Oprogramowanie na zamówienie czy gotowe: jak naprawdę zdecydować
Ramy decyzji między kupnem a budową oprogramowania — łącznie z całkowitym kosztem posiadania, o którym zapomina się po obu stronach.
Domyślną odpowiedzią powinno być: kupić. Gotowe oprogramowanie jest tańsze, szybsze, lepiej przetestowane i utrzymywane przez kogoś innego. Firma, która buduje coś, co mogła kupić, zwykle podjęła drogą decyzję z wygodnego powodu.
Ale domyślna odpowiedź nie zawsze jest właściwa — a sposobem, żeby to sprawdzić, nie jest porównanie funkcji.
Zły sposób podejmowania decyzji
Większość decyzji „zbudować czy kupić” zapada na podstawie porównania list funkcji. Daje to złe wyniki w obie strony: produkty wygrywają, bo mają funkcje, z których nigdy nie skorzystasz, albo przegrywają, bo brakuje im jednej rzeczy, którą dało się obejść.
Lepsze ujęcie: które elementy tego, jak pracujesz, są Twoją przewagą konkurencyjną, a które po prostu tym, jak robią to wszyscy?
Naginanie procesu do produktu jest tanie, gdy proces jest typowy. Jest drogie, gdy to właśnie ten proces jest powodem, dla którego klienci Cię wybierają.
Kiedy zakup jest oczywiście właściwy
- Księgowość, płace, poczta, HR. Uregulowane, dobrze zrozumiane i wszędzie podobne. Budowanie tego jest niemal nie do obrony.
- CRM dla typowego procesu sprzedaży. Jeśli Twój lejek wygląda jak lejek wszystkich innych, produkt będzie pasował.
- Wszystko, w czym najtrudniejsza jest zgodność z przepisami. Niech ktoś inny nadąża za zmianami.
- Gdy nie ma kto utrzymywać oprogramowania. To punkt, który się ignoruje. Oprogramowanie na zamówienie to stałe zobowiązanie, a nie zakup.
Kiedy budowa zaczyna mieć sens
- Proces jest produktem. Firma logistyczna, której logika wyznaczania tras jest naprawdę lepsza niż u konkurencji. Agencja, której sposób realizacji jest powodem, dla którego klienci zostają.
- Dane są uwięzione w kilku systemach i nikt nie ufa liczbom. Czasem budowa to cienka warstwa, dzięki której istniejące systemy zaczynają się zgadzać — często to oprogramowanie o najwyższym zwrocie, jakie firma kiedykolwiek zamówi.
- Cennik za stanowisko stał się absurdalny względem wartości. Pięćdziesiąt licencji na narzędzie, z którego zespół używa 15%, to realna kwota warta zestawienia z budową.
- Obejście stało się procesem. Arkusze równoległe do oficjalnego systemu, eksporty, które się ponownie importuje, jedna osoba, która „robi tę rzecz w piątki”.
- Potrzebujesz czegoś, co nie istnieje. Rzadko, ale się zdarza, zwłaszcza w wyspecjalizowanych branżach.
Koszty, o których się zapomina
Przy zakupie: koszt za stanowisko rosnący razem z firmą, praca nad integracją, żeby wszystko pasowało, dane, których nie da się łatwo wyeksportować, podwyżki, na które nie masz wpływu, i funkcje usuwane przy przebudowie, o którą nikt nie prosił.
Przy budowie: sama budowa to zwykle mniejsza połowa. Potem jest hosting, monitoring, aktualizacje bezpieczeństwa i zależności, zmiany w przeglądarkach i systemach, naprawa błędów i to, że każda prośba o ulepszenie trafia teraz do Ciebie. Zaplanuj 15–25% kosztu budowy rocznie na utrzymanie oprogramowania w dobrej formie — na stałe.
Odpowiedź hybrydowa, zwykle właściwa
Większość dobrych rozwiązań nie jest czysta. Wygląda tak:
- kupujesz systemy standardowe (księgowość, poczta, CRM);
- budujesz cienką warstwę specyficzną dla Ciebie;
- porządnie je łączysz, żeby dane przepływały bez przepisywania.
Masz wtedy koszty utrzymania małego kodu i możliwości dużego systemu. To mniej satysfakcjonujące niż „zbudowaliśmy własną platformę”, ale zwykle lepsza decyzja biznesowa.
Test na ten tydzień
Dla procesu, który rozważasz zautomatyzować własnym oprogramowaniem, odpowiedz na trzy pytania:
- Czy konkurent, który robiłby to dokładnie tak jak my, miałby przewagę? Jeśli nie — kupuj.
- Czy próbowaliśmy dopasować istniejący produkt i się nie udało? Jeśli nie próbowaliście, nie czas jeszcze na decyzję.
- Kto będzie to utrzymywał za dwa lata? Jeśli nie ma odpowiedzi — kupuj.
Dwie jasne odpowiedzi „budować” i konkretna osoba w pytaniu trzecim oznaczają, że budowę warto wycenić. Mniej — i lepiej kupić, zintegrować i wrócić do tematu za rok.
Prowadzimy tę rozmowę z obu stron. Jeśli się nad tym zastanawiasz, opisz nam proces — dostaniesz uczciwą ocenę, łącznie z sytuacjami, w których mówiliśmy ludziom, żeby niczego nie budowali.
Oskar Szymczak
Założyciel i inżynier oprogramowania
Odpowiada za techniczną stronę każdego projektu — architekturę, programowanie i decyzje, które później drogo zmieniać.
Więcej o zespolePotrzebujesz w tym pomocy?
To jest praca, którą wykonujemy. Te strony wyjaśniają, jak do niej podchodzimy.