Al jaren loopt Nederland voorop met procesmatig beheer in it service management (itsm) en is er veel gemoderniseerd. Toch is er een aantal quick-wins die nog altijd nauwelijks worden behaald. De traditionele benadering van deze aspecten is zo ‘gewoon’ geworden dat we nauwelijks meer open staan voor nieuwe inzichten. In deze blog aandacht voor enkele voorbeelden van overdaad, heilige huisjes en dogma’s in procesmatigheid.
Menig organisatie kent een aparte spoed-procedure. In de ‘gewone’ procedure zijn allerlei zaken geborgd om de juiste taken in de juiste volgorde, op de juiste wijze door de juiste mensen te laten afhandelen. Met als doelstelling dat er een goede oplossing wordt geboden zonder nadelige gevolgen achteraf. Kwaliteitsborging dus.
En wat gebeurt er dan met een ‘spoedje’? Omwille van de doorlooptijd doen we allerlei concessies. We slaan taken die we kennen uit de gewone procedure over, doen het anders, doen het in andere volgorde, laten het door andere mensen uitvoeren. Met als gevolg dat er achteraf veel meer last en schade ontstaat. En wat is ermee gewonnen? Tot aan de eerste oplevering ongeveer een derde van de doorlooptijd. Maar als alle nazorg wordt meegerekend, wordt er per saldo de helft meer tijd besteed dan bij toepassing van de gewone procedure.
Wachttijd
Ervaring leert dat ongeveer twee derde van de doorlooptijd bij een ‘gewone’ procedure wachttijd is. Simpelweg doordat de mensen die het werk moeten verrichten nog meer werkzaamheden hebben en elke taak dus gepland wordt na of tussen hun andere taken. Slechts een derde van de doorlooptijd wordt werkelijk aan afhandeling besteed. Als bij een spoedgeval de normale procedure wordt gevolgd en alleen de wachttijd er tussenuit gemanaged wordt, wordt niet een derde maar twee derde van de doorlooptijd gewonnen. En vindt afhandeling van alle taken plaats met de geborgde kwaliteit. In de juiste volgorde, op de juiste wijze, door de juiste mensen, in een keer goed, zonder die kostbare extra last en nazorg.
En hoe bepalen we dan of iets een ‘spoedje’ moet zijn? Niet door iemand de taak te geven elk geval afzonderlijk te beoordelen. Als er vooraf eenduidige criteria zijn opgesteld voor impact en urgentie, en dus voor prioriteit, en de verschillende diensten zijn ingedeeld naar business criticality, dan herkent iedere betrokkene de meldingen die gaan over een als belangrijk ingeschaalde bedrijfsactiviteit met hoge prioriteit. En die moeten niet onderop de stapel gelegd worden maar bovenop. Dat kan prima vanuit een uniforme structuur en werkwijze geborgd worden, zonder dat er iemand apart moet oordelen of er een spoedprocedure moet worden toegepast.
Detectie van ‘spoedjes’ met signalering naar, en activeren van, de juiste mensen is in de meeste it-service management-tools ook betrekkelijk eenvoudig te automatiseren. Inclusief signalering naar de verantwoordelijke manager die het spoedeisend karakter toetst en bewaakt in samenwerking met de betreffende business owner, en actief de wachttijden in de procesgang weg gaat managen.
Het ‘escalatieproces’
Menig organisatie kent een escalatieproces als alternatief voor uitzonderlijke situaties waarin andere processen niet toegepast kunnen worden. Omdat processen niet werken stellen we een proces vast?
Om vooraf een aanpak te kunnen bepalen voor uitzonderingen, moeten de mogelijke uitzonderingssituaties vooraf bekend zijn. En daar gaat het mank. Uitzonderingssituaties laten zich niet voorspellen. Hoe kan de toe te passen oplossingsmethode dan voorspeld worden?
Wat er nodig is in een uitzonderingssituatie is een specifieke aanpak voor de specifieke situatie. De enige reden om te escaleren is voor de behandelaar om toestemming te krijgen een alternatieve werkwijze op maat toe te passen. Meer dan dat kan het begrip ‘escalatie’ dan ook niet inhouden.
Escalatie is niet meer dan een verzoek om af te mogen wijken van de geldende processtructuur, ingediend bij een vooraf aangewezen functionaris. Deze beslisser heeft mandaat om afwijking in een specifieke situatie toe te staan.
Escalatie gaat over niet meer dan in staat zijn een goede oplossing te bieden. Dat staat los van urgentie, impact, prioriteit en business criticality. Escalatie staat dus ook los van de vraag of er sprake is van spoed.
VIP-users
‘All people are equal, but some people are more equal than others.’ Welke waarde wordt er voor bedrijfsactiviteiten gecreëerd als er specifieke gebruikers zijn die puur vanwege hun hiërarchische positie voorrang krijgen? In de praktijk zijn het vaak ‘hogere’ functionarissen die als preferente gebruiker worden gekenmerkt. Vip-users zijn daarmee juist de mensen die over het algemeen geen directe rol hebben bij klantgerichte bedrijfsactiviteiten, niet meer dan de meest basale functionaliteiten van kantoorautomatisering gebruiken en bij een eventuele verstoring beschikken over voldoende alternatieve middelen en mogelijkheden om hun taken voort te kunnen zetten. Echt urgent kan het dus eigenlijk nooit zijn. Welke vip-user heeft er immers niet een laptop, en een tablet, en een smartphone, en vaak ook nog een secretaresse die overal bij kan? En toch krijgen meldingen van vip-users voorrang op meldingen waarbij de bediening en tevredenheid van klanten in het geding kan zijn.
Het benoemen van vip-users is daarmee net zo logisch als het reserveren van de eerste parkeerplaatsen bij de ingang voor de directie, in plaats van voor klanten.
Deze serie blogs is geschreven door Edwin Charité in samenwerking met Jeroen van de Ven.
Edwin Charité heeft 25 jaar ervaring in Service Management en is als Business Process Consultant verbonden aan Logicalis SMC in Rijswijk. Meer informatie vindt u op www.linkedin.com/in/edwincharite/ en www.logicalissmc.com.
Jeroen van de Ven heeft ruim 25 jaar ervaring in automatiseringsland. Momenteel is hij als manager MICT Technische Services werkzaam binnen het Jeroen Bosch Ziekenhuis in ‘s-Hertogenbosch. Meer info vindt u op www.linkedin.com/in/jeroen-van-de-ven-223539/ en www.jeroenboschziekenhuis.nl.
