Oprogramowanie na zamówienie czy gotowe: jak naprawdę decydują małe firmy

Prędzej czy później każda rosnąca mała firma staje na tym samym rozdrożu: dalej mocować się z gotowym narzędziem, które prawie pasuje, czy zapłacić komuś za zbudowanie oprogramowania, które pasuje dokładnie. Przedstawia się to jako czyste „albo-albo” — kup bezpieczną, tanią, gotową rzecz, albo zaszalej z ryzykownym projektem na zamówienie. Takie ujęcie jest błędne i kosztuje ludzi mnóstwo pieniędzy. Prawdziwa decyzja jest cichsza, bardziej konkretna i znacznie łatwiejsza do trafienia, niż chcą wmówić Państwu sprzedażowe gadki z obu stron.

Widziałem, jak ta decyzja idzie w obie strony, wiele razy. Sprzedawca detaliczny, który poświęcił dwa lata i niemałą fortunę na budowę dedykowanego systemu magazynowego, który gotowy produkt obsłużyłby za cenę miesięcznej subskrypcji. I, na odwrót: firma usługowa płacąca za jedenaście różnych narzędzi SaaS plus osobę, której rzeczywistą pracą stało się przepisywanie danych między nimi, podczas gdy jedna skromna aplikacja na zamówienie zastąpiłaby cały ten zestaw i zwróciłaby się w ciągu roku. Obu dało się uniknąć. Obie wynikały z odpowiedzi na złe pytanie.

Odpowiedzmy więc na to właściwe. To nie jest argument sprzedażowy za oprogramowaniem na zamówienie, choć budowanie oprogramowania to część tego, czym się zajmujemy. To ramy decyzyjne, które poleciłbym znajomemu prowadzącemu firmę — wraz ze wszystkimi przypadkami, gdy uczciwa rekomendacja brzmi nie buduj niczego.

Co naprawdę oznacza każda opcja (poza broszurą)

Gotowe oprogramowanie to wszystko, co kupują Państwo w gotowej postaci i konfigurują: pakiet księgowy, narzędzie do rezerwacji, CRM, tracker projektów, w którym żyje Państwa zespół. Ktoś zbudował to raz i sprzedaje ten sam produkt tysiącom firm. Wynajmują to Państwo, dostosowują swój proces, aby do niego pasował, a w zamian otrzymują coś dojrzałego, wspieranego i taniego w przeliczeniu na użytkownika od pierwszego dnia.

Oprogramowanie na zamówienie jest budowane wokół Państwa procesu, a nie odwrotnie. Może to być pełny dedykowany system, ale dla małej firmy to znacznie częściej coś skromnego — mała aplikacja wewnętrzna, portal klienta, narzędzie zszywające dwa systemy i usuwające codzienną ręczną pracę. Cechą definiującą nie jest rozmiar ani koszt. Jest nią to, że robi dokładnie to, czego Państwo potrzebują, i nic ponadto, ponieważ zostało ukształtowane specjalnie pod Państwa firmę.

Oto część, którą broszury pomijają: to nie są wrogowie, a wybór niemal nigdy nie dotyczy całej firmy naraz. Mądry wzorzec dla większości małych firm to kręgosłup gotowych narzędzi do spraw uniwersalnych — księgowość, e-mail, płatności — z niewielką ilością oprogramowania na zamówienie dokładnie tam, gdzie Państwa firma robi coś, czego rynek nie oferuje, albo gdzie narzędzia odmawiają rozmowy ze sobą. Dobre decydowanie oznacza decydowanie proces po procesie, a nie jednym dramatycznym głosowaniem.

Uczciwy argument za gotowym rozwiązaniem

Dla przytłaczającej większości tego, co robi mała firma, gotowe jest właściwą odpowiedzią i nie ma tu dyskusji. Praca jest naprawdę taka sama jak u wszystkich innych. Państwa faktury nie są wyjątkowym płatkiem śniegu. Płace podlegają tym samym zasadom co u firmy obok. Gdy tysiące firm potrzebują identycznej rzeczy, produkt zbudowany dla nich wszystkich będzie tańszy, bardziej niezawodny i lepiej wspierany niż cokolwiek, co mogliby Państwo zamówić — ponieważ koszt jego budowy rozłożono na wszystkich tych klientów, a nie poniesiono go w pojedynkę.

