Wśród parametrów poziomu usług tzw. SLA, czas rozwiązania zgłoszenia (incydentu, problemu, service requestu) jest jednym z najczęściej definiowanych. Parametr ten jest bardzo ważny, ponieważ pokazuje, czy organizacja IT, jest dobrze przygotowana do wsparcia Użytkownika, w rozwiązywaniu powstających problemów. Obsługa zgłoszeń od użytkowników, jest narzędziem postrzegania przez biznes, jakości usług świadczonych przez IT. Co można zrobić aby obsługa klienta, w tym przypadku usług IT działała sprawnie?

SLA

Po pierwsze należy dobrze zdefiniować z biznesem, wartość dopuszczalną czasu rozwiązania. Klient, gdzie klientem jest biznes i/lub użytkownik, nie będzie zadowolony jeżeli wartość czasu rozwiązania będzie dla niego niekorzystna. Rolą IT jest rzetelne pokazanie jakie są możliwości po stronie IT i z jakimi kosztami wiążą się poszczególne czasy rozwiązania. Najważniejsze aspekty, na które należy zwrócić uwagę to obsługa zgłoszeń i czas rozwiązania.

Obsługa zgłoszeń

Musimy rozważyć trzy przypadki:

• w dni robocze w godzinach pracy, np. 8:00-16:00
• w dni robocze poza godzinami pracy, np. 16:00-8:00
• w dni wolne od pracy, soboty, niedziele i święta

W pierwszej kolejności, ustalamy z biznesem czy wystarczająca jest obsługa w dni robocze w godzinach pracy. Z tym wariantem wiążą się najniższe koszty, bo mamy osoby z zespołów wsparcia na miejscu i nie musimy ich specjalnie organizować.

Jeżeli wymagania biznesu są wyższe, należy ustalić, w jakich godzinach w dni robocze oczekiwane jest wsparcie. Im dłuższe godziny wsparcia tym większy koszt, który wynika z zapłacenia pracownikom za pracę poza „normalnymi” godzinami. W przypadku obsługi zgłoszeń 24 godziny na dobę, należy uwzględnić pracę w nocy i wymagania wynikające z kodeksu pracy. Może to skutkować koniecznością zatrudnienia dodatkowych osób.

Naturalnie największe koszty są przy świadczeniu wsparcia 24/7/365. Wynikają one z liczby osób, jaką musimy posiadać w zespołach wsparcia, pracy w nocy oraz w dni wolne od pracy i wymagań kodeksu pracy. W tym przypadku należy zastanowić się czy najlepszym rozwiązaniem nie będzie pracy zmianowa 12/12 (dwie zmiany) lub 8/8/8 (trzy zmiany).

Czas rozwiązania

Oczekiwanie użytkownika jest, że każde jego zgłoszenie zostanie rozwiązane jak najszybciej. Takiego wymagania nie można zrealizować w sposób efektywny kosztowo. Dlatego bardzo ważne jest, aby odpowiednio zdefiniować kategorie zgłoszeń oraz pilność i wpływ, i do nich przypisać właściwe czasy rozwiązania. Jeżeli rzetelnie i obiektywnie jako IT, ustalimy te kwestie z biznesem, to zróżnicujemy czasy rozwiązania w zależności od kategorii i priorytetu zgłoszenia. Np dla odblokowania konta powinno to być 2 godziny ale już na instalację aplikacji krytycznej wystarczające powinno być 8 godzin. Wyznaczenie kategorii, pilności i wpływu (priotytet) oraz określenie dla nich czasów rozwiązania jest bardzo indywidualne i powinno zostać dostosowane do każdej organizacji.

OLA

Kiedy mamy już uzgodnione z biznesem wymagania związane z czasem rozwiązania, musimy podjąć decyzję czy świadczymy wsparcia wewnętrznymi zasobami IT czy z pomocą dostawcy zewnętrznego.

Decydując się na świadczenie wsparcia zasobami wewnętrznymi musimy zadbać aby wymagania z SLA przełożyć na zapisy w OLA. Szczegółowo opisałem to w artykule „OLA – czy ktoś ją kiedyś widział”. Zachęcam do zapoznania się.

UC

Jeżeli nie mamy zasobów do świadczenia wsparcia, zgodnie z wymaganiami uzgodnionymi z biznesem lub z innych względów chcemy skorzystać z pomocy z zewnątrz, to podpisujemy umowę z dostawcą zewnętrznym. Te inne względy to mogą być kwestie formalne, podatkowe, minimalizacji ryzyka. Na co zwrócić podpisując taką umowę wskazywałem w artykule „Underpinning contract – zadbaj o swoje interesy”.

Czas poświęcony na rzetelne zdefiniowanie wymagań związanych z czasem rozwiązania, zaprocentuje podczas obsługi zgłoszeń od użytkowników. Biznes będzie wiedział czego może się spodziewać a IT jak ma rozkładać priorytety rozwiązując zgłoszenia od użytkowników.

Pytanie: W jakich godzinach najczęściej obsługujesz zgłoszenia od użytkowników?

Artykuł Czas rozwiązania w SLA, OLA i UC – jak go poprawnie definiować? pochodzi z serwisu Mariusz Siek.

