Veranderen door échte feitenkennis

Veranderen door échte feitenkennis
Deze casestudie beschrijft hoe een combinatie van process mining en enterprise engineering is gebruikt om een incidentmanagementproces bij een multinational te analyseren en aanzienlijk te verbeteren, gebaseerd op feiten.
Process mining is een krachtig middel om inzicht te krijgen in de uitvoering van bedrijfsprocessen in de praktijk. Enterprise Engineering legt de grondoorzaken achter afwijkingen in de procesuitvoering bloot. Deze casestudie beschrijft hoe ze zijn gebruikt om een incidentmanagementproces bij een multinational te analyseren en te verbeteren. Het verbeterproject wat daarop volgt, is uitgevoerd bij verschillende afdelingen van deze multinational, die om verschillende redenen anoniem wenst te blijven. We zullen deze multinational in dit artikel ‘Trace’ noemen.
Figuur 1. Procesflow incidentmanagementproces
Het doel van het incidentmanagementproces (figuur 1) is het zo snel mogelijk oplossen van (dreigende) verstoringen in de dienstverlening. Klanten hebben via internet te maken met defecten en uitval van informatiesystemen van Trace, zoals mislukte of uitgestelde opdrachtverwerking en defecte apparatuur. Ook externe partijen waar Trace mee samenwerkt hebben te maken met defecten. Ten slotte kunnen ook de interne medewerkers van Trace last hebben van storingen op de interne informatiesystemen. Het oplossen van dit soort problemen valt onder de verantwoordelijkheid van de afdeling Service. Binnen deze afdeling is een aparte groep, Service Desk genaamd, die de administratieve kant van de afhandeling van incidenten uitvoert terwijl de verschillende productafdelingen verantwoordelijk zijn voor het daadwerkelijk oplossen van de incidenten. Regelmatig moet ook de ICT-afdeling worden ingeschakeld om problemen te verhelpen. Het oplossen geschiedt uiterlijk binnen de daarvoor overeengekomen oplostijd en zo nodig via work-arounds.
 
De aanpak
In figuur 2 is de projectaanpak geschetst. De casestudie begint met de formulering van hypotheses. De opdrachtgever verwacht dat het, gegeven het grote aantal betrokken partijen, bij het oplossen van incidenten regelmatig voorkomt dat klanten niet, te laat of een verkeerde oplossing krijgen. Om de juistheid van deze hypothese te kunnen onderzoeken formuleren we een aantal vragen:
• Komt de daadwerkelijke doorlooptijd overeen met de afgesproken normtijd?
• Zijn er grondoorzaken aan te wijzen die de doorlooptijd verlengen?
• Hoeveel stappen zijn er nodig om een incident op te lossen?
• Zijn er grondoorzaken aan te wijzen waardoor het aantal stappen (on)nodig toeneemt?
 
Figuur 2. De aanpak van de casestudie
 
Gedurende het project wordt de vraagstelling verder verfijnd vanuit de inzichten uit interviews en data-analyse. Het process-mining- en het Enterprise-Engineeringtraject worden parallel en gelijktijdig opgestart en op gezette punten in de tijd vindt afstemming en validatie plaats met de opdrachtgever.
 
