Kiedy odłożyć przepisanie systemu na później?

Twój system pochłania coraz więcej pieniędzy i spowalnia kolejne zmiany. Przepisanie go może wtedy wyglądać jak naturalny następny krok.

Problem pojawia się wtedy, gdy firma sama nie potrafi jeszcze jasno powiedzieć, jak powinny działać jej procesy. W takiej sytuacji nowy system może odziedziczyć te same problemy, które dziś przypisujesz staremu.

Ten tekst pomoże Ci ocenić, czy firma jest gotowa na przepisanie systemu, czy lepiej najpierw uporządkować procesy, odpowiedzialność i wymagania.

Odłóż przepisanie, gdy firma nie umie opisać swoich procesów

Jednym z najczęstszych powodów, żeby nie przepisywać systemu od razu, jest brak jasno opisanych procesów.

Mieliśmy taki przypadek u jednego z klientów. Kiedy przejęliśmy system, praktycznie wszyscy na niego narzekali. Operacje i biznes mówiły, że część funkcji nie działa, innych brakuje, a całość jest trudna w użyciu.

Po pewnym czasie okazało się, że część problemów nie wynikała bezpośrednio z technologii. Firma nie miała jednej, uzgodnionej wersji tego, jak powinny działać jej procesy.

Przykład: chcieliśmy poprawić jeden z procesów logistycznych. Pytaliśmy kierownika, jak powinien wyglądać, i na tej podstawie projektowaliśmy rozwiązanie. Później pojawiała się kolejna osoba i mówiła o wyjątkach, których wcześniej nikt nie wymienił. Jeszcze ktoś inny opisywał ten sam proces inaczej. Czasem te wersje były ze sobą sprzeczne.

Duża część wiedzy o działaniu firmy była w głowach kierowników i koordynatorów. Nie istniał jeden opis, do którego można było się odwołać i sprawdzić, która wersja procesu jest właściwa.

W takiej sytuacji zespół budujący nowy system nadal musi odpowiedzieć na te same pytania: jakie reguły zaimplementować, jakie wyjątki obsłużyć i kto ma podjąć decyzję, gdy wymagania się wykluczają.

Dlatego przed dużym rewrite’em warto sprawdzić dwie rzeczy. Po pierwsze, czy procesy są wystarczająco dobrze opisane. Po drugie, czy po stronie biznesu jest osoba, która może rozstrzygać sporne przypadki i podejmować ostateczne decyzje.

Znaczenie ma też dostępność zespołu operacyjnego. Jeśli osoby, które najlepiej znają codzienną pracę firmy, nie mają czasu uczestniczyć w projekcie, zespół technologiczny będzie projektował rozwiązanie na podstawie niepełnej wiedzy.

Przepisywanie systemu podczas dużych zmian w firmie zwiększa ryzyko

Sytuacja staje się jeszcze trudniejsza, gdy firma równocześnie zmienia model biznesowy albo najważniejsze procesy.

Wtedy wymagania do nowego systemu mogą zmieniać się jeszcze w trakcie projektu.

W tej samej firmie trwała duża transformacja związana z uruchamianiem nowych magazynów. To właśnie magazyny były wtedy głównym obszarem inwestycji, więc większość wymagań dla nowego systemu powstała z myślą o nich.

Pozostałe procesy firmy zostały potraktowane znacznie mniej dokładnie. Po wdrożeniu okazało się, że system dobrze odpowiada na część potrzeb związanych z nowymi magazynami, ale nie obsługuje wielu innych ważnych procesów.

Poprawki zajęły dużo czasu. Problemy z systemem zaczęły też opóźniać zmiany w samych magazynach, które nowe rozwiązanie miało wspierać.

Dlatego projektowanie nowego systemu w trakcie dużej transformacji jest ryzykowne. Procesy, które dziś traktujesz jako docelowe, za kilka miesięcy mogą wyglądać inaczej.

W takiej sytuacji można najpierw ustalić i ustabilizować nowe procesy, a dopiero później przepisać system. Można też zacząć od jednego obszaru, w którym sposób działania firmy jest już dobrze znany i raczej nie zmieni się w najbliższym czasie.

Jeśli odkładasz przepisanie systemu, wykorzystaj ten czas

