Umowa z firmą IT — na co uważać

Na co uważać w umowie IT — krótka odpowiedź

W umowie z firmą IT sprawdź pięć rzeczy. To zapisany czas reakcji i czas naprawy, okres wypowiedzenia oraz kary umowne z limitem odpowiedzialności. Do tego umowa powierzenia danych i zwrot danych oraz dostępów po zakończeniu współpracy. Brak któregokolwiek punktu to sygnał ostrzegawczy.

Te pięć punktów odróżnia umowę, która Cię chroni, od takiej, która chroni tylko dostawcę. Reszta artykułu rozkłada każdy z nich na pytania, które możesz zadać wprost na rozmowie.

Jedna uwaga na start. Nie jesteśmy kancelarią prawną. Ten tekst to lista kontrolna kupującego, nie porada prawna — gotową umowę zawsze pokaż swojemu prawnikowi przed podpisem.

SLA z liczbami, nie obietnicami

SLA to część umowy, w której dostawca zapisuje, jak szybko zareaguje na zgłoszenie i kiedy przywróci działanie usługi. „Szybkie reagowanie” jest niemierzalne i jest zaproszeniem do sporu. Liczy się to, co da się sprawdzić zegarkiem.

Dobra umowa rozróżnia dwa terminy. Czas reakcji to moment, w którym dostawca potwierdza zgłoszenie i zaczyna się nim zajmować. Czas naprawy to moment, w którym usługa znów działa. To nie to samo i nie wolno ich mylić.

Umowa powinna też dzielić zgłoszenia na kategorie: krytyczne, poważne i drobne. Inny czas reakcji należy się na padnięcie całego serwera, inny na jedną nieczynną drukarkę w księgowości. Bez kategorii każde zgłoszenie traktowane jest tak samo — czyli najczęściej zbyt wolno.

Przykładowo, umowa może zakładać reakcję w 4 godziny na zgłoszenie poważne i w 1 godzinę na krytyczne. To liczby do zilustrowania, jak czytać SLA — nie nasza deklaracja. Naszą konkretną gwarancję ustalamy przed podpisem i wpisujemy do umowy. Chodzi o to, żebyś przy każdej kategorii widziała liczbę, nie przymiotnik.

Czas reakcji a czas naprawy

To rozróżnienie myli najwięcej osób, a kosztuje najwięcej. Dostawca może odpowiedzieć na Twoje zgłoszenie w kwadrans i naprawiać problem trzy dni — formalnie dotrzymując czasu reakcji. Dlatego oba terminy muszą być w umowie osobno.

Tak wygląda różnica między nimi:

• Co mierzy — czas reakcji: ile czeka zgłoszenie na potwierdzenie i podjęcie tematu. Czas naprawy: ile trwa przywrócenie działania usługi.
• Kiedy się kończy — czas reakcji: gdy dostawca potwierdza i zaczyna pracę. Czas naprawy: gdy usługa znów działa.
• Co znaczy dla Ciebie — czas reakcji: wiesz, że ktoś już się tym zajął. Czas naprawy: wiesz, kiedy firma wróci do pracy.
• Czego pilnować w umowie — czas reakcji: rozpisany na kategorie zgłoszeń. Czas naprawy: podany osobno, bo sama reakcja niczego nie naprawia.

Sam czas reakcji bez czasu naprawy to częsta pułapka. Wygląda dobrze w tabeli, a nie mówi, kiedy odzyskasz działający system. Jeśli czasu naprawy nie da się zagwarantować dla każdej awarii, umowa powinna przynajmniej określać sposób jego liczenia i wyłączenia.

Czas wypowiedzenia i lock-in

Sprawdź okres wypowiedzenia i to, czy umowa jest na czas określony czy nieokreślony. Roczne zobowiązanie z karą za wcześniejsze wyjście wygląda inaczej niż umowa z miesięcznym wypowiedzeniem. Ani jedno, ani drugie nie jest złe — złe jest podpisanie tego, nie wiedząc, co podpisujesz.

