Mity i legendy świata umów wdrożeniowych

Przedmiotem tego artykułu nie jest strona biznesowa wdrożeń informatycznych, nie będę zatem próbował odpowiadać na pytania w rodzaju: "Jak rozpoznać potrzeby klienta i jak prawidłowo wdrożyć system, którego klient oczekuje?". Zamierzam natomiast odpowiedzieć na pytanie: "W jaki sposób napisać dobrą umowę wdrożeniową i czy w ogóle jest to możliwe?"

Przedmiotem tego artykułu nie jest strona biznesowa wdrożeń informatycznych, nie będę zatem próbował odpowiadać na pytania w rodzaju: "Jak rozpoznać potrzeby klienta i jak prawidłowo wdrożyć system, którego klient oczekuje?". Zamierzam natomiast odpowiedzieć na pytanie: "W jaki sposób napisać dobrą umowę wdrożeniową i czy w ogóle jest to możliwe?"

Jak doskonale wiadomo, umowy pisane są "na złe czasy". Wszelkie zabezpieczenia, kary umowne, ograniczenia odpowiedzialności itp. zapisywane są zazwyczaj wyłącznie "na wszelki wypadek". Regułą jest, że jeżeli obie strony umowy współpracują dochowując przy tym elementarnej staranności, realizacja umowy przebiega gładko, a w umówionym terminie zamawiający czy też kupujący dostaje to, co zamówił, to nikt nie sięga do kar umownych, nie nalicza odszkodowań, ani nie żąda dodatkowych pieniędzy. Wyjątkiem są umowy, których przedmiotem jest wdrożenie systemów informatycznych. Zazwyczaj prędzej czy później okazuje się, że dostawca dostarcza wadliwy produkt i nie dotrzymuje umówionych terminów, a zamawiający musi dołożyć do pierwotnego budżetu dodatkowe pieniądze. W tym momencie obie strony sięgają po umowy i zwracają się do swoich prawników z nieśmiertelnym pytaniem: kto jest winny? Prawnicy albo nie wiedzą, co odpowiedzieć, albo udzielają odpowiedzi wysoce niesatysfakcjonującej dla klienta, a zaczynającej się od "to zależy…". Nasuwa się zatem pytanie: co jest przyczyną takiego stanu rzeczy? Oczywiście przedmiotem tego tekstu nie jest strona biznesowa wdrożeń informatycznych, nie będę zatem próbował odpowiadać na pytania w rodzaju: "Jak rozpoznać potrzeby klienta i jak prawidłowo wdrożyć system, którego klient oczekuje?". Zamierzam natomiast odpowiedzieć na pytanie: "W jaki sposób napisać dobrą umowę wdrożeniową i czy w ogóle jest to możliwe?".

Krótka wersja odpowiedzi jest taka: nie istnieje coś takiego, jak doskonała umowa wdrożeniowa, ponieważ żaden inżynier, informatyk czy handlowiec nie jest w stanie w momencie zawierania umowy opisać dokładnie systemu, który powstanie w wyniku realizacji umowy. Po pierwsze, w większości przypadków szczegółowy opis systemu będzie tworzony dopiero w czasie realizacji umowy. Po drugie, nawet w maksymalnie szczegółowej analizie funkcjonalnej czy projekcie technicznym niejednokrotnie znajdą się zapisy pozostawiające pole do interpretacji. Nie bez znaczenia jest też powszechna skłonność zamawiających do nadmuchiwania zakresu wdrożenia oczekiwaniami, które przyszły im do głowy już po zaakceptowaniu analizy systemowej (przy czym w takich przypadkach dostawca zazwyczaj słyszy, że "to przecież jest oczywiste, że taka funkcjonalność musi być w systemie i wcale nie trzeba było o tym pisać").

W tłumaczeniu na język prawnika powyższe wątpliwości oznaczają tyle, że w 99% umów wdrożeniowych nie ma w pełni zdefiniowanego zakresu zobowiązań stron. Pozostały 1% "wdrożeń" to instalacja systemu operacyjnego Windows na pojedynczych komputerach. Skoro zaś nie ma precyzyjnie opisanej kwestii tak elementarnej jak przedmiot umowy, to jest naturalne, że w toku realizacji umowy powstają pytania, na które nie ma dobrych odpowiedzi. No bo jak prawnik ma odpowiedzieć na pytanie: "Czy należy się klientowi kara umowna w związku z niewykonaniem w terminie danej funkcjonalności?", skoro nie wiadomo, czy funkcjonalność ta w ogóle miała zostać wykonana? Zarówno dostawcy, jak i ich klienci przeważnie zdają sobie sprawę z tego problemu, ale nie nazywają go po imieniu i usiłują stosować do wdrożeń systemów informatycznych przepisy, które nie do końca się do tego nadają, wymyślając przy tym konstrukcje prawne, które w świetle obowiązujących przepisów nie mają prawa zadziałać. Świat umów wdrożeniowych dorobił się w związku z tym swoistych mitów i przesądów. Ponieważ spotykam się z nimi nagminnie i zapewniam, że ogromnie utrudniają one życie prawnikom i negocjatorom, postanowiłem rozwiać niektóre z nich.