Odroczenie nie musi oznaczać bezczynności. Ten czas można wykorzystać na przygotowanie firmy i obecnego systemu do późniejszej zmiany.

1. Opisz procesy.
   Ustal, jak naprawdę działa firma, razem z wyjątkami i nietypowymi przypadkami. Jeśli różne osoby opisują ten sam proces inaczej, rozstrzygnij te różnice. Każdy ważny proces powinien też mieć osobę, która może podejmować ostateczne decyzje.
2. Przeanalizuj obecny system.
   Sprawdź, jakie funkcje rzeczywiście realizuje, jakie reguły biznesowe są zapisane w kodzie i od jakich innych elementów zależy. To szczególnie ważne w starszych systemach, w których część wiedzy o działaniu firmy nigdy nie została udokumentowana. AI może dziś przyspieszyć taką analizę. Może pomóc przejrzeć kod, zależności i logikę biznesową, a następnie wskazać miejsca, które wymagają dalszej weryfikacji z zespołem.
3. Popraw najbardziej problematyczne miejsca.
   Usuń najpoważniejsze awarie, dodaj monitoring i przygotuj testy dla najważniejszych procesów. Takie testy przydadzą się później podczas budowy nowego systemu, bo pomogą sprawdzić, czy zachowuje się zgodnie z ustalonymi zasadami.
4. Wymieniaj stabilne fragmenty, jeśli ma to sens.
   Nie trzeba czekać, aż cała organizacja będzie gotowa. Jeśli jeden obszar jest już dobrze opisany, stabilny i wiadomo, jak powinien działać, można zacząć jego wymianę niezależnie od pozostałych części systemu.

W takim okresie może pomóc nasza usługa Rescue. Developerzy i product ownerzy z Pragmatic Coders dołączają do zespołu klienta i pracują razem z nim nad uporządkowaniem sposobu działania projektu. Pomagają poprawić procesy, sposób podejmowania decyzji oraz najbardziej problematyczne elementy systemu.

Kiedy firma jest gotowa na pełne przepisanie systemu?

Do decyzji o pełnym przepisaniu warto wrócić, gdy spełnione są cztery warunki:

• procesy są opisane i po stronie biznesu jest osoba, która może je zatwierdzać,
• model biznesowy i najważniejsze procesy są już względnie stabilne,
• utrzymanie starego systemu jest na tyle kosztowne lub trudne, że zaczyna hamować rozwój firmy,
• firma wie, co chce poprawić dzięki nowemu systemowi i potrafi później sprawdzić, czy cel został osiągnięty.

Ostatni punkt jest szczególnie ważny. Samo stwierdzenie, że nowy system ma być „lepszy” albo „nowocześniejszy”, nie daje jeszcze podstawy do oceny inwestycji.

Warto wcześniej określić konkretne efekty. Może chodzić na przykład o krótszy czas wdrażania zmian, mniej awarii, niższy koszt utrzymania, krótszą obsługę procesu albo możliwość uruchomienia nowych produktów i usług.

Zanim zaplanujesz budżet na przepisanie systemu, sprawdź stan projektu z pomocą naszego ebooka o autodiagnozie. Pomoże to ustalić, czy głównym problemem jest technologia, czy sposób, w jaki firma organizuje pracę i wprowadza zmiany.

Jeśli warunki do przepisania są już spełnione, można wrócić do decyzji o przepisaniu systemu legacy. Warto wtedy zacząć od sprawdzenia, czy inwestycja ma uzasadnienie biznesowe i jaki sposób migracji będzie najbezpieczniejszy.

Stary system nie musi od razu znikać. Może nadal obsługiwać firmę w czasie prac, a nowe elementy mogą być wdrażane stopniowo.

Podsumowanie

Drogie utrzymanie starego systemu nie oznacza jeszcze, że firma jest gotowa na jego przepisanie. Najpierw trzeba wiedzieć, jak mają działać procesy, kto podejmuje decyzje i jaki efekt biznesowy ma przynieść nowy system.

Jeśli tych warunków jeszcze nie ma, warto wykorzystać ten czas na uporządkowanie procesów, poznanie obecnego rozwiązania i ograniczenie jego największych problemów. Pełny rewrite można rozpocząć później albo wcześniej wymieniać te obszary, które są już dobrze opisane i stabilne.