Umowa SLA na obsługę IT — co naprawdę znaczy

To rozróżnienie przesądza o wartości całego dokumentu, a mimo to ginie w rozmowie handlowej. Czas reakcji to termin, w którym ktoś potwierdza zgłoszenie i zaczyna się nim zajmować. Czas naprawy to termin, w którym problem przestaje istnieć. Zobowiązanie do czasu reakcji jest w tych dokumentach regułą, zobowiązanie do czasu naprawy — wyjątkiem; warto sprawdzić, czy w Waszej umowie w ogóle się pojawia.

Ma to dobre uzasadnienie. Nikt nie wie z góry, czy awaria bierze się z padniętego dysku, z nocnej aktualizacji producenta systemu, czy z przerwy u operatora, na którego dostawca IT nie ma wpływu. Zobowiązanie do usunięcia każdej awarii w określonym czasie oznaczałoby przyjęcie odpowiedzialności za cudze systemy i za fizykę sprzętu — dlatego umowa obiecująca czas naprawy dla wszystkiego jest albo bardzo wąsko zakrojona w miejscu, którego nie czytacie, albo nie jest poważna.

Nie znaczy to, że o naprawie nie da się zapisać niczego. Da się zobowiązać do działania: do pracy bez przerwy nad zgłoszeniem krytycznym, do informowania o postępach w ustalonych odstępach, do zaproponowania obejścia, gdy właściwa naprawa wymaga czasu albo części. Warto też sprawdzić, czy umowa definiuje moment zamknięcia zgłoszenia — i czy zamyka je dostawca, czy osoba, która je zgłosiła. To drugie zdarza się rzadziej i bywa warte więcej niż niejeden zapis o terminie.

Czas reakcji bez poziomów pilności nie znaczy nic, bo jednym terminem nie da się objąć i poczty, która przestała działać w całej firmie, i prośby o konto dla stażysty. Dlatego każde sensowne SLA dzieli zgłoszenia na poziomy — dwa albo trzy, nie więcej. Przy większej liczbie poziomów wybór przestaje być oczywisty dla osoby, która zgłasza problem raz na kwartał — a wtedy albo sięga po najwyższy, albo wybiera na chybił trafił. Model, w którym wszystko jest krytyczne, nie ma priorytetów w ogóle.

Podział, którym się posługujemy, opiera się na jednym pytaniu: kto przez ten problem nie pracuje.

Każdy termin w SLA biegnie w jakichś godzinach i to, w jakich, zmienia go bardziej niż sama liczba. Zapis „reakcja w ciągu 12 godzin” i zapis „reakcja w ciągu 12 godzin roboczych” wyglądają niemal identycznie. Przy zgłoszeniu w piątek o szesnastej pierwszy kończy się tej samej nocy, a drugi — przy dniu pracy od ósmej do szesnastej — dopiero we wtorek w południe. Ta sama liczba, ponad trzy doby różnicy.

Stąd drugie pytanie: w jakich godzinach dostawca w ogóle pracuje. Łatwo pomylić trzy różne rzeczy — godziny przyjmowania zgłoszeń, godziny, w których biegnie termin reakcji, i godziny, w których ktoś faktycznie pracuje nad problemem. Umowa może mieć całodobowy kanał zgłoszeń i jednocześnie liczyć terminy wyłącznie w dni robocze; to uczciwe rozwiązanie, pod warunkiem że jest napisane wprost, a nie domyślne.

Dla firmy pracującej od poniedziałku do piątku w godzinach biurowych okno liczone w godzinach roboczych zwykle wystarcza i jest tańsze. Dla firmy, która wydaje towar w sobotę albo pracuje na zmiany, ten sam zapis jest pułapką — i trzeba o tym powiedzieć przy pierwszej rozmowie, a nie po pierwszym weekendzie. Rozszerzenie godzin zawsze kosztuje, bo ktoś musi być dostępny niezależnie od tego, czy cokolwiek się wydarzy.

Dopóki nie zobaczycie listy, „pełna obsługa informatyczna firmy” jest nazwą, a nie zakresem. Załącznik z zakresem to dokument, do którego obie strony wrócą w dniu sporu, więc czyta się go uważniej niż paragrafy o poufności. Dobrze napisany ma dwie kolumny: co mieści się w miesięcznym ryczałcie i co jest rozliczane osobno.

Granica między jednym a drugim jest granicą między utrzymaniem a projektem. Zakładanie kont, aktualizacje, pomoc przy codziennych problemach, nadzór nad kopiami zapasowymi i przeglądy uprawnień to utrzymanie — i w każdym planie powinno być jasno powiedziane, które z nich mieszczą się w opłacie, a które są rozszerzeniem zakresu. Migracja poczty, wymiana serwera, przebudowa sieci w nowym biurze czy wdrożenie systemu branżowego to projekty z własnym harmonogramem i wyceną. Dostawca, który twierdzi, że migracja mieści się w abonamencie za helpdesk, albo doliczył ją po cichu do ryczałtu, albo nie zamierza zrobić jej porządnie.