Gebruikte technieken process mining
De IEEE Task Force on Process Mining (2011) beschrijft in haar manifest het brede spectrum van beschikbare process-miningtechnieken. In deze casestudie gebruiken we ‘process discovery’ voor het ontdekken van procespaden en varianten op basis van een eventlog van het incidentmanagementproces. Hiermee maken we de ‘control flow’ van het incidentmanagementproces zichtbaar. Daarnaast analyseren we de proces-performance. Via benchmarking op doorlooptijd zoemen we verder in op bottlenecks die zichtbaar worden in de vorm van wachtrijen. Als derde techniek passen we een vorm van conformance-checking toe om te analyseren waar het werkelijke aantal processtappen afwijkt van het verwachte aantal. Ook kijken we hiermee naar welke procesvarianten substantieel afwijken van de beoogde procesflow (figuur 1). Tot slot gebruiken we ‘social network analysis’ om te kijken naar overdrachtsmomenten tussen partijen, teams en functionarissen. Ter ondersteuning van deze process mining gebruiken we het tool Disco van Fluxicon. Om process mining te kunnen uitvoeren, moet de dataverzameling voldoen aan de volgende minimale eisen:
• Er bestaat een uniek nummer per case (caseid) en elk event verwijst naar de bijbehorende case
• Elk event verwijst naar een activiteit (activity)
• Elk event heeft een tijdstempel (timestamp)
• Elk event die niet volledig automatisch is uitgevoerd, heeft een uitvoerder, bijvoorbeeld een persoon, rol, functie, of afdeling (performer)
De data verzamelen we uit het ondersteunende registratiesysteem van het incidentmanagementproces. Hiervoor maken we gebruik van een dataspecialist en een inhoudelijk (proces) deskundige. Vervolgens onderzoeken we de verstrekte data, dat precies één jaar overspant, met behulp van Disco. Figuur 3 geeft de zogenaamde casefrequentie weer, en toont het aantal unieke cases/incidenten die behandeld zijn en via welke paden ze zijn aangeleverd. Herhalingen zoals heropende incidenten worden in dit overzicht niet meegeteld. De praktijk wijst uit, dat er verscheidene iteraties nodig zijn om tot een goed analyseerbare dataset te komen.
Figuur 3. De data van één jaar in Disco
 
Gebruikte technieken Enterprise Engineering
Enterprise Engineering is een vakgebied dat is ontstaan uit onvrede over de resultaten van het blackbox besturen van organisaties. Met blackbox bedoelen we dat een organisatie uit een wirwar van elementen bestaat die elkaar continu beïnvloeden, waarbij we niet precies weten hoe deze beïnvloeding werkt. Om een bepaald resultaat te bereiken is het dus altijd de vraag op welke knoppen je moet drukken: het systeem is onbekend. En de ene keer werkt het wel, maar de andere keer niet. We kúnnen de werking van het systeem echter wél zichtbaar maken. Uitgangspunt van Enterprise Engineering is dat een organisatie een ‘sociaal systeem’ is, dat we op basis van een universeel patroon van hoe mensen met elkaar samenwerken kunnen ontwerpen. Dit universele patroon van samenwerking kan met behulp van diverse modellen blootgelegd worden. Dit is in het kort waar Enterprise Engineering over gaat. Voor dit verbeterproject maken we gebruik van drie basistechnieken uit Enterprise Engineering: de constructie van organisaties, elementaire constructiefouten (ECF’s) en de relatie tussen constructie en proces. Organisaties bestaan uit drie lagen van samenwerking. Voor dit artikel voert het te ver om ze alle drie te behandelen (Janssen, 2014). Voor nu is het voldoende te weten dat we de binnenste laag (de kern) de constructie van de organisatie noemen. Het fungeert ook echt als een constructie: de constructie van een auto bepaalt hoe hard deze kan rijden of hoe zuinig hij is. Ook in organisaties bepaalt de constructie de performance van de organisatie. Het helpt om een slipcursus te hebben gevolgd als je een lekke band hebt, maar beter is het om naar de garage te gaan en er een nieuwe band onder te leggen. Dit geldt ook voor organisaties: duurzame en essentiële verbeteringen vragen om ingrijpen op constructieniveau. Een constructiemodel (figuur 4) visualiseert de constructie van de organisatie.
Figuur 4. Een eenvoudig constructiemodel met twee actorrollen en een transactie
 
De primaire bouwstenen van een constructiemodel vormen de actorrollen en de transacties. Een actorrol is een unieke bundeling van verantwoordelijkheden, bevoegdheden en competenties. Een transactie is een afspraak tussen twee actorrollen. Figuur 4 toont twee actorrollen A en B en één transactie T. Iedere succesvolle transactie kent vijf volgordelijke stappen: (a) het verzoek (request), (b) de belofte (promise), (c) de uitvoering (produce), (d) het aanbod (state), en (e) de acceptatie (accept). Een eenvoudig voorbeeld van hoe dit werkt: een klant bestelt een brood bij de bakker (request), de bakker knikt en zegt dat het brood eraan komt (promise), vervolgens pakt hij het brood en doet het in een zak (produce), dan geeft de bakker het brood aan de klant (state) en de klant neemt, nadat hij heeft gecontroleerd of hij krijgt wat hij wilde hebben, het brood in ontvangst (accept). Bij de actorrollen en bij de transacties kunnen er in de praktijk ongewenste afwijkingen plaatsvinden. Zowel de afwijkingen op actorrolniveau als die op transactieniveau heten ‘Elementaire ConstructieFouten’ (ECF’s). Ze komen boven water door een gestructureerde analyse van de betrokken transacties en actorrollen. ECF’s worden in een constructiemodel gevisualiseerd (figuur 5).
 
