ISO 20000 ticketsysteem: welke eisen stelt de norm?

ISO 20000-1 schrijft geen specifiek ticketsysteem voor. De norm eist wel dat je incidenten, serviceverzoeken en problemen vastlegt, opvolgt en kunt aantonen. Een ticketsysteem is in de praktijk het bewijsmiddel daarvoor. Wat je systeem moet kunnen, volgt uit de eisen voor incidentbeheer en de andere servicemanagementprocessen in clausule 8, en uit de eisen aan documentatie en bewijs in clausule 7. De norm zelf is ISO/IEC 20000-1:2018 , te koop via NEN . De beschrijving van certificering staat bij BSI .

Het ticketsysteem hoeft dus geen speciale ISO-software te zijn. Een gewone servicedesk-tool, een spreadsheet of een formulier met een logboek kan voldoen. Wat telt is dat je elk ticket kunt terugvinden, dat er een duidelijke afhandeling in staat, en dat je de cijfers eruit kunt halen die je nodig hebt voor de interne audit.

Wat moet een ticket aantonen?

Een auditor kan een paar tickets uitkiezen en van begin tot eind nalopen. Zo ziet hij of je proces werkt. Een ticket moet op die reis drie vragen beantwoorden: wat was het probleem, wie heeft het opgepakt en wat is er gedaan? Als het antwoord op één van die vragen ontbreekt, is het bewijs zwak.

De norm schrijft geen velden voor. Onderstaande set is een praktische minimumset waarmee je de afhandeling kunt aantonen.

Let op de koppeling. Een incident dat steeds terugkomt, hoort in het problemenregister. Zonder die link ziet de auditor niet dat je de oorzaak zoekt, alleen dat je de melding wegwerkt.

Welke statussen heb je nodig?

Je hebt een vaste reeks statussen nodig, zodat iedereen weet waar een ticket staat. Een eenvoudige set werkt voor de meeste organisaties:

1. Nieuw. Binnengekomen, nog niet beoordeeld.
2. In behandeling. Iemand werkt eraan.
3. Wacht op klant of leverancier. Tijd die je niet beïnvloedt. Vermeld waarop je wacht.
4. Opgelost. Dienst hersteld, maar nog niet bevestigd door de melder.
5. Gesloten. Bevestigd of na een vaste termijn zonder reactie.

Eigen statusnamen zijn prima, zolang je ze consequent gebruikt en in je procesbeschrijving vastlegt.

Voorbeeld: één ticket van begin tot eind

Een klant meldt dat zijn bestanden op de netwerkschijf niet opslaan. Zo ziet het ticket er na afhandeling uit.

De auditor ziet hier alles wat hij nodig heeft. De melding, de beoordeling, de SLA-tijd en de oplossing. De koppeling naar het probleemregister laat zien dat de oorzaak is opgepakt, zodat het niet opnieuw gebeurt.

Wat de auditor wil zien

Bij de stage 2 audit kijkt de auditor naar praktijkvoorbeelden. Hij vraagt vaak om een steekproef van tickets over de afgelopen maanden. Zorg dat je die steekproef snel kunt leveren, zonder eerst handmatig dingen te zoeken.

• Volledigheid. Elk ticket heeft de verplichte velden ingevuld, ook de gesloten.
• Tijdigheid. Je kunt laten zien dat je SLA-tijden haalt, of waarom je ze niet haalt.
• Consistentie. Dezelfde categorieën en prioriteiten worden overal gebruikt.
• Terugkoppeling. Problemen en wijzigingen zijn terug te vinden in hun eigen registers.
• Rapportage. Je kunt een overzicht maken van aantallen, doorlooptijden en terugkerende incidenten.

Veelgemaakte fouten

• Prioriteit zonder regel. Als iedere servicedeskmedewerker zelf bepaalt wat P1 is, kun je niet aantonen dat je systeem consistent is. Leg de matrix van impact en urgentie vast.
• Problemen niet koppelen. Een terugkerend incident zonder probleemrecord is een gemiste verbetering.
• Het systeem als enige bron. Als alleen één persoon weet hoe de tool werkt, is het systeem niet beheerst. Documenteer hoe je het gebruikt.
• Meerdere waarheden. Tickets in het systeem en afspraken in de mail die niet worden vastgelegd, maken je bewijs onvolledig.

Hoe kies je een ticketsysteem?

Begin bij de eisen uit deze pagina en de procesbeschrijving die je hebt, niet bij de functies van een product. Vraag een leverancier of het systeem de velden, statussen en koppelingen uit de tabel kan vastleggen. Laat ook zien hoe je een steekproef van tickets exporteert. Kan dat niet snel, dan wordt de audit lastig, ongeacht hoe mooi de tool is.

Voor een kleine organisatie is een eenvoudig systeem met een vaste velden-lijst vaak genoeg. Groeit je dienstverlening of doe je meerdere klanten, dan wordt een volwaardige servicedesk-tool sneller de betere keuze. Wat je ook kiest, leg de keuze vast in je SMS-documentatie.

Relatie met ISO 27001

Veel organisaties die ISO 20000 en ISO 27001 combineren, gebruiken hetzelfde ticketsysteem voor beveiligingsincidenten en servicestoringen. Dat is efficiënt, mits de categorieën duidelijk zijn. Een datalek heeft andere afhandelingseisen dan een trage server. Lees meer over de combinatie op ISO 20000 en ISO 27001.

Volgende stappen

Bronnen

• NEN – IT-servicemanagement met ISO/IEC 20000  – Nederlands Normalisatie-instituut
• BSI – ISO/IEC 20000-1 Service Management  – British Standards Institution