Otrzymują też Państwo rzeczy, które łatwo niedoceniać, dopóki ich się nie straci: ktoś inny naprawia błędy, ktoś inny dba o bezpieczeństwo, ktoś inny dodaje funkcje, gdy Państwo śpią. Gdy ktoś odejdzie, kolejny pracownik prawdopodobnie zna już popularne narzędzia. I można zacząć jutro — bez projektu, bez czekania, bez ryzyka, że rzecz nigdy nie powstanie. Dla procesu standardowego płacenie za samodzielne odbudowanie go jest jak zamawianie czajnika na miarę. Nie zagotuje wody ani trochę lepiej, a Państwo będą jedyną osobą na ziemi, która umie go naprawić.

Gdzie gotowe po cichu przestaje pasować

A jednak. Jest powód, dla którego to pytanie wciąż wraca, i jest nim to, że gotowe oprogramowanie ma sufit, którego nie zauważa się, dopóki się o niego nie uderzy. Początki są cudowne — narzędzie robi 90% tego, czego potrzeba, a brakujące 10% wydaje się błahe. Potem firma rośnie we własny kształt, a te 10% zamienia się w miejsce, w które ucieka cały Państwa czas.

Awaria rzadko wygląda jak pojedyncza katastrofa. Wygląda jak tysiąc małych obejść. Arkusz, który żyje obok oficjalnego systemu, bo oficjalny system nie potrafi zrobić jednej rzeczy, której Państwo potrzebują. Osoba, która co rano eksportuje raport z narzędzia A i ręcznie wkleja go do narzędzia B. Konwencja kolorystyczna, którą wszyscy mają w pamięci, bo oprogramowanie nie pozwala dodać pola, na którym naprawdę Państwu zależy. Żadne z tego nie jest kryzysem. Razem są odgłosem oprogramowania, które Państwo przerośli.

Jest też subtelniejsza pułapka. Czasem narzędzie pasuje do firmy, ale model cenowy nie. Cena za stanowisko jest urocza przy pięciu osobach i brutalna przy pięćdziesięciu. Opłata transakcyjna niewidoczna przy niskim wolumenie staje się podatkiem od wzrostu przy wysokim. Gdy rachunek skaluje się szybciej niż wartość, gotowe może stać się opcją drogą — choć każda pojedyncza subskrypcja wygląda tanio.

Prawdziwe pytanie o koszt (to nie cena z metki)

Większość ludzi porównuje te opcje na złej liczbie. Patrzą na miesięczną subskrypcję wobec wyceny budowy na zamówienie, widzą, że jedna jest mała, a druga duża, i przestają myśleć. Ale subskrypcja nie jest prawdziwym kosztem gotowego, a wycena budowy nie jest prawdziwym kosztem na zamówienie. Aby zdecydować uczciwie, trzeba policzyć całkowity koszt w ciągu trzech lat — wliczając godziny, które zespół traci na narzędzie, które nie do końca pasuje.

Po stronie gotowej proszę zsumować subskrypcje (wszystkie, w tym nakładające się), razy liczba użytkowników, razy wzrost, plus koszt wynagrodzeń za ręczne obejścia, które narzędzia wymuszają. Ta ostatnia pozycja jest niewidoczna na żadnej fakturze i często jest największą liczbą. Po stronie na zamówienie proszę policzyć nie tylko budowę, ale i bieżącą rzeczywistość: hosting, utrzymanie, sporadyczną zmianę w miarę jak firma się przeobraża. Oprogramowanie na zamówienie to nie zakup jednorazowy; to coś, co Państwo posiadają, a posiadanie rzeczy wiąże się z kosztami bieżącymi.

Gdy zliczy się to uczciwie, obraz często odwraca się od pierwszego odruchu. Narzędzie na zamówienie z realną ceną z góry może być tańsze w ciągu trzech lat niż stos subskrypcji plus pół etatu ręcznego przerzucania. I równie często idzie to w drugą stronę — obejścia są irytujące, ale tanie, a budowa nigdy nie zwróciłaby swojego kosztu. Rzecz nie w tym, że jedna zawsze wygrywa. Rzecz w tym, że nie da się tego wiedzieć bez policzenia ukrytych pozycji, a prawie nikt tego nie robi.

