Obsługa informatyczna firm - umowa SLA i priorytety zgłoszeń

Obsługa informatyczna firm - co reguluje umowa SLA

Coraz więcej przedsiębiorstw powierza informatykę zewnętrznemu dostawcy zamiast utrzymywać własny dział. Umowa główna określa cenę i okres współpracy, ale to załącznik SLA mówi, co dokładnie dostawca gwarantuje. Bez niego zapis „zapewniamy wsparcie IT” można spełnić odpowiedzią po trzech dniach.

SLA składa się z kilku elementów, które da się zmierzyć i porównać z rzeczywistością. Każdy z nich ma wartość liczbową albo warunek, który dostawca lub klient potrafi potwierdzić danymi z systemu zgłoszeń. Zakres podstawowy tej usługi, czyli opiekę nad stanowiskami i licencjami, opisuje osobny tekst o obsłudze informatycznej w zakresie podstawowym.

Reguła: parametr bez sposobu pomiaru nie jest zobowiązaniem, tylko deklaracją.

Podobny mechanizm stosuje się poza IT. Umowę o czasach obsługi przewoźników w module awizacji opisuje tekst o SLA z przewoźnikami w systemie VSS.net, gdzie parametrem jest czas na rampie zamiast czasu reakcji helpdesku.

Zgłoszenia i priorytety

Priorytet decyduje o tym, ile czasu ma dostawca i w jakiej kolejności zgłoszenia trafiają do techników. Bez jasnej klasyfikacji spór o pilność wybucha przy każdej awarii: użytkownik uważa, że jego problem jest najważniejszy, a dostawca ma dziesięć innych zgłoszeń.

Wpływ i pilność

Priorytet wynika z dwóch pytań. Wpływ mówi, jak szeroki jest zasięg problemu wśród osób i procesów. Pilność mówi, jak szybko rośnie szkoda, jeśli nic się nie zmieni. Połączenie obu wartości w macierzy usuwa uznaniowość: technik nie ocenia „na oko”, tylko odczytuje priorytet z tabeli.

Poziomy priorytetu i limity czasu

Umowy SLA zwykle rozróżniają cztery poziomy, od krytycznego do niskiego. Poniższa tabela pokazuje przykładowe przypisanie zgłoszeń i typowe limity. Konkretne wartości ustala się w umowie, a czasy z tabeli są ilustracją, nie zapisem, który obowiązuje w każdej firmie.

Kategoria zgłoszenia ma znaczenie równie duże jak priorytet. Incydent, czyli awaria istniejącej usługi, obsługuje się w trybie pilnym. Zlecenie serwisowe, na przykład założenie konta, realizuje się w uzgodnionym terminie i zwykle według osobnego limitu czasu.

Cykl życia zgłoszenia w systemie ticketowym

System ticketowy rejestruje każde zgłoszenie z numerem i właścicielem oraz z historią zmian statusu. To z jego znaczników czasu wylicza się dotrzymanie SLA, więc umowa powinna opisywać statusy i ich wpływ na zegar. Nazwy statusów zależą od narzędzia, a poniższa lista jest typowym układem.

Przejście do statusu „Oczekuje na klienta” wymaga krótkiego komunikatu, co dokładnie jest potrzebne. Dostawca, który wstrzymuje zegar bez wyjaśnienia, osłabia zaufanie do całego raportu. Klient natomiast odpowiada w ustalonym czasie, po którym zgłoszenie zamyka się automatycznie z możliwością ponownego otwarcia.

Czas reakcji i czas rozwiązania

Czas reakcji jest łatwy do dotrzymania, bo wystarcza pierwsza merytoryczna odpowiedź. Czas rozwiązania wymaga naprawy albo obejścia problemu, więc zależy od przyczyny. Dobra umowa określa oba parametry dla każdego priorytetu, a także to, co uznaje się za rozwiązanie: naprawę trwałą czy tymczasowe obejście z terminem naprawy docelowej.

Godziny wsparcia i zegar SLA

Zegar SLA biegnie w godzinach wsparcia z umowy. Przy wsparciu w dni robocze od rana do popołudnia zgłoszenie wysłane wieczorem zaczyna być liczone następnego dnia, a przy pracy w trybie ciągłym liczy się każda godzina. Firma prowadząca sprzedaż wieczorami lub magazyn na dwie zmiany powinna wybrać godziny, które odpowiadają jej rzeczywistemu czasowi pracy.

Zegar zatrzymuje się, gdy zgłoszenie czeka na działanie klienta. Umowa wskazuje status, który wstrzymuje liczenie, na przykład „oczekuje na klienta”, oraz zasadę wznowienia po odpowiedzi. Bez tego zapisu dostawca mógłby bez końca zamykać zgłoszenia z powodu braku informacji, a klient odwrotnie zarzucać opóźnienia, których nie spowodował dostawca.

Pomiar dotrzymania SLA w zapytaniu SQL

Rozliczenie SLA sprowadza się do policzenia odsetka zgłoszeń, które mieściły się w limicie. Poniższe zapytanie T-SQL ilustruje mechanizm dla tabeli zgłoszeń z kolumnami czasu utworzenia i pierwszej reakcji. Nazwy tabel i kolumn są przykładowe. W praktyce minuty liczy się według kalendarza godzin wsparcia, a nie zegara ściennego, co wymaga tabeli kalendarza roboczego.

SELECT z.Priorytet,
       COUNT(*) AS LiczbaZgloszen,
       SUM(CASE WHEN DATEDIFF(MINUTE, z.Utworzono, z.PierwszaReakcja) <= p.LimitReakcjiMin
                THEN 1 ELSE 0 END) * 100.0 / COUNT(*) AS ProcentWLimicie
FROM dbo.Zgloszenie AS z
JOIN dbo.PriorytetSla AS p ON p.Priorytet = z.Priorytet
WHERE z.Utworzono >= DATEADD(MONTH, -1, CAST(GETDATE() AS date))
  AND z.PierwszaReakcja IS NOT NULL
GROUP BY z.Priorytet;

Obejście i rozwiązanie docelowe

Przy awariach krytycznych priorytetem jest przywrócenie pracy, a nie znalezienie przyczyny. Technik stosuje obejście, na przykład przełącza użytkowników na zapasowy serwer albo uruchamia usługę z kopii, a analizę przyczyny źródłowej prowadzi po odzyskaniu ciągłości. Umowa może wtedy przewidywać dwa terminy: przywrócenia usługi oraz przekazania raportu z analizy przyczyny.

Raport poawaryjny zawiera oś czasu zdarzeń oraz przyczynę źródłową. Trzecim elementem są działania zapobiegawcze z terminami. Całość pozwala odróżnić awarię jednorazową od problemu, który wróci przy najbliższej zmianie konfiguracji.

Dostępność usług w procentach

Dostępność zapisuje się jako procent czasu, w którym usługa działa w okresie rozliczeniowym. Różnica między 99 a 99,9 procent wygląda niewielko, ale przekłada się na dziesięciokrotnie krótszy dopuszczalny przestój. Poniższa tabela przelicza wartości na miesiąc liczący 30 dni.

Każda dodatkowa dziewiątka podnosi koszt, bo wymaga redundancji sprzętu, drugiego łącza lub całej infrastruktury zapasowej. Przed wyborem wartości warto policzyć koszt godziny przestoju w firmie i porównać go z ceną redundancji. Ogólne zasady definiowania celów niezawodności opisuje dokumentacja celów niezawodności w Microsoft Learn.

Wyłączenia z liczenia dostępności

Umowa wymienia sytuacje, które nie wliczają się do przestoju. Najczęściej są to planowane prace serwisowe w uzgodnionym oknie oraz awarie wynikające z działań klienta lub jego dostawców zewnętrznych, na przykład przerwa w łączu operatora. Lista wyłączeń powinna być zamknięta, bo otwarte sformułowania pozwalają zaliczyć niemal każdą awarię do wyjątków.

Eskalacja i raportowanie w umowie SLA

Eskalacja uruchamia się, gdy limit czasu jest bliski przekroczenia albo problem przekracza kompetencje pierwszej linii. Ścieżka zawiera osoby i terminy powiadomień, dzięki czemu zgłoszenie krytyczne nie leży w kolejce bez opieki.

• Eskalacja funkcjonalna - przekazanie zgłoszenia do specjalisty od danej technologii, na przykład sieci lub bazy danych.
• Eskalacja hierarchiczna - powiadomienie kierownika dostawcy, gdy limit czasu zostaje zagrożony.
• Powiadomienie klienta - komunikat o statusie w ustalonych odstępach, także gdy przyczyna nie jest jeszcze znana.
• Zamknięcie - potwierdzenie przez zgłaszającego, że usługa działa, przed formalnym zamknięciem zgłoszenia.

Raport miesięczny zamyka obieg informacji. Pokazuje liczbę zgłoszeń, średni czas ich obsługi, najczęstsze przyczyny awarii i odsetek zgłoszeń w limicie. Dobrą praktyką jest comiesięczne spotkanie, na którym omawia się raport i koryguje priorytety, na przykład gdy firma otwiera nową lokalizację albo wdraża nowy system.

