Wdrożenie systemu IT to operacja wysokiego ryzyka, która czasem może przypominać nawet hazard niż strategiczną inwestycję. Uważamy, że głównym powodem porażek nie jest brak kompetencji programistów, ale niska jakość kontraktów, które nie zabezpieczają interesów zamawiającego na wypadek rozjechania się wizji z rzeczywistością. Sprawdziliśmy, że duża część sporów wynika z braku precyzyjnego zdefiniowania, czym właściwie jest „gotowy system”, co pozwala dostawcom na bezkarne przesuwanie terminów.
Dlaczego wdrożenia IT kończą się sporami?
Powodów może być mnóstwo, jednak zatrzymajmy się przy kwestiach prawnych. Projekty IT upadają z powodu braku precyzyjnej specyfikacji funkcjonalnej oraz niedopasowania modelu zarządzania projektem, do zapisów zawartych w umowie. To prowadzi do sytuacji, w której przedsiębiorca płaci za roboczogodziny, nie otrzymując w zamian działającego narzędzia, a dostawca zasłania się zmianą zakresu prac przy każdej próbie wyegzekwowania wyników.
Z naszego doświadczenia wynika, że korzeniem problemu jest tzw. luka oczekiwań. Przedsiębiorca kupuje rozwiązanie problemu biznesowego, a software house sprzedaje określoną liczbę godzin pracy programistów. Bez twardych zapisów o etapach (kamienie milowe) i precyzyjnych kryteriów akceptacji, konflikt jest nieunikniony. W przeciwieństwie do np. zakupu maszyn, gdzie parametry są mierzalne, w IT działający moduł może oznaczać dla każdej ze stron coś zupełnie innego. To prowadzi do wniosku, że bez udziału prawnika rozumiejącego architekturę systemów już na etapie negocjowania kontraktu, firma podpisuje coś jak czek in blanco na rzecz dostawcy. Dodatkowo, brak procedur zarządzania zmianą powoduje, że projekty puchną, budżety pękają, a ostateczny produkt i tak nie integruje się z istniejącą infrastrukturą firmy, generując kolejne koszty zamiast oszczędności.
Punkty zapalne, gdzie dostawcy przepalają budżet?
Największym generatorem strat w projektach IT są opóźnienia oraz błędy krytyczne, które dostawca próbuje zakwalifikować jako dodatkowe funkcjonalności. Sprawdziliśmy, że większość sporów sądowych w tej branży, dotyczy właśnie momentu oddania dzieła i interpretacji tego, czy wykryte błędy uniemożliwiają korzystanie z systemu, czy są jedynie usterkami kosmetycznymi.
W praktyce biznesowej może spotkać się z kilkoma głównymi patologiami. Po pierwsze, opóźnienia, które wynikają z braku odpowiedniego personelu po stronie dostawcy (Twoim projektem zajmują się juniorzy, choć płacisz za seniorów). Po drugie, całkowite niewdrożenie systemu, gdzie po roku prac okazuje się, że architektura jest błędna i projekt trzeba zacząć od nowa. Po trzecie, brak integracji, czyli system działa w próżni, nie wymieniając danych z Twoim CRM-em czy ERP-em, co czyni go bezużytecznym. Po czwarte, jednostronne naruszenia umowy, np. żądanie dodatkowych opłat za moduły, które miały być w standardzie. Bywa, że przedsiębiorca często boi się przerwać współpracę, wpadając w pułapkę kosztów, co tylko zwiększa ostateczną skalę strat finansowych.
Jak odzyskać pieniądze od nierzetelnego dostawcy?
Skuteczna windykacja należności od software house’u wymaga twardego udokumentowania nienależytego wykonania zobowiązania i wykazania, że dostawca naruszył konkretne parametry SLA lub specyfikacji technicznej. Podstawą jest tutaj profesjonalne wezwanie do zapłaty, które nie jest jedynie prośbą o zwrot, ale merytoryczną analizą błędów, opartą na zgromadzonym materiale dowodowym, takim jak np. logi z Jiry czy korespondencja e-mail.
Trzeba zadbać o materiał dowodowy. Dostęp do serwerów, kod źródłowy w repozytorium czy dokumentacja w chmurze mogą zostać zablokowane przez dostawcę w momencie eskalacji sporu. Dlatego pierwszym krokiem powinno być zabezpieczenie stanu faktycznego, najlepiej przy udziale biegłego informatyka, który sporządzi raport z niefunkcjonowania systemu. To prowadzi do wniosku, że walkę o pieniądze wygrywa się nie w sądzie, ale na jeszcze na etapie dokumentacji projektowej. Jeśli masz dowody na to, że system generuje błędy uniemożliwiające sprzedaż, Twoja pozycja negocjacyjna rośnie. Pamiętaj, że dostawcy boją się utraty reputacji, więc dobrze uzasadnione roszczenie może skończyć się ugodą już po pierwszym oficjalnym piśmie z kancelarii.
Negocjacje czy twarde uderzenie?
Uważamy, że mediacje biznesowe w sporach IT jak najbardziej mają sens, gdy dostawca wykazuje realną wolę naprawy błędów. W przeciwnym razie negocjacje są jedynie metodą na granie na zwłokę, co pozwala nieuczciwemu kontrahentowi na wyprowadzenie majątku ze spółki. Jeśli nie ma miejsca na negocjacje, należy skupić się na szybkich działaniach windykacyjnych.
Jeśli jednak zależy ci na dokończeniu wdrożenia, warto rozważyć ugodę korygującą. Polega ona na renegocjacji harmonogramu w zamian za solidne obniżenie ceny lub przekazanie pełnych praw autorskich do kodu źródłowego na każdym etapie prac. Z tego powodu, obecność prawnika w rozmowach z dostawcą zmienia dynamikę relacji. Przestaje to być rozmowa o technologii, a zaczyna o odpowiedzialności kontraktowej. Mediacja prowadzona przez neutralną stronę może uratować projekt, ale wymaga odwagi do przyznania się do błędów nawet przez obie strony. W sporach B2B czas to kapitał, każda godzina przestoju systemu to realna strata, dlatego szybka, nawet częściowa ugoda, bywa lepsza niż wywalczony wyrok za trzy lata.
Jak wygrać starcie z nierzetelnymi programistami?
Proces sądowy w sprawach IT to bitwa na opinie biegłych, dlatego bardzo ważne jest sformułowanie precyzyjnych pytań do eksperta, które wykażą obiektywne wady produktu, a nie tylko niezadowolenie klienta. Sąd nie zna się na kodowaniu, on ocenia, czy dzieło zostało wykonane zgodnie z umową, dlatego to jakość Twojego kontraktu i raportów z testów akceptacyjnych decyduje o wyniku.
Przygotowanie pozwu musi być poprzedzone audytem prawno-informatycznym. Trzeba precyzyjnie określić roszczenie: czy żądasz zwrotu całości wpłaconych środków (odstąpienie od umowy), czy odszkodowania za nienależyte wykonanie (np. pokrycie kosztów poprawy systemu przez inną firmę). W sporach dużą rolę odgrywa dowodzenie z dokumentacji projektowej. Jeśli w toku wdrożenia akceptowałeś etapy prac bez zastrzeżeń, Twoja droga do odzyskania pieniędzy jest znacznie trudniejsza. Dlatego tak ważne jest rygorystyczne podchodzenie do protokołów odbioru. W przeciwieństwie do standardowych sporów o zapłatę, tutaj biegły sądowy z zakresu informatyki będzie wyrocznią.
Twoja checklista ratunkowa
Jeśli Twój projekt IT stoi w miejscu, a pieniądze znikają, nie czekaj na cud ze strony dostawcy. Czas działa na korzyść, ale niestety tych nierzetelnych firm.
Zabezpiecz komunikację: Ściągnij historię z komunikatorów i systemów do zarządzania zadaniami.
Wykonaj audyt: Zatrudnij niezależnego eksperta, który oceni stan kodu.
Wypowiedz umowę z głową: Zrób to w sposób, który nie pozbawi Cię praw do tego, co już zostało stworzone.
Uderz prawnie: Wyślij wezwanie do zapłaty przygotowane przez specjalistów od sporów IT.
