„Zmiany, zmiany, zmiany … ” cytując za klasykiem z polskiej komedii „Co mi zrobisz jak mnie złapiesz” w reżyserii niezapomnianego Stanisława Barei, to nieodzowny elementy w zarządzaniu usługami. Swoją drogą, wypowiada je ulubiony aktor Barei, Stanisław Tym, który w ostatnich dniach przeszedł na drugą stronę życia.

Jak wiemy z każdą zmianą związane jest ryzyko i każda zmiana wymaga akceptacji, dlatego zmianom poświęca się dużo uwagi, między innymi poprzez praktykę ITIL „Umożliwiania zmian”. Teraz jednak nie o tym.

Systemy i usługi funkcjonują w środowisku, które jest co raz bardziej zmienne, niepewne, złożone i niejednoznaczne (VUCA). Biznes oczekuje wprowadzania co raz więcej zmian, skracania czasu dostarczania usług do klienta i wysokiego poziomu świadczonych usług. Czy jest możliwe poradzić sobie w takich warunkach?

ITIL 4 proponuje cele, zasady, metody i techniki związane z IT wysokich prędkości (High velocity IT), które mają pomóc osiągać zamierzone cele.

1. Kluczowe cele

Kluczowymi celami związanymi z szybkim wprowadzaniem zmian są:

• Wartościowe inwestycje, które wykorzystują IT w sposób strategiczny, innowacyjny i efektywny kosztowo. Organizacje mając określone zasoby, powinny nimi tak zarządzać aby wykorzystywać je do  realizacji projektów i zadań, które będą cechowały się jak największym zwrotem z inwestycji (ROI) i przyczyniały się do osiągania celów strategicznych organizacji.
• Szybki rozwój, który zapewnia sprawnie wykonywane i dostarczane usługi i produkty IT. Wykorzystywane są metodyki Agile i DevOps (DevSecOps), które pozwalają optymalnie wykorzystać cykl wytwarzania usług i produktów, które dostarczane są iteracyjnie i przyrostowo oraz jak najwięcej czynności i działań jest zautomatyzowanych (CI/CD).
• Odporność operacji, gwarantująca wysoką odporność produkcyjnych usług i produktów IT na występowanie incydentów, w szczególności tych poważnych. Wysoka odporność, pozwala na ciągłość działania usług i produktów IT na produkcji. Wystąpienie awarii nie powoduje niedostępności usługi i/lub jest bardzo szybko mitygowane lub naprawiane dzięki zaprojektowanej architekturze oraz automatyzacji.
• Współtworzenie wartości, pozwalające na efektywną interakcję między dostawcami usług a korzystającymi z usług. Dostarczana usługa ma tylko sens, kiedy zapewnia korzystającemu z niej wymaganą wartość, pomaga mu osiągać wyznaczone cele i dostarcza oczekiwanych rezultatów. Rola konsumenta jest równie ważna jak rola dostawcy usług w współtworzeniu wartości.
• Zapewnienie zgodności, zapewniające przestrzeganie wymagań dotyczących nadzoru, zarządzania ryzykiem i zgodności (Governance, Risk, Compliance – GRC). Fakt, że wprowadzamy szybko zmiany, nie oznacza że nie muszą one spełniać zasad, reguł i polityk obowiązujących w organizacji dostawcy usług i konsumenta usług. Zapewnienie zgodności jest kluczowym celem, który powinien być osiągnięty. Nie przestrzeganie zasad, może doprowadzić do nie dostarczenia wartości dla konsumenta.

2. Minimalizacja ryzyka

Aby zmniejszyć ryzyko związane z wprowadzanymi zmianami, zmniejszamy zakres wprowadzanych zmian. Możemy to zrobić dzięki mikrousługom (microservices) i odpowiednio zaprojektowanej architekturze usług i produktów.

Mniejsze zmiany można szybciej wytworzyć, przetestować i wdrożyć na produkcję. Wdrożenie małej zmiany zmniejsza ryzyko niepowodzenia oraz  ewentualne negatywne skutki jakby poszło coś nie tak.

Małą zmianę możemy też szybko wycofać, jeżeli byłaby taka konieczność. Jeżeli wdrażamy dużo i często małych zmian, to doskonalimy nasze umiejętności aby przeprowadzać takie zmiany szybko i bezproblemowo od developmentu do udostępnienie użytkownikom na produkcji.

3. Kluczowe wzorce zachowań

Osiąganie celów opisanych w punkcie 1. wspierane jest przez podejmowanie kluczowych wzorców zachowań, takich jak:

