Oprogramowanie dedykowane — kiedy gotowe narzędzie przestaje wystarczać
Gotowe narzędzia są tańsze, szybsze we wdrożeniu i w większości przypadków wystarczające. Problem zaczyna się, gdy firma zaczyna zmieniać sposób pracy po to, żeby zmieścić się w cudzym oprogramowaniu.
- Dedykowane ma sens tam, gdzie proces stanowi przewagę firmy — nie dla procesów standardowych.
- Kod należy do firmy, która za niego zapłaciła. To powinno być w umowie wprost.
- Pierwsza wersja to kwestia miesięcy; budżet planowany tylko do uruchomienia jest błędem.
- System musi dać się przejąć komuś innemu — inaczej jest zobowiązaniem, nie aktywem.
Kiedy to się opłaca, a kiedy nie
| Rozwiązanie dedykowane | Gotowe narzędzie |
|---|---|
| Proces jest przewagą firmy i nie mieści się w gotowym narzędziu | Proces jest standardowy i wygląda tak samo w każdej firmie |
| Zespół obchodzi ograniczenia narzędzia arkuszami „obok" | Narzędzie robi to, co trzeba, bez obejść |
| Koszt licencji rośnie szybciej niż wartość, którą wnoszą | Koszt licencji jest przewidywalny i akceptowalny |
| Potrzebna jest integracja, której narzędzie nie przewiduje | Wymagane integracje są dostępne w standardzie |
Co zbudowaliśmy
System zamawiania i obsługi płatności w gastronomii
Aplikacja obsługująca pełną ścieżkę: zamówienie klienta, płatność online, wydruk dokumentu na drukarce termicznej, e-paragon, faktura VAT przy podanym NIP-ie oraz powiadomienia. Około 26 tysięcy linii kodu, 170 testów automatycznych, wdrożenie produkcyjne po trzech miesiącach, rozwój i utrzymanie do dziś.
Charakterystyczna cecha tego projektu: rozwiązanie jest świadomie zbudowane pod jeden podmiot, bez uogólnień „na przyszłość". Abstrakcje dokładane na zapas kosztują od razu, a zwracają się tylko wtedy, gdy przewidywanie okaże się trafne.
System sprzedażowy z analityką dla zespołu terenowego
Aplikacja webowa dla firmy z branży farmaceutycznej, obsługiwana przez konsultantów pracujących w terenie w całej Polsce. Poza obsługą sprzedaży zawiera panele analityczne z filtrowaniem po regionach, województwach, sieciach sprzedaży, produktach i kategoriach.
Jak pracujemy
- Proces przed technologią. Najpierw rozumiemy, jak firma działa dziś i gdzie realnie boli.
- Architektura pod problem. Dobór technologii wynika z zadania, nie z tego, co akurat modne.
- Etapy z działającą wersją. Kierunek koryguje się po miesiącu, nie po roku.
- Testy i migracje od początku. Bez nich każda późniejsza zmiana jest ryzykiem.
- Przekazanie i utrzymanie. Kod, dokumentacja i możliwość przejęcia przez kogoś innego.
Pytania, które padają najczęściej
Kiedy dedykowane oprogramowanie jest lepsze od gotowego SaaS?
Gdy proces, który stanowi o przewadze firmy, nie mieści się w gotowym narzędziu — i firma zaczyna dopasowywać sposób pracy do oprogramowania zamiast odwrotnie. Albo gdy koszt licencji rośnie z liczbą użytkowników szybciej niż wartość, którą one wnoszą.
Dla procesów standardowych — księgowość, poczta, dokumenty — gotowe narzędzia są prawie zawsze lepszym wyborem i odradzamy budowanie ich od zera.
Do kogo należy kod źródłowy?
Do firmy, która za niego zapłaciła. To powinno być zapisane w umowie wprost, razem z przekazaniem repozytorium i dokumentacji wdrożeniowej.
Warto sprawdzić ten punkt u każdego wykonawcy przed podpisaniem. Model, w którym kod zostaje u wykonawcy, a klient dostaje wyłącznie dostęp do działającej aplikacji, jest spotykany — ale to jest wtedy usługa abonamentowa, nie oprogramowanie na własność.
Ile trwa zbudowanie systemu od zera?
Pierwsza działająca wersja systemu obsługującego realny proces to zwykle kwestia kilku miesięcy — w jednym z naszych wdrożeń były to trzy miesiące do wersji działającej produkcyjnie.
Ale „pierwsza wersja" nie znaczy „koniec". System, który jest używany, generuje kolejne potrzeby; ten sam projekt rozwijał się długo po uruchomieniu i pozostaje na utrzymaniu. Planowanie budżetu wyłącznie do dnia uruchomienia jest najczęstszym błędem w takich projektach.
Co, jeśli firma urośnie albo proces się zmieni?
To jest główny argument za rozwiązaniem dedykowanym i jednocześnie jego test. System zbudowany pod konkretny proces daje się zmieniać razem z nim — pod warunkiem, że został napisany z myślą o zmianie, a nie o jak najszybszym uruchomieniu.
Praktycznie oznacza to testy automatyczne i migracje bazy danych prowadzone od pierwszego dnia. Bez nich każda zmiana po roku jest ryzykiem, a nie rutyną.
Czy dostanę system, który potem utrzyma ktoś inny?
Tak i uważamy to za wymóg, nie za dodatek. Oznacza to standardowe technologie zamiast egzotycznych, dokumentację wdrożeniową, migracje bazy w repozytorium i testy, które pozwalają kolejnej osobie zmienić kod bez modlitwy.
Wykonawca, który buduje system tak, że nikt inny go nie przejmie, rozwiązuje swój problem biznesowy kosztem klienta.
Jak wygląda praca w trakcie projektu?
Zaczynamy od procesu, nie od technologii: co się dzieje dziś, kto co robi, gdzie jest wąskie gardło. Dopiero potem powstaje decyzja o architekturze.
Dalej idzie to etapami z działającą wersją na końcu każdego z nich. Chodzi o to, żeby móc zobaczyć i skorygować kierunek po miesiącu, a nie po roku — bo część rzeczy da się ocenić dopiero na działającym systemie.
Co się dzieje po wdrożeniu?
System zostaje na utrzymaniu. W praktyce to najważniejsza część współpracy: systemy zewnętrzne zmieniają API, przepisy się zmieniają, a firma po roku działa inaczej niż w dniu wdrożenia.
Rozwiązanie, którego nikt nie pilnuje, przestaje działać w momencie pierwszej zmiany po drugiej stronie — zwykle bez ostrzeżenia i zwykle w najgorszym momencie.
Jak wygląda rozliczenie?
Zakres i sposób rozliczenia ustalamy przed startem, po rozmowie o procesie i przejrzeniu tego, co już działa w firmie. Wycena powstaje po tym etapie, a nie przed nim — inaczej byłaby zgadywaniem.
Po wdrożeniu system zostaje na utrzymaniu: poprawki, zmiany wynikające z rozwoju firmy i reakcja na zmiany po stronie systemów zewnętrznych. To osobne ustalenie, niezależne od samego wdrożenia.
Wyrosłeś z gotowego narzędzia?
Opisz, czego dziś nie da się zrobić i jak zespół to obchodzi. Odpowiem, czy to przypadek na system dedykowany, czy wystarczy integracja albo automatyzacja tego, co już macie — bo to zwykle tańsza droga.