Skonstruowanie umowy utrzymaniowej na oprogramowanie (Service Level Agreement – SLA), zabezpieczającej interesy zamawiającego i spełniającej jego oczekiwania, wymaga zaangażowania wielu obszarów organizacji. Udział prawnika jest ważnym, ale nie jedynym czynnikiem wpływającym na sukces projektu.
Pomijając wątki uniwersalne, o których należy pamiętać przy każdej umowie z dostawcą, takich jak zasady rozwiązania umowy, transfer praw autorskich do rezultatów umowy, ochrona informacji poufnych zamawiającego czy RODO, przyjrzyjmy się bliżej kwestiom kluczowym z punktu widzenia zamawiającego.
Analiza potrzeb zamawiającego
Zacznijmy od podstawowych pytań, dotyczących umowy:
- W jakich godzinach mają być obsługiwane błędy?
- Czy nasze uprawnienia do systemu pozwalają na obsługę systemu przez dowolnego dostawcę, czy jesteśmy ograniczeni do wąskiego kręgu podmiotów?
- Czy dostawca ma również odpowiadać za utrzymanie parametrów wydajnościowych systemu?
Wyniki tej analizy powinny być uwzględnione w naszym zapytaniu ofertowym, a następnie odzwierciedlone w umowie.
Takie podejście zwiększy szanse na to, że oferty wykonawcy będą dopasowane do wymogów zamawiającego. Kolejną korzyścią są oszczędności: po co płacić za gotowość zespołu utrzymaniowego dostawcy 24/7 w sytuacji, kiedy wystarczy nam gotowość w godz. 9 – 17 w dni robocze?
Co więcej, im dokładniej określimy nasze wymagania na wczesnym etapie projektu, tym większe są szanse na szybkie zawarcie umowy utrzymaniowej.
Definicje „Błędów” i ich priorytety
To mina, która może zniweczyć wysiłek włożony w negocjacje każdej umowy utrzymaniowej. Określmy w umowie, co strony uważają za „Błąd” – czyli, które przypadki nieprawidłowego funkcjonowania systemu są w ogóle objęte obowiązkiem ich obsługi przez dostawcę.
Ustalmy następnie, które kategorie „Błędów”mają być usuwane najszybciej, a które są dla nas mniej krytyczne. Wprowadźmy do umowy definicje tych kategorii. Pamiętajmy o udziale zespołu biznesowego, który pracuje z systemem na co dzień – to on pomoże nam zdefiniować priorytety.
Częstą pułapką jest ograniczenie definicji błędu do działania systemu niezgodnego z jego dokumentacją. Czy jednak posiadamy taką dokumentację? A jeśli tak, to czy dokumentacja jest aktualna i kompletna oraz kto będzie odpowiadał za jej aktualizację?
Akceptacja napraw
Procedura weryfikacji/akceptacji napraw powinna jasno określać podział obowiązków stron. Ustalmy m.in. jakimi kanałami dostawca przekazuje nam paczkę instalacyjną z poprawką, które testy poprawki są realizowane po stronie dostawcy, a które po naszej. Ustalenie tych kwestii pozwoli nam uniknąć sporów na etapie realizacji projektu.
Pamiętajmy, aby procedura uwzględniała nasze wewnętrzne wymagania – przykładowo, nie możemy zobowiązać się w umowie do zapewnienia dostawcy dostępu do środowiska produkcyjnego systemu, jeśli taki dostęp jest niedopuszczalny przez nasz obszar cyberbezpieczeństwa.
Zabezpieczmy się również przed praktyką niesumiennych dostawców, którą można nazwać tzw. „wiadrem gruzu”. To sytuacja, w której dostawca przekazuje nieskuteczną poprawkę tylko po to, aby czas weryfikacji poprawki przez zamawiającego (a zwykle czas ten „wstrzymuje” zegar SLA) wykorzystać na przygotowanie właściwej naprawy.
Kary umowne
Kary umowne są najefektywniejszym narzędziem pozwalającym „zmotywować” dostawcę do przestrzegania warunków serwisu. Ich katalog i wysokość powinny jednak odzwierciedlać nasze priorytety. Rozważmy, czy na pewno chcemy mieć możliwość naliczenia kar umownych za przekroczenie czasów SLA dla wszystkich kategorii.
Zawyżone lub nadmiarowe kary umowne wpływają na warunki oferty z uwagi na większe ryzyko dostawcy w projekcie. Nie zapominajmy również o ryzyku ich obniżenia przez sąd na żądanie dostawcy na podstawie przepisów Kodeksu Cywilnego.
Istotne jest precyzyjne odzwierciedlenie w umowie ustaleń stron co do przesłanek naliczenia kar umownych i ich wysokości – w przypadku niejasności, każda z nich będzie broniła swojej interpretacji, zgodnej z jej interesem. Nieprecyzyjna redakcja kar umownych obniża szanse wygranej w przypadku sporu sądowego, a może nawet wpłynąć na ich nieważność.
W umowach utrzymaniowych ważne jest precyzyjne określenie naszych potrzeb. Wymagania te powinny możliwie najwcześniejsze zostać przedstawione potencjalnym wykonawcom. Równie ważne jest odzwierciedlenie ustaleń stron w tym zakresie w umowie utrzymaniowej.
Wszystkie te czynniki zwiększają szanse powodzenia projektu.
Autor: Maciej Tabor, ekspert z zakresu prawa nowych technologii w kancelarii Lawspective Litwiński Valirakis Radcowie Prawni Sp.k. Wspiera zamawiających oraz wykonawców w projektowaniu i negocjacjach umów IT.
E-mail: maciej.tabor@lawspective.pl
