ServiceNow i SLA

Praktyka zawierania umów SLA (Service Level Agreement – umowa o gwarantowanym poziomie świadczenia usług) jest niemal tak stara jak cała branża IT. Zgodnie z ITIL4 SLA jest to udokumentowana umowa między dostawcą usług a klientem, która definiuje zarówno wymagane usługi, jak i poziom ich świadczenia. Dostawca i klient mogą być odrębnymi podmiotami (wtedy umowa ma charakter komercyjny), mogą też należeć do tej samej organizacji (umowa niekomercyjna).

Oprócz SLA rozróżnia się jeszcze:

• OLA (Operational Level Agreemen) – umowa o gwarantowanym poziomie wsparcia.
• UC (Underpinning Contract) – kontrakt z dostawcą zewnętrznym.

Zależności pomiędzy SLA, OLA i UC są następujące:

• SLA reprezentuje umowę główną, dotyczącą usług świadczonych przed dostawcę na rzecz klienta.
• OLA i UC dotyczą usług wspierających realizowanych odpowiednio:
  • OLA – wewnętrznie (działy, zespoły w organizacji dostawcy usług),
  • UC – zewnętrzne (zewnętrzni dostawcy usług).

Przykład:

1. SLA – umowa na świadczenie usług: utrzymanie serwisu www,
2. OLA – umowa wewnętrzna dotycząca utrzymania sieci, infrastruktury czy wsparcia użytkownika,
3. UC – umowy z podmiotami zewnętrznymi na usługi wspierające, niezbędne do świadczenia usługi głównej, takie jak: łącza internetowe, zasilanie, bezpieczeństwo fizyczne.

Praktyka stosowania umów SLA

W praktyce wielu organizacji nie zawsze rozróżnia się te trzy rodzaje umów, a stosuje w każdym przypadku termin SLA, co najwyżej dodając, kogo dana umowa dotyczy np.: „SLA z klientem” czy „SLA z dostawcą Internetu”.

Nie jest to istotne uchybienie, ponieważ w każdej z tych umów znajdziemy te same elementy:

• Zakres umowy (jakie usługi są świadczone),
• Wymagany poziom usług,
• Pomiary i weryfikacja usług,
• Wynagrodzenie i kary umowne (w umowach wewnętrznych może mieć inny charakter niż w umowach komercyjnych).

Odwzorowanie postanowień umów SLA/OLA/UC w systemie ServiceNow może być sporym wyzwaniem, w szczególności, gdy nie wszystkie zapisy umowy są precyzyjne lub umowa nie uwzględnia realiów stosowania narzędzi ITSM. Co więcej, raporty SLA z systemu ServiceNow mogą stanowić podstawę do weryfikacji jakości świadczenia usług, a tym samym, podstawę do rozliczeń pomiędzy stronami umowy. Jest to zatem kwestia niezwykle istotna.

Cechy usług będących przedmiotem umów SLA

Cechy i parametry usług, które zwykle są (powinny być) przedmiotem umów SLA:

• Wolumen ruchu/danych (ang. Volume/traffic) – czy usługa jest w stanie obsłużyć wymaganych wolumen ruchu lub danych(np.: do 100 000 żądań HTTP miesięcznie)?
• Dostępność (ang. Availability) – czy usługa jest dostępna dla użytkowników/klienta, gdy jej potrzebują (np. 99% dostępności 24×7)?
• Opóźnienie (ang. Latency) – czy wynik działania usługi jest dostarczany w akceptowalnym dla użytkownika/klienta czasie (np. odpowiedź ze strony serwisu HTTP w czasie nie dłuższym niż 300 ms)?
• Błędy (ang. Errors) – czy usługa dostarcza wymagany zakres funkcjonalności (np. żądania HTTP nie zwracają kodów odpowiedzi 4xx albo 5xx)?
• Obsługa zgłoszeń (ang. Tickets) – czy wsparcie jest odpowiednio skuteczne i wydajne (zgłoszenia (incydenty, wnioski, zmiany) są realizowane w ustalonym czasie)?

