Jak dążyć do jakości metodami prawnymi

Jako doradcę prawnego zawsze intrygowało mnie pytanie, do jakiego stopnia można zapisami umownymi wpłynąć na jakość implementacji rozwiązań IT.

Jako doradcę prawnego zawsze intrygowało mnie pytanie, do jakiego stopnia można zapisami umownymi wpłynąć na jakość implementacji rozwiązań IT.

Nienależyta jakość systemów IT ma i dobre strony, przynajmniej dla kancelarii prawnych. Jeżeli zastanowić się, jakie spory między firmami IT a klientami zdarzają się najczęściej i zajmują najwięcej czasu, okaże się, że na czołowym miejscu pojawi się zarzut "a miało być inaczej...". Zarzut ten, niezwykle pojemny, mieści w sobie błędy systemów operacyjnych, brak funkcjonalności w systemach ERP, nieudane czy nieterminowe wdrożenia oraz wiele innych zjawisk związanych ze złą jakością rozwiązań IT lub ich implementacji. Jako doradcę prawnego zawsze intrygowało mnie pytanie, do jakiego stopnia można zapisami umownymi wpłynąć na jakość implementacji rozwiązań IT. Odpowiedź nie jest oczywista.

Mimo wszystko trzeba skończyć

W "staroświeckim" pojmowaniu prawa wady towarów czy usług dyskwalifikowały sprzedawców i dostawców, wściekły klient zrywał współpracę, oddawał zepsute urządzenia i prędzej czy później uzyskiwał odszkodowanie. Lektura orzeczeń Sądu Najwyższego dotycząca wad małych fiatów może być pocieszająca dla zwolenników takiego pojmowania prawa. Większość tych spraw dotyczyła jednak stosunkowo prostych sytuacji czy rzeczy. W przypadku systemów IT polityka powyższa nie zdaje egzaminu - co prawda zarząd spółki, implementującej piąty rok z rzędu zintegrowany system finansowy, najchętniej zerwałby kontrakt i zbankrutował dostawcę, ale zdaje sobie doskonale sprawę, że rozpoczęte wdrożenie jest praktycznie nie do zatrzymania bez ponoszenia olbrzymich strat. Za plecami czekają właściciele, rada nadzorcza, niejednokrotnie opinia publiczna - w konsekwencji ogromny wysiłek jest wkładany w zawarcie ugody i wynegocjowanie zmiany zakresu czy czasu projektu. Rozwiązania ostateczne stosowane są rzadko.

Stąd zapewne bierze się determinacja wielu firm, aby podpisać kontrakt i martwić się dopiero jak powstaną kłopoty. Postępowanie takie jest jednak balansowaniem na krawędzi - co prawda w ogromnej większości przypadków udaje się coś na kształt ugody zawrzeć, ale rentowność projektu spada dramatycznie, a i pozycja u klienta nie zawsze się umacnia. Jeszcze gorzej jest po przekroczeniu krawędzi - w konsultingu doświadczył tego m.in. Artur Andersen, a i w IT podobne klęski się zdarzały. Może bez bankructw, ale z horrendalnymi odszkodowaniami, sporami i pretensjami, z ogłoszeniami prasowymi naruszającymi dobra osobiste zwaśnionych stron włącznie. A każda ze stron wynajmuje renomowane kancelarie, co wspomnianą rentowność dobija ostatecznie.

Lista grzechów głównych

Doprowadzenie do sporu nie jest trudne, czasami wręcz niewyobrażalnie łatwe. Można pokusić się o wymienienie kilku typowych grzechów głównych:

1 Brak wizji. Zaczyna się z reguły od braku świadomości klienta, co chce tak naprawdę nabyć, lub braku rozeznania potrzeb zamawiającego po stronie dostawcy. Zaskakująco wielu menedżerów jest przekonanych o konieczności "unowocześnienia" firmy czy zaletach "wdrożenia nowoczesnego systemu ERP", bez jakiejkolwiek wiedzy o narzędziach i zasadach działania systemów IT. Oszczędzanie na analizie potrzeb mści się szybko i skutecznie. Pewnym ratunkiem są doświadczone firmy IT, które pierwszy okres współpracy poświęcają na edukację klienta. W opisywanej sytuacji prawnicy są absolutnie niezbędni, ale w "negatywnym" znaczeniu - tylko ich doświadczenie w konstruowaniu umownych zabezpieczeń może uratować firmę IT przed odszkodowaniem, a klientowi pozwolić w miarę szybko i tanio wycofać się z projektu, który nie ma szans na powodzenie. Cały wysiłek idzie więc w opracowanie klauzul mających zabezpieczyć czy uchronić interesy klientów na wypadek - niemal pewnego - konfliktu. Jeżeli konflikt taki nie prowadzi do zerwania współpracy, prawnicy przydają się także do pisania kolejnych aneksów i porozumień.

