Posiedzenie zarządu, punkt piąty: nowy portal dla klientów B2B. Dyrektor sprzedaży przekonuje, że bez niego firma traci zamówienia na rzecz konkurencji. Dyrektor IT, zapytany o koszt, mówi: „między półtora a czterema milionami, zależy od zakresu”. Dyrektor finansowy odkłada długopis. Prezes prosi o konkretną liczbę na następne posiedzenie, bo z takim przedziałem nie da się podjąć decyzji.
Za miesiąc na stole leży jedna liczba: 2,4 miliona złotych. Wygląda poważnie, ma dwa miejsca po przecinku w arkuszu i nikt nie pyta, skąd się wzięła. Zarząd ją zatwierdza, dział zakupów rozsyła zapytanie ofertowe, a trzy oferty, które wracają, wynoszą 1,6, 2,9 i 4,1 miliona. Teraz każda z nich jest porównywana z liczbą, która od początku była zgadywaniem.
Ten artykuł jest dla prezesów, dyrektorów finansowych i osób, które przygotowują dla nich materiały. Pokazuje, jak zbudować kosztorys i uzasadnienie biznesowe projektu IT, zanim pojawią się oferty dostawców. Teza jest prosta i może wydać się niewygodna: na tym etapie uczciwy budżet to przedział z założeniami, a dobra decyzja zarządu dotyczy pierwszego etapu, a nie całego projektu. Jedna liczba podana zbyt wcześnie nie zmniejsza ryzyka, tylko je ukrywa.
Dlaczego zarząd dostaje jedną liczbę, choć powinien dostać przedział?
Bo jedna liczba łatwiej mieści się w arkuszu budżetowym i w protokole z posiedzenia. Przedział wygląda jak brak przygotowania. Tymczasem na początku projektu wiedza o zakresie jest niewielka, a z niej wynika koszt. Steve McConnell w opracowaniu firmy Construx opisał tak zwany stożek niepewności: na etapie wstępnej koncepcji rzeczywisty koszt może okazać się nawet czterokrotnie wyższy albo czterokrotnie niższy od szacunku. Krytycy, m.in. Laurent Bossavit, wskazują, że te konkretne proporcje pochodzą z oceny eksperckiej, a nie z mierzonego zbioru danych, ale sam kierunek nie budzi sporów: niepewność maleje dopiero wtedy, gdy zapadają decyzje o zakresie.
Dane o przekroczeniach budżetów pokazują, co się dzieje, gdy tę niepewność się ignoruje. McKinsey razem z Uniwersytetem Oksfordzkim przeanalizował w 2012 roku ponad 5400 projektów IT. Duże projekty, o początkowym budżecie powyżej 15 milionów dolarów, przekraczały budżet średnio o 45% i harmonogram o 7%, dostarczając jednocześnie o 56% mniej wartości, niż zakładano. Twój projekt może być mniejszy, ale mechanizm jest ten sam: budżet zatwierdzony przed zrozumieniem zakresu jest punktem odniesienia dla wszystkich późniejszych rozczarowań.
Co więc przedstawić zarządowi? Przedział z jasno opisanymi założeniami, informację, co trzeba zrobić, żeby go zawęzić, i prośbę o decyzję dotyczącą tego właśnie kroku. To nie jest unikanie odpowiedzialności. To przyznanie, że decyzja za kilka milionów złotych zasługuje na kilka tygodni pracy, która pozwoli ją podjąć świadomie.
Co musi zawierać kosztorys projektu IT?
Kosztorys, który pokazuje tylko cenę wykonawcy, jest niepełny. Pełny obejmuje wszystko, co firma wyda w związku z projektem, niezależnie od tego, komu zapłaci. Warto go ułożyć w dziesięć pozycji.
Analiza i discovery. Doprecyzowanie wymagań, makiety, architektura, plan wdrożenia. Najczęściej osobne, krótkie zlecenie.
Budowa. Praca zespołu wykonawczego: programiści, testerzy, projektanci interfejsu, analityk, kierownik projektu.
Integracje. Połączenia z systemem ERP, CRM, płatnościami, systemami partnerów. Często niedoszacowane, bo ich złożoność wychodzi na jaw po stronie systemów, które już istnieją.
Migracja danych. Przeniesienie, oczyszczenie i weryfikacja danych ze starych systemów.
Licencje i infrastruktura. Chmura, licencje komponentów, narzędzia, środowiska testowe.
Bezpieczeństwo i zgodność. Testy penetracyjne, przegląd ochrony danych osobowych, wymagania sektorowe.
Koszty wewnętrzne. Czas Twoich pracowników zaangażowanych w projekt (o tym niżej).
Wdrożenie i zmiana organizacyjna. Szkolenia, materiały, komunikacja, okres równoległej pracy starego i nowego systemu.
Utrzymanie i rozwój. Koszty po uruchomieniu w horyzoncie 3–5 lat.
Rezerwa na ryzyko. Wyliczona, a nie dopisana jako okrągły procent.
Każdą z pozycji opisz w trzech kolumnach: kwota lub przedział, źródło szacunku (oferta, analogia, wyliczenie, założenie) i właściciel, czyli osoba, która za nią odpowiada. Kolumna „źródło” jest najważniejsza, bo pokazuje zarządowi, które liczby są twarde, a które są przypuszczeniami. Jeśli połowa budżetu ma źródło „założenie”, to ważna informacja, a nie wstydliwy szczegół.
Jak oszacować koszt budowy, zanim pojawią się oferty?
Bez ofert koszt budowy można oszacować trzema metodami. Najlepiej użyć co najmniej dwóch i porównać wyniki.
Analogia. Porównanie z podobnymi projektami, własnymi albo opisanymi publicznie. Jeśli firma zbudowała trzy lata temu podobny system, jego rzeczywisty koszt (nie budżet!) to cenny punkt odniesienia. Bent Flyvbjerg nazywa ten sposób prognozowaniem na podstawie klasy referencyjnej i od lat argumentuje, że to skuteczna obrona przed nadmiernym optymizmem planistów. Słabością analogii jest dobór porównania: projekty zawsze wydają się bardziej wyjątkowe, niż są.
Szacunek parametryczny. Skład zespołu razy czas razy stawka. To arytmetyka, którą zarząd rozumie od razu. Przykład ilustracyjny: zespół złożony z czterech doświadczonych specjalistów i jednej osoby na poziomie mid, pracujący przez osiem miesięcy. Według benchmarku ARDURA na 2026 rok senior backend developer kosztuje 180–260 zł netto za godzinę, a mid 130–180 zł. Przyjmując środki przedziałów i 160 godzin w miesiącu, czterech seniorów to około 140 800 zł miesięcznie, osoba na poziomie mid około 24 800 zł, razem około 165 600 zł miesięcznie, czyli przez osiem miesięcy około 1,32 miliona złotych netto. Dla porównania strona usług tworzenia oprogramowania ARDURA podaje, że typowy trzyosobowy zespół (dwóch programistów i tester) kosztuje około 62 000–123 000 zł miesięcznie, zależnie od poziomu doświadczenia. Słabość tej metody: wymaga założenia, ile czasu potrzeba, a to właśnie jest niewiadoma.
Szacunek oddolny. Lista funkcji, każda wyceniona przez osoby, które będą ją budować, z sumą na końcu. Jest najdokładniejszy, ale wymaga dobrze opisanego zakresu, więc na etapie koncepcji zwykle nie jest jeszcze możliwy. Dobrze sprawdza się po fazie discovery.
Co zrobić, gdy wyniki dwóch metod znacząco się różnią? Nie uśredniaj ich. Rozbieżność jest informacją: zwykle oznacza, że analogia pomija coś, co w Twoim projekcie jest inne (nowe integracje, większy wolumen danych, wymagania regulacyjne), albo że szacunek parametryczny zakłada zbyt krótki czas. Zapisz obie liczby, wyjaśnij różnicę i pokaż zarządowi, które założenie trzeba sprawdzić, żeby ją rozstrzygnąć. Często właśnie to pytanie staje się pierwszym zadaniem fazy discovery.
Do szybkiej orientacji przy mniejszych projektach może posłużyć kalkulator kosztów MVP, który na podstawie typu produktu, platformy, funkcji i integracji podaje orientacyjne widełki kosztu i czasu. Ogólne ramy czasowe z naszej strony usług: proste MVP to 2–3 miesiące, aplikacje średniej wielkości 4–8 miesięcy, systemy klasy enterprise 8–18 miesięcy. Takie widełki nie zastąpią kosztorysu, ale pozwolą sprawdzić, czy Twój szacunek mieści się w rozsądnym rzędzie wielkości.
Które koszty po własnej stronie zarządy najczęściej pomijają?
Koszty wewnętrzne są najczęściej pomijaną pozycją, bo nie generują faktury. Pracownicy i tak dostają pensję, więc ich czas wydaje się darmowy. Nie jest: jeśli kierowniczka działu obsługi klienta spędza dwa dni w tygodniu przez pół roku na warsztatach, odbiorach i testach, jej zespół ma mniej uwagi szefowej, a jej inne zadania czekają.
Najważniejsze role po stronie zamawiającego to właściciel produktu (osoba podejmująca decyzje o zakresie i priorytetach, zwykle przez znaczną część czasu pracy), eksperci dziedzinowi (osoby znające procesy, odpowiadające na pytania analityków), testerzy akceptacyjni (użytkownicy sprawdzający, czy system robi to, czego potrzebują), administratorzy systemów, z którymi trzeba się zintegrować, oraz osoba zarządzająca dostawcą i umową. Policz ich czas w osobodniach i przemnóż przez pełny koszt zatrudnienia.
Przykład ilustracyjny, z założeniami przyjętymi dla obliczeń. Właściciel produktu zaangażowany w połowie etatu przez dziesięć miesięcy to około 100 osobodni. Trzech ekspertów dziedzinowych po dzień w tygodniu przez ten sam okres to kolejne około 130 osobodni. Dziesięciu użytkowników testujących przez dwa tygodnie przed uruchomieniem to 100 osobodni. Razem około 330 osobodni. Przy założonym pełnym koszcie dnia pracy na poziomie 800 zł daje to około 264 000 zł, czyli kwotę, która w projekcie za półtora miliona złotych stanowi istotną część budżetu, choć nie pojawi się na żadnej fakturze. Twoje liczby będą inne, ale rząd wielkości zwykle zaskakuje zarządy, które tego wcześniej nie liczyły.
Drugą grupą pomijanych kosztów są działania wokół danych. Migracja danych z systemu, który działa od dziesięciu lat, prawie zawsze ujawnia duplikaty, braki i niespójności. Ktoś musi zdecydować, co z nimi zrobić, a to zwykle praca ekspertów dziedzinowych, nie programistów.
Trzecią grupą jest okres przejściowy. Przez kilka tygodni lub miesięcy stary i nowy system mogą działać równolegle, pracownicy uczą się nowych narzędzi i pracują wolniej, a dział wsparcia odbiera więcej zgłoszeń. Te koszty są realne, choć nie trafiają do budżetu projektu. Warto je pokazać zarządowi, żeby nie były zaskoczeniem w pierwszym kwartale po uruchomieniu. Szerzej o kosztach zespołu IT w języku zrozumiałym dla finansów piszemy w artykule budżetowanie zespołu IT na 2026.
Jak policzyć całkowity koszt posiadania na trzy do pięciu lat?
Koszt budowy to zwykle mniejsza część kosztu systemu w całym jego życiu. Po uruchomieniu system trzeba utrzymywać: aktualizować biblioteki i komponenty, usuwać błędy, dostosowywać do zmian w systemach, z którymi jest zintegrowany, monitorować, zabezpieczać i rozwijać. Do tego dochodzą infrastruktura, licencje i wsparcie użytkowników.
Całkowity koszt posiadania (TCO) to suma kosztów budowy i kosztów użytkowania w przyjętym horyzoncie, zwykle 3–5 lat. Horyzont powinien odpowiadać realnemu okresowi używania systemu i okresowi, w którym liczysz korzyści. Porównywanie korzyści z pięciu lat z kosztem budowy bez kosztów utrzymania to najczęstszy błąd w uzasadnieniach biznesowych.
Jak oszacować utrzymanie przed wyborem dostawcy? Można przyjąć zespół utrzymaniowy w określonym składzie i policzyć go metodą parametryczną, tak jak budowę. Można też oprzeć się na doświadczeniu firmy z podobnymi systemami. W obu przypadkach zapisz założenie i źródło. Przy wariantach SaaS porównuj abonament przez cały horyzont z kosztem budowy i utrzymania własnego systemu, a nie abonament roczny z kosztem budowy.
Przykład ilustracyjny pokazuje, dlaczego to ma znaczenie. Jeśli budowa portalu kosztuje 1,3 miliona złotych, a jego utrzymanie i rozwój wymagają zespołu dwóch osób przez cały rok, to przy stawkach z benchmarku opisanego wyżej utrzymanie może kosztować kilkaset tysięcy złotych rocznie. W horyzoncie pięciu lat suma kosztów utrzymania łatwo przewyższy koszt budowy. Do tego dochodzą infrastruktura, licencje i koszty wsparcia użytkowników. Zarząd, który zatwierdził 1,3 miliona, w rzeczywistości zobowiązał się do wydatku kilkukrotnie wyższego, tylko nikt mu tego nie pokazał.
Z tego wynika praktyczna wskazówka: przy porównywaniu wariantów pytaj nie tylko o koszt budowy, ale też o to, ile osób i jakich kompetencji będzie potrzebnych do utrzymania systemu po uruchomieniu. Rozwiązanie tańsze w budowie, ale oparte na niszowej technologii, może okazać się droższe w utrzymaniu, bo trudniej o specjalistów.
Składniki TCO i ukryte koszty oprogramowania rozkładamy szczegółowo w artykule o całkowitym koszcie posiadania oprogramowania. Tutaj wystarczy zasada: zarząd powinien zatwierdzać TCO, a nie koszt budowy, bo to TCO będzie płacił.
Ile rezerwy na ryzyko wpisać i jak ją uzasadnić?
Rezerwa wpisana jako „plus 15%” bez uzasadnienia jest pierwszą pozycją, którą dyrektor finansowy chce skreślić, i słusznie, bo nie wiadomo, za co płaci. Rezerwa wyliczona z listy ryzyk jest znacznie trudniejsza do zakwestionowania.
Warto rozdzielić dwie rzeczy. Rezerwa na zidentyfikowane ryzyka pokrywa zdarzenia, które potrafisz nazwać: integracja z ERP okaże się trudniejsza, dane będą wymagały więcej czyszczenia, kluczowy ekspert dziedzinowy będzie niedostępny. Dla każdego ryzyka szacujesz prawdopodobieństwo i koszt, a suma iloczynów daje rezerwę. Rezerwa zarządu pokrywa rzeczy, których nie przewidziałeś, i jest uruchamiana decyzją zarządu, a nie kierownika projektu. Hasło ocena ryzyka w naszym słowniku opisuje podstawowe techniki.
Ile powinny wynosić? Nie ma jednej wartości, i każdy, kto podaje uniwersalny procent, upraszcza. Wysokość rezerwy powinna wynikać z niepewności: na etapie koncepcji, przed discovery, jest wyższa, po doprecyzowaniu zakresu i architektury niższa. Dane McKinsey i Oksfordu o średnim przekroczeniu budżetu dużych projektów o 45% nie są normą do przepisania, ale są przypomnieniem, że rezerwa bliska zera w projekcie o niejasnym zakresie jest deklaracją optymizmu, a nie planem.
Rezerwę warto też powiązać z modelem umowy. W umowie o stałej cenie część ryzyka przejmuje wykonawca i wlicza je w cenę, więc Twoja rezerwa może być niższa, ale za to płacisz za ryzyko w cenie. W rozliczeniu za czas pracy ryzyko zostaje po Twojej stronie, więc rezerwa musi być wyższa, ale płacisz tylko za to, co się wydarzy. Porównanie modeli i podziału ryzyka znajdziesz w artykule o abonamencie zespołu, time and materials i fixed price.
Jak zbudować scenariusze: bazowy, ostrożny i minimalny?
Jedna liczba ukrywa to, że zakres projektu jest decyzją, a nie faktem. Trzy scenariusze pokazują zarządowi, co dostaje za jakie pieniądze, i pozwalają wybrać świadomie.
Scenariusz minimalny. Najmniejszy zakres, który rozwiązuje główny problem. Dla portalu B2B mogą to być składanie zamówień, status zamówień i faktury, bez konfiguratora produktów i bez integracji z systemami partnerów. Najniższy koszt, najszybsze uruchomienie, część korzyści.
Scenariusz bazowy. Zakres, którego oczekuje biznes, z realistycznymi założeniami co do integracji i danych. Na nim opierasz główną rekomendację.
Scenariusz ostrożny. Ten sam zakres co bazowy, ale z założeniami, które mogą się nie sprawdzić: trudniejsze integracje, więcej czyszczenia danych, dłuższy okres przejściowy. Pokazuje, ile może kosztować projekt, jeśli kilka ryzyk się zmaterializuje.
Do tego warto dodać wariant „nic nie robimy”: ile kosztuje utrzymanie obecnego stanu przez ten sam horyzont. To często pomijany punkt odniesienia, a bez niego trudno ocenić, czy projekt się opłaca. Utrzymanie starego systemu, ręczna obsługa zamówień, utracona sprzedaż, ryzyko awarii nieobsługiwanej technologii też mają cenę.
Scenariusze pomagają też w rozmowie z dostawcami. Zamiast prosić o wycenę jednego, sztywnego zakresu, możesz poprosić o wycenę scenariusza minimalnego z opcjami rozszerzeń. To pozwala zacząć od mniejszego zobowiązania i rozszerzać zakres, gdy pierwsza część zacznie przynosić korzyści.
Jak przedstawić korzyści i ROI, żeby dyrektor finansowy je przyjął?
Strona korzyści w uzasadnieniach biznesowych jest zwykle słabsza niż strona kosztów. Koszty mają oferty i stawki, a korzyści mają przymiotniki: „usprawnienie”, „lepsze doświadczenie klienta”, „przewaga konkurencyjna”. Dyrektor finansowy nie może ich sprawdzić, więc ich nie uwzględnia.
Korzyści warto podzielić na trzy kategorie. Przychodowe: dodatkowa sprzedaż, wyższa wartość koszyka, mniejsza utrata klientów. Kosztowe: mniej pracy ręcznej, niższe koszty utrzymania starego systemu, mniej błędów. Ryzyka unikniętego: koniec wsparcia technologii, kary regulacyjne, awarie. Dla każdej korzyści podaj sposób pomiaru, wartość bazową dziś, wartość docelową, termin i właściciela, czyli osobę z biznesu, która podpisuje się pod tą liczbą. Korzyść bez właściciela to życzenie.
Dobrze opisana korzyść wygląda na przykład tak: „Udział zamówień składanych przez portal wzrośnie z 0% do 40% w ciągu dwunastu miesięcy od uruchomienia; każde zamówienie złożone samodzielnie przez klienta oszczędza średnio 12 minut pracy działu obsługi, co przy obecnym wolumenie daje X godzin miesięcznie; właściciel: dyrektor sprzedaży; pomiar: raport z systemu zamówień co miesiąc”. Liczby w tym przykładzie są ilustracją, ale struktura zdania pokazuje, czego dyrektor finansowy oczekuje: wartości bazowej, wartości docelowej, mechanizmu, właściciela i sposobu pomiaru. Taką korzyść da się po roku rozliczyć, a to zmienia charakter całego uzasadnienia biznesowego z obietnicy w zobowiązanie.
Unikaj podwójnego liczenia. Jeśli portal skraca obsługę zamówienia, możesz policzyć oszczędność czasu działu obsługi albo dodatkową sprzedaż, którą ten dział obsłuży w zaoszczędzonym czasie, ale nie obie naraz. Unikaj też przeliczania zaoszczędzonych godzin na pieniądze, jeśli nikt nie planuje zmienić zatrudnienia ani przesunąć ludzi do innych zadań. Czas, który rozpływa się w organizacji, nie poprawia wyniku.
Na koniec wskaźniki: okres zwrotu (kiedy skumulowane korzyści przekroczą skumulowane koszty), wartość bieżąca netto przy stopie dyskontowej przyjętej w firmie i ewentualnie ROI. Pokaż je dla każdego scenariusza. Jak realistycznie szacować zwrot z oprogramowania dedykowanego, opisujemy w artykule kalkulator w głowie prezesa, a jak policzyć zwrot z pracy zewnętrznych specjalistów, w tekście o ROI z outsourcingu IT.
Jak księgowość i podatki zmieniają obraz budżetu?
Dla zarządu nie jest obojętne, czy projekt obciąży wynik jednorazowo, czy zostanie rozłożony na lata. Ten sam wydatek w gotówce może wyglądać zupełnie inaczej w rachunku zysków i strat, w zależności od tego, czy jest nakładem inwestycyjnym, czy kosztem bieżącym.
Kilka zasad warto znać przed rozmową z głównym księgowym. Oprogramowanie budowane na własne potrzeby może być aktywowane jako wartość niematerialna, jeśli spełnia warunki określone w polityce rachunkowości firmy (w firmach stosujących MSSF reguluje to MSR 38, który oddziela fazę badań od fazy prac rozwojowych). Na gruncie podatku dochodowego od osób prawnych licencje na programy komputerowe amortyzuje się przez co najmniej 24 miesiące, zgodnie z art. 16m ustawy o CIT. Abonamenty SaaS i usługi chmurowe są zwykle kosztem bieżącym. Usługi zespołu wykonawczego mogą być kosztem bieżącym albo częścią wartości aktywowanego oprogramowania, zależnie od tego, czego dotyczą.
Te rozróżnienia wpływają na wybór wariantu. Rozwiązanie SaaS i system budowany na zamówienie mogą mieć podobny TCO w pięcioletnim horyzoncie, ale zupełnie inny wpływ na wynik w pierwszym roku. Firma, której zależy na wyniku operacyjnym w danym roku, może preferować inną strukturę niż firma, która patrzy głównie na przepływy pieniężne.
Nie jest to porada podatkowa ani księgowa. Celem jest to, żeby budżet przedstawiony zarządowi pokazywał nie tylko gotówkę, ale też wpływ na wynik w kolejnych latach, uzgodniony z działem finansowym przed posiedzeniem, a nie w jego trakcie.
Jak wygląda business case na jedną stronę dla zarządu?
Zarząd nie przeczyta czterdziestu stron. Uzasadnienie biznesowe powinno mieścić się na jednej stronie, z załącznikami dla osób, które chcą sprawdzić szczegóły. Poniższa tabela pokazuje strukturę, która sprawdza się jako punkt wyjścia.
| Sekcja | Co zawiera | Pytanie zarządu, na które odpowiada |
|---|---|---|
| Problem i cel | Co nie działa dziś, ile to kosztuje, co chcemy osiągnąć | Po co to robimy? |
| Warianty | Minimalny, bazowy, ostrożny, „nic nie robimy”, ewentualnie SaaS | Jakie mamy opcje? |
| Koszt budowy | Przedział dla każdego wariantu, źródło szacunku | Ile kosztuje zbudowanie? |
| Koszty wewnętrzne | Osobodni ludzi po naszej stronie, okres przejściowy | Ile kosztuje nas samych? |
| TCO 3–5 lat | Budowa plus utrzymanie, licencje, infrastruktura | Ile zapłacimy łącznie? |
| Rezerwa | Rezerwa na zidentyfikowane ryzyka i rezerwa zarządu | Co, jeśli coś pójdzie źle? |
| Korzyści | Mierzalne, z wartością bazową, docelową i właścicielem | Co dostaniemy i kto za to odpowiada? |
| Wskaźniki | Okres zwrotu, NPV dla każdego scenariusza | Czy to się opłaca? |
| Wpływ na wynik | Podział na nakłady inwestycyjne i koszty bieżące | Jak to wpłynie na wynik w kolejnych latach? |
| Etapy i decyzje | Pierwszy etap, jego koszt, kryteria przejścia dalej | O czym decydujemy dziś? |
| Założenia | Lista założeń z oceną pewności | Na czym to wszystko stoi? |
Ostatni wiersz jest najważniejszy, choć zwykle trafia na koniec. Lista założeń pozwala zarządowi zobaczyć, które elementy budżetu są pewne, a które są hipotezą do sprawdzenia w pierwszym etapie. Dobre uzasadnienie biznesowe nie udaje pewności, której nie ma.
Przy każdym założeniu warto podać ocenę pewności w prostej skali, na przykład wysoka, średnia i niska, oraz sposób jego weryfikacji. Założenie „integracja z ERP przez istniejące API” z niską pewnością to sygnał, że pierwszym zadaniem discovery powinna być rozmowa z administratorem tego systemu. Zarząd widzi wtedy nie tylko liczby, ale też plan, który zamieni niepewne założenia w fakty.
Jak podejmować decyzję etapami, a nie raz na cały projekt?
Najlepsza odpowiedź na niepewność to nie większa rezerwa, tylko mniejsze decyzje. Zamiast zatwierdzać cały projekt za kilka milionów złotych, zarząd zatwierdza pierwszy etap z jasno określonym kosztem i kryteriami, po których spełnieniu wróci do decyzji o kolejnym.
Typowy podział wygląda tak. Etap pierwszy to discovery: doprecyzowanie wymagań, architektura, prototyp, zawężony kosztorys. Trwa kilka tygodni i kosztuje ułamek całości. W ARDURA faza discovery w projektach tworzenia oprogramowania trwa 1–2 tygodnie i służy zdefiniowaniu zakresu oraz architektury. Etap drugi to wersja minimalna, uruchomiona dla części użytkowników, na której sprawdzasz pierwsze korzyści. Etap trzeci to rozwój do pełnego zakresu, finansowany na podstawie wyników drugiego.
Kryteria przejścia między etapami powinny być zapisane z góry. Dla discovery: zakres opisany, przedział kosztu zawężony do ustalonej szerokości, kluczowe ryzyka zidentyfikowane, decyzja o modelu umowy. Dla wersji minimalnej: korzyści mierzone na rzeczywistych użytkownikach, koszt w przedziale, brak blokujących problemów technicznych. Jeśli kryteria nie są spełnione, zarząd może zmienić zakres, zmienić dostawcę albo zakończyć projekt, tracąc ułamek budżetu zamiast całości.
Jak przedstawić taką decyzję na posiedzeniu? Zamiast wniosku „zatwierdzamy budżet projektu w wysokości X” zarząd dostaje wniosek „zatwierdzamy etap discovery za Y, z terminem Z; po jego zakończeniu otrzymamy zawężony kosztorys, rekomendację modelu umowy i listę dostawców do zapytania ofertowego; na tej podstawie zdecydujemy o etapie drugim”. Dyrektor finansowy dostaje wtedy kwotę, którą da się kontrolować, a dyrektor sprzedaży widzi, że projekt rusza od razu, a nie po kolejnym kwartale dyskusji. Jednocześnie warto pokazać zarządowi pełny przedział dla całego projektu, żeby nikt nie był zaskoczony skalą przy decyzji o etapie drugim.
Takie podejście zmienia też logikę finansowania. Zamiast rocznego budżetu na projekt pojawia się finansowanie kolejnych etapów na podstawie dostarczonej wartości. To podejście nazywa się często zwinnym budżetowaniem albo finansowaniem wartości zamiast projektów.
Jak budżet wpływa na wybór dostawcy i model umowy?
Budżet przygotowany przed wyborem dostawcy to nie tylko materiał dla zarządu. To także narzędzie w rozmowie z rynkiem. Kilka decyzji warto podjąć świadomie.
Pierwsza: czy podać dostawcom przedział budżetu. Bez tej informacji dostawcy proponują rozwiązania o bardzo różnej skali, a oferty trudno porównać. Ujawnienie przedziału nie musi oznaczać, że wszyscy wycenią projekt na górnej granicy, jeśli zapytanie ofertowe zawiera precyzyjny zakres i jasne kryteria oceny. Druga: czy zamówić najpierw discovery jako osobne zlecenie. Zmniejsza to ryzyko obu stron, a dokument wynikowy możesz wykorzystać w dalszym wyborze wykonawcy, jeśli umowa przenosi na Ciebie prawa do niego.
Trzecia: model umowy. Stała cena daje przewidywalność budżetu, ale wymaga precyzyjnego zakresu i zawiera premię za ryzyko. Rozliczenie za czas pracy daje elastyczność, ale wymaga aktywnego zarządzania zakresem i limitów. Abonament zespołu przenosi rozmowę z ceny projektu na koszt miesięczny i tempo dostarczania. Każdy z tych modeli wymaga innej rezerwy i innego sposobu raportowania do zarządu. Przy stałej cenie zarząd powinien dostawać informację o zleceniach zmian i ich skumulowanej wartości, bo to tam ucieka budżet. Przy rozliczeniu za czas pracy potrzebne jest comiesięczne porównanie zużytego budżetu z postępem prac, z prognozą do końca etapu. Przy abonamencie zespołu liczy się tempo dostarczania funkcji i ich zgodność z priorytetami biznesu. Ustal format tych raportów przed podpisaniem umowy i wpisz go do niej, żeby dostawca od początku zbierał potrzebne dane, a zarząd nie dowiadywał się o przekroczeniu dopiero na koniec kwartału.
Czwarta: jak porównywać oferty z budżetem. Porównuj oferty z przedziałem i z założeniami, nie z jedną liczbą. Oferta poniżej dolnej granicy przedziału to sygnał, że dostawca coś pominął albo przyjął inne założenia, i warto to sprawdzić przed podpisaniem, a nie po pierwszym zleceniu zmiany. Jeśli projekt dotyczy rozbudowy istniejącego systemu, którego stanu nie znasz, warto przed budżetowaniem zlecić niezależny audyt kodu; w ARDURA audyt kondycji kodu kosztuje od 18 000 zł, trwa 1–2 tygodnie i ma stały zakres.
Jakie są kluczowe wnioski przed posiedzeniem zarządu?
Budżet projektu IT przygotowany przed wyborem dostawcy nie musi być zgadywaniem, ale nie może też udawać pewności, której nie ma. Dobry kosztorys pokazuje przedział, jego źródła i założenia, a dobra decyzja zarządu dotyczy pierwszego kroku, który ten przedział zawęzi.
Zapamiętaj sześć rzeczy. Po pierwsze, przedstaw przedział z założeniami zamiast jednej liczby i powiedz, co trzeba zrobić, żeby go zawęzić. Po drugie, ułóż kosztorys w dziesięć pozycji, łącznie z kosztami wewnętrznymi, migracją danych i okresem przejściowym, i przy każdej podaj źródło szacunku. Po trzecie, każ zarządowi zatwierdzać TCO w horyzoncie 3–5 lat, a nie sam koszt budowy. Po czwarte, wylicz rezerwę z listy ryzyk i oddziel ją od rezerwy zarządu. Po piąte, pokaż trzy scenariusze i wariant „nic nie robimy”, a korzyści przypisz do konkretnych właścicieli. Po szóste, poproś o decyzję etapową: najpierw discovery, potem wersja minimalna, potem pełny zakres.
Jeśli potrzebujesz zawęzić przedział przed posiedzeniem zarządu albo przed zapytaniem ofertowym, zobacz, jak pracujemy w tworzeniu oprogramowania na zamówienie, lub umów rozmowę. Faza discovery trwa 1–2 tygodnie i kończy się zakresem, architekturą i kosztorysem, który można przedstawić zarządowi.