8 ryzyk nieświadomie pomijanych przez zarządy przy kontraktach IT o wartości liczonej w milionach złotych

Jeśli macie dziś na biurku ofertę na wdrożenie, migrację albo modernizację systemu za milion złotych i więcej, to prawdopodobnie oceniacie ją przez pryzmat dwóch aspektów: ceny i wiarygodności dostawcy. Oba są ważne. Żaden z nich nie dotyka jednak ryzyk, które najczęściej wpływają na niepowodzenie projektów IT o takiej skali.

Przez 25 lat byłem po stronie dostawcy technologii – sprzedawałem, negocjowałem i zamykałem duże umowy na rynkach EMEA. Z tej perspektywy widać rzecz, która pozostaje niewidoczna dla drugiej strony stołu negocjacyjnego: prawie każda kosztowna porażka była przewidywalna. Nie oczywista – przewidywalna. Ktoś po prostu nie nazwał bariery, zanim złożył podpis.

Ryzyko w kontrakcie IT rzadko wynika z cenny znajdującej się na pierwszej stronie oferty. Siedzi w zapisach, w modelu współpracy i w tym, czego w umowie nie ma. Ujawnia się nie w dniu podpisu, lecz 12-18 miesięcy po zwarciu kontraktu, a więc wtedy, kiedy jest już drogie do naprawienia.

Warto od razu zaznaczyć jedno: żadne z opisanych niżej ryzyk nie wynika z nieuczciwości dostawcy. Wszystkie wynikają z asymetrii. Po jednej stronie stołu siedzą ludzie, którzy takie kontrakty negocjują kilkadziesiąt razy w roku. Po drugiej – osoby, które robią to raz na kilka lat. Nie jest to zatem zła wola żadnej ze strony. To pewna struktura i jak każdą strukturę można ją zawczasu rozpoznać oraz zmienić.

Oto osiem ryzyk, które najczęściej umykają zarządom oraz pytania, które warto zadać przy każdym z nich, zanim ryzykowna decyzja stanie się nieodwracalna.

1. Nikt nie jest właścicielem ryzyka

Kontrakt zatwierdza komitet, zarząd, kilka podpisów. Ale gdy projekt nie dowiezie, okazuje się, że nikt pojedynczo nie odpowiada za skutki. Decyzja rozproszona to decyzja, za którą nikt nie odpowiada, a brak właściciela ryzyka to pierwszy sygnał, że eskalacja -gdy tylko przyjdzie – utknie w martwym punkcie.

Pytanie: Kto imiennie odpowiada, jeśli ten projekt się nie uda – i czy ta osoba była realnie w procesie decyzyjnym?

2. Cena ofertowa to nie całkowity koszt

Cena ofertowa bywa zaprojektowana tak, żeby wyglądać rozsądnie. Bywa też celowo zaniżona, by wygrać kontrakt, a realna ekonomia odbudowywana jest później, aneks po aneksie. To skuteczna taktyka, bo na etapie delivery zmiana dostawcy jest praktycznie niemożliwa: projekt jest w toku, zespół zaangażowany, a każdy kolejny aneks trafia w sytuację bez alternatywy. Klient płaci, bo nie może już zawrócić.

Przykład z praktyki. Przetarg na duży projekt infrastrukturalny dla międzynarodowej firmy produkcyjnej. Już na etapie przygotowywania oferty było wiadomo, że zakres założony przez klienta jest nierealny – nie obejmował elementów, które i tak trzeba będzie wykonać. Cena zwycięskiej oferty była niższa od naszych szacunków nawet o 25%.

Pierwsze rozmowy o zmianie zakresu zaczęły się po czterech, może pięciu miesiącach, gdy ruszyły warsztaty wdrożeniowe i okazało się, że procesy biznesowe klienta wyglądają zupełnie inaczej niż w analizie przedwdrożeniowej. Pojawił się pierwszy aneks. Później następny. I kolejny.

Klient tłumaczył to sobie bardzo prosto: „skoro projekt już trwa, to przecież nie możemy go zatrzymać”. W praktyce koszt wrócił dokładnie do poziomu, który od początku był realistyczny – został jednak rozłożony w czasie i zatwierdzony w kawałkach, z których żaden z osobna nie wyglądał dramatycznie.

