SLA w outsourcingu IT. Czas reakcji a czas rozwiązania
- co naprawdę powinna zawierać umowa?

"Czas reakcji na awarię: 15 minut." Brzmi dobrze. Problem w tym, że po 15 minutach możesz otrzymać jedynie informację: "zgłoszenie zostało przyjęte".

Dlatego porównując oferty outsourcingu IT, nie warto patrzeć wyłącznie na jedną liczbę w tabeli SLA. Znacznie ważniejsze jest to, co dostawca rozumie przez reakcję, kiedy rozpoczyna pracę nad awarią, jak długo może trwać przywrócenie usługi i co dzieje się, gdy problem zależy od zewnętrznego operatora lub producenta.

Dobre SLA nie powinno być marketingową obietnicą. Powinno jasno określać zasady działania wtedy, gdy infrastruktura rzeczywiście przestanie działać.

Czym właściwie jest SLA w outsourcingu IT?

SLA, czyli Service Level Agreement, określa uzgodniony poziom świadczenia usług IT.

Może być osobnym dokumentem albo częścią umowy na stałą obsługę informatyczną. W praktyce powinno odpowiadać przynajmniej na kilka podstawowych pytań:

Bez takich zapisów deklaracja "zapewniamy szybkie wsparcie" w praktyce niewiele znaczy.

Dla klienta SLA powinno być przede wszystkim odpowiedzią na jedno pytanie: co wydarzy się po jego stronie, kiedy przestanie działać coś naprawdę ważnego?

Czas reakcji a czas rozwiązania - to nie jest to samo

To jedna z najważniejszych rzeczy, które warto sprawdzić przed podpisaniem umowy z firmą IT.

Czas reakcji

Czas reakcji, czyli Response Time, określa czas od prawidłowego zgłoszenia incydentu do podjęcia przez dostawcę określonej w umowie reakcji.

I właśnie słowo "określonej" jest tutaj kluczowe.

SLA powinno precyzować, czy reakcją jest:

To ogromna różnica.

Załóżmy, że o 9:00 przestaje działać system ERP. O 9:03 system ticketowy automatycznie odpowiada: "Zgłoszenie nr 12345 zostało przyjęte."

Jeżeli umowa uznaje to za reakcję, dostawca może formalnie wykazać czas reakcji wynoszący 3 minuty, mimo że żaden administrator nie rozpoczął jeszcze diagnostyki.

Dlatego w PRO-Admin przez reakcję rozumiemy realne podjęcie zgłoszenia przez człowieka, a nie automatyczną wiadomość wysłaną przez system.

Czas rozwiązania

Czas rozwiązania, czyli Resolution Time, określa czas potrzebny na rozwiązanie incydentu.

Tutaj pojawia się jednak kolejny problem. Nie każdą awarię można naprawić w z góry określonym czasie.

Jeżeli uszkodzi się fizyczny dysk, przestanie działać łącze operatora albo problem znajduje się w oprogramowaniu zewnętrznego producenta, administrator może nie mieć pełnej kontroli nad czasem usunięcia przyczyny.

Dlatego dobre SLA powinno rozróżniać kilka pojęć:

• › Czas reakcji - kiedy rozpoczynamy obsługę zgłoszenia
• › Czas przywrócenia usługi - kiedy użytkownicy mogą ponownie pracować
• › Czas pełnego rozwiązania - kiedy usunięta zostaje właściwa przyczyna problemu

To nie zawsze ten sam moment.

I właśnie dlatego dobrze napisane SLA powinno uwzględniać nie tylko naprawę, ale również skuteczne obejście problemu.

Priorytety P1, P2, P3 i P4

Nie każde zgłoszenie powinno być obsługiwane w taki sam sposób.

Awaria systemu ERP dla całej firmy nie może mieć tego samego priorytetu co prośba o utworzenie nowego konta użytkownika.

Dlatego najczęściej stosuje się kilka poziomów, z odpowiednio dobranymi do nich parametrami czasowymi. Przykładowo:

To tylko przykład. Właściwe parametry powinny wynikać z potrzeb konkretnej organizacji.

Firma produkcyjna pracująca 24/7 potrzebuje zupełnie innego SLA niż biuro pracujące od poniedziałku do piątku od 8:00 do 16:00.

Najważniejsze pytanie: od kiedy właściwie liczymy czas?

To jeden z zapisów, który potrafi całkowicie zmienić znaczenie SLA.

Załóżmy, że awaria wydarzyła się w sobotę o 10:00. Umowa przewiduje reakcję P1 w ciągu jednej godziny, ale SLA obowiązuje wyłącznie w dni robocze od 8:00 do 16:00.

Formalnie dostawca może rozpocząć obsługę dopiero w poniedziałek.

Dlatego umowa powinna jasno określać:

Monitoring 24/7 nie oznacza automatycznie wsparcia technicznego 24/7. To również warto rozróżnić.

Monitoring może przez całą dobę wykrywać problemy i generować alerty, podczas gdy właściwa obsługa administratora może podlegać innym zasadom wynikającym z umowy.

Jak powinno wyglądać zgłoszenie awarii?

SLA powinno jednoznacznie określać oficjalne kanały zgłoszeń. Może to być:

To ważniejsze, niż może się wydawać. Wiadomość wysłana prywatnie administratorowi na komunikatorze o 22:00 niekoniecznie musi być formalnym zgłoszeniem incydentu.

