Zapraszam na pierwszy wywiad z Panem Łukaszem Węgrzynem z Kancelarii Prawnej Maruta i Wspólnicy w Warszawie.
ŁUKASZ WĘGRZYN
Specjalista z zakresu prawa nowych technologii oraz własności intelektualnej. Wcześniej pracował między innymi jako prawnik wewnętrzny dla Agora S.A.. MTv Networks oraz członek zespołu TMT (Technology – Media – Telecomunications) międzynarodowej kancelarii prawnej „Bird & Bird”. Aktualnie pracuje w Kancelarii Prawnej Maruta i Wspólnicy w Warszawie. Wykładowca na Wydziale Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego. Absolwent Wydziału Prawa i Administracji Uniwersytetu Jagiellońskiego oraz podyplomowych studiów na kierunku „Prawo Nowoczesnych Technologii” prowadzonych przy Polskiej Akademii Nauk.
Serdecznie zapraszam na wykład o najczęstszych problemach z umowami wdrożeniowymi oraz o roli analizy w umowie.
1. Jakie są najczęstsze przyczyny problemów w umowach wdrożeniowych i jakie są ich skutki z punktu widzenia sporów sądowych na polskim rynku IT?
Stosunkowo najczęstszym powodem sporów jest legendarny już zakres, a konkretnie trudność w odpowiedzi na pytanie o co tak naprawdę się umówiliśmy.
Powodów takiego stanu rzeczy jest wiele. Jednym z nich jest między innymi niewłaściwie wykonana analiza przedwdrożeniowa. Analiza to jeden z podstawowych załączników umowy wdrożeniowej, wyznaczający jej zakres, a zatem to, co ma zostać w wyniku podpisania umowy zrealizowane.
Nierzadko analizy przedwdrożeniowe posługują się generalnymi pojęciami lub pojęciami, których znaczenie nie jest wystarczająco jasno i precyzyjnie określone. Taka sytuacja skutkuje z kolei dużą dowolnością interpretacyjną, a tym samym powoduje, że strony umowy wchodzą w spór co do właściwego brzemienia konkretnych zapisów analizy, które decydują o zakresie umowy, czyli o tym, co zostanie lub nie zostanie w wyniku umowy zrealizowane.
Kolejna przyczyna problemów nie jest związana z tym „CO” mamy zrobić, ale „JAK” to mamy zrobić. W praktyce sprowadza się do sytuacji, w której strony niewystarczająco jasno i precyzyjnie opisały w umowie poszczególne etapy przebiegu wdrożenia. To bardzo częsty problem, w rezultacie którego strony zaczynają się przerzucać odpowiedzialnością co do realizacji konkretnych działań niezbędnych dla właściwej, a co najważniejsze efektywnej realizacji projektu wdrożeniowego. Stad już tylko krok do eskalacji sporu i całkowitej klęski projektu.
- Jaka jest rola dobrze napisanych kontraktów na dostarczenie oprogramowania? Czy obecnie zapisy w umowach różnią się od tych sprzed kilku lat?
Na tak postawione pytanie najchętniej odpowiadam, że rola kontraktów jest służebna. Krótko mówiąc, mam na myśli to, że kontrakty mają służyć temu aby projekt się udał. Ich zadaniem powinna być maksymalizacja szans na powodzenie projektu przy jednoczesnym wykluczeniu nieakceptowalnych ryzyk. Zmierzam do tego, że pisząc umowę wdrożeniową powinniśmy się pozbyć pokutującego powszechnie przeświadczenia, że umowy pisze się tylko na złe czasy.
Jeśli uwierzymy w to, że umowy pisze się tylko na czas wojny, istotnie zwiększamy ryzyko na to, że pominiemy w umowie wdrożeniowej te obszary, których obecność może być kluczowa dla powodzenia projektu. Mam tu konkretnie na myśli zapisy dotyczące przebiegu realizacji wdrożenia czy postanowienia odnoszące się do wzajemnego współdziałania stron w ramach realizacji projektu.
W 2007 roku IACCM (z ang. International Association for Contract & Commercial Management) przeprowadziło badanie, w wyniku którego stworzono listę obszarów umownych, którym podczas negocjacji poświęcamy procentowo najwięcej czasu. Jak pokazało badanie największą uwagę koncentrujemy na kwestiach związanych z odpowiedzialnością, gwarancją, wypowiedzeniem czy prawami autorskimi. Co ciekawe, w pierwszej dziesiątce obszarów umownych pochłaniających najwięcej czasu podczas negocjacji nie znalazły się te dotyczące współdziałania stron, sposobu realizacji projektu czy właściwego określenia przedmiotu umowy.
Wydaje się, że od tamtego czasu niestety niewiele się zmieniło. W dalszym ciągu dominuje optyka wojenna. Jednym słowem dalej nie patrzymy na umowę jako na narzędzie, które ma nam pomóc w pozytywnej realizacji projektu, a wciąż próbujemy w nim dostrzec oręż mający nam służyć na czas walki sądowej.
- Jakie cechy powinna mieć dobra umowa wdrożeniowa, na co szczególnie zwrócić uwagę?
Patrząc z perspektywy wysokopoziomowej umowa wdrożeniowa powinna być napisana prostym i łatwym do zrozumienia językiem. Umowa nie jest miejscem na popisy słowotwórstwa. Przeciwnie, im jaśniej tym lepiej. To w dużej mierze pozwoli uniknąć niepotrzebnych wątpliwości interpretacyjnych.
Bez wątpienia umowa powinna odpowiadać założeniom biznesowym projektu którego dotyczy. To oczywiście brzmi jak banał, ale zbyt często przychodzi mierzyć się z sytuacją, w której umowa istotnie rozmija się z założeniami biznesowymi projektu, dla którego ma być formalną podstawą. Co ważne, najczęściej dotyczy to tych obszarów umowy które opisują sposób realizacji projektu wdrożeniowego. Klasycznym już przykładem jest opisanie w umowie czysto „waterfallowych” procedur dla projektu realizowanego zwinnie.
Inny przykład to posługiwanie się w umowie ITIL-owską siatka pojęciową, w sytuacji kiedy akurat ten model zarządzania usługami informatycznymi nie jest podstawą realizacji projektu wdrożeniowego. To prosta i skuteczna droga do porażki projektu.
Schodząc na niższy poziom, nawiązując do tego o czym już wcześniej rozmawialiśmy, pamiętajmy aby umowa nie tylko precyzowała „CO”, ale jednocześnie konkretyzowała „JAK”. Nie zapominajmy o takich rzeczach jak administracja środowiskami, zasady testowania i odbiorów, kodach źródłowych, standardach dokumentacji, etc. Aby to właściwie opisać trzeba wystarczająco dobrze poznać organizację u której konkretny system będzie wdrażany. Trzeba poznać jej metodyki działania, zagregować harmonogram umowy z kalendarzem wydań panującym w danej organizacji, dostosować procedury testowe opisane w umowie do tych panujących u zamawiającego. Takich postanowień umowy nie da się oprzeć na standardowych klauzulach, to zawsze jest pisane „na miarę”. Inaczej po prostu tego nie da się zrobić.
- Jakie najczęstsze błędy, przeoczenia popełniane są przy podpisywaniu umów z dostawcą? Czy da się ich uniknąć? Jakie są Pańskie doświadczenia w tym aspekcie?
Najczęstsze błędy to właśnie te, o których przed chwilą rozmawialiśmy. Zasadniczo sprowadzają się one do niewystarczająco jasno opisanego zakresu projektu. Przy czym mówiąc o zakresie mam tu na myśli nie tylko co ma zostać zrealizowane, ale również jak to ma zostać zrealizowane. Co istotne, nie chodzi mi o to aby już na samym wstępie drobiazgowo i precyzyjnie opisać wszelkie wymagania związane z projektem, bo jak doświadczenie uczy te mogą się w trakcie projektu zmienić. Chodzi mi bardziej o to aby w projekcie nie było tzw. szarych stref lub ziemi niczyjej, czyli takich obszarów, względem których nie wiadomo która strona odpowiada. To właśnie takie sytuacje są często punktami zapalnymi projektu.
A jeśli mówimy już o zmienności wymagań w trakcie realizacji projektu, to warto wyposażyć umowę w mechanizmy pozwalające taką sytuacją zarządzić. Brak takich postanowień prędzej czy później doprowadzi do impasu projektu.
- Czy mógłby Pan opowiedzieć jakiś case study, który opisywałby proces IT z konsekwencjami dla zamawiającego, bądź wykonawcy? Gdzie były popełnione błędy i czy udało się ich uniknąć?
Jednym z takich przypadków była sytuacja kiedy już w połowie realizacji dużego wdrożenia, zamawiający zlecił nam przeprowadzenie renegocjacji kontraktu wdrożeniowego. Wdrożenie było już na półmetku, a pierwotna umowa nie była przez nas przygotowywana ani negocjowana. Kiedy poprosiliśmy o dokumentację aby przygotować się do renegocjacji umowy, szybko okazało się, że mamy do czynienia z jednym z klasycznych w polskiej branży IT przypadków, a mianowicie tzw. syndromem umowy w szufladzie. Impas projektowy będący powodem dla którego zostaliśmy zaangażowani w sprawę wynikał z faktu, że realizacja projektu od strony metodyk projektowych nijak nie pokrywała się z postanowieniami umowy co do procedur realizacji projektu. W efekcie zespoły projektowe nie chcąc się specjalnie przejmować formalnościami zaczęły realizować projekt „po swojemu”. I wszystko być może dobrze by się skończyło, gdyby nie fakt, że w którymś momencie zaczęło dochodzić do istotnych różnic zdań pomiędzy stronami kontraktu co do zakresu konkretnych działań, jakie miały być podejmowane na projekcie przez zamawiającego lub dostawcę. Dopiero wtedy zdecydowano się zajrzeć do umowy. Problem w tym że to co było zapisane w umowie było już nijak nieprzystawalne do rzeczywistości projektowej. Nasze zadanie polegało zatem na tym aby spowodować że umowa stanie się kompatybilna z realiami projektowymi.
Takie sytuacje dzieją się coraz częściej. Wynika to często z coraz szybszego tempa w jakim realizowane są projekty wdrożeniowe, w których jak się okazuje, często nie ma czasu aby spojrzeć do umowy. Kolejną przyczyną takiego stanu rzeczy jest pisanie umów, które nie uwzględniają specyfiki konkretnych organizacji, ich preferowanych metodyk czy nawet metodologii działania.
Jak temu zaradzić? Jednym ze sposobów jest coraz częściej zlecana prawnikom usługa stałej asysty projektowej. Prawnik stając się integralnym członkiem zespołu projektowego aktywnie i na bieżąco uczestniczy w tworzeniu, weryfikacji i analizie wybranych obszarów dokumentacji prawnej. Dodatkowo jego rola sprowadza się do kontrolowania czy kluczowe procesy projektowe takie jak np. procedury odbiorowe przebiegają zgodnie z zasadami opisanymi w umowie. W pewnym sensie prawnik pełni tu rolę Scrum Mastera projektu, dbającego o to aby projekt przebiegła zgodnie z procedurami ustalonymi przez strony w umowie.
- Jaką rolę (i czy w ogóle) odgrywa dokumentacja tworzona przez Analityka w procesach sądowych?
Tak, odgrywa rolę i to nie małą. Pamiętajmy, że tworzona przez analityka dokumentacja jest jednym z elementów decydujących o przedmiocie umowy, a konkretnie o jej zakresie, stanowi zatem jeden z punktów odniesienia dla oceny tego na co strony się w kontrakcie umówiły. Ma to szczególnie duże znaczenie dla tych projektów wdrożeniowych, które realizowane są w oparciu o model umowy o dzieło. A bez wątpienia to właśnie takie projekty stanowią znakomitą większość.
- Czy w swojej pracy spotkał Pan się kiedyś z sytuacją, kiedy użycie niewłaściwego wyrażenia w dokumentacji stało się przyczyną do wejścia na drogę sądową? Jakie to było wyrażenie?
Nie. Z czymś takim się nie spotkałem. Ale niejednokrotnie byłem świadkiem sytuacji kiedy niewłaściwa tj. niewystarczająco konkretna, zbyt ogólna redakcja wybranych obszarów dokumentacji prowadziła do istotnych różnić interpretacyjnych, w konsekwencji wywołując poważny impas w projekcie.
- Proszę o 5 kluczowych rad dla osób, które zajmują się przygotowywaniem umów wdrożeniowych.
Z oczywistych względów będzie to wysokopoziomowe spojrzenie.
1.Po pierwsze im jaśniej i prościej tym lepiej.
2.Po drugie nie tylko „CO” ale również „JAK.
3.Po trzecie właściwy opis procedur współdziałania stron. Nie zostawiajmy szarych stref, względem których trudno określić która ze stron jest za nie odpowiedzialna.
4.Po czwarte kary umowne powinny stymulować, nie paraliżować. Dobrze opisany mechanizm kar umownych, oparty na obiektywnie wyliczalnych parametrach to naprawdę rzadkość w kontraktach wdrożeniowych.
5.I po piąte, piszmy kontrakty które odpowiadają założeniom biznesowym. Tak co do zakresu projektu, jak i sposobu jego realizacji. W przeciwnym wypadku przygotujmy się na szuflady pełne umów.