Wyłączenia czyta się osobno, bo to tam mieszkają niespodzianki: sprzęt bez wsparcia producenta, oprogramowanie branżowe, którego dostawca zniknął z rynku, praca na miejscu poza ustalonym obszarem, koszty licencji i części. Samo wyłączenie nie jest niczym złym — każdy zakres gdzieś się kończy. Złe jest wyłączenie, o którym dowiadujecie się przy pierwszej fakturze za „prace dodatkowe”.

Termin, którego nikt nie mierzy, nie jest terminem. Jeżeli zgłoszenia przychodzą telefonicznie i na prywatną skrzynkę informatyka, to po pół roku nikt nie odpowie na proste pytanie: ile zgłoszeń wpłynęło, ile dostało odpowiedź w umówionym czasie i które przekroczyły termin. Zapis o raportowaniu nie jest więc dodatkiem do SLA — to mechanizm, który czyni resztę dokumentu egzekwowalną.

W praktyce wystarczają trzy rzeczy: jeden zdefiniowany kanał zgłoszeń, rejestr z datą wpłynięcia i datą pierwszej odpowiedzi oraz okresowe podsumowanie, które ktoś po Waszej stronie czyta. Podsumowanie ma sens, gdy odpowiada na pytania biznesowe — co się wydarzyło, co wymaga Waszej decyzji, co planujemy — a nie gdy jest wydrukiem z systemu zgłoszeń. Raport, którego nikt nie otwiera, jest kosztem po obu stronach.

Jest jeszcze jedna rzecz, o którą prawie nikt nie pyta: czyją własnością jest ta historia. Jeśli rejestr zgłoszeń żyje wyłącznie w systemie dostawcy, w dniu rozstania znika razem z nim — a to wiedza o Waszej firmie, nie o jego pracy. Zapis, że przy zakończeniu współpracy dostajecie eksport historii zgłoszeń, kosztuje jedno zdanie i bywa wart znacznie więcej.

Klauzula wypowiedzenia jest fragmentem czytanym najrzadziej, a wpływa na realny koszt współpracy mocniej niż stawka. Dostawca, od którego nie da się odejść bez kosztownego chaosu, nie musi się starać — i zwykle sam o tym wie. Rozsądny okres wypowiedzenia nie jest więc uprzejmością, tylko deklaracją, że umowa zamierza bronić się jakością.

Wyjście z obsługi IT nie jest jedną czynnością, tylko listą rzeczy, które muszą zmienić właściciela. Ta lista powinna znaleźć się w umowie, zanim będzie potrzebna.

Pracujemy na trzech poziomach zakresu — IT Essential, IT Business i IT Critical — oraz na trzech opisanych wyżej poziomach pilności. Baza umowna stałej obsługi to reakcja w ciągu trzech dni roboczych na zgłoszenie standardowe i w ciągu dwunastu godzin na zgłoszenie pilne. To terminy z umowy, a nie deklaracja dobrej woli. Kanał zgłoszeń pilnych jest dostępny stale, ale zakres pracy poza godzinami roboczymi zależy od planu i od tego, co zapisaliśmy w SLA.

Krótszych okien reakcji dla planów IT Business i IT Critical nie publikujemy w tabeli i robimy to świadomie. Okno reakcji jest zobowiązaniem do gotowości, a gotowość zależy od liczby użytkowników, godzin pracy firmy, tego, czy w środowisku stoi serwer, od którego wszystko zależy, i od tego, jak daleko trzeba jechać, gdy zdalnie nie da się nic zrobić. Liczba wpisana na stronę przed tą rozmową byłaby prawdziwa dla jednej firmy i fałszywa dla dziesięciu innych, czyli byłaby hasłem reklamowym, a nie zobowiązaniem. Ustalamy ją po audycie i wpisujemy do SLA, gdzie ma skutki.

Z tego samego powodu nie zobowiązujemy się do czasu usunięcia awarii dla wszystkiego. Zobowiązujemy się do reakcji, do pierwszeństwa zgłoszeń krytycznych, do informowania o postępach i do szukania obejścia, gdy naprawa wymaga czasu albo części. Tam, gdzie firma potrzebuje twardego terminu odtworzenia jednego konkretnego systemu, jesteśmy gotowi o nim rozmawiać i zapisać go osobno — tylko wtedy taki termin jest wykonalny. Resztę trzyma jeden kanał zgłoszeń i rejestr, comiesięczne podsumowanie w planie IT Business i formalne raportowanie w IT Critical.

Okres wypowiedzenia ustalamy przed startem i proponujemy taki, przy którym rezygnacja nie jest karą. Dokumentacja środowiska powstaje od pierwszych tygodni i jest Wasza, a konta, domeny i licencje rejestrujemy na Waszą firmę. Umowa ma być powodem, dla którego zostajecie, a nie powodem, dla którego nie możecie odejść.