insights article

RPA-konceptet: automatisering eller brugervenlighed?

Få inspiration
Tilmeld dig vores nyhedsbrev, og få et fagligt indspark med substans direkte i indbakken.
Del artikel
Del artikel

RPA dagen derpå

De grundlæggende årsager hertil kan være mange, og de er også velbeskrevne: Processerne var for fragmenterede; IT var ikke om bord og ændrede hele tiden forudsætninger uafhængigt af RPA-projektet; der var ikke tilstrækkelige ressourcer internt, der kunne overtage robotten; robotten blev ikke tænkt ind i en større løsningsstrategi og blev en ’dum’ medarbejder, der ikke gav anden værdi end den manuelle. Og mange flere. Og hvis man vil løse disse problemer, kan man være sikker på, at der er endnu en udgift forbundet hermed, og dermed at ens forventede ROI stille og roligt afslører sig som et spejlblankt, flimrende fatamorgana i horisonten. For slet ikke at nævne tidsplanen.

RPA er død - længe leve RPA!

Hvis vi skal undgå dette dødvande, og RPA skal opnå den plads, det retteligt har krav på, handler det om at vende hele konceptet på hovedet. Det koncept, der skal bevises i en Proof of Concept, er ikke automatisering. Det er efterhånden bevist og burde til dels være indlysende, at IT-systemer kan automatiseres ved hjælp af IT. Så kan man skulle bevise graden af kompleksitet i sin automatisering, nuvel, men det er ikke jo ikke det, der efterspørges, når man vil have et bevis på et nyt produkt. Forestil dig at købe en bil – du vil have Proof of Concept – en demo. Sælgeren sætter bilen op på en autolift og viser dig, hvor hurtigt hjulene kan køre rundt. Eller han sætter dig ind på bagsædet og kører en tur med dig. Det er ikke helt nok, vel? Det koncept, du ønsker bevist, er ikke, om bilen kan køre, og hjulene kan dreje rundt. I stedet ønsker du at teste, hvordan den passer til dig. Det indebærer: Kan jeg lide, hvordan jeg sidder i bilen?; er den tilpas avanceret at benytte?; får jeg brugt alle funktionerne, eller kan jeg neddrosle? Og så videre. Det vigtige koncept for bilforhandleren er altså rettet mod dig, modtageren, og din fornemmelse for bilen. Det er årsagen til, at bilforhandlere lader dig køre deres demobiler. De skal ikke bevise, at bilen kan køre, men deres bil skal være bedst for dig.

På samme måde skal konceptet for RPA heller ikke være, om opgaven kan automatiseres. For det kan den formentlig, hvis du kan forestille dig det. I stedet må konceptet nødvendigvis være, om du kan finde ud af at anvende værktøjet. Husk, at det ikke er, om du kunne tænke dig resultaterne ved en automatisering, men om du kan anvende det nye redskab, du har købt til dit IT-skur, som skal stå ved siden af ERP, MS Office mm. Kan du lide, hvordan det ser ud? Er det intuitivt? Føler du dig hjemme i interfacet? Kan du løse de problemer, der unægteligt dukker op? Kan du selv sætte den op til at tage dig fra A til B? Konceptet må og skal være rettet mod modtageren og den, der skal bruge værktøjet.

Når jeg er ude som konsulent, er vi begyndt at udtale denne forandring: Vi ønsker ikke at bevise automatisering, men brugervenlighed. Vi ønsker at sælge kurser og workshops, der beviser, hvor nemt det kan være. Jeg arbejder primært i RPA-værktøjet Foxtrot fra Enablesoft, som velsagtens er det nemmeste og mest intuitive værktøj på markedet. Dermed ikke sagt, at det er et værktøj, som alle vil kunne lide – nogle vil føle sig mere hjemme med mere avancerede interfaces og mere hands on-kodning. Jeg har dog via mit arbejde i Basico god erfaring for, at når vi beviser brugervenlighed på et kursus med Foxtrot, så giver det dyb genlyd hos kursisterne. Folk tager det til sig i alle afdelinger på alle niveauer og – vigtigst af alt – ofte uden forudgående IT-skills af nogen art. Det er ganske unikt på markedet, og jeg kan mærke, at det er i den retning, RPA er nødt til at bevæge sig for at komme ud af sit dødvande. Automatisering må ikke være et IT-projekt, for der er allerede tusindvis af IT-projekter i en forsinket pipeline, og hvis du alligevel sætter en IT-ekspert på arbejde, hvorfor så ikke bare lave et API, en ny applikation eller en tilføjelse til dit ERP? RPA skal være et redskab, der kan anvendes af den enkelte medarbejder, lige meget hvad han eller hun arbejder med til daglig.

Derfor: RPA skal bevise, at det er brugervenligt og kan forankres hos modtageren direkte ude hos procesejeren. Det er her, den virkelige udfordring ligger. Men det er også det, der allerede til dels ligger til grund for al hypen: Robotter skal være allemandseje er forestillingen, teknologi skal demokratiseres, det skal være dit og mit. Indtil videre har RPA og de fleste leverandører dog været fokuseret på udelukkende automatiseringsdelen. Men det har aldrig været her, kimet til hypen lå. POC-kirkegården er derfor ved at fyldes med projekter, ingen kan genoplive.

Helt grundlæggende bør logikken være, at hvis du kan undervise den nuværende procesejer i at automatisere, så får du den mest optimale automatiseringskonsulent på den pågældende opgave. Det betyder, at flere af de udfordringer, der blev nævnt i toppen, nemmere og hurtigere løses. Lyder det fornuftigt? Så lad os være enige om at ændre konceptet for RPA: Alle kan lære at automatisere. Det er det endemål, vi skal gå efter.

Få vores faglige magasin Content

I Content finder du masser af inspiration til supportfunktionerne i form af faglige artikler og tankevækkende interviews.