Service Management is de manier om een IT afdeling te structureren en te organiseren. Tot zover niets nieuws! We hebben allemaal de ITIL-boeken gelezen die boordevol staan met mooie theorieën over hoe processen eruit zouden moeten zien. Regelmatig komen er nieuwe versies op de markt. Ook zie je dat er nieuwe werkwijzen en methodieken bij komen om de boel nog gestroomlijnder te krijgen. Denk hierbij aan Lean IT, DevOps, Kanban, ISM en USM. Als het om theorie gaat komen we niets te kort!
Eerst even dit: theorie en praktijk.
Wat mij altijd heeft geboeid is hoe theorie en praktijk zich tot elkaar verhouden. Dat maakt mij dan ook tot de typische Hbo’er. Theorie waar je niets mee kan in het dagelijks leven, heb je niets aan. Ik chargeer een beetje natuurlijk. Maar als business consultant heb ik in de loop der jaren tientallen klanten geholpen met hun ambities om hun service organisaties te verbeteren. Wat mij opviel is hoe weinig mensen eigenlijk deze mooie theorieën weten te vertalen naar de praktijk. Want het blijkt dat toch veel van dit soort verbetertrajecten nooit de beoogde doelen halen. Of als ze het beoogde doel halen, zakt na een aantal maanden toch weer alles in elkaar en ben je terug bij af. De vraag die mij dus fascineerde is: hoe kunnen we standaardiseren. Dat wil zeggen: langdurig verbeteringen krijgen. Duurzaam om maar een modern woord te gebruiken.
Tip 1: Service Management is geen wiskunde.
Als je met procesverbetering aan de slag gaat is een eerste logische stap om de procedures op te gaan stellen. Je haalt uit bijvoorbeeld een ITIL boekje het incident proces, werkt deze verder uit met de verbijzonderingen voor je eigen situatie en koppelt er de uitvoerende rollen aan. Hier wordt in het algemeen een hoop tijd aan besteed. Als er een intern projectteam is geformeerd dat zich mag buigen over de nieuwe procedure, kan men in eindeloze discussies terecht komen over volgordelijkheid, details en met name uitzonderingen. We proberen een alles-in-eenformule te vinden zodat de medewerkers die het moeten uitvoeren aan de slag kunnen zonder procedurele fouten te maken. De vraag is of dit een goed uitgangspunt is. Ja, we willen een eenduidige werkwijze, maar we willen in onze vastlegging de medewerkers stimuleren om hun intelligentie in te zetten. De procedure zou dus meer een goede richtlijn moeten zijn dan een wiskundig correct document die alle situaties afdekt.
Tip 2: The proof of the pudding is in the eating.
Stel je voor dat je een nieuwe collega op de servicedesk of in je beheerteam krijgt. Hoe wordt deze persoon bij jullie ingewerkt? Meestal is het zo dat de nieuwe collega op zijn eerste dag gekoppeld wordt aan een collega die al een tijd voor jullie organisatie werkt. Hij gaat alle belangrijke informatie overdragen aan de nieuwe collega. Er zijn vaak wel “mooie” werkinstructies beschikbaar, maar die zijn vaak niet goed bijgehouden en te veel gericht op de tool. Dat soort documenten vertellen je dan hoe je bijvoorbeeld een nieuwe ticket aan moet maken. Wat er niet in staat in welke informatie je op welk moment zou moeten verzamelen. Het is dus te veel gericht op de functionaliteiten van je ITSM tool en niet op de gewenste werkwijze. Een goede werkinstructie is in mijn beleving de procedure (de blauwdruk van je organisatie) verrijkt met hoe je dat in jullie ITSM tool moet doen. Uiteindelijk zou je één document (per proces) willen voor je medewerkers waarin beschreven staat hoe ze moeten werken. De beste toets of dit gelukt is blijkt uit als je een nieuwe medewerker krijgt en deze persoon kan 80 – 90% van hoe hij dient te werken uit deze documentatie halen. Dan is je doel behaald.
Tip 3: Als je klaar bent, begint het standaardiseren pas.
De meeste trajecten voor het standaardiseren van Service Management hebben een projectvorm. Dat betekent dat er een duidelijk begin en einde is gedefinieerd voor de verbeterslag. Een belangrijk deel van de beoogde verandering zijn in de vorm van fysieke producten als nieuwe beschrijvingen en documentatie en een versie inrichting in de ITSM tool. Dat is meestal ook wat er in het projectplan wordt opgenomen, een lijst met fysieke project deliverables die we kunnen afvinken. In de IT wereld zijn we gewend om te denken in lijstjes en bullets. Met technische projecten klopt dat ook prima. Als er een nieuwe mailomgeving opgeleverd moet worden kunnen we een breakdown maken van onze project deliverables en een stappenplan bedenken voor de migraties van de gebruikers van de oude omgeving naar de nieuwe. Als alle gebruikers over zijn is ons project met nog wat nazorg klaar. Op naar de volgende! Als het om veranderingen in een werkwijze gaat, werkt dit heel anders. We hebben te maken met menselijk gedrag dat soms al jaren in ingesleten. Mensen zijn gewoonte dieren die, ook al denken we vaak anders over onszelf, niet makkelijk willen veranderen. We doen het niet voor niets al jaren zo is vaak de stelling. Als we onze medewerkers toch anders willen laten werken, bewuster elke stap willen laten uitvoeren, moeten we ons gaan verdiepen in hoe menselijk gedrag te veranderen is. Dit blogartikel is beperkt om alles over te delen, maar je zult het moeten zoeken in de hoek van psychologie. Belangrijk is om een persoon binnen je organisatie te vinden die zich hier goed bewust van is en hem een prominente rol binnen het project en daarna te geven.
Tot slot.
Samenvattend is standaardiseren van Service Management nooit klaar. Het lastige is dat een organisatie grip wil krijgen op de kwaliteit van de dienstverlening, waarbij een individuele medewerker niet voorop staat. Dat betekent dat je soms het gevoel als medewerker hebt dat je iets aan het doen bent waar je zelf niets aan hebt. Het is in het totaalplaatje alleen wel belangrijk omdat je waarschijnlijk een collega hier enorm mee geholpen hebt. Daarom zou ik willen afsluiten met de mooie one-liner “Standaardiseren is voor niemand het allerbeste, maar voor iedereen beter”.
Wil je meer weten over efficiënt werken? Ontdek onze werkwijze!
Deel je eigen tips.
Heb je zelf nog ideeën en tips om een succes te maken van je ITSM-implementatie en de bijbehorende software? Laat ze achter in de reacties hieronder. Ik ben erg benieuwd.