Warto zwrócić uwagę, że podane wyżej parametry są zwykle dobrze rozumiane przez użytkowników/klientów/biznes, ale ocena jakości ich realizacji w oparciu o mechanizmy SLA dostępne w ServiceNow może okazać się wyzwaniem.

Ze względu na ograniczenia niniejszej publikacji, przedstawione przykłady konfiguracji ograniczają są do tematyki obsługi zgłoszeń, takich jak incydenty czy wnioski usługowe i dotyczą sytuacji i rozwiązań typowych (mogą nie wyczerpywać wszystkich możliwości).

Parametry obsługi zgłoszeń

Często stosowane w umowach SLA parametry obsługi zgłoszeń to:

1. Zakres świadczonej usługi (co może być przedmiotem zgłoszeń, np. nieprawidłowe działanie serwisu www będzie obsługiwane, ale awaria stacji roboczej użytkownika już nie).
2. Kanały komunikacyjne do zgłaszania usterek lub zapotrzebowania (np.: telefonicznie, e-mailem, przez portal klienta, przez chat).
3. Osoby mające prawo do zgłaszania.
4. Ustalony wolumen zgłoszeń (np. w ramach umowy klient ma prawo do 100 zgłoszeń miesięcznie. Obsługa zgłoszeń po wyczerpaniu ustalonej puli, może oznaczać dodatkowe opłaty).
5. Czas reakcji (po jakim czasie od przesłania/utworzenia zgłoszenia podjęte zostaną działania związane z naprawą usterki lub obsługą zgłoszenia).
6. Czas rozwiązania (po jakim czasie usterka zostanie usunięta lub zrealizowane zamówienie).

Dobrze napisana (precyzyjna) umowa SLA jest warunkiem dobrej implementacji rozwiązania w systemie ServiceNow.

W podanym powyżej przykładzie precyzja ustaleń dotyczy punktów odpowiednio:

• 1, 2, 3 i 4 – na jakiej podstawie stwierdzamy, czy zgłoszenie jest prawidłowe/prawidłowo zgłoszone? Czy te nieprawidłowe też rejestrujemy, a jeżeli tak, to czy obniżają pulę zgłoszeń dostępnych dla klienta?
• 5 i 6 – jak mierzymy czas? Kiedy włączamy (start), kiedy wstrzymujemy (pauza), a kiedy kończymy (stop) pomiar czasu? Ponadto, czy czasy reakcji i rozwiązania są łączne czy rozłączne (zaczynamy je mierzyć równocześnie, czy czas rozwiązania zaczynamy mierzyć po upływie czasu reakcji)?

Poziom trudności wzrasta, gdy SLA zawierane jest w dużej organizacji, działającej w różnych strefach czasowych (różne godziny pracy), kulturowych (różnice w kalendarzu dni roboczych i świątecznych, język komunikacji) oraz gdy oferowane usługi mogą różnić się cechami czy parametrami w zależności od lokalizacji.

Definicje SLA w ServiceNow

Pierwszym elementem, którego konfiguracja może być potrzebna, jest definicja SLA (ang. SLA Definition). Formularz nowego rekordu wygląda następująco:

Znaczenie poszczególnych pól

Name: Nazwa rekordu – warto przed skonfigurowaniem nazwy ustalić standard nazewniczy, tak by stosowane nazwy były znaczące i usystematyzowane. Im więcej rekordów w tabeli contract_sla, tym jest to bardziej istotne. Stosowanie standardu nazewniczego ułatwia orientację w widoku listy oraz znacząco usprawnia filtrowanie po nazwach.

Type: Konfigurując rekordy SLA Definition w ServiceNow, można rozróżniać typy umów, ale ma to znaczenie wyłącznie w raportowaniu, bo na działanie samej definicji wpływu nie ma. W odniesieniu do CSDM umowy SLA zwykle będą związane z BSO (Business Service Offering), natomiast OLA czy UC z TSO (Technical Service Offering).