To mechanizm, nie wypadek. Różnica 20-25 procent na etapie oceny ofert wygrywa przetarg. Ta sama różnica rozpisana na sześć aneksów w ciągu dwóch lat nie wywołuje żadnej dyskusji na zarządzie, bo każdy z nich jest omawiany osobno i zawsze w kontekście projektu, który już się toczy.

Do tego dochodzi prawdziwe TCO: integracja, migracja danych, szkolenia, dodatkowe moduły, wyższe poziomy wsparcia, wzrost stawek po okresie promocyjnym i koszt wewnętrznego czasu zespołu. Różnica między ceną a całkowitym kosztem projektu potrafi być wielokrotnością tego, co widnieje na pierwszej stronie oferty.

Pytanie: Jaki jest pełny koszt w horyzoncie 3-5 lat – i czy cena ofertowa jest realna, czy zaniżona po to, by odbudować ją aneksami, gdy nie będziemy już mogli zmienić dostawcy?

3. Dostawca licytuje bez zasobów do realizacji

Część dostawców wchodzi w przetarg bez zespołu i kompetencji potrzebnych, by dowieźć projekt. Liczą na to, że niezbędne zasoby pozyskają już po podpisaniu umowy, czy to przez podwykonawców czy za pośrednictwem ludzi ściąganych z rynku.

Efekt jest przewidywalny: koszty rosną, terminy się wydłużają, a jakość zależy od zespołu, którego w momencie wyboru oferty jeszcze nie było. Oceniacie markę i referencje dostawcy; dostajecie zespół kompletowany naprędce pod Wasz projekt.

Pytanie: Czy zespół, który zrealizuje nasz projekt, istnieje dziś u dostawcy — czy zostanie powołany dopiero po podpisaniu umowy?

4. Asymetryczne zapisy umowy

SLA, kary, limity odpowiedzialności, klauzule indemnizacyjne to elementy przygotowywane przez dział prawny dostawcy – i tworzone z myślą o jego interesach. Tymczasem po stronie klienta analiza oferty najczęściej skupia się na cenie i zakresie. Mało kto analizuje klauzule prawne, choć to właśnie one decydują o tym, która ze stron będzie odpowiedzialna za ewentualne ryzyka i poniesie koszt, gdy coś pójdzie nie tak.

Warto zwrócić uwagę na proporcję, którą łatwo sprawdzić w kwadrans: limit odpowiedzialności dostawcy jest zwykle ustalany jako ułamek wartości kontraktu. Tymczasem, Wasza realna strata w razie niepowodzenia projektu nie ma nic wspólnego z wartością kontraktu – jest funkcją tego, ile procesów firmy jest od tego systemu zależnych.

Pytanie: Kto ponosi ryzyko, gdy usługa zawiedzie – i czy limit odpowiedzialności dostawcy ma jakikolwiek związek z naszą realną stratą?

5. Koszt wyjścia nie został policzony

Vendor lock-in nie boli w dniu podpisania umowy. Boli wówczas, kiedy zapadnie decyzja o rozstaniu z dostawcą. Zastrzeżone formaty danych, brak realnej przenaszalności kodu, uzależnienie od jednego integratora – wszystko to sprawia, że zmiana dostawcy staje się na tyle kosztowna, że przestaje być realną opcją biznesową. Dodatkowo, dostawca, który wie, że nie możecie odejść, negocjuje inaczej przy każdym odnowieniu.

Przykład. Duża organizacja finansowa chciała zmienić dostawcę systemu po kilku latach współpracy. Na poziomie zarządu panowało przekonanie, że wystarczy rozpisać nowy przetarg.

Dopiero głębsza analiza pokazała, że drogi wyjścia praktycznie nie ma. Dziesiątki integracji z innymi systemami. Budowane latami dedykowane rozszerzenia. Dane zapisane w niestandardowych strukturach. Plus kilku kluczowych administratorów, którzy jako jedyni naprawdę rozumieli całość środowiska.

