Organizacja która zdecyduje się na wprowadzenie profesjonalnych standardów zarządzania usługami IT (ang. IT Service Management – ITSM), najprawdopodobniej skorzysta z zaleceń zawartych w zbiorze dobrych praktyk dla działów IT czyli biblioteki ITIL (ang. Information Technology Infrastructure Library). ITIL został opracowany w Wielkiej Brytanii. Jego początki sięgają lat 80 XX wieku ale jest stale rozwijany i obecnie aktualną wersją jest wersja trzecia. Określenie ITIL’a standardem byłoby na wyrost. Jest to raczej zestaw szczegółowych metod postępowania oraz rekomendacji mających na celu dostarczanie usług IT dla biznesu w efektywny, skuteczny i dopasowany sposób.
Słowo „szczegółowych” zostało użyte celowo, ponieważ dogłębne poznanie i zrozumienie ITIL’a może wymagać odbycia wielu szkoleń oraz lat praktyki. W tym artykule postaram się opisać w przystępny sposób wybrane procesy Incident, Change i Problem Management, związane z zarządzaniem usługami IT (ITSM) definiowane przez ITIL v3 oraz wskazać jakie relacje zachodzą między nimi.
Incident Management (IM): Jeżeli organizacja zastanawia się od czego zacząć wdrożenie procesów ITSM to najbardziej naturalnym wyborem będzie proces Incident Management’u. O incydencie jest mowa wówczas gdy usługa IT w niezamierzony sposób przestaje działać (np. serwer aplikacji nie odpowiada) lub następuje spadek jakości jej działania (np. spowolnienie transmisji danych w sieci). Czyli jest to sytuacja która może dotyczyć każdego użytkowanego systemu i na wypadek której należałoby się dobrze przygotować. Proces IM zajmuje się cyklem życia incydentów a jego priorytetowym celem jest jak najszybsze przywrócenie usługi do normalnego działania oraz ograniczenie negatywnego wpływu na działalność biznesową. W skład wspomnianego cyklu życia wchodzą m.in. takie działania jak wykrycie incydentu oraz jego zarejestrowanie (np. w systemie zgłoszeniowym), diagnoza przyczyny, naprawienie oraz odzyskanie usługi. W przypadku gdyby nie udało się całkowicie naprawić usterki a zastosowano jedynie tymczasowe rozwiązanie (ang. Workaround) lub przyczyna incydentu nie została do końca rozpoznana i zachodzi ryzyko powtórzenia się awarii, dalsze analizy będą wykonywane w ramach procesu Problem Management.
Problem Management (PM): Proces ten ma na celu całkowite wyeliminowanie problemu i tym samym ograniczenie towarzyszących mu incydentów lub ewentualnie zredukowanie negatywnego wpływu incydentów w przypadku gdyby problemu nie dało się całkowicie rozwiązać. Problem Management poszukuje odpowiedzi co doprowadziło do zaistnienia problemu oraz wspiera poszukiwanie przyczyny (ang. Root Cause Analysis) incydentu w następujący sposób:
- Pozwala zarejestrować problem oraz wskazać referencje do powiązanych incydentów.
- Przechowuje informacje zebrane podczas analizy problemu oraz opis rozwiązania tymczasowego lub trwałego
Udokumentowane rozwiązanie problemu, dzięki interfejsowi z procesem Knowledge Management , można umieścić w bazie znanych błędów (ang. Known Error Database) i korzystać z niego za każdym razem gdy wystąpi opisany problem.
Przygotowanie do implementacji rozwiązania, wymaga od procesu PM zagwarantowania, że odbywa się to w zgodzie z obowiązującymi procedurami Change Management.
Change Management (ChM) ma na celu obsługę zmian w systemie IT w jednorodny i kontrolowany sposób, zgodnie z przyjętymi procedurami. Chodzi o zapewnienie, że zmiany:
- zostały poddane ocenie wpływu na system oraz odpowiednie elementy infrastruktury (CI ang. Configuration Items) zostały zidentyfikowane i powiązane ze zmianą w bazie CMDB (ang. Configuration Management Database),
- niosą ze sobą konkretne korzyści,
- uzyskały akceptację,
- nie zakłócą działania środowiska IT
Zmiany mogą wynikać z błędów, które wykryto podczas analizy incydentów lub problemów. Mogą być także zgłaszane przez użytkowników oraz członków zespołu IT lub być związane z koniecznością dostosowania systemu do zewnętrznych regulacji. W chwili gdy zmiana została opracowana i jest gotowa (m.in. przeszła pomyślnie testy) do wdrożenia (zadania realizowane w ramach procesu Release and Deployment Management), Change Manager uzgadnia dogodny i nie kolidujący z działalnością biznesową termin implementacji. Gdy zmiana zostanie faktycznie wdrożona, dobrą praktyką jest weryfikacja czy działa zgodnie z założeniami (ang. Post Implementation Review) oraz zamknięcie powiązanych z nią problemów oraz znanych błędów.
Na koniec przykład służący zobrazowaniu jak opisane procesy działają w praktyce.
Incident Management: użytkownik zgłasza brak danych w systemie. Zespół operacyjny ustala, że plik z danymi nie został załadowany do systemu i aby szybko rozwiązać incydent wykonuje ręczne ładowanie danych.
Problem Management: problem zostaje poddany analizie, która prowadzi do ustalenia przyczyny z powodu której plik nie jest automatycznie ładowany do systemu. Pomimo tego, że powstaje opis rozwiązania to nadal funkcjonuje obejście ponieważ zmianę należy wykonać zgodnie z procedurą zarządzania zmianami.
Change Management: Zmiana zostaje poddana weryfikacji. Potwierdzono jej zasadność, zaakceptowano i ustalono komponenty na które będzie miała wpływ. Przekazano realizację do zespołu deweloperskiego i po pomyślnym przetestowaniu, Change Manager ustala termin wdrożenia na produkcję. Potwierdzono, że wdrożona poprawka działa zgodnie z celem co pozwala uznać problem za rozwiązany i go ostatecznie zamknąć.
autor: Artur Lachowicz, IT Delivery Manager posiadający doświadczenie w zarządzaniu usługami IT oraz w prowadzeniu projektów informatycznych
kontakt: https://www.linkedin.com/in/arturlachowicz/
