Change Management & Problem Management (ITILv3)

Change Management & Problem Management (ITILv3) Marek Rychlý Vysoké uˇcení technické v Brneˇ Fakulta informaˇcních technologií Ústav informaˇcních systému˚

Pˇrednáška pro ISE 16. bˇrezen 2015

Marek Rychlý

Change Management & Problem Management (ITILv3) — Pˇrednáška pro ISE, 16. bˇrezen 2015

1 / 46

Obsah 1

Cíle pˇrednášky a opakování Cíle pˇrednášky Change Management Problem Management

2

Change Management ˇ Zmena (Change) a její podpora ˇ Analýza a proces schválení zmen Spolupráce služeb

3

Problem Management Popis problému ˇ Rešení problému˚ Spolupráce služeb

Marek Rychlý


2 / 46

Cíle pˇrednášky a opakování Change Management Problem Management

Cíle pˇrednášky Change Management Problem Management

Cíle pˇrednášky

Znát cíle, obsah a pˇrínosy Change Managementu. ˇ popsat význam zmeny, ˇ Umet postup jejího plánování, realizace a vyhodnocení. Znát cíle, obsah a pˇrínosy Problem Managementu. ˇ významu incidentu, problému a postupu jeho ˇrešení. Porozumet Mít pˇredstavu o spolupráci služeb v této oblasti.

Marek Rychlý


4 / 46



