Lepiej zapobiegać, niż leczyć – mówi stare porzekadło. Remedium na większość konfliktów, do jakich dochodzi między zamawiającym a wykonawcą, jest dobrze napisana, skrojona pod potrzeby obu stron umowa. Aby zminimalizować ryzyko pata w przyszłości, w kontrakcie powinny zostać uwzględnione określone zagadnienia. Omawiamy je w tym artykule.

Niezależnie od tego, czy chodzi o zamówienie u wykonawcy dedykowanego oprogramowania z usługą jego wdrożenia, czy przedmiotem umowy ma być skomplikowany sprzęt o unikatowych cechach, punktem wyjścia do ustalenia szczegółów współpracy powinno być drobiazgowe opisanie cech i funkcji rozwiązania. Opis przedmiotu zamówienia powinien określać m.in.:

do czego ma służyć oprogramowanie lub sprzęt (za co ma odpowiadać w przedsiębiorstwie)?
w jakie funkcjonalności i moduły ma być wyposażony?
w przypadku oprogramowania – z jakim oprogramowaniem i sprzętem istniejącym ma być kompatybilne?
w przypadku sprzętu – jakie ma mieć parametry?
czy rozwiązanie ma być kompatybilne z innymi już wdrożonymi w firmie?
jaka powinna być jego wytrzymałość (z jaką ilością danych ma sobie poradzić lub z jakiej wielkości linią produkcyjną)?
czy rozwiązanie ma być skalowalne?
jaka ma być perspektywa rozwoju rozwiązania oraz możliwych jego modyfikacji?

Równie ważne są poziomy zabezpieczeń w oprogramowaniu, wygląd i wymiary sprzętu, liczba pracowników potrzebnych do jego obsługi czy szczegóły licencji lub ograniczeń prawnych dotyczących danego rozwiązania. Przywiązanie do detali sprzyja obu stronom – wykonawca dokładnie wie, co ma zostać stworzone, a zamawiający może być pewny, że w razie nieosiągnięcia przez rozwiązanie wymaganych parametrów będą mu przysługiwać roszczenia o doprowadzenie zamówienia do stanu wymaganego umową. Co równie ważne, taka praca wymaga często zewnętrznego konsultanta albo zatrudnienia specjalisty w danej dziedzinie. Pozwala to uniknąć sytuacji, gdy zamawiającemu jedynie wydaje się, że wie i rozumie, co zamawia albo gdy obie strony inaczej interpretują zakres zamówienia. W takim przypadku spór jest jedynie kwestią czasu.

Metodyka pracy i zasady współpracy stron

Po opisaniu potrzeb przychodzi czas na dobranie przez wykonawcę odpowiedniej metodyki pracy oraz określenie, jaką rolę w procesie tworzenia i wdrożenia nowego rozwiązania ma mieć zamawiający. Dochodzenie do efektu końcowego jest procesem, a niektórzy klienci chcą w tym procesie aktywnie uczestniczyć.

Przed podpisaniem umowy należy określić, czy testowanie rozwiązania ma nastąpić dopiero po zakończeniu pracy nad nim, czy kilkukrotnie na etapie jego rozwijania. Jeśli mamy do czynienia z tworzeniem dedykowanego sprzętu lub oprogramowania, zamawiający będzie prawdopodobnie oczekiwał możliwości zgłaszania uwag i poprawek. Dobrze jest jeszcze przed zawarciem umowy określić, ile będzie miał na to czasu i jakiego rodzaju mogą to być poprawki. Warto mieć na względzie, że zgłaszanie uwag, które zmierzają do rozbudowy rozwiązania względem pierwotnie opisanego przedmiotu zamówienia może doprowadzić do zwiększenia kosztów wykonania rozwiązania i wydłużenia czasu jego realizacji – a to już dwa potencjalne zapalniki w relacjach między kontrahentami.