MIT PIERWSZY: Odbiory jednostronne

Jak wiadomo, jednym z najstraszliwszych koszmarów obydwu stron umowy wdrożeniowej jest sen o odbiorach, a zwłaszcza o testach prowadzonych przez użytkowników. Odbiór jest bowiem tym momentem, w którym najczęściej okazuje się, że to, co zostało wykonane, nie jest tym, czego oczekiwał klient. Niezależnie od tego, czy klient ma rację czy nie, jego standardową reakcją na taki problem jest odmowa podpisania protokołu odbioru systemu lub jego części. Ponieważ zaś w umowie zapisano, że bez podpisanego obustronnie protokołu nie można wystawić faktury VAT, dostawca ma problem z uzyskaniem zapłaty za wykonany system. Aby jakoś zneutralizować problem, dostawcy walczą jak lwy o wpisywanie do umów klauzul sprowadzających się do stwierdzenia, że jeżeli zamawiający bez powodu odmówi podpisania protokołu odbioru, to dostawca może wystawić tzw. protokół jednostronny i na jego podstawie żądać zapłaty. Pech polega na tym, że ów "protokół jednostronny" nie ma żadnego znaczenia prawnego ani jakiegokolwiek waloru poza czysto psychologicznym. Zamawiający nie będzie zobowiązany do zapłaty tylko dlatego, że dostawca dostarczył mu jednostronny protokół, czyli własne oświadczenie co do wykonania umowy.

Patrząc na to z drugiej strony, brak zapisu o protokole jednostronnym w żaden sposób nie uniemożliwia dostawcy domagania się zapłaty za należycie zrealizowane prace. Prawo cywilne jest bowiem - w tym akurat zakresie - boleśnie proste. W największym uproszczeniu Kodeks cywilny mówi tak: jeżeli wykonałeś świadczenie, do którego byłeś zobowiązany, to twój kontrahent ma obowiązek wykonać swoje świadczenie (wzajemne). Innymi słowy, jeżeli wykonałeś system zgodnie z umową, to możesz żądać zapłaty. Jeżeli klient zapłacić nie chce, możesz go pozwać o zapłatę. Jeżeli klient nie chce zapłacić, ponieważ uważa, że system jest źle wykonany, to oczywiście też go możesz pozwać, przy czym niestety będziesz musiał bronić się w sądzie przed zarzutem niewykonania zobowiązania. Tak czy inaczej, możliwość domagania się zapłaty wynika wyłącznie z faktu wykonania zobowiązania, a nie z tego, czy zostało to potwierdzone jakimkolwiek dokumentem. Na marginesie wypada przypomnieć, że identycznie podchodzi do sprawy ustawa o VAT: obowiązek podatkowy powstaje, co do zasady, w momencie faktycznego wykonania świadczenia, a nie z chwilą potwierdzenia wykonania przez drugą stronę transakcji. Powstaje więc pytanie, czy dostawcy powinni walczyć o protokoły jednostronne? Odpowiedź jest typowo prawnicza: to zależy. Zależy od tego, jaka jest sytuacja negocjacyjna i jaki jest kontrahent. W skrajnie sformalizowanych, dużych strukturach walka o protokół jednostronny ma dla dostawcy sens o tyle, że taki protokół, jeżeli jest wyraźnie opisany w umowie, może czysto faktycznie ułatwić uzyskanie zapłaty. Sama umowna możliwość "wystawienia" takiego protokołu może być motywująca dla strony ociągającej się z odbiorem. Nie warto jednak za protokół jednostronny umierać. Jeżeli klient stawia twarde veto, to należy pamiętać, że brak upragnionego zapisu o protokole jednostronnym nie uniemożliwia dostawcy żądania zapłaty za należycie wykonane prace. Należy też pamiętać, że protokołem jednostronnym dostawca nie jest w stanie wykonać żadnej "sztuczki" umożliwiającej uzyskanie zapłaty, jeżeli swoje zadanie wykonał nienależycie, bowiem w wypadku niewykonania zobowiązania zamawiający nie jest zobowiązany do zapłaty nawet wówczas, gdy otrzyma dziesięć protokołów jednostronnych. Prawdę powiedziawszy, zamawiający w takiej sytuacji nie będzie zobowiązany do zapłaty nawet wówczas, gdy sam podpisze protokół, z którego będzie wynikać, że wykonano zobowiązanie, którego nie wykonano. O czym za chwilę.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200