Uzasadnienie biznesowe modernizacji: jak zdobyć budżet zarządu i policzyć zwrot

Wnioski o budżet na modernizację najczęściej upadają nie dlatego, że są błędne, lecz dlatego, że są napisane w niewłaściwym języku. Dyrektor techniczny wchodzi na posiedzenie zarządu z listą problemów architektonicznych, wskaźnikiem pokrycia testami i mapą zależności. Po drugiej stronie stołu siedzą ludzie, którzy tego samego dnia rozpatrują dwa inne wnioski: o wejście na nowy rynek i o rozbudowę zespołu handlowego. Obydwa mają policzony zwrot. Modernizacja go nie ma, więc przegrywa, nawet jeśli jest najbardziej opłacalna z całej trójki.

Nie chodzi o to, że zarząd nie rozumie technologii. Chodzi o to, że dwóch inwestycji po prostu nie da się porównać, gdy tylko jedna z nich mówi o pieniądzach. Ten artykuł pokazuje, jak zbudować uzasadnienie biznesowe modernizacji, które tę lukę zamyka: jak policzyć koszt bieżący, koszt utraconych możliwości i koszt odroczenia, jak przedstawić scenariusze, które metryki trafiają do zarządu i jak uniknąć błędów najczęściej kosztujących akceptację wniosku.

Dlaczego wniosek techniczny przegrywa z wnioskiem handlowym

Zarząd ocenia inwestycje według jednego kryterium: co firma z tego będzie miała i kiedy. Wniosek o rozbudowę zespołu handlowego mówi wprost, ile dodatkowych transakcji ma przynieść i w jakim czasie. Wniosek o modernizację zwykle mówi, że architektura jest ciasno powiązana, dług technologiczny rośnie, a system stanowi ryzyko. To wszystko może być prawdą, a i tak nie wystarcza do decyzji, bo nie pada w nim ani kwota, ani horyzont czasowy.

Druga przyczyna porażki to sposób ramowania. Modernizacja opisana jako sprzątanie po latach kompromisów brzmi jak koszt naprawiania własnych błędów. Ta sama modernizacja opisana jako usunięcie bariery, która blokuje wzrost, brzmi jak inwestycja. Ta różnica nie jest kosmetyczna. W pierwszej wersji wniosek konkuruje z innymi kosztami, w drugiej z innymi inwestycjami, a to zupełnie inna półka w rozmowie budżetowej.

Trzecia przyczyna to brak alternatywy. Wniosek z jednym rozwiązaniem i jedną kwotą stawia zarząd przed wyborem zero-jedynkowym. Wniosek z trzema scenariuszami i konsekwencjami każdego z nich, łącznie ze scenariuszem zaniechania, daje zarządowi to, czego oczekuje: możliwość podjęcia decyzji zamiast jej zatwierdzenia.

Pierwszy filar: koszt bieżący

Koszt bieżący najłatwiej policzyć i najczęściej się go zaniża. Składa się z kilku pozycji, które warto rozdzielić, bo każda przemawia do innego członka zarządu.

Podstawą jest koszt dostarczania. Jeśli funkcja, która kiedyś zajmowała dwa tygodnie, dziś zajmuje sześć, można to przełożyć wprost na koszt pracy zespołu na jednostkę dostarczonej wartości. W jednym z systemów modernizowanych przez Altimi, platformie do zarządzania jakością opartej na technologiach z 2016 roku, koszt dostarczenia funkcji wzrósł pięciokrotnie. Przy kilkunastoosobowym zespole taka różnica zamienia się w kwotę, którą każdy dyrektor finansowy rozpozna bez tłumaczenia.

Druga pozycja to koszt utrzymania i infrastruktury, najlepiej pokazany jako udział w przychodzie i śledzony w czasie. Rosnący udział przy stabilnej marży produktowej jest twardym dowodem, że model nie skaluje się zgodnie z planem.