Figuur 5. Een voorbeeld constructiemodel met ECF’s
 
In deze figuur heeft de actorrol ‘prijsvaststeller’ niet voldoende competenties om de prijs correct vast te stellen (rode ‘C’ in actorrol A7). En de actorrol ‘aanbieder offerte’ blijkt niet bevoegd om een offerte af te geven (rode ‘B’ in actorrol A5). De klantgegevens zijn niet actueel (rode gestippelde informatiebank). En ten slotte is de oplevertermijn voor de offerte onvoldoende duidelijk (rood ‘?’ in transactie T3). In totaal zijn er 22 verschillende typen ECF’s te onderkennen (Janssen, 2014). Het boek (Janssen, 2014) beschrijft ook de relatie tussen een constructie van een organisatie en een proces. We volstaan hier met een metafoor om dit aannemelijk maken: als een stuur van een auto aan de linkerkant zit, dan stap je eerst met het rechterbeen naar binnen. En als het stuur rechts zit dan zet je eerst je linkerbeen erin. Ook het besturen van de auto gaat anders wanneer het stuur links of rechts zit: je kijkt anders en je schakelt anders. Ergo, uit de constructie van de auto volgt het proces van instappen en het proces van besturen. Zo werkt het ook bij organisaties: uit de constructie volgt het proces.
 
De resultaten
In totaal ontdekten we tijdens de casestudie 35 ECF’s die voorkómen dat het incidentmanagementproces binnen Trace optimaal verloopt. Dit artikel belicht drie opvallende voorbeelden. Op basis van deze ECF’s hebben we in samenspraak met de betreffende afdeling verbeteracties geformuleerd.
 
De oplossing van een incident
Wie bepaalt wat de oplossing van een incident gaat worden (figuur 6) ? Er zijn meer dan vijf verschillende partijen c.q. afdelingen betrokken bij het bepalen van de oplossing. Dit geeft onduidelijkheid over wie nu werkelijk oplost, wat de doorlooptijd laat toenemen.
Figuur 6: De ECF met een onduidelijke oplosser van incidenten
 
Met process mining onderzoeken we of er feiten zijn die deze ECF onderbouwen (figuur 7) . We zien in deze figuur de aantallen incidenten (cases) die zijn bestudeerd. Wat opvalt is, dat als de afdeling Service het incident zelf oplost, dit significant sneller gaat (123 uur) dan wanneer er een extra partij (lees: de ICT-organisatie van Trace) bij betrokken is (229 uur). Een groot verschil in doorlooptijd dus.
Figuur 7. Aantallen incidenten over een jaar verdeeld naar zonder en met betrokkenheid van de ICT-afdeling
 
Een tweede bevinding is dat het aantal stappen in het incidentmanagementproces toeneemt, als een extra partij betrokken is (figuur 8) . Dit leidt tot de verbeteractie: “Breng partijen bij elkaar en maak heldere en haalbare afspraken over verantwoordelijkheden en communicatie”. Een uitspraak van de opdrachtgever: “Met process mining wordt snel duidelijk, in welke mate we niet voldoen aan onze interne normtijden. Uiteraard willen we weten waardoor dit wordt veroorzaakt. Enterprise Engineering verschaft ons dat inzicht.”
Figuur 8. Aantallen stappen over een jaar verdeeld naar zonder en met betrokkenheid ICT- afdeling
 
