Belangrijkste punten
- Een servicecatalogus is meer dan een naslagdocument: hij bepaalt hoe diensten worden aangevraagd, geleverd en gemeten.
- Zonder servicecatalogus worden resultaten willekeurig: de dienstverlening hangt dan af van individuele technici in plaats van van consistente processen.
- De interne en de klantgerichte weergave dienen verschillende doelen en moeten op elkaar afgestemd blijven: de interne versie beschrijft de leveringsstappen en technische details, de klantgerichte versie de resultaten en doorlooptijden.
- Standaardiseer servicedefinities voor consistentie: als elke dienst een vastgelegde scope, vereiste input en een verwacht resultaat heeft kan ieder teamlid een aanvraag volgens dezelfde norm afhandelen.
- Een niet-onderhouden catalogus is een risico: verouderde vermeldingen, diensten die allang zijn uitgefaseerd en definities die niet meer overeenkomen met de werkelijke levering ondermijnen de gewenste consistentie.
Veel IT-teams en zelfs MSP’s zien een servicecatalogus als een opsomming van wat ze aanbieden, aangevuld met wat basisdocumentatie. Dat beeld klopt niet helemaal, want een catalogus doet meer dan dat. Een goed opgezette catalogus legt vast hoe IT-diensten zijn opgebouwd, worden aangevraagd, geleverd en ondersteund. Zo blijft die structuur gelijk voor elke klant en elke technicus binnen de organisatie.
Voor MSP’s is de servicecatalogus die IT-teams gebruiken tegelijk een naslagwerk en een sturingsmiddel dat de dienstverlening consistent houdt en het resultaat binnen de verwachtingen van de klant. Dit artikel laat zien hoe u er een bouwt die ook echt zo werkt.
Een IT-servicecatalogus opzetten waar MSP’s iets aan hebben
Goed beheer van een servicecatalogus begint bij het besef dat de catalogus de structuur is die bepaalt hoe diensten worden geleverd, gevolgd en in de loop van de tijd verbeterd.
Waarom is een servicecatalogus belangrijk voor de dienstverlening?
Zonder een gestructureerde IT-servicecatalogus leunt de dienstverlening zwaar op de expertise van individuele technici. Dat kan even goed gaan, maar op de lange termijn is het niet houdbaar en na verloop van tijd ontstaan er gaten.
Dit zijn een paar veelvoorkomende problemen die opduiken zonder gestructureerde catalogus:
- Inconsistente dienstverlening: dezelfde aanvraag wordt anders afgehandeld, afhankelijk van wie hem oppakt. Klanten merken dat verschil, ook als technici het zelf niet zien.
- Onduidelijke scope van aanvragen: zonder afgebakende diensten komen aanvragen vaag binnen en is er heen-en-weergepraat nodig voordat het werk kan beginnen. Dat kost tijd en zorgt aan beide kanten voor frustratie.
- Uiteenlopende verwachtingen over de levering: als technici verschillende ideeën hebben over wanneer dezelfde dienst “af” is wordt de kwaliteit onvoorspelbaar en moeilijk te sturen.
- Lastige rapportage en meting: als diensten niet consistent zijn gedefinieerd is er geen betrouwbare nulmeting. Prestaties volgen of terugkerende problemen signaleren wordt dan gokwerk.
Een catalogus lost dit op door elke dienst een vaste structuur te geven die iedereen in het team kan volgen, ongeacht ervaringsniveau of bekendheid met een bepaalde klant.
Het verschil tussen een interne en een klantgerichte IT-servicecatalogus
Een servicecatalogus die IT-teams voor intern gebruik opbouwen ziet er heel anders uit dan de catalogus waar klanten mee te maken krijgen. De inhoud is in de kern hetzelfde, maar de opzet moet aansluiten bij een ander publiek: de klant of het interne team.
De interne catalogus is gemaakt voor technici en operationele teams. Die bevat:
- Hoe diensten worden geleverd: stap-voor-stapprocessen, afhankelijkheden en workflows die technici volgen om elke aanvraag consistent af te handelen.
- Technische details: systeemvereisten, escalatiepaden en alle tools of scripts die bij de levering komen kijken.
- Operationele ondersteuning: alles wat een technicus nodig heeft om de dienst uit te voeren zonder te improviseren of iemand anders te moeten vragen hoe het ook alweer zit.
De klantgerichte catalogus is gemaakt voor de mensen die diensten aanvragen. Die bevat:
- Welke diensten beschikbaar zijn: beschrijvingen in gewone taal die uitleggen wat elke dienst doet, zonder technische details.
- Verwachte resultaten en doorlooptijden: wat de klant krijgt, wanneer hij het kan verwachten en welke SLA’s van toepassing zijn.
- Hoe een aanvraag wordt ingediend: een eenvoudig, helder proces waarvoor geen IT-kennis nodig is.
Het is cruciaal dat beide catalogi op elkaar zijn afgestemd en dat ook blijven. Verandert een dienst intern, dan moet de klantgerichte vermelding daar ook op worden aangepast. Lopen ze uiteen dan ontstaat er verwarring en verdwijnt juist de consistentie die de catalogus moet afdwingen.
Definieer diensten als gestandaardiseerde eenheden
Elke dienst in de IT-servicecatalogus moet duidelijk vastleggen hoe de dienstverlening verloopt.
Een gestandaardiseerde servicedefinitie bevat:
- Naam en doel van de dienst: een omschrijving in gewone taal van wat de dienst is en wat hij voor de aanvrager doet.
- Scope en beperkingen: wat wel en wat niet onder de dienst valt.
- Vereiste input en afhankelijkheden: de informatie of randvoorwaarden die aanwezig moeten zijn voordat de dienst kan worden geleverd.
- Verwachte resultaten: wat de aanvrager krijgt zodra de dienst is afgerond.
- Leveringsproces: de stappen die technici volgen om de dienst consistent uit te voeren.
Als elke dienst zo is gedefinieerd, kan iedereen in het team een aanvraag oppakken en volgens dezelfde norm afronden.
💡Let op: klantgerichte definities moeten in gewone taal zijn opgesteld, zodat iedereen ze begrijpt. De interne versie mag wel de technische details bevatten die technici nodig hebben.
Gebruik de catalogus om variatie te beperken
Variatie betekent in deze context dat verschillende technici dezelfde dienst op verschillende manieren leveren, met verschillende resultaten voor dezelfde aanvraag. Goed beheer van de servicecatalogus is een van de meest directe manieren om dat op te lossen.
Standaardisatie helpt door:
- Voorspelbare dienstverlening: klanten krijgen hetzelfde resultaat, ongeacht welke technicus de aanvraag behandelt.
- Minder afhankelijkheid van persoonlijke kennis: met vastgelegde processen hangt de levering niet af van één iemand die weet hoe iets moet.
- Betere onboarding en training: nieuwe technici kunnen vanaf dag één de catalogusdefinities volgen, zonder voor elk type dienst met een ervaren collega mee te hoeven lopen.
- Gelijkgestemde verwachtingen tussen teams: iedereen werkt vanuit dezelfde definitie van wat een dienst omvat en wanneer die af is.
Bij MSP’s die meerdere klanten beheren stapelt variatie zich snel op. Een catalogus houdt de levering consistent terwijl het team en het klantenbestand groeien.
Koppel de catalogus aan uw operationele workflows
De catalogus hoort onderdeel te zijn van uw dagelijkse werk en uw workflows. Is dat niet zo dan blijft het slechts een naslagwerk. Door hem te koppelen aan de dienstverleningsprocessen, wordt hij een actieve sturingslaag.
Integratiepunten die u in de catalogus kunt inbouwen:
- Workflows in het ticketsysteem: elke catalogusvermelding is rechtstreeks gekoppeld aan het ticketsysteem, zodat aanvragen automatisch tickets aanmaken in de juiste wachtrij met de juiste prioriteit.
- Aanvraag- en goedkeuringsprocessen: leg vast wie welke dienst mag aanvragen, welke informatie vooraf nodig is en of er goedkeuring vereist is voordat het werk start.
- Automatisering in kaart brengen: bepaal welke diensten herhaalbare stappen bevatten die u kunt automatiseren, zodat er minder handwerk nodig is en de levering sneller gaat.
- Meetwaarden voor rapportage: stem catalogusvermeldingen af op de metrics waarmee u prestaties volgt, zodat aanvraagvolume, oplostijd en SLA-compliance per dienst meetbaar worden.
Zodra de IT-servicecatalogus gekoppeld is aan de workflows van uw team, wordt hij onderdeel van het systeem.
Richt governance en lifecycle-beheer in
Een catalogus die niet actief wordt onderhouden wordt een risico. Staan er bijvoorbeeld verouderde servicedefinities, uitgefaseerde diensten en vermeldingen in die niet meer weergeven hoe er wordt gewerkt, dan ondermijnt dat juist de consistentie die de catalogus moet bieden.
Governance-afspraken om de catalogus accuraat te houden:
- Regelmatige review van servicedefinities: plan periodieke controles om te bevestigen dat elke vermelding nog klopt met de manier waarop de dienst daadwerkelijk wordt geleverd.
- Updates bij nieuwe tools of processen: verandert de manier van leveren dan moet de catalogus meeveranderen om accuraat te blijven.
- Verwijderen van verouderde diensten: uitgefaseerde of beëindigde diensten haalt u er snel uit om verwarring en verkeerd gerichte aanvragen te voorkomen.
- Versiebeheer en wijzigingsregistratie: houd bij wat er is gewijzigd, wanneer en waarom, zodat er een audittrail is en u kunt terugdraaien als er iets misgaat.
Governance beklijft pas als elke catalogusvermelding een duidelijke eigenaar heeft. Is iemand verantwoordelijk voor het actueel houden van een servicedefinitie dan wordt die ook onderhouden. Is dat niet zo dan gaat de kwaliteit langzaam achteruit.
Veelgemaakte fouten met servicecatalogi en hoe u ze voorkomt
Een uniforme template voor de IT-servicecatalogus voorkomt inconsistentie vanaf het begin, maar de structuur is niet beter dan de gewoonten die eromheen ontstaan. Dit zijn de fouten die MSP’s het vaakst maken met hun servicecatalogus en hoe u ze oplost.
- De catalogus behandelen als statische documentatie: teams bouwen de catalogus één keer en onderhouden hem daarna niet meer. Wijs per servicevermelding een eigenaar aan en plan regelmatige reviews om hem actueel te houden.
- Te veel technische details in klantgerichte vermeldingen: klanten hoeven het leveringsproces niet te kennen, alleen wat ze krijgen en wanneer. Houd klantgerichte vermeldingen gericht op het resultaat en vrij van interne vaktaal.
- Interne en externe versies niet op elkaar afstemmen: verandert de interne catalogus wel en de klantgerichte versie niet dan krijgen klanten onjuiste informatie. Elke wijziging in de manier waarop een dienst wordt geleverd hoort een review van de bijbehorende klantgerichte vermelding in gang te zetten.
- Diensten niet bijwerken als de omgeving verandert: tools worden vervangen, processen herzien en diensten ontwikkelen zich verder. Catalogusvermeldingen die beschrijven hoe het vroeger werkte zorgen voor verwarring bij technici én klanten.
De meeste van deze problemen hebben dezelfde oorzaak: de catalogus wordt gezien als een eenmalig project in plaats van als een doorlopende operationele bron.
Een servicecatalogus bouwen die de dienstverlening verbetert
Een servicecatalogus is net zo nuttig als de structuur en gewoonten die eromheen zijn opgebouwd. Diensten helder definiëren, de interne en klantgerichte weergave scheiden, de catalogus koppelen aan het ticketsysteem en de rapportage en hem onderhouden: dat maakt van een naslagdocument iets dat daadwerkelijk bepaalt hoe het werk wordt gedaan.
MSP’s die de catalogus zien als operationeel instrument in plaats van als eenmalig project leveren consistenter, hebben een snellere onboarding en maken minder vaak mee dat de servicekwaliteit afhangt van wie de aanvraag toevallig oppakt.
Quick-start guide
Zo bouwt u een effectieve servicecatalogus in NinjaOne:
- Definieer uw diensten met tickettypes voor supportaanvragen
- Documenteer elke dienst in de Knowledge base, inclusief vereisten en procedures
- Maak checklists voor de workflows van uw dienstverlening om consistentie te waarborgen
- Stel SLA’s in om serviceniveaus en reactietijden vast te leggen
- Gebruik automatisering om supportaanvragen efficiënt te routeren en te beheren
- Volg de compliance via ticketbeheer en afgeronde checklists
Gerelateerde onderwerpen:
