Piotr FilipowiczSystem działa. Klienci składają zamówienia, faktury się wystawiają, nikt nie dzwoni w nocy.
Jednocześnie mały feature trafia na produkcję po trzech tygodniach, kilka osób z operacji codziennie poprawia dane w Excelu, a na pytanie, kiedy ostatnio sprawdzaliśmy przywrócenie systemu z backupu, w pokoju zapada cisza. Trudno powiedzieć.
Ile kosztuje nas utrzymywanie takiego systemu?
W budżecie IT znajdziemy serwery, licencje, dostawców i wynagrodzenia. Pozostała część rachunku jest rozłożona po całej firmie: w pracy operacji, w obsłudze klienta, w opóźnionych projektach i w czasie kilku osób, które wiedzą, co zrobić, żeby wszystko nadal działało. Tej części nikt nie widzi w jednym raporcie, więc w rozmowie o modernizacji zwykle przegrywa z liczbami, które da się łatwo pokazać.
Z mojej perspektywy rozmowę o legacy warto zacząć od zebrania tych kosztów w jednym miejscu. Dopiero wtedy da się sensownie zdecydować, co zostawić, co usprawnić i gdzie potrzebujemy większej zmiany.
Co właściwie oceniamy?
Sam wiek systemu mówi niewiele o jego opłacalności. Starsza aplikacja może dobrze wspierać stabilny proces biznesowy, mieć przewidywalne koszty, dostępne kompetencje i sprawdzone procedury odtwarzania. Młodszy system, napisany kilka lat temu w pośpiechu, może już wymagać kosztownych obejść i blokować rozwój produktu.
Podobnie patrzy na to brytyjska administracja. W definicji legacy IT zaktualizowanej w sierpniu 2026 roku za legacy uznaje się system, którego dalsze używanie tworzy trwałe, nieakceptowalne obciążenie lub ryzyko, a przy tym nie da się go już skutecznie i ekonomicznie utrzymać ani zabezpieczyć. Autorzy wprost zaznaczają, że definicja opiera się na obciążeniu i ryzyku, a wiek, rodzaj technologii czy model hostingu mają drugorzędne znaczenie (GOV.UK, 2026). Dla mnie to dobry punkt wyjścia, bo łączy perspektywę techniczną z biznesową i od razu przesuwa rozmowę z pytania „czy ten system jest stary?” na pytanie „ile nas kosztuje i co ryzykujemy?”.
Proponuję przejść przez osiem obszarów i w każdym odpowiedzieć na cztery pytania:
- Co wiemy o obecnej sytuacji?
- Jak to mierzymy?
- Jaki koszt lub ryzyko z tego wynika?
- Co powinniśmy zrobić dalej?
Efektem ma być mapa, z którą CTO i zarząd mogą usiąść do jednej rozmowy, patrząc na te same liczby i te same założenia.
01
Infrastruktura i dostawcy
Zacznijmy od kosztów, które najłatwiej znaleźć: hosting, sprzęt, bazy danych, licencje, wsparcie producenta i zewnętrzna firma, która utrzymuje fragment rozwiązania. Warto zebrać ich roczną sumę i sprawdzić, jak zmienia się względem skali biznesu.
Co mierzyć:
- całkowity roczny koszt infrastruktury, licencji i wsparcia;
- koszt na jednostkę użycia, np. zamówienie, transakcję lub aktywnego klienta;
- dodatkowe opłaty wynikające z pozostawania na starszej wersji, np. za rozszerzone wsparcie.
Jeżeli koszty rosną razem z liczbą obsługiwanych klientów, może to być w pełni uzasadnione. Jeżeli biznes stoi w miejscu, a rachunek rośnie, potrzebujemy wyjaśnienia.
Kierunek działania: ustalić źródło wzrostu. Sprawdzić wykorzystanie zasobów, warunki umów i koszt aktualizacji, a migrację porównać z tymi opcjami, uwzględniając koszt jej przeprowadzenia.
02
Ludzie i wiedza
Ile osób potrafi bezpiecznie zmienić krytyczny fragment systemu? Co się wydarzy, kiedy osoba, która zna mechanizm rozliczeń, będzie przez miesiąc niedostępna?
Koszt wiedzy zamkniętej w kilku głowach ujawnia się podczas wdrażania nowych osób, analizy zmian i rozwiązywania incydentów. Bardzo często pochłania czas najbardziej doświadczonych ludzi, czyli dokładnie tych, których chcielibyśmy mieć przy nowych inicjatywach.
Co mierzyć:
- czas do pierwszej samodzielnej, bezpiecznej zmiany nowej osoby;
- godziny ekspertów przeznaczane na pomoc i odtwarzanie kontekstu;
- liczbę osób zdolnych obsłużyć każdy krytyczny element.
Miesiąc wdrożenia nowej osoby angażuje zwykle również kilka innych osób, które odpowiadają na pytania, robią code review i tłumaczą, dlaczego coś działa tak, a nie inaczej. Ich czas też należy do rachunku.
Kierunek działania: zacząć od wiedzy o największym znaczeniu dla ciągłości działania. Rozłożyć ją w zespole, przećwiczyć zastępstwo i zapisać procedury. Przydatność dokumentacji najlepiej sprawdzić w praktyce, prosząc inną osobę o wykonanie zadania wyłącznie na jej podstawie.
03
Wprowadzanie zmian
Ile zajmuje dowiezienie małego feature'a na produkcję? To dobre pytanie otwierające, natomiast żeby coś z niego wynikało, trzeba rozłożyć odpowiedź na części.
Załóżmy, że dodajemy pole do istniejącego formularza wraz z walidacją i zapisem. Ile czasu zajmuje analiza? Implementacja? Testy? Ile zadanie czeka na uzgodnienia i na okno wdrożeniowe?
Co mierzyć:
- czas od przyjęcia gotowego zadania do realizacji do dostępności funkcji dla użytkownika;
- sumę roboczogodzin wszystkich zaangażowanych osób;
- nakład na poprawki po wdrożeniu.
DORA w swoim zestawie metryk mierzy między innymi czas od commita do wdrożenia produkcyjnego (DORA). Proponowana tu analiza obejmuje również wcześniejsze etapy, bo w systemach legacy sporo czasu potrafi zniknąć jeszcze przed pierwszą linijką kodu, na analizie wpływu zmiany i uzgodnieniach.
Warto przyjrzeć się kilku porównywalnym zadaniom i zapisać zarówno typowy wynik, jak i przypadki, które trwały szczególnie długo.
Przykład na umownych liczbach: zmiana pochłania 32 roboczogodziny. Przy pełnym koszcie godziny pracy 250 zł kosztuje 8 000 zł. Jeśli uda się ograniczyć nakład do 16 godzin, odzyskujemy czas wart 4 000 zł na każdą zmianę, a przy 20 takich zmianach miesięcznie potencjał wynosi 80 000 zł.
Trzeba to dobrze nazwać. To wartość odzyskanej zdolności zespołu, a faktyczna oszczędność gotówkowa zależy od tego, czy zmniejszymy wydatki, czy wykorzystamy ten czas na kolejne zadania. Obie decyzje są sensowne, tylko inaczej wyglądają w budżecie.
Kierunek działania: znaleźć etap, który generuje największy nakład lub opóźnienie. Przyczyną mogą być zależności w kodzie, ręczne testy, kolejki albo sposób podejmowania decyzji, więc zanim wybierzemy rozwiązanie, warto ustalić, który z tych mechanizmów dominuje.
04
Awarie i odtwarzanie działania
Wyobraźmy sobie utratę całego środowiska produkcyjnego. Po jakim czasie klient ponownie złoży zamówienie? Jakie dane odzyskamy? Kto potwierdzi, że rozliczenia są poprawne?
Samo uruchomienie serwerów pozostawia jeszcze sporo pracy: odtworzenie danych, podłączenie integracji, sprawdzenie spójności i potwierdzenie, że kluczowy proces biznesowy znowu działa.
Co mierzyć:
- rzeczywisty czas odtworzenia kluczowego procesu podczas testu;
- osiągnięty punkt odtworzenia danych;
- liczbę roboczogodzin potrzebnych do przywrócenia działania.
Wyniki porównujemy z wymaganiami biznesowymi: dopuszczalnym czasem odtworzenia (RTO) oraz dopuszczalnym okresem utraty danych (RPO). Test powinien uwzględniać zależności i działanie odtworzonej usługi, a nie tylko samą infrastrukturę (CMS, ISCP Exercise Handbook).
Biznes potrzebuje powrotu w cztery godziny, a test trwa dziewiętnaście. W tym momencie mamy konkretną lukę i podstawę do ustalenia działań, zamiast ogólnego poczucia, że „backupy chyba są”.
Koszt scenariusza obejmuje pracę przy odtwarzaniu, dodatkowe zasoby, skutki przestoju i odrabianie zaległości. Część sprzedaży może przesunąć się w czasie, część przepaść, więc te założenia trzeba zapisać obok kwoty.
Kierunek działania: przeprowadzić kontrolowany test dla jasno określonego scenariusza, zmierzyć poszczególne etapy i usprawnić największe ograniczenia. Jeżeli testu nie było, w macierzy wpisujemy „niezweryfikowany”. To też jest informacja, i to dość ważna.
05
Bezpieczeństwo i zgodność
Utrzymywanie ochrony systemu też kosztuje. Aktualizacje mogą wymagać długich testów regresji, audyt może angażować kilka zespołów, a wyjątek bezpieczeństwa może wymuszać dodatkowe zabezpieczenia i regularną kontrolę.
Co mierzyć:
- nakład pracy na aktualizacje, audyty i obsługę wyjątków;
- czas usuwania istotnych podatności, z uwzględnieniem ich ryzyka;
- krytyczne komponenty bez dostępnego wsparcia i bez planu dalszego działania.
Tu potrzebujemy dwóch osobnych zapisów: kosztu utrzymywania zabezpieczeń oraz pozostałego ryzyka. Liczba otwartych podatności sama w sobie nie daje kwoty potencjalnej straty, więc lepiej nie udawać, że da się ją na taką kwotę przeliczyć jednym mnożeniem.
Kierunek działania: ustalić, które zaległości i wyjątki tworzą największą ekspozycję, i zaplanować ich usunięcie albo ograniczenie skutków, wraz z właścicielem i terminem.
06
Integracje i dane
Dane klienta są w trzech miejscach i każde pokazuje trochę inną wersję. Integracja działa, dopóki plik przychodzi w odpowiednim formacie, a kiedy się zatrzyma, ktoś poprawia dane ręcznie i uruchamia proces jeszcze raz. Takie sytuacje mają mierzalny koszt, tylko rzadko ktoś go sumuje.
Co mierzyć:
- liczbę błędów integracji i rozbieżności danych;
- czas poświęcany na diagnozę, korekty i ponowne przetwarzanie;
- koszt utrzymania oraz zmiany poszczególnych połączeń.
Warto też sprawdzić konsekwencje poza IT: błędne faktury, opóźnione zamówienia czy dodatkowe kontakty z klientami, którzy dzwonią zapytać, dlaczego widzą inne dane niż w mailu.
Kierunek działania: wskazać źródła prawdy dla danych i odpowiedzialność za ich jakość, a następnie wybrać połączenia, które generują najwięcej kosztownych problemów.
07
Praca ręczna poza IT
Ten obszar łatwo przeoczyć podczas technicznego przeglądu, bo nie widać go ani w repozytorium, ani w monitoringu. Ktoś eksportuje dane, ktoś łączy arkusze, ktoś przepisuje wynik do kolejnego systemu. Każda czynność zajmuje kilka minut, natomiast powtarzana setki razy w miesiącu staje się stałym obciążeniem firmy.
Co mierzyć:
- czas wykonania czynności;
- liczbę powtórzeń w miesiącu;
- czas poprawek i obsługi wyjątków.
Przykładowo: osiem minut, 600 powtórzeń miesięcznie. To 80 godzin pracy, czyli przy koszcie godziny 100 zł około 8 000 zł miesięcznie, jeszcze przed doliczeniem poprawek.
Kierunek działania: najpierw sprawdzić, czy czynność nadal jest potrzebna. Zdarza się, że raport albo eksport nadal powstaje tylko dlatego, że kiedyś ktoś go potrzebował. Dopiero potem warto uprościć proces i ocenić sens automatyzacji.
08
Możliwości biznesowe
Które konkretne plany firmy są opóźnione przez ograniczenia systemu? Wejście na nowy rynek? Nowy model rozliczeń? Integracja z dużym klientem?
Tutaj łatwo zbudować atrakcyjną prezentację na słabych założeniach. Dlatego potrzebujemy konkretnej inicjatywy i jasno opisanego ograniczenia, które ją blokuje.
Co mierzyć:
- opóźnienie, które można przypisać temu ograniczeniu;
- koszt dodatkowej pracy;
- zakres potencjalnie utraconej lub przesuniętej korzyści.
Szacunek powinien mieć wariant ostrożny, bazowy i optymistyczny, a właściciel biznesowy inicjatywy powinien uczestniczyć w jego przygotowaniu. Jeśli IT samo wyliczy utracone przychody, zarząd ma pełne prawo w te liczby nie uwierzyć.
Kierunek działania: sprawdzić, jaka najmniejsza zmiana pozwoli odblokować plan biznesowy. Czasem wystarczy przebudowa jednej funkcji albo jednej integracji, bez ruszania całego systemu.
Złóżmy to w jedną macierz
Po przejściu ośmiu obszarów uzupełniamy prostą tabelę:
| Obszar | Wynik pomiaru i dowód | Poziom wymagany przez firmę | Koszt lub ryzyko | Następne działanie |
|---|---|---|---|---|
| Infrastruktura i dostawcy | … | … | … | … |
| Ludzie i wiedza | … | … | … | … |
| Wprowadzanie zmian | … | … | … | … |
| Awarie i odtwarzanie | … | … | … | … |
| Bezpieczeństwo i zgodność | … | … | … | … |
| Integracje i dane | … | … | … | … |
| Praca ręczna poza IT | … | … | … | … |
| Możliwości biznesowe | … | … | … | … |
Każdy obszar oznaczamy jako:
- Akceptowalny
- Wymagający poprawy
- Krytyczny
- Niezweryfikowany
Przy dowodzie zapisujemy datę i źródło, bo pomiar, wynik testu i opinia eksperta mają różny poziom pewności i warto, żeby było to widać w tabeli.
Progi ustalamy względem potrzeb firmy. Sklep obsługujący zamówienia przez całą dobę ma inne wymagania niż narzędzie używane raz w miesiącu do zamknięcia okresu.
Jak z tego wybrać działania?
Wybrałbym trzy priorytety.
Zagrożenia wymagające zabezpieczenia teraz
Utrata danych, brak możliwości odtworzenia, krytyczna zależność od jednej osoby.
Powtarzalne koszty, które można ograniczyć wykonalną zmianą
Ręczne uzgadnianie danych, czasochłonne testy, powracające incydenty.
Ograniczenie o największym znaczeniu dla planów firmy
Konkretna przeszkoda blokująca produkt, klienta lub skalę działania.
Dla każdego zapisujemy właściciela, pierwszy krok i miernik, po którym poznamy poprawę. Krytycznej luki nie uśredniamy z dobrymi wynikami pozostałych obszarów.
Sprawny proces zmian nie zrównoważy braku działającego backupu.
W rachunku pilnujemy też podwójnego liczenia. Godziny pracownika uwzględnione w koszcie zespołu pokazują, na co ten budżet jest wykorzystywany, a dodanie ich drugi raz jako osobnego kosztu zawyży wynik. Osobno pokazujemy poniesione koszty, scenariusze przyszłych strat i utracone możliwości, bo każda z tych kategorii ma inną pewność i inaczej będzie oceniana przez zarząd.
Jeżeli rozważamy modernizację, do porównania dokładamy migrację danych, równoległe utrzymanie obu rozwiązań przez okres przejściowy, szkolenia i wyłączenie starego systemu. Te pozycje łatwo pominąć w pierwszej wycenie, a potrafią zmienić wynik całego porównania.
Zacząłbym od sprawdzenia trzech rzeczy: rzeczywistego kosztu kilku małych zmian, wyniku odtwarzania kluczowej usługi oraz czasu pracy ręcznej wymuszanej przez system. Te dane pozwolą wypełnić pierwszą wersję macierzy i wybrać działania, których efekt będziemy potrafili sprawdzić.