Minimalizowanie negatywnego wpływu błędów infrastrukturalnych na biznes powinno być celem każdego dostawcy usług informatycznych. Proces zarządzania problemami opisuje i wskazuje metody, jak taki wpływ skutecznie eliminować lub redukować. Zarazem jest jednym z trudniejszych procesów fazy eksploatacji usług, głównie ze względu na szeroki kontekst, w jakim proces się porusza. Wykracza on bowiem poza standardowe ramy technologiczne i wymusza od organizacji samodoskonalenie i usprawnianie. Oczywiście przemyślany, dopasowany i zwinny proces zarządzania problemami może dostarczyć sporych korzyści.

Korzyści z procesu zarządzania problemami wynikają głównie ze zwiększonej dostępności usług IT, poprzez redukowanie liczby i czasu trwania incydentów. Zarządzanie problemami  ściśle współpracuje z innym procesem fazy eksploatacji usług – zarządzaniem incydentami, a także z procesem z fazy przekazania – zarządzaniem zmianą. Połączone wysiłki z tych trzech procesów mogą zapewnić zwiększoną dostępność oraz wyższy poziom jakości oferowanych usług.

Proces zarządzania problemami – reaktywny czy proaktywny

Zarządzanie problemami można rozpatrywać zarówno w aspekcie reaktywnym jak i proaktywnym. Reaktywna forma procesu zarządzania problemami będzie koncentrować się na rozwiązywaniu problemów, w odpowiedzi na jeden lub więcej incydentów. Czynności powiązane z przeglądem poważnych incydentów w kontekście możliwych sposobów eliminacji podobnych zdarzeń w przyszłości, również będzie wpisywać się w reaktywną naturę procesu. Podczas gdy aktywności z aspektu reaktywnego będą wykonywane w odpowiedzi na zaistniałe incydenty, tak proaktywny aspekt procesu zarządzania problemami będzie skoncentrowany na poprawie dostępności oraz polepszeniu jakości oferowanych usług.

Analiza trendów oraz logów i zdiagnozowanie potencjalnych problemów, które jeszcze się nie pojawiły będą wspierać proaktywną naturę procesu. Proaktywny proces zarządzania problemami jednocześnie poszerza kontekst procesu, gdyż stanowi o możliwościach uczenia się organizacji i zdolności po usprawniania oferowanych usług informatycznych. Przez to aspekt ten będzie silnie skorelowany z fazą ustawicznego doskonalenia usług, która to bezpośrednio odpowiada za identyfikację oraz implementację udoskonaleń.

Ustandaryzowane podejście do rozwiązywania problemów

Proces zarządzania problemami obejmuje aktywności potrzebne do zdiagnozowania przyczyny powstawiania incydentów oraz zdiagnozowania sposobu rozwiązania problemu.

Sposobów dochodzenia przyczyn jest kilka. Wybór jednego odpowiedniego lub zestawu kilku będzie zależeć od organizacji i świadomości osób, biorących udział w procesie. Poniżej kilka najczęściej stosowanych metod:

  1. Analiza zdarzeń w porządku chronologicznym– metoda ta polega na przedstawieniu zdarzeń na linii czasu, porządkując zdarzenia względem czasu ich powstawania. Dzięki temu osoby analizujące problem są w stanie dostrzec zależności pomiędzy zdarzeniami, określając, co wywołało problem.
  2. Burza mózgów– bardzo często przydatne jest zwołanie grupy osób, która na podstawie rzucania pomysłów jest w stanie dojść do przyczyny problemu. Wiedza oraz doświadczenie osób biorących udział w tej metodzie jest kluczem do szybkiego wyłapania istoty problemu.
  3. Medoda 5-why– metoda o wysokiej efektywności. Najpierw formułuje się problem a następnie poprzez zadawanie tego samego pytania: „dlaczego tak się stało?”, dochodzimy do źródła problemu. W piątej iteracji zazwyczaj odnajdujemy prawdziwą przyczynę  komplikacji.
  4. Kepner-Tregoe– ciesząca się coraz to większą popularnością metoda rozwiązywania problemów, opracowana przez Charlesa Kepnera i Benjamina Tregoe. Określa i opisuje ustandaryzowane podejście do analizy komplikacji.

Lista ta stanowi jedynie wycinek tych metod, które opisane są w publikacji Service Operations. Gorąco zachęcam do zapoznania się z opisem pozostałych. Oczywiście Internet jest pełen stron opisujących techniki analizy problemów. Jedna z nich zawiera opis 7 technik. Stanowi to dobrą lekturę początkową.

Problem a znany błąd

Proces zarządzania problemami odróżnia problem od znanego błędu. ITIL definiuje problem, jako przyczynę jednego lub wielu incydentów. Warto nadmienić, że używana definicja problemu nie do końca jest trafna. Użycie bowiem słowa incydent mogłoby wskazywać na to, że proces zarządzania problemami zawiera jedynie aspekt reaktywny, a jak wiemy – tak nie jest (patrz: pierwszy akapit).

Znany błąd (ang. Known-Error) zdefiniowany jest w ITILu, jako problem z udokumentowaną zarówno przyczyną (wskazanie na powody, dlaczego problem się pojawił) jak i obejściem problemu (ang. workaround). Jeżeli uda się znaleźć obejście problemu, jego rekord musi zostać zaktualizowany o te informacje, przy czym sam rekord pozostaje otwarty. Zamknięcie problemu może nastąpić jedynie po tym, jak w sposób kontrolowany (za pomocą procesu zarządzania zmianą, ang. Change Management) uda nam się całkowicie rozwiązać problem, poprzez np. zainstalowanie poprawki do systemu.

Wiele osób prowadzi dyskusję nt. momentu, w którym znany błąd powinien być zarejestrowany w narzędziu ITSM. Przywołując raz jeszcze definicję znanego błędu, możemy być przekonani, że jego zarejestrowanie może nastąpić tylko, jeżeli ustaliliśmy przyczynę problemu (ang. root cause) oraz wiemy, jak go obejść. Paragraf 4.4.5.7 publikacji Service Operations doprecyzowuje, że znany błąd powinien zostać zarejestrowany tak szybko, jak tylko będzie to uzasadnione, nawet przed tym, jak przyczyna lub obejście zostaną zdiagnozowane.