Article: AN0001810Updated: 11.04.2020
Tato vrstva obsahuje entity z oblasti Incident and Problem management definovaných v ITIL verze 3 (viz oficiální stránka ITIL, ITIL na Wikipedii). U každého incidentu se odvozuje jeho Priorita (Incident priority) z jeho Dopadu (Incident impact) a Urgentnosti (Incident urgency). Dopad definuje závažnost incidentu z pohledu narušení standardních procesů organizace. Urgentnost zohledňuje potřebu řešit incident okamžitě (u neřešeho incidentu menšího dopadu může jeho závažnost vzrůst) nebo naopak možnost řešení odložit (dopad incidentu v některých případech odeznívá např. kvůli zahájení alternativních postupů organizace). Priorita složená z kategorií dopadu a urgentnosti určuje cílový čas vyřešení stanovený pro daný typ incidentu a cílový čas odezvy (zahájení řešení incidentu). Z porovnání skutečných časů zahájení řešení a vyřešení konkrétního incidentu s těmito plánovanými hodnotami, pak lze vyvodit, zda byl incident vyřešen včas nebo ne.
Incident se uzavírá návratem do původního stavu, ale příčiny jeho vzniku mohou přetrvávat dále. Pokud identifikujeme skutečnou příčinu incidentů, zakládáme záznam v entitě Problém (Problém). Opakující se incidenty stejného typu pak odkazujeme na identifikovaný problém. To umožňuje rozlišit situace, které jsou vždy řešeny pouze ad hoc bez vyřešení pravých příčin.
Další entitou je Známá chyba (Known error). Jedná se např. o chyby uznané výrobce, jejichž vyřešení je přislíbeno v další verzi produktu. Pokud v rámci incidentu nebo problému zjistíme, že příčinou je známá chyba, odkážeme na ni. To umožní doložit např. nutnost upgradu zastaralé verze software na novou, která danou chybu již neobsahuje.
Ideální situací je odstranění příčin problémů a jejich skutečné vyřešení. V některých případech je však vhodné, byť dočasně, použít Workaround (Workaround), řešení, které umožní vyrovnat se s projevy problému.
Incidenty i problémy se týkají konkrétní Konfiguračních položek (Configuration items), které jsou jimi postiženy. Workaround naopak konfigurační položky používá pro dočasné "řešení" problému.
Na základě incidentu nebo problému organizace může založit Servisní požadavek (Service requests), pokud se incident nebo problém nedaří vyřešit interními zdroji a musí se tedy obrátit na servisního partnera.
Před implementací by model měl být upraven dle konkrétní situace a potřeb každého zákazníka.
Konfigurační databáze (CMDB) a proces Configuration management jsou představeny i na webu ObjectGears.