• Akceptacja niejednoznaczności i niepewności. Należy pogodzić się z faktem, że funkcjonujemy w niestabilnym i niejednoznacznym środowisku. Systemy i usługi zawsze będą miały błędy i będą ulegały awariom. Należy to zaakceptować i wykorzystywać eksperymenty w poszukiwaniu rozwiązań i nie obawiać się bezpiecznych i przemyślanych porażek.
• Okazywanie sobie wzajemnego zaufania. Nie można skutecznie i efektywnie współpracować, jeżeli nie można ufać drugiej stronie. Chodzi tu o zaufanie do osób we własnym zespole, pomiędzy zespołami dostawcy usług, w stosunku do partnerów i dostawców czy wreszcie w stosunku do klienta i użytkownika. Szanujemy umiejętności zawodowe innych osób i ufamy, że podejmują dobre decyzje. Szczerze ale również delikatnie przekazujemy informacje zwrotne. Chodzi o stworzenie przyjaznego środowiska pracy, gdzie nie będzie funkcjonowała kultura obwiniania a ludzie będą się czuli dobrze w zgodzie ze swoimi wartościami. Należy zachęcać pracowników do zabierania głosu i dzielenia się wiedzą a kierownictwo do nie odczuwania oporu przed przyznaniem się do niewiedzy lub poproszeniem o pomoc.
• Ciągłe podnoszenie poprzeczki. Należy zawsze kwestionować status quo i nigdy nie być zadowolonym z obecnego stanu. Jeżeli nawet coś działa dzisiaj, może się okazać, że jutro będzie niewystarczające. Zachęcamy do kultury ciągłego doskonalenia, bo zawsze można coś poprawić, udoskonalić lub zmienić, choćby w niewielkim stopniu, z czego będzie zadowolony klient i użytkownicy.
• Pomaganie klientom w realizacji zadań. Każda organizacja powinna stawiać swoich klientów na pierwszym miejscu. Niezależnie jakie zadania czy działania wykonuje dostawca usług, powinien pamiętać, że odbiorcą usług i produktów jest klient i użytkownik. Ich satysfakcja i zadowolenie z korzystania z usługi lub produktu, powinno być najważniejszy celem dostawcy usług. Jeżeli klient lub użytkownik będzie niezadowolony, to niezależnie co zrobił dostawca nie będzie to miało znaczenia. Usługi i produktu oraz praktyki wykonywane przez dostawcę muszą dostarczać wartość oraz wspierać osiąganie rezultatów oczekiwanych przez korzystającego z usług.
• Zobowiązanie się do ciągłego pogłębiania wiedzy. Świat zmienia się tak szybko, że jeżeli się nie rozwijamy, doskonaląc naszą wiedzę i umiejętności, to się cofamy. Ten wzorzec zachowań stanowi podstawę wszystkich pozostałych. Musimy być świadomi potrzebnych informacji i wiedzy, które należy pozyskać aby podejmować lepsze decyzje. Pamiętamy o niejednoznaczności i niepewności, co oznacza że nie jesteśmy przewidzieć wszystkiego w zmiennym środowisku. Każdy w organizacji powinien ciągle się uczyć, poszerzać swoją wiedzę i zwiększać poziom posiadanych informacji. W ciągłym uczeniu pomagają krótkie pętle informacji zwrotnych oraz przeprowadzanie eksperymentów kwestionujących i doskonalących hipotezy.

Kierowanie się opisanymi kluczowymi celami i przyjmowanie kluczowych wzorców zachowań, pomaga mieć kontrolę nad zmiennym, niestabilnym i niejednoznacznym środowisku.

Zachowajmy otwartość umysłu, poszerzajmy ciągle swoją wiedzę i pamiętajmy o dostarczaniu i współtworzeniu wartości z klientem, a pojawiające się zagrożenia będziemy w stanie zidentyfikować i podjąć skuteczne działania aby każdą zmianę zakończyć z sukcesem.

Jak jesteś przygotowany na wprowadzanie wielu zmian w środowisku VUCA?

Artykuł Prosto o ITIL – Jak wprowadzać szybko i bezpiecznie zmiany? pochodzi z serwisu Mariusz Siek.

1.  Święta, święta i po świętach

Koniec roku to czas do podsumowań, refleksji i wyciągania wniosków z tego co już minęło. Ja również podsumuję może nawet więcej niż rok.

Od czasu do czasu słyszę głosy, że ITIL kończy się powoli. Nie przystaje do obecnych czasów, nie wprowadza nic nowego tylko odświeża to co już było 10-15 lat temu. Zacząłem się zastanawiać czy faktycznie tak jest, przecież w każdej plotce jest część prawdy. To jaka ta prawda „naprawdę” jest? Skąd biorą się takie opinie i czy mają uzasadnienie?

Od razu chcę jasno powiedzieć, że każdy może mieć swoje zdanie i ja to zdanie szanuję, w końcu każdy człowiek jest innym, ma swoje doświadczenie i swój własny świat. Nie będę próbował nikogo przekonywać czy starał się zmienić jego opinię. To jest wyłącznie moje doświadczenie, spostrzeżenia i wnioski płynące z serca.

2.  Dawno, dawno temu w odległej galaktyce …

Moja przygoda i podróż z ITIL zaczęła się w październiku 2005 roku, kiedy to brałem udział w szkoleniu ITIL Foundation. ITIL był wtedy w wersji 2 i był to dla mnie całkiem nowy obszar wiedzy. Początek też nie był typowy bo w praktyce zacząłem zajmować się katalogiem usług i umową SLA. W tamtym czasie większość zaczynała od Service Desku, zarządzania incydentami, problemami, zmianą i konfiguracją. Kiedyś napiszę szczegółowo moją historię z ITIL.