Trzecia to koszt incydentów i przestojów, liczony nie tylko jako czas pracy zespołu, ale też jako wpływ na klientów i zobowiązania z umów o poziomie usług. Czwarta, często pomijana, to koszt rekrutacji i wdrożenia. Gdy nowy programista potrzebuje kwartału, żeby pracować samodzielnie, każdy etat zwraca się znacznie później, niż zakłada plan zatrudnienia.

Drugi filar: koszt utraconych możliwości

To najtrudniejsza do policzenia i zwykle największa część rachunku. Koszt bieżący widać w raportach. Koszt opcji nie pojawia się nigdzie, bo dotyczy rzeczy, które się nie wydarzyły.

Warto skwantyfikować trzy pozycje. Pierwsza to przegrane transakcje. Kiedy dział handlowy odpada na etapie ankiety bezpieczeństwa albo z powodu braku certyfikacji oczekiwanych przez klientów korporacyjnych, wartość tych transakcji jest bezpośrednim kosztem stanu technicznego. Wystarczy zestawić utracone szanse z przyczyną odrzucenia, żeby otrzymać liczbę, której nikt nie podważy.

Druga to opóźnione wejście na rynek. Jeśli plan zakładał start nowej linii produktowej w danym kwartale, a stan systemu przesunął go o dwa, kosztem jest przychód nieosiągnięty w tym oknie oraz przewaga oddana konkurencji.

Trzecia to funkcje, których nigdy nie zgłoszono. Tej pozycji trzeba szukać świadomie, bo z definicji nie ma jej w backlogu. W praktyce wystarczy zapytać liderów produktu, czego przestali proponować, wiedząc, że system tego nie udźwignie. Odpowiedzi bywają zaskakujące i to często one najlepiej pokazują zarządowi, że problem nie jest techniczny, tylko strategiczny.

Trzeci filar: koszt odroczenia

To pytanie pada najrzadziej, a zwykle najbardziej przekonuje zarząd wahający się między działaniem teraz a odłożeniem decyzji o rok.

Odroczona modernizacja nie kosztuje za rok tyle samo co dziś, z kilku powodów. Przez ten czas przybywa kodu opartego na starych założeniach, więc zakres prac rośnie. Okno przed końcem wsparcia komponentów się zamyka, co przy dużej bazie klientów potrafi przesądzić o tym, czy migracja w rozsądnym terminie jest w ogóle wykonalna. We wspomnianej platformie do zarządzania jakością jednym z czynników wymuszających decyzję było zaplanowane na 2027 rok wygaszenie wspieranej wersji bazy danych, które przy migracji całej bazy klientów wymagało rozpoczęcia prac z dużym wyprzedzeniem.

Rośnie też ryzyko. Każdy kolejny kwartał na niewspieranych komponentach to wyższe prawdopodobieństwo incydentu bezpieczeństwa i coraz trudniejsze rozmowy z klientami korporacyjnymi. Pokazanie tego jako krzywej, a nie jednorazowej kwoty, zmienia charakter dyskusji. Zarząd przestaje wybierać między wydaniem pieniędzy teraz a niewydawaniem ich wcale, a zaczyna wybierać między mniejszą kwotą teraz a większą później.

Jak przedstawić scenariusze

Dobry wniosek zawiera co najmniej trzy warianty, każdy z kwotą, harmonogramem i konsekwencjami.

Wariant zaniechania jest punktem odniesienia. Pokazuje, jak za dwa lata będą wyglądać koszty bieżące, ryzyko i tempo dostarczania, jeśli nic się nie zmieni. Bez niego zarząd nie ma do czego porównać pozostałych wariantów.

Wariant modernizacji przyrostowej jest zwykle rekomendacją. Zaczynamy od modułów o najwyższym ryzyku i największym wpływie na plan, dostarczamy etapami, a zespół przez cały czas wypuszcza nowe funkcje. Najważniejsze jest pokazanie, że pierwsze efekty pojawiają się w ciągu kilku miesięcy, a nie dopiero po zakończeniu całego programu.

