Mity umów wdrożeniowych. Mit 2 – odbiór końcowy końcem problemów

Jak wiadomo, zasadniczym celem każdego kierownika projektu jest doprowadzenie do szczęśliwego podpisania przez zamawiającego protokołu odbioru końcowego. Z niejasnych przyczyn większość dostawców systemów informatycznych uznaje, że jeżeli uda im się przekonać kontrahenta do złożenia podpisu na dokumencie potwierdzającym zakończenie realizacji umowy, to uzyskują tym samym niepodważalny dowód wywiązania się z umowy. Zła wiadomość jest taka, że wspomniana większość się myli.

Oczywiście podpisanie odpowiedniego protokołu jest istotnym zdarzeniem, ponieważ zazwyczaj oznacza uzyskanie dokumentu umożliwiającego domaganie się wynagrodzenia za wykonane prace, jest to jednak zdarzenie o charakterze czysto proceduralnym, a sam dokument ma jedynie walor dowodowy.

Jeżeli po „pozytywnym odbiorze końcowym” okaże się, że system nie spełnia któregoś ze zdefiniowanych umową wymagań, to nie oznacza to jeszcze, że klient automatycznie z tego wymagania rezygnuje. Trzeba pamiętać, że ocenie podlega stan faktyczny, a nie stan utrwalony w dokumentach – jeżeli zgodnie z umową ma zostać dostarczonych np. 6 serwerów, w rzeczywistości zostało dostarczonych 5, a klient podpisał protokół odbioru, z którego wynika, że otrzymał 6 urządzeń, to nie oznacza to, że umowa została należycie wykonana. W podanym powyżej przykładzie klient będzie miał roszczenie o dostarczenie szóstego serwera, choćby cały zarząd własną krwią podpisał się na protokole potwierdzającym odbiór sześciu sztuk. Umowa została bowiem wykonana nienależycie i klient może w związku z tym domagać się jej wykonania oraz naprawienia powstałej szkody (w tym może naliczyć kary umowne za zwłokę, o ile zostały one przewidziane na okoliczność nie dostarczenia w terminie całości sprzętu).

Powyższa sytuacja jest dość jednoznaczna, ale zasada oceniania faktów, a nie rzeczywistości papierowej, działa także w przypadku bardziej złożonych stanów faktycznych. Jeżeli klient potwierdził odbiór systemu, a np. miesiąc po odbiorze ujawniły się jego wady, to wykonawca będzie zobowiązany do ich usunięcia na jednej z kilku możliwych podstaw (w zależności od treści umowy, np. na podstawie przepisów o rękojmi lub o gwarancji), a także będzie odpowiedzialny za szkodę poniesioną przez klienta wskutek nienależytego wykonania umowy. Ponieważ doskonale wiadomo, że żaden system informatyczny nie jest wolny od wad, trzeba taką okoliczność uwzględniać w umowie. Wskazane jest określanie dopuszczalnego poziomu błędów i takie definiowanie treści zobowiązań, żeby nie narazić się na wielomilionowe odszkodowanie w związku z zawieszeniem się systemu pół roku po jego odbiorze… Wskazane jest oczywiście także tworzenie systemów, które się nie wieszają, ale jak na razie bardziej prawdopodobne jest chyba oswojenie klientów z myślą, że nie dostaną nigdy doskonałego i całkowicie pozbawionego błędów produktu informatycznego.

W następnym odcinku mit 3 – nie ma kar, nie ma problemu