Dobrą praktyką jest również ustalenie osobnego kanału dla awarii krytycznych. P1 nie powinno czekać w tej samej kolejce co prośba o instalację drukarki.

Co z awariami zależnymi od innych dostawców?

To kolejny element, którego często brakuje w umowach.

Administrator może bardzo szybko ustalić, że przyczyną problemu jest:

Dostawca IT nie jest w stanie zagwarantować, że zewnętrzna firma naprawi swój system w ciągu dwóch godzin.

Może jednak zagwarantować coś znacznie bardziej wartościowego: że będzie aktywnie prowadził incydent, kontaktował się z dostawcą, eskalował problem, szukał obejścia i informował klienta o sytuacji.

Dobre SLA powinno więc określać nie tylko terminy, ale również odpowiedzialność za koordynację incydentu.

Klient nie powinien podczas awarii sam zastanawiać się, czy ma dzwonić do operatora, producenta ERP, Data Center czy dostawcy backupu.

Procedura eskalacji

Co dzieje się, gdy pierwsza osoba nie potrafi rozwiązać problemu?

Umowa powinna określać ścieżkę eskalacji. Przykładowo:

1. 1 Administrator rozpoczyna diagnostykę
2. 2 Problem zostaje przekazany do specjalisty odpowiedzialnego za dany obszar
3. 3 W razie potrzeby angażowany jest zewnętrzny producent lub operator
4. 4 Przy długotrwałym incydencie klient otrzymuje regularne informacje o statusie
5. 5 Po awarii krytycznej wykonywana jest analiza przyczyny

Szczególnie ostatni punkt jest ważny.

Naprawienie awarii to jedno. Ustalenie, dlaczego do niej doszło i jak zapobiec jej powtórzeniu, to dopiero profesjonalna administracja IT.

Co powinno znaleźć się w raporcie SLA?

Jeżeli parametry są mierzalne, klient powinien mieć możliwość ich zweryfikowania.

Raport miesięczny może zawierać między innymi:

Dzięki temu SLA przestaje być tabelą zapisaną w umowie i staje się rzeczywistym wskaźnikiem jakości współpracy.

Kary umowne i service credits

Co dzieje się, gdy dostawca regularnie nie dotrzymuje SLA? Umowa powinna to określać.

Jednym z rozwiązań są service credits, czyli obniżenie miesięcznego wynagrodzenia w przypadku niedotrzymania określonych parametrów.

Nie chodzi jednak o stworzenie systemu kar za każde spóźnienie o kilka minut. Znacznie ważniejsze jest zabezpieczenie klienta przed sytuacją, w której dostawca przez kilka miesięcy deklaruje określony poziom usług, ale regularnie go nie realizuje.

Warto więc określić również warunki renegocjacji lub rozwiązania umowy w przypadku powtarzających się naruszeń SLA.

7 rzeczy, które sprawdzilibyśmy przed podpisaniem umowy

Jeżeli porównujesz oferty kilku firm IT, nie patrz wyłącznie na cenę abonamentu i największą liczbę wpisaną w tabeli SLA.

Sprawdź:

Jeżeli umowa nie odpowiada na te pytania, nawet bardzo atrakcyjne "SLA 15 minut" może mieć niewielką wartość. Pełną listę pytań do nowego dostawcy znajdziesz w artykule 10 pytań, które warto zadać firmie IT przed podpisaniem umowy.

Czy zawsze potrzebujesz SLA 15 minut?

Nie. I to również jest ważne.

Im bardziej restrykcyjne SLA, tym większe zasoby musi utrzymywać dostawca i tym wyższy będzie koszt usługi.

Jeżeli awaria danego systemu przez dwie godziny nie powoduje istotnych strat, płacenie za reakcję w 15 minut może nie mieć ekonomicznego sensu.

Z drugiej strony, jeżeli zatrzymanie systemu ERP oznacza zatrzymanie magazynu, produkcji albo sprzedaży, różnica pomiędzy reakcją po 15 minutach a reakcją następnego dnia może oznaczać dziesiątki tysięcy złotych.

SLA powinno wynikać z kosztu przestoju, a nie z tego, która liczba najlepiej wygląda w ofercie.

Jak wygląda SLA w PRO-Admin?

Nie proponujemy jednego poziomu SLA każdej firmie.

Najpierw ustalamy:

Na tej podstawie dobieramy model obsługi.

Dzięki temu klient nie płaci za parametry, których nie potrzebuje, a systemy kluczowe dla działalności otrzymują odpowiedni priorytet.

Jeżeli przejmujemy istniejące środowisko, współpracę zaczynamy od audytu infrastruktury. Pozwala nam to określić, za które elementy możemy realnie wziąć odpowiedzialność i gdzie przed uruchomieniem określonego SLA potrzebne są dodatkowe działania.

FAQ - SLA w outsourcingu IT

Podsumowanie

Dobre SLA nie powinno obiecywać rzeczy niemożliwych.

Powinno natomiast bardzo dokładnie określać, co wydarzy się od momentu zgłoszenia awarii do przywrócenia działania firmy.

Czas reakcji jest ważny, ale sam w sobie niewiele mówi. Znacznie istotniejsze jest to, czy ktoś rzeczywiście rozpocznie diagnostykę, jak wygląda eskalacja, kto koordynuje działania z innymi dostawcami i jak szybko zostanie przywrócona możliwość pracy.

Dlatego przed podpisaniem umowy outsourcingu IT warto przeczytać tabelę SLA znacznie dokładniej niż samą ofertę cenową.