W ostatnim czasie bardzo dużo pisałem o katalogu usług i SLA, ponieważ według mnie są to najważniejsze elementy w zarządzaniu usługami IT. Wykorzystujemy je w relacjach zewnętrznych biznesu z IT. Jednak gdy już je mamy opracowane i uzgodnione pomiędzy biznesem i IT, powinniśmy zadbać również o przełożenie SLA na OLA i Underpinning Contracts (UC). Brak uregulowania wymagań na poziom usług w OLA i/lub UC jest bardzo często przyczyną niedotrzymania SLA z biznesem.

Dlaczego jednak większość organizacji tego nie robi? Dlaczego tak się dzieje? Przybliżę to zagadnie w tej publikacji.

Jak OLA się nazywa?

OLA czyli Operation Level Agreement jest to wewnętrzne porozumienie pomiędzy zespołami IT, które określa jaka jest odpowiedzialność poszczególnych zespołów wewnątrz IT za dotrzymanie SLA przed biznesem. Właściwie, ktoś może powiedzieć po co nam OLA przecież mamy SLA. Czy to nie wystarczy? Odpowiedź brzmi nie.

Dlaczego więc w IT nie lubimy OLA?

• OLA kojarzona jest z formalizmami a tych żaden administrator czy programista nie lubi
• Nie rozumiemy różnicy pomiędzy SLA, OLA i UC
• Zakładamy, że jakoś to będzie, przecież do tej pory dawaliśmy sobie bez tego radę
• Nie wiemy jak OLA mogłaby nam pomóc w codziennej pracy

Poszukajmy, jakie korzyści mamy ze zdefiniowania i wprowadzenia OLA?

• Zespoły IT dowiadują się jakie wymagania (SLA) zostały uzgodnione dla usług, za utrzymanie których odpowiadają
• Dokonujemy podziału odpowiedzialności pomiędzy poszczególne zespoły IT, które świadczą wsparcie
• Uzgadniamy zasady komunikacji pomiędzy zespołami IT
• Definiujemy ścieżki eskalacji, w przypadku sytuacji konfliktowych

Co OLA oznacza w praktyce?

Podejrzewam, że większość z Was nadal nie wie jak OLA zastosować w praktyce. Wyjaśnię to na przykładzie jednego parametru SLA. Tym parametrem jest czas rozwiązania incydentu określony w SLA dla usługi.

Zakładamy, że czas rozwiązania incydentu w SLA wynosi 8 godzin. Co powinniśmy określić w OLA? Większość organizacji wsparcia składa się z trzech linii wsparcia:

• I linia wsparcia stanowi przeważnie Service Desk, do którego incydenty wpadają w pierwszej kolejności
• II linia wsparcia to zespół utrzymania odpowiedzialny z utrzymanie danej usługi (aplikacji)
• III linia wsparcia składa się z zespołu wytwórczego i/lub zespołu infrastruktury

Jak podzielić czas rozwiązania incydentu z SLA, pomiędzy trzy linie wsparcia? Poniżej moja propozycja z komentarzem.

• I linia wsparcia = 1 godzina. Service Desk według ITIL powinien rozwiązywać 70% zgłoszeń od użytkowników. Dodatkowo powinien robić to szybko i sprawnie. Dlatego jeżeli w ciągu 1 godziny nie jest w stanie znaleźć rozwiązania powinien przekazać incydent do II linii wsparcia
• II linia wsparcia = 1 godzina. Zespół utrzymania po otrzymaniu incydentu z Service Desk, bada i diagnozuje incydent w celu znalezienia rozwiązania. Ma większe kompetencje niż Service Desk. Jednak jeżeli w ciągu 1 godziny nie znajdzie rozwiązania lub obejścia powinien przekazać incydent do III linii wsparcia
• III linia wsparcia = 6 godzin. Zespół wytwórczy i/lub zespół infrastruktury w zależności, jakiego obszaru (błąd w kodzie oprogramowania czy niepoprawnie działająca infrastruktura) dotyczy incydent rozwiązuje zgłoszenie.

Czas rozwiązania a eskalacja funkcjonalna

Zaraz, zaraz ktoś powie, jak to I i II linia wsparcia na rozwiązanie mają po 1 godzinie a III linia wsparcia 6 godzin? Coś tu się nie zgadza. Wszystko jest poprawnie, ponieważ mamy w tym przypadku do czynienia z eskalacją funkcjonalną. Jeżeli pierwsza linia wsparcia nie potrafi ustalić przyczyny incydentu w ciągu jednej godziny, musi przekazać zgłoszenie do kolejnej linii wsparcia. Jakby Service Desk umiał rozwiązać incydent miałby 8 godzin aby to zrobić (cały czas rozwiązania z SLA).

Analogicznie II linia wsparcia ma 7 godzin na rozwiązanie incydentu. Jednak jeżeli w ciągu jednej godziny nie znajdzie rozwiązania przekazuje incydent do III linii wsparcia, która ma już tylko 6 godzin na rozwiązanie. Jak widać trzecia linia wsparcia ma nie najdłuższy ale najkrótszy czas na rozwiązanie zgłoszenia.

Dla każdego parametru SLA trzeba przeprowadzić analogiczne ćwiczenie aby ustalić, który zespół wsparcia odpowiada, za jaką część parametru SLA.

Pytanie: Czy stosujesz w swojej organizacji OLA i dla jakich parametrów SLA najczęściej?

Artykuł OLA – czy ktoś ją kiedyś widział? pochodzi z serwisu Mariusz Siek.