Sam koszt migracji i odtworzenia wszystkich zależności okazał się wyższy niż kilka kolejnych lat współpracy z obecnym dostawcą. Formalnie klient mógł odejść. Ekonomicznie już nie.

Rzecz, na którą warto zwrócić uwagę: żaden z tych czterech elementów nie powstał w wyniku złej decyzji. Integracje budowano, bo były potrzebne. Rozszerzenia – bo standard nie wystarczał. Wiedza skupiła się w kilku osobach, bo tak się dzieje w każdej organizacji. Vendor Lock-in nie jest wydarzeniem. Jest osadem, który narasta przez lata poprawnych decyzji. To właśnie dlatego nikt nie ryzyka zauważa w momencie, w którym da się go jeszcze ograniczyć – czyli przed podpisaniem umowy.

Pytanie: Ile realnie kosztowałoby nas wyjście od tego dostawcy za trzy lata – i czy w ogóle to policzyliśmy?

6. W umowie nie ma scenariusza wyjścia

Co się dzieje, gdy projekt nie dowozi, dostawca zmienia model cenowy albo zostaje przejęty? Warunki wypowiedzenia, wsparcie w okresie przejściowym, zwrot i format danych – wszystko to negocjuje się przed formalnym zawarciem umowy, a więc wtedy, kiedy macie siłę przetargową. Po złożeniu podpisu na umowie jest zdecydowanie za późno na przygotowanie scenariusza wyjścia.

Pytanie: Czy mamy zapisaną, wykonalną ścieżkę wyjścia – z określonym wsparciem przejściowym i zwrotem danych?

7. Pomijamy kondycję i trajektorię biznesową dostawcy

Oceniamy, co dostawca potrafi dziś. Rzadko oceniamy to, dokąd zmierza, jaka jest jego strategia biznesowa, pozycja rynkowa i plany. Przejęcie, zmiana właściciela, wycofanie produktu, zmiana modelu licencjonowania – każde z takich zdarzeń może z dnia na dzień zmienić ekonomię kontraktu podpisanego w dobrej wierze. Obietnica roadmapy nie jest zobowiązaniem.

Pytanie: Co stanie się z naszym kontraktem, jeśli dostawca zostanie przejęty albo zmieni licencjonowanie — i czy nie opieramy decyzji na obietnicach, których nie ma w umowie?

8. Decyzja, której nie należało podejmować

Najdroższe decyzje IT, jakie widziałem, nie były tymi źle wynegocjowanymi. Były tymi, których w ogóle nie powinno się podejmować – w pełni zatwierdzonymi, poprawnie podpisanymi, z przekonaniem wdrożonymi.

Przykład, który zmienił mój sposób patrzenia na tego typu projekty dotyczył realizowanego w jednej z dużych organizacji programu transformacyjnego o bardzo dużej wartości. Od początku było widać, że biznes nie jest na taką zmianę gotowy: procesy nieuzgodnione, właściciele poszczególnych obszarów ze sprzecznymi celami oraz sponsor, który bardziej potrzebował ogłosić rozpoczęcie programu, niż go rzeczywiście przeprowadzić.

Mimo to projekt dostał zielone światło. Nikt nie chciał powiedzieć „stop”, bo oznaczałoby to zakwestionowanie decyzji członka zarządu, który był twarzą całego przedsięwzięcia – i to mimo tego, że ryzyko niepowodzenia było widoczne dla wszystkich. Polityka organizacyjna okazała się silniejsza od faktów.

Po kilkunastu miesiącach program został zasadniczo przebudowany. Wydano ogromne środki zanim organizacja przyznała, że problemem nigdy nie była technologia. Problemem była decyzja podjęta z powodów politycznych, zanim organizacja była gotowa do zmiany.

Wtedy zrozumiałem, że największym ryzykiem w projektach enterprise rzadko jest technologia. Najczęściej jest nim decyzja, której nikt nie miał odwagi zakwestionować.

Projekt forsowany przez jedną osobę, presję czasu albo przekonanie, że „wszyscy to mają”, bez realnej potrzeby i bez prawdziwego poparcia organizacji, jest ryzykiem samym w sobie — niezależnie od tego, jak dobry jest dostawca.