Ramy decyzyjne, które przejdą Państwo samodzielnie

Nie potrzeba konsultanta, by podjąć pierwszą, sensowną decyzję w tej sprawie. Potrzeba czterech uczciwych pytań, zadawanych proces po procesie — nie o całą firmę, lecz o tę konkretną rzecz, która uwiera Państwa właśnie teraz.

1. 1
   Czy ten proces jest standardowy, czy specyficzny dla Państwa?

   Jeśli tysiące firm robi to tak samo (fakturowanie, płace, e-mail), mocno skłaniajcie się ku gotowemu. Jeśli to sposób, w jaki konkurujecie lub unikalnie działacie, na zamówienie zaczyna mieć sens.
2. 2
   Czy jakiś produkt już robi 90% tego?

   Jeśli tak, wdróżcie go i dostosujcie swój proces — ostatnie 10% rzadko warte jest obudowywania. Jeśli nic nie pokrywa nawet rdzenia, to prawdziwy sygnał na zamówienie, a nie problem konfiguracji.
3. 3
   Ile naprawdę kosztuje Państwa niepasowanie?

   Wyceńcie tygodniowe godziny tracone na obejścia, razy rok. Jeśli to mało, da się z tym żyć. Jeśli to znaczący kawałek czyjegoś wynagrodzenia, budowa może się zwrócić.
4. 4
   Czy ten proces pozostanie stabilny przez kilka lat?

   Oprogramowanie na zamówienie nagradza stabilne, dobrze rozumiane procesy. Jeśli to, jak tu pracujecie, wciąż zmienia się co kwartał, jest za wcześnie, by utwardzać to w kodzie — zachowajcie elastyczność i wróćcie do tego później.

Przejdźcie przez te cztery pytania, a większość procesów sama się posortuje. Ciekawe przypadki to te w środku i zwykle mają to samo rozwiązanie: nie pełny system na zamówienie, lecz mały, celowany kawałek oprogramowania na zamówienie siedzący na istniejących narzędziach — portal, konektor, jedna aplikacja usuwająca jedną bolesną pracę. Ta środkowa ścieżka to miejsce, gdzie małe firmy biorą z obu opcji to, co najlepsze, i to opcja, którą ujęcie „wszystko albo nic” ukrywa przed Państwem.

Środkowa ścieżka, którą niemal wszyscy pomijają

Gdy ludzie wyobrażają sobie oprogramowanie na zamówienie, widzą gigantyczny dedykowany system zastępujący wszystko — straszny, roczny projekt ze straszną ceną. Ta wersja istnieje i dla większości małych firm jest niewłaściwa. Wersja, która naprawdę wygrywa, jest mała i chirurgiczna: zachowajcie wszystkie dobre gotowe narzędzia i zbudujcie tylko cienką warstwę na zamówienie, która sprawia, że działają tak, jak Państwo pracują.

• Konektor, który przepycha nowe zamówienia prosto do fakturowania i CRM, tak że nikt już nigdy nie przepisuje adresu.
• Prosty portal klienta na istniejących systemach, tak że klienci obsługują się sami, zamiast pisać do Państwa e-maile.
• Jednoekranowa aplikacja wewnętrzna zastępująca cieniowy arkusz, na którym wszyscy po cichu polegają.
• Mały pulpit, który automatycznie scala trzy raporty w jeden, w każdy poniedziałek rano.
• Most teren–biuro, tak że szczegóły zleceń z miejsca wracają bez drugiej rundy wprowadzania danych.

Każde z nich jest skromne. Żadne nie zastępuje pakietu księgowego ani e-maila. Każde usuwa jedno konkretne, powtarzające się źródło tarcia — a ponieważ jest zbudowane pod Państwa proces, nie ma obejść, bo obejście jest produktem. To też, dogodnie, miejsce, w które wpasowuje się dziś SI: nie jako powód, by przebudowywać wszystko, lecz jako inteligentny komponent, który wstawiają Państwo w tę cienką warstwę na zamówienie, gdy zadanie obejmuje nieuporządkowany ludzki język lub ocenę. Architektura jest ta sama; warstwa po prostu stała się zdolniejsza.