Change Management ˇ hladká a nákladoveˇ efektivní implementace schválených zmen ˇ rizika, produktivita) (transparentnost, provázanost, ohodnocení a dopady zmen,

ˇ minimalizaci vzniku incidentu˚ v dusledku ˚ provedených zmen ˇ koordinace jejich pˇripomínkování, schvalování zmen, implementace a její vyhodnocení ..................................................................... v ESM patˇrí do skupiny služeb Relationship Management (služba, se kterou pˇríchází zákazník pˇrímo do styku)

v ITILv2 patˇrí do skupiny procesu˚ Service Support (procesy technické a uživatelské podpory u IT služeb)

v ITILv3 patˇrí do skupiny procesu˚ Service Transition (procesy pro pˇrevod 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ˇríprava a implementace služeb) Marek Rychlý


5 / 46



Problem Management prevence opakování incidentu, ˚ poruch infrastruktury, chyb ˇrízení (minimalizace jejich dopadu, úˇcelné využívání zdroju) ˚

vyšší stabilita IT infrastruktury (neustálého zlepšování kvality, méneˇ incidentu, ˚ trvalá ˇrešení)

ˇ vyšší úspešnost Service Desku v ukazateli „first-time fix“1 . ..................................................................... v ESM patˇrí do skupiny služeb Relationship Management (služba, se kterou pˇríchází zákazník pˇrímo do styku)

v ITILv2 patˇrí do skupiny procesu˚ Service Support (procesy technické a uživatelské podpory u IT služeb)

v ITILv3 patˇrí do skupiny procesu˚ Service Operation ˇ (procesy ˇrízení IT služeb behem používání, optimalizace)

v COBITv4.1 proces DS10 „Manage Problems“ (doména Deliver and Support, tedy doruˇcení/zavedení a podpora služeb) 1 FTF:

Incidenty vyˇrešené ihned pˇrímo pracovníky uživatelské podpory.

Marek Rychlý


6 / 46


ˇ Zmena (Change) a její podpora ˇ Analýza a proces schválení zmen Spolupráce služeb

Change Management ˇ stav IT infrastruktury nebo služby ˇ zmena je cokoliv, co mení ˇ (typicky požadovaná zmena tzv. „configuration item“)

ˇ do procesu vstupuje požadavek na zmenu (tzv. „Request for Change“, RFC) za úˇcelem implementace nových požadavku, ˚ plánovaných vylepšení ˇ opravy chyb nebo pˇrizpusobení ˚ služeb zmenám prostˇredí

cílem procesu potom je ˇ minimalizovat riziko, které muže ˚ zmena provést ˇ na poskytované služby a na business zákazníka) (urˇcit dopad zmeny

ˇ na první pokus, efektivne, ˇ bez následných incidentu˚ provést zmenu

ˇ a jejich ohodnocení, proto proces zahrnuje evidenci zmen schválení, urˇcení priority, naplánování, otestování, provedení a následnou dokumentaci a zhodnocení

Marek Rychlý


8 / 46



ˇ ˇ IT služeb (ITILv2) Zmena v kontextu zajištení

Marek Rychlý


9 / 46



Otázky v rámci Change Management ˇ Kdo nebo co požaduje zmenu? ˇ Jaký je duvod ˚ pro zmenu? Co pˇrinese? ˇ Jaké bude mít zmena dusledky? ˚ Budou trvalé? ˇ (a pokud výsledky nebudou odpovídat, pujde ˚ zmena vrátit?)

ˇ Jaké rizika pˇrináší zmena? Jak je budeme ˇrešit? (jaká bude prevence rizik a krizové plány?)

ˇ Jaké budou potˇreba zdroje pro provedení zmeny? (profese, lidé, peníze, cˇ as, služby, položky IT infrastruktury, atd.)

ˇ ˇ Kdo bude zodpovedný za pˇrípravu, testy a realizaci zmeny? ˇ vuˇ ˇ Jaký je vztah dané zmeny ˚ ci ostatním zmenám? (a to minulým, souˇcasneˇ ˇrešeným, pˇrípadneˇ i oˇcekávaným)

Marek Rychlý


10 / 46



Popis „Request for Change“ (RFC) ˇ (Change ID) jedineˇcný identifikátor zmeny ˇ (Initiator) zdroj zmeny datum pˇrijetí požadavku ˇ (kdo ji potˇrebuje) krátký popis zadavatele zmeny ˇ eˇ (Business Case) popis duvodu ˚ ke zmen ˇ na klienta, IT služby, IT komponenty (konfiguraˇcní dopad zmeny položky) a použité/požadované technologie ˇ rizika plynoucí z implementace zmeny, jejich typy a pˇríslušná protiopatˇrení k jejich prevenci/minimalizaci ˇ pˇredpokládaný a navržený cˇ asový rozpis implementace zmeny ˇ zdroje potˇrebné pro implementaci zmeny (požadovaný druh, poˇcet a zapojení pracovníku, ˚ zapojení klienta, školení pracovníku˚ i klienta, finanˇcní nákladnost, zdroje financí)

Marek Rychlý


11 / 46



ˇ zpracování požadavu na zmenu ˇ (dle ITILv3) Prub ˚ eh

Change proposal (optional) ●

Record the RFC Initiator

Requested

Review the RFC

Change Management

Ready for evaluation

Assess and evaluate change Ready for decision

Authorize change proposal

Change Authority

Authorized

Change Management

Change Mgmt.

Evaluation report

Work orders

Authorize change

Plan updates Scheduled

Co-ordinate change implementation* Implemented

Review and close change record

Work orders

Update change and configuration in CMS

Create RFC

Closed Marek Rychlý


12 / 46



ˇ Záznam a prvotní revize požadavku na zmenu ˇ odpovídat významu zmeny ˇ popis požadavku zadavatelem by mel ˇ mohou vyžadovat hlubší zduvodn ˇ a finanˇcní plán) (vážné zmeny ˚ ení

ˇ být veˇ ˇ rejneˇ viditelné požadavky by nemely ˇ by být posuzovány pouze odborne) ˇ (obsahují citlivé informace, mely

nevhodné požadavky je možno zamítnout již pˇri prvotní revizi (napˇr. již ˇrešené požadavky, nekompletní zadání, nepraktické, atp.)

ˇ být ohodnoceny a zpracovávány dle priorit požadavky by mely Normal Changes ˇ ˇ (bežné zmeny, mohou podstoupit standardní proces a oˇckat minimálneˇ ˇ reny na pravidelné týdenní schuzce) jeden týden, kdy jsou proveˇ ˚

Exception Changes ˇ (duležit ˚ ejší, schvalovat velmi rychle, nelze zajistit plnou analýzu rizik)

Emergency Changes (duležité ˚ pro podporu business aktivit zákazníka, neschvalovat normální postupem, zajišt’ují napˇr. okamžité ˇrešení incidentu) Marek Rychlý


13 / 46



ˇ a proces jejího schválení Analýza zmeny ˇ každá zmena pˇrináší rizika, nutné provést analýzu rizik ˇ (a zaznamenat napˇr. do matice: dopady × pravdepodobnosti)

ˇ být posuzována z obchodního pohledu dopady a rizika by mela (ohodnocení dopad, nutnosti, rizika, užitku a ceny, pro každou stranu)

ˇ dán jejím pˇrínosem pˇri úspešném ˇ dopad zmeny provedení nebo ˇ (napˇr. pokud rozsahem rizik odvrácených v dusledku ˚ zmeny ˇ reaguje na incident, opravuje nejaký problém) ˇ je dána dobou, dokdy je nutné zmenu ˇ provést nutnost zmeny ˇ a nutnost zmeny ˇ také ovlivnují ˇ její prioritu dopad zmeny ˇ a potvrzena/pˇrenastavena beh ˇ em ˇ analýzy) (navržena zadavatelem zmeny

ˇ na základeˇ analýzy se provede schválení zmeny ˇ bežného ˇ u zmen dopadu v rámci „Change Advisory Board“ (CAB) (pˇrípadneˇ „Emergency CAB“ u Exception/Emergency Changes)

ˇ s dopadem na více služeb na schuzi u zmen ˚ jejich zástupcu˚ ˇ s velkým dopadem/rizikem na zasedání vedoucích u zmen

Marek Rychlý


14 / 46



ˇ podle cíle Klasifikace zmen

ˇ Hardware: instalace a odinstalace, pˇremístení, modifikace ˇ komponent, zmena firmware. Software: modifikace operaˇcního systému, konfigurace a ˇ oprávnení. Aplikaˇcní: modifikace uživatelských aplikací, aktualizace. Sít’ové: instalace a modifikace sít’ových komponent, vˇc. firewallu.

Marek Rychlý


15 / 46



ˇ podle vlivu Klasifikace zmen ˇ Prostˇredí: zmeny, které mají vliv na IT prostˇredí. ˇ el. energie, (napˇr. stavební úpravy, chladící systémy, zajištení kabeláž, úprava fyzického pˇrístupu)

ˇ ovlivnující ˇ Infrastruktura: zmeny komponenty IT infrastruktury. ˇ mající vliv na dostupnost a aktivitu služby. Operace: zmeny ˇ (napˇr. pojmenování, standardy, procedury pˇrihlášení, zmeny operaˇcních procedur (disaster recovery plan), automatických postupu, ˚ cˇ innost údržby)

ˇ ovlivnující ˇ Informace: zmeny dostupnost daných služeb v daných ˇ provádené ˇ cˇ asech, nebo zmeny tˇretími stranami. ˇ vedoucí k aktivaci nebo deaktivaci služby. (De)Aktivace: zmeny

Marek Rychlý


16 / 46



ˇ Pˇríklad nástroje pro evidenci zmen

CA Service Desk Manager Marek Rychlý


17 / 46



Porady „Change Advisory Board“ (CAB) ˇ vetšinou se setkává jednou týdneˇ a obsahuje pˇredsedu, obvykle je to Change Manager zástupce zákazníka, vedoucí uživatelu, ˚ zástupce skupin uživatelu, ˚ vývojáˇre, konzultanty specialisty, zástupce techniku˚ ˇ zamestnance konkrétních služeb a operaˇcního ˇrízení ostatní úˇcestníky dle SLA, zástupce dodavatlu, ˚ atd.

nejlépe osobní setkání, pˇrípadneˇ v kombinaci s telemosty pˇresneˇ daný program jednání ˇ ˇ ˇ a jejich pˇriˇrazení (neoprávnené nebo chybneˇ provedené zmeny, návrhy na zmeny ˇ zprávy o provedených zmenách ˇ jednotlivým cˇ lenum, ˚ revize a plánování zmen, a ˇ atd.) jejich zhodnocení, návrhy na schválení zmen,

ˇ na setkání se neschvalují zmeny, pouze doporuˇcují (schvaluje až výkonné vedení podle jejich dopadu, napˇr. Change Manager)

Marek Rychlý


18 / 46



ˇ zmen ˇ Plánování a provádení schválené požadavky pˇredány pˇríslušných technickým skupinám (ty rozpracují plány jejich provedení)

ˇ ˇ jsou provedeny podle standardních postupu, bežné zmeny ˚ ˇ ostatní nutno plánovat dukladn ˚ eji (vˇc. plánu˚ záchranných ˇrešení a záložnách komunikaˇcních kanálu) ˚

ˇ jsou seskupovány v rámci tzv. „releases“ zmeny ˇ (spoleˇcneˇ plánovány, testovány a provádeny, minimalizace ostatních závoslostí)

ˇ dohlíží pro neˇ poveˇ ˇ rení „Change Coordinators“ na skupiny zmen ˇ výsledky jejich testu, (kontrolují plány zmen, ˚ pˇrípravy ke krytí rizik, atd.)

ˇ provedeny v tzv. „change windows“, minimální rizika zmeny ˇ v daném cˇ asovém pásmu) (mimo pracovní dobu, napˇr. v pozdní noci na nedeli

aktivity jsou koordinovány se všemi úˇcastníky ˇ se zákazníkem, dodavateli, realizace zmeny ˇ nesmí pˇrekvapit) (porozumení Marek Rychlý


19 / 46



ˇ Vyhodnocení a uzavˇrení zmen ˇ zpracování její zhodnocení formou zprávy po provedení zmeny ˇ její realizace a skuteˇcný dopad) (prub ˚ eh

ˇ skuteˇcný vs. oˇcekávaný vliv zmeny ˇ názor zuˇ ˚ castnených stran na výsledky a identifikace nedostatku˚ ˇ neoˇcekávané situace as jejich ˇrešení vedlejší efekty zmen, ˇ skuteˇcné vs. oˇcekávané využití zdroju, ˚ cˇ as a cena zmeny ˇ realizace zmeny, ˇ prub ˚ eh pˇrípadneˇ ˇrešení krizových situací ˇ návratu k pˇredešlému stavu, pokud se aplikace zmeny ˇ nezdaˇrila) (prub ˚ eh

ˇ analýza zpráv o zmenách, sledování trendu˚ a dodržování SLA ˇ ale muže (porušení SLA není obvyklé, díky dobrému plánování zmen, ˚ nastat)

ˇ je uzavˇren Change Managerem a získané návrh na zmenu zkušennosti zaneseny do Knowledge Database ˇ cný kontrola/uzavˇrení se provádí v pravidelných intervalech) (závereˇ

Marek Rychlý


20 / 46



Infrastructure Service Interconnections (ESM)

Configuration Management ˇ ené ˇ (všechny men IT prvky jsou v databázi konfigurace)

Software Distribution ˇ (všechny distribuce jsou požadavkem na zmenu)

Call Management, Operations Management ˇ a reakce na komunikaci) (komunikace s uživateli ohledneˇ zmen

Business Process Management ˇ mohou mít vliv na business aktivitu nebo být iniciovány její zmenou) ˇ (zmeny

Resource Management ˇ vyžadují zdroje) (zmeny

Marek Rychlý


21 / 46



Relationship Service Interconnections (ESM) Reporting Management ˇ cní zprávy pro poskytovatele služeb a zákazníka) (denní, týdenní a mesíˇ

Request Management ˇ ˇ je plánována na základeˇ požadavku) (vetšina zmen ˚

Knowledge Management ˇ (zprávy o zmenách tvoˇrí znalostní bázi organizace)

Asset Management ˇ (vyhodnocení dopadu zmen)

Notification Management ˇ ˇ dochází k upozornením ˇ ˇ (behem zmen zúˇcastnených subjektu) ˚

Problem Management ˇ (zmena muže ˚ vyvolat problém a být pozastavena do jeho vyˇrešení)

Marek Rychlý


22 / 46



Proces AI6 Manage Changes v COBIT 4.1 — zde má být pˇríloha — pˇrejít na pˇrílohu

Marek Rychlý


23 / 46



IBM Global Systems Management Reporting Technology (GSMRT) – Change Package Overview — zde má být pˇríloha — pˇrejít na pˇrílohu

Další pˇríklady nástroju: ˚ 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ý


24 / 46


Popis problému ˇ Rešení problému˚ Spolupráce služeb

Problem Management problém je (neznámá) pˇríˇcina jednoho nebo více incidentu˚ do procesu vstupuje popis problému (tzv. „Problem Ticket“) cílem procesu potom je vyˇrešit problém, zabránit jeho budoucímu opakování (na základeˇ popisu problému identifikovat chybu a nalézt ˇrešení)

zabránit budoucím incidentum ˚ známých problému, ˚ pˇrípadneˇ minimalizovat jejich dopad ˇ (nekterým incidentum ˚ nelze zabránit, pˇrestože známe problém = pˇríˇcinu)

proto proces zahrnuje detekci problému, ˚ jejich evidenci, ohodnocení, vyšetˇrení, nalezení doˇcasných i trvalých ˇreš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ému˚ a jejich možných ˇrešení)

