Case Story - Copenhagen Airports A/S

 

Efter gennemførsel af en Process Mining opgave for Københavns Lufthavne A/S har jeg udarbejdet en case story i samarbejde med Claudia Billing fra Københavns Lufthavne A/S.

 

Casen kan downloades nederst i dette blog indlæg, hvor opgaven gennemgåes.

Bemærk: Fortrolige data gengives ikke. Diagrammer og analyser er anonymiseret eller ikke angivet i detaljer, for at sikre fortrolighed omkring data.

 

 

 

 

 

 

Proces Analyse af baggage fabrik performance

 

Opgaven omhandlede analyse af forretningsprocessen omkring håndtering af baggage fra det tidspunkt hvor der er kendskab til et styk baggage og til det er på plads i et fly - det vil sige hele håndteringen af at modtage et styk baggage, få det transporteret, sorteret gennem baggage fabrikken og få det med det rigtige fly.

 

En baggages rejse gennem lufthavnen starter med en stregkode label, som påsættes baggagen (en såkaldt BagTag). Denne stregkode label scannes på forskellige steder i rejsen fra check-in til den er ombord på et fly.

 

 

 

 

Hver gang en stregkode label scannes, dannes der samtidig en record i baggage systemet. Det er disse data, der blev trukket ud af baggage systemet for at indgå i en Process Mining opgave. Data'ene var godt struktureret og indeholdt events for hele processen (end-to-end processen). Selve udtrækket af data var hurtigt gjort. Det var et spørgsmål om få timer.

 

 

 

Indlæsning af data til Process Mining analyse

 

Data blev modtaget som en flad komma separeret fil (CSV format) og kunne umiddelbart indlæses i et Process Mining værktøj, for nærmere analyse.

 

 

 

Generering af proces overblik

 

Efter indlæsning blev der automatisk genereret et proces diagram over processen, som kan ses nedenfor. Det er en såkaldt spaghetti process, med utroligt mange proces trin kombinationer.

 

 

 

 

 

 

At processen var en såkaldt spaghetti process, var ikke så overraskende. Det ses ofte i processer, hvor der er høj grad af automatiseret logistik. I denne her proces er baggage sortering og transport af baggage gennem lufthavnen stort set fuldt automatiseret. Det betyder, at der kan være mange måder at transportere et styk baggage fra A til B, hvor vejene hver især kan være lige gode og performe lige godt. Om den automatiserede sortering og transport nu også var effektiv og performede godt, var et af de elementer, der kunne analyseres og gives svar på i denne opgave.

 

For at få et overblik over den reelle baggage forretningsproces i et billede, der er menneskeligt forståligt, genererede vi et proces overblik over de mest hyppige proces forløb. Det gav et mere håndterbart proces diagram, som det kan ses nedenfor.

 

 

 

 

At have et proces overblik er interessant. Dels fordi det giver et grundlag for at have kendskab til hvordan processen er i relation til integration med andre forretningsprocesser og integration til andre IT systemer - men også for at kunne analysere på designet af processen og se om der umiddelbart er uhensigtsmæssigheder.

 

Ofte, når der kigges på proces designet (altså processens udseende) ledes der efter uhensigtsmæssige proces mønstre såsom flaskehalse i designet, for meget sekventialitet i proces flowet, for mange rolleskift, for mange transaktionspunkter, ikke-værdiskabende procestrin etc.

 

I ovenstående procesdiagram fik vi lynhurtigt og automatisk genereret et overblik over hele processen. Proces designet kunne derefter skraks blive underlagt en vurdering af, om proces designet havde uhensigtsmæssigheder.

 

En fordel ved det automatisk genererede proces diagram er, at det er baseret på fakta - nemlig de tusindvis af baggage proces instancer, der er udlæst fra baggage systemet. En anden fordel er, at proces diagrammet kan vises og analyseres i et utal af detalje grader. Ovenstående proces diagram er her vist med ganske få oplysninger, udover den typiske hovedvej gennem processet. Det gør det let at få et godt overblik over processen.

 

 

 Iteration 1

 

Hvordan performer vi? - formulering af spørgsmål der skal analyseres

 

Til analyse at 1. iteration blev der lagt vægt på følgende områder:

 

1. Hvordan ser processen ud?
2. Er eventuelle flaskehalse problematikker centreret omkring båndene og cirkulationen i baggage fabrikken eller omkring de omkring liggende processer?
3. Overholdes KPIerne for processen?
4.  Er det statistisk belæg for årsag/virkninger 

 

  

 

Resultater fra Iteration 1

 

Den første iteration blev kørt med afsæt i det indledende møde og havde til formål at skabe et overblik over processen, checke for flaskehalse, undersøge overholdelse af KPIer samt lede efter andre faktorer der kunne føres et statistisk belæg for.

 

For at komme videre med analysen var det nødvendigt at filtrere data så analyse resultaterne ville give mening. Først og fremmest blev ikke-komplette cases sorteret fra, men ligeså vigtigt blev cases der indeholdt elementer forstyrrende for de enkelte analyser sorteret fra.

For eksempel, i forbindelse med performance analyse og KPI analyse, blev cases med proces trin til EBS lokationen sorteret fra. EBS er Early Baggage Storage og er et venteområde fx for baggage, der er checket ind for tidligt og ikke kan udsorteres endnu - disse cases ville naturligvis ødelægge en end-to-end KPI performance analyse.