Pytanie: Gdybyśmy nie czuli presji, żeby działać teraz – czy podjęlibyśmy tę decyzję w ogóle?

Kiedy zadawać pytania?

Osiem wymienionych powyżej ryzyk ma różny termin przydatności. Każde z nich da się rozbroić w innym momencie procesu, a jednocześnie przeoczenie tego etapu oznacza, że pozostaje już tylko absorbowanie kosztu.

• Zanim powstanie zapytanie ofertowe. Tu należą ryzyka 1 i 8: kto imiennie jest właścicielem decyzji i czy tę decyzję w ogóle należy podejmować. To jedyny moment, w którym można powiedzieć „nie” bez konsekwencji reputacyjnych. Wysłanie zapytania jest publicznym zobowiązaniem organizacji wobec samej siebie — od tej chwili wycofanie się będzie niosło m.in. potencjalne straty wizerunkowe.
• W trakcie oceny ofert. Tu należą ryzyka 2, 3 i 7: pełny koszt w horyzoncie pięcioletnim, realne zasoby dostawcy i jego trajektoria. To ostatni moment, w którym macie konkurencję na stole, a więc jedyny, w którym możecie żądać danych i dostawać je szybko. Po wyborze dostawcy te same pytania stają się uciążliwością, a nie warunkiem.
• Przy negocjacji umowy. Tu należą ryzyka 4, 5 i 6: rozkład odpowiedzialności, koszt wyjścia i ścieżka wyjścia. Po złożeniu podpisu na umowie wasza dźwignia negocjacyjna spada do zera i nie wraca, a wszystkie trzy ryzyka dotyczą sytuacji, które wydarzą się dopiero za trzy lata.
• Po podpisaniu umowy. Żadne. Ryzyka można już wyłącznie zaabsorbować.

Otwarte pozostaje natomiast pytanie o to, kto powinien dociekać i kwestionować warunki opisane w standardowej umowie – i to jest trudniejsza część. W praktyce osoba, która na tydzień przed złożeniem podpisu podnosi kwestię kosztu wyjścia w czwartym roku, nie jest odbierana jako ostrożna. Jest odbierana jako ta, która opóźnia projekt. Proces przygotowania trwał rok, ludzie są zmęczeni, termin jest w planie rocznym, ktoś obiecał radzie nadzorczej konkretną datę.

Dlatego pytania, które potencjalnie mogłyby rozbroić istotne ryzyka projektowe rzadko padają spontanicznie. Muszą być czyjąś formalną rolą, zostać wpisane w agendę komitetu, przypisane imiennie, zadane wtedy, gdy zadanie ich nie jest jeszcze aktem odwagi. Taki podział ról kosztuje jedno popołudnie i jest najtańszym elementem całego procesu zakupowego.

Bariera nazwana wcześnie to przypis. Nazwana późno – to odpis.

Na koniec chciałbym podkreślić, że rozbrojenie każdego z wymienionych ryzyk nie wymaga większego budżetu. Wymaga natomiast nazwania zanim umowa z dostawcą zostanie zawarta, a nie po fakcie. Decyzję można tanio zmienić, dopóki zarząd się nie zobowiązał. Potem już się jej nie naprawia – tylko absorbuje jej koszt.

Stół, przy którym podpisuje się kontrakt IT za milion i więcej, ma dwie strony. Dostawca dokładnie zna swoją. Pytanie, które warto zadać przed złożeniem podpisu na umowie brzmi: czy równie dobrze znamy swoją?

Jacek Dukat, Founder, JDSD – niezależne doradztwo przy decyzjach i kontraktach IT

Jacek Dukat posiada 25 lat doświadczenia w sprzedaży i negocjacjach kontraktów IT na rynkach EMEA po stronie dostawcy. Dziś doradza zarządom i właścicielom po stronie kupującego, przy dużych decyzjach technologicznych i transformacyjnych. Twórca The Barrier Method – metody nazywania barier, które przesądzają o dużych decyzjach enterprise, zanim te się ujawnią.