Spodobał mi się ten ITIL i zacząłem zdobywać doświadczenie oraz kolejne obszary wiedzy oraz certyfikaty.

ITIL v2 składał się z 11 procesów podzielonych na dwa obszary Service Support (zarządzanie incydentami, problemami, zmianami, wersją i konfiguracją)  i Service Delivery (zarządzanie poziomem usług, dostępnością, pojemnością, ciągłością, bezpieczeństwem i finansowe) i jednej funkcji Service Desk.

Organizacje wdrażały wybrane procesy i wykorzystywały najlepsze praktyki w zarządzaniu usługami IT. Była też możliwość certyfikacji ISO 20000, która potwierdzała, że organizacja ma „wdrożone” wszystkie 11 procesów. Był to elitarne grono, również w Polsce było trochę takich organizacji z tym certyfikatem.

Dzięki wykorzystaniu ITIL, organizacje mogły efektywnie obsługiwać incydenty, problemy, zmiany, zarządzać CMDB itd.. Jeżeli ktoś korzystał z ITIL postrzegany był jako zaawansowany w zarządzaniu usługami IT. Jeżeli organizacja chciała, miała możliwość wdrożenia wszystkich 11 procesów i jednej funkcji.

3.  ITIL v3 czas na zmiany

Około 2007 roku rozpoczęło się wprowadzanie nowej wersji ITIL. Ilość procesów wzrosła do 27. Pojawił się cykl życia usługi od strategii, przez projektowanie, wdrożenie, operacje a skończywszy na ciągłym doskonalenie. Oczywiście procesy z ITIL v2 zostały jednak pojawiły się całkiem nowe, które miały uzupełnić aktywności na poszczególnych etapach cyklu życia usługi. Pewne luki, które były dostrzegane w ITIL v2 zostały wypełnione i został zamknięty cały cykl życia usługi. Oczywiście wdrożenie wszystkich procesów było już dużym wyzwaniem i organizacje korzystały z tych, które były im w danym momencie potrzebne. Zresztą zasada ITIL „adopt and adapt”, oznacza, że wybieramy i dopasowujemy te elementy ITIL, które pasują do naszych potrzeb.

4.  Kto się nie rozwija ten się cofa

ITIL zawsze potrafił słuchać potrzeb biznesu  oraz IT i dopasowywać się do zmian w technologii i otoczeniu biznesowym. Rozglądał się również dookoła i zauważał inne metodyki pracy takie jak Lean, Agile, DevOps. Miał jednak świadomość, że każdej czegoś brakuje i sam ITIL w pewnych obszarach jest niewystarczający.

Na tej bazie w 2020 roku powstał ITIL 4, który wskazuje konieczność dostarczania wartości, skupieniu się na doświadczeniu użytkownika i klienta, strumieniach wartości oraz transformacji cyfrowej. Widzi również potrzebę szukania synergii z innymi metodykami pracy Lean, Agile i DevOps, poprzez wprowadzenie siedmiu podstawowych zasad. Z nowych rzeczy, oprócz podstawowych zasad, pojawia się system wartości usług (SVS), jako model zarządzania usługami IT oraz łańcuch wartości usług, którego sześć działań pomaga tworzyć strumienie wartości w organizacjach.

Możemy również wykorzystać cztery wymiary zarządzania usługami, które pozwalają na całościowe, holistyczne spojrzenie na zagadnienia związane z zarządzaniem usługami. Mamy 34 praktyki jako mięso zarządzania usługami i główne narzędzie do realizacji pracy i osiągania celu w ramach kroków  strumieniu wartości usług.

5.  Gdzie jest obecnie problem z wykorzystaniem ITIL?

Według mnie wiedzy, metod, praktyk i technik jest tak dużo, że komuś zaczynającemu trudno jest się w tym odnaleźć i zrozumieć od czego zacząć, co wybrać i na czym się skupić. Ponad 3 lata już prowadzę szkolenia z ITIL 4 i mogę powiedzieć, że dopiero teraz poznałem i rozumiem kluczowe elementy, nie jest to jednak jeszcze cała wiedza. Nikt nie czyta wszystkich 34 praktyk i bardzo dobrze, bo nie taki jest cel ITIL.

Niezależnie co robisz, pamiętaj o wspomnianej już zasadzie „adopt and adapt”. Selektywnie wybieraj tą wiedzę, która jest Tobie lub Twojej organizacji potrzebna i stosuj ją w praktyce, pamiętając o zaczynaniu, tam gdzie się aktualnie znajdujesz, podejściu iteracyjnym z informacją zwrotna oraz ciągłym doskonaleniu. Wykorzystanie ITIL to nie pojedyncze wdrożenie ale podróż i droga, która nigdy się nie kończy. Nie wystarczy coś zrobić jednorazowo, trzeba cały czas to udoskonalać, rozwijać, jeżeli trzeba rozszerzać, obserwując co działa a co nie. ITIL to nie jest już metodyka ale cała filozofia działania, która pomaga funkcjonować w świecie VUCA i nadążać za szybkim tempem zmian, jakie stawia przed IT biznes.