Przykład z życia: firma z jedenastoma narzędziami

Zilustrujmy to konkretem na przypadku złożonym — zanonimizowanym i na tyle typowym, że rozpoznają Państwo w nim kawałki własnej firmy. Średniej wielkości firma usługowa, około trzydziestu osób, przyszła do nas przekonana, że potrzebuje wielkiej platformy na zamówienie, by „wreszcie naprawić wszystko”. Inna pracownia wyceniła im zawrotną kwotę za pełny dedykowany system i chcieli drugiej opinii, zanim podpiszą.

Sytuacja

Zaczęliśmy tam, gdzie zawsze: nie od oprogramowania, lecz od ich tygodnia. Działali na jedenastu osobnych narzędziach. Kilka się nakładało — dwa z nich, szczerze mówiąc, robiły niemal to samo. Prawdziwy ból nie tkwił w żadnym pojedynczym narzędziu; każdy produkt z osobna był w porządku. Bólem były luki między nimi. Nowy klient oznaczał te same dane wpisane ręcznie do czterech systemów. Praca jednej osoby po cichu stała się „przerzucaniem danych”, kilka godzin dziennie, codziennie. Cieniowe arkusze miały swoje cieniowe arkusze.

Co zrobiliśmy

Pełna platforma na zamówienie, którą im wyceniono, zastąpiłaby bez powodu doskonale działające narzędzia i kosztowała fortunę. Odradziliśmy ją więc — na głos, na pierwszym spotkaniu, przed jakąkolwiek umową. Zamiast tego zrobiliśmy najpierw tanią, mało efektowną pracę: od razu wycięliśmy dwie zbędne subskrypcje. Potem zbudowaliśmy jeden mały konektor na zamówienie — cienką warstwę — który nowego klienta wprowadzonego raz automatycznie przepychał do systemów, które go potrzebowały. Żadnej wielkiej platformy. Żadnego wyrwij-i-zastąp. Chirurgiczny kawałek oprogramowania na zamówienie siedzący na narzędziach, które zachowali.

Rezultat

Praca „przerzucania danych” w większości zniknęła — te godziny wróciły do realnej pracy z klientem. Budowa kosztowała ułamek wyceny platformy na zamówienie i, między zaoszczędzonymi subskrypcjami a odzyskanym czasem, wygodnie zwróciła się w pierwszym roku. (Proszę traktować te liczby jako poglądowe, nie jako obietnicę — każda firma jest inna.) Lekcją nie było „na zamówienie wygrało”. Lekcją było to, że właściwą odpowiedzią był mały kawałek na zamówienie w dokładnie jednym miejscu, pośród morza gotowych narzędzi, które słusznie zachowali. Kosztownym błędem byłoby potraktowanie tego jako „wszystko albo nic”.

Zanim zobowiążą się Państwo do budowy czegokolwiek

Jeśli Państwa uczciwe odpowiedzi wskazują na zamówienie — dobrze, ale zwolnijcie jeszcze na jeden takt, bo tu marnuje się pieniądze nawet wtedy, gdy decyzja jest słuszna. Porażki w oprogramowaniu na zamówienie rzadko dotyczą kodu. Dotyczą zakresu, własności i zbyt dużego startu — tak samo jak projekty gotowe po cichu gasną, gdy nikt nie czuje się ich właścicielem.

Zacznijcie od najmniejszej wersji, która daje realny rezultat, a nie od pełnej wizji. Wybierzcie jeden bolesny proces, zbudujcie cienką warstwę, która go naprawia, uruchomcie ją na żywo i pozwólcie, by wygrana sfinansowała kolejny kawałek. Upewnijcie się, że posiadają Państwo to, co zbudowano — kod, dane, jasne przekazanie — tak byście nigdy nie utknęli z jednym dostawcą, jak utknęliście z narzędziem, które przerośliście. I nalegajcie, by ten, kto to buduje, odwiódł Państwa od części, których nie potrzebujecie. Dobry partner zmniejsza Państwa projekt. Tylko zły go rozdmuchuje.

Częste pytania