5. Lista klauzul kluczowych i dbanie o ich precyzyjny zapis

Cały wysiłek analityczny (a przecież prawo to tylko jeden z elementów) może na nic się nie przydać, jeśli nie zapiszemy go w twardych, zrozumiałych i jednoznacznych klauzulach. Duża część zamawiających przecenia dobre scenariusze, nie docenia złych. Zamawiający wierzy wykonawcy, wykonawca wierzy, że będzie dobrze. Skrajnym przypadkiem jest akceptacja oferty i wzorca wykonawcy bez wprowadzania zmian - totalne zaufanie i totalne rozczarowanie (niekoniecznie zresztą z winy wykonawcy, jak się nie ma okazji omówić specyfiki projektu i zagrożeń, to często dwie strony zupełnie inaczej rozumieją zapisy umowy).

Nie wierzmy słownym deklaracjom, naszym uczuciom ani kodeksom - zapiszmy jasno, co chcemy. I pamiętajmy, że nawet jak napiszemy wyśmienity system kar umownych, będzie on funta kłaków wart, jeśli nie będzie wiadomo w jakiej sytuacji go stosować - tu kłania się wiele umów SLA, które de facto oznaczają bezkarność wykonawcy i faktyczną niemożliwość wykazania mu niedopełnienia warunków umowy. Precyzja, precyzja, precyzja, często przy pomocy standardowych metodyk usługowych czy projektowych.

6. Realne wymagania

Mimo kluczowego znaczenia IT we współczesnym biznesie, z reguły nie negocjujemy kontraktów na zapewnienie bezpieczeństwa energetycznego państwa ani sterowanie pociskami patriot. Dostępność 99,99% jest miła, ale rzadko kiedy krytycznie potrzebna. Jeżeli zażądamy zbyt wiele (słynna gwarancja na zero martwych pikseli w monitorach LCD na pięć lat, wymóg bodajże z 2002 r.) skończymy z absurdalną ceną, albo - co częściej - z takimi zapisami, które pozwolą wykonawcy "rozmydlić" przedmiot umowy.

Podobnie z karami umownymi - możemy teoretycznie wymusić milion złotych za każdy dzień zwłoki, ale wtedy wysiłek wykonawcy idzie w udowodnienie, że zwłoki nie było (przecież to wina zamawiającego), a nie w kontynuację projektu (z prawnego punktu widzenia lepiej czasami wadliwej procedury nie naprawiać, gdyż naprawa może być przyznaniem się do błędu). A wykonawca z reguły jest znacznie lepszy w procesie dokumentacji i udowadnianiu, kto kiedy nienależycie wykonał swoje obowiązki.

7. Realnie, nie znaczy łagodne

Najgorsza umowa, to taka, którą opłaca się nie wykonywać. Albo wprost (np. bardzo niski poziom kar umownych, bez innych mechanizmów odpowiedzialności), albo pośrednio - czyli wszystko OK, chyba że zawali się inny projekt i wykonawca przerzuci tam (bezkarnie) swoje siły. To wymaga m.in. precyzyjnego SLA (nigdy za dość precyzji, parametr "dostępność" nie mówi nic, "obejście" też niewiele - w znanym mi przypadku, w ramach obejścia, dostawca kazał wystawiać faktury ręcznie), progresywnych, odczuwalnych kar (a nie obniżenia ceny), rozsądnych limitów odpowiedzialności i...

8. Możliwość zmiany dostawcy

Często to fikcja, ale warto spróbować tak konstruować umowy, żeby w razie czego była ona rzeczywistą, choć bolesną, alternatywą. Dróg do tego jest wiele, od reguł wypowiadania umowy, poprzez kontrolę praw do stworzonego oprogramowania, po wyrafinowane metody zarządzania dostawcą (wraz z prawem przejęcia kontraktów podwykonawczych). Tak na marginesie - o prawach autorskich jeszcze się pamięta (acz często nieskutecznie zapisuje), ale co z bazami danych, know how, domenami, danymi osobowymi, a czasem i wzorami przemysłowymi czy patentami? To powinno być uregulowane, inaczej powoduje monopolizację pozycji dostawcy. Czysto prawnicza praca o nadzwyczaj doniosłych skutkach.

9. Opis jak to działa - procesy, zarządzanie zmianą, testy i odbiory...

Umowa to nie tylko prawnicze punkty, to dokładnie opisane zasady jej wykonywania. Pamiętajmy, że jak ich nie opiszemy, mamy problem - przepisy nam nie wystarczą. Nie pomogą też "ustalone zwyczaje", gdyż ich brak. Poza tym takimi punktami, często pomijanymi przez doradców prawnych, można skutecznie "rozwodnić" i przedmiot umowy, i SLA, i zasady odpowiedzialności. Nie wierzmy w konieczność "scenariuszy testowych" jako wyłącznej drogi do weryfikacji prac, nie przeceniajmy roli protokołów odbioru, jeżeli chcemy trzymać się ITIL, dostosujmy umowę do tego standardu (np. poprzez definicje). Dbajmy o odpowiednie uprawnienia dla zespołu wdrożeniowego, żeby każda zmiana nie wymagała uchwały zarządu, ale z drugiej strony, żeby kierownik umowy nie mógł jej samodzielnie wypowiedzieć (bywało). Tysiące drobnych kwestii, które mogą ułatwić lub utrudnić codzienną współpracę.

10. Skupmy się na procesach i konsekwencjach rozwiązania umowy

Pod koniec negocjacji mało kto ma już siły opisywać takie zjawisko, a są to zagadnienia pierwszorzędne dla zamawiającego. Często okazuje się, że umowy nie da się rozwiązać. A klauzule o prawie do "natychmiastowego" wypowiedzenia to zupełne science fiction. Dostawca ma nasze dane, przy outsourcingu naszego oprogramowania, nasz biznes jest uzależniony od zewnętrznej usługi. Sama relokacja zasobów sprzętowych może zając tygodnie, a proces przejmowania oprogramowania (także tych dziesiątek drobnych modyfikacji na naszym systemie) może wymagać zgody osób trzecich i dodatkowych płatności. Problemy sprawia też procedura wyłaniania nowego dostawcy (zwłaszcza w zamówieniach publicznych). Krótki okres wypowiedzenia to nie zaleta dla zamawiającego, a duże niebezpieczeństwo.

I jeszcze jedna uwaga na koniec - nie zostawiajmy prawników samym sobie, a zespołów merytorycznych bez prawników. Można napisać umowę czysto prawniczą bez udziału biznesu, ale za wyjątkiem standardowych kontraktów, będzie to tekst oderwany od rzeczywistości, choć czasem nawet ładnie napisany. Można też pisać umowy bez prawników, ale bez złudzeń - 5 lat studiów, 3 lata aplikacji i szereg lat praktyki ciągnie za sobą pewną wiedzę. Nie ma szans, aby biznes przewidział wszystkie konsekwencje prawne (w 9 na 10 wypadkach źle konstruuje klauzule autorskie, podobnie z zasadami rozwiązywania umowy). Prędzej czy później rachunek wyniesie więcej niż stawki nawet bardzo szacownych kancelarii - tak swoją drogą, jak tylko możemy, bierzmy prawników "z branży" (w IT pierwszoplanowe jest doświadczenie) i umawiajmy się na ryczałt - ci, co przeżyli odpowiednią ilość umów, wiedzą jak je wyceniać.

Marcin Maruta jest wspólnikiem kancelarii radców prawnych Kuczek-Maruta.