ITSM Maturity Model - Tarrani

1 itsm Maturity Model1- Ad Hoc2 - Repeatable3 - Defined4 - Managed5 - OptimizingIncidentmanagement No standardized incidentmanagement process exists Incident managementprocedures are ad hoc No formal, written standardprocedures, or procedures areout of date or not followed Lack of, or unenforcedpolicies governing incidentmanagement Incident urgency, impact andpriority arbitrarily assigned No single owner of theprocess Existing tools are eitherinadequate or not used to fullcapabilities Incident sources are notcaptured Cannot determine whether allincidents are either reported orcaptured Policies governing incidentmanagement are publishedand enforced Incident management processis established and followed Formal written procedures thatare up-to-date and followed Roles and responsibilitieshave been clearly defined andassigned Incident urgency.

2 Impact andpriority classes are clearlydefined and used in aconsistent manner Incident lifecycle established Incident sources are capturedand documented Key performance indicatorsfor resolving incidents areemployed and tracked(response and resolutiontargets based on urgency,impact and priority; first callresolution rates tracked) Single point of processownership Hierarchical and functionalescalation paths established Incident resolution progress ismonitored Knowledgebase establishedand employed Incidents with an unknownroot cause are passed toproblem management Automated tool in place tosupport incident managementand capabilities and functionsare being properly used Incident management processis aligned to ITIL framework Interrelationships between andamong other ITIL processesand functions are clearlydefined and understood by allincident management roles Clear interface betweenincident management andproblem

3 management (problem/known errordatabase information availableto incident management ) OLAs between and amongother process areas andfunctions established Incident lifecycle KPIsmeasured: total number of incidents average resolution time average resolution time, bypriority averages resolved withinSLAs percentage of incidentsresolved by first-line support(without routing) number of incidents (orpercentage) with initialincorrect classification number of incidents (orpercentage) routed incorrectly Procedures in place to manageincident backlogs Incidents are correlated tochanges Clear interface betweenincident management andservice level management Integration of incidentmanagement tools andautomated monitoring tools Policies, procedures andprocess formally reviewed forcontinued applicability (on aset schedule.)

4 , every sixmonths) Process monitored for gapsand inefficiencies Costs per incident by service known and continuouslytracked Reconciliation of conflictinggoals between incident andproblem management Complete alignment betweenincident and service levelmanagement User satisfaction measuredand tracked Trend analysis of all KPIs andprocess parameters Known costs of each incidentby service broken out by CIand urgency Incident management processcontinuously reviewed forimprovement opportunities Regression analysis applied toKPIs; gap analysis and rootcause investigated when actualvalues are not equal toforecasts1- Ad Hoc2 - Repeatable3 - Defined4 - Managed5 - OptimizingProblemmanagement No standardized problem management process exists Problem managementprocedures are ad hoc No formal, written standardprocedures, or procedures areout of date or not followed Lack of.

5 Or unenforcedpolicies governing problemmanagement Root cause analysis is notperformed on incidents that donot have a known root cause Known errors andworkarounds are not published Organization does notdistinguish between incidentsand problems No single owner of theprocess Existing tools are eitherinadequate or not used to fullcapabilities Clear differentiation betweenincidents and problems allincidents that cannot beresolved or have an unknownroot cause trigger the problemmanagement process Policies governing problemmanagement are publishedand enforced Problem management processis established and followed Formal written procedures thatare up-to-date and followed Roles and responsibilitieshave been clearly defined andassigned Problem classification criteriais established and employed( , category, impact,urgency, priority & status)

6 Single owner of process Problems are investigated todetermine root cause Known errors andworkarounds are documentedand added to theknowledgebase Clear path of advancingproblems to known errors RFCs are raised whenapplicable to resolve knownerrors Problem database ismaintained and up to date Automated tools in place tosupport the problemmanagement process withlinkage between incidentrecords and problem tickets. Problem management processis aligned to ITIL framework Interrelationships between andamong other ITIL processesand functions are clearlydefined and understood by allproblem management roles Clear interface betweenproblem management andincident management (problem/known errordatabase information availableto incident management ) Problem managementdatabase is integrated withCMDB Known error elimination istracked and weekly statusreports of outstanding KEs,action taken to date and ETCsfor each.

7 Formal and structured analysistechniques are made a part ofSOP and employed Recurring problems aretracked and analyzed for rootcauses Policies, procedures andprocess formally reviewed forcontinued applicability (on aset schedule; , every sixmonths) Process monitored for gapsand inefficiencies Trend analysis of problemsfed to availability and capacitymanagement Costs of problem managementactivities are known and arelinked to CIs . Problem management processcontinuously reviewed forimprovement opportunities Regression analysis applied toKPIs; gap analysis and rootcause investigated when actualvalues are not equal toforecasts Proactive posture MTBF data from availabilitymanagement used to predictproblems and proactivelyaddress them CIs with identified highincident or problem rates areflagged and analyzed tosupport financial, servicecontinuity and availabilitymanagement process goalsChangemanagement No standardized change management process exists Change managementprocedures are ad hoc No formal.

8 Written standard Policies governing changemanagement are publishedand enforced Change management processis established and followed Change management processis aligned to ITIL framework Interrelationships between andamong other ITIL processesand functions are clearly Policies, procedures andprocess formally reviewed forcontinued applicability (on aset schedule; , every sixmonths) Change management processcontinuously reviewed forimprovement opportunities Regression analysis applied toKPIs; gap analysis and root1- Ad Hoc2 - Repeatable3 - Defined4 - Managed5 - Optimizingprocedures, or procedures areout of date or not followed Lack of, or unenforcedpolicies governing changemanagement Changes are made withoutimpact analysis and/orapproval No clear definition of whatconstitutes a change Changes often requirebackouts or trigger incidents No single owner of theprocess (change manager)

9 Lack of a CAB Existing tools are eitherinadequate or not used to fullcapabilities Formal written procedures thatare up-to-date and followed Roles and responsibilitieshave been clearly defined andassigned A change manager has beenassigned and is the processowner A CAB is chartered andmembers identified Changes are classified bytype, priority and severity Changes are assessed beforesubmission to the CAB CIs associated with RFCs areclearly identified Changes are linked toincidents and problems RFCs have clearly definedimplementation,communication and backoutplans PIRs are performed whenchanges are made to resolvean incident, problem or knownerror, and when the change isbacked out or deviates fromthe implementation plan The CMBD is updated beforethe change is closed out A centralized, automatedchange management tool is inuse KPIs are established andtracked.

10 Example KPIsinclude: number of changesimplemented in a period(overall and per CI-category) list of the causes of changesand RFCs number of successfullyimplemented changes number of back-outs and theirreasons number of incidents related todefined and understood by allchange management roles Clear interface among change,release, configuration, incidentand problem management All process circumventionsare visible Additional KPIs are tracked,including: rate at which changes areimplemented (aggregate andby CI) number of rejected changes Graphing and trending of KPIsestablished PIR lessons learned arepublished to promote processimprovement Process monitored for gapsand inefficiencies Costs of changes known foreach CI Integration of changemanagement tool and CMDB Time values established forchange implementations by CIto more accurately forecastimplementation costs investigated when actualvalues are not equal toforecasts Analysis of problems andincidents triggering changes todetermine opportunities forinfrastructure improvement.