RPA bør være et plaster, der skal fjernes igen

RPA-teknologien er smart, men den kræver både omtanke og eftertanke for alle parter. Johnny Vad, der er it-chef hos Aalborg Kommunes Familie- og Beskæftigelsesforvaltning, deler i dette indlæg sine betænkeligheder ved brugen af softwarerobotter - og giver et bud på, hvad man bør overveje, inden man går i gang.
Brødtekst

Vi har i Familie- og Beskæftigelsesforvaltningen i Aalborg Kommune nu arbejdet aktivt med anvendelsen af softwarerobotter i en årrække og er efterhånden blevet ret gode til at udnytte teknologien, når vi nu selv skal sige det.

Efterhånden som platformen til RPA (Robotic Process Automation, red.) er blevet bedre – og de forskellige fagsystemer, vi anvender, har nået et modenhedsniveau (web-teknologi), hvor det også er forholdsvis simpelt at komme i gang, har vi på det seneste oplevet en 'overflod' af tilbud om RPA-løsninger. Det indikerer, at anvendelsen af teknologien er ved at gå ind i en fase, hvor RPA kompenserer for en systemleverandørs manglende evne til at tænke en løsning rigtigt ind fra starten – eller manglende vilje/evne til at optimere sin løsning i forhold til aktuelle behov.

Vi har oplevet at få tilbud fra leverandører af fagsystemer om RPA-løsninger til at kompensere for processer i egne fagsystemer – naturligvis mod ekstra betaling. Når vi så sætter et alvorligt spørgsmålstegn ved dette, er svaret typisk, at andre kunder jo med glæde har tilkøbt disse RPA-robotter. Dels – naturligvis – for at få optimeret deres arbejdsproces, men mindst lige så vigtigt for at kunne sige, at de nu også i deres organisation har taget RPA-teknologien i brug.

Enøjet fokus bliver en bekostelig affære

RPA tilbyder nogle fantastiske muligheder for at automatisere og optimere steder, hvor det ellers ville være svært eller helt umuligt. Men hvis vi som systemejere alene satser på at optimere på denne måde, vil vores TCO-omkostninger på it-området vokse, vokse og vokse, og den rigtige løsning vil aldrig blive udviklet.

Vi har hos os netop rundet potentialeafklaring på softwarerobot nummer 150. Af disse mange potentialer har vi kunnet anvise andre løsninger end RPA for langt hovedparten. En god del med henvisning til, at den ønskede funktionalitet/optimering kunne opnås på anden vis; enten i selve løsningen eller via en mindre omlægning af arbejdsgangen omkring denne.

En anden stor mulighed, som vi ofte sætter i spil, er en målrettet udnyttelse af vores eksisterende BI-miljø, der reelt kan bruges til meget mere end 'bare' at lave opfølgningsrapporter på økonomital, men også bruges til f.eks. opfølgning på datakvaliteten i vores fagsystemer – og dermed om systemerne benyttes som tiltænkt.

Vi bruger en del forskellige fagsystemer i vores forretning, og vi modtager derfor løbende tilbud fra forskellige aktører om, at de kan etablere og bearbejde data fra andre systemer end deres egne ved at lade softwarerobotter udlæse data og derefter generere smarte rapporter, overblik eller måske endda forsendelser af breve.

Måske var det en god løsning, hvis det ikke havde været fordi, sådanne data ofte allerede findes i vores datawarehouse – og at denne platform allerede indeholder analyseværktøjerne, der med en lille indsats kan bringes til at levere det samme. Og havde vi ikke allerede data dér, så vil det i mange tilfælde være både billigere – og mere it-arkitekturmæssigt rigtigt – at bede vores fagsystemleverandør om at etablere et udtræk frem for at bede en tredjepart om at etablere dette via en RPA-løsning i forhold til systemets skærmdialogvinduer.

Jeg har stor forståelse for, at leverandører gerne vil etablere et salg, og at et salg af en RPA-løsning frem for en optimering af en eksisterende løsning ofte vil give en langt højere fortjeneste, hvorfor man som systemejer nok kan forvente dette.

Smart eller manglende kontrakts- og leverandørstyring?

Har man et eget internt RPA-team, har jeg stor forståelse for, at dette 'hurtigt' kan løse en spændende opgave, og at det kan være fristende at sætte i gang. Men man bør altid tage sig tid til en hurtig proces, der reelt vurderer alternativerne – herunder måske en dialog med ens leverandør af det/de fagsystemer, der er i spil. Måske er denne ikke selv klar over, at løsningen har mangler og dermed udviklingspotentiale.

Et lille 'smut' forbi kontrakten kan ofte også betale sig, da mange leverancer faktisk inkluderer en ikke ubetydelig aftalt mængde videreudviklingsarbejde. Så måske er den bedste løsning faktisk også en gratis løsning.

Er du systemejer, og har du kørende RPA-løsninger, så bør du med mellemrum spørge dig selv, om de eksisterende RPA-løsninger nu også er et udtryk for 'smart' tænkning, innovation og optimering – eller om det snarere er et udtryk for manglende kontrakt- og leverandørstyring på de løsningsområder, som RPA-teknologien binder sammen?

Er du leverandør af it-systemer, hvorpå dine kunder i overvejende grad er begyndt at bruge RPA-teknologi (uanset om det er dine egne eller leveret af andre), så bør du nok overveje, hvilke mangler du har i løsningen, og hvor langt I er fra, at en anden leverandør kompenserer for dette. Ikke via en RPA-løsning, men en endnu bedre samlet it-løsning, der ikke kræver, at dine kunder køber eksterne RPA-robotter.

RPA-teknologien er smart, og der findes store potentialer, der i perioder med stor fordel kan udnyttes via denne. Men den kræver både omtanke og eftertanke for alle parter. Og husk nu, at de løsninger, der leveres, ikke bliver bedre end den kvalitet og løsningsmodel, som efterspørges.