Target: Rozróżnienie pomiędzy Rozwiązaniem (ang. Resolution) a Reakcją (ang. Response). Ta własność ma znaczenie wyłącznie przy raportowaniu i nie wpływa na działanie Definicji SLA, niemniej należy konsekwentnie konfigurować pozostałe parametry rekordu, jeżeli zostanie użyta któraś z podanych wyżej wartości. Dygresja: Konfiguracja tej własności w Definicji SLA wynika z treści umowy. Należy się upewnić, że strony umowy mają jednakowe rozumienie tego, co jest reakcją, a co rozwiązaniem, w szczególności, kiedy każda z tych czynności się zaczyna, a kiedy kończy.

Table: Na jakiej tabeli stosowana jest definicja. Ważne ustawienie. W praktyce najczęściej stosowane są tabele incident, sc_req_item, sc_task, problem. Wybór tabeli determinuje wobec jakiego procesu dana definicja SLA jest stosowana.

Flow: Wykorzystanie konkretnego przepływu pracy (ang. Flow) pozwala na inicjowanie określonych działań w trakcie realizacji SLA np.: generowanie powiadomień albo eskalacji.

Vendor: Pole odwołuje się do tabeli core_company, co pozwala na wskazanie podmiotu (firmy zewnętrznej) odpowiedzialnego za realizację umowy (w szczególności UC).

Service Commitment: Należy zaznaczyć, gdy Definicja SLA jest powiązana z Service Commitment i w konsekwencji z Service Offering.

Enable logging: Zaznaczenie umożliwia generowanie szczegółowych logów dla danej definicji SLA. Przydatne w diagnozowaniu nieprawidłowości w działaniu mechanizmów SLA.

Active: Zaznaczenie powoduje, że Definicja SLA jest aktywna i można jej używać.

Duration type: Określa metodę obliczania czasu realizacji w ramach definicji SLA i zmienia sposób działania definicji jak i samego formularza. Wybranie wartości:

• „User specified duration” wymaga określenia czasu realizacji w kolejnym polu Duration, które pojawia się wtedy w formularzu.
• Inna wartość: Określa względny czas realizacji np. „End of next business day” (koniec następnego dnia roboczego). Wymaga sprecyzowania dla jakiego rekordu będzie obliczany względny czas realizacji – poniżej pojawia się pole „Relative duration works on”.

Duration: Pojawia się, gdy w polu Duration type wybrano „User specified duration”. Określa czas, po przekroczeniu którego, następuje naruszenie SLA. Dygresja: Czas może nie być mierzony w sposób ciągły – o tym, kiedy pomiar czasu zostaje uruchomiony (start), wstrzymany (pauza), zakończony (stop) decydują inne parametry rekordu definicji SLA, takie jak Harmonogram (ang. Schedule) oraz reguły Start/Pause/Stop Condition.

Relative duration works on: Pojawia się, gdy w polu Duration type wybrano wartość inną niż User specified duration. Pozwala na wybór jednej z dwóch wartości: Task record albo SLA record.

Schedule source: Określa, skąd pochodzi Harmonogram (ang. Schedule) używany w czasie pomiaru realizacji SLA. Dostępne opcje:

• No schedule: Stosowany jest Harmonogram 24×7 (full time) bez żadnych wyjątków, czy wyłączeń.
• SLA Definition: Wymaga wskazania konkretnego Harmonogramu w kolejnym polu Schedule.
• Task field: Opcja, która tutaj się pojawia, jest uzależniona od wartości ustawionej w polu Table (np: Incident field, Incident task field, Catalog task field). Wybór tej opcji wymaga wskazania obiektu zawierającego Harmonogram (ang. Schedule) np: Configuration Item -> Schedule.

Schedule source field: Wskazuje obiekt zawierający Harmonogram np.: Configuration Item Schedule lub Caller Schedule.

