Incident Management en Change Management, ITIL-processen, hebben in veel organisaties een bepaalde volwassenheid bereikt. Echter om de een of andere reden wil het in veel bedrijven niet vlotten met het proces Problem Management. Als gecertificeerd ITIL Proces consultant met meer dan 10 jaar ervaring op het gebied van processen en outsourcing, durf ik te stellen dat Problem Management in de meeste bedrijven fout is geïmplementeerd. Geen zorgen, ik ga je vertellen waarom en laat zien hoe het wél kan.
HET MOEILIJKE INCIDENTEN PROCES
Je kent het vast wel. Op de Servicedesk wordt er een incident ontvangen, dat daar niet opgelost kan worden, noch op de tweede lijn en zelfs niet op een eventuele derde lijn. Het incident dreigt buiten de SLA te lopen en we maken van het incident een zogeheten problem. Niet omdat we binnen Problem Management een andere aanpak hebben ten opzichte van Incident Management, maar wel omdat we daar vaak meer tijd hebben om tot een oplossing te komen, doordat er andere servicelevels gelden.
Het incident wordt gekoppeld aan het problem en vaak ook gesloten, met de mededeling aan de eindgebruiker dat we er een problem van hebben gemaakt. En vervolgens kennen we het toe aan onze beste engineer, die het op eenzelfde manier probeert op te lossen als dat hij incidenten oplost. Dit is niet het Problem Management proces maar eerder het Moeilijke Incidenten proces.
WAT ZIJN DE VERSCHILLEN
Om te begrijpen waar het fout gaat, zullen we eerst moeten kijken waar Problem Management en waar Incident Management voor staan en waar ze dus in verschillen:
Incident Management tracht het overeengekomen serviceniveau zo snel mogelijk te herstellen of te handhaven, zodat de impact op het bedrijf wordt geminimaliseerd.
Problem Management tracht de negatieve impact van incidenten en problemen op het bedrijf, die worden veroorzaakt door onderliggende fouten in de IT-infrastructuur, te minimaliseren en proactief herhaling van incidenten met betrekking tot deze fouten te voorkomen.
WAT GAAT ER NU FOUT?
Incident Management en Problem Management hebben, zoals je hebt gezien, totaal verschillende doelen. En om deze reden worden er kapitale fouten begaan, binnen het Moeilijke Incidenten proces:
Het eindgebruikersrecht
Elke eindgebruiker heeft het recht om zo spoedig mogelijk dan wel binnen de gestelde servicelevels die er voor Incident Management gelden, een oplossing te krijgen (workaround of structureel) voor zijn of haar incident. Door van het incident een problem te maken en het incident zonder oplossing te sluiten, wordt niet voldaan aan dit recht en doen we de eindgebruiker te kort.
Niet per se problemen
Een moeilijk incident is niet per definitie een problem. Het betreft alleen een problem als het van structurele aard is en/of een hoge impact op de business heeft en/of er een reden is om nader te onderzoeken. Als we de grondoorzaak al kennen, de root cause, dan hoeven we hier geen onderzoek meer naar te doen en dan is een problem hier niet op z'n plaats.
We lossen niks op
Binnen Problem Management lossen we niks op, we analyseren/onderzoeken alleen, om de root cause te achterhalen en om beter te begrijpen wat zich nu precies voordeed, om hier in de toekomst van te leren. Dit documenteren we vervolgens in een Root Cause Analyses document (RCA). Een mogelijke oplossing dragen we voor, vanuit de RCA, in de vorm van RFC's (Request for Change). Uiteindelijk zal door middel van de RFC's de root cause weggenomen moeten worden. En als aan het einde blijkt dat de root cause is weggenomen en onze analyse juist was, zullen we onze knowledge-base (known errors) met deze kennis vullen, zodat ons dit nooit meer kan gebeuren.
Het Problem Team
Goed analyseren van problems gaat nooit efficiënt en effectief door er maar één persoon op te zetten. Vaak overstijgen problems technologieën, maar ook lijnen. Ze kunnen beter door een multidisciplinair team opgepakt worden, in een soort project samenstelling, waarbij één lid de leiding krijgt als een project manager (problem owner). Het problem team bestaat uit mensen van verschillende disciplines en niveaus van de beheerorganisatie die relevant zijn voor dit problem. Dus van een Servicedesk agent, immers zij hebben de incidenten geregistreerd en spreken met de eindgebruiker, tot aan Technisch Consultants die gespecialiseerd zijn in verschillende relevante technieken. In sommige gevallen is er zelfs een leverancier nodig. Immers iedereen heeft vanuit zijn expertise een andere kijk op het probleem.
Symptoombestrijding
Binnen Incident Management wordt een incident vaak door middel van symptoombestrijding geprobeerd zo snel als mogelijk op te lossen. Voorbeeld: Je account wordt ge-unlockt door de Servicedesk. Waarom (oorzaak) je account elke dag om 11.00 uur wordt gelockt weten we niet, maar je kan wel weer verder werken en je blijft productief voor je werkgever.
Root Cause
Binnen Problem Management zoeken we naar de hoofdoorzaak. Om deze te kunnen vinden, zullen we moeten leren begrijpen wat er allemaal op de achtergrond gebeurt. In de praktijk zien we echter dat er vaak niet maar één oorzaak te vinden is, vaak betreft het een samenloop van omstandigheden en dus van verschillende oorzaken. En om die reden gaan we dan ook op zoek naar een oorzaak, die de keten van gebeurtenissen in een zo'n vroeg mogelijk stadium (binnen onze invloedssfeer) stopt. Dit noemen we dan de root cause. Ons onderzoek, de bewijslast, onze bevindingen en onze voorstellen hoe deze root cause weggenomen kan worden beschrijven we in een RCA. Tot op dit moment hebben we nog steeds niks gewijzigd aan de systemen, immers we willen niet dat bewijzen verloren gaan door contaminatie.
Meer dan de implementatie
Eerlijkheidshalve moet ik toegeven dat het niet alleen aan de implementatie van Problem Management hoeft te liggen. Vaak worden we gestuurd door de manier hoe onze Service Management tools omgaan met bepaalde processen. Ik heb veel tools gezien en Problem Management ziet er vaak exact hetzelfde uit als het Incident Management proces. Het ligt dan ook voor de hand, dat we op een zelfde manier met problems omgaan als dat we dat doen met incidenten.
EN HOE ZIT HET MET DE KPI’S
Daar waar we binnen Incident Management proberen de eindgebruiker zo snel als mogelijk weer verder te kunnen laten werken, al dan niet met een workaround, proberen we binnen Problem Management de root cause te achterhalen, het probleem te begrijpen en deze kennis vast te leggen en beschikbaar te maken voor onze gehele beheer-organisatie.
Tijd is binnen Problem Management van ondergeschikt belang. Een Problem Management KPI die stuurt op tijd is een fout gekozen KPI, immers heb je voor goede analyses juist tijd nodig en kun je op voorhand niet weten hoe lang een gedegen analyse duurt.
Een betere KPI zou bijvoorbeeld kunnen zijn dat er binnen een tijdvak minimaal een X-aantal RCA's worden verwacht, die hebben bijgedragen aan het voorkomen van minimaal X-aantal incidenten. Zo weet je in ieder geval dat je Problem Management proces doet wat het zou moeten doen, namelijk wijzer worden van gemaakte fouten (kennis) en incidenten voorkomen.
Maar hoe weet je dat je kostbare tijd en effort gestoken wordt in het oplossen van de juiste problems? Door als eerste de problems op te pakken die de grootste impact hebben op de business van je klant, want daar doen we het uiteindelijk allemaal voor.
Een aantal mooie bijkomstigheden van goed Problem Management is dat de kwaliteit van de dienstverlening omhoog gaat, waardoor je minder incidenten te verwerken krijgt wat op zijn beurt dan weer vaak gepaard gaat met een hogere klanttevredenheid. En omdat we meer tijd over houden, kunnen we ons nóg meer richten op kwaliteit, waardoor de klanttevredenheid nog meer om hoog kan gaan.
TOT SLOT
Zoals je ziet is goed Problem Management cruciaal voor jouw beheerorganisatie en voor je klant. Door een goed Problem Management proces ga jij met jouw organisatie efficiënter om met je tijd en effectiever om met incidenten. Hierdoor zal je klant een hoger gevoel van kwaliteit ervaren wat kan resulteren in een tevredenere klant.
Bent je geïnteresseerd geraakt door mijn verhaal, neem dan contact met mij op of laat een comment achter en wellicht zitten we binnenkort te sparren over hoe we jouw Problem Management proces weer dat kunnen laten doen, waarvoor het bedoeld was.