Reguła: kara umowna działa tylko wtedy, gdy umowa wskazuje próg i sposób pomiaru oraz podaje termin naliczenia.

Kary umowne za niedotrzymanie parametrów przyjmują zwykle postać obniżenia abonamentu za okres, w którym dostępność lub czasy reakcji spadły poniżej progu. Wysokość obniżki strony ustalają w umowie. Pozostałe zapisy, czyli dostęp do haseł administracyjnych oraz dokumentację środowiska, uzupełniają próby odtwarzania kopii zapasowych. Opisuje je tekst o obsłudze informatycznej w Poznaniu i wymaganiach RPO i RTO.

Próba eskalacji przed startem umowy

Ścieżkę eskalacji warto sprawdzić przed podpisaniem umowy, a nie w trakcie pierwszej awarii. Prosty test polega na zgłoszeniu fikcyjnego incydentu krytycznego i obserwacji, kto odbiera telefon, kto dostaje powiadomienie oraz po jakim czasie do klienta wraca informacja o statusie. Test ujawnia brakujące numery kontaktowe i nieaktualne listy osób, a wynik można wpisać do protokołu odbioru. Powtarza się go po każdej większej zmianie w zespole dostawcy albo w strukturze firmy klienta.

Pakiety wsparcia i model współpracy

Usługi zwykle dzieli się na pakiety dopasowane do wielkości organizacji. Podstawowy pakiet obejmuje helpdesk i podstawowy monitoring. Średni dodaje zarządzanie kopiami zapasowymi i aktualizacjami. Rozszerzony wprowadza audyt bezpieczeństwa oraz stałego opiekuna technicznego przypisanego do klienta. Struktura pozwala zacząć od minimum i rozszerzać zakres bez zmiany dostawcy.

W praktyce współpraca opiera się na dwóch warstwach zdalnych i wizytach na miejscu. Helpdesk przyjmuje zgłoszenia telefonicznie albo przez system ticketowy i nadaje im priorytet. Monitoring proaktywny działa w tle i wykrywa wiele awarii, zanim odczują je pracownicy. Wizyta na miejscu pozostaje na sytuacje wymagające fizycznej interwencji, na przykład wymiany podzespołu.

Po stronie klienta dobrze działa jedna osoba odpowiedzialna za kontakt z dostawcą, co porządkuje przepływ informacji i przyspiesza decyzje wymagające akceptacji budżetu. Osoby zaczynające współpracę mogą sprawdzić podstawowe terminy w słowniku pojęć. Firmom o większej strukturze pomaga tekst o obsłudze informatycznej przedsiębiorstw, który opisuje katalog domenowy i polityki bezpieczeństwa.

Jak sprawdzić dostawcę przed podpisaniem umowy SLA

Wybór dostawcy wymaga więcej niż porównania cenników. Najpierw firma określa własne potrzeby: liczbę stanowisk, używane oprogramowanie branżowe i wymagania dotyczące danych. Zamiast szukać jednego specjalisty od wszystkiego, lepiej sprawdzić, czy zespół dostawcy ma osoby wyspecjalizowane w sieciach i serwerach oraz znające systemy branżowe używane w firmie.

Test zgłoszenia przed podpisaniem umowy pokazuje więcej niż referencje. Wysyła się zgłoszenie testowe i mierzy czas pierwszej reakcji oraz jakość odpowiedzi. Warto też poprosić o przykładowy raport miesięczny lub wgląd w panel monitoringu. Dostawca, który nie ma takiego raportu, prawdopodobnie nie potrafi rozliczyć własnych zobowiązań.

Ochrona danych stanowi osobny obszar. Rzetelny partner potrafi wskazać, gdzie fizycznie przechowywane są dane firmy, jak zabezpieczono kopie zapasowe i kto ma do nich dostęp. Powinien też opisać procedurę reagowania na incydenty bezpieczeństwa, na przykład ataki szyfrujące dane. Czas reakcji w takich sytuacjach decyduje o skali strat, więc procedura ma być spisana i znana klientowi.

Reguła: dostawca, który nie umie pokazać własnego raportu z obsłużonych zgłoszeń, nie rozliczy też zobowiązań z umowy.

Model współpracy z zewnętrznym zespołem opisuje też tekst o outsourcingu informatycznym, a lokalny kontekst zamawiania usług w regionie strona o outsourcingu IT w Poznaniu. SoftwareStudio łączy bieżącą obsługę z wdrożeniami systemów klasy WMS i YMS, więc firma ma jeden punkt kontaktu dla wsparcia i dla większych projektów. Indywidualną wycenę można uzyskać przez kontakt z SoftwareStudio.