Schedule: Pozwala na wybranie konkretnego Harmonogramu z tabeli cmn_schedule. Harmonogramy zwykle pozwalają na zdefiniowanie czasu pracy (dni roboczych i godzin pracy).

Timezone source: Określa strefę czasową używaną przy tworzeniu zadania SLA. Do wyboru:

• Strefa czasowa osoby zgłaszającej: The caller’s time zone.
• Strefa czasowa związana z definicją SLA: The SLA definition’s time zone. W następnym polu Timezone należy podać konkretną strefę czasową przypisaną do Definicji SLA.
• Strefa czasowa związana z elementem konfiguracji: The CI’s location’s time zone.
• Strefa czasowa związana z lokacją (Location) przypisaną do zadania: Task’s location’s time zone.
• Strefa czasowa związana z lokacją (Location) przypisaną do zgłaszającego. The caller’s location’s time zone

Dygresja: ustawienia stref czasowych są szczególnie istotne w organizacjach międzynarodowych, gdzie wsparcie działa w innych strefach czasowych niż użytkownicy, np.: europejski Service Desk wspierający użytkowników w USA.

Warunki Start/Pause/Stop/Reset condition

Ogólnie warunki te określają, kiedy należy rozpocząć (ang. Start) pomiar czasu realizacji danego zadania, kiedy wstrzymać (ang. Pause), a kiedy zakończyć pomiar (ang. Stop). Pozwala też określić warunki resetu (ang. Reset) pomiaru czasu.

Konfiguracja Start/Pause/Stop/Reset condition oferuje szeroki wachlarz możliwości i zwykle oparta jest na mniej lub bardziej skomplikowanych warunkach (filtrach), które muszą być spełnione, by daną akcję związaną z pomiarem czasu wykonać.

Start condition: formularz konfiguracji przedstawia poniższy rysunek. Jest to zestaw filtrów pozwalających określić warunek lub warunki, które muszą być spełnione, by uruchomić pomiar czasu.

Retroactive start: Zaznaczenie tej opcji skutkuje pojawieniem się w formularzu dwóch dodatkowych parametrów: „Retroactive pause” oraz „Set start to” i wpływa na pomiar czasu w ten sposób, że czas nie jest mierzony od chwili spełnienia warunku podanego w filtrze Start condition, ale od momentu, który został ustawiony w polu Set start to.
Z opcji Retroactive start należy korzystać, gdy jest możliwe, że w trakcie realizacji zgłoszenia następuje zmiana definicji SLA. Przykład: zmiana priorytetu zgłoszenia w trakcie jego obsługi.

Retroactive pause: Jeżeli w trakcie realizacji zgłoszenia występowały pauzy (wstrzymanie pomiaru czasu), to zostaną one uwzględnione w kalkulacji czasu (ang. Duration) po zmianie definicji SLA.

Set start to: Moment z historii zgłoszenia, który zostaje uznany za początek pomiaru czasu. (Przykład: moment utworzenia zgłoszenia).

When to cancel: Kiedy anulować zliczanie czasu? Zawiera 3 opcje do wyboru :

• Cancel conditions are met: Skutkuje pojawieniem się dodatkowej opcji „Cancel conditions” i wymaga podania warunków, które muszą być spełnione, aby anulować działanie danej definicji SLA.
• Start conditions are not met: Nie są lub przestają być spełnione warunki podane w „Start condition”.
• Never: Nie wymaga komentarza.

Cancel condition: Warunki (filtr) które muszą być spełnione, by anulować działanie danej definicji SLA (pojawia się, gdy wybrano When to cancel -> Cancel conditions are met).

Pause condition: Zawiera warunki (filtr), które muszą być spełnione, by wstrzymać (pauza) pomiar czasu.

When to resume: Definiuje warunki wznowienia pomiaru czasu i zawiera dwie opcje do wyboru:

• Pause conditions are not met: Gdy tylko warunki podane w opcji Pause condition przestają być prawdziwe, pomiar czasu zostaje wznowiony.
• Resume conditions are met: Określa warunki, które muszą być spełnione, by można było wznowić pomiar czasu. Wymaga uzupełnienia dodatkowej opcji Resume conditions będącej zestawem warunków (filtrem).

Stop condition: Zawiera tylko warunki (filtr), których spełnienie skutkuje zakończeniem pomiaru czasu.

Reset condition: Pozwala zdefiniować dodatkowe warunki, których spełnienie skutkuje natychmiastowym zakończeniem lub anulowaniem działającej definicji SLA i uruchomieniem nowej. Jeżeli w trakcie realizacji zadania zmienił się jakiś istotny parametr i wymaga to zmiany SLA, opcja „Reset condition” może okazać się pomocna. Przykład: przypisanie zadania do grupy (ang. Assignment group), która działa w oparciu o inne warunki niż podane w uruchomionej definicji SLA. Nowa definicja SLA zostanie uruchomiona, o ile spełnia warunki Start condition.

Uwaga:
Warunki SLA (Start/Pause/Stop Condition) są wykonywane w następującej kolejności:

1. Stop condition
2. Pause condition
3. Start condition

Jeżeli w trakcie przetwarzania warunków, znalezione zostanie dopasowanie, to kolejne warunki nie są przetwarzane!

Studium przypadku

Ze względu na to, że bardziej szczegółowy opis możliwości konfiguracji rekordów Definicji SLA byłby na tyle obszerny, że zasługiwałby na odrębny artykuł, ograniczyłem się do najbardziej typowych zastosowań jako formy przykładu.

Przed przystąpieniem do konfiguracji warto zapoznać się z zaleceniami, jak w ogóle za takie zadanie się zabrać. Bardzo pomocne, oprócz zrozumienia treści umowy (lub umów) SLA, jest rozpisanie (zwizualizowanie) procesu, dla którego definicje SLA są tworzone. Warto rozważyć wszystkie możliwe przypadki użycia procesu, a następnie odpowiednio odzwierciedlić je w konfiguracji.

Definiowanie SLA dla zarządzania incydentami

Przykład: należy skonfigurować Definicje SLA dla zarządzania incydentami, gdzie występują 4 priorytety obsługiwane zgodnie z poniższą tabelą:

Obok priorytetów podano Harmonogramy (ang. Schedule) oraz czasy realizacji (ang. Duration).

W obsługę zgłoszeń zaangażowane są 3 zespoły (grupy wsparcia) reprezentowane przez odpowiednie grupy użytkowników (sys_user_group) w systemie ServiceNow.

• Service Desk
• Level2
• Level3

Tak postawione zadanie napotyka na pewne trudności w realizacji:

1. W jaki sposób liczymy czas realizacji zgłoszeń obsługiwanych przez więcej niż jeden zespół? Dla każdego zespołu z osobna, czy całościowo?
2. Kto jest właścicielem każdego zgłoszenia od momentu jego utworzenia do zamknięcia?
3. Jak mierzymy czas reakcji, a jak czas realizacji?
4. Jakie sytuacje/warunki powodują wstrzymanie pomiaru czasu (pauza)?
5. Jakie sytuacje/warunki powodują anulowanie realizacji zgłoszenia?
6. Czy harmonogramy uwzględniają jakieś dni wolne albo święta?

Osoba odpowiedzialna za konfigurację Definicji SLA w ServiceNow, która otrzyma podobne zadanie, będzie musiała uzyskać odpowiedzi na powyższe pytania. Możliwe, że odpowiedzi znajdą się w umowie SLA, a jeżeli nie, należy poprosić osoby odpowiedzialne za zawarcie umowy o doprecyzowanie.

Załóżmy, że uzyskano następujące odpowiedzi:

Ad 1. Czas mierzymy całościowo, z perspektywy klienta/użytkownika, bez względu na to, które zespoły są zaangażowane w rozwiązywanie zgłoszenia.

