RPA i et forvaltningsinformatisk perspektiv
En tematisk analyse om bruken av RPA i tre virksomheter
Masteroppgave ved Avdeling for forvaltningsinformatikk Kandidatnummer 120742
30.06.2021 Antall ord: 15102
Takk til Statnett, Statkraft og Avinor for samarbeidet, takk til Eilif for veiledningen,
takk til gjengen på lesesalen for alle faglige og ufaglige diskusjoner og takk til Kristin som har holdt ut og støttet med meg gjennom arbeidet.
1
Sammendrag
I denne masteroppgaven ser jeg på hvordan tre forskjellige virksomheter knyttet til
statsforvaltningen bruker RPA. Jeg har undersøkt hvilke typer oppgaver de automatiserer med RPA, hvordan de går frem for å velge ut de ulike oppgavene de automatiserer og hvilke vurderinger de gjør knyttet opp mot regelverk når de automatiserer. Jeg bruker teorien om lettvekts IT for å se hvordan den teknologiske endringen påvirker organisatoriske og rettslige valg. De tre bruker RPA for å automatisere gjentagende kontoroppgaver som sortering av meldinger, hente informasjon fra ulike kilder og fylle den inn i de aktuelle systemene og for å få til økt samhandling mellom systemer som ikke er koblet sammen. De tre har gjort forskjellige valgt når det kommer til hvordan de organiserer arbeidet med RPA. Det viste seg at vurderinger rundt regelverk ikke var noe det ble lagt noe stor vekt på når en prosess ble automatisert med RPA. I tillegg har jeg sett på hvordan det er å faktisk
programmere boter og går gjennom en bot steg for steg.
2
Innholdsfortegnelse
Sammendrag ...1
1 Innledning ...4
2 Metode ...6
3 Teori ...9
3.1 Det forvaltningsinformatiske hjulet...9
3.2 Hva er Robot Process Automation?... 10
3.3 Lettvekts IT ... 12
3.4 Bruksområder for RPA ... 14
3.5 Kjennetegn for prosesser hvor automatisering gir gevinst ... 15
3.5.1 Svært mange transaksjoner... 17
3.5.2 Særdeles viktige eller verdifulle transaksjoner ... 17
3.5.3 Hyppig bruk av flere systemer ... 17
3.5.4 Stabile omgivelser ... 17
3.5.5 Lite menneskelig inngripen ... 18
3.5.6 Få unntak ... 18
3.5.7 Lett å gjøre feil manuelt ... 19
3.5.8 Enkel å bryte ned til delprosesser... 19
3.5.9 Godt forstått manuell kostnad ... 19
3.6 RPA eller andre former for automatisering ... 19
3.7 Min erfaring med UiPath ... 21
3.8 Et eksempel på programringen av en bot ... 23
4 Tre forvaltningsorganisasjoner ... 32
4.1 Statnett ... 32
4.2 Statkraft ... 34
4.3 Avinor... 37
4.3.1 Informant 4 ... 38
4.3.2 Informant 5 ... 38
5 Funn og analyse ... 41
5.1 Robot Process Automation er en teknologi Statnett, Statkraft og Avinor bruker for å lage midlertidige løsninger. ... 41
5.2 Gevinster og midlertidighet ... 41
5.3 RPA kan gi skyggeløsninger ... 42
3
5.4 Kjennetegnene og virksomhtene ... 43
5.5 Hvordan har de valgt å organisere arbeidet med RPA i organisasjonene sine? ... 43
5.6 Både Avinor og Statkraft innså at de måtte kastet seg på RPA etter å ha fått demonstrert teknologien hos andre. ... 44
5.7 Lite fokus på regelverk i utviklingsprosessen ... 45
5.8 Avinor har valgt å ikke bruke RPA i sikker sone før de blir mer kjent med teknologien. ... 46
5.9 Samhandling ... 47
6 Avslutning ... 47
7 Referanser ... 50
4
1 Innledning
I denne masteroppgaven ser jeg på bruken av robotic process automation i de tre virksomhetene Statnett, Statkraft og Avinor. Dette er en teknologi som ikke lenger får like mye oppmerksomhet som for noen år siden. Som Figur 1-1 under viser, er RPA nede i bølgedalen på hype syklusen til Gartner.
Samtidig spår Gartner at denne teknologien vil nå produktivitetsplatået i løpet av to år.1
Digitaliseringsdirektoratet påpeker i rapporten: Oversikt over digitaliseringstiltak i staten. Status for 2019 at virksomhetene har et potensial når det kommer til å ta i bruk teknologier som RPA.2 Dette tyder på en teknologi som vil kunne by på mange nye muligheter. Da dukker naturlig nok spørsmålet om hvordan RPA kan brukes i forvaltningen opp. Det er det jeg ønsker å belyse i denne oppgaven.
Figur 1-1 Gartners hype syklus for juridiske- og samsvarsteknologier juli 20203
1 (van der Meulen 2020)
2 (Digitaliseringsdirektoratet 2020)
3 (van der Meulen 2020)
5 Jeg har endt opp med å gjøre undersøkelser hos Statnett, Statkraft og Avinor. Disse tre
virksomhetene er alle eid av staten, men de har en veldig liten grad av myndighetsutøvelse.
Statnett er et statsforetak eid av staten ved Olje- og energidepartementet.4 Hovedoppgaven til Statnett er som OED skriver: «å være det systemansvarlige nettselskapet i Norge.»5 Denne rollen gir dem myndighet til å fatte vedtak knyttet til strømnettet. Det er særlig på ett område at Statkraft skiller seg ut fra de to andre, nemlig det at de aktivt konkurrerer i det åpne markedet. Statkraft er organisert som et aksjeselskap som i sin helhet er eid av Statkraft SF. Dette statsforetaket er i sin tur eid av Nærings- og fiskeridepartementet.6 Avinor sitt samfunnsoppdrag er å sikre gode
luftfartstjenester i hele landet.7 De eier, driver og utvikler en rekke sivile flyplasser og de leverer flysikringstjenester til både sivil og militær sektor.8 De er organisert som et aksjeselskap som er fullt ut eid av staten ved Samferdselsdepartementet.9 Alle tre har lange historiske røtter i staten med statskraftverkene og luftfartsverket. Tabell 1-1 under viser en enkel oversikt over de tre
virksomhetene jeg har undersøkt.
Tabell 1-1 Enkel oversikt over de tre virksomhetene
4 (Olje- og energidepartementet u.d.)
5 (Olje- og energidepartementet u.d.)
6 (Statkraft u.d.)
7 (Avinor u.d.)
8 (Avinor u.d.)
9 (Samferdselsdepartementet u.d.)
Statnett Statkraft Avinor
Utøver
offentligmyndighet
Ja, gjennom systemansvaret for kraftsystemet
Nei Nei, men leverer tjenester
Konkurranseutsatt Nei, har tilnærmet monopol
Ja deltar i det åpne kraftmarkedet på like vilkår
Nei
Finansiering Inntekter fra utenlandskablene, nettleie ol.
Kjøp og salg av kraft, etc. Får noe innskudd til større prosjekter
Driftsinntekter som overskudd av tax-free og avgifter flyselskaper må betale.
Antall ansatte 1400 4500 3300
Eid av Olje og
energidepartementet
Nærings- og
fiskeridepartementet
Samferdselsdepartementet
6 For å få noe innsikt i hvordan forvaltningen bruker RPA har jeg delt opp spørsmålet i mindre deler.
Jeg har sett på
• Hvilke typer oppgaver RPA brukes til (for eksempel om å fordele meldinger, ulike HR oppgaver, fakturering).
• Hvilke vurderinger gjøres for å velge ut prosesser som passer til RPA.
• Hvordan organiseres arbeidet med RPA.
For å tolke svarene fra intervjuobjektene har jeg brukt det forvaltningsinformatiske hjulet (Figur 3-1) til Schartum,10 teorien om lettvekts IT11 samt annen forskning på RPA. Det er i tillegg være innslag av gevinstrealisering og teknisk, juridisk, semantisk og organisatorisk samhandling. For å bedre forstå hvordan RPA boter lages har jeg også lært meg å lage enkle RPA løsninger. Gjennom arbeidet har jeg laget flere boter og jeg viser et eksempel senere i oppgaven. Dette har vært et gøyalt avbrekk fra å lese lange engelskspråklige fagartikler. Jeg har også gjort dette for å teste om det faktisk er lett å lære seg, men jeg har ikke laget noe strengt vitenskapelig opplegg for dette.
Videre gjør jeg først rede for metoder i kapittel 2, før jeg går gjennom relevant teori i kapittel 3. Der går jeg også igjennom min erfaring med UiPath som verktøy og viser et eksempel på hvordan programmeringen av en bot kan se ut. I kapittel 4 er det samtalene jeg har hatt med de forskjellige informantene i de tre organisasjonene som står i fokus. Kapittel 5 dreier seg om funn og analyse av disse før jeg avslutter i kapittel 6 med noen oppsummerende og avsluttende refleksjoner.
2 Metode
Jeg har jobbet med en eksplorerende tilnærming hvor problemstillingen har blitt til underveis for å prøve å forstå hvordan RPA brukes, organiseres og oppfattes i de tre virksomhetene Statnett, Statkraft og Avinor. Jeg har jobbet etter kvalitative metoder med åpne intervjuer som hovedkilde hvor jeg har undersøkt tre ulike virksomheter som er alle over 1000 ansatte. De er alle statseid, men driver i liten eller ingen grad myndighetsutøvelse. Gjennom å kombinere intervjuene med andre kilder som forskjellige dokumenter og relevant litteratur prøver jeg å danne et bilde av hvordan de utvalgte virksomhetene bruker RPA.
10 (Schartum, Developing E-government Systems - Legal, Technological and Organizational Aspects 2010)
11 (Bygstad 2017)
7 Siden vi hadde hatt om roboter i UDI med Martin Koldaas i emnet FINF 4011 høsten 2019 var det naturlig å rette en forespørsel om samarbeid til dem. Denne planen var utgangspunkt for valg av problemstilling. UDI hadde dessverre ikke mulighet til å bistå meg i arbeidet med masteroppgave denne våren. Det startet arbeidet med å lete etter andre informanter som kunne belyse den samme problemstillingen.
Gjennom nettverk fikk jeg kontakt med informant 2 i Statnett. Hun tilbød seg å sette opp et møte med informant 1 som er ansvarlig for RPA i Statnett. I løpet av dette intervjuet foreslo informant 1 at jeg skulle kontakte informant 3 i Statkraft og en kontakt i Avinor. Jeg kontaktet informant 3 i Statkraft og fikk avtalt tid for intervju senere samme uke. I Avinor tok det litt lenger tid å få svar, men etter litt frem og tilbake fikk jeg avtalt tid for intervju med informant 4. I løpet av denne samtalen kom navnet til informant 5 opp som en det ville være naturlig å snakke med siden han hadde ledet pilotprosjektet med RPA i Avinor. Han hadde flere forslag til personer jeg kunne kontakte, men jeg valgte å sette strek her. Siden jeg har vært ute etter å undersøke hvordan RPA brukes i forvaltningen har det vært nødvendig å snakke med personer som kjenner til temaet. Dette har gjort at utvalgskriteriene mine er en blanding av det Jacobsen betegner som snøball12 og informasjon.13 Jeg hadde også en samtale med informant 2. Denne handlet om hvordan Statnett jobber og bruker ulike styringsverktøy i driften.
Tabell 2-1 Oversikt over informantene
Tematisk analyse.
Jeg har vært ute etter å få historien om RPA i organisasjonen. Gjennom åpne intervjuer som grenser til observasjon hadde jeg samtaler på opptil en time med de ulike informantene. Intervjuene har foregått som videosamtale over nett med Microsoft Teams. På grunn av Covid-19 pandemien var det ikke realistisk å gjennomføre intervjuer ansikt til ansikt. Under pandemien har dert blitt vanligere å bruke videomøter. Dette har som Jacobsen på peker redusert skillet mellom intervjuer ansikt til
12 (Jacobsen 2018) s. 182
13 (Jacobsen 2018) s. 181
Informant 1 RPA ansvarlig i Statnett
Informant 2 Spesialrådgiver for risiko- og virksomhetsstyring
i Statnett
Informant 3 Head of automation i Statkraft
Informant 4 Ansatt i IT avdelingen i Avinor
Informant 5 Økonomisjef forretningsstøtte Avinor
8 ansikt og over nettet.14 Det at intervjuene har foregått over nett har også gjort det lettere å få avtalt tid for intervju. Kostnadene med intervjuene har vært lave både når det gjelder utgifter og tidsbruk på planlegging. Dette er en av fordelene med video intervju.15 Siden jeg ikke satt i samme rom som de jeg snakket med har jeg hatt mindre kontroll over intervjusituasjonen.16 Alle informantene mine har erfaring med å ha videomøter og var komfortable med å gjennomføre intervjuene både med lyd og bilde. I tillegg valgte jeg å ikke gjøre opptak av samtalene. Dette er faktorer jeg mener har bidratt til å få informantene til å snakke fritt om temaet. Siden jeg er ute etter å få et helhetlig bilde av RPA både med positive og negative sider har det vært viktig å ha en samtale der informantene har følt seg komfortable. Alle informantene bortsett fra informant 2 jobber i en eller annen form med RPA. Det betyr at jeg har stort sett snakket med personer som kjenner tematikken godt. Dette har gjort at jeg har kunnet ha en lav struktureringsgrad i intervjuene. Det jeg har spurt om og brukt som
intervjuguide er som følger:
• Hvordan jobber Statnett/Statkraft/Avinor med digitalisering og hvordan brukes RPA i dette arbeidet?
• Hvordan arbeidet med RPA organiseres?
• Hvilke vurderinger som blir gjort i utviklingsprosessen (dette inkluderer vurderinger knyttet til organisering, regelverk og tekniske vurderinger)
• Hvordan brukes Robotic Process Autoation i forvaltningen?
• Hvilke typer oppgaver? (Fordele meldinger, ulike HR oppgaver, fakturering,)
• Hvilke vurderinger gjørers for å velge ut prosesser?
Jeg har også lært meg å bruke programeditoren til UiPath for å lage noen ulike boter. Dette har jeg gjort for å bedre forstå hvordan RPA teknologien fungerer. Gjennom å lage forskjellige boter har jeg fått førstehåndserfaring med hvordan noen typer utfordringer kan løses som for eksempel input bokser som flytter seg. Denne er faringen har vært nyttig i intervjuene siden vi ikke har behøvd å bruke tid på grunnleggende ting som hvordan de programmeres. Det har også satt meg i stand til å bedre forstå utfordringene som for eksempel varierende omgivelser representerer.
14 (Jacobsen 2018) s. 149
15 (Jacobsen 2018) s. 148
16 (Jacobsen 2018) s. 148
9
3 Teori
3.1 Det forvaltningsinformatiske hjulet
I forvaltningsinformatikk er det flerfaglige perspektivet sentralt. Dette kommer frem i figuren under som Schartum har utviklet.17
Denne figuren illustrerer hvordan endringer hos et av de tre ulike domenene IKT-utvikling,
regelverksutvikling og organisasjonsutvikling påvirker de to andre. Pilene går begge veier for å vise at påvirkningen mellom de tre er gjensidig.18 Regelverksutvikling kan legge føringer for hvilke
teknologiske virkemidler som kan brukes av en virksomhet eller hvordan disse kan brukes. Dette kan være spesifikke regler som i forskrift om IT standarder19 eller mer generelle regler som i
personvernsforordningen.20 Samtidig vil den teknologiske utviklingen utfordre og bidra til utvikling i regelverk. Et dagsaktuelt område hvor vi ser dette skje er innenfor kunstig intelligens, hvor EU jobber med å få på plass en regulering.21 Gjennom 2020 og 2021 var det på grunn av pandemien mange som ble pålagt å ha hjemmekontor. Dette var et pålegg fra myndighetene, altså en regelverksendring som har ført til endringer i både organisering og i bruken av IKT. Det å sende alle på hjemmekontor har
17 (Schartum, Developing E-government Systems - Legal, Technological and Organizational Aspects 2010)
18 (Schartum, Jansen og Tranvik, Digital forvaltning - en innføring 2017) s. 16
19 (Forskrift om IT-standarder i offentlig forvaltning 2013) se for eksempel §9
20 (Pvf 2016)
21 (Stortingsbiblioteket 2021)
Digital
forvaltning
Organisatorisk endring
Teknologisk endring
Rettslig endring
Figur 3-1 Sammenhenger mellom endringsprosesser i digitalforvaltning. Oversettelse fra (Schartum, Jansen og Tranvik, Digital forvaltning - en innføring 2017) s. 15
10 utløst et behov for å bruke teknologi for å for eksempel holde møter. Samtidig har utviklingen av teknologiske løsninger som for eksempel sky-tjenester gjort det mulig å gjennomføre denne omorganiseringen så raskt. I tillegg har den økte bruken av hjemmekontor ført til diskusjoner rundt bruken av hjemmekontor og regelverket rundt dette.22
3.2 Hva er Robot Process Automation?
Robot process automation er en type teknologi som benytter programvare til å emulere handlingene til en menneskelig bruker i et system. Dette blir gjort gjennom å programmere boten til å gjøre de samme handlingene som en menneskelig bruker gjør. Det kan gjøres på forskjellige måter, for eksempel ved hjelp av koordinatene på skjermen eller gjennom ymse tagger det grafiske
brukergrensesnittet bruker. En bot vil kunne kjøre på en virtuell maskin som en egen bruker hvor den kan åpne og lukke de ulike programmene den trenger for å utføre en oppgave. For at boten skal kunne implementeres må det være klare fastsatte regler for hva boten skal gjøre. Det at boten etterligner faste handlingsmønstre gjør den egnet til å løse rutinepregede oppgaver som følger fastsatte regler. Det kan være å hente opplysninger fra faste steder, for så å putte dem inn i en annen applikasjon. Avhengig av oppgaven boten utfører vil den kunne jobbe med eller uten veiledning av et menneske.
Bruksområdet til RPA er å automatisere arbeidsoppgaver som er enkle og repetitive. Dette kan for eksempel være å kopiere informasjon fra en applikasjon inn i en annen, eller å lese av et skjema og skrive informasjonen inn i en database. RPA utnytter sterkt funksjonaliteten i andre programmer, og kan ofte lages av folk uten it-faglig bakgrunn. I boken “The Robotic Process Automation Handbook” av Tom Taulli deles de ulike variantene av RPA inn i tre hovedkategorier:
Ledsaget RPA, hvor programvaren jobber sammen med et menneske, Selvstendig RPA, hvor programmet jobber alene etter klare faste regler og
«intelligent» RPA, som bruker kunstig intelligens/maskinlæring for å gjøre oppgaver23 I ledsaget PRA, hvor en bot jobber under veiledning av et menneske, er det ikke nødvendigvis slik at mennesket overvåker boten. Det vil i større grad være at mennesket og boten jobber sammen, for eksempel ved at boten søker opp og sammenstiller informasjon om en kunde for kundebehandleren.
Et eksempel på en Ledsaget RPA er caset til Agurre og Rodriguez,24 hvor kundebehandleren tar imot henvendelsen fra kunden, mens en RPA-bot tar seg av utsending og arkivering av bekreftelse til
22 (Arbeids- og sosialdepardementet 2021)
23 (Taulli 2020) s. 6
24 (Aguirre og Rodriguez 2017) s. 68-69
11 kunden. Et annet eksempel er en bot som henter informasjon fra forskjellige strukturerte datakilder og sammenstiller informasjonen, slik at saksbehandler får et godt vurderingsgrunnlag for avgjørelsen vedkommende skal ta. Da inngår boten i et beslutningsstøttesystem. Ledsaget RPA kan også være en bot som gjør en oppgave eller anbefaler en beslutning et menneske godkjenner før den blir endelig gjennomført. En annen oversettelse av Ledsaget RPA er Overvåket RPA. Ledsaget RPA ble først tatt i bruk på begynnelsen av 2000 tallet, og er den tidligste typen RPA.25
Selvstendig RPA brukes til å løse klart definerte oppgaver. Hendelser trigger et klart definert
aksjonsmønster fra boten sin side. Bergen kommune løste eksempelvis oppgaven med å sortere mail til ulike tjenester med den selvstendige RPAen Digifrid som ble tatt i bruk i 2017. 26 IKT Helse mottok i 2017 daglig ca. 350 Pleie- og omsorgsmeldinger i døgnet. Dette utgjorde 13500 meldinger i
måneden.27 Med 30 sekunder per melding for å rute den til riktig mottaker utgjorde det 112,5 timer i måneden, eller rundt regnet 28 timer i uken. To ansatte delte denne oppgaven. Digifrid fikk klart definerte regler for hvordan en melding skulle sorteres. Hendelsen at en ny mail kom inn trigget at hun beregnet hvem som skulle motta mailen, og videresendte den til riktig adresse. Dette har frigjort mye arbeidstid til andre oppgaver. Siden 2017 har tjenesten blitt utvidet til å sortere flere typer meldinger, og sorterer nå ca. 1000 meldinger i døgnet. Hvis tidsbruken for disse meldingene tilsvarer de opprinnelige, tilsvarer det en besparelse på omtrent 80 arbeidstimer i uken.
Intelligent RPA kjennetegnes av at den utnytter kunstig intelligens, maskinlæring og/eller ulike former for statistikk for å løse oppgavene, og er en relativt ny form for RPA. Intelligent RPA kan kreve ekstra kompetanse hos den som lager boten. Det er imidlertid en fremvekst av brukervennlige AI- komponenter som kan inkluderes som en del av RPAer, for eksempel hjelpemidler til å trene boter med naturlig språk. I caset hvor kundebehandleren svarer kunden og boten tar seg av arkivering og bekreftelse som Aguirre og Rodriguez28 omtaler, kunne prosessen i teorien helautomatiseres ved at kundebehandleren erstattes med en intelligent RPA som er trent på naturlig språk. Et annet
eksempel på en bot hvor maskinlæring ble brukt er Roy autopilot som sorterer meldinge Avinor får inn via nettsidene sine.29
Kunstig intelligens (KI) og maskinlæring kan også brukes til å lage boter som er mer tilpasningsdyktige til endringer i systemene den interagerer med. For eksempel at den fortsatt finner en knapp som flyttes eller redesignes. Selv om KI baserte boter kan tåle variasjon på spesifikke deler av prosessen
25 (Taulli 2020) s.
26 Stat og styring 1-2018 s.7
27 (Bergen kommune 2017)
28 (Aguirre og Rodriguez 2017) s. 68-69
29 (Sopra Steria 2021)
12 eller omgivelsene opererer de også etter klare prosedyrer og regelverk. Kunstig intelligens,
maskinlæring og statistikk er være kraftige verktøy som kan gi mange muligheter for å endre hvordan vi jobber.
3.3 Lettvekts IT
Et konsept som kan gjøre det lettere å forstå noen av sidene med RPA er konseptet om lettvekts IT.
Bygstad skiller mellom kunnskapsregimene lettvekts IT og tungvekts IT og trekker frem ulike gode praksiser for de ulike kategoriene. 30 Bygstad definerer lettvekts IT som «a socio-technical knowledge regime, driven by competent users’ need for solutions, enabled by the consumerisation of digital technology, and realized through innovation processes.»31 Det kan oversettes til at lettvekts IT er et sosioteknologisk kunnskapsregime, som er drevet av kompetente brukeres løsningsbehov, muliggjort av utvikling av digital teknologi utenfor IT-sektoren, og utført gjennom innovasjonsprosesser. Det vil si at lettvekts IT er et kunnskapsregime hvor brukerne og innovasjon er i fokus. RPA går inn under lettvekts IT fordi det er rettet mot og kan utvikles av brukere uten IT faglig bakgrunn, i tillegg til at det er en naturlig del av innovasjonsprosesser. Derfor vil jeg gå litt nøyere inn på lettvekts IT under.
Lettvekts IT er avhengig av en tyngre infrastruktur som deles av mange aktører, og kan betegnes som et eget teknologilag som ligger oppå infrastrukturlaget. Et eksempel Bygstad bruker på denne
interaksjonen er hvordan apper utnytter annen teknologi som en plattform. 32 Ulike apper kan utnytte den samme teknologien, for eksempel et operativsystem, en nettleser eller et annet program, istedenfor å implementere funksjonalitet selv. Plattformen fungerer i sin tur som et bindeledd til tyngre infrastruktur som for eksempel servere eller stormaskiner. Appene kan da være lettvektsløsninger som man kan lage relativt enkelt, og som alle kan bruke. I dette eksempelet kan
30 (Bygstad 2017) s. 181
31 (Bygstad 2017) s. 181
32 (Bygstad 2017) s. 183
13 man se på appene, plattformen og den tyngre infrastrukturen som ulike teknologilag hvor hvert lag kun kommuniserer med laget over og under.
I følge Lacity og Willcocks kan datateknologi deles inn i lag som illustrert i Figur 3-2. Det øverste laget er fremstillingslaget. Det representerer det en sluttbruker ser og interagerer med på skjermen. Det er hovedsakelig dette laget RPA benytter seg av. Lagene for forretningslogikk og dataaksess inkluderer programvaren og maskinvaren til brukerne, og kan kjøres enten lokalt eller på servere. Databaselaget er typisk på servere lokalt eller i skyen, og ikke på maskinen til hver enkelt bruker. Tradisjonell IT utvikling, som Bygstad kaller tungvekts IT, foregår i alle de fire lagene i figuren over. RPA benytter seg gjerne av tungvekts IT, og foregår vansligvis i de øverste lagene på figuren.
Tungvekts IT er drevet av personer med IT faglig bakgrunn som jobber med teknologier og systematiske rammeverk som i hovedsak er godt utprøvde, mens lettvekts IT drives av
eksperimentering fra sluttbrukere. 33 Det er styrker og svakheter med begge regimene. Ifølge Bygstad er vilkårene for innovasjon best mulige når regimene holdes noenlunde adskilt. Dette uttrykker han som tre designprinsipper; løs teknisk kobling, løs organisatorisk kobling og løs kobling mellom standarder.34 Han mener løs kobling mellom regimene fører til at man både kan dra nyttene av
33 (Bygstad 2017) s. 181
34 (Bygstad 2017) s. 190
Figur 3-2 Illustrerer Lacity og Willcocks lagdelte systemstruktur (Lacity & Willcocks, 2016) s. 24
14 muligheter som springer ut av samspill mellom de to regimene, og regimenes ulike generative
egenskaper. Løs teknisk kobling betyr at systemene ikke bør integreres fullstendig, men for eksempel bruke APIer til å kommunisere. Det fører til at de som jobber med systemene ikke behøver å ha satt seg inn i både systemene som er del av regimene lettvekts IT og tungvekts IT, og at utvikling kan foregå i parallell. Løs organisatorisk kobling betyr også at det blir et mindre behov for koordinering, og støtter lokal adopsjon. For å unngå at de to tankesettene bak de to regimene kolliderer er det viktig med løs organisatorisk kobling. 35 Det kan være en utfordrende oppgave å lage standarder som både favner lettvekts IT og tungvekts IT. En løs kobling mellom standarder øker muligheten for innovasjon, da det vil redusere tiden fagfeltene må vente på at standarder blir utviklet.36
3.4 Bruksområder for RPA
RPA blir gjerne solgt inn som enkelt å sette opp, konfigurere og ta i bruk. Blant annet fordi det ligger oppå systemene virksomheten allerede har. Figur 3-3 illustrerer at det kreves lite programmerings- teknisk kunnskap for å lage og ta i bruk RPA-boter.
Figur 3-3 Skjermbilde fra program for å endre rente fra flytende til fast (Stople, et al. 2017) s. 3.
35 (Bygstad 2017) s. 190
36 (Bygstad 2017) s. 190
15 Skjermbildet i Figur 3-3 illustrerer hvordan banken i artikkelen til Stolpe med flere implementerte en RPA-bot som endret en lånerente fra flytende til fast. Hver av de hvite boksene med bølgete
underside utgjør en delprosess, for eksempel boksene merket «Startup checks», «1. (AFS) Åpne sak i AFS», og «2. (AFS) Kontroller AFS skjema og hent ut endringsdetaljer». Hver av delprosessene har en egen fane øverst hvor den er nøyere spesifisert, i tillegg til å være plassert i flytdiagrammet på forsiden. Flytdiagrammet på forsiden beskriver prosessen som en helhet, ikke ulikt
arkitekturdiagrammer som vanlige i tungvekts IT. I dette programmet er ikke flytdiagrammet bare en plan for hvordan det skal implementeres, men selve implementeringen av RPA-roboten. Siden man setter sammen enkle komponenter for å bygge den prosessen man ønsker, sammenligner forfatterne å programmere en RPA-robot med å bygge Lego.37 Figur 3-4 illustrerer Lego sitt visuelle
programmeringsspråk. Det er laget etter samme prinsipp som de fysiske plastblokkene. Det består også av enkle komponenter man knyter sammen ved å klikke og dra, og har mange likhetstrekk med RPA-programmering.
Figur 3-4 Eksempel på programmering av en robot i Lego Mindstorm. (Oscar-Andersen 2020) s. 4
3.5 Kjennetegn for prosesser hvor automatisering gir gevinst
Robot Process Automation brukes til å automatisere hele eller deler av en prosess for å oppnå ulike gevinster. En nærliggende gevinst er tidsbesparelser. RPA sparer tid dersom tiden det tar å planlegge, utvikle, bestyre og vedlikeholde RPA boten er lavere enn den tiden det ville tatt å utføre prosessen manuelt. En prosess består av en rekke transaksjoner. Hvor mye tid som spares avhenger av hvor ofte prosessen utføres, hvor mange transaksjoner den består av, og hvor tidkrevende transaksjonene er. Hvilken verdi den sparte tiden har for virksomheten er en vurderingssak. Det er også en
vurderingssak om tiden spart er mer eller mindre verdt for virksomheten enn tiden som må brukes.
Det kan for eksempel være ulike ressurser eller ulik kompetanse som utvikles. Hvis folk som ringer inn for å kjøpe forsikring får en raskere kundebehandling kan det for eksempel føre til flere kjøp. Eller de med kompetanse på RPA kan være opptatt med forretningskritiske oppgaver.
37 (Stople, et al. 2017) s. 3
16 Siden en manuell og en automatisert prosess ikke er identiske kan det både være gevinster ved å automatisere en prosess eller holde den manuell. For eksempel kan det føles trygt for blant annet eldre å bestille legetime via telefon gjennom å snakke med et menneske, mens en sms eller en automatisk telefonmeny gjør at pasienter slipper å vente i kø. For at bruken av RPA skal bli vellykket bør virksomheten ha en plan for hva de skal bruke det til før de setter i gang. Fung identifiserte i 2014 ni kjennetegn for prosesser hvor RPA har potensiale til å være nyttig. 38 Disse kjennetegnene er at den manuelle prosessen
1. har svært mange transaksjoner 2. er særdeles viktig eller verdifull 3. krever hyppig bruk av flere systemer 4. foregår i stabile omgivelser
5. krever lite menneskelig inngripen 6. har få unntak
7. er lett å gjøre feil manuelt
8. er enkel å bryte ned til delprosesser som ikke krever skjønn 9. har en kostnad som er godt forstått. 39
For å finne ut om en prosess bør automatiseres kan man bruke kjennetegnene som kriterier å vurdere den etter. Da er det større sjanse for at det gir gevinst å automatisere prosessen hvis den oppfyller flere av kriteriene. Kriteriene er kun nummerert i denne teksten for at det skal være lettere å henvise til dem. Delkapitlene under utdyper hvert av kriteriene. Fung fokuserer på oppgaver knyttet til drift og vedlikehold av rene IT-systemer. Siden kriteriene er generelle og ikke teknologiavhengige mener jeg at de kan overføres til andre områder. Under utdyper jeg med eksempler for hvordan prinsippene kan brukes.
En prosess behøver ikke å oppfylle alle kriteriene for at det lønner seg å automatisere den. For eksempel må Lånekassen forholde seg til flere unntak (kriterie 6) for hvem som kan få fullt studielån, men innvilgelse av lån for den gjennomsnittlige studenten kan gå automatisk. I dette eksempelet lønner det seg med automatisering blant annet fordi prosessen oppfyller kriterie 1, 4, og 8. Det vil si at det er svært mange standardlån som skal innvilges (kriterie 1). I tillegg er Lånekassens
organisering, regelverket de forholder seg til, og IT-systemene de bruker relativt stabile, og forandrer seg mye mindre hyppig enn tempoet lånesøknader kommer inn (kriterie 4). Prosessen kan deles inn i
38 (Fung 2014) s.2
39 (Fung 2014) s.2-3
17 delprosesser som ikke krever skjønn (kriterie 8); en delprosess hvor det sorteres ut lån som ikke krever skjønnsmessig vurdering, og en delprosess hvor lånet innvilges og utbetales.
3.5.1 Svært mange transaksjoner
I en prosess med svært mange transaksjoner (kriterie 1) vil vanligvis en del av transaksjonene ligne på hverandre, og derfor være repetitive eller rutinepregede. Det vil ofte være lønnsomt å automatisere disse prosessene fordi RPA egner seg til å løse repetitive og rutinepregede oppgaver.40 I tillegg kan en liten besparelse per transaksjon bli stor når det er et stort volum av transaksjoner. Volumet av transaksjoner kan være stort fordi prosessen har mange transaksjoner, eller fordi prosessen blir utført svært ofte. Det er imidlertid nødvendig å vurdere om automatiseringen bør komme i form av RPA, eller i form av tungvekts IT ved for eksempel integrerte endringer av de eksisterende
systemene.
3.5.2 Særdeles viktige eller verdifulle transaksjoner
En prosess må ikke nødvendigvis bli utført mange ganger for at det skal bli lønnsomt å automatisere den hvis den er spesielt viktig (kriterie 2). Det kan være avtalt et høyt straffegebyr for feilbehandling eller redusert respons- eller oppetid som gjør potensiell menneskelig svikt ved manuell behandling dyrt. Automatisering kan være billigere enn å ha ansatte på jobb i helgene for å sørge for den påkrevde oppetiden.41 Et eksempel er en bank som må være tilgjengelig hele døgnet.
3.5.3 Hyppig bruk av flere systemer
En prosess som benytter flere systemer (kriterie 3) kan det lønne seg å automatisere fordi den kan ha stort potensiale for menneskelige feil, og ta unødvendig mye tid å gjøre manuelt. Når en manuell prosess tar i bruk flere systemer øker sjansen for menneskelige feil. For eksempel hvis informasjon for samme ansattnummer i ulike systemer skal hentes ut og sammenstilles, kan brukeren med et uhell hente ut opplysninger fra feil person i et av systemene. I tillegg kan RPA spare tid for brukeren i en prosess hvor flere systemer brukes fordi det å logge inn på flere systemer ofte tar tid.
3.5.4 Stabile omgivelser
Siden RPA boter baserer seg på klare regler og prosedyrer må prosessen foregå i omgivelser som er tilstrekkelig stabile (kriterie 4) for at det skal være lønnsomt å automatisere den. Når omgivelsene er mer stabile, krever boten mindre vedlikehold. RPA boter kan lages slik at de tar høyde for spesifikk variasjon. Det finnes for eksempel boter som kan lete flere steder på en nettside etter riktig knapp å trykke på, eller boter som kan lese håndskrift. Om miljøet boten opererer i endres mer enn det
40 (Fung 2014) s.2
41 (Fung 2014) s.2
18 implementeringen av boten har tatt høyde for må boten endres. Hvis en bot må endres hyppig risikerer man at det tar mer tid å holde boten oppdatert enn å gjøre prosessen manuelt. Hvis boten må endres sjelden kan det veie opp for at transaksjonene også er sjeldne. Det viktige er at
transaksjonene skjer tilstrekkelig oftere enn endringene i omgivelsene.
Kravet til tilstrekkelig stabilitet gjelder hele miljøet RPA-boten opererer i. Det inkluder
organisasjonen, regelverket og IT miljøene den samhandler med. Hvis en RPA-bot sender en alarm når infrarøde kamera måler om det er for mange inne på et utested etter smittevernreglene, må boten oppdateres hver gang smittevernreglene oppdateres, selv hvis det er hver eneste dag. Hvis det stadig varierer hvem som har ansvar for hvert fagområde må en bot som sorterer mail til den som er ansvarlig oppdateres ofte. Hvis nettsiden en bot navigerer endrer seg ofte må boten endres slik at den fortsatt klarer å navigere på nettsiden.
3.5.5 Lite menneskelig inngripen
Prosesser har potensiale for å egne seg for RPA hvis de krever lite skjønnsmessig vurdering eller annen inngripen fra mennesker (kriterie 5). Det er fordi kun de delene av en prosess som kan utføres uten mennesker kan automatiseres. Hvis en oppgave krever subjektiv vurdering eller analyse er den vanligvis ikke egnet, mens oppgaver som er basert på matematikk og logikk ofte er egnet. Det er ikke alltid innlysende hvilke manuelle vurderinger som baserer seg på skjønn, og hvilke som baserer seg på logikk. For eksempel kan en bot avgjøre hvilke flyktninger som får oppholdstillatelse i noen tilfeller. Hvis det for eksempel er en krise i et land som gjør at mindreårige fra det landet har krav på oppholdstillatelse i Norge, kan ulike offentlige etater verifisere opplysningene, og en bot automatisk avgjøre og innvilge oppholdstillatelse.
3.5.6 Få unntak
Når en prosess vanligvis utføres på samme måte med få unntak (kriterie 6) er det lettere å automatisere den. Det er fordi den resulterende boten blir mindre komplisert enn om man må implementere behandling av mange unntak. At boten er mindre komplisert betyr at den har mindre sjanse for å inneholde feil, og at det er lettere og billigere å endre den dersom omgivelsene blir forandret. En strategi for å automatisere en prosess med mange unntak er å endre reglene eller prosessen slik at det er færre unntak.
Det er ikke et absolutt krav at det må være få unntak i en prosess for at den skal kunne
implementeres. Man kan blant annet skille ut unntakene og behandle dem manuelt. Dette avhenger av at det er mulig å bryte prosessen ned til delprosesser som ikke krever skjønn (kriterie 8). Hvis man sorterer ut unntak som skal behandles manuelt risikerer man imidlertid at gevinsten av
automatiseringen ikke er så høy. Det er ikke det totale volumet av transaksjoner som avgjør hvor
19 mye tid som blir spart, men volumet av transaksjoner som ikke må til manuell behandling. For å finne ut om prosessen egner seg for automatisering må man derfor vurdere delene av prosessen som kan automatiseres opp mot Fungs kriterier.
3.5.7 Lett å gjøre feil manuelt
Hvis det er lett å gjøre en prosess feil manuelt (kriterie 7) kan det gi stor verdi at den blir gjort korrekt av en bot. Hver feil kan i seg selv utgjøre en kostnad for virksomheten eller omgivelsene. En stiftelse kan for eksempel gå glipp av donasjoner hvis den ikke skriver riktig navn og adresse på alle brevene den sender ut for å be om penger.
Manuelle feil kan også føre til at hver utførelse av prosessen reelt sett tar mer tid, for eksempel hvis transaksjonen må gjøres igjen til prosessen er utført riktig. I noen systemer kan det ta mye tid å rette opp en feil, blant annet hvis det krever mer kunnskap å rette feil enn å følge den riktige prosessen.
3.5.8 Enkel å bryte ned til delprosesser
Hvis en prosess er enkel å bryte ned til delprosesser som ikke krever skjønn (kriterie 8) kan det bety at kostnaden ved å automatisere prosessen er relativt lav. En enkel prosess er lettere å
implementere og vedlikeholde, så hvis prosessen kan brytes ned til enkle delprosesser er det et tegn på at kostnaden med å automatisere kan være lav. Om kostnaden er lav kreves det ikke nødvendigvis store besparelser før automatisering er lønnsomt. En prosess som oppfyller kriterie 1 har også potensiale til å oppfylle kriterie 5; hvis en samling delprosesser som ikke krever skjønn utgjør en prosess krever prosessen lite menneskelig inngripen.
3.5.9 Godt forstått manuell kostnad
Der kostnaden av å utføre prosessen manuelt er godt kjent (kriterie 9), må man bare finne ut hvor mye det koster å automatisere den for å vite om det lønner seg. Arbeidet med å finne ut om en prosess bør automatiseres kan sees som en kostnad ved å automatisere prosessen. Da blir kostnaden lavere når mulighetsstudien koster mindre. Når den manuelle kostnaden er godt forstått kan det også bety at prosessen i seg selv er godt forstått. Det reduserer kostnaden ved å automatisere. Dette betyr at prosesser som oppfyller kriterie 9 har potensiale for å være lavthengende frukter som kan skape ekstra verdi ved at virksomheten får testet ut automatisering og bygd kompetanse.
3.6 RPA eller andre former for automatisering
Selv om det lønner seg å automatisere en prosess betyr ikke det at den bør automatiseres med RPA.
Det kan være at det er mer hensiktsmessig å bruke tradisjonelle automatiseringsmetoder, for eksempel å kjøpe inn et system som gjør oppgaven, eller å utvide et eksisterende system. Figur 3-5 illustrerer hvilke prosesser og oppgaver hvor RPA er egnet som automatiseringsverktøy ifølge van der
20 Aalst sin artikkel.42 I figuren er prosessene sortert på to akser; hvor ulik hver gjennomføring av prosessen er, og hvor ofte prosessen gjennomføres. Figuren illustrerer at det er negativ korrelasjon mellom hvor ofte en prosess utføres og hvor forskjellig hver utførelse er. Det vil si at hvis en prosess utføres mange ganger er det sannsynlig at den utføres likt hver gang, og hvis den gjennomføres sjelden er det sannsynlig at hver gjennomføring av prosessen varierer mer.
Figur 3-5 Posisjonering av RPA (van der Aalst, Bichler og Heinzl 2018) s. 270
Tradisjonelle metoder for automatisering er ofte dyrere å implementere og mer stabile enn automatisering med RPA. Derfor vil det ofte lønne seg å bruke tradisjonelle metoder for å
automatisere prosesser som gjennomføres svært ofte og svært likt.43 En prosess som oppfyller Fungs kriterier til en stor grad vil det også være sannsynlig at havner i denne kategorien. Lånekassen innvilger for eksempel svært mange lån maskinelt, og det er naturlig at de bruker tradisjonelle automatiseringsmetoder for dette. På den annen side kan en prosess kun gjøres av mennesker hvis hver gjennomføring er svært forskjellig, slik Fungs kriterier 4, 5, 6 og 8 også antyder. Selv om den kan automatiseres kan det også være at det ikke er lønnsomt. Når en prosess er strømlinjeformet nok til å dra nytte av å utføres automatisk, men det ikke lønner seg å bruke tradisjonelle metoder for automatisering, er RPA et gunstig valg. Typiske oppgaver som bør automatiseres med RPA er rutinepregede. For eksempel reiseregninger, lønnskjøring eller andre administrative oppgaver.
42 (van der Aalst, Bichler og Heinzl 2018) s. 270
43 (van der Aalst, Bichler og Heinzl 2018) s.270
21 Aguirre og Rodriguez sin artikkel sammenligner en prosess hvor det blir sendt ut en kvittering til en kunde etter at den har snakket med en kundebehandler.44 I den ene gruppen fikk kundebehandleren støtte fra en RPA-bot, mens den andre gjorde oppgavene manuelt. Noen av kundebehandlerne var erfarne og hadde rutiner som gjorde at de behandlet sakene veldig raskt. I snitt brukte gruppen med RPA bare 9 sekunder mindre per kundebehandling enn gruppen uten. Allikevel håndterte gruppen med RPA 20% flere saker per uke enn den andre gruppen. Mesteparten av den økte produktiviteten kunne forklares med at RPA-botene håndtere flere saker på en gang, til motsetning fra de
menneskelige arbeiderne.45 Dette bruksområdet oppfyller flere av kriteriene til Fung siden det var et høyt volum av transaksjoner (kriterie 1), prosessen krevde at flere systemer ble tatt i bruk (kriterie 3), de kunne skille ut en delprosess som ikke krevde skjønn (kriterie 8), slik at den delen av prosessen de automatiserte hadde lite behov for menneskelig inngripen (kriterie 5).
3.7 Min erfaring med UiPath
For å betre forstå hvordan botene fungerer har jeg satt meg inn i RPA pakken til UiPath. Siden jeg hadde gjort dette før intervjuene startet kunne jeg bruke kunnskapene fra dette for å bedre forstå de tekniske sidene ved å lage boter.
UiPath har tre varianter av editoren sin: StudioX, Studio og Studio pro. I StudioX brukes det ferdige moduler og ikke programmeringsspråk. Disse er knyttet til typiske kontor apper som Word, Excel og Power Point.
44 (Aguirre og Rodriguez 2017)
45 (Aguirre og Rodriguez 2017) s.69
22
Figur 3-6 Ulike aktiviteter som kan brukes i StudioX
Som vi kan se av figuren over, vil de ulike modulene gjøre forhåndsbestemte oppgaver som å legge inn et bilde i et Word-dokument. Dette er ment som et verktøy der det er mulig å automatisere enkle oppgaver uten å måtte ha noe kunnskap om programmering. En av de største forskjellene mellom StudioX og Studio og Studio Pro er at i de to siste bruker du programmeringsspråkene VB.net eller C#.
Dette gjør det mulig å bruke mer tradisjonelle programmerings teknikker som egendefinerte variabler, argumenter og lignende. Det brukes fortsatt ferdige moduler så istedenfor å skrive if bruker du if modulen som har egne bokser for de ulike utfallene. I Studio og Studio Pro har du tilgang på mer avanserte metoder for å få boten til å gjøre mer komplekse oppgaver.
23
3.8 Et eksempel på programringen av en bot
Som et eksempel på hva RPA kan gjøre kan vi se for oss en månedlig salgsrapport hvor inntekten fra salg i ulike land skal samles og konverteres til en bestemt valuta. Denne prototypen har jeg laget med programvaren UiPath Studio. Denne var en del av et nettbasert innføringskurs UiPath tilbyr gratis og hele kurset tok rundt fire timer å gjennomføre. I dette prosjektet bruker jeg VB.net som
programmeringsspråk.
Først åpnes Excel-malen som rapporten bruker. Etter dette åpnes og leses dataene fra en CSV-fil i boksen Read CVS. Disse dataene blir lagt inn i Excel som en data tabell og teksten «Total sales USD»
skrives inn i celle F1. Se Figur 3-7.
Figur 3-7: Åpne Excel malen, hent data fra CVS fil og skriv inn i F1 "Total Sales USD"
24 Deretter åpnes en nettleser for å google valutakursene som skal konverteres. Som Figur 3-8 viser går boten direkte til en forhåndsbestemt nettside.
Figur 3-8 Boten åpner en nettleser og går til en bestemt adresse
Som Figur 3-9 viser brukes en For løkke for hver valuta i Excel-arket «Converter». Her skal boten søke opp valutaen i USD og lese av resultatene fra Google. Når boten søker fyller den inn tekst i søkefeltet og sender signal om at Enter er trykket på for å starte søket. Når den skal lese av resultatene er det viktig å sikre at den leser av riktig sted. Avlesningsmålet som er markert i grønt er koblet til et anker markert i blått. Ved å koble det sammen på denne måten blander ikke boten felter som ligner på hverandre, som i feltet rett over med verdien 1 for valutaen som skal konverteres. Kursen legges så inn i Excel
25
Figur 3-9 Boten googler valutakurser
Etter å ha funnet de nødvendige kursene regnes totalsummen for hver vare ut i dollar og skrives inn i Excel filen. Dette vises i Figur 3-10. Igjen brukes en For each løkke som går igjennom alle varene, slår opp hvilken valuta de er registrert i, henter konverteringsraten og skriver inn en formel som ganger
26 sammen antallet varer, prisen per vare i den lokale valutaen og konverteringsraten til amerikanske dollar.
Figur 3-10 Boten bruker Excel for å gjøre utregninger
27 Så lager boten en Pivot tabell med oversikt over hvor mye det er solgt for i USD i hvert land. Videre henter boten filinformasjon for å lage en kopi av den ferdig utfylte malen som lagres i en egen mappe. Dette vises i Figur 3-11
Figur 3-11 Boten lager en Pivot tabell og kopierer filen
Til slutt skal boten sende den ferdige rapporten på epost til de som skal ha den (Figur 3-12). Dette gjøres ved å åpne den aktuelle epostklienten, logge inn og bruke send epost funksjonen. Her er det
28 en fast rutine e-post som sendes, så mottaker, emne og meldingstekst er fast. Til slutt legges filen ved som et vedlegg og eposten sendes til den adressen som er lagt inn. Mottaker adressen kan være en variabel slik at mottaker kan endres ved behov.
Figur 3-12 Boten setter sammen en epost og sender den
Mottaker får en epost som i Figur 3-13 under. Som det fremgår av filnavnet på raporten er det noen endringer som må til. Her skulle det egentlig skrives inn datoen den ble generert, men i stedet står dato formatet. Dette er et eksempel på typen finpuss som må gjøres for å få boten til å nå alle de forskjellige kravene. Den fungerer uten siden eposten blir sendt og innholdet er riktig, men riktig
29 filnavn er viktig av flere grunner. Hvis filnavnet er galt vil for eksempel en annen bot som skal bruke filen videre få problemer med å finne den.
Figur 3-13 Mottatt epost
I Figur 3-14 ser vi de ulike valutakursene boten har hentet inn. Figur 3-15 viser oversikten over produkt, pris, valuta, antall solgt, land og total salgssum i amerikanske dollar. Det siste bildet i Figur 3-16 viser den ferdige pivot tabellen.
Figur 3-14 Innhentede valutakurser
30
Figur 3-15 Salgsdata
Figur 3-16 Salg per land i USD
Dette vil være en typisk oppgave robot process automation passer godt til. Dette kommer av at den kan jobbe etter klare faste regler hvor de ulike parameterne er konstante. Boten vil også håndtere
31 variabler i form av valutakurser, men det er bestemt i dataene den leser fra hvilke valutaer det er snakk om.
Et annet eksempel på en prosess kan være å bestille blomster til ansatte i forbindelse med hendelser som nyansettelse, jubileer, den ansatte går av med pensjon, fødsler og lignende. En tekstlig
beskrivelse av en slik prosess kan se ut som følger:
Steg 1: Registrering av bestilling med nødvendig informasjon som
• navn,
• adresse,
• telefonnummer,
• type bukett (sorg eller glede) og
• eventuell tekst til kort tas imot på epost.
Steg 2. Gå til blomsterhandlerens nettbutikk.
Steg 3. Fyll inn påloggings informasjon og trykk på logg inn.
Steg 4. Søk opp typen bukett.
Steg 5. Velg bukett og størrelse. Trykk neste.
Steg 6. Fyll inn tekst til kort. Hvis korttekst er blank, hopp over og gå til neste.
Steg 7. Velg type leveringsadresse (privat, jobb, eller annet).
Steg 8. Fyll inn personalia for levering.
Steg 9. Velg leverings tidspunkt.
Steg 10. Lag sammendrag av bestillingen og varsle for å få godkjenning.
Steg 11. Hvis bestillingen blir godtatt, send bestilling med fakturabetaling.
Denne beskrivelsen er en grei start for å lage en bot, men den må være enda mer detaljert for å kunne brukes i praksis. Det må for eksempel legges til om det for å gå videre tykkes på enter eller om det er klikk med musa. Sånn som jeg har lagt opp til her ville en bot som gjorde denne prosessen være en ledsaget løsning siden den ber om godkjenning fra en bruker om valgene den har gjort er godkjente. Det vil også være mulig å lage denne som en selvstendig løsning.
32
4 Tre forvaltningsorganisasjoner
4.1 Statnett
Statnett er et statsforetak eid av Olje og energidepartementet46 med ansvar for kraftsystemet i Norge. De drifter 11000 km med kraftledninger og 150 transformatorstasjoner fordelt over hele landet. Med over 1400 ansatte jobber de hver eneste dag for å sikre at vi har strøm i stikkontakten.
Statnett er tildelt konsesjon som systemansvarlig for det norske strømnettet. Dette innebærer myndighet til å fatte vedtak ovenfor andre aktører i kraftbransjen. Det gjør de blant annet for å ivareta balansen mellom produksjon og forbruk i strømnettet.47 Dette er regulert gjennom forskrift om systemansvaret i kraftsystemet.48
For å møte behovene i fremtiden jobber de etter en strategi der smart, effektiv og sikker er nøkkelordene.49 Statnett ønsker med dette å velge smarte og effektive løsninger for fremtiden der sikkerheten blir ivaretatt. Gjennom å bruke ulike verktøy som for eksempel autonome droner, sensorer og maskinlæringsalgoritmer50 jobber Statnett med å overvåke og balansere strømnettet.
Dette arbeidet støtter de også gjennom ulike digitaliserings- og automatiseringstiltak. Det er i dette aspektet RPA kommer inn som et verktøy.
Når Statnett bruker RPA ønsker de å tenke bredt, det er ikke bare HR oppgaver de ser på. Blant annet bruker de RPA i forbindelse med arbeidsordre, driftsplanlegging, regnskap og for å flytte data mellom ulike systemer. De vurderer om prosessen som foreslås skal innlemmes i systemet eller om de skal bruke RPA. De ser på RPA som en midlertidig løsning og mener det er et fint verktøy å bruke for å få ulike prosesser automatisert i påvente av integreringer.
De jobber ut ifra et rammeverk som lar dem jobbe smidig for å raskt få løsninger opp og gå. Siden de er to som jobber med RPA har de få ressurser. Per i dag mottar de innspill fra de ulike
miljøene/prosessrådgivere om hvilke oppgaver RPA kan brukes på. De ønsker å bli mer proaktive i dette arbeidet, men er ikke der nå.
For å vurdere et forslag har del laget ulike maler i Excel hvor de gir poeng til de ulike
vurderingskriteriene som kost/nytte, antall, tid og kvalitet. De ser også på hvordan det påvirker arbeidsoppgavene til de ansatte siden det ikke er et mål å fjerne jobber. I vurderingen av kostnader ser de på hvor mange skjermbilder må det klikkes gjennom, eksisterende systemer, nye systemer, er
46 (Statnett u.d.)
47 (Statnett 2019)
48 (Forskrift om systemansvaret i kraftsystemet 2002)
49 (Statnett 2018)
50 https://www.youtube.com/watch?v=fqufZ8zSMKw&t=9s rundt 1:35
33 dataene strukturerte eller ikke, er det klare regler både for prosedyren, eksterne og programvaren, kan de endre prosessen og hvor stor variasjon det er i prosessen/hvor mange variasjoner det er.
Totalsummen av de ulike kriteriene vil vise hvor egnet RPA er til den aktuelle oppgaven. Når en prosess er valgt ut utarbeider de en detaljert prosess beskrivelse (DPB). Her blir hele prosessen beskrevet ned til hvert enkelt klikk. Denne må godkjennes av prosessleder.
Etter godkjenning må prosessleder forberede en akseptanstest. Deretter må tjenestemottaker prioritere de ulike utviklingsoppgavene som skal gjøres. RPA utvikleren lager deretter ulike tekniske tester og automatiserer løsningen. Etter utført og godkjent akseptanstest fra prosessleder blir løsningen satt i produksjon og implementert. Siden det er boter som skal kjøre på egen hånd vil de i starten følge mer med i starten for å være sikre på at den fungerer som ventet og etter en stund vil de la den jobbe for seg selv. Denne prosessen er beskrevet i Figur 4-1 under. Denne figuren er et utkast laget av de som jobber med prosessen og avventer godkjenning av ledelsen i Statnett.
Figur 4-1 Utkast til prosesstegning for RPA i Statnett
Siden Statnett er et statsforetak med ansvar for strømnettet, forvalter de en svært kritisk
infrastruktur. For å ivareta dette jobber de ut ifra ulike målbilder. Målbildet for en prosess kan kan være xxx oppetid på anlegg og yyy forsyningssikkerhet. Mens målbilde for styring og kontroll dreier
34 seg mer om at de har kontroll på at de gjør de riktige tingene i prosessen/prosedyren/sjekklisten og at det de sier de skal gjøre blir gjort. Statnett bruker risikostyring som metodikk knyttet til
internkontroll. Dette går ut på å identifisere risiko, identifisere tiltak og gjennomføre disse. Med denne metodikken sørger Statnett altså for at prosessene og prosedyrene har krav og kontroller som bidrar til at risikoen knyttet til oppnåelsen av målbilde i Figur 4-2 nedenfor håndteres
tilfredsstillende.
Figur 4-2: Statnetts målbilde for styring og kontroll
Som vi kan se av bildet over er ett av målene å overholde eksterne lover, regler og interne krav. For å holde oversikt over hvilke eksterne lover og regler som treffer Statnett bruker de en
samsvarsmatrise. Denne viser i tillegg til hvilke lover og regler også hvordan disse er ivaretatt i policy/instruks/prosesser/prosedyrer, samt i tilhørende nøkkelkontroller. Vurderingen av samsvar er risikobasert. Samsvarsmatrisen skal gi oversikt over status og danner grunnlag for å planlegge forbedringer av styringssystemet. Dette gjør dem i stand til å sjekke i hvilken grad målet om å
overholde eksterne lover og regler er oppfylt. De har også mulighet til å gjøre tilsvarende vurderinger for interne krav.
4.2 Statkraft
I 2004 ble virksomheten til Statkraft SF overført til et underliggende aksjeselskap med tilhørende datterselskaper. Statkraft AS er i dag organisert som et konsern som er delt opp i fire
forretningsområder, produksjon, vind- og solkraft Europa, internasjonal kraft og marked og IT samt to stabsområder, finansdirektørens stab og konsernstaber.51 De opererer i 17 land med 4500 ansatte
51 (Statkraft u.d.)
35 over hele verden. Statkraft konkurrer i det åpne kraftmarkedet på lik linje med andre
kraftprodusenter.
Det er særlig innenfor finansområdet de har tatt i bruk RPA. De har i lang tid jobbet med
automatisering og stilte seg spørsmålet: «Må vi endre oss?», «Ja, men hvordan?». I 2016 startet Statkraft RPA reisen med en workshop hvor de ble mer kjent med teknologien og snakket med ulike aktører. Her stilte de seg spørsmålene hva betyr det å ta i bruk roboter, hva kan utbedres av dagens løsninger og hva kan ny teknologi gjøre for å løse disse problemstillingene og matche gammelt og nytt sammen. De valgte å bruke RPA for noen utfordringer som ikke krever noen særlige endringer i programmer de bruker. Tidligere måtte de få IT inn for å gjøre slike endringer. De har et mål om å bli mer selvstendig. De har i dag et Center of Excellence bestående av 5 personer. I 2016 lagde de en bot som koblet seg til Nord Pool kontoen til Statkraft for å hente ut data som de bruker til å kontrollere efakturaer. Dette er ikke en tidskritisk oppgave og tidligere de brukte en student til å gjøre denne oppgaven. Boten jobbet i nesten 1 år uten at det var nødvendig med endringer, men oppdateringer i Google Chrome og på nettsidene til Nord Pool skapte utfordringer. Nå har det kommet på plass en løsning med API som er mer stabilt.
De første erfaringene med teknologien er positive og i årene etter øker antallet boter. De blir blant annet brukt til å fordele data mellom systemer, men igjen dukker problemet med ustabile kilder opp.
Dette gjelder særlig for kilder og systemer utenfor deres kontroll. Siden Statkraft driver over hele verden, trenger de data om ulike valutakurser. For eksempel brukte de en bot for å hente
valutakurser fra Peru. Det ble gjort ved å gå til nettsidene til det peruanske finansdepartementet for å finne gjellende kurs. Finansdepartementet i Peru står fritt til å endre nettsidene sine når de vil og dette skapte utfordringer for boten.
Intervjuobjektet i Statkraft estimerer at de bruker ca. 4 timer på å programmere en bot og at de bruker omtrent 1 time i uken på å vedlikeholde den. Det er noe av grunnen til at han ser på RPA som en midlertidig løsning. Et annet eksempel han brukte var tolkning av vedlegg fra brokers. Her gikk treffsikkerheten ned over tid fra ca. 80% til ca. 20%. Dette førte til at de valgte å bygge boten på nytt.
Nå kontrolleres og behandles vedlegg etter filtype (er det xml, pdf, etc.) og ikke etter innhold.
Statkraft bruker SAP 2008 ERP som kjernesystem, dette er stabilt, men det er treigt å endre siden de må vente på oppdateringer fra leverandøren. De er nå i prosess med å oppgradere til en nyere versjon. Denne tregheten er noe av grunnen Statkraft bruker RPA. En annen del er at botene kan jobbe raskere en mennesker og et eksempel på dette er hvordan Statkraft sjekket opp
merverdiavgifts opplysninger om forskjellige leverandører og kunder hos Brønnøysundregistrene.
Det er snakk om rundt 7000 oppslag. Tidligere måtte dette søkes opp manuelt en og en på
36 nettsidene til Brønnøysundregistrene. Med RPA ble denne oppgaven gjort over natten og de ansatte i Statkraft kunne bruke tiden sin på andre oppgaver. Nå som Brønnøysundregistrene har laget en løsning med API for denne typen oppslag er det ikke lenger nødvendig å bruke en bot til dette og oppslaget med API for alle 7000 tar ca. en time.
I Statkraft er de tydelig på at en bot IKKE erstatter en person. Detter er fordi en person sitter på mye kunnskap om prosessen og hvis boten går ned må noen kunne dekke jobben. Denne kunnskapen er viktig ved vedlikehold av botene.
Når det kommer til utvikling av botene mener intervjuobjektet at det er viktig å bruke litt tid på å vurdere om det er en god ide å automatisere denne prosessen med RPA. De har en ambisjon om at brukerne skal kunne gjøre mye av jobben med automatiseringen selv og at de i CoE kan sjekke om den er godkjent. Her kan det bli fare for skygge automatisering hvor brukere har laget løsninger på siden av de godkjente løsningene. I slike tilfeller vil ikke CoE kunne hjelpe når boten slutter å fungere.
Det lages en bestilling av en automatisering av en prosess. Her kreves det en tydelig dokumentasjon av prosessen og hva boten skal gjøre. Roller og ansvar klargjøres, boten programmeres og debugges og det gjøres versjonskontroll. 30% av jobben med å lage en bot er å utarbeide beskrivelsen av prosessen. En business analytiker går inn og siller alle de «dumme» spørsmålene. De jobber tett sammen med brukerne for å få en grundig beskrivelse av prosessen. Jo bedre beskrivelse jo bedre kan de estimere hvor lenge boten kan jobbe uten større vedlikehold. Her har de fått inn en ingeniør med erfaring fra oljebransjen som har hevet kvaliteten på estimatene. For å nå målet om at alle de ansatte skal kunne lage/automatisere løsninger som de i CoE kontrollerer kvaliteten til må brukerne
37 få en god opplæring. Statkraft er ikke der i dag, men ønsker å komme dit. I Figur 4-3 under vises veien fra forslag til en bot settes i drift.
Figur 4-3 Hoved stegene i RPA prosessen hos Statkraft. Presentasjon mottatt på e-post av informant 3
Dette var ikke en del av samtalen, men en presentasjon informant 3 hadde holdt i februar 2021 som han videresendte til meg. Ulike forslag til prosesser som RPA kan brukes på kommer inn fra
forskjellige aktører i organisasjonen. Disse blir så vurdert og definert for så å få en prioritering. Så begynner de å designe hvordan prosessen med RPA ser ut. Her ser vi også at Statkraft gjennomfører en vurdering av personvernskonsekvenser som må godkjennes før de går videre. De kaller det en
«DPIA light» så det dreier seg om en forenklet vurdering av personvernskonsekvensene. Etter dette kommer planlegging og selve utviklingen. Utviklingen foregår etter smidige metoder og de har daglige Scrum møter. Når utviklingen nærmer seg slutten, gjør de en ny runde med prioritering. Her blir også koden gjennomgått og vurdert. Når dette er gjort starter de med akseptanstesting. Her tester de om boten tilfredsstiller de ulike kravene som stilles og når disse er oppfylt er det klart for å sette boten i drift.
4.3 Avinor
Avinor er et statseid AS som drifter 44 flyplasser i Norge. De leverer også flysikringstjenester for sivil og militær sektor. Selskapet finansieres gjennom salg på flyplassene og ulike avgifter knyttet til luftfart. Avinor har i dag rundt 3000 ansatte. Hos Avinor har jeg snakket med to personer, en fra IT og en fra fortetningsstøtte. I Avinor ligger ansvaret for RPA hos IT: konsern, ledelse og støtte. De støtter
38 forvaltning med ulike løsninger. De har jobbet med RPA siden ca. 2017 og bruker UiPath levert av Sopra Steria.
4.3.1 Informant 4
RPA kan brukes på en del administrative prosesser (HR, arkiv, etc.). Her er det mye manuelt arbeid og dårlig flyt mellom systemer. Avinor hadde ved start et mål om å redusere mengden manuelt arbeid og ansatte. Informant 4 beskriver en situasjon der valg av løsning (RPA) kommer før prosessen er grundig vurdert og eventuelt optimalisert. Hun føler de som organisasjon har en del å gå på. De har i dag ikke en standardisert systematisk prosess for å velge ut prosesser som kan være egnet til RPA. Hun opplever bruken av RPA som lav. RPA blir av IT sett på som en merkostnad når ande underliggende systemer oppgraderes/oppdateres siden botene må rettes på for å fortsette å fungere. RPA er ikke alltid løsningen siden det finnes flere måter å løse et problem på f.eks. mer tradisjonelle integrasjoner mellom systemer. Holdningen i IT er å være litt tilbakeholden.
I Avinor har de gjort en vurdering om de skal ha egne ansatte med kompetanse på RPA eller om de skal bruke konsulenter. Siden de er usikre på hvor mye RPA kan brukes og at det kreves en viss teknisk kompetanse selv om det er low code har de valgt å gå for konsulenter. Konsulentene kan RPA godt, men kan risikere å hoppe over andre ting som for eksempel prosess optimalisering.
Med RPA er lett å få opp en beta, med det er en del finpussing for å få den bra. Som informant 4 sier:
«Ja du kan få opp en midlertidig løsning relativt rask, men er det verdt å bruke 100 000 på noe som skal brukes i noen måneder?»
Fremover kunne de se på en hybridløsning der IT ikke sitter med alt av ansvaret. Den største utfordringen de har i dag er knyttet opp mot systematikk og styring siden de ikke har et fast rammeverk.
4.3.2 Informant 5
Implementerings prosjektet brukte ca. 1 år. De hadde inne ca. 1,5 konsulenter og produserte løsninger for 10 prosesser. Dette initiativet kom fra forretningsstøtte. Forretningsstøtte driver med regnskap, operativt HR, dokumentforvaltning som arkiv og dokumenthåndtering, adgangs kontroll og har en administrativ stab. Frem til 01.01.21 hadde de operativt innkjøp, men dette er nå slått
sammen med strategisk innkjøp.
Avinor startet RPA reisen sin i 2017. Informant 5 fikk på våren se hvordan noen andre virksomheter brukte dette og ble nysgjerrig. Han startet å undersøke hva dette var for noe og om det var noe for Avinor. De var først ute i konsernet med å ta det i bruk og i dag brukes det i flere deler av
organisasjonen, blant annet til appen som viser avgang og ankomst tider.
39 De inviterte noen ulike leverandører til workshop for å lære mer og etter dette gikk de videre med Sopra Steria som partner fra høsten 2017. Gjennom kartleggingsarbeidet ble det klart at de hadde en del gjentagende oppgaver. I avdelingen har de ca.90-100 ansatte med en snitt alder på ca. 48 år og en stor andel nærmer seg pensjonsalder eller AFP alder. Dette innebærer en del som skal slutte i de nærmeste årene. Noe av målet ble å kunne automatisere slik at de ikke trengte å ansette like mange som gikk ut. Dette ville være med på å nå målsetninger om effektivisering og rasjonalisering.
For å forankre initiativet samlet de alle de ansatte til et møte der de la frem hvorfor de ville ta i bruk
«roboter». Det er ikke for å si opp folk, men for å møte fremtiden som kommer og de endringene det innebærer. Ledelsen så på dette som et verktøy for å klare å henge med i utviklingen. Etter møtet satt ledelsen igjen med et inntrykk av at mange var positive, men at det også var litt frykt for å miste oppgaver/jobben. Videre ble de 5 avdelingslederne utfordret til å komme med 3 caser hver som kunne passe til RPA. Dette ble gjort som en konkurranse mellom avdelingene og internt i avdelingene siden de skulle velge ut 3 vinner caser som ble brukt til proof of consept (PoC). Disse tre var:
1. Adgangskontroll 2. Klagebehandling 3. Innkjøp
Gjennom denne prosessen så de at RPA er noe som kan passe dem bra. Særlig på arkiv så de en nytteverdi og at dette kan gjøre at fagfolk jobber med fag og ikke klipp og lim, flytte dokumenter hit og dit. Det kan den digitalemedarbeideren Roy autopilot ta seg av.
Roy kjører ca. 20 ulike prosesser. Han behandler omtrent 100 000 fakturaer i året, oppretter leverandører, sorterer og arkiverer 6000 henvendelser fra Avinor.no med klager, ris og ros. Her har de tatt i bruk maskinlæring for å sortere riktig. Roy kan kjenne igjen mønstre i teksten og trekker ut grunn info, oppretter sak og sender den til rette vedkommende. Dette var en manuell jobb før, men nå dekker Roy ca. 99% av sakene.
I Avinor har de tråkket opp stien mens de gikk og de har lært underveis i prosessen. Nå prøver de mer systematisk å sette opp buisnes case for mulige kandidater og ser på hva kostnadene for å lage er og hvilke gevinster gir det som for eksempel tid spart. Er dette positivt vil det sannsynligvis settes i drift.
4.3.2.1 Kulturell lærdom
IT har vært involvert fra starten og har vært med hele veien. Informant 5 kom til dem med en ide om at RPA er spennende, dette må jo IT være gira på. Det viste seg at det var de ikke. Han opplevde at motstand i IT organisasjonen førte til noen forsinkelser i 2018. Blant annet mener han at det tok
