Problem manager to rola w ramach praktyki Problem Management (IT Service Management), odpowiedzialna za zarządzanie pełnym cyklem życia problemów. Jest właścicielem i koordynatorem procesu: od identyfikacji i rejestracji problemu, przez koordynację analizy przyczyn źródłowych, po wdrożenie trwałego rozwiązania i zamknięcie rekordu. Celem tej roli jest ograniczanie liczby i dotkliwości incydentów przez eliminowanie ich przyczyn, nie zaś doraźne przywracanie usług.

Jeśli ten sam błąd wraca co kilka tygodni, samo restartowanie usługi niczego nie zmienia. Ktoś musi ustalić, dlaczego incydent w ogóle powstaje, i doprowadzić sprawę do końca. Tę odpowiedzialność bierze na siebie problem manager. Szersze spojrzenie na zależności między praktykami ITSM znajdziesz w tekście Zarządzanie usługami IT. Nie, to nie jest kolejny framework.

Zakres obowiązków problem managera

Problem manager odpowiada za przebieg całej praktyki i pilnuje, żeby żaden problem nie zniknął z radaru między kolejnymi awariami. Do jego zadań należą:

• identyfikacja i rejestracja problemów na podstawie zgłoszeń, danych monitoringu oraz powtarzających się incydentów;
• kategoryzacja i priorytetyzacja rekordów według wpływu na usługi;
• koordynacja analizy przyczyn źródłowych z zespołami technicznymi;
• dokumentowanie known error wraz z obejściem w bazie wiedzy;
• inicjowanie zmiany (RFC) i zamykanie rekordu po potwierdzeniu naprawy.

Ta rola spina pracę wielu zespołów, dlatego problem manager stale współpracuje z Change Management oraz Service Deskiem. Pełny opis zakresu obowiązków przedstawia What is a Problem Manager? Roles and Responsibilities – Freshworks.

Problem manager a incident manager – różnica w horyzoncie działania

Obie role dotyczą tych samych awarii, ale patrzą na nie z innej perspektywy czasowej. Incident manager reaguje natychmiast, żeby przywrócić usługę, często obejściem. Problem manager pracuje w perspektywie średnio- i długoterminowej, usuwając źródła awarii i zasilając Continual Improvement.

W praktyce te role się uzupełniają. Obejście wypracowane podczas gaszenia pożaru staje się punktem wyjścia do trwałej poprawki, nad którą czuwa problem manager. Podział odpowiedzialności między rolami w procesie opisuje Problem Management Roles and Responsibilities – Atlassian.

Techniki analizy przyczyn stosowane przez problem managera

Żeby odróżnić rzeczywistą przyczynę od objawu, problem manager prowadzi ustrukturyzowaną Root Cause Analysis. Najczęściej sięga po trzy metody:

• 5 Why – kolejne pytania o powód, aż dotrzesz do źródła, a nie do skutku;
• diagram Ishikawy – uporządkowanie możliwych przyczyn w kategorie przyczynowo-skutkowe;
• analiza Pareto – wskazanie tych kilku problemów, które generują większość incydentów.

Wybór techniki zależy od charakteru awarii i dostępnych danych. Przy pojedynczym, powtarzalnym błędzie dobrze sprawdza się metoda 5 Why, przy rozproszonych usterkach pomaga diagram Ishikawy.

Metryki skuteczności problem managera

Pracę tej roli ocenia się po efektach, nie po liczbie prowadzonych rekordów. Główną metryką jest MTTRC (Mean Time to Root Cause), czyli średni czas od rejestracji problemu do potwierdzenia przyczyny źródłowej. Uzupełniają ją dwie kolejne miary:

• odsetek powtarzających się incydentów – spadek oznacza, że naprawy faktycznie działają;
• liczba problemów zamkniętych trwałą poprawką, a nie tylko obejściem.

Zestaw tych wskaźników pokazuje, czy zespół realnie zmniejsza wolumen awarii, czy jedynie dokumentuje kolejne obejścia. Definicję roli w świetle ITIL 4 porządkuje ITIL 4 Practitioner: Problem Management – PeopleCert.

Odmiana proaktywna – praca przed incydentem

Proaktywny problem manager nie czeka na zgłoszenie. Analizuje trendy i dane z monitoringu, żeby wykryć słabości infrastruktury, zanim doprowadzą do przestoju. Gdy w jednym obszarze rośnie wolumen drobnych usterek, uruchamia działania zapobiegawcze wcześniej, niż powstanie poważna awaria.

Takie podejście zmniejsza ilość nieplanowanej pracy operacyjnej i poprawia stabilność usług. Zamiast reagować na kolejne zgłoszenia, zespół usuwa źródła awarii generujące najwięcej pracy.

Czynniki sukcesu w pracy problem managera

Badania akademickie (Sajaniemi, Jyväskylä 2016) wskazują osiem krytycznych czynników sukcesu Problem Management. Dla samej roli znaczenie mają szczególnie:

• dedykowane zasoby przypisane do analizy problemów, nie doraźnie oddelegowane;
• zaangażowanie kierownictwa, które broni czasu na pracę nad przyczynami;
• integracja z Change Management, żeby rozwiązania trafiały na produkcję;
• istnienie bazy known error (KEDB) oraz wsparcie narzędziowe do śledzenia obejść;
• silne zaangażowanie właściciela procesu, czyli samego problem managera.

Bez tych warunków rola bywa spychana przez bieżące gaszenie pożarów. Kontekst organizacyjny procesu i jego ról opisuje Problem Manager – IT Process Wiki.

FAQ

Czym zajmuje się problem manager?

Problem manager jest właścicielem praktyki Problem Management i koordynuje cały cykl życia problemów: identyfikację, kategoryzację, priorytetyzację, analizę RCA, dokumentację known error, inicjowanie zmiany i zamknięcie rekordu. Pilnuje, żeby każde zidentyfikowane źródło awarii zostało usunięte trwałą poprawką.

Jak problem manager mierzy swoją skuteczność?

Główną metryką jest MTTRC, czyli średni czas od rejestracji problemu do potwierdzenia przyczyny źródłowej. Uzupełniają ją odsetek powtarzających się incydentów oraz liczba problemów zamkniętych trwałą poprawką. Spadek tych pierwszych dwóch wartości pokazuje, że naprawy faktycznie ograniczają awarie.

Czym problem manager różni się od incident managera?

Incident manager reaguje natychmiast, żeby przywrócić usługę, często obejściem. Problem manager działa w perspektywie średnio- i długoterminowej, usuwając przyczynę, żeby ten sam incydent nie wracał. Obie role współpracują, bo obejście z incydentu zasila trwałe rozwiązanie z problemu.