De acceptatie van een oplossing
Wie accepteert de gekozen oplossing (figuur 9) ? Er bestaat onduidelijkheid over wie nu eigenlijk de uiteindelijke oplossing accepteert. Is het de proceseigenaar, de productmanager, de Functioneel Applicatie Eigenaar, de Functioneel Applicatie Beheerder? Ze vinden allemaal, dat zij acceptant van de oplossing zijn. Maar alleen de indiener van het incident, degene die de pijn voelt, accepteert uiteindelijk de oplossing. Een ‘accept’ hoort tenslotte door dezelfde actorrol gedaan te worden als de ‘request’. Als anderen de acceptatie doen, groeit de kans dat de indiener nog steeds een probleem heeft. Dan wordt het incident heropend. Zijn hier feiten voor te vinden in de data?
Figuur 9. ECF: onduidelijke acceptant van de melding
 
Na analyse in Disco blijkt dat er 460 ‘re-opens’ zijn (figuur 10) . 460 op een totaal van 4983 cases betekent, dat zo’n 10 procent van de gesloten incidenten opnieuw wordt geopend. Het kost veel tijd om deze incidenten opnieuw te adresseren (figuur 11) . Dit leidt tot de verbeteractie: “Alleen de indiener mag de oplossing accepteren.” Een uitspraak van de opdrachtgever: “Direct concrete en tastbare resultaten gebaseerd op feitelijke analyses.”
Figuur 10. Aantal re-opens van incidenten
 
Figuur 11. Extra tijd bij re-opens van incidenten
 
Besluitvorming bij hoge prioriteit
Wie beslist bij incidenten met hoge prioriteit? Zodra een incident een prioriteit 2 heeft – dat betekent dat deze in vier uur opgelost moet zijn – dan komt een aantal managers en inhoudelijk deskundigen bijeen om gezamenlijk een beslissing te nemen over dit incident. Zo’n groep wordt een CrisisTeam (CT) genoemd.
 
Figuur 12. Onduidelijkheden in het CT
 
Een aantal ECF’s die te maken hebben met dit type incidenten (figuur 12) :
• Het is onduidelijk hoe de prioriteit van een incident wordt bepaald
• Degene die bepaalt of er al of geen CT moet komen, beschikt niet over de juiste competenties om deze beslissing te nemen
• Het is onduidelijk hoe de beslissing tot stand komt of een CT al of niet ingezet moet worden
• Er ontbreekt informatie om te bepalen wie er allemaal op de hoogte gesteld moet worden van beslissingen die het CT neemt
Met process mining achterhalen we dat de prioriteit 2-incidenten verhoudingsgewijs veel langer duren dan de incidenten die een andere prioriteit meekrijgen (figuur 13) . En dat terwijl die juist eerder opgelost zouden moeten zijn! Dat geeft feitelijk weer, hoe onduidelijk de besluitvorming is bij dit type incidenten. Dit leidt tot de verbeteracties: “Scherper formuleren en invoeren van het CT-proces” en “breng benodigde competenties op peil”.
Figuur 13. Doorlooptijden van incidenten per prioriteit
 
Tot slot
Deze casestudie laat zien dat process mining en Enterprise Engineering elkaar versterken. De eigenaar van het incidentmanagementproces binnen Trace is de in totaal 35 verbeterpunten één voor één aan het implementeren. Echte veranderingen, gebaseerd op feiten. Process mining geeft kwantitatief en op feiten gebaseerd inzicht in de uitvoering van processen. Enterprise Engineering geeft inzicht in de organisatorische constructiefouten die de afwijkingen veroorzaken in het gedrag van mensen bij de uitvoering van processen. Constructiefouten geven aanleiding tot (sub)hypotheses voor process mining. De combinatie zorgt voor inzicht in de grondoorzaken van afwijkingen en zorgt voor een betere focus bij het doelgericht verbeteren van processen.
 
Drs. Theo Janssen is organisatieadviseur bij Delta Change Consultants. E-mail: theo.janssen@deltacc.nl
Ing. Remko Tamminga is organisatieadviseur bij Delta Change Consultants. E-mail: remko.tamminga@deltacc.nl
 
Literatuur
IEEE Task Force on Process Mining (2011), Process Mining Manifest, BPM 2011 Workshops proceedings, Lecture Notes in Business Information Processing, Springer-Verlag Janssen, Theo (2014), Organisaties blijvend verbeteren - Naar effectieve organisaties met Enterprise Engineering, ISBN 9789055949151, Scriptum
 
 
 

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag