Fra 2017: Prosessforbedring med Robotic Process Automation (RPA)

Skrev denne artikkelen i 2017 da jeg arbeidet en del med RPA, og den er fortsatt relevant, så tenkte dele den her også.

“All work is process work”, sa prosessguru Michael Hammer. Selv om det er sant, så kan prosessarbeid ha mange former. I denne bloggen følger noen betraktninger om særegenheter ved å arbeide med prosesser på automatiseringsnivå. 

Prosessarbeid på ulike nivåer av detalj tar ulik form. På høyeste nivå er fokuset gjerne på verdikjeder og deres delprosesser, eksempelvis «Produser varer». Arbeidet inkluder å forstå verdiskapningen, sekvens mellom prosesser, relasjon til avdelinger, hvem som er ansvarlig for å understøtte hva, samt hvilke mål og krav som gjelder. På middels detaljnivå, menneskelig nivå, er fokuset ofte på arbeidsflytdiagrammer. Disse viser hvem som gjør hva i hvilken rekkefølge, og brukes for å standardisere / forbedre hvordan en arbeider og for å oppnå bedre eller konsistente resultater, samsvar, og lignende. Eksempelvis prosessen «Gjennomfør ansettelse», kan en se for seg som en mindre og mer detaljert prosess enn «Produser varer». Et tilbakevendende tema på dette nivået er om ulike kontorer og geografiske lokasjoner kan dekkes av samme prosessmodell. Eksempelvis kan en ende opp med en «hovedkontormodell» samt en rekke «lokalkontorvarianter».

Det laveste detaljeringsnivå kan gjerne kalles automatiseringsnivå. Her er prosessene ofte veldig små.

Eksempelvis kan en se for seg en del klikk og tastetrykk i ett eller flere datasystem som utgjør prosessen «Registrer sak». Det er her en typisk arbeider med Robotic Process Automation (RPA). Da formålet med kartlegging og standardisering på dette nivået ofte er automatisering så må detaljeringsnivået nødvendigvis være så høyt som relevant automatiserings-software krever. 

For en RPA software innebærer dette gjerne hva vi kaller detaljering på «tastetrykknivå». I disse prosessbeskrivelsene indikeres hver eneste aktivitet et menneske gjør som et eget steg som roboten potensielt skal utføre. Jeg skriver potensielt fordi roboten har egenskaper som gjør at den ofte kan arbeide mer effektivt og annerledes enn mennesker. Den har for eksempel mildt sagt veldig god hukommelse. For å utnytte dette maksimalt må roboten av og til arbeide litt annerledes.

Når man dokumenterer en prosess på dette detaljnivået er variasjon og kompleksitet noe en raskt møter. En oppdager at prosesser ikke bare kan være forskjellige på tvers av geografiske lokasjoner / kontorer, men også har en rekke forgreninger / saksvarianter (se figur 1).

Figur 1: Prosess med lokasjonsvarianter og saksvarianter per lokasjonsvariant

Figur 1 viser hvordan en prosess i første omgang har tre lokasjonsvarianter. «The happy path», altså stegene som utføres i en standard ideal vellykket sak, er i eksempelet relativt like på tvers av lokasjonene, men forgreningene ut fra «happy-path» er mange og relativt forskjellige. Alternative forløp og forgreninger av en prosess kalles saksvarianter og «cases» på engelsk.

Da mennesket var utførende av prosessen eksisterte den samme kompleksiteten og variasjonen. Men nettopp fordi mennesket utførte prosessen manuelt, var det ikke behov for å definere regler og standardisere prosessen i like stor grad. Når en da arbeider med forskjeller på tvers av lokasjoner skjer det ofte med fokus på “happy-path” og ikke “for detaljert”. På automatiseringsnivå kan en ikke la ting forbli taus kunnskap, overse potensielle forgreninger eller unntaksutfall. Roboten er ikke smartere enn vi gjør den, så en må tvert imot møte og håndtere all kompleksiteten.

Under følger noen eksempler på noen (ikke uttømmende) forskjellige mulige saksvarianter fra lokasjonsvariant A fra prosessen over, der hvert tall representerer en aktivitet:

Figur 2: Lokasjonsvariant A med saksvarianter

·        Saksvariant A: 1a,2,3,4,5,6,7,8,9,10 (happy-path)

·        Saksvariant B: 1b,2,3,4,5,6,7,8,9,10

·        Saksvariant C: 1a,2,11,12,13,6,7,8,9,10

·        Saksvariant D: 1a,2,11,12,14,15,16,8,9,10

·        Saksvariant E: 1a,2,3,4,5,17,18,19,20,10

Eksempelet illustrerer at en prosess egentlig består av en rekke saksvarianter. Saksvariantene oppstår på grunn av forretningsreglene som styrer prosessen kombinert med sakens input, og andre elementer som feil og lignende. Dette gir forgreninger. En forgrening i dette eksempelet kan skyldes manglende informasjon i søknaden som mottas (input), eller at kunder skal behandles forskjellige etter ting som medlemskap, alder, osv (forretningsregler). Når prosessen skal automatiseres er det derfor viktig å være klar over at selv tilsynelatende enkle prosesser ofte er mer komplekse enn de ser ut til på overflaten. Personer i IT er gjerne mer kjent med dette, men det er ofte nytt for forretningssiden.

For RPA prosjekter betyr dette at en tidlig i prosjektet må kartlegge alle forretningsregler og saksvarianter i prosessen. Deretter bør fokuset være på å automatisere såkalt «happy path», den saksvarianten som utgjør et standard vellykket forløp. Det er gjerne her det er størst volum og best forretningscase. Deretter kan automatiseringen utvides saksvariant for saksvariant så langt det lar seg gjøre og er kost/nytte-effektivt. De variantene som vil forbli mer manuelle er de som innebærer mest kreativitet / skjønn eller har veldig lavt volum / er lite lønnsomme å automatisere. Disse kan roboten sende til manuell behandling eksempelvis via epost, lagre en fil eller ved å legge de tilbake i en eller annen kø.

De færreste virksomheter forvalter i dag dokumentasjon tilstrekkelig detaljert og korrekt strukturert for automatisering. Godt samarbeid med prosessens superbrukere blir følgelig kritisk når en initierer RPA prosjekter. Superbrukere er ansatte som er spesielt dyktige på og / eller har lang fartstid med å utføre prosessen. I løpet av dette arbeidet avdekkes, artikuleres og dokumenteres prosessens struktur, samt en rekke forretningsregler (i noen tilfeller for første gang). Denne avdekkingen av regler utgjør en god mulighet for ledere til å vurdere om de fremdeles er gode og ønskelige.

Arbeidet med Robotic Process Automation innebærer i tillegg en rekke tema som blant annet analyse og potensiell standardisering av input, interaksjon og samspill med forskjellige IT-systemer, kjøremønster og orkestrering, logging og varsling, ansvarsavklaringer og eierskap av prosess og prosjekt, samt kontinuitetsplanlegging.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s