Eskalacja funkcjonalna a hierarchiczna – czy ich używasz?

Podziel się

eskalacja funkcjonalnaProces zarządzania incydentami, to jeden z najczęściej wykorzystywanych procesów ITSM z biblioteki dobrych praktyk ITIL. Dużo organizacji ma tak naprawdę tylko wdrożony ten jeden proces. Chociaż ja zalecam rozpoczęcie przygody z ITIL od katalogu usług (patrz artykuł Katalog usług – dlaczego jeszcze go nie masz?), posiadania dobrze funkcjonującego procesu zarządzania incydentami, też jest ważne i ostatecznie może być uruchamiane w pierwszej kolejności. W szczególności, że proces zarządzania incydentami odpowiada za bardzo ważne parametry SLA. Czy jednak na pewno dobrze funkcjonuje w Twojej organizacji? Jak wykorzystujesz eskalację funkcjonalną i hierarchiczną, najważniejsze elementy tego procesu?

Eskalacja funkcjonalna

Bardzo często korzystamy z eskalacji funkcjonalnej, nie do końca mając tego świadomość. Eskalacja funkcjonalna określa, jak należy się zachować podczas rozwiązywania incydentu, jeżeli I lub II linia wsparcia nie potrafi go rozwiązać. Jakie jednak powinny być kryteria przekazania zgłoszenia do kolejnej linii wsparcia? Należy określić dwa wyzwalacze:

  • Pierwszy musi być związany z kompetencjami.
    • Jeżeli I linia wsparcia (Service Desk), nie umie rozwiązać zgłoszenia (incydentu), przekazuje zgłoszenie do II lub III linii wsparcia. Od Service Desk zależy, czy posiada odpowiednią wiedzę i doświadczenie czy zgłoszenie można przekazać od razu do III linii wsparcia z pominięciem II.
    • Jeżeli II linia wsparcia (zespołu utrzymania) nie umie rozwiązać zgłoszenia (incydentu), przekazuje zgłoszenie do III linii wsparcia (zespoły wytwórcze lub infrastruktury)
  • Drugi musi być związany z czasem.
    • Jeżeli I linia wsparcia, nie znajdzie rozwiązania incydentu w ustalonym czasie, zgłoszenie przekazywane jest do II linii wsparcia
    • Jeżeli II linia wsparcia, nie znajdzie rozwiązania incydentu w ustalonym czasie, zgłoszenie przekazywane jest do III linii wsparcia

Należy zwrócić szczególną uwagę, aby dobrze zdefiniować czas na znalezienie rozwiązania dla I i II linii wsparcia.

  • Nie może to być za mało, bo wtedy większość incydentów będzie trafiać do II linii wsparcia a w konsekwencji również do III. Spowoduje to „zatkanie” się tych zespołów w obsłudze incydentów i nie dotrzymanie SLA związanego z czasem rozwiązania.
  • Nie może to być za dużo, aby czas poświęcony na obsługę incydenty przez Ii lub II linię wsparcia, nie zmniejszał czasu na rozwiązane, odpowiednio przez II i III linię wsparcia.

Poruszałem to zagadnienie w artykule OLA – czy ktoś ją kiedyś widział?, gdzie podałem przykładowy podział czasu rozwiązania pomiędzy I, II i III linię wsparcia. Zachęcam do zapoznania się.

Eskalacja hierarchiczna

Równie ważna co eskalacja funkcjonalna, jednak znaczniej rzadziej wykorzystywana jest eskalacja hierarchiczna. Określa ona jakie działania należy podjąć, jeżeli mamy do czynienie z poważnym incydentem (zagadnieniem) lub czynności związane z badaniem i diagnozą oraz rozwiązaniem i przywróceniem trwają za długo. Nazywana jest również eskalacją zarządczą, ponieważ dotyczy kadry zarządzającej wszystkich szczebli od menedżerów zespołów, przez menedżerów procesów iTSM a na dyrektorze ds. IT i członkach zarządu kończąc.

Eskalacja hierarchiczna dotyczy dwóch aspektów:

  • Informacyjnego – menadżerowie muszą być poinformowani o możliwych problemach z rozwiązaniem incydentu aby byli świadomi tego faktu.
  • Decyzyjnego – w przypadku zagrożenia nie dotrzymania czasu rozwiązania, wymagane jest podejmowanie decyzji, które pozwolą nie przekroczyć czasu rozwiązania lub zminimalizować jego niedotrzymanie.

Zasady stosowania eskalacji hierarchicznej muszą być opisane w procedurze eskalacji, która będzie odpowiednio wdrożona w organizacji. Niestety taka procedura rzadko występuje, dlatego zwrócić szczególną uwagę na jej przygotowanie. Może nie będzie potrzebna codziennie ale jak już będzie to zaoszczędzi dużo czasu i zamieszania w procesie decyzyjnym.

Eskalacja funkcjonalna vs hierarchiczna

Tak naprawdę eskalacja hierarchiczna jest uzupełnieniem eskalacji funkcjonalnej. Jeżeli III linia wsparcia nie umie rozwiązać incydentu, wtedy w ramach procedury eskalacyjnej, kierownictwo organizacji podejmuje decyzję czy zwiększyć zasoby wewnętrzne potrzebne do rozwiązania czy może należy sięgnąć po zewnętrznych specjalistów. Jak widać obie eskalacje się uzupełniają i pominięcie którejś w procesie zarządzania incydentami, wpływa na jakość funkcjonowania procesu.

Mam nadzieję, że przybliżyłem Wam te dwa zagadnienia i już teraz nikt nie będzie miał wątpliwości do czego służą, i że są bardzo potrzebne.

Pytanie: Jak wykorzystujesz eskalację funkcjonalną i hierarchiczną w swojej organizacji?


Podziel się

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.