Publikováno: 12. 5. 2007
Remedy podporuje funkcionalitu kde je založen separátní záznam pro Problém investigation a pro vyřešení Known Error. Jaké má toto řešení výhody? Zdá se nám rozumnější mít jeden záznam, kde Problém je v určitém stavu řešení/investigace, kdy známe RootCause a Workaround, prohlášen za Known Error. Odpadá tak údržba 2 záznamů. Jaké jsou výhody odděleného záznamu Problem Investigation a Known Error?
ODPOVĚĎ
Ano, to je pravda a netýká se pouze Remedy. Dalším příkladem může být např. HP Service Center (Peregrine) či Marval, kde jsou rovněž oddělené entity. Naopak u HP Service Desku, Heatu či CA Unicenter Service Desku se jedná o jednu jedinou entitu.
Prakticky to nehraje podle mého názoru až tak moc důležitou úlohu, jedinou přidanou hodnotou odděleného řešení je možnost zakládání separátní KE aniž by k ní existoval problém. Modelově jde o situaci popsanou v ITIL V2 jako známé chyby pocházející z vývoje, v tomto případě se jedná o publikování známých chyb ještě předtím, než se stanou problémem v provozu.
Odvrácenou stranou tohoto uspořádání je zcela nepochybně vyšší režie procesu PrM, nutnost provazování vazeb mezi KE a PRB a nutnost nějakého definovaného vstupu z Release managementu či vývoje do databáze KE. Formálně nicméně podle ITILv2 je to tak SPRÁVNĚ. Píši úmyslně V2, neboť ve V3 je to už trochu jinak, jsou potlačeny subprocesy Problem Control a Error Control.
Osobně jsem k použití separátních entit spíše skeptický, podle mého názoru nejčastějším použitím KE je používání znalostních databází ať už zaintegrovaných v řešení ITSM jako je CA Unicenter SD či HP Service Center/SM7 a nebo separátních. Podle nějakých průzkumů pocházejících myslím z IDC (zdrojem si nejsem úplně jist) je nejčastější znalostní databází známých chyb vyhledávač Google.
Štítky: Vladimír Kufner
Autor:: Kateřina Mrkvičková