Otázka č. 23

Publikováno: 3. 1. 2012

Mám dvě otázky z oblasti Incident a Problem managementu.

Jde mi především o prakticky použitelné zkušenosti. Metriky, které moc nedávají smysl, nebo je nejde ve skutečnosti rozumně měřit, jsou všude po Internetu (a částečně i v ITILu). Obě otázky jdou k jádru procesu: chci měřit Voice of the customer (ala Six Sigma), tedy “Nechceme opakované incidenty” a “Chceme snížit počet incidentů”. Nechci metriky, které se sice snadno měří, ale jsou pro měření přínosu Problem managementu nedůležité – např. počet zalogovaných problémů, průměrná cena vyřešení problému.

  1. Jakou reálně použitelnou metriku lze použít na měření základního cíle procesu Problem management, tedy snížení počtu incidentů? Počet incidentů je obecně závislý na spoustě faktorů (kvalita monitoringu, množství služeb, množství uživatelů, živelné události apod..) a tak je obtížné tyto další faktory z metriky vyloučit a ukázat jen přínos Problem managementu. I při perfektně fungujícím Problem managementu se počet incidentů může, např. zavedením lepší detekce krátkých výpadků služeb, rapidně zvýšit. Nebo zavedením nové technologie místo staré poruchové se i bez přispění Problem managementu může počet incidentů snížit.
  2. Problem management mluví o opakovaných incidentech. Máte nějakou zkušenost, jak tyto opakované incidenty rozpoznávat, abychom mohli změřit procento opakovaných incidentů (uživatelé nesnáší opakované incidenty, je vhodné naplnění tohoto požadavku pokud možno měřit). Ruční procházení databáze s incidenty a rozhodování, co je a není opakovaný incident, není reálné, i když by bylo asi nejpřesnější.

ODPOVĚĎ

Odpověď Roberta Krajči

1. Jakou reálně použitelnou metriku lze použít na měření základního cíle procesu Problem management, tedy snížení počtu incidentů?

  1. Neexistuje jedna universální metrika, lze použít následující techniky:
  2. porovnávání počtu incidentů s naměřenou baseline – čili počtem, který v průměru bývá detekován v danou hodinu, den, měsíc a podobně
  3. zavést měření počtu incidentů pro konkrétní KP nebo kategorie KP, speciálně ty, které byly předmětem implementace změn iniciovaných vyřešením problému (či problémů). To má výhodu, že takto můžeme detekovat také opakující se incidenty po implementaci změny anebo nové incidenty způsobené implementací změny
  4. měření počtu incidentů, které vznikly od okamžiku vygenerování problému až do jeho vyřešení a které samozřejmě souvisí s tímto problémem
  5. a samozřejmě aplikovat korekce na počty incidentů, které zohlední uvedené výkyvy nahoru nebo dolů (nová aplikace – může zvýšit nebo snížit, nová technologie, podrobnější monitoring, změny v prahových hodnotách monitoringu)

2. Problem management mluví o opakovaných incidentech. Máte nějakou zkušenost, jak tyto opakované incidenty rozpoznávat, abychom mohli změřit procento opakovaných incidentů?

Kandidáti na opakované incidenty se vedle manuální analýzy mohou detekovat následovně:

  1. seskupení podle přiřazených konfiguračních položek, kódu uzavření a případně dalších atributů – to se týká všech incidentů, ovšem výsledek závisí na kvalitě a granularitě CMDB, struktuře číselníku kód uzavření apod. V případě, že máme jen generické KP, pak bude vypovídací hodnota minimální
  2. u incidentů detekovaných nástrojem (např. z procesu event mgmt, čili posílaných z monitoringu) seskupení pomocí korelačních pravidel monitorovacího nástroje, tady použijeme sofistikovanější logiku a využijeme víc atributů než jen přiřazenou KP. Korelační nástroj může u detekovaných událostí dodat jejich celkový počet před korelací
  3. pomocí technologií na Service Desku, kdy u vybraných incidentů automaticky podsuneme agentovi na Service Desku dotaz na volajícího (nebo přidáme povinné pole tomu, kdo zadává přes web, e-mail, …), zda jde o první nebo opakovaný výskyt

Kandidáty potom podrobit analýze a tím zpřesnit výsledky.

Odpověď Jiřího Skály

Je pravda, že základním cílem procesu problem management je snížení počtu opakovaných incidentů, a RK ve své odpovědi správně uvádí, jak tento přínos prakticky měřit. Chtěl bych jen dodat, že problem management má ještě další významný přínos, a tím je zkrácení doby řešení opakovaných incidentů a minimalizace dopadu na uživatele, čehož dosahuje tím, že se snaží: opakované incidenty identifikovat (způsobem, který uvádí RK) a svazovat je se záznamem problému, přičemž pokud ještě takový problém založen není, tak jej vytvořit.

K tomu dvě poznámky:

1) ITIL V2 v knize Service Support dokonce uváděl, že každý incident, u něhož není možné identifikovat konkrétní KP, jejíž selhání jej způsobilo, by měl být svázán se záznamem problému (nebo známé chyby, neboť ve V2 se ještě rozlišovalo mezi problémem a známou chybou).
2) je potřebné, aby pro incident management platila tato dvě pravidla:

a. řešitel incidentu, který využije postup uvedený ve znalostní DB, sváže incident s příslušným záznamem ve znalostní DB

b. pokud řešitel incidentu vyřeší incident díky opravě KP, jejíž selhání identifikoval, tak incident sváže s touto KP.

Díky těmto dvěma pravidlům se výrazně sníží počet incidentů, které bude muset problem management analyzovat, tzn. zůstanou pouze incidenty, které nemají identifikovanou příčinu (tj. KP, jež incident způsobila) a incidenty, jež nebylo možné vyřešit díky informacím ze znalostní DB.

  • problém dále řešit hledáním příčiny a nejlepší možné reakce na incidenty, touto příčinou vyvolanými, a popisy příčin incidentů a postupy řešení jimi vyvolaných incidentů současně zaznamenávat do znalostní databáze, a to takovým způsobem, aby tyto informace byly snadno vyhledatelné a pohotově použitelné pro operátory service desku a řešitele incident managementu
    Metriky pro měření tohoto přínosu jsou především dvě:
  • počet incidentů, které nemají přiřazenou KP, jež selhala, a současně nejsou svázané s žádným problémem ani záznamem ve znalostní DB (čím menší hodnota, tím vyšší efektivnost problem managementu).
  • průměrná délka celého životního cyklu opakovaných incidentů (jak identifikovat opakovaný incident viz odpověď RK).

Svazování opakovaných incidentů s existujícím problémy, resp. se záznamy ve znalostní DB, má další přínos v tom, že následně může change management hodnověrněji rozhodnout o tom, které problémy působí největší potíže, a tedy upřednostnit změny, resp. patche, které je řeší.

Vzhledem k tomu, že je v poslední době obrovský tlak na snižování IT nákladů, je tento druhý přínos problem managementu stejně důležitý, jako ten první, a možná že i důležitější. Jinými slovy: snižování počtu opakovaných incidentů může být (za určitých okolností) nákladnější a tedy méně efektivní, než vylepšování postupů reakce na opakované incidenty (prostřednictvím doplňování znalostní DB). Samozřejmě souhlasím s tvrzením tazatele, že uživatelé si primárně přejí snížení opakovaných incidentů. Nicméně efektivní problem management je schopen vytvořit takové postupy reakce na opakovaný incident, že jeho vznik nemusí uživatel vůbec pocítit.

Odpověď Vladimíra Kufnera

Snížení počtu incidentů je základní cíl, ale nikoliv jediný. V principu se může stát, že jde o problém vzniklý z jediného incidentu. Pak je to o vyřešení problémů a tím zvýšení stability/kvality (dostupnosti) služeb. Další věcí je třeba eliminace nepříznivého dopadu na business u těch problémů/incidentů, kde jim nejde zabránit pomocí lepších organizačních opatření – nezapomeňme např. na fakt, že Problem manager figuruje v eskalační matici pro IM.

K odpovědi na otázku 1. – asi bych odkázal na edici 2011, kde je teď k dispozici přehršel podle mého názoru velmi rozumných metrik jak pro IM, tak i PrM – SO/4.2.8 a 4.4, např.:

  • KPI Percentage of incidents closed by the service desk without reference to other levels of support (often referred to as ‘first point of contact’)
  • KPI Average incident resolution time for those incidents linked to problem records

K odpovědi na otázku č.2, první odrážka (seskupení podle KP, kódu uzavření a dalších atributů):

Přidal bych další atributy jako jsou základní symptomy v popisu problému, stejný čas, stejná lokalita, stejná služba, stejný uživatel/skupina uživatelů. Dospělé systémy pro ITSM umí indexovat záznamy o incidentech, problémech, KE atd. takže asi není problém klást strukturované dotazy.

Toto klade poměrně vysoké nároky na KOREKTNÍ a KOMPLETNÍ popisy incidentů/problémů. Tendence je zde zadávat informace typu “nefunguje služba XY”, ale proces IM/PrM ve skutečnosti vyžaduje zadávat celou řadu dalších údajů právě k zajištění možnosti takovéhle prohledávání uskutečňovat.

Obecně je zde nutné říci, že metriky vyžadují korektní spolupráci mezi oběma (třemi, včetně ChM) procesy v tom smyslu, že je zde nutné vytvářet vazby na záznamy – např. 1 PRB na několik INC nebo u INC definovat odkaz na KE. Bez tohoto opatření, které bude systémově dodržováno, si můžeme definovat metriky jaké chceme, ale v praxi je nelze uskutečnit, resp. budou ukazovat ptákoviny.

Štítky: , ,
Autor:: Kateřina Mrkvičková