Ad 2. Właścicielem zawsze jest Service Desk.

Ad 3. Pomiar czasu reakcji i czasu rozwiązania zgłoszenia zaczynamy w tym samym momencie. Pomiar czasu reakcji kończymy, gdy zostanie wypełnione pole Assigned to.

Ad 4. Komunikacja z użytkownikiem. Czekanie na odpowiedź na zadanie pytanie daje prawo wstrzymania pomiaru czasu (Pauza).

Ad 5. Nie ma takich warunków, wszystkie zgłoszenia muszą być realizowane.

Ad 6. Harmonogramy nie uwzględniają dni wolnych i świąt.

Podany przykład jest stosunkowo prosty, ale i tak będzie wymagał utworzenia 8 definicji SLA: 4 priorytety, a dla każdego priorytetu jedna Definicja SLA dla reakcji i jedna dla rozwiązania.

Trochę praktyki

Rozważmy następujący przypadek: Zgodnie z powyższym przykładem Incydenty P2 muszą być rozwiązywane w czasie 12h od chwili ich zarejestrowania. Realizacja odbywa się przez całą dobę, w dni robocze. Reasumując, KAŻDY incydent P2 musi być w podanym czasie rozwiązany, każdy – czyli 100%. Dotyczy to również incydentów o innych priorytetach w podanym przykładzie.

W praktyce zarządzania umowami SLA poziom realizacji sięgający 100% spotykany jest rzadko, często jest nieosiągalny lub kosztowny (np.: dostępność 99,999%), a zatem stosowany tylko w uzasadnionych przypadkach. Czy zatem w odniesieniu do realizacji zgłoszeń można oczekiwać podobnych zasad? Tak. W umowie SLA powinny być zdefiniowane poziomy realizacji np.:

Rekordy definicji SLA nie zawierają takiej opcji konfiguracyjnej. Jak zatem skonfigurować poziom realizacji? Można mierzyć i raportować wyniki SLA w raportach SLA. Drugie rozwiązanie to rekord Service Commitment zawierający własność SLA Percentage, która właśnie do tego służy.

Przykładowy raport SLA:

W podanym okresie rozliczeniowym 95,03% incydentów o priorytecie 3 (P3) zostało rozwiązane zgodnie z parametrami podanymi w definicji SLA dla tego priorytetu. 4,97% incydentów nie zostało rozwiązanych w wymaganym czasie. Zgodnie z tabelą powyżej wymagany poziom realizacji dla incydentów P3 wynosi 98%, a zatem w podanym przykładzie doszło do naruszenia SLA, gdyż osiągnięty poziom realizacji to nieco ponad 95%.

Sii x ServiceNow

Dzięki opartej na chmurze ServiceNow AI Platform automatyzujemy procesy i ułatwiamy pracę działów, aby zwiększać produktywność w całych organizacjach.

Oferta ServiceNow

Podsumowanie

Zarządzanie umowami SLA w oparciu o rozwiązania oferowane przez system ServiceNow to zagadnienie bardzo obszerne, wymagające – oprócz znajomości samego systemu ServiceNow – wiedzy z innych obszarów, takich jak zarządzanie systemami IT, zarządzanie procesowe, prawo czy zarządzanie finansowe (mamy tu do czynienia z umowami, które nakładają na strony określone zobowiązania).

Trudno sobie wyobrazić, by takie kompetencje były skupione w ramach jednej osoby lub jednego stanowiska. W praktyce zagadnieniem negocjowania, zawierania i realizacji umów SLA zajmują się odpowiednie zespoły i tu warto podkreślić, że wszystkie wspomniane wyżej kompetencje są niezbędne, by takie umowy były dobrze skonstruowane i zawierały zapisy, które nie tylko są korzystne dla obu stron, ale przede wszystkim możliwe do realizacji w sensie podjętych zobowiązań oraz ich implementacji we wiodącym narzędziu ITSM, jakim jest ServiceNow.