Et andet eksempel er frasortering af cases, der kom fra Transit, da disse også ville give et urealistisk af en end-to-end KPI performance analyse. 

 

Efter 1. iteration blev der afholdt en workshop hvor følgende resultater blev gennemgået:

 

1. Proces diagram blev præsenteret og gennemgået. Overblik over processen blev produceret som beskrevet ovenfor (de to proces diagrammer tidligere i dette indlæg). Det var interessant at se den faktiske proces baseret på faktuelle data.
2. Det blev vist, at de flaskehalse der opstod stort set aldrig forekom når først et styk baggage cirkulerede rundt i baggage fabrikken, men snarere grundet en langsom reaktionstid fra ændringer fra Airline til baggagen igen cirkulerede rundt i baggage fabrikken. Det kunne altså konkluderes, at optimeringen og cirkulationen i baggage fabrikken fungerede tilfredsstillende. Som det illustreres på nedenstående diagram (her vist i overbliks versionen) er flaskehalse centreret i modtagelse og ændringer af beskeder fra airline omkring baggagen (Baggage System Message).

 

 

 

 

3.  Performance KPI'erne blev undersøgt og der hvor der var afvigelser, kunne såvel performance som årsager belyses.

4. Flere statistiske årsags/virkningsforhold kunne belyses. For eksempel kunne det påvises, at weekender havde flere cirkulationer af baggage end de andre dage. Det kunne også belyses om der var bestemte flyselskaber, der klarede sig anderledes end andre. Et andet eksempel er overblik over hvor ofte og hvor mange redirect cirkulationer, der blev foretaget og hvilke faktorer der drev dette forhold - eksempel på redirects kan ses i diagrammet nedenfor.

 

 

  

 

 

 

 

Iteration 2

  

Processen fra et andet perspektiv

 

 

Før igangsætning af iteration 2 blev det aftalt, at der skulle fokuseres på performance, ikke alene mellem proces trinnene, men også  mellem lokationerne for de enkelte proces trin.

For at opnå det perspektiv blev data loaded ind igen, men denne gang hvor hvert proces trin var en sammensætning af processens aktivitet + lokationen, hvor den blev udført.

 

 

Til analyse af 2. iteration blev der lagt vægt på følgende områder:

 

1. Hvordan ser processen ud fra et andet perspektiv?
2. Hvilke interessante gennemsnits transport tider kan vi se?
3. Hvor længe ligger baggage i gennemsnit på EBS?

 

  

Resultater fra Iteration 2

 

1. Processen set fra et andet perspektiv proces aktivitet + lokation blev genereret og kan ses på nedenstående diagram. 
2. Ved at se på processen fra et andet perspektiv blev det muligt straks at se andre former for gennemsnitstider. For eksempel blev det muligt at se antal minutter i gennemsnit, der går fra et styk baggage er checket ind, til den ses for første gang i baggage fabrik BF3 (se orange og grøn pil på nedenstående diagram). Endelig kunne det ses at cirkulationen af baggage gik hurtigt og at sorteringen virker (se blå pil på nedenstående diagram).
3. En interessant måling - hvor længe baggage i gennemsnit ligger på EBS'en - kunne straks ses på den gennemsnitlige tid fra proces trinnet "Discharge-Verification" @ EBS til Scanned @ Scanner (gul pil i nedenstående diagram).

 

 

 

 

 

 

Københavns Lufthavne A/S fik afdækket de ønskede proces insights på 2 iterationer og fik mulighed for at sammenligne proces performance for specielle dage (fx med maskin nedbrud) op i mod normale dage med normal gennemsnitlig performance eller op i mod de bedst performede dage.

 

 

Mulighederne for indsigt var mange. 

 

 

 

 

Fremgangsmåde i Process Mining processen

 

Tilgangen til proces analyse med Process Mining tog udgangspunkt i AllAboutRequirements metoden (udviklet af John Hansen), hvor proces analyse med Process Mining delen er illustreret nedenfor. Tilgangen bygger på en agil tilgang, hvor der anylyseres i et antal iterationer, med tilpasning af målsætning efter hver iteration.

 

Med Københavns Lufthavne A/S proces analyse af baggage fabrik performance blev der gennemført i alt 2 iterationer.

 

Følgende del processer blev gennemført:

 

1. Inledende møde til afdækning af proces kendskab, data behov, data tilgængelighed, forventninger og målsætning for analysen
2. Udtræk af data i CSV format
3. 1. Iteration: Analayse af processen i Disco process mining værktøj. Generering af proces overblik. Identificering af flaskehalse. analyse af performance og virkning/årsagsanalyse
4. Workshop. Gennemgang af 1. iteration analyse resultater. Fastlæggelse af målsætning og forventninger til 2. iteration analyse
5. 2. Iteration: Analyse af processen hvor lokation er en del af procestrinnene. Analyse af performance
6. Workshop. Gennemgang af 2. iteration analyse resultater. Opsummering af analyse resultater. Afrunding af opgaven
7. Færdiggøre analyse resultater fra de 2 iterationer
8. Fremlæggelse for ledelse og præsentation af rapport med analyse resultater

 

 

 

 

 

 

 

 

Den officielle case story (engelsk)

 

 

Download Copenhagen Airports - Process Mining Case Story