System w firmie działa coraz gorzej. Rachunki rosną, terminy się przesuwają, a zespół nie umie powiedzieć, co jest zepsute. Padają trzy rady: naprawić to, co jest, zmienić firmę informatyczną albo napisać system od nowa. Każda pasuje do innej przyczyny. Zacznij od pytania: czego firma nie może dziś zrobić przez ten system? Potem sprawdź, która z trzech opcji do tej odpowiedzi pasuje.
Artykuł sponsorowany
Opcja 1. Stabilizacja
Co to jest
Stabilizacja oznacza, że zostajesz przy obecnym systemie i porządkujesz to, co naprawdę blokuje firmę. Usuwasz najgorsze awarie. Spisujesz, jak ludzie pracują. Wyznaczasz osobę, która rozstrzyga spory. Wymieniasz tylko te części programu, które są już opisane i stabilne.
Nowy system na tym etapie powtórzyłby ten sam bałagan. Jeśli dwa działy opisują jedną pracę inaczej, programiści i tak muszą wybrać jedną wersję. Lepiej, żeby ten wybór zapadł w firmie, zanim powstanie nowy kod.
Kiedy należy iść w tę opcję
Idź w stabilizację, gdy spełnia się choć jedna z tych rzeczy.
- Nikt nie spisał, jak firma naprawdę pracuje, razem z wyjątkami. Dwa działy opisują ten sam proces inaczej i nie ma osoby, która powie, która wersja obowiązuje.
- Ludzie od codziennej pracy nie mają czasu usiąść do projektu.
- Firma w tym samym czasie zmienia sposób zarabiania albo najważniejsze procesy, więc wymagania do systemu zmieniają się w trakcie budowy.
Stabilizacja jest też właściwa, gdy program da się jeszcze spokojnie zmieniać. Poprawka w jednym miejscu nie sypie błędami w całej firmie. Ktoś umie wytłumaczyć zasady. Najważniejsze czynności są sprawdzane. Koszt utrzymania da się zaakceptować wobec tego, ile system firmie daje. Wtedy pieniądze idą w konkretny problem, a działający system zostaje.
W tym czasie robisz cztery rzeczy. Spisujesz procesy i wyznaczasz właściciela każdego ważnego procesu. Odczytujesz z obecnego programu zasady, które nigdy nie trafiły do dokumentu. Usuwasz najpoważniejsze awarie i ustawiasz powiadomienia, żebyś wiedział o błędzie, zanim zadzwoni klient. Przygotowujesz testy najważniejszych ścieżek. Jeśli jeden obszar jest już opisany i stabilny, możesz wymienić tylko ten kawałek. Reszta może poczekać.
Kiedy to nie jest opcja
Stabilizacja nie załatwi sprawy, gdy nie masz kodu, haseł ani ludzi, którzy wiedzą, jak system jest zbudowany. Wtedy najpierw trzeba odzyskać kontrolę.
Stabilizacja nie jest też drogą, gdy problem dotyczy całego systemu, firma już wie, jak ma działać, a samo utrzymanie hamuje rozwój i da się zmierzyć, co nowy system ma poprawić. Dalsze łatanie tylko przedłuża koszt. Wtedy najlepiej przepisać system.
Sam wiek programu nie jest powodem, żeby zostać przy stabilizacji ani żeby z niej wyjść. Liczy się to, czy kolejne zmiany da się wprowadzać w znanym czasie i za znaną cenę.
Opcja 2. Przejęcie
Co to jest
Przejęcie oznacza, że odbierasz projekt poprzedniej firmie informatycznej i przekazujesz go do nowej partnera technologiczne, który najpierw odzyskuje kontrolę nad systemem. Kontrola to kod, hasła, sposób wypuszczania poprawek, wiedza o tym, co się sypie, i uczciwy plan na kolejne miesiące.
Nowy zespół nie zaczyna od listy zaległych funkcji. Zaczyna od odpowiedzi, co naprawdę jest w systemie i co może zatrzymać firmę jutro rano.
Kiedy należy iść w tę opcję
Idź w przejęcie, gdy systemem rządzi ktoś spoza firmy. Nie masz kodu. Nie masz dostępu do serwerów. Nie masz osób, które wiedzą, jak program jest zbudowany. Opis jest niepełny albo opisuje stan sprzed miesięcy, a nie to, co działa dziś. Poprzedni dostawca zostawił prezentacje. Każda nowa funkcja na chwiejnym systemie dokłada bałaganu.
Firma musi mieć prawa do kodu i móc przekazać dostępy, dane oraz połączenia z innymi programami. Bez tego przejęcie się nie zaczyna.
W pierwszych tygodniach sprawdzasz siedem rzeczy: czy codzienna praca na systemie jest stabilna, kto ma hasła, jak wychodzą poprawki, czy wiesz o awarii zanim zadzwoni klient, które czynności muszą działać bez przerwy, jaka praca czeka w kolejce i w jakim stanie jest sam program. Z tego powstaje mapa: co z czym jest połączone i co się sypie, gdy ruszysz jedną część.
Potem praca idzie w 3 trybach:
- Utrzymanie obsługuje awarie, bezpieczeństwo danych i obsługę użytkowników.
- Rozwój odpowiada za funkcje, które dają firmie nowe możliwości.
- Porządki w starym kodzie robisz tylko tam, gdzie bałagan ma cenę: ryzyko awarii, wysoki koszt albo blokada kolejnej zmiany.
Szef dostaje plan na piśmie: co działa, co jest ryzykowne, co musi poczekać i ile kosztuje każda decyzja.
Kiedy to nie jest opcja
Przejęcie nie jest odpowiedzią, gdy kod, dostępy i ludzie są już w firmie, a boli brak ustaleń, jak praca ma wyglądać. Zmiana dostawcy tego nie zmieni. To jest stabilizacja.
Przejęcie nie zastępuje też decyzji o przepisaniu, gdy cały system blokuje rozwój, procesy są już opisane i rachunek utrzymania przegrywa z budową nowego. Może być krokiem wcześniejszym, jeśli kod siedzi u obecnego dostawcy. Samo przejęcie nie jest wtedy celem. Celem jest odzyskać kontrolę, a potem zdecydować, czy system naprawiać, czy pisać od nowa.
Nowy zespół nie obiecuje, że w dwa tygodnie nadrobi zaległy rok. Uczciwa obietnica brzmi inaczej: najpierw kontrola, potem tempo.
Opcja 3. Przepisanie
Co to jest
Przepisanie oznacza budowę nowego systemu w miejsce starego. Zachowujesz funkcje, na których opiera się firma. Upraszczasz to, co sprawia, że każda zmiana jest droga i ryzykowna. Stary system może w tym czasie dalej obsługiwać ludzi. Nowe części wchodzą po kolei. Dane przenosisz według planu ułożonego na starcie, nie w ostatni weekend przed przełączeniem.
Kiedy należy iść w tę opcję
Idź w przepisanie, gdy problem dotyczy całości, a nie jednego modułu. Wiesz już, co system ma robić dla firmy, nawet jeśli obecny program robi to źle. Dalsze utrzymanie kosztuje więcej niż budowa nowego.
Do tej decyzji wracasz, gdy naraz spełnione są cztery warunki:
- procesy są opisane, a ktoś w firmie może je zatwierdzić,
- sposób zarabiania i najważniejsze procesy są już w miarę stałe,
- utrzymanie jest tak drogie albo tak trudne, że hamuje rozwój,
- wiesz, co ma się poprawić, i potrafisz później sprawdzić, czy cel został osiągnięty.
Cel ma być konkretny. Krótszy czas wprowadzenia zmiany. Mniej awarii. Niższy koszt utrzymania. Krótsza obsługa procesu. Albo usługa, której dziś nie da się sprzedać, bo system jej nie uniesie.
Porównaj cztery warianty:
- dalsze utrzymywanie obecnego systemu,
- naprawę i modernizację,
- wymianę wybranych elementów,
- przepisanie całego systemu od nowa.
Dla każdego wariantu policz pełny koszt, uwzględniając pracę ludzi, infrastrukturę i serwery, awarie, ręczne obejścia i arkusze, migrację danych oraz utracone przychody wynikające z ograniczeń obecnego systemu.
Przed zatwierdzeniem pozostałej części budżetu wybierz jeden reprezentatywny fragment systemu i przeprowadź na nim pilotaż. Powinien to być element o podobnej złożoności, zależnościach i problemach jak reszta systemu. Na jego podstawie zmierz rzeczywisty czas realizacji, koszt oraz ryzyka.
Nie wybieraj do pilotażu prostego, odizolowanego modułu, ponieważ jego wyniki nie będą miarodajne dla całego systemu.
Kiedy to nie jest opcja
Nie przepisuj systemu od nowa, gdy firma nie ma jeszcze ustalonych procesów, właśnie zmienia model działania albo nadal szuka właściwej oferty. W takich warunkach wymagania szybko się zmieniają, więc nowy system od początku goni ruchomy cel.
Nie warto też robić tego tylko dla nowszej technologii lub AI. Jeśli obecny system można rozwijać za rozsądny koszt, lepiej naprawić najważniejsze problemy. AI może przyspieszyć pisanie kodu, ale nie zastąpi jasnych wymagań, testów i odpowiedzialności za jakość.
Podsumowanie
Wybór zależy od źródła problemu. Stabilizuj, gdy firma nie ma ustalonych procesów albo system nadal da się rozsądnie rozwijać. Odzyskaj kontrolę nad systemem, gdy kod, dostępy i wiedza są poza firmą. Przepisuj dopiero wtedy, gdy spełnione są kluczowe warunki i dalsze utrzymanie kosztuje więcej niż nowy system.
Najdroższe błędy to przepisywanie bez uzgodnionych procesów oraz dalszy rozwój systemu, nad którym firma nie ma kontroli.
Jeśli od miesięcy gasicie kolejne problemy bez poznania ich przyczyny, ratowanie projektu powinno zacząć się od faktów. Efektem jest jeden plan: co zostawić, co usunąć, co przebudować, ile to kosztuje i kto za to odpowiada.