Jeżeli ktoś jest na etapie, że nie ma świadomości, że nie wie, to jak może wybrać najlepsze praktyki zarządzania, skoro jest to dla niego nieistniejąca galaktyka? Jak nie mając podstaw w zarządzaniu usługami, a takie podstawy daje ITIL Foundation, można zarządzać usługami IT? Dlaczego nie chcemy poznać tych zasad, które pomogą nam przebyć tą podróż w sposób świadomy, prostszy, skuteczny? Dlaczego organizacje nie doceniają ponad 30 lat doświadczenia zbieranego w różnych obszarach zarządzania usługami?

6.  Recepta na bolączki?

Każdy, kto w organizacji zajmuje się w jakimś stopniu zarządzaniem usługi IT a tak naprawdę, jest to każda osoba, która pracuje w dziale IT, powinna przejść szkolenie ITIL 4 Foundation. To są podstawy aby zrozumieć model usługowy i poznać język i słownictwo, którym wszyscy powinni się posługiwać. Na tym szkoleniu oprócz nowych elementów ITIL 4, poznaje się 15 praktyk, które są najczęściej wykorzystywane w organizacjach. Nadal jest to podstawowa wiedza ale daje ona możliwości dalszego rozwoju.

Są oczywiście kolejne szkolenia i kto będzie potrzebował tej wiedzy może w nich uczestniczyć ale żadne szkolenie, nie zastąpi samokształcenia i samodzielnego rozwoju i nauki. O każdej z 34 praktyk trzeba doczytać samemu. Zagłębić się w te tematy, które aktualnie są dla Ciebie ważne i którymi się zajmujesz. Opis 34 praktyk to źródło nieocenionej wiedzy dla każdego do początkującego po doświadczonego w zarządzaniu usługami. Poznawaną wiedzę trzeba stosować w praktyce inaczej bardzo szybko ulatuje z ludzkiego umysłu.

Pamiętajcie, że ten rozwój musi być ciągły, systematyczny, regularny. Działanie zrywami nie jest skuteczne. Małe ale regularnie wykonywane kroki dotyczące rozwoju wiedzy, umiejętności i kompetencji,  czasem przynoszą oczekiwanie rezultaty.

W podróży z ITIL można skorzystać z pomocy doświadczonych specjalistów, w końcu podróż z drugim człowiekiem (ludźmi) jest ciekawsza, łatwiejsza, nie nudzi się i mija szybciej. Jeżeli wiec nie mamy wystarczającej wiedzy, doświadczenia i czasu aby samemu poznawać i wykorzystywać najlepsze praktyki ITIL, znajdźmy kogoś kto podzieli się swoją wiedzą, doświadczeniem i umiejętnościami. Tak, trzeba ponieść tego koszty ale lepiej patrzeć na to jak na inwestycję we własny rozwój, doskonalenie i transformację. Może się okazać, że taka pomoc przemieni się z czasem w partnerstwo i wspólne podążanie wybraną drogą.

Artykuł Czy ITIL umarł? pochodzi z serwisu Mariusz Siek.

W poprzednich artykułach opisywałem strumienie wartości „Jak utworzyć nową usługę” i „Jak przywrócić usługę do działania”. Żeby strumień wartości był efektywny, skuteczny i dostarczał wartości, musimy mierzyć jego parametry i podejmować działania aby te wartości były jak najlepiej dopasowane do danego strumienia. Jakie to parametry?

1.  Czas cyklu (Cycle time)

Czas cyklu określa ile czasu jest wykonywana określona jednostka pracy, zadanie, przekształcając dane wejściowe w wyniki. Jest to czas, który faktycznie poświęcamy na realizację zadania. Przykładowo, jeżeli service desk rozwiązuje incydent zgłoszony przez użytkownika w ciągu 30 minut, to oznacza że czas cyklu wynosił 30 minut.

Jeżeli to możliwe, to optymalizujemy i skracamy czas cyklu, dzięki temu możemy skrócić czas realizacji strumienia wartości.

2.  Kolejka (Queue)

Kolejka wskazuje na ilość jednostek pracy, zadań, działań, które oczekują na wykonanie. Im krótsza kolejka tym lepiej. Na długość kolejki może mieć wpływ sposób jej obsługi, rozładowania. Dlatego zalecane jest aby zadania z kolejki były pobierane (pull), wtedy gdy wykonujący zadanie, pracę zakończył wykonywanie poprzedniego zadania. Wydłużać kolejkę może podejście wypychania zadań z kolejki (push), bez weryfikacji czy poprzednie zadanie zostało już zakończone.

W kolejce mogą oczekiwać zgłoszenia, które trafiają do service desku, zanim zostaną obsłużone przez pierwszą lub kolejne linie wsparcia.

3.  Czas oczekiwania (Wait time)

