Umowa utrzymaniowa

Jest to umowa, na podstawie której firma IT świadczy usługi utrzymania systemu IT. Umowa utrzymaniowa, często też określana jest, jako umowa na obsługę i rozwój systemu. Usługi utrzymania polegają na zapewnieniu hostingu, utrzymania systemu informatycznego w infrastrukturze, diagnozowaniu przyczyn problemów z istniejącym oprogramowaniem komputerowym oraz usuwaniu błędów. Często usługom utrzymania towarzyszą usługi rozwoju oprogramowania komputerowego np. jego modyfikacje, czy dodawanie nowych funkcjonalności.

Na potrzeby niniejszego tekstu strony tej umowy nazwiemy:

• Usługobiorca – strona, która zamawia usługi utrzymania;
• Usługodawca – firma IT odpowiedzialna za świadczenie usług utrzymania.

Kwalifikacja prawna umowy: umowa o świadczenie usług, albo umowa nienazwana z elementami umowy o dzieło i umowy o świadczenie usług.

Mające zastosowania przepisy: Kodeks Cywilny, ustawa o prawie autorskim i prawach pokrewnych, ustawa o zwalczaniu nieuczciwej konkurencji.

Podstawowe postanowienia

• Przedmiot umowy. Należy określić przynajmniej:

  • Usługi – usługi mogą być określone w umowie lub w załączniku do niej w postaci specyfikacji usług lub podlegać doprecyzowaniu na etapie zamówień, gdy umowa ma charakter ramowy; zakres usług każdorazowo określa wówczas zamówienie. Usługi mogą dotyczyć utrzymania, monitorowania oprogramowania lub rozwoju. Należy precyzyjnie określić jakiego oprogramowania dot. te usługi;

  • Tryb składania zamówień – jeśli umowa przewiduje dookreślenie usług w zamówieniach;

  • Limit roboczogodzin (MH) na dana usługę - nie jest to element obowiązkowy, ale z punktu widzenia obu stron warto sprecyzować, czy usługi te mają mieć określony limit (cap) określony np. w roboczogodzinach na dany miesiąc. Strony powinny także sprecyzować czy niewykorzystane przez Zamawiającego MH dostępne w ramach usługi otrzymania mają być opłacone (opłacanie pewnego rodzaju “pozostawania w gotowości”) czy też wynagrodzenie należne jest wyłącznie za MH rzeczywiście przepracowane zgodnie np. z miesięcznym raportem czasu pracy. W przypadku ustalenia limitu MH, należy również doprecyzować konsekwencje tego faktu np. przerwanie prac lub ich dalsze rozliczanie po innej stawce;

• Miejsce świadczenia usług - np. zdalnie, lub w siedzibie Usługobiorcy;

• Czas trwania Umowy – umowy na utrzymanie najczęściej maja charakter terminowy. Można również przewidzieć zapisy precyzujące przyczyny wypowiedzenia umowy przed czasem np. opóźnienie w realizacji usługi, płatności etc.;

• Wynagrodzenie Usługodawcy.
  • Istnieje kilka sposobów określenia formuły wynagrodzenia. Do najpopularniejszych należą:
    • Fixed price – strony z góry określają wynagrodzenie należne Usługodawcy za całość usług wraz z określeniem ich miesięcznego wolumenu (abonamentu). Wykonawca jest wówczas uprawniony do wynagrodzenia bez względu na rzeczywiste wykorzystanie tego wolumenu;
    • Time&Materials - formuła wynagrodzenia odpowiadająca MH (man-hour) lub MD (man-days) które zostały rzeczywiście spożytkowane i wynikające z raportu czasu pracy dostarczonego przez Usługodawcę; Usługobiorca płaci wyłącznie za wykorzystane godziny;
    • Time&Materials z Capem – jest to rozliczenie w formule jak T&M z tą różnicą, że określamy co stanie się po osiągnięciu określonej liczby MH lub MD przez Usługodawcę tj. przewidujemy tzw. CAP;
  • Terminy płatności wynagrodzenia - w przypadku umowy utrzymaniowej najczęściej wynagrodzenie jest opłacane w okresach rozliczeniowych np. okresach miesięcznych;
  • Wynagrodzenie powinno obejmować przeniesienie praw autorskich lub udzielenie stosownych licencji na rzecz Usługobiorcy;
• Przeniesienie praw autorskich. Usługobiorca powinien pozyskać prawa autorskie do rezultatów usług. Czy będzie to nabycie praw autorskich czy też licencja (wyłączna/niewyłączna), zależy od konkretnego przypadku, aczkolwiek z punktu widzenia Usługobiorcy pożądane jest nabycie praw autorskich. Należy w sposób szczególnie skrupulatny odnieść się do pól eksploatacji, które powinny być w umowie określone w sposób wyczerpujący;

Postanowienia dodatkowe

• Określenie zasad współpracy stron – np. obowiązek przekazywania danych, informacji, udostępniania dokumentacji, dodanie koordynatorów Stron, udzielenia stosownych dostępów personelowi Usługodawcy, czy obowiązek przedstawiania logów przez Usługobiorcę i wszystkich informacji niezbędnych do zdiagnozowania błędów i rzetelnego świadczenia usług przez Usługodawcę;
• Określenie procedury odbiorowej – zwłaszcza poprzez akceptacje raportów realizowanych roboczodni / roboczogodzin, a w przypadku zamówień na rozwój, zwykle na podobnych zasadach, jak w przypadku projektów IT.
• Wskazanie procedury zgłaszania błędów w oprogramowaniu wraz z określeniem osób, które po stronie Usługobiorcy są do tego uprawnione – typowymi kanałami komunikacji jest np. email, zgłoszenie przez specjalnie dostosowaną do tego platformę, telefon. Należy również przewidzieć procedurę potwierdzania tego zgłoszenia przez Usługodawcę;
• Określenie poziomu świadczenia usług utrzymaniowych – w praktyce jest to po prostu określenie trybu zgłaszania i przyjmowania zgłoszeń wykrytych błędów, określenie czasów reakcji uwzględniającej też porę dnia (w przypadku krytycznego oprogramowania mogą to być także pory noce), czasu naprawy błędów (w zależności od ich rodzaju np. Błędy krytyczne naprawiane w kilka godzin, Błędy zwykłe do kilku dni roboczych);
• Określenie dostępności usług utrzymania – np. dni robocze, w godzinach 8-18;
• Określenie kar umownych za naruszenie procedury/czasów reakcji – np. jako procent wynagrodzenia Usługodawcy za każdą rozpoczętą godzinę opóźnienia; z punktu widzenia Usługodawcy karę należy limitować np. do maksymalnej wysokości miesięcznego wynagrodzenia;
• Wyłączenie odpowiedzialności Usługodawcy za określone kategorie usterek – np. spowodowanych nieprawidłowym działaniem Usługobiorcy lub podmiotów trzecich; Strony powinny także wyłączyć odpowiedzialność i stosowanie umowy do modyfikacji oprogramowania dokonanej samodzielnie przez Usługobiorcę;
• Uregulowanie zasad świadczenia usług rozwojowych - jeśli strony chcą je wprowadzić np. opisanie procedury odrębnych zamówień (do umowy można dołączyć szablon takiego zamówienia). Strony powinny określić również czy usługi te będą realizowane po z góry określonej stawce czy będzie to przedmiotem każdorazowej wyceny oraz sprecyzować, czy Wykonawca może odmówić ich realizacji;
• Ograniczenie Odpowiedzialności - strony mogą przewidzieć katalog sytuacji, których zaistnienie ogranicza odpowiedzialność Usługodawcy np. okoliczności siły wyższej, braku współpracy Usługobiorcy przy usuwaniu błędów, nieprawidłowego korzystania z oprogramowania wbrew zaleceniom Usługodawcy, etc. Z punktu widzenia Usługodawcy korzystne jest, aby ewentualnie zastrzeżone kary umowne zostały ograniczone (cap) np. do poziomu kwoty otrzymanego wynagrodzenia; w praktyce dochodzi również najczęściej do wyłączenia rękojmi;
• Kwestia poufności - Strony powinny zadbać, aby umowa zawierała zobowiązanie do zachowania poufności co do wszystkich informacji, które Strony chcą chronić przed wykorzystaniem lub ujawnieniem, w szczególności informacji, które stanowią tajemnicę przedsiębiorstwa (konieczne jest zdefiniowanie tego pojęcia w umowie). W praktyce, jest to istotniejsze z punktu widzenia Usługobiorcy;
• Zakaz przejmowania personelu – z punktu widzenia Usługodawcy jest to istotna klauzula, która pod rygorem kary umownej zakazuje przejmowania osób zaangażowanych w projekt u Usługobiorcy; zabezpiecza przed utratą kluczowego personelu;
• Procedura eskalacji sporu - np. powołanie komitetu sterującego i klauzula dot. Polubownego rozwiązywania konfliktów lub klauzula mediacyjna;

Dodatkowe pytania i problemy

• Prawidłowe zdefiniowanie czasów reakcji na poszczególne kategorie błędów, powinny być one liczone od przekazania przez Zamawiającego informacji niezbędnych do usunięcia błędów;
• Doprecyzowanie zasad współpracy między stronami; umowa utrzymaniowa jak mało która wymaga ścisłej współpracy Stron celem prawidłowego zdiagnozowania problemów i dostarczenia rozwiązania usuwającego usterkę;
• Właściwe zdefiniowane kategorii błędów (usterek) - rozróżnienie na krytyczne i zwykłe oraz skorelowanie z nimi czasów reakcji; próba rozszerzenia definicji błędów krytycznych może prowadzić do nadmiernego obciążenia Wykonawcy;