W każdej firmie, do której wchodzimy, prędzej czy później pada to samo pytanie: „czy zbudować coś własnego, czy kupić gotowca?". Odpowiedź „to zależy" jest prawdziwa, ale bezużyteczna. Ten tekst pokazuje, od czego naprawdę powinno zależeć — i jakie pułapki czekają po obu stronach, jeśli prowadzisz firmę 10–50 osób, a nie korporację z budżetem na własny zespół developerski.
W praktyce większość MŚP wpada w jeden z dwóch skrajnych dołków. Pierwszy to „kupmy gotowe, dostawca obiecał, że pokrywa 90% potrzeb" — a po roku okazuje się, że pokrywa 55% i reszta to drogie „customizacje", których nie da się aktualizować. Drugi to „zbudujmy własne, bo gotowe nas nie zadowala" — i firma po dwóch latach ma aplikację, którą rozumie tylko jeden programista, który właśnie odszedł.
Da się tego uniknąć. Trzeba tylko dwa razy w tygodniu pomyśleć o czymś nudnym: czy to, co właśnie wybieramy, jest rdzeniem naszego biznesu, czy tylko narzędziem wokół niego.
Domyślnie kupuj. Powody, dla których gotowe zwykle wygrywa
Jeśli proces, który chcesz wesprzeć, robi tak samo tysiąc innych firm — księgowość, kadry, magazyn, fakturowanie, podstawowy CRM — to z prawdopodobieństwem 95% gotowy system będzie tańszy, bezpieczniejszy i lepiej utrzymywany niż cokolwiek, co zlecisz na zamówienie.
Dlaczego? Bo koszt napisania to tylko czubek góry lodowej. Pod wodą siedzą:
- Utrzymanie — aktualizacje pod nowe wersje JPK, KSeF, RODO, zmiany w VAT, nowe standardy e-faktur. Dostawca Comarch Optima, enova365 czy Subiekt GT robi to dla wszystkich klientów na raz. W aplikacji własnej każdą zmianę finansujesz Ty.
- Bezpieczeństwo — łatki, audyty, polityki haseł, integracje z MFA. Gotowy SaaS dorzuca to w cenie licencji.
- Wiedza w branży — gotowy ERP wie o split payment, mechanizmie odwrotnego obciążenia, fakturach RR. Twój programista będzie się tego uczyć na Twój koszt.
- Ciągłość — gdy firma rośnie z 15 do 35 osób, gotowy system tylko skaluje licencje. Własny często wymaga przepisania.
Mówiąc krótko: nie buduj systemu finansowo-księgowego, nie buduj kadrowo-płacowego, nie buduj własnego CRM-a od zera. To są obszary, w których konkurencja produktowa jest gęsta, a Twój przewagi konkurencyjnej tam nie ma.
Kiedy własny software faktycznie ma sens
Są jednak sytuacje, w których gotowiec fundamentalnie nie pasuje, a próba „doginania" go customizacjami kończy się gorzej niż projekt od zera. Wskaźniki, po których to poznasz:
- Rdzeń biznesu, w którym jesteście inni niż wszyscy. Macie własną metodę wyceny, własny układ konfiguratora produktu, własny sposób planowania produkcji, którego konkurencja nie ma. To wasza przewaga — i właśnie ona nie zmieści się w pudełku gotowego ERP-a.
- Powtarzalny, masowy proces, którego żaden gotowy moduł nie obsługuje. Często to konfigurator wariantów, kalkulator ofert, generator dokumentów technicznych, dashboard operacyjny dla brygadzistów.
- Integracja, której rynek nie ma. Wasz dostawca chce dane w nietypowym formacie, urząd wymaga specyficznego raportu, klient korporacyjny narzuca własny EDI. Wszyscy będą wam to liczyć jako „customizację" — własne narzędzie wyjdzie taniej.
- Stosunkowo wąski zakres. Aplikacja zrobiona pod jeden konkretny ból (wycena, ofertowanie, raportowanie produkcyjne) ma 80% mniejszy zakres niż „kompleksowy ERP" — i jest dzięki temu realna do zbudowania w 2–4 miesiące, a nie w 2 lata.
Reguła kciuka: buduj to, co stanowi waszą przewagę konkurencyjną. Kupuj wszystko inne.
Przykład z życia — kiedy własna aplikacja zwraca się w pół roku
U jednego z naszych klientów — 28-osobowego producenta konstrukcji stalowych — sytuacja wyglądała tak. Mieli enova365 do księgowości, magazynu i sprzedaży. Z gotowym systemem 0 problemów. Ale ofertowanie wyglądało koszmarnie: każda oferta to było 30–120 minut pracy konstruktora w Excelu z makrami, obliczanie zużycia stali, kosztu malowania, transportu, marży. Konstruktor był jeden, a zapytań spływało 40 tygodniowo. Połowa zapytań nigdy nie dostawała oferty na czas, część klientów odchodziła.
Dostawca enovy zaproponował „dedykowany moduł ofertowy" za ok. 90 tys. zł plus utrzymanie. Po przejrzeniu zakresu okazało się, że i tak nie pokryje 40% logiki konstruktora i wymagałby równoległego Excela. Zbudowaliśmy zamiast tego osobną aplikację webową w .NET, zintegrowaną z enovą po REST API: katalog produktów synchronizuje się z enovy, oferty po akceptacji wpadają do enovy jako dokument handlowy, faktura już idzie standardową drogą.
Koszt: ok. 65 tys. zł, 3 miesiące pracy. Efekt: czas wystawienia oferty spadł z 30–120 minut do 6–8 minut. Konstruktor przestał być wąskim gardłem. Liczba ofert wystawionych w miesiąc wzrosła z około 90 do ponad 250. Po 5 miesiącach projekt zwrócił się samym wzrostem konwersji ofert na zamówienia. Aplikacja jest mała (jeden ekran kalkulatora, jeden ekran listy), dokumentacja mieści się na 12 stronach, kolejny developer wchodzi w nią w jeden dzień.
To nie był „własny ERP". To było jedno małe narzędzie, które robi jedną rzecz lepiej niż jakikolwiek gotowiec na rynku. I dlatego zadziałało.
Pułapka „customizacji" gotowego systemu
Najgorszy ze światów to środek: kupić gotowy ERP i potem przerabiać go pod siebie. Każda taka modyfikacja brzmi sensownie w ofercie („dodajemy pole, zmieniamy workflow, robimy własny wydruk"), a w sumie po trzech latach masz system, który:
- nie da się zaktualizować bez przepisywania zmian
- jest droższy w utrzymaniu niż własna aplikacja
- nadal nie robi dokładnie tego, czego chciałeś
- jest uzależniony od jednego konkretnego partnera wdrożeniowego
Widzieliśmy projekty, w których suma zafakturowanych „drobnych zmian" w gotowym ERP przekroczyła w trzy lata koszt zbudowania całej aplikacji dedykowanej od zera. I dalej szła licencja, której firma nie mogła odpuścić, bo „tam jest księgowość".
Reguła: jeśli już na etapie wdrożenia gotowca dostawca proponuje więcej niż trzy customizacje na poziomie kodu, to znak ostrzegawczy. Albo wybrałeś zły system, albo to, co próbujesz w nim zrobić, powinno być oddzielną aplikacją zintegrowaną po API.
Krótki test decyzyjny
Zanim podpiszesz cokolwiek, odpowiedz uczciwie na pięć pytań:
- Czy proces, który ma wspierać oprogramowanie, jest rdzeniem waszej przewagi konkurencyjnej, czy tylko zapleczem?
- Czy na rynku istnieje gotowy system, który pokrywa co najmniej 80% potrzeb bez modyfikacji kodu? (Nie: „z customizacjami". Bez nich.)
- Czy wasz proces jest na tyle stabilny, że nie będziecie go znacząco zmieniać przez najbliższe 3 lata?
- Czy macie kogoś, kto będzie właścicielem biznesowym projektu — nie IT, tylko osoba znająca proces od podszewki?
- Czy macie zaplanowane utrzymanie po wdrożeniu? (Własna aplikacja bez dedykowanego budżetu na utrzymanie umiera w ciągu 2 lat.)
Trzy lub więcej „tak" przy pytaniach 2 i 3 — kupuj gotowe. Trzy lub więcej „tak" przy 1, 4 i 5, a „nie" przy 2 — rozważ budowę. „Nie" przy pytaniu 4 — nie buduj nic, dopóki nie znajdziesz tej osoby.
Co dalej
Decyzja Build vs Buy rzadko jest „albo–albo". W praktyce większość MŚP, dla których pracujemy, ma układ hybrydowy: gotowy ERP do księgowości, magazynu i kadr (Comarch Optima, enova365 albo Subiekt) plus jedna lub dwie własne aplikacje punktowe na rdzeniowe procesy, zintegrowane po API. Tak właśnie wygląda zdrowy stack IT w firmie 20–40 osób.
Jeśli zastanawiasz się nad konkretnym projektem i nie wiesz, po której stronie tej granicy powinien być — chętnie pomożemy go rozłożyć na czynniki pierwsze. Pierwsza rozmowa jest bezpłatna i trwa pół godziny.
Buduj to, co stanowi waszą przewagę konkurencyjną. Kupuj wszystko inne. Reszta to detale.