Når data skal analyseres i process mining, bliver nogle overraskede over hvor nemt det er at arbejde med værktøjet. Efter et stykke tid, hvor vi har arbejdet sammen omkring analyser i process mining, bliver de ofte overraskede over hvor mange faldgruber, der er i data grundlaget som kan lede til forkerte konklusioner, der ikke er understøttelse for.
Følgende 5 ting ser jeg som nogle af de typiske faldgruber, når ITIL data skal analyseres og der skal findes påviselige årsager.
- Ikke-komplette sager medtages i analysen
- Ekstreme data forplumrer billedet
- Weekender og helligdage medtages i lead time
- Start og stop aktiviteter ikke korrekt definerede
- Ekstern vente-status forstyrrer analysen
Hver af ovenstående 5 faldgruber er beskrevet nærmere nedenfor:
Ad 1) Ikke-komplette sager medtages i analysen
Dette er egentligt en klassisk faldgrube i alle process mining analyser, men også i manuel data analyse. Det handler om at sager der ikke er komplette medtages i analyser. Da de ikke er komplette vil de ikke medgå i deres fulde længde og dermed ødelægge det statistiske grundlag. Som det ses nedenfor vil Case3 og Case4 se ud som om de er kortere end de egentlig er, da ikke alle deres aktivitetstrin er udlæst i data grundlaget.
Ad 2) Ekstreme data forplumrer billedet
Nogengange er der sager der tager ekstremt lang tid. Ofte er de sager oprettet fejlagtigt eller ekstremt lange af en anden årsag. Under alle omstændigheder vil de ødelægge billedet af den gennemsnitlige løsningstid (her er medianen en mere pålidelig rettesnor). De ekstreme sager, der ikke anses for at være reelle sager, bør filtreres ud af data grundlaget inden analysen starter.
Ad 3) Weekender og helligdage medtages i lead time
Den gennemsnitlige løsningstid kan blive misvisende, hvis sagerne går henover weekender, helligdage og ferier. I nedenstående eksempel er løsningstiden 7 dage, men kun 5 arbejdsdage. Man skal gøre sig klart, hvad man gerne vil måle på og tilpasse data grundlaget til dette.
Ad 4) Start og stop aktiviteter ikke korrekt definerede
Det sker at systemer selv sætter aktivitetstrin automatisk. For eksempel automatisk sætter et aktivitetstrin når en sag modtages eller sætter et aktivitetstrin 3 dage efter en sag er afsluttet.
Det skal overvejes om disse trin skal medtages i beregningen af den samlede løsningstid. Ligesom det skal overvejes om sådanne aktivitetstrin indgår i de forskellige KPIer som der måles på.
Ad 5) Ekstern vente-status forstyrrer analysen
Hvis der bruges en status hvor der afventes eksterne aktører at gøre noget, skal man overveje om dette tidsforbrug skal indgå i beregningen af den gennemsnitlige løsningstid. Alt afhængig af hvad man gerne vil måle på.
Man bør "trimme" sagerne, så de kun indeholder de aktivitetstrin og lead tider, der skal indgå i beregningen af løsningstid.