Najdroższy ukryty koszt to nie nowy dostawca. To migracja. Jeśli poprzednia firma trzyma Twoje hasła, konta i dokumentację techniczną, zmiana dostawcy potrafi się ciągnąć tygodniami. Twoi pracownicy w tym czasie eskalują wszystko do Ciebie.

Dlatego najważniejszy zapis to obowiązek zwrotu po zakończeniu współpracy. Umowa musi jasno mówić, że dostawca odda Ci wszystko, co pozwala przejąć IT bez paraliżu:

• hasła i dostępy do wszystkich kont oraz systemów
• dokumentację sieci, serwerów i konfiguracji
• kopie danych w czytelnym, otwartym formacie
• wskazanie osoby do kontaktu na czas przekazania

Bez tego zapisu jesteś związana z dostawcą nie umową, tylko brakiem dostępu do własnej infrastruktury. To najgorszy rodzaj lock-inu — czyli uzależnienia od jednego dostawcy, którego nie widać przy podpisie.

Kary umowne i limit odpowiedzialności

SLA bez konsekwencji to tylko słowa. Umowa musi mówić, co się dzieje, gdy dostawca nie dotrzyma zapisanych czasów. Najczęściej są to dwa mechanizmy: kary umowne albo upusty na fakturze, po angielsku service credits.

Kara umowna to z góry ustalona kwota za niedotrzymanie warunku — nie musisz wtedy udowadniać wysokości szkody. Upust na fakturze to obniżenie miesięcznej opłaty proporcjonalnie do tego, o ile dostawca przekroczył SLA. Oba rozwiązania są w porządku, byle były w umowie wprost.

Druga strona tego samego zapisu to limit odpowiedzialności, czyli cap. To górna granica kwoty, do której dostawca odpowiada za szkody. Dostawcy ją stosują i to normalne — ważne, żeby limit nie był symboliczny. Cap na poziomie jednej miesięcznej opłaty przy poważnej awarii niewiele Ci daje.

Umowa powierzenia danych (RODO)

Jeśli firma IT ma dostęp do skrzynek e-mail, bazy klientów albo systemu sprzedaży, w świetle RODO staje się podmiotem przetwarzającym Twoje dane. Wtedy potrzebna jest umowa powierzenia przetwarzania danych — osobny dokument albo wyraźna część umowy głównej.

Ta umowa jest obowiązkowa. Wymaga jej artykuł 28 RODO od administratora danych, czyli od Twojej firmy. Dotyczy to każdego podmiotu, który przetwarza dane w jego imieniu. Dopuszczalna jest forma pisemna lub elektroniczna; ważne, żeby była udokumentowana.

I tu rzecz, którą trzeba powiedzieć wprost. Za brak tej umowy odpowiada administrator, czyli Ty, a nie dostawca IT. To Twoja firma naraża się na karę, jeśli powierza dane bez podstawy.

Dlatego umowa powierzenia jest punktem, którego nie pomijasz. Sprawdź, czy dostawca sam ją proponuje. Firma, która zna RODO, przynosi gotowy wzór — to dobry sygnał, że wie, z czym pracuje.

Procedura zgłoszeń i eskalacji

Nawet najlepsze SLA jest puste, jeśli nie wiadomo, jak zgłosić problem. Umowa musi określać kanał zgłoszeń: czy to system ticketowy, adres help-desk, czy numer telefonu. Help-desk to punkt, w którym Twoi pracownicy zgłaszają usterki.

Drugi element to ścieżka eskalacji. Gdy zgłoszenie utyka, musisz wiedzieć, do kogo trafia wyżej i kto rozstrzyga w sporze. Bez tego każde trudniejsze zgłoszenie wraca do Ciebie, dokładnie tak jak przy starym dostawcy.

Dobra procedura odpowiada na trzy pytania:

1. Gdzie zgłaszam problem i w jakich godzinach przyjmowane są zgłoszenia.
2. Jak zgłoszenie jest klasyfikowane — kto decyduje, czy awaria jest krytyczna czy drobna.
3. Co się dzieje, gdy nie zgadzam się z reakcją — kto eskaluje i kto ma ostatnie słowo.

