Change Management & Problem Management (ITILv3) Marek Rychlý Vysoké učení technické v Brně Fakulta informačních technologií Ústav informačních systémů Přednáška pro ISE 16. březen 2015 Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 1 / 46
Obsah 1 Cíle přednášky a opakování Cíle přednášky Change Management Problem Management 2 Change Management Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb 3 Problem Management Popis problému Řešení problémů Spolupráce služeb Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 2 / 46
Cíle přednášky Cíle přednášky a opakování Change Management Problem Management Cíle přednášky Change Management Problem Management Znát cíle, obsah a přínosy Change Managementu. Umět popsat význam změny, postup jejího plánování, realizace a vyhodnocení. Znát cíle, obsah a přínosy Problem Managementu. Porozumět významu incidentu, problému a postupu jeho řešení. Mít představu o spolupráci služeb v této oblasti. Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 4 / 46
Cíle přednášky a opakování Change Management Problem Management Change Management Cíle přednášky Change Management Problem Management hladká a nákladově efektivní implementace schválených změn (transparentnost, provázanost, ohodnocení a dopady změn, rizika, produktivita) minimalizaci vzniku incidentů v důsledku provedených změn připomínkování, schvalování změn, koordinace jejich implementace a její vyhodnocení..................................................................... v ESM patří do skupiny služeb Relationship Management (služba, se kterou příchází zákazník přímo do styku) v ITILv2 patří do skupiny procesů Service Support (procesy technické a uživatelské podpory u IT služeb) v ITILv3 patří do skupiny procesů Service Transition (procesy pro převod IT služeb z fáze návrhu do fáze používání) v COBITv4.1 proces AI6 Manage Changes (doména Acquire and Implement, tedy příprava a implementace služeb) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 5 / 46
Cíle přednášky a opakování Change Management Problem Management Problem Management Cíle přednášky Change Management Problem Management prevence opakování incidentů, poruch infrastruktury, chyb řízení (minimalizace jejich dopadu, účelné využívání zdrojů) vyšší stabilita IT infrastruktury (neustálého zlepšování kvality, méně incidentů, trvalá řešení) vyšší úspěšnost Service Desku v ukazateli first-time fix 1...................................................................... v ESM patří do skupiny služeb Relationship Management (služba, se kterou příchází zákazník přímo do styku) v ITILv2 patří do skupiny procesů Service Support (procesy technické a uživatelské podpory u IT služeb) v ITILv3 patří do skupiny procesů Service Operation (procesy řízení IT služeb během používání, optimalizace) v COBITv4.1 proces DS10 Manage Problems (doména Deliver and Support, tedy doručení/zavedení a podpora služeb) 1 FTF: Incidenty vyřešené ihned přímo pracovníky uživatelské podpory. Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 6 / 46
Cíle přednášky a opakování Change Management Problem Management Change Management Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb změna je cokoliv, co mění stav IT infrastruktury nebo služby (typicky požadovaná změna tzv. configuration item ) do procesu vstupuje požadavek na změnu (tzv. Request for Change, RFC) za účelem implementace nových požadavků, plánovaných vylepšení opravy chyb nebo přizpůsobení služeb změnám prostředí cílem procesu potom je minimalizovat riziko, které může změna provést (určit dopad změny na poskytované služby a na business zákazníka) provést změnu na první pokus, efektivně, bez následných incidentů proto proces zahrnuje evidenci změn a jejich ohodnocení, schválení, určení priority, naplánování, otestování, provedení a následnou dokumentaci a zhodnocení Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 8 / 46
Cíle přednášky a opakování Change Management Problem Management Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb Změna v kontextu zajištění IT služeb (ITILv2) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 9 / 46
Cíle přednášky a opakování Change Management Problem Management Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb Otázky v rámci Change Management Kdo nebo co požaduje změnu? Jaký je důvod pro změnu? Co přinese? Jaké bude mít změna důsledky? Budou trvalé? (a pokud výsledky nebudou odpovídat, půjde změna vrátit?) Jaké rizika přináší změna? Jak je budeme řešit? (jaká bude prevence rizik a krizové plány?) Jaké budou potřeba zdroje pro provedení změny? (profese, lidé, peníze, čas, služby, položky IT infrastruktury, atd.) Kdo bude zodpovědný za přípravu, testy a realizaci změny? Jaký je vztah dané změny vůči ostatním změnám? (a to minulým, současně řešeným, případně i očekávaným) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 10 / 46
Cíle přednášky a opakování Change Management Problem Management Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb Popis Request for Change (RFC) jedinečný identifikátor změny (Change ID) zdroj změny (Initiator) datum přijetí požadavku krátký popis zadavatele změny (kdo ji potřebuje) popis důvodu ke změně (Business Case) dopad změny na klienta, IT služby, IT komponenty (konfigurační položky) a použité/požadované technologie rizika plynoucí z implementace změny, jejich typy a příslušná protiopatření k jejich prevenci/minimalizaci předpokládaný a navržený časový rozpis implementace změny zdroje potřebné pro implementaci změny (požadovaný druh, počet a zapojení pracovníků, zapojení klienta, školení pracovníků i klienta, finanční nákladnost, zdroje financí) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 11 / 46
Cíle přednášky a opakování Change Management Problem Management Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb Průběh zpracování požadavu na změnu (dle ITILv3) Create RFC Change proposal (optional) Authorize change proposal Evaluation report Initiator Record the RFC Requested Review the RFC Change Management Ready for evaluation Change Authority Assess and evaluate change Work orders Ready for decision Plan updates Change Management Scheduled Change Mgmt. Authorize change Authorized Co-ordinate change implementation* Implemented Review and close change record Closed Work orders Update change and configuration in CMS Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 12 / 46
Cíle přednášky a opakování Change Management Problem Management Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb Záznam a prvotní revize požadavku na změnu popis požadavku zadavatelem by měl odpovídat významu změny (vážné změny mohou vyžadovat hlubší zdůvodnění a finanční plán) požadavky by neměly být věřejně viditelné (obsahují citlivé informace, měly by být posuzovány pouze odborně) nevhodné požadavky je možno zamítnout již při prvotní revizi (např. již řešené požadavky, nekompletní zadání, nepraktické, atp.) požadavky by měly být ohodnoceny a zpracovávány dle priorit Normal Changes (běžné změny, mohou podstoupit standardní proces a očkat minimálně jeden týden, kdy jsou prověřeny na pravidelné týdenní schůzce) Exception Changes (důležitější, schvalovat velmi rychle, nelze zajistit plnou analýzu rizik) Emergency Changes (důležité pro podporu business aktivit zákazníka, neschvalovat normální postupem, zajišt ují např. okamžité řešení incidentu) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 13 / 46
Cíle přednášky a opakování Change Management Problem Management Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb Analýza změny a proces jejího schválení každá změna přináší rizika, nutné provést analýzu rizik (a zaznamenat např. do matice: dopady pravděpodobnosti) dopady a rizika by měla být posuzována z obchodního pohledu (ohodnocení dopad, nutnosti, rizika, užitku a ceny, pro každou stranu) dopad změny dán jejím přínosem při úspěšném provedení nebo rozsahem rizik odvrácených v důsledku změny (např. pokud reaguje na incident, opravuje nějaký problém) nutnost změny je dána dobou, dokdy je nutné změnu provést dopad změny a nutnost změny také ovlivňují její prioritu (navržena zadavatelem změny a potvrzena/přenastavena běhěm analýzy) na základě analýzy se provede schválení změny u změn běžného dopadu v rámci Change Advisory Board (CAB) (případně Emergency CAB u Exception/Emergency Changes) u změn s dopadem na více služeb na schůzi jejich zástupců u změn s velkým dopadem/rizikem na zasedání vedoucích Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 14 / 46
Cíle přednášky a opakování Change Management Problem Management Klasifikace změn podle cíle Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb Hardware: instalace a odinstalace, přemístění, modifikace komponent, změna firmware. Software: modifikace operačního systému, konfigurace a oprávnění. Aplikační: modifikace uživatelských aplikací, aktualizace. Sít ové: instalace a modifikace sít ových komponent, vč. firewallu. Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 15 / 46
Cíle přednášky a opakování Change Management Problem Management Klasifikace změn podle vlivu Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb Prostředí: změny, které mají vliv na IT prostředí. (např. stavební úpravy, chladící systémy, zajištění el. energie, kabeláž, úprava fyzického přístupu) Infrastruktura: změny ovlivňující komponenty IT infrastruktury. Operace: změny mající vliv na dostupnost a aktivitu služby. (např. pojmenování, standardy, procedury přihlášení, změny operačních procedur (disaster recovery plan), automatických postupů, činnost údržby) Informace: změny ovlivňující dostupnost daných služeb v daných časech, nebo změny prováděné třetími stranami. (De)Aktivace: změny vedoucí k aktivaci nebo deaktivaci služby. Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 16 / 46
Cíle přednášky a opakování Change Management Problem Management Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb Příklad nástroje pro evidenci změn CA Service Desk Manager Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 17 / 46
Cíle přednášky a opakování Change Management Problem Management Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb Porady Change Advisory Board (CAB) většinou se setkává jednou týdně a obsahuje předsedu, obvykle je to Change Manager zástupce zákazníka, vedoucí uživatelů, zástupce skupin uživatelů, vývojáře, konzultanty specialisty, zástupce techniků zaměstnance konkrétních služeb a operačního řízení ostatní účestníky dle SLA, zástupce dodavatlů, atd. nejlépe osobní setkání, případně v kombinaci s telemosty přesně daný program jednání (neoprávněné nebo chybně provedené změny, návrhy na změny a jejich přiřazení jednotlivým členům, revize a plánování změn, zprávy o provedených změnách a jejich zhodnocení, návrhy na schválení změn, atd.) na setkání se neschvalují změny, pouze doporučují (schvaluje až výkonné vedení podle jejich dopadu, např. Change Manager) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 18 / 46
Cíle přednášky a opakování Change Management Problem Management Plánování a provádění změn Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb schválené požadavky předány příslušných technickým skupinám (ty rozpracují plány jejich provedení) běžné změny jsou provedeny podle standardních postupů, ostatní nutno plánovat důkladněji (vč. plánů záchranných řešení a záložnách komunikačních kanálů) změny jsou seskupovány v rámci tzv. releases (společně plánovány, testovány a prováděny, minimalizace ostatních závoslostí) na skupiny změn dohlíží pro ně pověření Change Coordinators (kontrolují plány změn, výsledky jejich testů, přípravy ke krytí rizik, atd.) změny provedeny v tzv. change windows, minimální rizika (mimo pracovní dobu, např. v pozdní noci na neděli v daném časovém pásmu) aktivity jsou koordinovány se všemi účastníky (porozumění se zákazníkem, dodavateli, realizace změny nesmí překvapit) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 19 / 46
Cíle přednášky a opakování Change Management Problem Management Vyhodnocení a uzavření změn Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb po provedení změny zpracování její zhodnocení formou zprávy (průběh její realizace a skutečný dopad) skutečný vs. očekávaný vliv změny názor zůčastněných stran na výsledky a identifikace nedostatků vedlejší efekty změn, neočekávané situace as jejich řešení skutečné vs. očekávané využití zdrojů, čas a cena změny průběh realizace změny, případně řešení krizových situací (průběh návratu k předešlému stavu, pokud se aplikace změny nezdařila) analýza zpráv o změnách, sledování trendů a dodržování SLA (porušení SLA není obvyklé, díky dobrému plánování změn, ale může nastat) návrh na změnu je uzavřen Change Managerem a získané zkušennosti zaneseny do Knowledge Database (závěrečný kontrola/uzavření se provádí v pravidelných intervalech) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 20 / 46
Cíle přednášky a opakování Change Management Problem Management Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb Infrastructure Service Interconnections (ESM) Configuration Management (všechny měněné IT prvky jsou v databázi konfigurace) Software Distribution (všechny distribuce jsou požadavkem na změnu) Call Management, Operations Management (komunikace s uživateli ohledně změn a reakce na komunikaci) Business Process Management (změny mohou mít vliv na business aktivitu nebo být iniciovány její změnou) Resource Management (změny vyžadují zdroje) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 21 / 46
Cíle přednášky a opakování Change Management Problem Management Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb Relationship Service Interconnections (ESM) Reporting Management (denní, týdenní a měsíční zprávy pro poskytovatele služeb a zákazníka) Request Management (většina změn je plánována na základě požadavků) Knowledge Management (zprávy o změnách tvoří znalostní bázi organizace) Asset Management (vyhodnocení dopadu změn) Notification Management (během změn dochází k upozorněním zúčastněných subjektů) Problem Management (změna může vyvolat problém a být pozastavena do jeho vyřešení) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 22 / 46
Cíle přednášky a opakování Change Management Problem Management Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb Proces AI6 Manage Changes v COBIT 4.1 zde má být příloha přejít na přílohu Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 23 / 46
Cíle přednášky a opakování Change Management Problem Management Změna (Change) a její podpora Analýza a proces schválení změn Spolupráce služeb IBM Global Systems Management Reporting Technology (GSMRT) Change Package Overview zde má být příloha přejít na přílohu Další příklady nástrojů: HP s Peregrine Service Center IBM Tivoli Change and Configuration Management Database Mercury Change Control Management (formerly Kintana) BMC Remedy Change Management Application BMC s Topology Discovery Sunview s ChangeGear Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 24 / 46
Cíle přednášky a opakování Change Management Problem Management Problem Management Popis problému Řešení problémů Spolupráce služeb problém je (neznámá) příčina jednoho nebo více incidentů do procesu vstupuje popis problému (tzv. Problem Ticket ) cílem procesu potom je vyřešit problém, zabránit jeho budoucímu opakování (na základě popisu problému identifikovat chybu a nalézt řešení) zabránit budoucím incidentům známých problémů, případně minimalizovat jejich dopad (některým incidentům nelze zabránit, přestože známe problém = příčinu) proto proces zahrnuje detekci problémů, jejich evidenci, ohodnocení, vyšetření, nalezení dočasných i trvalých řešení, vyhodnocení a budoucí prevenci vzniku z procesu vystupují popisy známých chyb (Known Errors) (pro budoucí okamžitou identifikaci známých problémů a jejich možných řešení) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 26 / 46
Cíle přednášky a opakování Change Management Problem Management Popis problému Řešení problémů Spolupráce služeb Popis problému (Problem Ticket) I. Problem Description (stručný a dostatečný slovní popis problému) Severity (kritičnost problému výběrem z několika možností, nejdůležitější údaj, na základě Service Level Agreement (SLA) ovlivňuje požadovaný čas řešení) Time Opened (datum a čas, kdy byl problém nahlášen; je klíč) Group Assigned (skupina Subject Matter Experts (SME), která má problém řešit; je klíč) Contact Information (kontakty na zúčastněné strany, vč. posloupností kontaktů, jak postupovat, pokud předchozí neodpoví do určité doby) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 27 / 46
Cíle přednášky a opakování Change Management Problem Management Popis problému Řešení problémů Spolupráce služeb Popis problému (Problem Ticket) II. System, Component, Item, Module (SCIM) (konfigurace poskytnutá z Configuration Management, které se problém týká, např. konkrétní server/servery, OS, umístění systému a příslušné SME; pomáhá směrovat problém na příslušné osoby) Time Closed (datum a čas, kdy byl problém uzavřen, pak již nelze editovat 2 ) Change Integration (změny, ke kterým došlo v důsledku řešení a vyřešení problému) Duration for resolution (= Time Closed Time Opened) Resolution (způsob vyřešení problému vložen v čase jeho uzavření) 2 místo změn se vytváří další popis problému, např. poznámky řešitele, nebo znovu-otevřený problém Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 28 / 46
Cíle přednášky a opakování Change Management Problem Management Porady o problémech Popis problému Řešení problémů Spolupráce služeb Incident/Problem 3 review meetings (prevence problémů, definice operačních postupů pro budoucí rychlé řešení, zkoumání vzájemného propojení více problémů a synchronizace na nich pracujících skupin SME) denní setkání, kde se řeší problémy z předchozího dne, připravují aktualizace jejich popisů a kontrolují uzavřené problémy, Root cause analysis (RCA) review meetings (jsou podmětem pro personální a technologické změny, nákup a upgrade prvků IT infrastruktury) týdenní setkání, kde SME vysvětlují podstatu a řešení již uzavřených problémů 3 incident je okamžik vzniku problému Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 29 / 46
Cíle přednášky a opakování Change Management Problem Management Komunikace o problémech Popis problému Řešení problémů Spolupráce služeb Je potřeba: připravit zprávy o incidentech, analýze problémů a stanovení trendů, (identifikují se podobné problémy a doporučí budoucí prevence výskytů incidentů a rychlé řešení problémů) spravovat aktuální seznam prvků IT infrastruktury, identifikovat a nahlásit problémy, které mají vliv na činnost zákazníka, (problémům se přiřadí business criticality ) identifikovat eskalující a duplicitní problémy a určit budoucí rozpoznání a prevenci, přehodnotit a ověřit Severity levels v popisech problémů, identifikovat trendy, výstižnost informací a míru úplnosti popisu problémů, identifikovat zodpovědnosti poskytovatelů služeb a zákazníků. Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 30 / 46
Cíle přednášky a opakování Change Management Problem Management Životní cyklus problému Popis problému Řešení problémů Spolupráce služeb Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 31 / 46
Cíle přednášky a opakování Change Management Problem Management Řešení a uzavření problémů Popis problému Řešení problémů Spolupráce služeb řešení problémů koordinováno Problem Managerem (jednotlivé problémy jsou řešeny skupinami specialistů, dodavatelů, atd.) pro dočasné, ale okamžité řešení problémů, tzv. Workarounds (dočasně zabrání hromadění stejných problémů, přestože není jejich příčina dosud plně pochopena; bud se stane trvalým řešením, nebo jím bude nahrazeno) jakmile je známé řešení (i dočasné) tak musí být zaznamenáno do Known Error Record (záznam se provede do tzv. Known Error Database, části Knowledge Database) záznam obsahuje detailní popis chyby, její příznaky, společně s přesným popisem dočasného nebo trvalého řešení výhodné je zaznamenávat i řešené problémy s evidencí postupu (zabrání duplicitnímu řešení, eviduje dokumentaci, incidenty, změny, atd.) Known Error Records spravuje a uzavírá Problem Manager (zároveň sestavuje pravidelně Major Problem Reviews) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 32 / 46
Cíle přednášky a opakování Change Management Problem Management Popis problému Řešení problémů Spolupráce služeb Infrastructure Service Interconnections (ESM) Configuration Management (pro kategorizaci problému podle SCIM) Event Management (popisy problémů mohou být manuálně nebo automaticky vytvořeny a přiřazeny na základě událostí) Availability Management (porušení dostupnosti bývá zpravidla velmi vážný problém) Performance and Capacity Management (obtížně přiřaditelné problémy, zpravidla řešeny dlouho a několika skupinami) Operations Management (operátoři mohou zajistit stav prostředí při incidentu a provést první kroky řešení) Security Management, Network Management (narušení bezpečnosti/sítě může být způsobeno problémem a zároveň samo je vážný problém) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 33 / 46
Cíle přednášky a opakování Change Management Problem Management Popis problému Řešení problémů Spolupráce služeb Relationship Service Interconnections (ESM) Reporting Management (denní, týdenní a měsíční zprávy pro poskytovatele služeb a zákazníka) Change Management (řešení problémů vyžaduje změny) Knowledge Management (incidenty a problémy jsou zaznamenávány pro prevenci a výuku) Notification Management (během řešení problému je třeba hierarchicky upozorňovat různé subjekty) SLA Management (řešení problému musí splňovat a podporovat SLA) Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 34 / 46
Cíle přednášky a opakování Change Management Problem Management Popis problému Řešení problémů Spolupráce služeb Proces DS10 Manage Problems v COBIT 4.1 zde má být příloha přejít na přílohu Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 35 / 46
Cíle přednášky a opakování Change Management Problem Management Popis problému Řešení problémů Spolupráce služeb IBM Global Systems Management Reporting Technology (GSMRT) Standard Incident / Problem Package Overview zde má být příloha přejít na přílohu Další příklady nástrojů: BMC s Remedy HP s Peregrine Managed Objects IBM s Enterprise Systems Manager IBM MRO s Maximo (TSD) PeopleSoft s Vantive Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 36 / 46
Shrnutí a závěr Shrnutí a závěr Poděkování a otázky Přílohy Problem Management reaguje na incident řešením problému. Cílem je prevence incidentům a rychlé a účinné řešení budoucích problémů. Change Management plánuje a implementuje změny. Cílem je bezpečné provedení změny bez incidentů a její vyhodnocení. Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 37 / 46
Shrnutí a závěr Poděkování a otázky Přílohy Děkuji za pozornost. Otázky? Diskuze? Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 38 / 46
Shrnutí a závěr Poděkování a otázky Přílohy COBIT 4.1: Process AI6 Manage Changes ZAČÁTEK PŘÍLOHY zpět do prezentace přeskočit přílohu Proces v doméně Acquire and Implement. Důležitý proces. Velice podobný (a kompatibilní) s ITIL procesem Change Management. Převzato z IT Governance Institute: COBIT 4.1. ISACA, 2007, ISBN 1-933284-72-2. Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 39 / 46
PROCESS DESCRIPTION Acquire and Implement Manage Changes AI6 AI6 Manage Changes All changes, including emergency maintenance and patches, relating to infrastructure and applications within the production environment are formally managed in a controlled manner. Changes (including those to procedures, processes, system and service parameters) are logged, assessed and authorised prior to implementation and reviewed against planned outcomes following implementation. This assures mitigation of the risks of negatively impacting the stability or integrity of the production environment. P P P P Effectiveness Efficiency Confidentiality Integrity S Availability Compliance Reliability Control over the IT process of Manage changes that satisfies the business requirement for IT of responding to business requirements in alignment with the business strategy, whilst reducing solution and service delivery defects and rework by focusing on controlling impact assessment, authorisation and implementation of all changes to the IT infrastructure, applications and technical solutions; minimising errors due to incomplete request specifications; and halting implementation of unauthorised changes is achieved by Defining and communicating change procedures, including emergency changes Assessing, prioritising and authorising changes Tracking status and reporting on changes and is measured by Number of disruptions or data errors caused by inaccurate specifications or incomplete impact assessment Amount of application or infrastructure rework caused by inadequate change specifications Percent of changes that follow formal change control processes STRATEGIC ALIGNMENT VALUE DELIVERY PERFORMANCE MEASUREMENT IT GOVERNANCE RESOURCE MANAGEMENT RISK MANAGEMENT Applications Information People Infrastructure Primary Secondary 2007 IT Governance Institute. All rights reserved. www.itgi.org 93
Acquire and Implement AI6 Manage Changes AI6 Manage Changes CONTROL OBJECTIVES AI6.1 Change Standards and Procedures Set up formal change management procedures to handle in a standardised manner all requests (including maintenance and patches) for changes to applications, procedures, processes, system and service parameters, and the underlying platforms. AI6.2 Impact Assessment, Prioritisation and Authorisation Assess all requests for change in a structured way to determine the impact on the operational system and its functionality. Ensure that changes are categorised, prioritised and authorised. AI6.3 Emergency Changes Establish a process for defining, raising, testing, documenting, assessing and authorising emergency changes that do not follow the established change process. AI6.4 Change Status Tracking and Reporting Establish a tracking and reporting system to document rejected changes, communicate the status of approved and in-process changes, and complete changes. Make certain that approved changes are implemented as planned. AI6.5 Change Closure and Documentation Whenever changes are implemented, update the associated system and user documentation and procedures accordingly. 94 2007 IT Governance Institute. All rights reserved. www.itgi.org
MANAGEMENT GUIDELINES Acquire and Implement Manage Changes AI6 AI6 Manage Changes From Inputs Outputs To PO1 IT project portfolio Change process description AI1 AI3 PO8 Quality improvement actions Change status reports ME1 PO9 IT-related risk remedial action plans Change authorisation AI7 DS8 DS10 PO10 Project management guidelines and detailed project plan DS3 Required changes DS5 Required security changes DS8 Service requests/requests for change DS9-10 Requests for change (where and how to apply the fix) DS10 Problem records RACI Chart Functions Activities CEO CFO CIO Business Executive Business Process Owner Head Operations Chief Architect Head Development PMO Head IT Administration Develop and implement a process to consistently record, assess and prioritise change requests. A I R C R C C C Assess impact and prioritise changes based on business needs. I R A/R C R C R C Assure that any emergency and critical change follows the approved process. I I A/R I R C Authorise changes. I C A/R R Manage and disseminate relevant information regarding changes. A I R C R I R C A RACI chart identifies who is Responsible, Accountable, Consulted and/or Informed. Compliance, Audit, Risk and Security Goals Goals and Metrics IT Respond to business requirements in alignment with the business strategy. Reduce solution and service delivery defects and rework. Ensure minimum business impact in the event of an IT service disruption or change. Define how business functional and control requirements are translated into effective and efficient automated solutions. Maintain the integrity of information and processing infrastructure. set Process Make authorised changes to the IT infrastructure and applications. Assess the impact of changes to the IT infrastructure, applications and technical solutions. Track and report change status to key stakeholders. Minimise errors due to incomplete request specifications. set Activities Defining and communicating change procedures, including emergency changes and patches Assessing, prioritising and authorising changes Scheduling changes Tracking status and reporting on changes drive measure measure measure drive Metrics Number of disruptions or data errors caused by inaccurate specifications or incomplete impact assessment Amount of application rework caused by inadequate change specifications Reduced time and effort required to make changes Percent of total changes that are emergency fixes Percent of unsuccessful changes to the infrastructure due to inadequate change specifications Number of changes not formally tracked, reported or authorised Number of backlogged change requests Percent of changes recorded and tracked with automated tools Percent of changes that follow formal change control processes Ratio of accepted to refused change requests Number of different versions of each business application or infrastructure being maintained Number and type of emergency changes to the infrastructure components Number and type of patches to the infrastructure components 2007 IT Governance Institute. All rights reserved. www.itgi.org 95
Acquire and Implement AI6 Manage Changes AI6 Manage Changes MATURITY MODEL Management of the process of Manage changes that satisfies the business requirement for IT of responding to business requirements in alignment with the business strategy, whilst reducing solution and service delivery defects and rework is: 0 Non-existent when There is no defined change management process, and changes can be made with virtually no control. There is no awareness that change can be disruptive for IT and business operations, and no awareness of the benefits of good change management. 1 Initial/Ad Hoc when It is recognised that changes should be managed and controlled. Practices vary, and it is likely that unauthorised changes take place. There is poor or non-existent documentation of change, and configuration documentation is incomplete and unreliable. Errors are likely to occur together with interruptions to the production environment caused by poor change management. 2 Repeatable but Intuitive when There is an informal change management process in place and most changes follow this approach; however, it is unstructured, rudimentary and prone to error. Configuration documentation accuracy is inconsistent, and only limited planning and impact assessment take place prior to a change. 3 Defined when There is a defined formal change management process in place, including categorisation, prioritisation, emergency procedures, change authorisation and release management, and compliance is emerging. Workarounds take place, and processes are often bypassed. Errors may occur and unauthorised changes occasionally occur. The analysis of the impact of IT changes on business operations is becoming formalised, to support planned rollouts of new applications and technologies. 4 Managed and Measurable when The change management process is well developed and consistently followed for all changes, and management is confident that there are minimal exceptions. The process is efficient and effective, but relies on considerable manual procedures and controls to ensure that quality is achieved. All changes are subject to thorough planning and impact assessment to minimise the likelihood of post-production problems. An approval process for changes is in place. Change management documentation is current and correct, with changes formally tracked. Configuration documentation is generally accurate. IT change management planning and implementation are becoming more integrated with changes in the business processes, to ensure that training, organisational changes and business continuity issues are addressed. There is increased co-ordination between IT change management and business process redesign. There is a consistent process for monitoring the quality and performance of the change management process. 5 Optimised when The change management process is regularly reviewed and updated to stay in line with good practices. The review process reflects the outcome of monitoring. Configuration information is computer-based and provides version control. Tracking of changes is sophisticated and includes tools to detect unauthorised and unlicensed software. IT change management is integrated with business change management to ensure that IT is an enabler in increasing productivity and creating new business opportunities for the organisation. 96 2007 IT Governance Institute. All rights reserved. www.itgi.org
Shrnutí a závěr Poděkování a otázky Přílohy COBIT 4.1: Process AI6 Manage Changes KONEC PŘÍLOHY zpět na začátek přílohy Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 40 / 46
Shrnutí a závěr Poděkování a otázky Přílohy IBM Global Systems Management Reporting Technology (GSMRT) Change Package Overview ZAČÁTEK PŘÍLOHY zpět do prezentace přeskočit přílohu Changes by Completion Code Change Schedule Meeting Change Success Technical Change Meeting Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 41 / 46
Global Systems Management Reporting Technology Global Systems Management Reporting Technology (GSMRT) Change Package Overview Prepared by: Maureen McDonough GSMRT Change Package Overview 6.3.2008 2005 IBM Corporation
Global Systems Management Reporting Technology Terms of use, copyright and trademark information By using these materials you agree to the IBM Terms of Use: http://www.ibm.com/legal/us/. The IBM copyright and trademark information webpage is incorporated herein by reference: http://www.ibm.com/legal/copytrade.shtml. 2 GSMRT Change Package Overview 6.3.2008 2003 IBM Corporation
Global Systems Management Reporting Technology Changes by Completion Code Name Changes by Completion Code Report Layer(s) N/A since this is a parameterized report with drop down menus Grouping(s) Selected Completion Code; Selected Period Report Description This is a change management measurement summary report which contains the number of changes reported by completion code. Business Use To view the number of changes for each completion code in order to assess actions required for each ticket. / Need Notes 11 The graphical display will depend on the number of categories and the number of months for which the report is run. For small numbers, the graph will be a three dimensional bar chart; for large numbers and date ranges, the display will be in tabular format. GSMRT Change Package Overview 6.3.2008 2003 IBM Corporation
Global Systems Management Reporting Technology Changes by Completion Code 12 GSMRT Change Package Overview 6.3.2008 2003 IBM Corporation
Global Systems Management Reporting Technology Changes by Completion Code Code Selection 13 GSMRT Change Package Overview 6.3.2008 2003 IBM Corporation
Global Systems Management Reporting Technology Change Schedule Meeting Name Change Schedule Meeting Report Layer(s) Summary, Visual Summary, Detail Grouping(s) Summary and Detail sections scheduled start date, system and component; Visual scheduled start date Report Description This report contains summary and detail data for all open approved changes by scheduled start date, system and component for the current week. Colors indicate risk level of change. Red=Critical, Yellow=Major, Green=Medium, Blue=Minor, Grey=BAU. Business Use This report is intended for use by the change coordinators to view, manage and assess priority of scheduled changes for / Need upcoming and future weeks. 15 GSMRT Change Package Overview 6.3.2008 2003 IBM Corporation
Global Systems Management Reporting Technology Change Schedule Meeting Visual Overview 17 GSMRT Change Package Overview 6.3.2008 2003 IBM Corporation
Global Systems Management Reporting Technology Change Schedule Meeting Detail 18 GSMRT Change Package Overview 6.3.2008 2003 IBM Corporation
Global Systems Management Reporting Technology Changes Success 19 Name Change Success Report Layer(s) Trend, Summary, Detail Grouping(s) Trend and Summary section location; Detail location and assignee group Report Description This report displays a summary of successful closed change records. Summary is displayed in a bar chart and a tabular format followed by failed record details grouped by account major and workgroup. Business Use / Need This report is intended for use as a trending report to view and analyze the successful versus unsuccessful closed changes in order to increase the number of successful changes. GSMRT Change Package Overview 6.3.2008 2003 IBM Corporation
Global Systems Management Reporting Technology Change Success Trend Report 20 GSMRT Change Package Overview 6.3.2008 2003 IBM Corporation
Global Systems Management Reporting Technology Change Success Summary Report 21 GSMRT Change Package Overview 6.3.2008 2003 IBM Corporation
Global Systems Management Reporting Technology Change Success Detail Report 22 GSMRT Change Package Overview 6.3.2008 2003 IBM Corporation
Global Systems Management Reporting Technology Technical Change Meeting 33 Name Technical Change Meeting Report Layer(s) Summary, Detail Grouping(s) Summary and Detail location, previous period / current week / future changes, scheduled start date Report Description This report contains summary and detail data for all open change tickets that are not past due. The summary and detail data is grouped by account major, previous period/current week/future changes and scheduled start date. Business Use / Need This report is intended for use by the change coordinators to view and manage the technical details of the scheduled changes for upcoming and future weeks. GSMRT Change Package Overview 6.3.2008 2003 IBM Corporation
Global Systems Management Reporting Technology Technical Change Meeting 34 GSMRT Change Package Overview 6.3.2008 2003 IBM Corporation
Global Systems Management Reporting Technology Technical Change Meeting Detail 35 GSMRT Change Package Overview 6.3.2008 2003 IBM Corporation
Shrnutí a závěr Poděkování a otázky Přílohy IBM Global Systems Management Reporting Technology (GSMRT) Change Package Overview KONEC PŘÍLOHY zpět na začátek přílohy Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 42 / 46
Shrnutí a závěr Poděkování a otázky Přílohy COBIT 4.1: Process DS10 Manage Problems ZAČÁTEK PŘÍLOHY zpět do prezentace přeskočit přílohu Proces v doméně Deliver and Support. Důležitý proces. Velice podobný (a kompatibilní) s ITIL procesem Problem Management. Převzato z IT Governance Institute: COBIT 4.1. ISACA, 2007, ISBN 1-933284-72-2. Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 43 / 46
PROCESS DESCRIPTION Deliver and Support Manage Problems DS10 DS10 Manage Problems Effective problem management requires the identification and classification of problems, root cause analysis and resolution of problems. The problem management process also includes the formulation of recommendations for improvement, maintenance of problem records and review of the status of corrective actions. An effective problem management process maximises system availability, improves service levels, reduces costs, and improves customer convenience and satisfaction. P P Effectiveness Efficiency Confidentiality Integrity S Availability Compliance Reliability Control over the IT process of Manage problems that satisfies the business requirement for IT of ensuring end users satisfaction with service offerings and service levels, and reducing solution and service delivery defects and rework by focusing on recording, tracking and resolving operational problems; investigating the root cause of all significant problems; and defining solutions for identified operations problems is achieved by Performing root cause analysis of reported problems Analysing trends Taking ownership of problems and progressing problem resolution and is measured by Number of recurring problems with an impact on the business Percent of problems resolved within the required time period Frequency of reports or updates to an ongoing problem, based on the problem severity STRATEGIC ALIGNMENT VALUE DELIVERY PERFORMANCE MEASUREMENT IT GOVERNANCE RESOURCE MANAGEMENT RISK MANAGEMENT Applications Information People Infrastructure Primary Secondary 2007 IT Governance Institute. All rights reserved. www.itgi.org 137
DS10 Deliver and Support Manage Problems CONTROL OBJECTIVES DS10 Manage Problems DS10.1 Identification and Classification of Problems Implement processes to report and classify problems that have been identified as part of incident management. The steps involved in problem classification are similar to the steps in classifying incidents; they are to determine category, impact, urgency and priority. Categorise problems as appropriate into related groups or domains (e.g., hardware, software, support software). These groups may match the organisational responsibilities of the user and customer base, and should be the basis for allocating problems to support staff. DS10.2 Problem Tracking and Resolution Ensure that the problem management system provides for adequate audit trail facilities that allow tracking, analysing and determining the root cause of all reported problems considering: All associated configuration items Outstanding problems and incidents Known and suspected errors Tracking of problem trends Identify and initiate sustainable solutions addressing the root cause, raising change requests via the established change management process. Throughout the resolution process, problem management should obtain regular reports from change management on progress in resolving problems and errors. Problem management should monitor the continuing impact of problems and known errors on user services. In the event that this impact becomes severe, problem management should escalate the problem, perhaps referring it to an appropriate board to increase the priority of the (RFC or to implement an urgent change as appropriate. Monitor the progress of problem resolution against SLAs. DS10.3 Problem Closure Put in place a procedure to close problem records either after confirmation of successful elimination of the known error or after agreement with the business on how to alternatively handle the problem. DS10.4 Integration of Configuration, Incident and Problem Management Integrate the related processes of configuration, incident and problem management to ensure effective management of problems and enable improvements. 138 2007 IT Governance Institute. All rights reserved. www.itgi.org
MANAGEMENT GUIDELINES Deliver and Support Manage Problems DS10 DS10 Manage Problems From Inputs Outputs To AI6 Change authorisation Requests for change (where and how to DS8 Incident reports apply the fix) AI6 DS9 IT configuration/asset details Problem records AI6 DS13 Error logs Process performance reports ME1 Known problems, known errors and workarounds DS8 RACI Chart Functions Activities CEO CFO CIO Business Executive Business Process Owner Head Operations Chief Architect Head Development PMO Head IT Administration Compliance, Audit, Risk and Security Problem Manager Identify and classify problems. I I C A C C I R Perform root cause analysis. C C A/R Resolve problems. C A R R R C C Review the status of problems. I I C A/R C C C C R Issue recommendations for improvement, and create a related RFC. I A I I I R Maintain problem records. I I I I A/R A RACI chart identifies who is Responsible, Accountable, Consulted and/or Informed. Goals Goals and Metrics IT Ensure the satisfaction of end users with service offerings and service levels. Reduce solution and service delivery defects and rework. Protect the achievement of IT objectives. set Process Record and track operational problems through resolution. Investigate the root cause of all significant problems. Define solutions for identified operations problems. set Activities Assigning sufficient authority to the problem manager Performing root cause analysis of reported problems Analysing trends Taking ownership of problems and progressing problem resolution drive measure measure measure drive Metrics Number of recurring problems with an impact on the business Number of business disruptions caused by operational problems Percent of problems recorded and tracked Percent of problems that recur (within a time period), by severity Percent of problems resolved within the required time period Number of open/new/closed problems, by severity Average and standard deviation of time lag between problem identification and resolution Average and standard deviation of time lag between problem resolution and closure Average duration between the logging of a problem and the identification of the root cause Percent of problems for which a root cause analysis was undertaken Frequency of reports or updates to an ongoing problem, based on the problem severity 2007 IT Governance Institute. All rights reserved. www.itgi.org 139
DS10 Deliver and Support Manage Problems MATURITY MODEL DS10 Manage Problems Management of the process of Manage problems that satisfies the business requirement for IT of ensuring end users satisfaction with service offerings and service levels, and reducing solution and service delivery defects and rework is: 0 Non-existent when There is no awareness of the need for managing problems, as there is no differentiation of problems and incidents. Therefore, there is no attempt made to identify the root cause of incidents. 1 Initial/Ad Hoc when Personnel recognise the need to manage problems and resolve underlying causes. Key knowledgeable personnel provide some assistance with problems relating to their area of expertise, but the responsibility for problem management is not assigned. Information is not shared, resulting in additional problem creation and loss of productive time while searching for answers. 2 Repeatable but Intuitive when There is a wide awareness of the need for and benefits of managing IT-related problems within both the business units and information services function. The resolution process is evolved to a point where a few key individuals are responsible for identifying and resolving problems. Information is shared amongst staff in an informal and reactive way. The service level to the user community varies and is hampered by insufficient, structured knowledge available to the problem manager. 3 Defined when The need for an effective integrated problem management system is accepted and evidenced by management support, and budgets for the staffing and training are available. Problem resolution and escalation processes have been standardised. The recording and tracking of problems and their resolutions are fragmented within the response team, using the available tools without centralisation. Deviations from established norms or standards are likely to be undetected. Information is shared among staff in a proactive and formal manner. Management review of incidents and analysis of problem identification and resolution are limited and informal. 4 Managed and Measurable when The problem management process is understood at all levels within the organisation. Responsibilities and ownership are clear and established. Methods and procedures are documented, communicated and measured for effectiveness. The majority of problems are identified, recorded and reported, and resolution is initiated. Knowledge and expertise are cultivated, maintained and developed to higher levels, as the function is viewed as an asset and major contributor to the achievement of IT objectives and improvement of IT services. Problem management is well integrated with interrelated processes, such as incident, change, availability and configuration management, and assists customers in managing data, facilities and operations. Goals and metrics have been agreed upon for the problem management process. 5 Optimised when The problem management process is evolved into a forward-looking and proactive one, contributing to the IT objectives. Problems are anticipated and prevented. Knowledge regarding patterns of past and future problems is maintained through regular contacts with vendors and experts. The recording, reporting and analysis of problems and resolutions are automated and fully integrated with configuration data management. Goals are measured consistently. Most systems have been equipped with automatic detection and warning mechanisms, which are continuously tracked and evaluated. The problem management process is analysed for continuous improvement based on analysis of measures and is reported to stakeholders. 140 2007 IT Governance Institute. All rights reserved. www.itgi.org
Shrnutí a závěr Poděkování a otázky Přílohy COBIT 4.1: Process DS10 Manage Problems KONEC PŘÍLOHY zpět na začátek přílohy Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 44 / 46
Shrnutí a závěr Poděkování a otázky Přílohy IBM Global Systems Management Reporting Technology (GSMRT) Standard Incident / Problem Package Overview ZAČÁTEK PŘÍLOHY zpět do prezentace přeskočit přílohu Age Breakout Report Daily Morning Report Manage Top 10 Incident / Problem Measurement Out of Criteria Severity 1&2 Workgroup ID Marek Rychlý Change Management & Problem Management (ITILv3) Přednáška pro ISE, 16. březen 2015 45 / 46
Global Systems Management Reporting Technology Global Systems Management Reporting Technology (GSMRT) Standard Incident / Problem Package Overview Prepared by: Maureen McDonough GSMRT Incident and Problem Package Overview 03/06/08 2005 IBM Corporation
Global Systems Management Reporting Technology Terms of use, copyright and trademark information By using these materials you agree to the IBM Terms of Use: http://www.ibm.com/legal/us/. The IBM copyright and trademark information webpage is incorporated herein by reference: http://www.ibm.com/legal/copytrade.shtml. 2 GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Aging Report 4 Name Aging Report (Age Breakout Report) Report Layer(s) Summary, Detail Grouping(s) Summary - Resolver Group; Detail Resolver Group, Age Report Description Aging of open tickets by count per age bucket. Business Use / Need This trend report is intended for use by management to assess how many tickets are being resolved by which groups in a timely manner. GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Aging Report (a.k.a. Age Breakout Report) - Summary 5 GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Aging Report Detail 6 GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Daily Morning 7 Name Daily Morning Report Layer(s) Summary, Detail Grouping(s) Summary and Detail Ticket Status, Report Group 1, Report Group 2 Report Description This report displays summary and detail data for all open problem tickets; sorted by account major, account minor and then severity with tickets in await state at the bottom of the report. Business Use / Need This report is used by the problem coordinators to view detailed ticket information for all open incident / problem tickets. GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Daily Morning 8 GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Daily Morning Detail 9 GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Manage Top Incidents / Problems 10 Name Manage Top Incidents / Problems Report Layer(s) Trend, Detail Grouping(s) Trend Component; Detail Report Group 1, Report Group 2, System, Component, Cause Code Report Description This is a problem management measurement report which contains the top 10 reported issues by component. Business Use / Need This report is to focus the managers to assess problem tickets by component. (i.e. which components are creating the most tickets opened, etc.) GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Manage Top Problems 11 GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Manage Top Problems Detail 12 GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Out of Criteria 21 Name Out of Criteria Report Layer(s) Summary, Detail Grouping(s) Summary Report Group 1, Report Group 2; Detail Report Group 1, Report Group 2, Resolver Group, Out of Criteria Status Report Description This report contains open incident tickets that are either out of criteria or near out of criteria (where 75% or more of the SLA time has expired), sorted by workgroup then severity. Business Use / Need This report provides detailed information on tickets that were out of criteria in order to minimize future OOC tickets. GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Out of Criteria Summary 22 GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Out of Criteria Detail 23 GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Severity 1 & 2 45 Name Severity 1 & 2 Report Layer(s) Summary, Detail Grouping(s) Summary Report Group 1, Report Group 2; Detail Report Group 1, Report Group 2, Severity Report Description This report contains problem tickets opened within specified time period; sorted by severity, status and workgroup. Business Use / Need This report provides a snapshot of the severity 1 & 2 tickets in order to resolve the highest priority tickets first for the customer. GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Severity 1 & 2 - Summary 46 GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Severity 1 & 2 Detail 47 GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Workgroup ID 48 Name Workgroup ID Report Layer(s) Detail Grouping(s) Detail - Workgroup Report Description This report displays all workgroups and the users associated with those workgroups. Business Use / Need This report is used as a reference by the problem coordinators and other account management team members to find user information about each of the workgroups. GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation
Global Systems Management Reporting Technology Workgroup ID Report - Detail 49 GSMRT Incident and Problem Package Overview 03/06/08 2003 IBM Corporation