Marek Rychlý


26 / 46



Popis problému (Problem Ticket) – I. Problem Description (struˇcný a dostateˇcný slovní popis problému)

Severity ˇ ˇ ˇ údaj, na základeˇ (kritiˇcnost problému výberem z nekolika možností, nejduležit ˚ ejší ˇ Service Level Agreement (SLA) ovlivnuje požadovaný cˇ as ˇrešení)

Time Opened (datum a cˇ as, kdy byl problém nahlášen; je klíˇc)

Group Assigned (skupina Subject Matter Experts (SME), která má problém ˇrešit; je klíˇc)

Contact Information ˇ (kontakty na zúˇcastnené strany, vˇc. posloupností kontaktu, ˚ jak postupovat, pokud pˇredchozí neodpoví do urˇcité doby)

Marek Rychlý


27 / 46



Popis problému (Problem Ticket) – II. System, Component, Item, Module (SCIM) (konfigurace poskytnutá z Configuration Management, které se problém týká, ˇ systému a pˇríslušné SME; pomáhá napˇr. konkrétní server/servery, OS, umístení ˇ smerovat problém na pˇríslušné osoby)

Time Closed (datum a cˇ as, kdy byl problém uzavˇren, pak již nelze editovat2 )

Change Integration ˇ ˇrešení a vyˇrešení problému) (zmeny, ke kterým došlo v dusledku ˚

Duration for resolution (= Time Closed − Time Opened)

Resolution (zpusob ˚ vyˇrešení problému vložen v cˇ ase jeho uzavˇrení) 2 místo zmen ˇ se vytváˇrí další popis problému, napˇr. poznámky ˇrešitele, nebo znovu-otevˇrený problém Marek Rychlý


28 / 46



Porady o problémech Incident/Problem3 review meetings (prevence problému, ˚ definice operaˇcních postupu˚ pro budoucí rychlé ˇrešení, zkoumání vzájemného propojení více problému˚ a synchronizace na nich pracujících skupin SME)

denní setkání, kde se ˇreší problémy z pˇredchozího dne, pˇripravují aktualizace jejich popisu˚ a kontrolují uzavˇrené problémy,

Root cause analysis (RCA) review meetings ˇ ˇ (jsou podmetem pro personální a technologické zmeny, nákup a upgrade prvku˚ IT infrastruktury)

ˇ týdenní setkání, kde SME vysvetlují podstatu a ˇrešení již uzavˇrených problému˚ 3 „incident“ Marek Rychlý

je okamžik vzniku „problému“ Change Management & Problem Management (ITILv3) — Pˇrednáška pro ISE, 16. bˇrezen 2015

29 / 46



Komunikace o problémech Je potˇreba: pˇripravit zprávy o incidentech, analýze problému˚ a stanovení trendu, ˚ (identifikují se podobné problémy a doporuˇcí budoucí prevence výskytu˚ incidentu˚ a rychlé ˇrešení problému) ˚

spravovat aktuální seznam prvku˚ IT infrastruktury, identifikovat a nahlásit problémy, které mají vliv na cˇ innost zákazníka, (problémum ˚ se pˇriˇradí „business criticality“)

identifikovat eskalující a duplicitní problémy a urˇcit budoucí rozpoznání a prevenci, ˇ rit „Severity levels“ v popisech problému, pˇrehodnotit a oveˇ ˚ identifikovat trendy, výstižnost informací a míru úplnosti popisu problému, ˚ ˇ identifikovat zodpovednosti poskytovatelu˚ služeb a zákazníku. ˚

Marek Rychlý


30 / 46



Životní cyklus problému

Marek Rychlý


31 / 46



ˇ Rešení a uzavˇrení problému˚ ˇrešení problému˚ koordinováno Problem Managerem (jednotlivé problémy jsou ˇrešeny skupinami specialistu, ˚ dodavatelu, ˚ atd.)

pro doˇcasné, ale okamžité ˇrešení problému, ˚ tzv. „Workarounds“ ˇ stejných problému, (doˇcasneˇ zabrání hromadení ˚ pˇrestože není jejich pˇríˇcina dosud plneˇ pochopena; bud’ se stane trvalým ˇrešením, nebo jím bude nahrazeno)

jakmile je známé ˇrešení (i doˇcasné) tak musí být zaznamenáno do „Known Error Record“ (záznam se provede do tzv. „Known Error Database“, cˇ ásti Knowledge Database)

záznam obsahuje detailní popis chyby, její pˇríznaky, spoleˇcneˇ s pˇresným popisem doˇcasného nebo trvalého ˇrešení výhodné je zaznamenávat i ˇrešené problémy s evidencí postupu ˇ (zabrání duplicitnímu ˇrešení, eviduje dokumentaci, incidenty, zmeny, atd.)

„Known Error Records“ spravuje a uzavírá Problem Manager (zárovenˇ sestavuje pravidelneˇ Major Problem Reviews) Marek Rychlý


32 / 46



Infrastructure Service Interconnections (ESM) Configuration Management (pro kategorizaci problému podle SCIM)

Event Management (popisy problému˚ mohou být manuálneˇ nebo automaticky vytvoˇreny a pˇriˇrazeny na základeˇ událostí)

Availability Management (porušení „dostupnosti“ bývá zpravidla velmi vážný problém)

Performance and Capacity Management ˇ (obtížneˇ pˇriˇraditelné problémy, zpravidla ˇrešeny dlouho a nekolika skupinami)

Operations Management (operátoˇri mohou zajistit stav prostˇredí pˇri incidentu a provést první kroky ˇrešení)

Security Management, Network Management (narušení bezpeˇcnosti/síteˇ muže ˚ být zpusobeno ˚ problémem a zárovenˇ samo je vážný problém) Marek Rychlý


33 / 46



Relationship Service Interconnections (ESM)

Reporting Management ˇ cní zprávy pro poskytovatele služeb a zákazníka) (denní, týdenní a mesíˇ

Change Management ˇ (ˇrešení problému˚ vyžaduje zmeny)

Knowledge Management (incidenty a problémy jsou zaznamenávány pro prevenci a výuku)

Notification Management ˇ ˇrešení problému je tˇreba hierarchicky upozornovat ˇ (behem ruzné ˚ subjekty)

SLA Management ˇ (ˇrešení problému musí splnovat a podporovat SLA)

Marek Rychlý


34 / 46



Proces DS10 Manage Problems v COBIT 4.1 — zde má být pˇríloha — pˇrejít na pˇrílohu

Marek Rychlý


35 / 46



IBM Global Systems Management Reporting Technology (GSMRT) – Standard Incident / Problem Package Overview — zde má být pˇríloha — pˇrejít na pˇrílohu

Další pˇríklady nástroju: ˚ BMC’s Remedy HP’s Peregrine Managed Objects IBM’s Enterprise Systems Manager IBM MRO’s Maximo (TSD) PeopleSoft’s Vantive Marek Rychlý


36 / 46

ˇ Shrnutí a záver ˇ Podekování a otázky Pˇrílohy

ˇ Shrnutí a záver

Problem Management reaguje na incident ˇrešením problému. Cílem je prevence incidentum ˚ a rychlé a úˇcinné ˇrešení budoucích problému. ˚ ˇ Change Management plánuje a implementuje zmeny. ˇ bez incidentu˚ a její Cílem je bezpeˇcné provedení zmeny vyhodnocení.

Marek Rychlý


37 / 46


ˇ Dekuji za pozornost.

Otázky? Diskuze?

Marek Rychlý


38 / 46


COBIT 4.1: Process AI6 Manage Changes ˇ ˇ — ZACÁTEK PRÍLOHY — ˇ do prezentace zpet

pˇreskoˇcit pˇrílohu

Proces v doméneˇ „Acquire and Implement“. Duležitý ˚ proces. Velice podobný (a kompatibilní) s ITIL procesem Change Management. Pˇrevzato z „IT Governance Institute: COBIT 4.1. ISACA, 2007, ISBN 1-933284-72-2“.

Marek Rychlý


39 / 46

Acquire and Implement Manage Changes

AI6

PROCESS DESCRIPTION AI6 Manage Changes

Eff ec tiv Eff ene s i Co cien s nfi cy de Int ntial eg ity Av rity ail Co abili mp ty l Re ianc lia e bil ity

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

S

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

CE MANENT FOR PER SUREM MEA

IT GOVERNANCE

RESOURCE MANAGEMENT

Primary

Ap pli ca Inf tion orm s Inf atio ras n t Pe ructu op le re

DE VAL LIV UE ER Y

MAN RISK AGE MEN T

C GI T TE EN RA M ST IGN AL

Secondary

© 2007 IT Governance Institute. All rights reserved. www.itgi.org

93

AI6


CONTROL OBJECTIVES AI6 Manage Changes 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



AI6

MANAGEMENT GUIDELINES AI6 Manage Changes From Inputs

Outputs

PO1 PO8 PO9 PO10

IT project portfolio Quality improvement actions IT-related risk remedial action plans 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

To AI1…AI3 ME1 AI7 DS8 DS10

Change process description Change status reports Change authorisation

Develop and implement a process to consistently record, assess and prioritise change requests. Assess impact and prioritise changes based on business needs. Assure that any emergency and critical change follows the approved process. Authorise changes. Manage and disseminate relevant information regarding changes.

A I I I A

R A/R A/R A/R R

Chi ef A rch itec t Hea dD eve lopm Hea ent d IT Adm i n istr PM atio O n Com Ris plian k a ce, nd Au Sec dit, urit y

ss O wne per r atio ns

oce

dO

s Pr

I R I C I

Hea

Bus ines

Bus ines s Ex ecu CIO tive

Activities

CFO

Functions

CEO

RACI Chart

C C I C

R R R R R

C C

C R

C C C

I

R

C

A RACI chart identifies who is Responsible, Accountable, Consulted and/or Informed.

Goals

Goals and Metrics IT

Process

Activities

• 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.

• 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.

• Defining and communicating change procedures, including emergency changes and patches • Assessing, prioritising and authorising changes • Scheduling changes • Tracking status and reporting on changes

Metrics

measure

• 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


set

ve dri

• Number of disruptions or data errors caused by inaccurate specifications or incomplete impact assessment

e driv

measure

set

measure

• 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

95

AI6


MATURITY MODEL AI6 Manage Changes 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



COBIT 4.1: Process AI6 Manage Changes ˇ — KONEC PRÍLOHY — ˇ na zaˇcátek pˇrílohy zpet

Marek Rychlý


40 / 46


IBM Global Systems Management Reporting Technology (GSMRT) – Change Package Overview ˇ ˇ — ZACÁTEK PRÍLOHY — ˇ do prezentace zpet


Changes by Completion Code Change Schedule Meeting Change Success Technical Change Meeting

Marek Rychlý


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


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


6.3.2008



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.


6.3.2008



Changes by Completion Code

12


6.3.2008



Changes by Completion Code – Code Selection

13


6.3.2008



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


6.3.2008



Change Schedule Meeting – Visual Overview

17


6.3.2008



Change Schedule Meeting – Detail

18


6.3.2008



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.


6.3.2008



Change Success – Trend Report

20


6.3.2008



Change Success – Summary Report

21


6.3.2008



Change Success – Detail Report

22


6.3.2008



Technical Change Meeting

33

Name


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.


6.3.2008




34


6.3.2008



Technical Change Meeting – Detail

35


6.3.2008



IBM Global Systems Management Reporting Technology (GSMRT) – Change Package Overview ˇ — KONEC PRÍLOHY — ˇ na zaˇcátek pˇrílohy zpet

Marek Rychlý


42 / 46


COBIT 4.1: Process DS10 Manage Problems ˇ ˇ — ZACÁTEK PRÍLOHY — ˇ do prezentace zpet


Proces v doméneˇ „Deliver and Support“. Duležitý ˚ proces. Velice podobný (a kompatibilní) s ITIL procesem Problem Management. Pˇrevzato z „IT Governance Institute: COBIT 4.1. ISACA, 2007, ISBN 1-933284-72-2“.

Marek Rychlý


43 / 46

Deliver and Support Manage Problems

DS10

PROCESS DESCRIPTION DS10 Manage Problems

Eff ec tiv Eff ene s i Co cien s nfi cy de Int ntial eg ity Av rity ail Co abili mp ty l Re ianc lia e bil ity

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

S

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

DE VAL LIV UE ER Y

RESOURCE MANAGEMENT

Primary

Ap pli ca Inf tion orm s Inf atio ras n t Pe ructu op le re

MAN RISK AGE M

CE MANENT FOR PER SUREM MEA

IT GOVERNANCE

ENT

C GI T TE EN RA M ST IGN AL

Secondary


137

DS10


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



DS10

MANAGEMENT GUIDELINES DS10 Manage Problems From Inputs

Outputs

Change authorisation Incident reports IT configuration/asset details Error logs

To

Requests for change (where and how to apply the fix) Problem records Process performance reports Known problems, known errors and workarounds

DS8

Functions

Bus

ines s Ex CIO

Identify and classify problems. Perform root cause analysis. Resolve problems. Review the status of problems. Issue recommendations for improvement, and create a related RFC. Maintain problem records.

Bus

Activities

CFO

CEO

ecu t

ive

RACI Chart

AI6 AI6 ME1

ines s Pr oce Hea ss O dO wne per r atio ns Chi ef A rch itec t Hea dD eve lopm Hea ent d IT Adm i nist PM rati O on Com Ris plian k a ce, nd Au Sec dit, Pro u ble m M rity ana ger

AI6 DS8 DS9 DS13

I

I

C

I

I

C C I I

A C A A/R A I

C R C I

C C R C I I

I R C I

C C I

R A/R C R R A/R

A RACI chart identifies who is Responsible, Accountable, Consulted and/or Informed.

Goals

Goals and Metrics IT

Process

• 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.

• Record and track operational problems through resolution. • Investigate the root cause of all significant problems. • Define solutions for identified operations problems.

set

Metrics

measure

• 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


e driv

• Number of recurring problems with an impact on the business • Number of business disruptions caused by operational problems

set

e driv

measure

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

measure

• 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

139

DS10


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



COBIT 4.1: Process DS10 Manage Problems ˇ — KONEC PRÍLOHY — ˇ na zaˇcátek pˇrílohy zpet

Marek Rychlý


44 / 46


IBM Global Systems Management Reporting Technology (GSMRT) – Standard Incident / Problem Package Overview ˇ ˇ — ZACÁTEK PRÍLOHY — ˇ do prezentace zpet


Age Breakout Report Daily Morning Report Manage Top 10 Incident / Problem Measurement Out of Criteria Severity 1&2 Workgroup ID Marek Rychlý


45 / 46


Global Systems Management Reporting Technology (GSMRT) Standard Incident / Problem Package Overview Prepared by: Maureen McDonough

GSMRT Incident and Problem Package Overview

03/06/08



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


03/06/08



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.


03/06/08



Aging Report (a.k.a. Age Breakout Report) - Summary

5


03/06/08



Aging Report – Detail

6


03/06/08



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.


03/06/08



Daily Morning

8


03/06/08



Daily Morning – Detail

9


03/06/08



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.)


03/06/08



Manage Top Problems

11


03/06/08



Manage Top Problems – Detail

12


03/06/08



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.


03/06/08



Out of Criteria – Summary

22


03/06/08



Out of Criteria – Detail

23


03/06/08



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.


03/06/08



Severity 1 & 2 - Summary

46


03/06/08



Severity 1 & 2 – Detail

47


03/06/08



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.


03/06/08



Workgroup ID Report - Detail

49


03/06/08



IBM Global Systems Management Reporting Technology (GSMRT) – Standard Incident / Problem Package Overview ˇ — KONEC PRÍLOHY — ˇ na zaˇcátek pˇrílohy zpet

Marek Rychlý


46 / 46

Change Management & Problem Management (ITILv3)

Recommend Documents