Wariant pełnego przepisania warto pokazać nawet wtedy, gdy go nie rekomendujemy, właśnie po to, by uwidocznić jego koszt i ryzyko. Przepisanie zakłada, że zespół rozumie istniejący system na tyle dobrze, żeby go odtworzyć, że wymagania nie zmienią się przez wiele kwartałów i że w odrzucanym kodzie nie kryje się nic ważnego. Zestawienie tych założeń obok wariantu przyrostowego zwykle samo rozstrzyga dyskusję.

Przy każdym wariancie warto podać nie tylko koszt, ale też moment pojawienia się pierwszych korzyści oraz to, co dzieje się z dostarczaniem produktu w trakcie prac. Dla zarządu ta druga informacja bywa ważniejsza od pierwszej.

Metryki, które przemawiają do zarządu

Nie każda metryka inżynierska nadaje się na prezentację zarządczą. Sprawdzają się te, które łączą stan techniczny z wynikiem finansowym albo z planem.

Pierwsza grupa dotyczy tempa: czas od decyzji o funkcji do wdrożenia na produkcję oraz liczba wydań w miesiącu. To najprostszy sposób, by pokazać, czy inwestycja w fundamenty przekłada się na zdolność dostarczania.

Druga to koszt jednostkowy: koszt inżynierski na dostarczoną funkcję i koszt infrastruktury na klienta. Trzecia to ryzyko w kategoriach biznesowych: liczba otwartych krytycznych podatności, komponenty bez wsparcia producenta oraz stan spełnienia wymagań, które warunkują sprzedaż do segmentu korporacyjnego.

Czwarta, najważniejsza, to wpływ na plan: ile zaplanowanych inicjatyw produktowych blokuje stan systemu i jak ta liczba zmienia się w czasie. Ta metryka najlepiej tłumaczy zarządowi, dlaczego modernizacja konkuruje o budżet z inicjatywami wzrostowymi, a nie z kosztami administracyjnymi.

Warto z góry ustalić, jak te wskaźniki będą raportowane po starcie programu. Wniosek, który zawiera zobowiązanie do konkretnego sposobu mierzenia efektów, przechodzi znacznie łatwiej niż taki, który kończy się obietnicą poprawy.

Cztery błędy, które najczęściej kosztują akceptację

Pierwszy to jedna wielka kwota bez etapów. Duży budżet na wieloletni program budzi naturalną ostrożność. Ten sam program podzielony na etapy, z których pierwszy jest niewielki i kończy się konkretnym rezultatem, przechodzi znacznie łatwiej.

Drugi to obiecywanie korzyści, których nie da się zmierzyć. Hasła w rodzaju lepszej jakości kodu czy większej elastyczności architektury nie poddają się rozliczeniu, więc podważają wiarygodność całego wniosku. Lepiej obiecać mniej, ale w kategoriach, które da się zweryfikować.

Trzeci to pominięcie wariantu zaniechania. Bez punktu odniesienia zarząd porównuje koszt modernizacji z zerem, co zawsze wypada niekorzystnie. Z wariantem zaniechania porównuje dwie kwoty, z których jedna rośnie w czasie.

Czwarty to oparcie wniosku na szacunkach bez pokrycia. Kiedy koszt i harmonogram wynikają z przeczucia zespołu, pierwsze pytanie o podstawę tych liczb kończy dyskusję. Dlatego uzasadnienie biznesowe powinno wynikać z ustrukturyzowanej oceny na rzeczywistym kodzie, a nie z warsztatu przy tablicy.

Skąd wziąć liczby

To najczęstsza przeszkoda. Zespół wie, że system jest problemem, ale nie ma danych, żeby udowodnić to w języku finansowym. Ocena techniczna prowadzona pod kątem decyzji inwestycyjnej rozwiązuje ten problem, bo dostarcza jednocześnie diagnozę i jej wycenę.

AI Refactoring Assessment prowadzony przez Altimi trwa cztery tygodnie i jest pomyślany tak, aby jego wynik dało się położyć na stole zarządu. Składa się z dwóch powiązanych strumieni. Pierwszy to ocena architektury i długu technologicznego: wskazanie, które części systemu blokują wzrost i skalowalność, ze skwantyfikowanym długiem, oceną gotowości do zastosowania sztucznej inteligencji i przeglądem ryzyk infrastrukturalnych. Drugi to technical spike, czyli praktyczna walidacja najbardziej ryzykownego fragmentu na rzeczywistym kodzie produkcyjnym, która daje twarde dane o ryzyku migracji i realnym wpływie narzędzi AI, zanim zwiąże się budżet.