Czas oczekiwania jest ściśle powiązany z kolejką i określa ile czasu dana jednostka pracy, zadanie czeka, zanim zostanie pobrana do realizacji. Parametr ten może w znaczący sposób wydłużać czas jaki jest potrzebny do przejścia danej pracy przez cały strumień wartości. Na skracaniu czasu oczekiwania można uzyskać największe optymalizacje w strumieniu wartości.

Czasem oczekiwania może być czas od przekazania zgłoszenia od użytkownika do service desk do potwierdzenia użytkownikowi przyjęcia zgłoszenia.

4.  Czas realizacji (Lead time)

Czas realizacji to suma czasu cyklu i czasu oczekiwania. Jest to całkowity czas jaki jest potrzebny do ukończenia jednostki pracy od momentu kiedy znalazła się w kolejce do czasu zakończenia zadania.

Czasem realizacji może być czas od przekazania zgłoszenia (incydentu) od użytkownika do service desk do rozwiązania incydentu przez service desk.

5.  Praca w toku (Work-in-Progress, WiP)

Praca w toku to ilość jednostek pracy, które zostały rozpoczęte ale nie zostały jeszcze zakończone. Dążymy do minimalizowania pracy w toku, tak aby nie zaczynać nowych zadań, jeżeli nie zakończyliśmy już rozpoczętych. Minimalizacja pracy w toku, jest to jeden z głównych celów optymalizacji działania strumienia wartości.

Ilość zgłoszeń otwartych w service desk, określa nam pracę w toku.

6.  Przepustowość (Throughput)

Przepustowość to ilość jednostek pracy, które mogą być wykonane w określonym przedziale czasu, np. 8 godzin.  Jest to zdolność strumienia wartości do przetwarzania określonej ilości zadań/pracy, wskazując na jego wydajność i potencjał.

Ilość zgłoszeń jakie service desk może obsłużyć w ciągu dnia roboczego wyznacza nam przepustowość danego strumienia wartości.

Wszystkie opisane parametry strumienia wartości należy na bieżąco mierzyć i monitorować dla wszystkich strumieni wartości w organizacji, aby mieć wiedzę jak one działają i podejmować aktywności gdy występują problemy z przepływem pracy.

Takim przykładem mogą być wąskie gardła (bottleneck) w strumieniu wartości, które objawiają się piętrzeniem, zatorami  w wykonywaniu zadań w kroku strumienia wartości, podczas gdy w innych, dalszych krokach pracy jest niewiele. Usunięcie wąskiego gardła w jednym roku, może skutkować, że pojawi się ono w kolejnym, dlatego trzeba usuwać wąskie gardła aż do końca strumienia wartości i optymalizować cały strumień a nie tylko jeden krok.

Jakie parametry strumienia wartości mierzysz i monitorujesz?

Artykuł Prosto o ITIL – Jak mierzyć strumień wartości? pochodzi z serwisu Mariusz Siek.

W poprzednim artykule opisywałem jak utworzyć nową usługę za pomocą strumienia wartości usług. Drugim najczęściej występującym w organizacjach strumieniem wartości jest „Przywrócenie usługi do działania”. O kluczowych elementach strumienia wartości usług możesz zapoznać się w artykule „Prosto o ITIL – Jak Strumienie Wartości Usług dostarczają wartość?”

Dostawca usług świadczy swoje usługi konsumentom i zapewnia wsparcie użytkownikom w przypadku gdy usługa przestanie funkcjonować, musi ją jak najszybciej przywrócić do działania. Zapewnia mu to dobrze opracowany i wdrożony strumień wartości.

Składa się on z następujących elementów.

1. Wejścia strumienia

Wejściem do strumienia wartości usług jest potrzeba przywrócenia wartości, jaką jest prawidłowo działająca usługa. Wymagania te mogą pochodzić od:

• Użytkowników, którzy nie mogą korzystać z produktu lub usługi działającej na produkcji. Ta utrata produktywności prowadzi do utraty wartości.
• Monitoringu, prowadzonego przez dostawcę usług, w celu wykrywania zdarzeń, które wpływają na niedziałanie lub niepoprawne działanie usługi. Te proaktywne działania pozwalają rozwiązywać incydenty, zanim zostaną zgłoszone przez użytkowników. W takim przypadku można powiadomić użytkowników o podjętych działaniach.

2. Kroki strumienia

Krok 1 – Potwierdź i zarejestruj zapytanie od użytkownika

1. Działanie łańcucha wartości usług – Angażowanie
2. Opis  – Zaangażowanie klienta lub użytkownika w celu zebrania jak najwięcej informacji o zgłoszeniu i zarejestrowaniu go przez Service Desk. Na tym etapie nie jest jeszcze wiadomo czy mamy do czynienia z incydentem, problemem, wnioskiem o usługę czy zmianą.
3. Wspierające praktyki zarządzania

1. 1. Zarządzanie katalogiem usług
   2. Service Desk

Krok 2 – Zaklasyfikuj zapytanie jako incydent i podejmij próbę jego rozwiązania

