Większość rozwijających się firm w Wielkiej Brytanii działa w oparciu o zlepek narzędzi SaaS: CRM, program księgowy, helpdesk, może system magazynowy — wszystko połączone arkuszami kalkulacyjnymi i sporą dawką ręcznego przepisywania danych. To nie jest błąd w planowaniu. To rozsądny punkt startowy. SaaS jest tani na początku, szybki we wdrożeniu, a ciężar utrzymania spoczywa na kimś innym. Pytanie nie brzmi, czy SaaS jest dobry. Pytanie brzmi, czy nadal pasuje do firmy, gdy ta zmienia kształt.
To decyzja, którą warto podjąć świadomie, a nie z automatu czy z bezwładności. Poniżej znajduje się praktyczny schemat porównania obu opcji pod kątem wymiarów, które faktycznie mają znaczenie biznesowe: kosztu w czasie, własności, integracji, skalowalności, bezpieczeństwa i tego, kto odpowiada, gdy coś się psuje.
Koszt: cena z metki a całkowity koszt posiadania
Ceny SaaS są zaprojektowane tak, by wyglądały niepozornie. Miesięczna opłata za użytkownika jest łatwa do zaakceptowania bez większej analizy. Ale rzeczywista krzywa kosztów zwykle rośnie wraz z rozwojem firmy: więcej stanowisk, wyższe progi użytkowania, funkcje zablokowane za dodatkową opłatą, o których istnieniu dowiadujesz się dopiero wtedy, gdy już jesteś uzależniony od platformy, oraz moduły dodatkowe, które po cichu stają się niezbędne. Patrząc na okres trzech do pięciu lat, a nie na pierwszy miesiąc, całkowity wydatek często okazuje się znacznie wyższy, niż początkowo się wydawało, i rośnie wraz z liczbą pracowników, a nie z dostarczaną wartością.
Oprogramowanie na zamówienie odwraca ten schemat. Koszt początkowy jest realny i trzeba go rzetelnie zabudżetować — nie da się tego obejść. Ale po zbudowaniu systemu bieżący koszt to głównie utrzymanie i hosting, a nie powtarzająca się opłata od użytkownika. Dla firmy, która spodziewa się dalszego wzrostu liczby pracowników lub wolumenu transakcji, znacząco zmienia to kształt krzywej kosztów. Właściwym porównaniem nie jest koszt budowy a rok subskrypcji. To koszt budowy plus pięć lat utrzymania w porównaniu z pięcioma latami wzrostu subskrypcji, uwzględniając progi i dodatki, których prawdopodobnie będziesz potrzebować.
Moment, w którym SaaS zaczyna zawodzić
Istnieje dość rozpoznawalny wzorzec u firm, które zaczynają kwestionować swój zestaw narzędzi SaaS. Zwykle nie jest to jedna wielka porażka, lecz nagromadzenie drobnych obejść:
- Arkusz kalkulacyjny po cichu stał się źródłem prawdy dla czegoś, co miało obsługiwać narzędzie SaaS
- Pracownicy ręcznie kopiują dane między dwoma systemami, ponieważ nie ma czystej integracji, albo integracja istnieje, ale kosztuje dodatkowo
- Firma płaci za subskrypcję najwyższego poziomu tylko po to, by odblokować jedną potrzebną funkcję
- Proces kluczowy dla sposobu konkurowania firmy musi zostać naginany, by pasował do ogólnego przepływu pracy, zamiast być odwrotnie
- Raportowanie wymaga eksportowania danych i odtwarzania ich gdzie indziej, ponieważ natywne raportowanie platformy nie odpowiada temu, jak firma faktycznie działa
Żaden z tych czynników z osobna nie jest powodem, by zamawiać oprogramowanie na zamówienie. Ale razem, utrzymując się w czasie, stanowią dość wiarygodny sygnał, że firma wyrosła z narzędzia, które nigdy nie zostało zaprojektowane specjalnie dla niej. Samo obejście też ma swój koszt: czas pracowników, wskaźnik błędów i koszt alternatywny wynikający z tego, że ludzie zajmują się ręczną weryfikacją danych zamiast czymś innym.
Integracja i to, kto naprawdę jest właścicielem danych
W miarę jak firma łączy coraz więcej systemów — CRM z finansami, operacjami i portalem dla klientów — integracja staje się ważniejszym czynnikiem niż koszt czy funkcje. Platformy SaaS bardzo się różnią pod względem otwartości. Niektóre oferują szerokie API. Inne traktują dostęp do API jako płatny poziom, eksportują dane w formatach utrudniających migrację, albo po prostu nie udostępniają danych potrzebnych firmie do prawidłowego połączenia własnych systemów. Warto to sprawdzić konkretnie dla każdej rozważanej platformy, zamiast zakładać z góry jej otwartość.
Własność danych to prawdziwe ryzyko biznesowe, a nie tylko techniczny szczegół. Jeśli kluczowy zbiór danych — dane klientów, historia transakcji, dane operacyjne — znajduje się na platformie SaaS na warunkach dostawcy, zdolność firmy do migracji, integracji, a nawet pełnego zrozumienia własnych danych może być ograniczona przez czyjś cudzy plan rozwoju komercyjnego. To rozsądny kompromis, gdy dane te nie mają strategicznego znaczenia. Ale to znacznie większa kwestia, gdy te dane są kluczowe dla działania firmy lub jej przewagi konkurencyjnej.
Uzależnienie od dostawcy działa w obie strony
Kusi, by ująć to jako uzależnienie od SaaS kontra swoboda oprogramowania na zamówienie, ale to nie do końca prawda. Obie ścieżki tworzą zależność, tylko innego rodzaju.
- Uzależnienie od SaaS: wzrost cen, wycofywanie funkcji, wymuszone aktualizacje albo przejęcie lub zamknięcie dostawcy — wszystko poza kontrolą firmy
- Uzależnienie w przypadku oprogramowania na zamówienie: firma bierze na siebie zobowiązanie do utrzymania systemu. Ktoś musi go łatać, rozwijać i rozumieć, gdy zmieniają się pracownicy i stosy technologiczne
Ryzyko związane z oprogramowaniem na zamówienie jest często niedoceniane, ponieważ jest mniej widoczne niż faktura za subskrypcję. Autorski system bez budżetu na utrzymanie, bez dokumentacji i bez planu na wypadek odejścia pierwotnego dewelopera to zobowiązanie, a nie aktywo. Każdy, kto zamawia oprogramowanie na zamówienie, musi zabudżetować jego dalsze życie, a nie tylko sam proces budowy.
Bezpieczeństwo, zgodność i odpowiedzialność
Dla firm w Wielkiej Brytanii obowiązki związane z ochroną danych wynikające z brytyjskiego RODO obowiązują niezależnie od tego, czy dane znajdują się na platformie SaaS, czy w systemie na zamówienie. Różnica ma charakter praktyczny, nie prawny: przy SaaS renomowany dostawca zazwyczaj bierze na siebie sporą część technicznej pracy nad bezpieczeństwem (łatanie, zabezpieczanie infrastruktury, kontrolę dostępu) w ramach usługi, choć firma nadal odpowiada za to, jak korzysta z danych i komu je udostępnia. Przy oprogramowaniu na zamówienie ta odpowiedzialność spoczywa w bardziej widoczny sposób na firmie i osobie utrzymującej system w jej imieniu.
Konkretne obowiązki regulacyjne, wymogi dotyczące lokalizacji danych oraz przepisy branżowe różnią się w zależności od sektora i powinny zostać potwierdzone z wykwalifikowanym doradcą, a nie wywnioskowane z ogólnych wskazówek, takich jak te. Chodzi tu o to, gdzie leży odpowiedzialność operacyjna, a nie o zastępstwo porady prawnej.
Kiedy SaaS jest właściwym wyborem
SaaS pozostaje rozsądnym wyborem domyślnym dla wielu potrzeb biznesowych i nie ma żadnej przewagi konkurencyjnej w wymyślaniu na nowo funkcji, które są towarem powszechnym:
- Funkcje, które są naprawdę uniwersalne dla wszystkich firm: e-mail, księgowość, administracja HR, podstawowy CRM
- Procesy na wczesnym etapie lub szybko się zmieniające, gdzie elastyczność liczy się bardziej niż dopasowanie
- Sytuacje, w których szybkość wdrożenia liczy się bardziej niż długoterminowa krzywa kosztów
- Wszystko, w czym firma nie ma (i nie chce mieć) wewnętrznych kompetencji do zarządzania utrzymaniem systemu na zamówienie
Jeśli jakieś obejście kosztuje kilka godzin miesięcznie i nikogo to szczególnie nie irytuje, to nie jest to argument biznesowy za tworzeniem oprogramowania na zamówienie. To zaokrąglenie błędu.
Kiedy oprogramowanie na zamówienie zwraca się finansowo
Oprogramowanie na zamówienie zwykle jest uzasadnione, gdy dany proces jest bliski temu, co naprawdę wyróżnia firmę, a nie tylko ją wspiera. Kilka rozpoznawalnych scenariuszy:
- Kluczowy proces operacyjny jest naprawdę nietypowy, a wciskanie go w ogólne narzędzie oznacza ciągłe kompromisy lub ręczne łatanie
- Firma płaci za wiele subskrypcji SaaS i oprogramowanie pośredniczące do integracji, które łącznie kosztują więcej niż dopasowany system w ciągu kilku lat
- Portal dla klientów musi odzwierciedlać konkretną logikę biznesową lub branding, których ogólne narzędzia nie są w stanie odtworzyć bez wysokich opłat za dostosowanie
- Dane z kilku odrębnych systemów trzeba połączyć w jeden widok operacyjny, a żaden gotowy produkt nie robi tego dobrze dla tej konkretnej kombinacji systemów
- Ręczne obejście (arkusze kalkulacyjne, kopiowanie i wklejanie między narzędziami, doraźne raportowanie) stało się realnym źródłem błędów lub opóźnień wpływających na klientów lub przychody
W każdym z tych przypadków argument za oprogramowaniem na zamówienie nie polega na tym, że chce się mieć coś autorskiego dla samej idei. Chodzi o to, że skumulowany koszt, ryzyko i brak elastyczności wynikające z wciskania rosnącej, specyficznej firmy w ogólne narzędzie przewyższają koszt zbudowania czegoś, co pasuje.
Podejmowanie decyzji
Użytecznym sposobem na sprawdzenie tej decyzji jest uczciwe spojrzenie na to, ile tarcia istnieje obecnie, a nie ile tarcia mogłoby teoretycznie kiedyś wystąpić. Policz obejścia. Wylicz koszt czasu pracowników, który pochłaniają. Zsumuj, ile firma faktycznie płaci za obecny zestaw narzędzi SaaS, uwzględniając progi i dodatki, i zaprojektuj to na trzy do pięciu lat naprzód, biorąc pod uwagę realistyczny wzrost. Następnie zadaj pytanie, czy dany proces to coś, co firma musi robić tak samo jak każdy konkurent, czy też robienie tego inaczej jest częścią tego, jak firma wygrywa.
Jeśli odpowiedź brzmi, że wszystko jest mniej więcej w porządku, a obejścia to drobne uciążliwości, SaaS wciąż spełnia swoje zadanie. Jeśli odpowiedź brzmi, że firma wydaje realne pieniądze i realny czas na kompensowanie narzędzia, które nigdy nie zostało dla niej zbudowane, to jest właśnie moment, w którym warto przeprowadzić poważną rozmowę o zakresie oprogramowania na zamówienie — nie wcześniej.