W przypadku budowy oprogramowania niezbędnym elementem umowy jest określenie, jaką metodą będzie ono opracowywane – czy będzie to metoda tradycyjna, tzw. kaskadowa, czy metoda zwinna. W największym uproszczeniu tę pierwszą cechuje większe uporządkowanie, strony muszą włożyć więcej pracy w opisanie przedmiotu umowy, a koszt takiego rozwiązania bywa droższy, ale co do zasady pozostaje niezmienny. Ta druga zakłada większą elastyczność, strony dopiero w toku wykonywania umowy w kolejnych sprintach dochodzą do ostatecznego kształtu wdrażanego rozwiązania, co może być tańszym rozwiązaniem w ofertowaniu, ale też wiąże się z otwartym budżetem końcowym projektu. Wybór metody wpływa na budżet projektu i liczebność angażowanego po stronie wykonawcy zespołu, dlatego powinien być dokonywany świadomie. Nie należy także lekceważyć ustalenia przez strony poziomu zaangażowania przedsiębiorcy, który zamawia dane rozwiązanie. Wskazane jest określenie:

czy w trakcie pracy zamawiający powinien przekazać wykonawcy jakieś niezbędne szczegóły, dokumenty, materiały?
czy wykonawca ma pracować nad rozwiązaniem w infrastrukturze zamawiającego?
czy będą potrzebne wizyty u zamawiającego, dostęp do innych sprzętów i już działającego w jego przedsiębiorstwie oprogramowania?
jak wdrożenie może wpływać na bieżące funkcjonowanie zamawiającego?

Odpowiedzenie sobie na wszystkie te pytania zwiększy komfort współpracy po obu stronach.

Wycena i harmonogram

Dopiero po ustaleniu wymienionych szczegółów strony mogą w sposób świadomy ocenić koszt wdrożenia opisanego rozwiązania i czas potrzebny na jego instalację w przedsiębiorstwie. Jeżeli ma dojść do częściowych wdrożeń, strony powinny stworzyć ich terminarz. Świadomość wzajemnych obowiązków jest kluczowa, żeby uniknąć przyszłych problemów. Harmonogram (szerszy niż termin wykonania wdrożenia) i zasady oraz okoliczności, w jakich może być modyfikowany są kluczowe, zwłaszcza jeśli w projekt zaangażowany jest więcej niż jeden dostawca (np. w powstającym magazynie jeden wykonawca realizuje prace wdrożeniowe z zakresu automatyzacji, a inny montuje regały magazynowe).

Dlaczego to takie ważne?

Jednymi z podstawowych zarzutów spotykanych w sporach sądowych są te wynikające z rozminięcia się oczekiwań z rzeczywistością. Poniżej prezentujemy kilka przykładów sytuacji konfliktowych spowodowanych w dużej mierze (jeśli nie wyłącznie) nieprecyzyjnymi postanowieniami umowy.

Przykład 1

Umowa zawiera bardzo ogólny opis zamówienia i lakoniczny opis metody pracy. Na prośbę zamawiającego rozwijane są poszczególne elementy zamówienia. Po realizacji pracy wykonawca twierdzi, że stworzone przez niego dzieło zapewnia znacznie szersze funkcjonalności niż te, na które umówił się z zamawiającym. Oczekuje podwyższenia wynagrodzenia, ponieważ to ustalone w umowie nie pokrywa nawet kosztów wykonania dzieła. Zamawiający twierdzi natomiast, że od początku było dla niego jasne, że strony umówiły się na osiągnięty finalnie efekt końcowy i odmawia dopłaty.

Przykład 2

Umowa zawiera bardzo ogólny opis zamówienia i lakoniczny opis metody pracy, ale dochodzi do sytuacji odwrotnej niż w przykładzie 1. Zamawiający zgłasza uwagi do dzieła, twierdząc, że nie spełnia ono jego oczekiwań – rozwiązanie nie ma wszystkich funkcjonalności, na które strony się umówiły. Wykonawca odmawia rozbudowy rozwiązania, według niego dzieło jest kompletne i w ramach ustalonej pierwotnie ceny nie zamierza wykonać dla zamawiającego dodatkowych prac.