1. Działanie łańcucha wartości usług – Dostarczanie i wspieranie
2. Opis  – Agent Service Desk, na podstawie zarejestrowanych informacji, klasyfikuje zapytanie od użytkownika jako incydent i podejmuje próbę jego rozwiązania. W tym celu korzysta z Bazy Wiedzy, w której wyszukuje gotowe rozwiązanie dla zgłoszonego incydentu.
   Jeżeli rozwiązanie przywraca usługę do działania kończy się strumień wartości, ponieważ odzyskaliśmy wartość.
   Jeżeli Agent SD nie znajduje rozwiązania w bazie wiedzy, eskaluje (przekazuje) incydent do obsługi przez specjalistów w odpowiednim zespole wsparcia (kategoria incydentu).
3. Wspierające praktyki zarządzania

1. 1. Zarządzanie konfiguracją usług
   2. Zarządzanie incydentami
   3. Zarządzanie wiedzą
   4. Monitorowanie i zarządzanie zdarzeniami
   5. Service Desk

Krok 3 – Uzyskaj poprawkę od zespołu specjalistów

1. Działanie łańcucha wartości usług – Uzyskanie/tworzenie
2. Opis  – Wykonanie tego kroku może być przeprowadzone w zależności od kontekstu, w różny sposób:

1. 1. Agent SD szuka poprawki na stronie www dostawcy zewnętrznego (vendor). Cały czas kontrola incydentu jest po stronie SD a nie vendora.
   2. Agent SD zgłasza incydent do dostawcy zewnętrznego (vendor). Mamy równoległe incydenty w systemie zgłoszeń dostawcy usługi i dostawcy zewnętrznego. Kontrola incydentu jest po stronie SD.
   3. Agent SD przekazuje incydent do wewnętrznego zespołu wsparcia, jednocześnie przekazując jego kontrolę.
   4. Agent SD przekazuje incydent do zewnętrznego zespołu wsparcia. Kontrola incydentu może zostać po stronie SD lub być przekazana na zewnątrz.

1. Wspierające praktyki zarządzania

1. 1. Zarządzanie konfiguracją usług
   2. Zarządzanie incydentami
   3. Zarządzanie infrastrukturą i platformami
   4. Zarządzanie wiedzą
   5. Service Desk
   6. Zarządzanie finansowe usługami
   7. Walidacja i testowanie usług
   8. Programowanie i zarządzanie oprogramowaniem
   9. Zarządzanie dostawcami

Krok 4 – Wdróż poprawkę

1. Działanie łańcucha wartości usług – Projektowanie i przekazywanie
2. Opis  – Po uzyskaniu, przetestowaniu i walidacji, poprawka dla incydentu wdrażana jest dla użytkownika lub do środowiska produkcyjnego. Wdrożenie może zostać przeprowadzone na kilka sposobów np. z wykorzystaniem continuous integration/continuous delivery (CI/CD) w celu dystrybucji rozwiązania na produkcję.
3. Wspierające praktyki zarządzania

1. 1. Zarządzanie konfiguracją usług
   2. Zarządzanie wdrażaniem
   3. Zarządzanie incydentami
   4. Zarządzanie wiedzą
   5. Service Desk
   6. Zarządzanie finansowe usługami
   7. Programowanie i zarządzanie oprogramowaniem
   8. Zarządzanie dostawcami

Krok 5 – Zweryfikuj, że incydent został rozwiązany

1. Działanie łańcucha wartości usług – Dostarczanie i wspieranie
2. Opis  – Po wdrożeniu poprawki na produkcję, należy zweryfikować czy jest ona skuteczna i rozwiązała incydent. Potwierdzenie rozwiązania incydentu powinien wykonać użytkownik (zgłaszający) aby sprawdzić czy wartość została odzyskana w satysfakcjonujący sposób, z perspektywy użytkownika a nie dostawcy usług. W tym celu agent SD kontaktuje się z użytkownikiem. Incydent może być zamknięty po potwierdzeniu rozwiązania przez użytkownika
3. Wspierające praktyki zarządzania

1. 1. Zarządzanie incydentami
   2. Zarządzanie wiedzą
   3. Zarządzanie konfiguracją usług
   4. Service Desk
   5. Zarządzanie poziomem świadczenia usług

Krok 6 – Uzyskaj informacje zwrotne od klienta

1. Działanie łańcucha wartości usług – Angażowanie
2. Opis  – Po rozwiązaniu incydentu należy poprosić klienta/użytkownika lub innych interesariuszy o informacje zwrotna, która pozwoli zidentyfikować możliwości poprawy usługi, sposób komunikacji z użytkownikiem, procedury obsługi incydentów lub praktyki, które są wykorzystywane w strumieniu wartości.
3. Wspierające praktyki zarządzania

1. 1. Ciągłe doskonalenie
   2. Zarządzanie infrastrukturą i platformami
   3. Service Desk
   4. Programowanie i zarządzanie oprogramowaniem
   5. Zarządzanie dostawcami

Krok 7 – Zidentyfikuj możliwości doskonalenia

