ITSM voor het mkb: professioneel zonder groot budget

ITSM klinkt als iets voor organisaties met een IT-afdeling van veertig man en een procesarchitect op de loonlijst. Dat is jammer, want juist organisaties zónder eigen IT-afdeling hebben er het meeste aan. Zij kunnen zich namelijk het minst permitteren dat dingen zoekraken.

Het misverstand zit in de aanpak. ITSM wordt vaak gepresenteerd als een compleet model — ITIL heeft vierendertig praktijken — en dan haakt iedereen begrijpelijkerwijs af. Terwijl je met drie processen al tachtig procent van de winst binnenhaalt.

Wat je met drie processen al oplost

1. Incidentbeheer: zorg dat niets zoekraakt

Het klinkt bijna te simpel, maar de grootste winst in kleine organisaties zit in het feit dat vragen ergens binnenkomen waar ze niet zoekraken. Niet in een persoonlijke mailbox, niet in een appje, niet in de wandelgang.

Wat je minimaal nodig hebt: één ingang, een eigenaar per melding, een status die klopt, en een melder die weet waar zijn vraag staat. Meer niet. Categorieën, prioriteitenmatrices en escalatiepaden komen later — en als je ze te vroeg invoert, worden ze vooral genegeerd.

De valkuil is de categorieënboom. Vrijwel elke organisatie begint met te veel categorieën, waarna niemand de juiste kan vinden en alles onder “overig” belandt. Begin met vijf tot acht, en breid pas uit als je uit je eigen cijfers ziet dat het nodig is.

2. Wijzigingsbeheer: weet wat er is veranderd

Als er iets stukgaat, is de eerste vraag altijd: wat is er veranderd? Zonder wijzigingsregistratie is dat giswerk, en giswerk kost uren.

Voor een kleine organisatie hoeft dat geen CAB met wekelijkse vergadering te zijn. Het minimum: elke wijziging aan een systeem wordt vastgelegd, met wie, wanneer en waarom — en met een regel voor wat er niet zonder overleg mag. Dat is het. Een wijzigingsproces dat zwaarder is dan de wijzigingen zelf, wordt omzeild, en dan ben je slechter af dan zonder.

3. Kennisbeheer: schrijf op wat je twee keer uitlegt

Dit is het proces dat het vaakst wordt overgeslagen en het meest oplevert. De regel is eenvoudig: leg je iets voor de tweede keer uit, schrijf het dan op. Eerst voor je collega's, later voor gebruikers zelf.

In een kleine organisatie is dit bovendien je enige verdediging tegen het vertrek van de persoon die alles weet. Zolang kennis alleen in hoofden zit, is elke vakantie een risico.

Wat je bewust nog niet doet

Even belangrijk is wat je laat liggen tot je er echt aan toe bent:

• Een volledige CMDB. Een configuratiedatabase die niet actueel wordt gehouden, is schadelijker dan geen CMDB, want mensen vertrouwen erop. Begin met de assets die er werkelijk toe doen — laptops, telefoons, licenties — en breid pas uit als je het bijhouden geautomatiseerd hebt.
• Problembeheer als apart proces. Onder een bepaald volume herken je terugkerende problemen prima zonder eigen procedure. Voer het in als je merkt dat dezelfde storing voor de derde keer terugkomt en niemand ernaar kijkt.
• Een uitgebreide SLA-structuur. Verschillende doorlooptijden per prioriteit per categorie per klantgroep klinkt professioneel en is in de praktijk vooral werk. Begin met één norm en kijk of je die haalt.

Waar de winst zit: automatisering

Zodra die drie processen lopen, ligt de grootste opbrengst niet in méér proces maar in minder handwerk. Moderne ITSM-tools kunnen veel meer dan de meeste kleine organisaties gebruiken.

In TOPdesk automatiseer je binnen de tool zelf met Gebeurtenissen en Acties: een melding die automatisch naar de juiste behandelaar gaat op basis van de categorie, een bevestiging aan de melder, een escalatie als een SLA dreigt te verlopen, een status die vanzelf doorschuift. Dat scheelt geen minuten maar uren per week, en het is werk dat je één keer inricht.

Wat daarbuiten valt, doe je via de API. De koppeling die in kleine organisaties het meest oplevert is die met het HR-systeem: in-, door- en uitstroom van medewerkers die automatisch de juiste meldingen en taken aanmaakt. Een nieuwe medewerker betekent een laptop, een account, een telefoon en een toegangspas — en dat zijn vier dingen die je niet handmatig wilt aanmaken en al helemaal niet handmatig wilt intrekken.

De volgorde

Als je vandaag zou beginnen, zou de volgorde zijn:

1. Eén ingang voor alle vragen, met een eigenaar per melding.
2. Vijf tot acht categorieën, niet meer.
3. Wijzigingen vastleggen: wie, wanneer, waarom.
4. Opschrijven wat je twee keer uitlegt.
5. Na drie maanden: kijken wat de cijfers zeggen en pas dán verfijnen.
6. Automatiseren wat elke week terugkomt.

Dat is geen ITIL-implementatie. Het is een half jaar werk waarvan het meeste in de eerste maand gebeurt, en het levert meer op dan een model dat op papier compleet is en in de praktijk niet gevolgd wordt.

Meten of het werkt

Drie cijfers zijn genoeg om te weten of het de goede kant op gaat: hoeveel meldingen er openstaan en of dat aantal stijgt of daalt, hoe lang meldingen gemiddeld open staan, en hoeveel meldingen worden heropend. Dat laatste getal is de meest onderschatte: een heropende melding betekent dat iemand hem te vroeg heeft gesloten, en dat is precies het gedrag dat je krijgt als je alleen op doorlooptijd stuurt.