Incident management is in tegenstelling tot problem management de ITIL-favoriet, en wordt ook wel gezien als de brandweer van de ITIL-familie. Bijna al mijn klanten hebben een vorm van incident management ingericht: het is een proces waar je eigenlijk niet zonder kunt. In deze blogpost ga ik dieper in op hoe incident management hoort te werken, hoe je het proces moet implementeren en wat de belangrijkste valkuilen zijn.
Doel van het proces
Het doel van het incident management-proces is het zo snel mogelijk herstellen van een ongeplande serviceonderbreking naar het vooraf afgesproken niveau. Oftewel: het blussen van de brand. Het voorkomen dat de brand opnieuw ontstaat op dezelfde plek met dezelfde oorzaak is níet het doel van dit proces. Daar hebben we change management voor. Bij het ontbreken van incident management zie je in de praktijk dat er niet met de juiste prioriteit aan verstoringen wordt gewerkt. Hierdoor krijg je te maken met ontevreden klanten. Incident management voorkomt dit.
De processtappen
Zoals elk proces, heeft ook dit proces een aantal standaardstappen. Maar is dit de heilige graal om elke verstoring snel op te lossen? Nee, helaas. Er zal altijd gekeken moeten worden welk proces het beste past bij een organisatie.
Wel is het zo dat het proces van incident management zo standaard is, dat er gelukkig weinig aanpassingen nodig zullen zijn. De processtappen zijn, heel globaal, als volgt:
| Processtap | Uitleg |
| Identificeren incident | Meld het incident bij de interne ict-afdeling. Dit kan automatisch gebeuren of een eindgebruiker doet dit handmatig. |
| Categoriseren en prioriteren | Ken een categorie en een prioriteit toe aan het incident. Aan de hand van de categorie zie je of het een terugkerend incident is. De prioriteit bepaalt hoe snel een incident moet worden opgelost. |
| Analyseren | Analyseer de oorzaak van het incident. |
| Oplossen | Tijdens deze stap wordt het incident opgelost. Dit kan op drie niveaus gebeuren: - Eerste lijn: servicedesk - Tweede lijn: interne oplosgroep - Derde lijn: externe partij |
| Klanttevredenheid | Controleer na het oplossen van het incident of de oplossing werkt en of de klant tevreden is met de geleverde service. |
In de praktijk
In de praktijk begint het leeuwendeel van de incidenten met een melding bij de servicedesk. Die zal de eindgebruiker aanhoren en de melding categoriseren en prioriteren. Het kan hier bijvoorbeeld gaan om een kapot toetsenbord, maar ook om een serieuzer probleem met een van de servers. De servicedesk bepaalt de prioriteit aan de hand van de impact van het incident.
Je kunt je natuurlijk goed voorstellen dat een incident waar slechts één gebruiker last van heeft een lagere prioriteit krijgt dan een incident waardoor de hele organisatie het werk moet neerleggen. De servicedesk zal haar best doen om de melding op te lossen. Mocht dat niet gaan, dan zal zij de melding doorzetten aar een tweedelijns oplosgroep. Deze zal de melding oplossen en gereed melden. Na een verificatie van de servicedesk zal deze de melding definitief sluiten.
Shift left
Een beweging die we bij OGD al een tijd toepassen, en die je nu ook veel in de rest van de ict-wereld ziet, is shift left. Hiermee bedoelen we dat je waar mogelijk complexe ict-gerelateerde zaken verschuift van de tweedelijns oplosgroep naar de servicedesk of zelfs naar de eindgebruiker!
Denk aan:
- Een self service portal waar een eindgebruiker zijn eigen melding kan maken, in plaats van te moeten bellen naar de servicedesk;
- Een webpagina waar een eindgebruiker zijn of haar wachtwoord zelf kan resetten;
- Een webpagina met veelgestelde vragen (een FAQ) waardoor het aantal meldingen bij de servicedesk sterk kan dalen.
De valkuilen bij de implementatie
Ondanks het relatief simpele proces, is het implementeren van incident management toch complexer dan vaak gedacht. Ik zie in de praktijk vaak deze valkuilen terugkomen.
| Valkuil | Gevolg | Aanbeveling |
|---|---|---|
| Drie niveaus van prioriteit | Men kiest snel de middelste prioriteit. Hierdoor wordt het maken van onderscheid tussen verschillende incidenten onmogelijk. | Zorg voor een even aantal prioriteiten |
| Te uitgebreide categorisatie | De servicedesk weet niet meer wat te kiezen en zal al snel de categorie overig kiezen. | Gebruik de service catalogue als uitgangspunt om een goede categorisatie te kiezen. Als die niet beschikbaar is, begin je met de volgende hoofdcategorieën: 1. Kantoorapplicaties 2. Businessapplicaties 3. Client hardware 4. Netwerk hardware Vervolgens kun je subcategorieën aanmaken. |
| De servicedesk moet handmatig de juiste oplosgroep kiezen. | De servicedesk kiest de verkeerde oplosgroep waardoor meldingen de organisatie door pingpongen. | Zorg voor een heldere categorisatie zodat de servicedesk direct de juiste oplosgroep kiest. |
Kom jij andere valkuilen tegen? Laat het me weten, en ik verwerk ze in dit artikel.
Relaties met andere processen
Zoals met alle andere ITIL-processen staat incident management er niet alleen voor. In onderstaand overzicht zie je de belangrijkste relaties:
| Proces | Relatie |
|---|---|
| Asset management en configuration management | Aan de hand van de Configuration Management Database (CMDB) kun je bepalen welke diensten mogelijk hinder ondervinden van de verstoring. Als je dit goed inricht zie je ook direct welke bedrijfsprocessen en klanten worden geraakt. |
| Problem management | Geeft een structurele oplossing voor vaak voorkomende incidenten of het voorkomt dat iets een incident wordt. Hierdoor wordt de eindgebruiker minder gehinderd door ict die niet doet wat het zou moeten doen. |
| Event management | Dit proces voedt het incident management-proces met events die een verstoring zijn voor de dienstverlening. Niet elk event is een incident of kan leiden tot een incident. Dat kan bijvoorbeeld ook een melding zijn dat een server opgestart is. |
Conclusie
Het goed inrichten van je incident management-proces biedt meer voordelen dan alleen het blussen van brandjes. Tegelijkertijd zie je dat het toch iets complexer is dan slechts het inrichten van een simpel meldingssysteem.
Meer weten over ITSM?
Ik gaf een webinar over ITSM van tegenwoordig. Wat zijn de veranderingen, uitdagingen en kansen? De volgende onderwerpen komen aan bod:
- de nieuwe manier waarop steeds meer organisaties invulling geven aan ITSM;
- het bieden van waarde aan klanten en bedrijven dankzij het zelf verzorgen van ITSM;
- het belang van agile werken voor it-servicemanagement.
Luister deze webinar terug en ontvang praktische tips en een stapsgewijze aanpak voor een ijzersterke ITSM-dienstverlening.
Delen
Wat het Analytics Maturity-model kan betekenen voor incident management van jouw servicedesk
ITIL in de praktijk: problem management