1. Działanie łańcucha wartości usług – Doskonalenie
2. Opis  – Na podstawie zebranych informacji zwrotnych od wszystkich interesariuszy można zaplanować działania związane z doskonaleniem obejmujące: komponenty systemu wartości usług SVS, strumień wartości usług, relacje z klientem, użytkownikiem, dostawcą zewnętrznym lub innymi interesariuszami, sposoby definiowania i postrzegania wartości. Inicjatywy związane z doskonaleniem muszą być zarejestrowane w rejestrze ciągłego doskonalenia i następnie w odpowiedni sposób zarządzone.
3. Wspierające praktyki zarządzania

1. 1. Zarządzanie konfiguracją usług
   2. Ciągłe doskonalenie
   3. Zarządzanie wdrożeniem
   4. Zarządzanie incydentami
   5. Zarządzanie infrastrukturą i platformami
   6. Zarządzanie wiedzą
   7. Monitorowanie i zarządzanie zdarzeniami
   8. Zarządzanie problemami
   9. Zarządzanie ryzykiem
   10. Service Desk
   11. Finansowe zarządzanie usługą
   12. Walidacja i testowanie usług
   13. Zarządzanie poziomem świadczenia usług
   14. Programowanie i zarządzanie oprogramowaniem
   15. Zarządzanie dostawcami

3. Wyjście strumienia

Po rozwiązaniu incydentu, usługa zostaje naprawiona i odzyskane jest dostarczana wartość. Użytkownicy mogą w pełni korzystać z możliwości jakie daje usługa.

Każdy krok w strumieniu wartości usług „Przywrócenie usługi do działania” przyczynia się do tworzenia wartości. Głównymi narzędziami wspierającymi współtworzenie wartości są wymienione w każdym kroku praktyki zarządzania. Bez korzystania z odpowiedniego zestawu praktyk dla każdego z kroków, nie jest możliwe dostarczanie wartości.

Czy mógłbyś zastosować taki strumień wartości w swojej organizacji? Jakiego kroku Ci brakuje lub jaki według Ciebie jest niepotrzebny. Zapraszam do dyskusji.

Artykuł Prosto o ITIL – Jak strumień wartości przywraca usługę do działania? pochodzi z serwisu Mariusz Siek.

W poprzednim artykule opisywałem jak strumień wartości usług dostarcza wartość. Zostały omówione kluczowe elementy strumienia wartości usług. Teraz czas pokazać jak taki strumień wartości może wyglądać w rzeczywistości.

Jednym z najczęściej występujących w organizacjach strumieniem wartości jest „Utworzenie nowej usługi”.

Składa się on z następujących elementów.

1.  Wejścia strumienia

Wejściem do strumienia wartości usług są wymagania, potrzeby związane z nową usługą. Potrzeby te mogą pochodzić od:

• Konsumentów, takich jak klient, użytkownik i sponsor, którzy mogą być wewnętrzni lub zewnętrzni w stosunku do organizacji dostawcy usług
• Zewnętrznych interesariuszy, innych niż konsumenci, np. dostawca zewnętrzny lub regulator
• Członków organizacji biznesowej dostawcy usług, takich jak sprzedaż lub marketing, którzy dostrzegli szanse związane z dostarczeniem nowej usługi
• Członków organu zarządczego w organizacji, podejmujących strategiczne decyzji związane z portfelem świadczonych usług.

2.  Kroki strumienia

Krok 1 – Zrozum i udokumentuj żądanie nowej usługi

1. Działanie łańcucha wartości usług – Angażowanie
2. Opis  – Wszystkie wymagania związane z nową usługą zbierane są od wymaganych interesariuszy i dokumentowane w formie pisemnej. Do tego celu możemy wykorzystać business case, który będzie zawierał wymagania, korzyści ilościowe i jakościowe, koszty i ryzyka.
3. Wspierające praktyki zarządzania

1. 1. Analiza biznesowa
   2. Zarządzanie konfiguracją usług
   3. Zarządzanie relacjami
   4. Zarządzanie poziomem świadczenia usług (SLM)
   5. Zarządzanie portfelem usług

Krok 2 – Zdecyduj czy inwestować w nową usługę

1. Działanie łańcucha wartości usług – Planowanie
2. Opis  – Po udokumentowaniu wymagań w business case i wstępnej ocenie kosztów, korzyści i ryzyk należy zaplanować prace do wykonania, prowadząc rozmowy z wewnętrznymi zespołami, klientem i innymi kluczowymi interesariuszami. Opracowany plan przedstawiany jest zespołowi zarządzającemu, który podejmuje decyzję czy będzie realizowany czy zostanie odrzucony .
3. Wspierające praktyki zarządzania

1. 1. Analiza biznesowa
   2. Zarządzanie konfiguracją usług
   3. Zarządzanie infrastrukturą i platformami
   4. Zarządzanie problemami
   5. Zarządzanie projektem
   6. Zarządzanie ryzykiem
   7. Projektowanie usług
   8. Service desk
   9. Finansowe zarządzanie usługami
   10. Zarządzanie poziomem świadczenia usług (SLM)
   11. Zarządzanie portfelem usług
   12. Programowanie i zarządzanie oprogramowaniem

Krok 3 – Zaprojektuj architekturę nowej usługi tak aby spełniała wymagania klienta