Wynikiem jest pakiet decyzyjny przygotowany pod poziom zarządu i inwestorów: streszczenie wykonawcze, mapa ryzyka, roadmapa modernizacji z wykorzystaniem AI, priorytetyzowany backlog długu technologicznego, wnioski ze spike'u oraz uzasadnienie biznesowe z metrykami finansowymi. Całość zostaje przekazana na warsztacie podsumowującym, co ma praktyczne znaczenie: zarząd może dopytać osoby, które prowadziły analizę, zamiast czytać dokument bez kontekstu.

Dla rachunku zwrotu szczególnie istotna jest wycena wpływu AI. Analiza pokazuje, które zadania modernizacyjne narzędzia AI mogą przyspieszyć o 50 do 80 procent, a które nadal wymagają osądu doświadczonych inżynierów. To rozróżnienie zmienia kosztorys programu, a więc i wynik całego uzasadnienia, dlatego oparcie go na ogólnych założeniach zamiast na walidacji na własnym kodzie prowadzi do liczb, których nie da się obronić.

Obciążenie zespołu jest przy tym niewielkie, bo prace toczą się w trybie tylko do odczytu, z dwiema lub trzema sesjami tygodniowo z architektami lub liderami technicznymi, bez zamrażania roadmapy. Altimi ma na koncie ponad sto pięćdziesiąt ocenionych systemów legacy w segmentach SaaS, FinTech, EdTech i cyberbezpieczeństwa, od monolitów zbudowanych przez założycieli po skalujące się platformy średniej wielkości działające pod presją dostarczania.

Kontekst europejski

Dla firm działających w Polsce, regionie CEE i na rynkach niemieckojęzycznych najmocniejszym argumentem w uzasadnieniu bywa wymiar regulacyjny, bo najłatwiej przeliczyć go na przychód. Zgodność z RODO, wymagania norm takich jak ISO 27001 oraz oczekiwania klientów korporacyjnych co do bezpieczeństwa i śledzenia zmian realnie decydują o dostępie do najbardziej wartościowych segmentów rynku. Jeśli architektura uniemożliwia ich spełnienie, koszt tego stanu można wyrazić wprost jako część rynku niedostępną dla firmy.

Znaczenie ma również to, gdzie przetwarzany jest kod źródłowy podczas oceny wspomaganej sztuczną inteligencją. Współpraca z partnerem z siedzibą w Unii Europejskiej i certyfikatem ISO 27001 pozwala utrzymać wrażliwy kod w europejskim obszarze ochrony danych i udokumentować zasady wykorzystania AI, co bywa istotne przy audytach i w rozmowach z klientami korporacyjnymi.

Uzasadnienie biznesowe modernizacji

Modernizacja przegrywa walkę o budżet nie dlatego, że jest nieopłacalna, lecz dlatego, że rzadko przedstawia się ją jako inwestycję z policzonym zwrotem. Uzasadnienie, które ma szansę przejść, opiera się na trzech filarach: koszcie bieżącym, który widać w liczbach, koszcie utraconych możliwości, którego trzeba świadomie poszukać, oraz koszcie odroczenia, który pokazuje, że kwota rośnie z każdym kwartałem zwłoki.

Do tego potrzebne są trzy rzeczy: scenariusze zamiast jednej propozycji, metryki łączące stan techniczny z wynikiem finansowym oraz liczby z oceny na rzeczywistym kodzie, a nie z szacunków. Tak zbudowany wniosek przestaje konkurować z kosztami administracyjnymi, a zaczyna konkurować z inicjatywami wzrostowymi, czyli trafia do właściwej kategorii.

Jeśli przygotowujesz taki wniosek i potrzebujesz liczb, które obronią się przed zarządem, najprościej zacząć od krótkiej rozmowy o systemie i o tym, co dziś blokuje plan.