Den danske blog om Process Mining

Foredrag Lean Akademiet

 

På Lean Akademiets event "Fremtidens optimering" 6. september 2024 holdt jeg et indlæg om Process Mining. Process mining er absolut et element i fremtidens proces optimering. Med process mining får man en databaseret tilgang til arbejdet med processer og optimering.

 

Da process mining bygger på faktuelle data fra de procestrin, der er udført og gemt i IT systemerne, kan der ikke alene dannes et procesmap, men man får også automatisk stillet performanceanlyse, root cause analyse og AI analyse til rådighed.

 

Det var også en generel introduktion til process mining og ikke miste den udvikling process mining har været igennem, hvilket er illustreret nedenfor.

 

 

 

DMAIC modellen, der kendes fra arbejdet med Lean og SixSigma, kan sagtens indarbejde process mining i flere af faserne. Med process mining har man et værktøj, der kan være hjælpe med hurtigere at få overblik over processen, forstå problemet, etablere målinger på processen og udføre root cause analyser.

 

Et andet indlæg på dagen, var omkring etablering af  en Digital Twin. Også her kan man benytte process mining. Alle processer kan i princippet spejles over i process mining, hvor processen kan overvåges og der kan etableres predictions over hvordan den, eller enkelte cases, vil performe. Det skal siges, at hvis behovet er at etablere en Digital Twin for et fysisk produktionselement og udføre simuleringer på denne, så er det et andet værktøj, der er brug for, der er mere rettet mod en industriel Digital Twin.

 

 

Eksekvering af sustainability på det operationelle niveau med process mining

 

Bæredygtighed og bæredygtig forretning er vigtigere end nogensinde før. 

 

I 2015 ved COP21 i Paris blev de 196 medlemslande i FN's klimakonvention enige om en forpligtende klimaaftale – Parisaftalen. Ifølge Parisaftalen forpligtede landene sig til begrænse den globale udledning af drivhusgasser og arbejde for at begrænse den globale temperaturstigning til 1,5 grader celsius. 

 

EU er gået skridtet videre med at arbejde for den grønne omstilling. Med EUs Green Deal er ambitionen, at EU skal blive det første klimaneutrale kontinent , med klimaneutralitet senest i 2050.

For at opnå dette har EU besluttet, at der skal stilles krav til virksomhedernes bæredygtighed, og at de skal rapportere på det. 

 

Hvis virksomhederne skal være bæredygtige, og være en del af den grønne omstilling, kræver det for det første, at virksomhedernes processer tilrettelægges og optimeres til dette, men også at bæredygtighedsdata, der skal rapporteres på, ikke alene kan frembringes, men også kan operationaliseres. Det kræver i høj grad, at data, der rapporteres på, kan indgå i de operationelle beslutninger. Ellers er den årlige rapportering (eller i bedste fald kvartalsvise rapportering) blot et øjebliksbillede, hvor man kan konstatere om man nåede målene eller ikke.

 

Hvis rapporteringen skal være andet end et øjebliksbillede og en meget high-level pejling af, om man er på rette spor, er man nødt til at gøre de data, der rapporteres på, til aktive KPIer og lade de KPIer indgå i operationelle beslutninger på daglig basis.

 

Man kan for eksempel forestille sig at en rapportering på virksomhedens udledning af drivhusgasser påvirkes af, hvordan virksomheden distribuerer sine varer - herunder om det sker med skib, fly, tog eller lastbil og hvor mange kilometer varerne transporteres.

 

Hvis økonomi ikke er den eneste KPI, der skal tages hensyn til, når en medarbejder skal beslutte hvordan en given ordre skal distribueres, er den medarbejder nødt til at have KPI data til rådighed, der kan fortælle om konsekvensen ved de forskellige valg af distributionsform. Et forsimplet eksempel kan være. at transport med leverandør A medfører transport med lastbil som udleder mere co2 end transport med leverandør B, som transporterer med tog, men at prisen for leverandør A er billigere. Eller at leverandør C også transporterer med tog men over en længere strækning end leverandør B og derved udleder mere co2 end leverandør B. Valg som disse skal være mulige at tage med de rigtige data til rådighed i beslutningsøjeblikket - ellers bliver bæredygtighedsrapportering blot statiske øjebliksbilleder.

 

 

Udgangspunkt i de 17 verdensmål

 

Når virksomheder skal igang med bæredygtighed, kan det være oplagt at tage udgangspunkt i FNs 17 verdensmål (under de 17 mål er der ialt 169 delmål)

Med udgangspunkt i de 17 verdensmål har virksomhederne i princippet 17 bundlinier at forholde sig til. Traditionelt set har der været én bundlinie, nemlig den finansielle. Med verdensmålene og krav til bæredygtighedsrapportering forholder det sig nu anderledes. Da verdensmålene kan deles op i E (environment), S (Social) og G (Governance), kan det siges at rapportering kun på F (Finansiel) går over til at blive foretaget på F-E-S-G.

 

Når der er flere bundlinier, er der også flere områder, hvor der skal hentes data. Men endnu vigtigere er der flere områder, hvor der skal etableres de rigtige processer og KPIer at styre efter.

 

 

EUs rapporterings direktiv (CSRD)

 

EU har under Green Deal paraplyen besluttet, at der skal rapporteres på bæredygtighed. Til dette har EU vedtaget CSRD (Corporate Sustainability Reporting Directive) direktivet, der angiver hvorledes, der skal rapporteres. Retningslinierne for rapporteringen indarbejdes i de enkelte EU landes lovgivning. Selve rapporteringen skal ske efter et sæt standarder kaldet ESRS (European Sustainability Reporting Standards). Rapporteringsstandarden ESRS dækker over 12 standarder med ialt ca. 1100 målepunkter.

 

 

 

 

Ifølge ESRS standarden skal der rapporteres efter princippet om dobbelt væsentlighed. Der skal med andre ord kun rapporteres på de bæredygtighedsemner, der er væsentlige for virksomheden. I dobbelt væsentlighedsanalysen ses der både på virksomhedens påvirkning af bæredygtighed og på eksterne bæredygtighedsforhold, der påvirker virksomheden. Der ses altså både indefra og ud og udefra og ind.

 

Det helt overordnede formål er, at virksomhedernes indsatser skal være i overensstemmelse med Parisaftalens mål om at begrænse den globale opvarmning til 1.5 grader celsius.

 

For at arbejde hen imod målet, om at begrænse den globale opvarmning til 1.5 grader celsius, er det nødvendigt at måle og rapportere på virksomhedernes udledning af co2. Med udgangspunkt i ERSR er det i dette tilfælde E1. For at gøre målinger af co2 aftryk sammenlignelige på tværs af virksomheder, domæner og aktiviteter opfordres der til, at dette sker med udgangspunkt i udregninger, der følger Green House Gas Protocol (GHG protokollen) 

 

Derudover skal rapporteringen ske, ikke alene for virksomhedens egne direkte aktiviteter, men også for indirekte aktiviteter. Dette skal ske efter en opdeling i scope1, scope2 og scope3. Det var oprindeligt the Green House Gas Protocol, der introducerede opdelingen i scope1, scope2 og scope3 og som standarden nu siger, der skal rapporteres efter i forbindelse med rapportering på co2 udledninger (drivhusgasser - ikke kun co2). 

 

 

 

 

 

 

Scope3 er opdelt i 15 forskellige upstream og downstream aktiviteter, som fordeler sig som vist nedenfor. En vejledning til beregning af scope3 udledningerne og de 15 kategorier kan ses her på ghgprotocol.org.

 

 

Som det kan ses af opdelingen i scope1, scope2 og scope3 er virksomhedens egne aktiviteter (scope1) populært sagt de aktiviteter, der kontrolleres af virksomheden selv og foregår på egen matrikel, mens scope2 er de indirekte aktiviteter, der er nødvendige at indkøbe til produktionen på egen matrikel (scope2) som primært er indkøbt energi. 

 

Scope1 og scope2 er relativt nemmere end scope3 at indsamle data på, fordi disse aktiviteter kontrolleres af virksomheden selv. 

Scope3 er vanskeligere at gå til, da disse aktiviteter (opdelt i de 15 kategorier) dækker over aktiviteter i hele virksomhedens værdikæde og dermed ikke kun aktiviteter som virksomheden kontrollerer.

 

Det er dog uhyre vigtigt, at der også rapporteres, optimeres og operationaliseres på scope3 data og KPIer, for det i scope3 langt det meste af virksomhedernes co2 udledning kan henføres til. Ofte tales der om at 80% af virksomheders co2 udledning stammer fra scope3. Dansk Industri mener det er ca. 75-95%.

 

 

Sammenhæng mellem strategisk, taktisk og operationelt niveau

 

Nedenfor ses hvordan bæredygtighedsinitiativer fordeler sig på de typiske niveauinddelinger i virksomheden.

 

 

 

 

 

 

Bæredygtighed på det strategiske niveau

 

På det strategiske niveau etableres bæredygtighed som en del af virksomhedens strategi. Der kan med fordel tages udgangspunkt i verdensmålene og dernæst lægge en dobbelt væsentlighedsanalyse til grund for det videre arbejde.

Desuden opstilles der delmål til brug i den taktiske styring. 

 

Når virksomhedens strategi og forretningsmodel er på plads og den dobbelte væsentlighedsanalyse er klar til det videre arbejde og rapportering på bæredygtighed, skal virksomhedens processer ses efter i sømmene.

 

På dette niveau er det naturligvis ikke de detaljerede processer , der skal ses på. Men virksomhedens processer på øverste niveau (proces niveau 1) skal efterses for at finde ud af, om de er tilstrækkelige til at understøtte de strategiske valg. Hvis ikke skal virksomhedens overordnede processer re-designes.

 

Re-design af de overordnede processer bør ske med udgangspunkt i strategien.

 

 

Bæredygtighed på det taktiske niveau

 

På det taktiske niveau fastlægges der, med udgangspunkt i strategien, de taktiske rammer som virksomheden skal agere indenfor.

 

Når der senere skal tilrettelægges hvordan, der i det daglige skal tages beslutninger, skal det ske med hensyn til de taktiske rammer og delmål, der er fastlagt.

 

For eksempel er der fra den dobbelte væsentlighedsanalyse fastlagt, hvad der skal rapporteres på. Disse rapporteringsmål skal der stableres overordnede KPIer for. Med udgangspunkt i ESRS E1 klimaforandringer kunne virksomhedens co2 udledning være en overordnet KPI, der skal rapporteres på. De overordnede KPIer kan ydermere samles i en KPI på et højere aggregeringsniveau  for, for eksempel, at have en måling på virksomhedens overordnede bæredygtighedsscore.

 

Der er derfor allerede på det taktiske niveau et arbejde med at udmønte strategi og processer til taktiske rammer og delmål, der kan måles på.

 

 

Bæredygtighed på det operationelle niveau

 

På det operationelle niveau bliver det afgørende at etablere processer, der understøtter den daglige håndtering af virksomhedens aktiviteter med hensyntagen til de taktiske rammer.

 

Det er på det operationelle niveau, det bliver afgørende om bæredygtighedsrapportering skal være mere end et øjebliksbillede som man ser en gang om året eller en gang i kvartalet.

 

Hvis det skal det, så er det nødvendigt at indarbejde følgende:

1. Processer der understøtter strategien
2. KPIer og del-KPIer til måling af bæredygtighed
3. KPIer skal være til rådighed på alle relevante procestrin hvor der skal træffes beslutninger
4. Brugere skal modtage hjælp fra predictive analytics af processer og KPIer

 

 

Bæredygtighed på det operationelle niveau operationaliseres med process mining

Hvis eksemplet med minimering af virksomhedens co2 aftryk skal fortsættes, er det værd at se på tidligere omtalte figur, hvor det kan ses at Scope3 er opdelt i 15 forskellige upstream og downstream aktiviteter. Aktiviteterne er typiske elementer fra Supply Chain Management som for eksempel Procurement & Order Management.

 

Når det meste af virksomhedens co2 udledning kan henføres til disse aktiviteter, er det interessant, for eksempel, at se på virksomhedens P2P (Procurement to Pay) proces og O2C (Order to Cash) proces. Disse processer dækker over indkøb, der foretages, og ordrer der modtages og leveres. I forvejen er disse processer ofte underlagt bevågenhed og optimering under Supply Chain Management initiativer - men det er ofte uden at have bæredygtighed for øje. 

 

Man kunne for eksempel sørge for, at alle leverandører i indkøbssystemet havde en tilknyttet Bæredygtigheds score. I forbindelse med oprettelse af rekvisitioner for indkøb, skal de mulige leverandører, der kan vælges påvirke en Bæredygtigheds KPI via deres Bæredygtigheds score. Hvis der vælges en anden leverandør, end de leverandører der er udvalgt som strategiske leverandører, bør der i det valg altid skeles til, hvad det så betyder for bæredygtigheds KPIen.

 

Varer kan desuden mappes til en co2 score, så det bliver muligt i real tid at få oplyst hvilken betydning et valg har for co2 aftryk KPIen.

 

 

 

 

 

Ovenstående eksempler er med udgangspunkt i indkøb. Der er også muligheder i at indbygge bæredygtigheds KPI i distributionen af virksomhedens varer. Der kunne for eksempel etableres KPIer for co2 aftryk i valg af transportformer, holdt op imod de afstande der skal transporteres.

 

Der er gode muligheder for at optimere på bæredygtighedsforhold, når bæredygtighed indarbejdes i virksomhedens processer og beslutningssystemer. Det gælder i hele virksomhedens værdikæde. Lige fra valg af  leverandører, minimering af spild i produktionen til minimering af co2 aftryk i udvælgelsen af leverandører og såvel indgående som udgående transport.

 

Det er for mange et data problem. Der skal samles operationelle data og scientific data om co2 udledninger, og så skal der etableres en platform, hvor det hele bringes sammen.

 

Men det er vejen at gå, hvis bæredygtighedsmål skal være andet end lejlighedsvise målingsnedslag.

 

 

Tanker fra naturkonference

Naturkonferencen, afholdt af Hedeselskabet på Christiansborg 19. februar 2024, satte nogle tanker igang.

 

 

Biodiversiteten er under pres. 

 

20% af alle arter er i fare for at uddø indenfor de næste 50 år. Halvdelen af verdens værdier er afhængig af naturen og rent vand bliver en mangelvare i fremtiden.

 

Der er brug for tiltag. Vild Med Vilje sender et godt signal, men kommer ikke til at redde os - der skal mere til. For eksempel skal der etableres store områder med beskyttet natur.

 

Man kunne måske forestille sig, at der kunne være en fond, der køber meget store arealer op og omdanner disse til natur for at fremme biodiversiteten?

 

Det er interessant at se, at biodiversitet og afforestation (skovrejsning) ofte ligger længere ude i modenhedsrejsen, når der arbejdes med biodiversitet for øje.

 

Der er bred enighed om at teknologi alene ikke løser biodiversitetproblemet. Der skal også ses på governance og adfærdsændringer.

 

Processer er vigtige i relation til kortlægning og styring af governance, men også til arbejdet med biodiversitet.

 

Der bør etableres processer for hvordan naturarealer etableres og dernæst oprettes proces-KPIer for hvordan det går med den deraf afledte forbedring af biodiversiteten.

Men pas på med at skele for meget til biodiversitets kreditter - der findes nemlig ikke biodiversitets-ekvivalenter, som det kendes fra Co2 ekvivalenter.

 

 

 

Brug af process mining til audit

 

Auditering er et område, hvor process mining kan gøre god gavn. 

Der kan skelnes typisk mellem ekstern audit og internt audit. Det eksterne audit handler overordnet set om, at undersøge om de afrapporterede financielle rapporter (fx virksomhedens resultatopgørelse, balance og cash flow) stemmer overens med virkeligheden og at det virker troværdigt, hvad der er rapporteret i bøgerne. I det eksterne audit vil tilgangen ofte være at tage udgangspunkt i de rapporterede tal for gå tilbage til de transaktioner, der ligger bag, for at se om det stemmer. Det er selvfølgelig ikke alle underliggende transaktioner, der kan underlægges en kontrol. Der må ud fra en vurdering af risiko og plausibilitet lægges en strategi for hvilke transaktioner, og hvor mange (stikprøve kontrol), der skal ses nærmere på.

 

Med udgangspunkt i loggede data kunne den eksterne revision få genereret et proces overblik, der på overordnet niveau kunne se ud som nedenfor. Ud fra proces diagrammet kan det hurtigt ses, at der er en procesafvigelse i, at en del fakturaer går til betaling uden at være blevet godkendt først. Med process mining er det også muligt at se hvor stor en procentdel af fakturaer, der ikke går gennem proces trinnet "Godkend faktura" samt se karakteristika, der kan give et hint om årsagen til dette.

 

 

 

De fordele som den eksterne revision har af audit med process mining er:

• Audit bliver lavet på hele populationen af data
• Audit bliver data-drevet og baseret på faktuelle proces overblik
• Audit sikrer compliance ved at identificere afvigelser fra standard processer
• Audit kan genkøres på nye data men med den etablerede proces og KPI model

 

Der er dog også en række udfordringer forbundet med at gå fra den traditionelle måde at lave audit på til at gøre det data-drevet:

• Data kvaliteten kan gøre det vanskeligt at etablere et grundlag for data-drevet audit
• Komplekse processer kan gøre det vanskeligt at udtrække data korrekt og skabe et overblik, der giver det korrekte billede
• Proces afvigelser kan skyldes forretningsregler, der ikke er nedarvet i proces diagrammet

 

Især det sidste punkt "Proces afvigelser kan skyldes forretningsregler, der ikke er nedarvet i proces diagrammet" er værd at forholde sig til. Det kan godt være, at man ud fra proces diagrammet identificerer den afvigelse, at der er nogle fakturaer, der går til betaling uden først at være godkendt. Men det er ikke sikkert, at dette er en afvigelse i alle tilfælde. Det kan for eksempel være at fakturaer fra en bestemt leverandør ikke behøver godkendelse før betaling, eller at fakturaer, under et bestemt beløb, ikke kræver godkendelse inden betaling. Det, der i så tilfælde, er identificeret er nogle forretningsregler. Disse forretningsregler skal indarbejdes i det KPI overblik som process mining proces modellen ligger i, og derefter kan der ledes efter afvigelser igen.

Det man så i nogle tilfælde vil opleve er, at den tid der er sparet ved at gå fra traditionel audit metodik til en data-drevet tilgang blot kanaliseres over i at få identificeret forretningsregler og få renset KPI og proces model for afvigelser, der kan forklares med forretningsregler.

 

I det interne audit, som oftest varetages internt af virksomheden selv, er der et lidt andet fokus. Her vil fokus i højere grad være på at sikre, at der er de korrekte kontroller til stede og at processen er optimal og compliant. Til dette arbejde vil der formentligt være endnu større fordele at hente ved brug af process mining, end man umiddelbart ser ved ekstern revision.

 

Til såvel ekstern revision som til intern revision vil det være vigtigt at opbygge process mining kompetencer hos personer, der også besidder kompetencer indenfor auditering.

 

 

Analytikeres udfordringer i process mining - Indsigter fra analyse

 

Jeg har for nyligt været inviteret til at deltage i en undersøgelse af hvilke udfordringer analytikere møder, når der arbejdes med process mining. Analysen var baseret på interviews og praktiske øvelser med 41 deltagere fra både industrien og den akademiske verden og fordelte sig på 27 forskellige organisationer.

 

De udfordringer, der kom ud af undersøgelsen, blev fordelt efter følgende 6 projektfaser, som man typisk kommer igennem i et process mining projekt:

 

• Defining research questions
• Data collection
• Data pre-processing
• Mining & analysis
• Stakeholder evaluation
• Implementation

 

Overordnet blev der identificeret 23 typiske udfordringer. Udfordringerne fordelte sig på alle ovenstående projektfaser, på nær fasen "Implementation" hvor der ikke blev identificeret nogen udfordringer. Det er i sig selv bemærkelsesværdigt, at der ikke er udfordringer, der springer i øjnene, når der tales om implementeringsfasen. Dette kan måske skyldes, at implementeringsfasen er mindre påvirket af udefrakommende faktorer, hvorfor analytikerne har mere kontrol over denne fase.

 

Under "Defining research questions" fasen blev der identificeret en udfordring omkring det, at formulere spørgsmål der er gode nok og egnede til at analysere nærmere på. Uden virkeligt gode research spørgsmål kan man sidde timevis og analysere på noget, som måske ikke har nogen relevans.

 

I forbindelse med "Data collection" er der en række udfordringer. Der kan nævnes udfordringer med "Missing permissions" og "Extract from systems".

Det er klassiske udfordringer i næsten alle process mining projekter (og data mining projekter for den sags skyld), at få fat i data i et format der muliggør en fornuftig analyse. Ofte ses der projekter, hvor hovedparten af tidsforbruget går til at få fat i data og gøre dem klar til analysen. Det søges for eksempel løst ved at værktøjerne indarbejder connectors til de mest anvendte systemer og standardprocesser.

Derudover oplever man ofte at være afhængig af IT for at kunne få data ud. Det kan både hænge sammen med manglende adgange til kildesystemerne men også med et stort behov for at alliere sig med personer, der har indgående kendskab til data strukturen i kildesystemerne.

 

Når der så ses videre på fasen "Data pre-processing", støder man på udfordringer som "Correct aggregation level" og "Low data quality". Her ses der et vist overlap med udfordringerne i fasen "Data collection" og udfordringerne går især på at få fat i data på en måde, så de egner sig til den videre process mining analyse.

 

Fasen "Mining & analysis" berør udfordringer som "Tool knowledge", "Missing insights about data structure" og ulemper ved direct-follows-graphs.  

Udfordringerne begynder nu at centrere sig mere omkring de tekniske process mining værktøjer. Kendskab til værktøjer opleves som en stigende barriere i takt med, at værktøjerne bliver mere og mere komplekse. Desuden kan der være udfordring forbundet med at vise direct-follows-graphs repræsentationer af proces flowet, fordi der så mangler beslutningsforgreninger og parallelitet, der afspejler den virkelige verden og det kan vanskeliggøre samtalen omkring processen.

 

Endelig nævnes der under fasen "Stakeholder analysis" udfordringer med, i samarbejde med stakeholders, at "Answering research questions" og "Formulate concrete recommendations".

 

 

 

De største udfordringer, der blev omtalt, knytter sig dog tværgående til alle projektfaserne. Det er følgende udfordringer:

 

• Domain knowledge
• Log file 
• Tool knowledge

 

Domæne specifikt kendskab kan være afgørende for at kunne skabe meningsfulde analyser. Uden dette kendskab vil man ofte risikere at fokusere på forkerte problemstillinger og overse de oplagte. Har man ikke domæneviden i forvejen, må man hurtigst muligt tilegne sig dette og måske også alliere sig med nogen, der besidder det nødvendige domænekendskab. Workshops og interviews med nøglepersoner kan være en genvej til dette.

 

Et andet interessant udbytte fra undersøgelsen er, at værktøjerne bliver mere og mere komplekse samtidigt med, at de også er intuitive at komme igang med at bruge.  Det vil sige, at tilgangen er nem, men at man nemt kan fare vild i værktøjet.

Det blev også citeret fra interviews, at der er fare for at hoppe til forkerte konklusioner - man kan have data loaded og have dem helt korrekte og så er det rimeligt nemt at foretage en analyse, men så er det samtidigt også en kæmpe faldgrube, at hoppe til forkerte konklusioner (dette relaterer sig også til de udfordringer, der opleves i samarbejdet med stakeholders).

 

 

En interview deltager formulerer det således "way of thinking as a process mining analyst requires time and experience."

 

 

 

Undersøgelsen blev foretaget af en gruppe fra University of St. Gallen.

 

Gruppens kontakt side og LinkedIn informationer kan ses her:

 

Chair: SE - Institute of Computer Science (unisg.ch)

Francesca: (1) Francesca Zerbato | LinkedIn

Prof. Barbara Weber: (1) Barbara Weber | LinkedIn

Lisa: (1) Lisa Zimmermann | LinkedIn

 

 

Springer Link til publikationen:

Link: Process Mining Challenges Perceived by Analysts: An Interview Study | SpringerLink

 

 

 

 

 

 

Citation:

Zimmermann, L., Zerbato, F., Weber, B. (2022). Process Mining Challenges Perceived by Analysts: An Interview Study. In: Augusto, A., Gill, A., Bork, D., Nurcan, S., Reinhartz-Berger, I., Schmidt, R. (eds) Enterprise, Business-Process and Information Systems Modeling. BPMDS EMMSAD 2022 2022. Lecture Notes in Business Information Processing, vol 450. Springer, Cham. https://doi.org/10.1007/978-3-031-07475-2_1

Ansvarsfordeling i process mining projekter

 

Hvem har egentligt ansvaret i process mining projekterne?

 

For at svare på dette er det nødvendigt først at se på hvilke ansvarsområder der er. Der kan tages udgangspunkt i de 4 overordnede faser, som vist nedenfor, hvor et typisk process mining projekt gennemgår design, implementering, monitorering og endelig analyse.

 

De 4 faser indeholder en række aktiviteter. Et overordnet overblik over typiske aktiviteter, i de 4 faser, er illustreret nedenfor:

 

 

Aktiviteterne kunne grupperes i følgende områder:

 

• Kravstillelse

 

• Udvikling

 

• Test

 

• Dokumentation

 

Hvis process mining projektet og etablering af process mining købes udefra, for at indtage ekstern ekspertise, vil man som udgangspunkt købe en fuld end-to-end implementering. Når man indkøber en fuld implementering, har man oftest også en forventning om, at leverandøren har hele ansvaret i hele processen. Men det er ikke altid sådan det forholder sig.

Som det ses nedenfor, er der nogle områder, hvor man typisk kan komme i en grå-zone omkring hvem der er den udførende part - leverandøren eller kunden. I kølvandet på dette kommer naturligvis afstemning og efterfølgende diskussion af, hvem der så har ansvaret.

 

 

 

Hvem har ansvaret?

Det er utroligt vigtigt at afstemme og dokumentere hvem der har ansvaret. Dette bør dokumenteres allerede i indgåelsen af udviklingsaftalen, kontrakten, statement of work eller hvad der ellers ligger forud.

 

Eksempelvis kan der peges på en aktivitet som "Udvikle views". I takt med at kunden bliver mere og mere bekendt med process mining og ikke mindst det process mining værktøj der benyttes, bliver de også i stand til at tilpasse og udvikle views - og ofte ønsker de også at gøre dette for at kunne reagere hurtigere på ændringsbehov. 

 

Der er leverandører, der griber dette og indfører i kontrakterne, at "kunden står for tilpasning og oprettelse af views". Men her skal man som kunde passe på. For hvad sker der, hvis der er views man ikke kan få til at opføre sig korrekt eller vise det ønskede på den rigtige måde? Ja, hvis der står i kontrakten, at det er kundens ansvar, så er det kundens ansvar (og problem).

Derfor bør leverancerne af en end-to-end process mining implementering altid være leverandørens ansvar i hele processen og i alle aktiviteterne. Hvis kunden så sideløbende kan udvikle og tilpasse, så er det fint - men det er leverandøren, der har leveranceansvaret.

 

 

 

Dokumentering af komplekse processer

 

Serialiser ikke hvad der i virkeligheden er parallelt

 

En god tommelfingerregel, når man dokumenterer processer, er at undgå at serialisere processer, som i realiteten ikke udføres serielt. Det sker ofte, at parallelle processer dokumenteres som værende serielle, fordi det giver pænere og mere overskuelige diagrammer. Men også fordi en seriel proces illustrerer en slags huskeliste og/eller den rækkefølge, man vil anbefale at udføre proces trinnene i.

Et eksempel kunne være diagrammeringen af, hvordan man laver en burger – bare for at tage et helt banalt eksempel.

 

 

Processen illustrerer nok meget godt hvordan, man ville lave en burger. Processen er optegnet som en seriel proces, hvor rækkefølgen er strengt defineret. Det gør det nemt at overskue processen og det angiver den rækkefølge, man ønsker at tingene bliver udført i. Men det afspejler ikke virkeligheden særlig godt. Det er jo for eksempel helt uden betydning, om man tilsætter salt inden man tilsætter peber eller om man smør mayo på før man smør ketchup på – men processen er tegnet sådan, at rækkefølgen ikke kan brydes. Der kan altså ikke tilsættes peber førend, der tilsættes salt.  Omvendt giver det nok god mening at man steger bøffen, inden man varmer bollen.

Hvis man fastholder processen på denne måde, så har man for det første ikke en proces, der afspejler hvordan man udfører den i praksis. Derudover er det ikke en særlig fleksibel proces, da den netop angiver at tingene SKAL udføres i en bestemt rækkefølge. Måske havde det i så tilfælde været bedre med en huskeseddel i stedet for et proces diagram.

Hvis processen skulle tegnes så den var mere virkelighedstro kunne den se sådan ud:

 

 

Nu er der indsat parallelle aktiviteter og diagrammet er mere virkelighedstro. Steg bøffen og start på opvarmning af bolle efter 5 minutter. Læg ost på den stegte bøf. Når både bøf og bolle er klar, skal der i tilfældig rækkefølge smøres mayo og ketchup på, og tilsættes salt og peber. Når alle aktiviteter er udført, skal burgeren samles.

I overstående flow tillades ikke, at der er aktiviteter, der udelades. Man kan for eksempel ikke lave en burger uden mayo, hvis det ønskes. Dette kunne dog godt være diagrammeret, hvis det var ønskeligt.

 

Hvordan håndteres det hvis processerne bliver for komplekse?

 

Meget komplekse processer kan være svære at diagrammere ud fra den traditionelle metode. Ovenstående eksempel er meget banalt og den proces vil være nem at identificere. Men andre mere komplekse processer kan være meget svære at identificere – især hvis de skal afspejle virkeligheden (som overstående eksempel viser kan være vanskeligt).

Proces mining er et godt værktøj til at identificere processer og give et korrekt billede af hvordan processerne udføres i virkeligheden.

En meget kompleks proces, hvor aktiviteterne udføres i helt vilkårlig rækkefølge og hvor det fra case til case er meget forskelligt hvilke aktiviteter der skal udføres, kan for eksempel være meget videnstunge processer. Et eksempel kunne være processen under en operation på et sygehus. Her vil der være mange parallelle aktiviteter og aktiviteterne kan udføres i forskellige rækkefølger alt efter behovet og den situation, man befinder sig i.

Process mining på sådanne processer vil typisk give et spaghetti diagram som dette eksempel:

 

 

I process mining værktøjer vil man kunne zoome ind på processen og få vist en forsimplet proces over det mest sandsynlige flow. Det vil give et fint billede og også et godt udgangspunkt til at undersøge for performance og hensigtsmæssighed i processen. Og på den måde vil det process mining genererede diagram kunne give stor værdi.

Det er dog mindre sandsynligt, at diagrammet vil kunne bruges som et arbejdsredskab under udførslen af processen. Dertil er processen simpelthen for kompleks og for anarkistisk i sin udformning. I sådanne tilfælde vil det være mere hensigtsmæssigt for eksempel at udarbejde et hierarkisk opgave diagram:

 

 

Et hierarkisk opgave diagram opdeler mål og opgaver i underliggende delopgaver, der skal til for at opfylde opgaverne/målene. Dertil kan der skrives planer, der angiver regler som fx om rækkefølger må være vilkårlige, eller er faste.

Proces mining er et godt værktøj til at identificere processen og selv ud fra en identificeret spaghetti proces, kan den faktiske proces identificeres. Måske til brug som afsæt for opbygningen af et opgave hierarki med planer for udførslen. Det kan så yderligere udbygges via Task mining teknikker. På den måde kan process mining give et første overordnet overblik over selv meget anarkistiske processer og task mining kan bruges til at udbygge processen med underprocesser i mere detaljeret form.

Gevinsten er diagrammering og fastholdelse af selv meget anarkistiske processer i et automatiseret og dynamisk miljø, der er nemt at tilgå og opdatere.

 

 

Optimer flaskehalse og begrænsninger med process mining

 

Med process mining er det muligt at få et objektivt billede af, hvor der er flaskehalse i processen. Teorien om constraints (https://en.wikipedia.org/wiki/Theory_of_constraints) påpeger, at en organisation kan måles og styres efter varianter over tre indikatorer: gennemløb, operationelle udgifter og lager. Med proces øjne er det mest interessante at fokusere på gennemløb, og se hvor effektiv processen er.

 

Med teorien omkring constraints skal man først identificere de begrænsninger (constraints) der er og derefter løse den begrænsning, der har den største betydning for processen. Man kan sige, at der kan være mange flaskehalse med kun en begrænsning ad gangen.

 

Det er vigtigt at skelne mellem flaskehalse (bottlenecks) og begrænsninger (Constraints).  En flaskehals er tilstede i en proces, hvis der er højere krav til gennemløb end processen har kapacitet til at levere.  Så hvis en proces har kapacitet til at behandle 100 elementer i timen, men der flyder mere end 100 elementer ind til behandling i timen, så opstår der en flaskehals.

 

Flaskehalse kan ofte ses ved at der er ”kø” / ventetid foran processen eller, at der er mangel på ”opgaver” i en modtagende proces. I tilfældet af kø er der flere elementer til behandling der flyder ind i processen, end den kan nå at behandle. Når der er mangel på opgaver i en efterfølgende proces, kan det være fordi den forudgående proces ikke får behandlet elementer hurtigt nok.

 

I nedenstående procesdiagram ses det, at kapaciteten på 80 i proces 2 udgør en flaskehals, fordi der vil tilgå 100 fra proces 1. Samtidig kan det ses, at der vil tilgå 160 til proces 4 som kun har kapacitet til 120, hvilket også er en flaskehals. Der er altså to flaskehalse, men flaskehalsen i proces 4 udgør også begrænsningen i processen, som aldrig vil kunne behandle mere end 120 i timen.

 

 

 

 

 

Det rigtige at gøre er nu at fokusere på processens begrænsning og få gjort noget ved den.  Man kan for eksempel tilføre flere ressourcer til proces 4 for derved at øge dens kapacitet. Man kunne også sørge for, at der aldrig tilgår mere end 120 til processen, og så vil proces 4 ikke længere være en flaskehals. Når proces 4 flaskehalsen er elimineret, for eksempel ved at øge dens kapacitet til 160, så vil processens begrænsning nu flytte sig til at være flaskehalsen ved proces 2.

 

Det er ikke let at identificere flaskehalse og begrænsninger i en proces. Med process mining får man en genvej til et visuelt og faktuelt overblik over hvordan processen klarer sig.

 

Brug process mining til at identificere flaskehalsene og eliminer dem en for en startende med den vigtigste først.

 

 

Optimer test strategi med RPA og process mining

 

Test af IT systemer er en vigtig disciplin. Dels er det ofte meget dyrere og mere besværligt at opdage og rette fejl, når først de er i produktion, og dels kan pludseligt opståede fejl gøre betydelig skade. Derfor er test vigtig, og der bliver ofte lagt mange ressourcer i test af IT systemer.

Der er mange forskellige typer af test med forskelligt formål og forskellig detaljeringsgrad.

 

Groft sagt kan de forskellige test typer inddeles i følgende tre kategorier:

• Unit test
• Integrations test
• Funktionel test

 

Dette kan illustreres som en pyramide (Mike Cohns Test Pyramid) af testtyper:

 

 

Mike Cohns Test Pyramid

 

 

Unit test er test, der tester de mindst mulige elementer som for eksempel metoder og funktioner i den udviklede kode. Det er oftest udviklerne, der tester deres færdige arbejde for, om der er fejl i den udviklede kode.  Af de tre test typer vil det være unit tests, der vil være flest af.

 

Integration test er test hvor integrationerne til eksterne systemer testes. Mens unit test er test isoleret til enkelte metoder/funktioner, er integrationer oftest udeladt. Integration test er mere tidskrævende end unit tests, og kræver ofte at de eksterne systemet er kørende op imod et test miljø. Der vil være færre integration test end unit test, men de vil være sværere/mere tidskrævende både at udarbejde og teste.

 

Funktionel test (GUI Test) er den tredje kategori ,og dækker over test af systemets funktionalitet gennem bruger interfacet. Med andre ord testes der funktionalitet, der nås gennem brugergrænsefladen, og ofte strækker sig over flere unit tests og i nogle tilfælde over en hel end-to-end proces. Det er den mest tidskrævende test kategori, både i opbyggelse og udførelse, og kræver ofte gode test scripts og test data. Til gengæld vil de funktionelle test ofte kunne identificere fejl, der ikke er opdaget under unit test, da de funktionelle test tester funktionaliteten i sammenhæng. Funktionel test (GUI Test) er forudsætningen for, at brugerne kan godkende systemet og udgør derfor de funktionelle test cases. Det vil oftest være funktionelle test, der er færrest af, da de er tidskrævende at udarbejde, vedligeholde og udføre.

 

 

Test pyramidens relation til hastighed og pris kan illustreres som nedenfor:

 

 

 

 

I toppen af test pyramiden finder man GUI test, og det er her der ønskes så få test som muligt, for GUI test er langsomme og vanskelige at lave, besværlige at køre og svære at vedligeholde.

 

Løsningen kan være at udarbejde automatiserede test, som kan udføres uden involvering af mennesker. Til dette har der i årtier været forskellige værktøjer med forskellige fordele og ulemper.  Det har traditionelt set været svært at gå til. Ofte har barrieren været at skulle lære et nyt (scripting-)værktøj og begrænsninger i, at kunne lave automatiserede test på alle typer af GUI og på end-to-end processer, der måske spænder over flere GUI typer.

 

 

RPA kan være svaret på de udfordringer.

 

 

 

 

Man kunne benytte RPA til at udvikle automatiserede test i GUI test laget.

 

 

Det er dog vigtigt at huske følgende:

• Automatiserede test bør ikke kun være til stede i GUI laget. Ofte har IT leverandøren allerede automatiserede test i Unit Test og Integrationstest laget
• Som tommelfinger regel skal en udviklet automatiseret test udføres mindst 4 gange før investeringen er tjent hjem (før det er fornuftigt at udvikle testen som automatiseret test i forhold til at beholde den som en manuel test)
• De automatiserede RPA test scripts bør også automatisk kunne oprette tickets i et incident management system

 

Og endelig bør de RPA automatiserede test scripts hovedsageligt baseres på de processer, der er vitale – se inspiration til hvordan processer udvælges her: https://www.processmining.dk/2018/01/robotic-process-automation-succes-sikres-med-process-mining.html

 

 

 

 

Byg organisationens digitale tvilling med process mining

 

 

 

 

Tidligere var det normal praksis, at undersøge nye teknologier og implementere disse og derefter se hvor meget man kunne få ud af det. Men der er ved at ske et skifte fra den tilgang over til først at se på virksomheden og menneskerne i virksomheden.

 

I takt med at der fokuseres på virksomheden og menneskerne i den, bliver fokus rettet mod at effektivisere virksomhedens operationer og automatisere manuelle opgaver, som ikke kan elimineres. For at opnå effektivisering og automatisering skal der indsamles data til simulering af forretningen og automatisering af opgaver. Arbejdet med dette vil ofte resultere i kortlægning af virksomhedens processer med process mining og automatisering af arbejdsgange med RPA. Begge elementer vil ofte medføre, selvom det måske ikke var målet i første omgang, at der etableres en digital tvilling af organisationen (DTO).

 

Konceptet ”digital tvilling” er ikke nyt. Det ses ofte indenfor for eksempel industri produktion eller vindmølle industrien, hvor der bygges en virtuel kopi af den fysiske installation for at kunne simulere denne og dermed nemmere fejlfinde eller videreudvikle nye designs.

 

I modsætning af traditionelle digitale tvillinger, der er digitale repræsentationer af fysiske produkter eller maskiner hvor IoT data er det centrale, bygger organisationers digitale tvillinger på data født af virksomhedens operationer.

 

En organisations digitale tvilling (DTO) er altså en digital repræsentation af hvordan virksomheden fungerer, performer og skaber den ønskede værdi.

 

 

Hvorfor skal vi have en digital tvilling?

 

Virksomheder skal være i stand til at tilpasse sig en verden, der ofte ændrer sig. Når virksomheden skal tilpasse sig en ny virkelighed med ændrede forudsætninger, kræver det ofte at virksomheden ændrer på organisationen (re-design), interne systemer og procedurer, IT systemer eller infrastruktur. Med en digital tvilling er det nemmere at overskue hvilke elementer der er tilstede, hvordan de opfører sig og hvad de bør ændres til.

 

 

For at konkretisere hvilke fordele det kunne give, kan der nævnes følgende:

 

• Det er komplekst at overskue om organisationen er effektiv. Med en digital tvillings KPI dashboards og proces visualiseringer, kan dette ses i real tid
• Onboarding af nye medarbejdere bliver nemmere, hvis de nye medarbejdere kan introduceres til virksomheden ved at studere og arbejde med en digital tvilling
• Organisationsændringer (nye positioner) kan drage nytte af de samme fordele, som der er ved onboarding af nye medarbejdere. De får derved nemmere ved at indfinde sig i deres nye positioner.
• Konkurrencefordele kan optimeres. De klassiske konkurrencefordele som billigere produkter, bedre kvalitet eller hurtigere levering kan optimeres ved at studere virksomheden gennem den digitale tvilling repræsentation
• Digitaliseringsrejsen (herunder RPA) er nødt til at tage afsæt i virksomhedens processer, som ikke altid er kendte (visualiseret) men det er de, hvis der eksisterer en digital tvilling

 

 

Hvad skal der til for at være en digital tvilling?

 

 

Den ultimative digitale tvilling er en 1 til 1 digital repræsentation af hele virksomheden incl. processerne, produkterne, services, infrastrukturen, kunde interaktioner, distributionskanalerne – eller med andre ord: alt hvad der udgør virksomheden. Det er svært at opnå.  Det at etablere en digital tvilling er en rejse, der vil blive ved med at forgrene sig.

 

Det kan derfor være svært at vide hvornår man ikke blot har en digital repræsentation af dele af processerne, men har en digital kopi af virksomheden i et omfang, så man kan tale om en digital tvilling.

 

 

Der er nogle kendetegn, der skal være til stede:

 

 

 

 

 

1. Model
   1. Der skal være en model over virksomhedens processer og komponenter. Her er process mining vigtig. Dels for at kunne skabe en korrekt model ud fra faktiske data gemt i virksomhedens IT systemer, dels for at være i stand til at opdatere/ændre og monitorere processerne automatisk ud fra genindlæsning af data.
2. Målinger
   1. En digital tvilling skal måle vigtige forhold, som kan bruges til at monitorere hvordan det går og danne grundlag for beslutninger eller tiltag. Dette sker oftest gennem udstilling af KPIer og dashboards, der i real tid tager temperaturen på virksomheden og stiller dette til rådighed.
3. Data indsamling
   1. Der skal kontinuerligt indsamles data. Både data til understøttelse af KPIer og proces simulering/opdatering, men også data til modellering og simulering af aktiviteter, der ikke er IT understøttet. Til dette formål kan Task Mining bruges til at indsamle brugeraktivitet direkte fra skærmen og transformere disse til modellering i samspil med de øvrige processer.

 

 

 

Hvor skal man starte?

 

Start hvor der allerede er data og det er der i virksomhedens IT systemer. Process mining er et røntgenbillede af virksomhedens processer og et oplagt sted at starte. Derefter kan den digitale tvilling udbygges med flere processer, med task mining af ikke IT understøttede aktiviteter og med data fra fysiske enheder (IoT)

 

 

 

 

Hvilken proces skal analyseres med process mining

 

 

Når man skal igang med process mining, er det en god ide at se på de proceskandidater der er og vælge en proces, der skal mines udfra nogle objektive kriterier.

 

Hvis det er første gang, der skal igangsættes process mining initiativer, er det en god ide at betragte process mining opgaven som et pilot projekt og vælge en proces ud, udfra følgende 7 kriterier:

 

 

1. Afgrænset proces
2. Understøttet af ét IT system
3. Data logget
4. Data i høj kvalitet
5. Dataudtræk let tilgængeligt
6. Værdifuld proces
7. Kendte proces udfordringer

 

 

Afgrænset proces

 

Processen skal være afgrænset således, at det er kendt hvad der er starten af processen, og hvad der er slutningen af processen. Desuden skal processen være en selvstændig proces, der kan eksistere på egen hånd. Et eksempel kunne være en indkøbsproces. En indkøbsproces kan eksistere selvstændigt og det er velkendt hvad der er starten og slutningen af processen. IT Governance processen er til gengæld ikke en god kandidat, da den ikke er tilstrækkeligt afgrænset. Det er for eksempel ikke entydigt, hvor den starter eller slutter, desuden er den muligvis ikke afgrænset til kun et forretningsdomæne – er for eksempel Organisational Change Management og Risk Management processerne en del af processen?

 

Kriteriet for at processen er afgrænset er, at den knytter sig til en enkelt disciplin og at det er åbenlyst, hvad der starter og afslutter processen.

 

 

Understøttet af ét IT system

 

Processen skal være understøttet af et og kun et IT system. Det skal med andre ord være muligt at trække alle data ud fra kun et IT system.  Hvis processen er understøttet af flere IT systemer, er det nødvendigt at trække data ud fra flere systemer og flette disse sammen, og det øger kompleksiteten og fejlmulighederne.

Bemærk dog, at processen stadig er understøttet af kun et IT system selvom processen involverer eksterne parter. Man kunne forestille sig følgende proces trin:

 

1. Send faktura til kunde
2. Modtag betaling fra kunde

 

 

 

 

Mellem trin 1 og trin 2 sker der selvfølgelig noget i kundens proces. Det kan for eksempel være, at faktura bliver sendt til godkendelse hvorefter den frigives til betaling og endelig betales. Men disse proces trin hos kunden er irrelevante for processen, og det er derfor tilstrækkeligt at trin 1 og trin 2 er understøttet af et IT system.

 

 

Data logget

 

Data skal være logget. Det vil sige, at procestrinnene skal være stemplet i IT systemet. Der er to faktorer, der afgør i hvor høj grad man kan sige, at data er logget:

 

1. Antallet af procestrin der er logget i IT systemet – er det hele processen eller for eksempel kun 10% af procestrinnene?
2. Hvilke informationer er logget om processen – Er procestrin navn + dato + tidspunkt logget eller er det kun dele af de oplysninger der er logget.

 

 

Data i høj kvalitet

 

Data skal være i god kvalitet. Det nytter ikke meget, hvis data er logget, men at det er i en meget dårlig kvalitet. Dårlig kvalitet kan måles på disse tre parametre:

 

1. Mangelfuldhed
2. Uens formater
3. Pålidelighed

 

 

Mangelfuldhed

 

Med mangelfuldhed menes der manglende data. Det kan være at en bestemt data attribut kun er tilstede i få procent af tilfældene. For eksempel kunne det være at tid/dato stempel mangler i over halvdelen af tilfældene. I sådanne tilfælde kan det blive vanskeligt at foretage process mining på et repræsentativt udsnit af data.

 

Uens formater

 

En velkendt problematik er, at dato formater er gemt i forskellige formater i de forskellige IT systemer. For eksempel kan dato være gemt som US formater mm/dd/yyyy og US tidsformat 12.00PM i et system, mens det i et andet IT system er gemt som europæisk format yyyy-mm-dd eller dd.mm.yyyy. Forskellige dato- og tidsformater kan konverteres til at være sammenlignelige, hvis de er logget konsistent, selvom det naturligvis øger kompleksiteten.

 

Værre er det hvis data ikke er logget konsistent. Hvis der for eksempel i samme IT system er logget dato- og/eller tidsformater med forskellige formater, kan det vise sig at være umuligt at konvertere dem til ensartede pålidelige data.

 

Pålidelighed

 

Pålideligheden af data er det springende punkt. Hvis data ikke er tilstrækkeligt pålidelige, kan de ikke bruges til process mining, da man risikerer at drage konklusioner på et forkert grundlag.

 

Eksempler på upålidelige data kan for eksempel være:

 

• Status kan være (”Startet”, ”I gang”, ”Afsluttet”). Hvis angivelsen af status er en manuel handling, kan der være risiko for at brugerne glemmer at angive status eller, at nogle altid undlader at sætte status ”Startet” og andre altid først sætter status til ”Afsluttet”. Desuden, hvis det er et fritekst felt, kan nogle måske skrive ”Påbegyndt” i stedet for ”Startet” etc.
• Angivelse af størrelser på tøj kunne være angivet som ”S”, ”M”, ”L” men alt efter om det er en amerikaner, dansker eller franskmand kan det betyde forskellige faktiske størrelser.
• Snyd med KPIer. Hvis brugerne skal angive en status på for eksempel håndteringen af sager, og de bliver målt på hvor hurtigt de bliver løst, kunne de snyde ved at sætte status til en værdi, der sætter målingen på pause – for eksempel ”Venter på kundens svar” selvom det ikke er den rigtige status.

 

 

Dataudtræk let tilgængeligt

 

Det har selvfølgelig en betydning, hvor let tilgængeligt data udtrækket er. Skal der bruges flere uger på at udtrække meningsfulde data fra systemerne med dertilhørende konvertering og datavask, eller kan data udtrækkes let med et simpelt SQL udtryk lavet på få minutter?

 

 

Værdifuld proces

 

Processen, der ønskes analyseret, bør være værdifuld. Jo mere værdi en proces genererer eller jo mere omkostningstung den er og jo oftere den udføres,  jo mere interessant er det at behandle den med process mining og analysere den for optimeringsmuligheder.

 

Det er selvsagt mere interessant at behandle R&D processen end processen for bestilling af mødeforplejning.

 

 

Kendte proces udfordringer 

 

Det er en fordel at tilgå process mining analysen med et sæt af hypoteser, der skal efterprøves. Derfor er det en fordel, hvis der kan udvælges en proces, hvor der er kendte udfordringer. Det er bedre at vælge en proces, hvor det for eksempel på forhånd er kendt, at processen er for langsom, at den generer mange fejl eller lignende, i stedet for at vælge en proces, der tilsyneladende fungerer fint, for derefter at undersøge eksplorativt, om der er noget, der skinner i øjnene.

 

 

Korrelation og kausalitet - en faldgrube i procesanalyse

 

Med process mining kommer man hurtigt til resultater. Men en af udfordringerne er, at fortolkningen af resultaterne og konklusionen af det man ser måske ikke kan underbygges af de data, der ligger til grund for resultaterne. Derfor er det vigtigt ikke at drage forhastede konklusioner, som der ikke er data underbygget belæg for.

 

En af faldgruberne er at forveksle statistisk bevis for en sammenhæng i tallene med en afledt årsagssammenhæng - der er forskel på korrelation i to talsæt og kausalitet (årsagssammenhæng). 

 

Korrelation opstår, når der er sammenhæng mellem udviklingen af et talsæt og udviklingen af et andet talsæt. Det kunne for eksempel være, at der kan påvises en sammenhæng mellem fejl i behandlede sager og hvilket team, der har behandlet sagerne.

 

 

Men det betyder ikke, at der er årsagssammenhæng. Man kan for eksempel ikke konkludere, at personer der ansættes i team 1 eller team 2 vil komme til at performe dårligere. Det eneste vi kan se af ovenstående data er, at der tilsyneladende er dårligere performance i team 1 og 2, men årsagen kan vi ikke konkludere på ud fra data. 

 

Team 1 og team 2 har lavet flest fejl. Så alt andet lige performer team 1 og 2 dårligere. Problemet er bare at "alt andet" aldrig er lige. Det kunne jo for eksempel være at team 1 og 2 behandler langt de fleste sager, og så er det jo ikke så mærkeligt at de også laver de fleste fejl. Spørgsmålet er om de relativt set laver flere fejl end de andre teams.

 

 

Det kræver lidt flere data:

 

 

 

Med lidt flere oplysninger kan vi nu se, at team 1 og 2 begge laver hver 5% af alle fejl. Til gengæld behandler de også langt de fleste sager, så relativt set klarer de sig ikke dårligere end de øvrige teams. Team 1 laver en fejl for hver 12 sag der behandles (svarende til 8%) men når vi ser på antallet af fejl relativt set, er team 1 det næstbedste team, og der er ikke længere en korrelation mellem teams og fejl relativt set.

 

Men hvorfor er der så nogle teams, der performer dårligere end andre? der kan være mange årsager. Måske har nogle teams mere erfarne folk end andre. Måske har nogle teams fået mere træning end andre. Måske har nogle teams oftere de svære sager under behandling. Der kan være mange årsager. Hvis en korrelation mellem teams og antallet af fejl skal underbygges af en konklusion om kausalitet, skal data beriges med de informationer, der kan underbygge det.

 

Det er en meget typisk faldgrube at forveksle korrelation (sammenhæng mellem datasæt) og kausalitet (årsagssammenhæng).

 

Karikerede sjove eksempler er for eksempel:

 

 

Det er farligt at spise is, for der er flere der drukner på de dage, hvor der sælges flest is.

 

 

Man får alvorlige sygdomme af at læse Familie Journalen (selvom der jo nok skyldes, at læserne typisk er lidt ældre og oftere får alvorlige sygdomme).

 

 

For der kan være tale om en kausal sammenhæng og altså en årsagssammenhæng, skal følgende kunne konstateres:

 

1. Der skal være en logisk sammenhæng (sammenhængen mellem teams og fejl virker logisk, sammenhængen mellem alvorlige sygdomme og læsning af Familie Journalen gør ikke)
2. Årsagen skal have været til stede før effekten (hvis folk fx først er begyndt at spise ost efter de har fået allergi, er det usandsynligt at allergien skyldes, at de spiser ost)
3. Der er flere undersøgelser, der kan understøtte påstanden om kausalitet (er der andre undersøgelser, eller andre personer, der uafhængigt også peger på at der er den kausalitet som vi selv finder, så styrker det sandsynligheden for at der faktisk er kausalitet)

 

 

 

Hvorfor er kausalitet så farlig at forveksle med korrelation? det er det først og fremmest fordi, man kan komme til at konkludere en årsagssammenhæng, som der ikke er belæg for, og derved komme til at iværksætte initiativer som enten ikke har effekt, eller som i værste fald kan have den modsatte virkning.

 

For at imødekomme risikoen for at drage en forkert konklusion om kausalitet kan man dels teste kausalitetshypotesen op imod ovenstående 3 kriterier (udover selvfølgelig at underbygge den med data), dels kan man tænke på kausaliteten og hvor den måske kunne ligge i forhold til følgende tre grupperinger af kausalitet:

 

1. Åbentlys-ikke-kausalitet (åbentlys-ikke-kausalitet hænger sammen med kriteriet om, at der skal være en logisk sammenhæng. Der er for eksempel ikke logisk sammenhæng mellem at spise is og drukne)
2. Maskeret-ikke-kausalitet (Denne kategori er typisk svær, for der er korrelation til stede og en logisk sammenhæng. Ofte kræver det videnskabelige undersøgelser eller dybe analyser for at fjerne tanken om at der er kausalitet. Det kunne for eksempel være en kausalitetshypotese om, at det at have været på barsel medfører dårligere karriere muligheder)
3. Falsk-kausalitet (Stavgang motionister får oftere slidgigt i knæene. Hvis der er en kausalitet her, kunne det måske være fordi motionisterne har tillært sig en forkert teknik, og at det ikke er stavgang motionen i sig selv, der er problemet).

 

  

Gennemsnittets forbandelse - en faldgrube i procesanalyse

 

 

Ofte når der laves statistisk overblik over performance af processer, ses der på hvordan processen performer i gennemsnit.

 

Det giver et overordnet overblik over hvordan processen performer og hvor der er flaskehalse, men der skjules vigtig information, hvis der ses på gennemsnit, uden at der ses på hvilke tal, der ligger til grund for gennemsnittet.

 

Man kan let blive snydt og dermed komme til at konkludere på et forkert grundlag.

 

 

Hvis vi antager at data grundlaget er renset for faldgruber, såsom cases der ligger udenfor vinduet, ikke-komplette cases, ikke-repræsentativt grundlag etc. er der stadig to vigtige forhold, der skal belyses for ikke at blive vildledt at gennemsnitstallene for processens performance:

 

 

• Outliers
• Gennemsnittet relativt set

 

Outliers, eller ekstremer som vi også kan kalde dem, er cases der er så store/ekstreme at de forstyrrer gennemsnittet. På nedenstående graf over distributionen af cases er der nogle cases, der tager enormt lang tid. Læg mærke til at varigheden af alle cases i gennemsnit er 25,9 dage:

 

 

 

 

 

Nedenfor ses samme oversigt men hvor de ekstreme cases er blevet fjernet. Læg mærke til at den gennemsnitlige varighed nu er 21,5 dage, hvilket er betydeligt lavere end gennemsnittet, der var påvirket af de ekstreme cases:

 

 

 

Læg i øvrigt også mærke til at medianen er den samme i begge diagrammer. Medianen repræsenterer den værdi, der ligger i midten af datasettet og dermed med lige mange cases på hver side af værdien. Medianen er ofte et bedre fikspunkt end gennemsnittet, da medianen ikke påvirkes af ekstreme cases. Jo større forskel der er på medianen og gennemsnittet jo større ekstremer er der.

 

Det skal dog også nævnes, at ekstremerne bør undersøges inden de blot ses bort fra. Er de korrekte nok og skal de dermed blive som del af analysen? Nogen gange er ekstremer opstået som følge af registreringsfejl i data, men det bør undersøges hvad der ligger til grund.

 

 

Udover outliers er det også vigtigt at se på gennemsnittet relativt set. Gennemsnittet alene er ikke et godt målepunkt. Det er altid interessant at se tallet hold op imod noget andet - Gennemsnittet er 7%, Ja, men hvad var det sidste år? 7% af hvad? spørgsmål som disse er vigtige at overveje.

 

 

 

 

Gennemsnit er fantastiske formidlere af information på en hurtig og forståelig måde. Men man skal også passe på for gennemsnit vildleder også, fordi de skjuler en fordeling af tal der liggen nedenunder, og hvis ikke man har kendskab til denne talfordeling kan gennemsnittet, især når det står alene, være vildledende.

 

Robotic Process Automation succes sikres med process mining

 

 

Robotic Process Automation (RPA) er software robotter, der automatiserer og gentager interaktioner med computer systemer, som om det var en rigtig menneskelig bruger. På den måde automatiseres opgaver, som en bruger normalt ville skulle udføre.

Teknikken ligner lidt den måde, som man tidligere lavede screen scraping af websider på, for at hente information eller sende data via en formular, men RPA er en del mere modent og avanceret.

Traditionelt set når forretningsprocesser har været automatiseret, har det været strukturerede processer, hvor data har flydt gennem veldefinerede interfaces. Med RPA automatiseres de lidt mere ustrukturerede processer, som normalt har krævet en bruger som interagerer med et interface på en skærm.

 

For at komme godt igang med RPA er der et par udfordringer, der skal håndteres:

 

1. Der skal udvælges de rigtige processer, der skal automatiseres
2. Robotten skal "trænes" til at kunne håndtere processerne 

 

Det er uhyre vigtigt at vælge de rigtige processer til RPA automatisering. Det gamle mundheld, at hvis der sættes strøm til en dårlig, ineffektiv og måske forkert proces så mange dobler man ulemperne forbundet til processen mens automatisering af en strømlinet effektiv proces mange dobler fordelene, gælder også her. Derudover er der en del erfaring der viser, at for hver krone investeret i RPA software, bruges der 10 kroner til konsulentbistand for at etablere RPA og lære robotterne, hvordan de skal udføre processerne.

 

Det er altså ikke ligemeget hvilke processer, der udvælges til RPA.

 

I forbindelese med udvælgelse af processer der skal automatiseres har flere RPA implementeringer en proces matrix, som forretningsbrugerne udfylder med oplysinger om hvilke processer de har, hvor ofte de udfører dem, hvor lang tid de bruger på udførslen og i hvor høj grad de er strukturerede og ikke behøver subjektive (menneskelige) beslutninger.

 

Udfordringen er, at det ofte er subjektive vurderinger, der ligger til grund til denne evaluering. Sammenholdt med den relativt store investering som RPA kan være, er det en fordel at gå mere objektivt til værks i forbindelse med udvælgelse af hvilke processer, der skal automatiseres med RPA. Det er her process mining kommer ind i billedet (klik her for en kort introduktion til process mining)

 

Følgende spørgsmål er relevante at vide noget om, for at kunne udvælge de processer der skal automatiseres, og nedenfor beskrives hvordan process mining kan give et objektivt svar på hvert af spørgsmålene:

 

1. Hvilke processer har vi?
2. Er processerne optimale?
3. Er frekvensen af procesudførslen oplagt til automatisering?
4. Hvor lang til bruger vi på processerne? 
5. Er processerne baseret på objektive regler?

 

 

 

Ad 1) Hvilke processer har vi?

 

Hvilke processer har vi? hvordan hænger de indbyrdes sammen? viser vores proces tegning processen som den er eller som vi tror den er eller som vi kunne tænke os den er? Det er altsammen rigtig gode spørgsmål og sjældent nogle, der kan gives et præcist svar på, fordi der er for meget subjektivitet involveret. Med process mining kan der ud fra faktuelle data i de eksisterende IT systemer genereres et overblik over de processer der er, baseret på fakta.

Nedenfor ses et udsnit af en proces tegning, der er genereret med process mining. Der fås et overblik over hvilke processer der findes og hvordan de indbyrdes hænger sammen. Alle IT understøttede processer er identificeret - ikke kun dem som interview personer kunne huske eller dem som vi har nået at tegne op.

 

 

 

 

 

Ad 2) Er processerne optimale?

 

Som tidligere omtalt er det ikke fornuftigt at automatisere en dårlig proces. Derfor giver det god mening at sørge for at processen er optimal, inden der lægges automatisering ned over.  

 

Process mining giver mulighed for at analysere processen og derefter optimere den. I eksemplet fra Ad 1) kunne man stille sig følgende spørgsmål om processen:

 

Hvorfor sker der en tidlig ændring af rekvisitionen (Amend Purchase Requisition) i ca. 2% af tilfældene. Er det tegn på en dårligt udført proces?, manglende træning? eller?

Hvorfor stopper ca 10% af alle sager efter indkøbsrekvisitionen er analyseret første gang (Analyze Purchase Requisition)? Er det fordi brugeren ikke ved hvordan man kommer videre? Er der noget galt med processen?

Hvorfor er der forskellige forløb allerede efter indkøbsrekvisitionen er oprettet (Create Purchase Requisition)? Er det meningen? kunne det ensrettes, så der er en mere ensartet simpel proces?

 

 

 

Hvorfor er der så mange varianter af processen. Altså forskellige veje fra start til slut når der foretages indkøb via indkøbsrekvisitioner (som illustreret nedenfor)? Er det tegn på en dårligt udført proces? Kan det ensrettes noget mere? Er det tegn på for mange subjektive ikke-IT-understøttede beslutninger i processen?

 

 

 

 

Ad 3) Er frekvensen af procesudførslen oplagt til automatisering?

 

De processer der hyppigst udføres er naturligvis bedre kandidater til automatisering end de processer der sjældent udføres. Men hvilke processer udføres hyppigst? 

Med process mining skabes let et overblik over hvilke procestrin der hyppigst udføres (som vist nedenfor) baseret på et faktuelt grundlag.

 

 

 

 

 

Ad 4) Hvor lang til bruger vi på processerne? 

 

Men det er ikke nok at vide hvilke processer der hyppigst udføres. For at udvælge de rigtige automatiseringskandidater er det også nødvendigt at vide hvor lang tid det tager at udføre de enkelte processer.

Det overblik skabes også med process mining (som vist nedenfor) baseret på de faktiske data:

 

 

Her kunne processen også underlægges analyse. Der er for eksempel procestrin hvor der er stor variation af hvor lang tid det tager at udføre procestrinnet. Det kan være der er en god grund til dette, men det kan også være at processen kunne ensrettes og strømlines.

 

 

Ad 5) Er processerne baseret på objektive regler? 

 

Det siger sig selv, at det er nemmere at automatisere processer hvor de beslutninger der skal tages undervejs under udførslen baserer sig på objektive beslutningsregler, end hvis de baserer sig på subjektive vurderinger foretaget af brugeren.

Identificeringen af om der er subjektive beslutningsregler kan være vanskelig. Men der er en tendens til at processer, der er veldokumenterede med høj detaljegrad og med få variationer i udførslen oftere baseres på objektive beslutningsregler - og her kan process mining være med til lettere at identificere dette.

 

 

 

 

 

Foredrag på High Tech Summit Copenhagen 2017

  

 

 

Som taler på "Business Process Mining" sporet på årets High Tech Summet konference, præsenterede jeg process mining arbejdet for baggagefabrikken i Københavns Lufthavn. Med mere end 55 udstillere, 150 talere og 220 start-ups - og ikke mindst 2550 personer registreret, var der lagt op til en indholdsrig konference.

 

Vinklen på mit indlæg var den forretningsmæssige vinkel og ikke så meget den tekniske udførsel eller teknologien omkring process mining. Tilhørende fik mulighed for at høre om en virkelig brug af process mining og høre hvilke erfaringer lufthavnen fik.

De væsentligste forretningsmæssige erfaringer kan opsummeres i følgende:

 

• Ja, det er muligt at få fat i data
  • En vigtig erfaring er, at det ikke var en stor barriere at få fat i data at lave process mining på. Data blev eksporteret fra en SQL database, og efter et par iterationer havde vi tilstrækkeligt datagrundlag. 
• Information er lettere og hurtigere tilgængelig
  • Københavns Lufthavne har en analyse afdeling, hvorfra der allerede foretages performance analyser af forskellig slags. Nogle af de ting vi identificerede, kunne godt være tilvejebragt anderledes. Men med process mining var det væsentligt nemmere og hurtigere at komme frem til den information.
• Det kan betale sig at se på processen fra forskellige synsvinkler
  • Den umiddelbare proces gav ikke så mange indsigter fra procesdiagrammet, da processen var kendt, men det var udførslen (performance) der var interessant at se på. Ved at sammenlægge aktivitetstrin med den fysiske lokation blev det muligt at se på processen fra en anden vinkel og se på performance mellem aktiviteters fysiske lokation. 
• Forretningen fik lettere ved at engagere sig
  • Process mining præsenterer en del information i et let tilgængeligt visuelt format. Det visuelle overblik samt det faktum at visualiseringerne byggede på faktiske data gjorde, at personerne fra forretningen i højere grad tog analyserne og resultaterne til sig, end det ofte ellers er tilfældet med traditionelle analyser og rapporteringer. 
• Domæne kendskab er en stor fordel
  • Når der deltager personer med dyb forretningsviden, er det nemmere at identificere interessante indsigter, som måske ikke er åbentlyse.
• Proces analyse kompetencer er en stor fordel
  • Det er nødvendigt at analyseprocessen drives af en person med dyb kendskab til proces analyse, for at undgå faldgruber og forkerte konklusioner.
• Mavefornemmelser kan understøttes med facts
  • Nogle indsigter understøtter mavefornemmelser som personer fra forretningen allerede havde, men at det underbygges med faktuelle data gør, at det bliver muligt at forfølge såvel udfordringer som løsninger.

 

Derudover kommer de hårde analyse facts, som analysen viste:

 

• Procesudfordringer var ikke centreret omkring bagagebåndene med i højere grad ved manuel indgriben 
• Baggage fabrikken performeede dårlige i weekender
• Hvor lang tid ligger bags på ventelager
• Hvor ofte cirkuleres bags rundt i baggagefabrikken
• Hvor ofte sendes bags til manuel håndtering
• Hvor lang tid går der fra en bag er checket indtil vi ser den for første gang i baggage fabrikken (opdelt på terminal lokationer)

  

 

Se beskrivelse af den officielle case om process mining i baggagefabrikken i Københavns Lufthavne

Download Fuldt program High Tech Summit 2017

Download CPH Baggage process mining - HighTectSummit2017_Final

 

Forudsig udfaldet af dine forretningsprocesser

 

Process mining benyttes til at danne et overblik over hvordan forretningsprocessen ser ud. Desuden kan man i datasættet se de igangværende cases.

Udover et overblik over processen og de involverede cases får man mulighed for at se performance statistik og lave årsagsanalyser og performance analyser på processen og de involverede cases.

 

Det næste skridt er, udfra de kendte data, at kunne forudsige hvordan cases, der allerede er igang, vil udvikle sig og hvordan cases, der ikke er igang endnu, formentlig vil udvikle sig. Man kan ikke sige, at fordi der er 20% af de involverede cases der ender på en bestemt måde (for eksempel ender med en annulleret ordre) at så er der 20% sandsynlighed for, at den næste case vil ende som en annulleret ordre. Der skal lidt mere sandsynlighedsregning til, og man skal se på de karakteristika, der kan give udslaget.

 

Overordnet set er der 3 områder det er oplagt at lave forudsigelser på, når vi ser på de enkelte forretningsprocesser:

 

1. Forudsige for en case hvor lang tid der er tilbage før den afsluttes
2. Forudsige for en case hvad den næste aktivitet vil være
3. Forudsige for en case hvordan den ender

 

 

Hvornår vil en case ende? hvad ender den med? hvad er det mest sandsynlige næste trin?

 

 

Der er mange situationer, hvor det kan være nyttigt, med nogenlunde pålidelighed, at kunne forudsige udfaldet af igangværende cases. For eksempel når en kunde ringer ind til sit forsikringsselskab og spørger hvornår en skadesanmeldelse er færdigbehandlet - her kan forsikringsselskabet give et estimat for dette. Eller et universitet kan forudsige hvilke studerende, udfra deres studieadfærd, der højst sandsynligt vil ende med at dumpe, og så sætte ind med tiltag, der skal rette op på dette.

 

For at kunne lave forudsigelser på cases i processen, skal process mining værktøjet kunne tage information fra proces modellen, lære fra de cases der har gennemløbet den og bruge disse informationer til at lave forudsigelser. Det vil sige, at process mining værktøjet skal have indbygget en form for machine learning eller predictive analytics - og det er der flere af dem, der allerede har.

Hvis process mining værktøjet ydermere har direkte forbindelse til realtime data, vil det være muligt at foretage forudsigelser (predictive analytics på processen) - realtime.

 

 

 

 

Persondataforordningen og process mining

 

Persondataforordningen kræver overholdelse af reglerne omkring behandling af persondata. Persondata er alle data, der er personhenførbare til en fysisk levende person og gælder for data, der er gemt automatisk eller i registre (også fysiske registre).

 

Det at arbejde med persondataforordningen er i høj grad en compliance øvelse, som går på at sikre efterlevelse af reglerne - men det er også samtidig en teknisk og procedural sikkerhedsøvelse. Faktisk kan man opdele compliance med persondataforordningen i følgende generelle emner:

 

• Er virksomheden omfattet af persondataforordningen
• Retsmidler, ansvar og sanktioner
• Datasikkerhed og databeskyttelse (herunder organisatorisk sikkerhed (alle skal ikke have adgang til alt)  
• Opfyldelse af den registreredes rettigheder

 

Det er en overordnet grovinddeling. I denne blog post vil jeg fokusere på forretningsprocesserne og hvordan process mining kan have en rolle. Eller sagt på en anden måde, så vil jeg have fokus på hvad virksomhederne skal gøre i forhold til analyse, dokumentation og tilpasning af forretningsprocesser og IT systemer og ikke fokusere på jura eller IT sikkerhed - men stadig med det overordnede fokus: Kan man med fordel gøre brug af process mining.

  

Man skal være opmærksom på, at dokumentation er meget centralt i forhold til forordningen og man kan som udgangspunkt sige, at hvis noget ikke er dokumenteret, så er det som udgangspunkt ikke håndteret.

 

For at svare på spørgsmålet om virksomheden er compliant med persondataforordningen, er der en række principper, der skal efterleves. Det første der skal konstateres er om virksomheden er omfattet af persondataforordningen. Dernæst ser vi på hvad virksomheden i så fald skal gøre og her er mit fokus,  som sagt, på IT systemer og forretningsprocesser i relation til om man med fordel kan bruge process mining.

  

Nedenfor ses et overordnet forretnings-beslutningsdiagram, der kan afdække om virksomheden er omfattet af persondataforordningen (klik på link til pdf udgave for stor størrelse). Bemærk at diagrammet udelukkende indeholder beslutningsfigurer og ikke en eneste procesfigur. Det er fordi konstateringen af om virksomheden er omfattet af persondataforordningen er en juridisk/beslutningsmæssig vurdering, og der indgår som sådan ikke en forretningsproces i dette forhold. I diagrammet er der henvisninger til de relevante Artikler i persondataforordningen, hvor flere detaljer kan findes.

 

Download Underlagt persondataforordningen (pdf fil der kan vise diagrammet i større format)

 

 

Lad os antage at virksomheden er omfattet af persondataforordningen. Spørgsmålet er nu: hvad skal virksomheden så gøre?

 

 

Den dataansvarlige skal sikre at (ikke udtømmende liste): 

1. Når data indsamles, oplyses der om formålet med indsamlingen af persondata (Artikel 13+14)
2. Persondata kun benyttes til det oplyste formål (Artikel 5)
3. Persondata kun benyttes hvis nødvendigt (Artikel 5)
4. Persondata kun opbevares, sålænge det er nødvendigt (Artikel 5)
5. Persondata slettes eller anonymiseres når påkrævet og uden unødig forsinkelse (Artikel 17)
6. Persondata kan udleveres i maskinlæsbart format (Artikel 20)
7. Sikre at persondata er up-to-date før de benyttes (Artikel 5)
8. Dokumentere behandling og overholdelse af lov (Artikel 24)
9. En registrerets persondata kan findes frem og dokumenteres. Den registrerede har ret til indsigt omkring registrerede oplysninger og behandling af disse (Artikel 15)
10. En registrerets persondata kan findes frem og rettes. Den registrerede har ret til ajourføring/rettelse af urigtige data (Artikel 16)
11. En registrerets persondata kan findes frem og slettes. Den registrerede har ret til sletning - man har retten til at blive glemt (Artikel 17)
12. En registrerets persondata kan blokeres for behandling. Den registrerede har ret til begrænsning af behandling af ens data under visse omstændigheder (Artikel 18)

 

For at sikre ovenstående er den dataansvarlige nødt til at:

 

1. Vide hvilke persondata der gemmes og behandles
2. Vide hvor persondata gemmes og behandles (i denne blog post ses bort fra kravene til hvilke geografiske lokationer data gemmes for udelukkende at fokusere på det procesmæssige aspekt)
3. Sikre at kravene til behandling af data overholdes

 

 

I nedenstående vil jeg komme ind på hvordan disse 3 genrelle krav til den dataansvarlige kan tilgås og hvordan process mining kan være et vigtigt og effektivt værktøj i den forbindelse.

 

 

Ad 1) Vide hvilke persondata der gemmes og behandles

 

Her er virksomheden nødt til at vide hvilke persondata, der gemmes og behandles.  I dette trin er det nok at vide præcist hvilke data, der gemmes og behandles samt typen af persondata (samt hvor data er indsamlet - Se præcise krav til dokumentation af hvilke person data der gemmes og behandles i persondataforordningen). 

Dokumentationen af dette kunne godt tilvejebringes via den dokumentation, der allerede måtte ligge, eller man kunne fx lave data mining på dataelement titler, der indeholder henvisninger til noget, der kunne være personhenførbart som fx navn, titel, adresse etc. Bemærk dog, at data ikke altid gemmes i dataelementer og tabeller med sigende navne.

 

Nedenfor vises et eksempel på tabeller, der er identificeret som indeholdende persondata. Via denne dokumentation kan vi nu påvise hvilke persondata, der gemmes (database diagrammet nedenfor er ikke normaliseret til 3. normalform, men blot lavet som eksempel).

 

 

 

 

 

Ad 2) Vide hvor persondata gemmes og behandles

 

I Ad 1) er det et eksempel på dokumentation af hvilke persondata der gemmes. Men det er nødvendigt at vide og dokumentere hvor persondata gemmes, og hvor de benyttes. En person skal for eksempel kunne henvende sig og få oplyst hvilke data, der er gemt om vedkommende og hvad de benyttes til - her er det ikke sikkert, det er tilstrækkeligt at dokumentere de oplysninger, der er gemt. Endvidere kan man blive pålagt at ophøre med behandlingen af persondata for en bestemt person - i det tilfælde er det afgørende ikke alene at vide hvilke persondata der gemmes, men også at vide hvor de bruges. Desuden skal det dokumenteres hvor data fysisk gemmes geografisk, dette ligger dog udenfor scope her.

 

Dokumentationen af hvor persondata benyttes kan tilvejebringes ved at knytte persondata oplysninger til forretningsprocesser. For at gøre dette er man nødt til først at dokumentere forretningsprocesserne. Dette kan gøres ved den traditionelle metode med workshops, interviews, brownpapers etc. Man kunne også benytte process mining til at identificere forretningsprocessen.

Nedenfor ses et diagram, der vises processen for en indkøbsproces, som er genereret med process mining:

 

 

 

 

Dette diagram viser processen, men det fremgår ikke, hvor der gøres brug af persondata. Hvis man antager, at man udfra en viden om hvilken roller, der udfører hvert procestrin let kan identificere hvilke steder, der behandles persondata, kunne diagrammet genereres med den information og se således ud (efter processtrin navnet vises rollen, der udfører aktiviteten adskilt af "//":

 

 

 

Hvis vi zoomer lidt ind på processen, er det lettere at se dokumentationen af hvilken rolle, der udfører hvert trin:

 

 

Man kan nu filtrere procestrin væk, der udføres af roller, som ikke behandler persondata i forbindelse med deres behandling - fx Supplier, Purchasing Agent og Financial Manager. 

Det giver et procesdiagram over de procestrin hvor der behandles persondata, der ser således ud:

 

 

 

I listeform er det følgende procestrin, hvor der behandles persondata:

 

 

Ovenstående er lavet ud fra et data udtræk, der indeholdt information om hver enkelt case inklusiv rollen, der udfører hvert trin. Hvis man til hvert procestrin også udtrækker information fra IT systemet omkring hvilke persondata, der er blevet behandlet i det pågældende procestrin, kan det give en mere præcis dokumentation af, hvor persondata er blevet behandlet.

 

Et dataudtræk kunne nu se således ud:

 

 

 

Læg mærke til, at udtrækket af data nu indeholder de persondata, der benyttes i hvert proces trin. Nedenfor er der zoomet ind på et udsnit af de data og de er markeret med gul:

 

 

 

 

Hvis vi så manipulerer udtrækket og sætter et true/false flag ud for hvert proces trin, der angiver om proces trinnet behandler persondata, er det let at lave process mining på udtrækket og få vist præcist hvilke proces trin, der involverer persondata - som vist nedenfor:

 

 

 

 

Ved at logge brugen af persondata i systemet og medtage de oplysninger i udtrækket der foretages process mining på, er det nu nemt at finde yderligere informationer. Hvis K. Larsen henvender sig med spørgsmål om hvilke oplysninger, der er registreret om hende og hvor de bruges, kan dette overblik skabes øjeblikkeligt. Et udsnit af et eksempel er vist nedenfor:

 

 

 

Her kan man endvidere straks se, hvem der har behandlet data og hvornår, samt hvilke data der er behandlet.

 

Hvis nu man tog skridtet videre, kunne man også logge i systemet hvilke Views, der er involveret i hvert proces trin, eller ligefrem hvilke objekter/funktioner, der læser, opretter, ændrer eller sletter persondata. Det ville give et lynhurtigt overblik over hvilke views i systemet, der behandler persondata og dermed hvilke views, der skal laves begrænsninger i, hvis der for eksempel skal stoppes for behandlingen af persondata for bestemte personer.

 

 

 

 

Ad 3) Sikre at kravene til behandling af data overholdes

 

Man skal som databehandler sikre, at kravene til behandling af data overholdes. Som det ses i ovenstående, er process mining et særdeles velegnet værktøj til at sikre dette. 

Som nogle af fordelene, ved at benytte process mining til overholdelse af persondataforordningen, kan nævnes:

 

1. Forretningsproces overblikket kan automatisk genereres på baggrund af data, der allerede findes i IT systemerne
2. Dokumentation af hvilke persondata der benyttes hvornår, kan indbygges i systemerne og dermed er dokumentationen dynamisk og automatisk altid ajourført
3. Det kan let dokumenteres, hvem der behandler persondata og hvornår det er sket
4. Det kan let dokumenteres hvilke views i systemet, der behandler persondata og som måske skal begrænse behandlingen af bestemte personer
5. Det kan let dokumenteres om data er slettet

 

 

John Hansen - GDPR Certificeret gennem Kromann-Reumert 

Et overblik over process mining tools

 

Der er efterhånden ved at komme mange process mining tools på markedet. Der er tools der er indbygget i store BPM suites, open source tools og stand alone tools.

 

Nedenfor lister jeg en række af de, i skrivende stund, væsentligste process mining tools på markedet. Så kan du selv danne dig dit eget indtryk af værktøjerne.

 

 

Celonis - www.celonis.de

Disco - www.fluxicon.com

Perceptive - www.lexmark.com

QPR - www.qpr.com

PPM - www.softwareag.com

ProM - www.promtools.org

ProM Lite - www.promtools.org

RapidProM - www.rapidprom.org

Signavio Process Intelligence - http://www.signavio.com/products/process-intelligence/

EDS - www.stereologic.com

Fujitsu Interstage Business Process Manager Analytics - www.fujitsu.com

Icaro EVERFlow - www.icarotech.com

LANA Process Mining - www.lana-labs.com

Minit - www.minitlabs.com

myInvenio - www.my-invenio.com

Exeura - www.exeura.eu

SNP Business Process Analysis - www.snp-bpa.com

 

 

Data analyse af fodboldkamp - holdets samarbejde og taktik

 

 

Min partner Emmy Dudok og jeg har arbejdet intensivt med process mining analyse af fodboldkampe og andre sports kampe. Kampene indeholder netop en række processer, der gør os i stand til at identificere hvor godt holdene samarbejder, følger taktikken og bedst kommer til chancer og mål.

 

Emmy har forfattet en case story om hvordan fodbold og andre sports kampe kan analyseres ved brug af process mining. Se den danske version her:  Download DK Mere end assists - afdækning af DNAen for Oranje

 

 

Statistikker omkring fodboldkampe er ikke noget nyt - men analyse hvor det er samarbejdet og holdets performance der analyseres med process mining, er normalt ikke en del af de kendte sports statistikker.

 

 

Kontakt os gerne for mere information.

 

 

Top 5 faldgruber i analyse af ITIL data

 

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.