Redakcja
Zachęcamy do użycia wiedzy i doświadczenia, aby pomóc Administracji w stworzeniu lepszych umów z wykonawcami oprogramowania. Opracowane wzorcowe klauzule umowne mogą być wykorzystane przez zamawiających z sektora finansów publicznych w umowach IT w przedmiocie wdrożenia oprogramowania na infrastrukturze zamawiającego. Opracowanie zawiera klauzule do wykorzystania w procesie tworzenia umów zarówno zawieranych w procedurach przetargowych, jak i bez zastosowania ustawy Prawo zamówień publicznych.
W niedługim czasie Ministerstwo Cyfryzacji planuje opublikowanie wzoru umowy wdrożeniowej oraz drugiego zestawu klauzul, tym razem dotyczących wdrożenia oprogramowania wraz z dostawą infrastruktury. Rozważane jest również przeprowadzenie szkoleń z zakresu objętego klauzulami dla pracowników administracji publicznej.
Klauzule, ze względu na język, zapewne bliższe będą prawnikom, ponieważ zostały opracowane przez zespół kancelarii MARUTA WACHTA Sp. j. pod kierownictwem mec. Marcina Maruty i mec. Bartłomieja Wachty. Wykorzystano w nich również uwagi pracowników administracji publicznej, zarówno prawników, jak i specjalistów z dziedziny IT.
Można je znaleźć pod adresem: https://mc.gov.pl/aktualnosci/wzorcowe-klauzule-w-umowach-it
Uwagi należy przesyłać na adres: Klauzule@mc.gov.pl
Wybraliśmy dla czytelników kilka komentarzy i zapisów, aby pokazać, w jakim kierunku idą umowy IT w sektorze publicznym. Proszę uwzględnić, że jest to wstępny etap i klauzule mają jeszcze defekty.
O błędach i ich kategoriach
Błąd – nieprawidłowe działanie Oprogramowania, niezależnie od przyczyny takiej nieprawidłowości. W szczególności Błędem jest działanie Oprogramowania niezgodnie z Dokumentacją. Błędom przypisane są kategorie [opcjonalnie: priorytety].
Opis kategorii Błędów został zawarty w Załączniku nr __ [KATEGORIE BŁĘDÓW].
OPCJONALNIE (DEFINICJE POWINNY BYĆ OPRACOWYWANE DLA KAŻDEGO PROJEKTU. PONIŻEJ WYŁĄCZNIE PRZYKŁAD):
Błąd Krytyczny – nieprawidłowe działanie Oprogramowania powodujące albo całkowity brak możliwości korzystania z Oprogramowania, albo takie ograniczenie możliwości korzystania z niego, że przestaje ono spełniać swoje podstawowe funkcje. Przykładem Błędu Krytycznego jest niemożność uruchomienia Oprogramowania, brak odczytu/zapisu z bazy danych, utrata danych lub ich spójności, brak możliwości zalogowania użytkownika, niedostępność krytycznych funkcji Oprogramowania.
Błąd Poważny – nieprawidłowe działanie Oprogramowania powodujące ograniczenie korzystania z Oprogramowania przy zachowaniu spełniania przez Oprogramowanie jego podstawowych funkcji. Przykładem Błędu Poważnego jest niedostępność niekrytycznych funkcji Oprogramowania, wydajność poniżej progu określonego w Załączniku nr __ [SLA] .
Błąd Niskiej Kategorii – nieprawidłowe działanie Oprogramowania niepowodujące ograniczenia korzystania z Oprogramowania. Przykładem Błędu Niskiej Kategorii jest np. niedostępność systemu pomocy, błąd językowy w interfejsie.
Ogólnie o zasadach realizacji umowy
Paragraf ma na celu wskazanie ogólnych zasad współpracy stron. Może on zostać dowolnie rozbudowany w zależności od potrzeb. W szczególności jest rekomendowane przesądzenie o języku projektu, a zwłaszcza o wyjątkach. Językiem projektu będzie z reguły język polski. Poszczególne produkty, np. techniczna dokumentacja oprogramowania narzędziowego może być dostępna w języku angielskim, zwyczajowo stosowanym przez profesjonalistów w technicznych aspektach IT, jeśli taka wersja jest powszechnie używana i wystarczająca. W takiej sytuacji wymóg dostarczenia wersji polskiej może okazać się niecelowy i może wpłynąć na cenę oferty.
Rekomendowane jest wprowadzenie prawa audytu i opisanie zasad zdalnego dostępu, jeżeli ma zastosowanie.
Do uznania zamawiającego jest ewentualne wprowadzenie – w zakresie wdrożenia lub utrzymania - wskazania określonych metodyk (standardów). Z uwagi na konieczność zapewnienia konkurencyjności i równego traktowania wykonawców co do zasady nie jest możliwe narzucenie konkretnej metodyki projektowej. Możliwe jest natomiast wskazanie w SIWZ, jako przykładów i punktów odniesienia, konkretnych metodyk, typu PRINCE 2 , z dopuszczeniem metodyk równoważnych i zdefiniowaniem warunków tej równoważności. Celem takich postanowień SIWZ jest wymaganie posłużenia się przez wykonawcę uznaną metodyką projektową, zapewniającą profesjonalne realizowanie projektu, z wykorzystaniem dobrych praktyk branżowych. W przypadku wyboru oferty wskazującej konkretną metodykę może ona zostać wpisana do umowy wraz ze zobowiązaniem wykonawcy do stosowania tej metodyki w toku projektu. Takie podejście ułatwia ustalenie, czy umowa jest realizowana z zachowaniem wymaganej należytej profesjonalnej staranności.
Sporna jest praktyka regulacji umownych w zakresie tzw. miernika staranności. Zgodnie z art. 355 kodeksu cywilnego obowiązujący jest miernik należytej staranności, przy czym należytą staranność w zakresie prowadzonej działalności gospodarczej określa się przy uwzględnieniu zawodowego charakteru tej działalności. Oznacza to obowiązek dochowania „staranności ogólnie wymaganej w stosunkach danego rodzaju”. W praktyce umów wdrożeniowych trudno jest określić ową „ogólnie wymaganą staranność” – wynika to zarówno z różnorodności i niepowtarzalności projektów, jak i stosunkowo krótkiego okresu istnienia w obrocie tego typu umów, a co za tym idzie skromnego orzecznictwa i doktryny. W umowach spotyka się podwyższenie tego miernika do tzw. „najwyższej staranności”, co nakłada na wykonawcę większe, ale nadal niedookreślone obowiązki. W praktyce może okazać się, że określenie różnic między tymi miernikami będzie utrudnione. Z drugiej strony, jak każdy czynnik ryzyka, takie wymaganie może wpływać na ofertę wykonawcy, a w szczególności na jej cenę. Rekomendujemy wprowadzanie miernika najwyższej staranności wyjątkowo, wyłącznie w szczególnie istotnych projektach.
Praktyką jest uszczegółowienie obowiązku informacyjnego poprzez wprowadzenie zasady informowania o przebiegu projektu na piśmie, na żądanie zamawiającego. W przypadku bardzo sformalizowanych projektów można dookreślić termin przekazania takich informacji, ale zazwyczaj nie jest to konieczne (zasada niezwłoczności z kodeksu cywilnego). Nadużywanie tego uprawnienia (składanie niepotrzebnych wniosków w krótkich odcinkach czasowych) może być uznane za przeszkodę w realizacji projektu leżącą po stronie zamawiającego.
Opcjonalne (tam, gdzie ma to zastosowanie) należy wprowadzić klauzulę o zgodności oprogramowania z prawem – można także rozbudować ją o wykaz aktów prawnych. Należy pamiętać, że część regulacji obowiązujących administrację (np. wytyczne czy rekomendacje) lub określone sektory (np. finansowy – rola KNF) nie stanowi przepisów prawa i regulacje te nie będą objęte taką klauzulą. W takiej sytuacji regulacje należy włączyć do umowy np. w załączniku Wymagania Organizacyjne Zamawiającego.
Ważną decyzją jest określenie, na który moment projektu taka zgodność jest badana. Rozwiązaniem teoretycznie najkorzystniejszym dla zamawiającego jest moment odbioru wdrożenia, ale im dłuższy projekt, tym większe ryzyko po stronie wykonawcy, co może mieć znaczenie przy ustalaniu ceny i co może stanowić problem z uwagi na zasadę określoności przedmiotu zamówienia. Co więcej, duża zmiana legislacyjna może wymagać szeregu zmian projektowych (od harmonogramu po zmianę wymagań funkcjonalnych) i powinna być prowadzona w trybie procedury zmian, a nie ogólnego obowiązku wykonawcy. Istnieje więc możliwość, że w przypadku postawienia wymagania zapewnienia zgodności z prawem na dzień późniejszy niż złożenie oferty, wykonawcy będą mogli postawić słuszny zarzut, iż w takim przypadku nie są w stanie prawidłowo skalkulować oferty, bowiem nie mogą przewidzieć zakresu zmian, które będą zobowiązani wprowadzić do produktu w związku ze zmianami prawa mającymi miejsce już po złożeniu oferty. Wydaje się więc uzasadnione i najbezpieczniejsze z punktu widzenia zasad prawa zamówień publicznych wprowadzenie weryfikacji właśnie na moment złożenia oferty (zobowiązania wykonawców, by oferowane przez nich oprogramowanie było zgodne z przepisami prawa obowiązującymi na dzień złożenia ofert), natomiast zamawiający powinien zapewnić sobie możliwość wprowadzenia do umowy zmian uwzględniających ewentualne modyfikacje przepisów prawa, które nastąpią po dniu składania ofert. Odpowiednie mechanizmy są proponowane w ramach procedury kontroli zmian albo prac rozwojowych (w ramach zakupionego przez zamawiającego pakietu roboczogodzin lub roboczodni). Nie sposób jednak wykluczyć takiej sytuacji, w której zamawiający wskaże dalszy moment, w którym będzie oceniana zgodność z prawem, jeżeli np. w dniu składania ofert dana zmiana prawa jest już pewna, a tylko z uwagi na vacatio legis będzie wprowadzona później.
Poza wymaganiami wynikającymi z przepisów prawa poszczególni zamawiający mogą posiadać własne regulacje, których uwzględnienie przez wykonawców może być konieczne przy realizacji zamówienia. Jeżeli zamawiający np. z definicji nie zezwala na zdalny dostęp do swoich zasobów, informacja o tym powinna być przekazana wykonawcy przed złożeniem przez niego oferty, aby był w stanie uwzględnić takie ograniczenia w wycenie oferowanych usług lub produktów.
Rekomendowane jest wprowadzenie postanowień dotyczących środowisk – developerskich , testowych, rozwojowych. Proponowane klauzule wskazują, że jeżeli umowa nie stanowi inaczej, obowiązek zapewnienia środowisk niezbędnych do wdrożenia oprogramowania, w tym umożliwiających tworzenie i testowanie oprogramowania, leży po stronie wykonawcy. W wielu jednak przypadkach zamawiający żąda wykonania prac na swoich środowiskach, a co najmniej udostępnia środowiska testowe. Są też rozwiązania pośrednie, np. zamawiający dostarcza środowisko developerskie, ale po stronie wykonawcy pozostanie obowiązek jego konfiguracji (systemy, bazy danych etc.) i administrowania podczas wdrożenia lub utrzymania.
Rekomendowane jest także wprowadzenie klauzul, które mają na celu uzyskanie zapewnienia, że realizacja umowy lub korzystanie z systemu nie spowoduje konieczności nabycia przez zamawiającego dodatkowych licencji lub innych uprawnień. Takie ryzyko jest związane np. z konfiguracją oprogramowania standardowego, która może prowadzić do obowiązku zapłaty dodatkowych opłat licencyjnych.
O odbiorach
Dokonanie odbioru jest zobowiązaniem zamawiającego. Taki obowiązek jest ściśle przewidziany w przepisach prawa – w tym wprost w art. 643 k.c. („Zamawiający obowiązany jest odebrać dzieło, które przyjmujący zamówienie wydaje mu zgodnie ze swym zobowiązaniem”) i potwierdzony orzecznictwem. W praktyce kwestie odbioru budzą jednak wiele sporów i wątpliwości.
Nie ulega wątpliwości, że nie można mówić o obowiązku odebrania dzieła, gdy ma ono wady, zwłaszcza istotne. Na szczególną uwagę zasługuje postanowienie Sądu Najwyższego z dnia 17 kwietnia 2015 r. (III CZP 8/15) w którym stwierdził on, że „(…) zgodnie z art. 643 k.c., zamawiający ma obowiązek odbioru dzieła – a więc dokonania czynności wyrażającej wolę przyjęcia świadczenia i uznania go za wykonane – nie każdego, lecz tylko takiego, które przyjmujący zamówienie wydaje mu zgodnie ze swym zobowiązaniem. Nie sposób uznać, nawet przy ograniczeniu się do reguł wykładni językowej, aby zamawiający miał obowiązek odebrania dzieła, o którym mowa w art. 643 k.c., i zapłaty wynagrodzenia (art. 642 § 1 k.c.) w razie wydania mu dzieła z wadami istotnymi, a więc takimi, które uniemożliwiają korzystanie z niego zgodnie z przeznaczeniem lub sprzeciwiają się wyraźnie umowie”. Taki pogląd był zresztą wielokrotnie wyrażany wcześniej.
Warto zaznaczyć, że w przywołanym postanowieniu sąd odwołuje się do pojęcia wady „istotnej”. Zdecydowanie bardziej dyskusyjną kwestią jest zagadnienie odbioru dzieła z tzw. wadami nieistotnymi, gdzie reprezentowane są odmienne poglądy. Istotą tych wątpliwości jest, czy zamawiający jest zobowiązany do odbioru dzieła, gdy wady nie uniemożliwiają jego eksploatacji – odpowiedź odmowna mogłaby oznaczać sprzeczną z zasadami współżycia społecznego obstrukcję, np. odmowę odbioru wielostronicowej dokumentacji z powodu nielicznych błędów interpunkcyjnych. Granica między wadami istotnymi a nieistotnymi (pomijając nawet fakt uchylenia art. 637 k.c.) jest wyjątkowo nieostra w przypadku projektów informatycznych, gdzie np. błąd jednej litery w kodzie może skutkować wadą określaną jako istotną. Z drugiej strony – istnienie błędów w oprogramowaniu jest zjawiskiem całkowicie powszechnym i w obecnym stanie raczej nieuniknionym. Duże znaczenie ma okoliczność, że to z reguły zamawiającemu zależy, żeby zacząć korzystać z oprogramowania mimo istnienia błędów mniejszej wagi (nieistotnych) – błędy takie mogą być usunięte podczas eksploatacji produkcyjnej i nie powinny wstrzymywać odbioru. Z tego powodu rekomendowane jest zwrócenie szczególnej uwagi na definicje błędów i opracowanie załącznika z procedurą testów oprogramowania, w którym podane będą warunki akceptacji oprogramowania, nawet mimo istnienia określonych błędów. W rozbudowanych systemach można odrębnie określić warunki błędów, np. przy testach użytkowników (UAT) i testach integracyjnych. Inaczej też zazwyczaj definiuje się błędy związane z migracją danych. Kluczowa jest jak najdalej posunięta precyzja w tych definicjach i zwrócenie uwagi, że zbyt rygorystyczne przesłanki akceptacji mogą działać na niekorzyść przede wszystkim zamawiającego.
Należy zwrócić uwagę, że przyjęta we wzorcach definicja błędu odwołuje się do cech oprogramowania i przypadków jego nieprawidłowego działania. Podczas odbiorów mogą wystąpić inne nieprawidłowości, które nie skutkują wystąpieniem błędów w tym znaczeniu (w zależności od definicji, błędem nie musi być np. brak określonej funkcjonalności), dlatego kryterium odbiorów nie powinno zawężać się jedynie do weryfikacji systemu pod kątem błędów.
Z reguły procedury weryfikacji oprogramowania są bardziej rozbudowane niż innych produktów, w szczególności zawierają wykaz testów – integracyjnych, wydajnościowych, regresji, UAT etc. Mogą też opisywać reguły rozpoczęcia testowania (nie wszystkie systemy mogą być testowane od razu po dostarczeniu danego oprogramowania) czy też poszczególne, przykładowe scenariusze. Standardowe oprogramowanie systemowe oraz standardowe oprogramowanie aplikacyjne może – o ile procedura lub umowa nie stanowi inaczej – zostać odebrane wstępnie tylko ilościowo, po weryfikacji dostarczenia poprawnej zawartości (nośniki, dokumentacja) takiego produktu. Powyższe nie uchyla prawa zamawiającego do weryfikacji poprawności działania tego oprogramowania w późniejszym czasie, w szczególności podczas odbioru etapu lub odbioru wdrożenia.
Odbiór warunkowy może być rozwiązaniem przydatnym dla zamawiającego, który chce rozpocząć korzystanie z oprogramowania, godząc się na niedogodności. Jeżeli wykonawca nie wywiąże się z ustaleń dokonanych w toku warunkowego odbioru, wówczas zamawiający uzyskuje uprawnienie do naliczenia wszelkich kar i wykonania innych uprawnień związanych z niewykonaniem umowy w pierwotnie umówionym terminie. Zaproponowana konstrukcja odbioru warunkowego przewiduje – jako opcję – możliwość dokonania przez zamawiającego części płatności w związku z odbiorem warunkowym w chwili jego dokonania, a pozostałej części płatności – po usunięciu wszystkich błędów lub innych niezgodności z umową zgłoszonych przez zamawiającego w terminie przyjętym w warunkowym protokole odbioru.
Kolejną kwestią jest uzgodnienie harmonogramu i przypisanie w nim odpowiedniego czasu na odbiory. Jako że to zamawiający ustala reguły odbioru i czas jego realizacji, należy zwrócić szczególną uwagę na wyznaczenie realistycznych terminów pozwalających na należytą weryfikację przedmiotu danego odbioru. Zarzuty wykonawców wobec zamawiających są w tym zakresie często uzasadnione, a w zależności od sytuacji mogą prowadzić nawet do odstąpienia od umowy.
Należy rozróżnić testowanie oprogramowania w fazie zwykłych prac wdrożeniowych (np. w ramach testów wewnętrznych wykonawcy, testów wspólnych z zamawiającym) od odbioru, czyli czynności zmierzających do potwierdzenia należytego wykonania umowy. Wystąpienie nawet znacznej liczby błędów podczas testów prowadzonych w ramach wdrożenia może być zjawiskiem normalnym, natomiast testy realizowane w ramach odbioru nie powinny wykazać większej liczby błędów o określonych kategoriach. Przekroczenie dopuszczalnych limitów błędów w toku odbiorów oznacza nienależyte wykonanie umowy i jest podstawą do odmowy odbioru oraz skorzystania z mechanizmów przewidzianych przepisami prawa oraz postanowieniami umowy.
Problematyczną kwestią jest relacja odbiorów poszczególnych produktów czy etapu do całości wdrożenia. Chodzi o sytuację zaakceptowania danego produktu i późniejszego wykazywania w nim nieprawidłowości podczas odbioru systemu. Taka sytuacja może mieć miejsce i jest usprawiedliwiona, jeżeli np. zamawiający wykazuje błędy, których wcześniej nie mógł stwierdzić, dotyczące np. integracji czy wydajności. Wątpliwa jest możliwość zgłaszania zastrzeżeń, które modyfikowałyby wcześniejszy zakres odbioru, np. poprzez żądanie dodania nowych funkcjonalności. Może to być teoretycznie możliwe przy braku funkcjonalności jednoznacznie wymaganej w umowie, ale uprzedni odbiór takiego produktu może być uznany za wyraz woli stron co do ukształtowania zakresu obowiązków wykonawcy. Ma to zwłaszcza miejsce w sytuacjach nieostrych, gdy konieczne jest dookreślenie zobowiązań wykonawcy – wtedy odbiór produktu może stanowić takie dookreślenie w ramach umowy. Okoliczność ta ponownie wskazuje na obowiązek zachowania wyjątkowej staranności przy dokonywaniu odbiorów.
Konieczne jest też zwrócenie uwagi na częsty zarzut obstrukcji odbiorów przez zamawiającego. Obstrukcja taka może przejawiać się np. zgłaszaniem niemających pokrycia w umowie uwag, niedotrzymaniem terminów czy niedochowaniem należytej staranności przy procedurach testowych – np. przerywanie testów, niezgłoszenie wszystkich uwag, zgłaszanie uwag do już przeprowadzonych testów itp. Część z tych zagadnień można uregulować procedurą (np. prawo przerwania testów i zwrotu oprogramowania przy stwierdzonym pierwszym błędzie krytycznym), ale takie zachowania zamawiającego mogą prowadzić do obciążenia go za nie odpowiedzialnością i stają się też przedmiotem postępowań sądowych.
Klauzule i komentarze pochodzą z dokumentu z https://mc.gov.pl/ >>