Przykład 3

Strony nie określiły metodyki pracy nad oprogramowaniem. W połowie realizacji projektu zamawiający zwraca się do wykonawcy z prośbą o przedstawienie dotychczasowych efektów i zainstalowanie prototypu w przedsiębiorstwie. Wykonawca nie odmawia, jednak czas poświęcony na próbne wdrożenie nie był przewidziany w harmonogramie. Dochodzi do istotnego opóźnienia, co jest przedmiotem pretensji ze strony zamawiającego.

Sytuacje atypowe – czy można przewidzieć je w umowie?

Czasami sprecyzowanie wzajemnych oczekiwań i obowiązków nie wystarcza, by uniknąć konfliktu. Do sądów trafia wiele spraw związanych ze stwierdzeniem wad sprzętu lub oprogramowania, z opóźnień z winy którejś ze stron czy z niemożliwych do przewidzenia przeszkód. To te najtrudniejsze przypadki, gdzie umowa nie zapobiega sporom. Może jednak zawierać gotowe schematy rozwiązań dla danego typu problemu. W takim przypadku łatwiej jest przekonać do ugody stronę, która nie wykonała obowiązków – będzie ona zdawać sobie sprawę, że jej szanse na wygraną w sądzie przy takiej treści umowy są niewielkie. Przykłady takich sytuacji podajemy poniżej.

Przykład 1

Ujawnia się problem ze sprzętem lub oprogramowaniem. Z umowy wynika domniemanie, że problem z przedmiotem zamówienia wynika z wady, a ponadto sprecyzowane jest, w jakim czasie wykonawca jest zobowiązany zareagować i usunąć wadę. Jeśli po upływie czasu określonego konkretną datą wada nie jest usunięta, a wykonawca nie obalił domniemania, nie budzi wątpliwości, że naruszył on warunki umowy.

Przykład 2

Wykonawca spóźnia się z wykonaniem zamówionego sprzętu, ponieważ zbyt długo oczekiwał na zamówione materiały lub części potrzebne do jego budowy. W kontrakcie może być zapisane, że pozyskanie części jest wymagające czasowo i termin realizacji dzieła będzie liczony od daty ich dostawy, albo że zakup materiałów jest obowiązkiem wykonawcy i ewentualne problemy z tym związane nie mogą usprawiedliwiać opóźnienia w wykonaniu dzieła.

Przykład 3

Z powodu epidemii SARS-COV-2 doszło do zerwania łańcucha dostaw potrzebnych części, kluczowy personel wykonawcy trafił na dwa tygodnie na izolację albo ze względu na sytuację epidemiczną zamawiający nie mógł udostępnić wykonawcy siedziby swojego przedsiębiorstwa. Już od ponad roku w kontraktach dotyczących większych projektów uwzględniane są tego typu problemy i tworzone są alternatywne scenariusze działania. W takim przypadku często stosuje się przedłużenie terminu wykonania umowy, co rozwiewa wątpliwości odnośnie momentu, w którym wykonawca – odwlekając termin oddania dzieła – naruszył jej warunki.

Precyzja zapobiega sporom

W przypadku wdrażania w biznesie automatyki, robotyki czy szerzej pojmowanych innowacji bez wątpienia będą pojawiać się spory między stronami. Sprzyjają temu skomplikowanie techniczne materii oraz duże budżety przypisane do takich projektów. Niemniej jednak sporej ich części można uniknąć, uzgadniając pewne mechanizmy i precyzując prawa oraz obowiązki stron na etapie negocjowania i zawierania umów.

W kolejnym artykule odpowiemy na pytanie, co zrobić, kiedy zawarta umowa była niedoskonała, albo kiedy z powodu nieprzewidzianych okoliczności projekt nie zakończył się sukcesem.

Artykuł ukazał się na stronach 28 – 30 w Miesięczniku Automatyka, wydanie 4/2021. – https://automatykaonline.pl/Automatyka/Roczniki/2021/4-2021