Zapis „reakcja w możliwie krótkim czasie, w miarę możliwości dostawcy” to mina. Brzmi uprzejmie, a nie daje Ci żadnego punktu zaczepienia, gdy coś nie działa, a Ty czekasz.

Zakres usług i twarde wyłączenia

Ostatni punkt to zakres: co dokładnie wchodzi w abonament, a co jest płatne osobno. Tu rodzi się najwięcej sporów po podpisie. Każda strona pamięta inaczej, czy dane zgłoszenie było „w cenie”.

Dlatego umowa powinna wymieniać wprost rzeczy objęte stałą opłatą i rzeczy poza nią. Typowe wyłączenia to nowe wdrożenia, zakup sprzętu, prace projektowe albo wsparcie systemów, których dostawca nie zna. To normalne — byle było napisane, nie domyślne.

Uczciwie określony zakres działa na Twoją korzyść. Dostawca, który sam zaznacza, czego nie robi w abonamencie, jest wiarygodniejszy niż taki, który obiecuje „wszystko”. „Wszystko” w umowie zwykle znaczy „dogadamy się później”, a „później” oznacza fakturę, której się nie spodziewałaś.

Firmy z Legnicy i Lubina często pokazują nam projekt umowy z innej oferty przed podpisem. Najczęściej brakuje w nim właśnie jasnego zakresu i zwrotu danych. Jeśli porównujesz kilka ofert, zacznij od audytu dojrzałości cyfrowej. Pokaże, na czym naprawdę stoisz, zanim w ogóle dojdzie do umowy.

Częste błędy przy podpisywaniu umowy IT

Te same pomyłki wracają w kolejnych umowach, które oglądamy. Większość da się wyłapać jednym czytaniem projektu, jeśli wiesz, czego szukać.

• Branie „szybkiego reagowania” za SLA — bez liczb i kategorii to puste zdanie.
• Patrzenie tylko na czas reakcji, a nie na czas naprawy — reakcja niczego nie naprawia.
• Brak zapisu o zwrocie haseł, kont i danych po zakończeniu współpracy.
• Pominięcie umowy powierzenia danych — ryzyko spada na Twoją firmę, nie na dostawcę.
• SLA bez kar i bez limitu odpowiedzialności — zobowiązanie, którego nie da się wyegzekwować.
• Niejasny zakres abonamentu — źródło sporów o każdą większą usterkę.

Mały przykład z życia. Firma logistyczna spod Głogowa podpisała umowę z ładnym SLA, ale bez zapisu o zwrocie dostępów. Po roku chciała zmienić dostawcę — i okazało się, że hasła do serwera pocztowego ma tylko stara firma. Przejęcie zajęło sześć tygodni zamiast kilku dni.

Ten jeden brakujący akapit kosztował ich więcej niż cała roczna różnica w cenie między dostawcami. Dlatego zwrot danych jest na naszej liście tak wysoko.

Skąd wziąć dobrą umowę na obsługę IT

Dobrą umowę najłatwiej rozpoznać po tym, że dostawca sam podsuwa Ci te zapisy, a nie zgadza się na nie z oporem. Firma, która zna swoją robotę, nie boi się wpisać liczb do SLA ani obowiązku zwrotu danych.

Jeśli dopiero porównujesz dostawców, zacznij od szerszego obrazu. Nasz przewodnik po outsourcingu IT pokazuje, jak wygląda całe przejście i co wchodzi w stałą opłatę. Warto też wiedzieć, czym różni się outsourcing od zwykłej obsługi IT — bo to zmienia, czego w ogóle żądasz w umowie.

A jeśli szukasz jednego partnera zamiast kilku dostawców, zobacz, jak działa outsourcing IT dla firm na Dolnym Śląsku. Stała opłata, jeden opiekun, SLA na piśmie — dokładnie to, czego pilnujesz w umowie.

Niezależnie od tego, kogo wybierzesz, trzymaj się jednej zasady. Gotową umowę pokaż swojemu prawnikowi. My pomożemy Ci zrozumieć część techniczną — SLA, zakres, zwrot danych — ale część prawną zostaw kancelarii.