MIT DRUGI: Odbiór końcowy końcem problemów

Jak wiadomo, zasadniczym celem każdego kierownika projektu po stronie dostawcy 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. Mam złą wiadomość dla wykonawców: wspomniana powyżej większość się myli. Oczywiście, podpisanie odpowiedniego protokołu jest istotnym zdarzeniem, gdyż 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ń, 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. sześć serwerów, a w rzeczywistości zostało dostarczonych pięć i klient podpisał protokół odbioru, z którego wynika, że otrzymał sześć urządzeń, 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, co oznacza między innymi, że może naliczyć kary umowne za zwłokę, o ile zostały one przewidziane na okoliczność niedostarczenia w terminie całości sprzętu. Powyższa sytuacja była oczywiście dość jednoznaczna, jednak trzeba pamiętać, że 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. w ciągu miesiąca 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 tę okoliczność uwzględniać w umowie. Z punktu widzenia dostawcy wskazane jest określanie dopuszczalnego poziomu błędów i takie definiowanie treści zobowiązań, by nie narazić się na wielomilionowe odszkodowanie w związku z zawieszeniem się systemu pół roku po jego odbiorze. Wskazane jest oczywiście również tworzenie systemów, które się nie zawieszają...

MIT TRZECI: Nie ma kar, nie ma problemu

Dostawca systemu informatycznego nie jest zazwyczaj zdziwiony, jeżeli klient życzy sobie zawarcia w umowie zapisów określających kary umowne za niewykonanie poszczególnych zobowiązań. Pozwalam sobie przypomnieć, że kara umowna jest zryczałtowanym odszkodowaniem, przy czym po długich dyskusjach i sprzecznych wyrokach Sądu Najwyższego uznano ostatecznie, że dla dochodzenia kary umownej nie jest w ogóle konieczne wyrządzenie szkody. Wystarczy, że dostawca nienależycie wykona zobowiązanie i tylko ten fakt musi być wykazany przez klienta. Jest to więc skuteczny i czytelny mechanizm umożliwiający dyscyplinowanie wykonawców i ułatwiający klientom dochodzenie zapłaty "rekompensaty" w wypadku nienależytego wykonania umowy. Ponieważ rynek lubi rozwiązania proste i pewne, kary umowne stały się w większości umów standardem. To z kolei powoduje, że coraz częściej kary są uznawane za podstawowe lub nawet jedyne ryzyko związane z realizacją umowy. Poniżej przedstawiam nieznacznie uproszczony fragment negocjacji umowy o wdrożenie dość dużego systemu informatycznego:

Klient: Niezależnie od odrębnie płatnego serwisu, oczekujemy gwarancji na system.

Dostawca: Oczywiście, udzielamy gwarancji.

K: Oczekujemy dla błędu krytycznego czasu reakcji nie dłuższego niż godzina i czasu naprawy nie dłuższego niż 5 godzin od momentu zgłoszenia błędu.

D: OK.

K: Proponujemy karę umowną za niedotrzymanie tych terminów w wysokości 0,1% wartości umowy za godzinę zwłoki.

D: No to nie możemy zgodzić się na takie czasy reakcji i naprawy.

K: A jak nie będzie kary?

D: To się zgadzamy.

Trzeba jeszcze dodać, że prawnik dostawcy zapytał go, czy rzeczywiście chce on przyjąć tak krótkie terminy, na co uzyskał odpowiedź brzmiącą: "A co mi zrobią, skoro nie ma kar?". Student trzeciego roku prawa po usłyszeniu powyższego dialogu powinien powiedzieć, że dostawca prawdopodobnie strzelił sobie w stopę. Student wie bowiem (a w każdym razie powinien wiedzieć), że brak kary umownej nie oznacza braku odpowiedzialności za niewykonanie zobowiązania. Kodeks cywilny traktuje karę jako postanowienie dopuszczalne, ale jednocześnie jako wyjątek od ogólnej zasady, zgodnie z którą dłużnik jest zobowiązany do naprawienia pełnej szkody wynikłej z nienależytego wykonania zobowiązania. System informatyczny przeważnie wdrażany jest w celu usprawnienia lub umożliwienia realizacji konkretnych procesów biznesowych. Awaria krytyczna systemu, definiowana przeważnie jako niemożność wykorzystania jego zasadniczej funkcjonalności, może oznaczać poniesienie przez klienta gigantycznych szkód nawet w przypadku jednej godziny trwania awarii (dotyczy to zwłaszcza systemów obsługujących instytucje finansowe). W podanym przykładzie dostawca musi się więc liczyć z tym, że jeżeli nie uda mu się dochować restrykcyj-nego terminu naprawy i jeżeli spóźni się np. o pół godziny, będzie to ozna-czało nienależyte wykonanie zobo-wiązania. Jeżeli więc przez pół godzi-ny system nie działa i nie obsługuje transakcji, na których klient mógł zarobić 20 mln zł, to dostawca będzie zobowiązany do zapłaty odszkodowania w wysokości 20 mln zł… Rzecz niby oczywista, ale coraz częściej się o niej zapomina.

MIT CZWARTY: Bo jak sobie kupuję samochód...

Zalecaną w podręcznikach i często stosowaną w negocjacjach metodą jest porównanie. Chyba każdy negocjator pracujący dla branży IT usłyszał przynajmniej kilka razy przemowę zaczynającą się od: "A jak sobie Pan kupuje samochód…" albo: "Czy jeżeli zlecam wykopanie rowu…". Zazwyczaj po wygłoszeniu takich analogii przedstawiciele klienta, upojeni własną erudycją i fantazją, rozsiadają się wygodnie w fotelach i patrzą z wyższością na przedstawicieli dostawcy, którzy gorączkowo usiłują wymyślić jakieś trafne porównania do wdrożenia systemu informatycznego. Rozmowy zaczynają się więc toczyć o telewizorach, pralkach, domach i wszystkim, z czym negocjatorzy klienta mają kontakt na co dzień. Na początku mojej kariery w charakterze prawnika dostawców skupiałem się głównie na odbijaniu argumentów i walce tą samą bronią ("Ale jak Pan nie napisał, że ma być skórzana tapicerka, to skąd ja mam wiedzieć, że welurowa nie może być i dlaczego nie możemy podpisać protokołu odbioru?"). Z biegiem lat zaczął narastać we mnie bunt. Problem polega bowiem na tym, że analogie do sprzętów AGD i innych przedmiotów codziennego użytku są bardzo wygodne dla klientów, ale w większości przypadków są kompletnie chybione. Specyfika systemu informatycznego jest zupełnie inna niż specyfika telewizora czy samochodu. Prawo cywilne, które jest przyzwyczajone do regulowania obrotu prawami do przedmiotów "standardowych", nie zawsze pasuje do obrotu produktami informatycznymi. Klient nie bierze udziału w wyprodukowaniu pralki, samochodu czy telewizora.