2 Ogólna umowa, niesprecyzowany jej przedmiot i procedury współpracy. W Polsce obowiązują dwie szkoły: "amerykańska", nakazująca pisać niezwykle szczegółowe uregulowania umowne, gdzie zapisy o komitecie sterującym potrafią ciągnąć się i na dziesięć stron, oraz "kontynentalna", odsyłająca do kodeksu cywilnego i klauzul generalnych, regulująca tylko podstawowe kwestie (skrajnym przypadkiem w mojej karierze była umowa licencyjna i wdrożeniowa na 2,5 strony - wartość kontraktu ponad milion dolarów). Na rynku IT lepiej spisuje się pierwsza metodologia, w granicach rozsądku rzecz jasna (postanowienia o stosowaniu amerykańskich klauzul eksportowych są dyskusyjne). Wynika to ze sposobu interpretacji prawa - gdy brak regulacji w umowie, prawnicy sięgają do zapisów kodeksowych, zwyczaju i ustalonych standardów w branży. Kłopot w tym, że zapisy kodeksowe są niezwykle ogólne, a utrwalonych standardów i zwyczajów w branży IT brak, gdyż jest to stosunkowo młoda dziedzina biznesu. Szczegółowe uregulowania mają także dodatkową zaletę - w miarę wiernie przekazują wolę stron i utrudniają naciągane interpretacje. Wiadomo że w czasie skomplikowanych wdrożeń dochodzi nawet do kilkakrotnej zmiany zarządów i koordynatorów - dobrze napisana umowa jasno wskazuje na zakres obowiązków stron i uzgodnione procedury.

Niezbędny jest także dobrze opisany przedmiot umowy - rzecz niby oczywista, a powszechnie zbyt ogólnie zapisywana. Klauzule takie decydują wielokrotnie o powodzeniu projektu i jakości zaimplementowanego rozwiązania. Tytułem przykładu - istotą dobrej umowy outsourcingowej czy utrzymaniowej jest jasny i czytelny SLA, łącznie z opisem sposobu pomiaru poszczególnych parametrów jakościowych. "Dostępność systemu na poziomie 98%" jest pojęciem, które aż prosi się o kłopoty - znam przypadek, gdy jedna z firm IT utrzymywała, że system jest wdrożony zgodnie z umową i dostępny w 100%, bo administrator może w każdej chwili do niego się wlogować. A że system miał obsługiwać transakcje internetowe i czas otwarcia aplikacji z sieci przekraczał kilkanaście sekund, uznawane było przez wdrażającego za kwestię drugoplanową. Jeżeli stronom brak wizji co chcą zrobić (patrz powyżej), wychodzi to najlepiej podczas omawiania tej części umowy. Jeżeli strony wiedzą co chcą osiągnąć, należy to opisać - jednozdaniowa formuła "wdrożenie systemu" nie wystarcza. Bardzo często okazuje się, że przysłowiowy diabeł tkwi w szczegółach. I nawet najgorętszy spór przy negocjowaniu umowy jest per saldo korzystniejszy i tańszy niż spór nad interpretacją zapisów.

Rola prawników na tym etapie zależy w dużej mierze od ich doświadczenia pozaprawnego. Obowiązkiem prawnika jest czuwać nad jasnym sprecyzowaniem ustaleń - bardzo często zapisy są uzgadniane przez różne zespoły merytoryczne i są ze sobą niepowiązane (chociażby przez różne definiowanie tych samych pojęć). Najczęściej objawia się to w załącznikach - warto, aby cała umowa została dokładnie przez doradcę przeczytana i skonsultowana. Niezwykle cennym partnerem okazuje się prawnik, który uprzednio negocjował i doradzał w trakcie realizacji takich projektów. Zwłaszcza udział w realizacji projektów jest cenny, gdyż pozwala zweryfikować "na żywo" zapisane klauzule. Wynikający z takich doświadczeń know how jest trudny do przecenienia, szczególnie po stronie klienta, który z reguły ma mniejsze doświadczenie niż partner oferujący system.