RPA er en af de teknologier, der har eksisteret længere i danske virksomheder, end mange selv tror. Mange økonomi- og administrationsafdelinger har brugt små scripts eller robotter til at klikke sig igennem den samme rutine hver uge, længe før nogen begyndte at kalde det automatisering med stort A. Det, der er ændret de seneste år, er mest, at flere har lært ordet RPA at kende, og at salget af det er blevet en industri for sig selv.
Selve teknologien er stadig den samme i sin kerne. RPA står for robotic process automation, og det dækker over et stykke software, der kan udføre en rutine på en computer på samme måde som et menneske ville gøre det. Robotten åbner systemer, læser felter, kopierer tal, taster videre i et andet system og afslutter med at gemme eller sende. Den ved ikke, hvad den laver. Den følger en opskrift.
Det er værd at holde fast i, fordi det forklarer både styrkerne og svaghederne. RPA virker, når en proces er ensartet nok til at kunne beskrives skridt for skridt. Hvis et menneske ville gøre det samme hver gang uden at skulle tænke længere over det, er der gode chancer for, at en robot kan tage over. Hvis personen derimod hver dag tager små beslutninger, justerer noget i forhold til situationen eller skriver en mail med en bemærkning, der skal afvejes individuelt, så bliver opskriften pludselig meget længere og meget mere skrøbelig.
Mange projekter med RPA i danske virksomheder går skævt, fordi denne forskel ikke bliver afklaret, før indkøbet eller udviklingen begynder. Der bliver indkaldt til et møde, hvor en konsulent eller en intern projektleder taler om “alt det, vi kunne automatisere”, og listen vokser hurtigt. Det er først, når de første robotter sættes i drift, at det går op for organisationen, at netop de processer, der virkede oplagte, faktisk indeholdt en mængde små menneskelige vurderinger.
Den nøgterne tilgang er at starte med procesforståelse, ikke med teknologi. Den, der vil vurdere, om en konkret arbejdsgang er egnet til RPA, kan med fordel sætte sig sammen med den medarbejder, der udfører den, og kortlægge hvert skridt. Ikke som en proceslitteraturøvelse, men som en almindelig beskrivelse af, hvad personen klikker på, hvad personen læser, og hvad der får personen til at gøre noget anderledes end sidste gang. Det er ofte i de afvigelser, hele forretningen for automatisering ligger og falder.
En typisk velegnet opgave kunne være indlæsning af leverandørfakturaer fra et bestemt portalsystem, hvor felterne altid står de samme steder, og hvor reglerne for, hvad der skal i hvilken konto, kan beskrives præcist. Det samme gælder dataudtræk fra et ældre system, der ikke har et anstændigt API, men hvor en medarbejder hver morgen kører den samme rapport. Det er kedelige opgaver, og de er typisk netop derfor de bedste kandidater. Det kedelige er det forudsigelige.
En typisk uegnet opgave kunne være håndtering af kundehenvendelser, hvor henvendelsen kan handle om hvad som helst, og hvor en medarbejder hver gang skal afkode, hvad der reelt bliver bedt om, før der kan handles. Det kan også være sagsbehandling, hvor en lille detalje i en konkret sag flytter, hvilken regel der skal bruges. RPA er ikke en god ven i de tilfælde. Det er typisk dér, en sprogmodel eller et helt andet værktøj kommer på banen, og det er en separat diskussion.
Det andet fælles mønster er overautomation. Når en organisation først har set, at en robot kan tage en del af en proces, opstår der hurtigt en idé om, at flere skridt skal lægges ind i den samme robot. På et tidspunkt ender man med et stykke software, der ligner et større system, men som er bygget på den oprindelige opskrift uden den dokumentation, et rigtigt system ville have haft. Det er svært at vedligeholde, og det knækker, hver gang en kilde ændrer sig en lille smule. Det er en af grundene til, at en del RPA-implementeringer langsomt mister tillid i organisationen.
Den enkleste modgift er at sætte en grænse på forhånd. Hvis en robot bliver kompliceret nok til at kræve en projektplan, en testfase og en risikoanalyse, er det formentlig en rigtig systemudvikling, der skal i gang, og ikke længere en RPA-opgave i klassisk forstand. Det kan godt være, det skal laves alligevel, men det skal i så fald behandles som det, det er.
For den, der vil have et nogenlunde sammenhængende dansksproget overblik over, hvordan RPA passer ind sammen med nyere AI-værktøjer, ligger HverdagsAIs gennemgang af RPA
som et brugbart udgangspunkt. Den er holdt på et roligt niveau og forsøger ikke at love, at alt kan automatiseres. Det er en god tone at have med, når en virksomhed sætter sig ned og ser på, hvor RPA reelt kan tage noget fra hænderne på medarbejderne, og hvor det vil være en dårlig idé at forsøge.
Det vigtigste valg er sjældent, hvilket RPA-værktøj der skal vælges. Det er, om organisationen har vænnet sig til at beskrive sine egne processer godt nok til, at en robot overhovedet kan få lov at gøre noget, der giver mening i drift. Den disciplin er ikke ny. Den har bare fået et nyt navn.