1. Działanie łańcucha wartości usług – Projektowanie i przekazywanie
2. Opis  – Nowa usługa projektowana jest tak aby spełnić wymagania zgłoszone przez klienta. Na tym etapie przekłada się wymagania biznesowe na specyfikacje, które będą zrozumiałe dla zespołów IT. Weryfikowane jest jak można wykorzystać już istniejące komponenty (elementy konfiguracji). Wszystkie informacje zapisywane są w pakiecie projektowym usługi ( Service design package).
3. Wspierające praktyki zarządzania

1. 1. Zarządzanie architekturą
   2. Zarządzanie dostępnością
   3. Analiza biznesowa
   4. Zarządzanie potencjałem wykonawczym i wydajnością
   5. Zarządzanie konfiguracją usług
   6. Zarządzanie bezpieczeństwem informacji
   7. Zarządzanie infrastrukturą i platformami
   8. Zarządzanie projektem
   9. Zarządzanie ciągłością działania usług
   10. Projektowanie usług
   11. Zarządzanie poziomem świadczenia usług (SLM)
   12. Zarządzanie portfelem usług
   13. Programowanie i zarządzanie oprogramowaniem
   14. Zarządzanie dostawcami

Krok 4 – Utwórz komponenty usługi i potwierdź ich zgodność z potrzebami biznesowymi

1. Działanie łańcucha wartości usług – Uzyskanie/tworzenie
2. Opis  – Tworzone komponenty mogą dotyczyć aspektów technicznych: oprogramowanie, serwery, macierze, sieci jak również nietechnicznych: nowa struktura zespołu, nowe role, krytyczne umiejętności i kompetencje, artykuły bazy wiedzy, dokumentacja szkoleniowa. O informacje dotyczące komponentów aktualizowany jest pakiet projektowy usługi.
3. Wspierające praktyki zarządzania

1. 1. Zarządzanie konfiguracją usług
   2. Zarządzanie infrastrukturą i platformami
   3. Zarządzanie projektem
   4. Zarządzanie wydaniem
   5. Zarządzanie ryzykiem
   6. Zarządzanie portfelem usług
   7. Walidacja i testowanie usług
   8. Programowanie i zarządzanie oprogramowaniem
   9. Zarządzanie dostawcami

Krok 5 – Wdrażaj produkty i usługi na produkcji

1. Działanie łańcucha wartości usług – Projektowanie i przekazywanie
2. Opis  – Gotowe, wytworzone nowe komponenty usług przenoszone są do środowiska produkcyjnego w ramach wdrożenia. Można wykorzystać podejście Continous Integration, Continous Deployment (CI/CD). W metodyce Agile i DevOps, przeniesienie do produkcji (wdrożenie), nie oznacza udostępnienia do użytku (wydanie).
3. Wspierające praktyki zarządzania

1. 1. Umożliwianie zmian
   2. Zarządzanie konfiguracją usług
   3. Zarządzanie wdrożeniem
   4. Zarządzanie incydentem
   5. Zarządzanie wiedzą
   6. Zarządzanie problemem
   7. Zarządzanie projektem
   8. Zarządzanie wydaniem
   9. Service desk
   10. Zarządzanie dostawcami

Krok 6 – Udostępnij nową usługę klientom i użytkownikom

1. Działanie łańcucha wartości usług – Dostarczanie i wspieranie
2. Opis  – Opracowywany jest plan wydania (release plan), zgodnie z którym usługa jest udostępniana klientom i użytkownikom do użytku. Tworzone są materiały promocyjne pokazujące funkcjonalności nowej usługi.
3. Wspierające praktyki zarządzania

1. 1. Zarządzanie konfiguracją usług
   2. Zarządzanie incydentem
   3. Zarządzanie infrastrukturą i platformami
   4. Zarządzanie problemem
   5. Zarządzanie projektem
   6. Zarządzanie wydaniem
   7. Zarządzanie relacjami
   8. Service desk
   9. Programowanie i zarządzanie oprogramowaniem
   10. Zarządzanie dostawcami

3.  Wyjście strumienia

Po udostępnieniu usługi użytkownicy mogą z niej korzystać w relacji usługowej i dzięki temu dostarczać oczekiwane rezultaty i współtworzyć wartość.

Każdy krok w strumieniu wartości usług „Utworzenie nowej usługi” przyczynia się do tworzenia wartości. Głównymi narzędziami wspierającymi współtworzenie wartości są wymienione w każdym kroku praktyki zarządzania. Bez korzystania z odpowiedniego zestawu praktyk dla każdego z kroków, nie jest możliwe dostarczanie wartości.

Czy mógłbyś zastosować taki strumień wartości w swojej organizacji? Jakiego kroku Ci brakuje lub jaki według Ciebie jest niepotrzebny. Zapraszam do dyskusji.

Artykuł Prosto o ITIL – Jak utworzyć nową usługę za pomocą strumienia wartości usług? pochodzi z serwisu Mariusz Siek.

Proces 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?

Artykuł Eskalacja funkcjonalna a hierarchiczna – czy ich używasz? pochodzi z serwisu Mariusz Siek.

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.