Robotterne kommer – hold dem i kort snor

Af Peter Nørregaard, Expert Director

Robotic Process Automation (RPA) er i kraftig vækst. RPA-software er relativ let at implementere og hurtig at få til at generere værdi, sammenlignet med traditionelle it-systemer. Vejen til vellykket, og bæredygtig, brug af RPA er ikke uden risici, men rejsen kan lykkes ved at holde RPA robotterne i kort snor og styre dem uden om de mest almindelige risici og faldgruber.

Devoteam har omfattende erfaring med at udvikle og implementere RPA robotter. Devoteam er eksempelvis en af Nordens største leverandører af Automation Anywhere og har desuden fået tildelt udmærkelsen “Center of Excellence” af softwareleverandøren. På baggrund af denne omfattende erfaring med RPA og observationer hos kunder, både nationalt og internationalt, opstiller Devoteam her otte opmærksomhedspunkter på vejen mod en vellykket implementering af RPA:

1. Ændringer i brugergrænseflader
2. Licensforhold
3. Svækket Master Data Management (MDM)
4. Manglende efterlevelse af GDPR
5. Underminering af informationssikkerhed
6. Fare for “Robot Sprawling”
7. Performanceproblemer
8. Symptombehandling

Opmærksomhedspunkterne vil blive gennemgået nedenfor.

1) Ændringer i brugergrænseflader

RPA-robotter benytter it-systemers allerede eksisterende brugergrænseflader til at udføre de opgaver, de bliver sat til. Brugergrænseflader vil oftere blive justeret og ændret, sammenlignet med grænseflader længere nede i applikationsstakken. Sker der ændringer i brugergrænseflader, er der en sandsynlighed for, at robotten går i stå og ikke kan udføre sit job. Ændringer i brugergrænseflader kan i sagens natur være komplekse. Selv med den nyeste udvikling inden for RPA-teknologi er der ikke sikkerhed for, at robotter kan håndtere ændringer i brugergrænsefladen.

Hvis robotterne er opsat lokalt, er der yderligere en risiko for, at fejl ikke opdages under de sædvanlige procedurer for aftestningen af nye software-versioner.

Robotternes aktiviteter (RPA-driften) bør derfor overvåges centralt, så de kan blive testet og rekonfigureret hurtigt, hver gang det sker.

2) Licensforhold

Robotterne er virtuelle brugere af virksomhedens applikationer, men virtuelle brugere er kun sjældent dækket eksplicit i eksisterende licensaftaler.

Den typiske fortolkning af en RPA-robot vil være, at den sidestilles med en menneskelig bruger, og at RPA-robotten derfor skal have en licens af samme slags.

Hvor mange licenser, en RPA-robot skal have, kan dog være uklart. I nogle licensaftaler kan en navngiven bruger have flere sessioner åbne ad gangen uden at overtræde licensbetingelserne. En RPA-robot kan meget effektivt udnytte mange sessioner parallelt, evt. til forskellige opgaver på samme tid, hvilket udnytter licensens muligheder til – eller ud over – grænsen.

Når en RPA-robot anvendes til integration mellem systemer, kan der være et særligt opmærksomhedspunkt i forhold til licensbegrebet multiplexing. Multiplexing dækker over, at én licens benyttes af flere brugere, evt. på en indirekte måde.

Hvis licensbetingelserne indeholder bestemmelser om multiplexing, eller andre formuleringer om indirekte brug, kan de licensmæssige konsekvenser af en integration, via RPA eller på anden måde, være voldsomme.

Et eksempel på, hvornår multiplexing har konsekvenser er, når en robot integrerer data mellem en webshop og regnskabssystemet. Eksemplet er: En slutkunde i webshoppen skal have en pris på en vare. En RPA robot flytter i realtid forespørgslen over i regnskabssystemet, som beregner ordrens pris, og svaret indtaster RPA robotten i en administrativ grænseflade på webshoppen, hvor den derefter vises til kunden. Her kan der, afhængig af fortolkning og tekniske implementeringsdetaljer, være tale om multiplexing. I givet fald kan virksomheden blive afkrævet licens for hver slutkunde, som på denne måde bruger prisberegningsfunktionaliten i regnskabssystemet.

Microsoft, IBM og Oracle er, blandt mange andre, kendte for at regulere multiplexing i deres licensaftaler.

Her er det Devoteams anbefaling, at der altid foretages en juridisk vurdering af licensmæssige konsekvenser af at anvende RPA-robotter. Det anbefales også at en i RPA-teamet – eller evt. en jurist med tæt forbindelse til RPA-teamet – gøres ansvarlig for brugslicenser til RPA-robotter.

I forhold til multiplexing bør en arkitekt inddrages i designet af integrationen, da der sandsynligvis findes løsningsdesigns, hvormed virksomheden kan undgå licensmæssige risici.

3) Svækket Master Data Management (MDM)

Master Data Management foreskriver kontrol over, hvor data skabes, og hvordan, og med hvilken kvalitet de behandles i virksomhedens applikationer. Med Master Data Management etableres én version af data, som er delt på en kontrolleret måde.

RPA kan være et middel til netop at sikre, at data flyder mellem applikationer, som ellers kan være svære at integrere. Når RPA-robotter bruges til integrationer, kan MDM imidlertid også blive udfordret.

Brugergrænseflader har typisk ikke indbyggede funktioner, der opdager nye eller ændrede masterdata. Eftersom RPA er baseret på brugergrænseflader, er der en reel risiko for, at RPA-robotten ikke kan opdage, når masterdata ændrer sig, eller når nye kommer til. Dermed vil der være forældede data i de applikationer, som robotten er sat til at overføre data til.

Devoteam anbefaler, at RPA skal inddrages i virksomhedens MDM-strategi, som et interessant middel til at understøtte MDM, men med opmærksomhed på de risici, der her er nævnt.

4) Manglende efterlevelse af GDPR

EU’s Persondataforordning (GDPR) stiller krav til at virksomheder skal beskytte, informere om, og på anmodning eller efter forældelse, være i stand til at slette persondata. Virksomheden skal kunne håndtere, at data har en livscyklus. En implikation af GDRP er derfor, at flowet af persondata mellem systemer skal være kendt.

Dette kan være en udfordring for nogle RPA-robotter, da det endnu ikke er alle, der understøtter monitorering af, hvor (person)data befinder sig på alle tidspunkter. Når virksomheden investerer i en RPA-løsning, som bruges til at bygge RPA-robotter i, anbefaler Devoteam, at governance samt udviklings- og dokumentationsstandarder er på plads, så RPA-robotternes behandling af persondata vil blive dokumenteret med henblik på at kunne spore disse data.

5) Underminering af informationssikkerhed

Applikationer, som indeholder kritiske data, beskytter disse via Identity and Access Management (IAM).

Hvis en RPA-robot flytter data fra én applikation med et IAM-regime til en anden applikation, er der risiko for at informationssikkerheden undermineres. Processen kan eksponere fortrolige oplysninger i en ny kontekst.

En RPA-robot skal derfor overholde IAM-reglerne på linje med andre brugere, og RPA-udviklere skal være særligt opmærksomme på det.

Når it-udviklere laver integrationer mellem systemer, er informationssikkerhed en del af deres faglighed og mindset. En løsning på problemet er derfor at uddanne RPA-udviklerne – nogle af dem er ikke it-kyndige i informationssikkerhed.

6) Fare for “Robot Sprawling”

Robot Sprawling er et begreb der dækker over, at anvendelsen af RPA-robotterne kan sprede sig ukoordineret, hvilket i øvrigt øger risikoen for at falde i de ovennævnte faldgruber.

Da RPA-robotter er så hurtige at bygge og sætte i produktion, kan organisationen risikere at have flere ukoordinerede robotter i drift og miste overblikket.

I nogle organisationer sker udviklingen og idriftsættelsen af robotter desuden decentralt. En tilsvarende situation var dengang, da Excel blev hvermandseje. De decentrale analyser og processering af data i regneark har over tiden givet mange udfordringer i forhold til korrekthed og fortolkning af data. Med Excel var følgevirkningerne nogenlunde begrænsede, da data blot endte hos brugerne. Med RPA-robotter kan konsekvenserne af forkert databehandling blive alvorligere, da problematiske data bliver lagt ind i systemer og spreder sig uden menneskelig indblanding og kvalitetskontrol.

Værktøjskassen til at forhindre Robot Sprawling er relativt velkendt og består bl.a. af god governance.

7) Performanceproblemer

Eftersom robotterne udfører handlinger i brugergrænseflader, som før teknologiens indtog var betinget af menneskelig interaktion, f.eks. fra en regnskabsafdeling, er der risiko for at automatiseringsprocesserne påvirker performance negativt eller ligefrem overbelaster systemerne. Selvom en RPA-robot som udgangspunkt efterligner en bruger, kan robotten, i kraft at sin automatisering, belaste systemet kraftigere end en menneskelig bruger.

Forud for deployment af robotten, bør der derfor testes, om der er risiko for at systemet bliver overbelastet.

8) Symptombehandling

Flere virksomheder oplever, at RPA kan kompensere for manglende systemintegrationer og bruges til at åbne legacy-siloer.

Når symptomerne på en sådan ufleksibel it-situation er blevet afhjulpet ved hjælp af RPA, er det fristende at ignorere de bagvedliggende problemer. Forretningsproblemerne er blevet løst, og fokus er rykket til andre vigtige gøremål, så hvorfor bruge krudt på det? Allerede nu, i det tidlige stadie som RPA befinder sig i, kan denne tendens ses i virksomhederne.

RPA bør ikke anvendes som erstatning for afvikling af teknisk gæld, eller for at tage de mere grundlæggende investeringer i fornyelse og modernisering, en it-portefølje kræver.

RPA-robotter er blevet beskrevet som it-arkitekturens svar på gaffatape: Godt at anvende på specifikke problemer med et afgrænset formål, eventuelt inden for et afgrænset tidsrum, men ikke hensigtsmæssigt at bygge videre på.

For at kunne lykkes med it-investeringer, også på længere sigt, er it-governance det måske vigtigste element, i forhold til hvornår, og hvordan RPA er en gangbar løsning.  Denne it-governance skal omfatte involvering af erfarne it-arkitekter til kvalitetssikring.

Etablér governance sammen med implementering af RPA

For at undgå de ovennævnte faldgruber kræves der tilstrækkelig governance. Overvej derfor følgende:

• Etabler procedurer for brugen af RPA, f.eks. i forhold til datasensitivitet, GDPR, eller i forhold til hvilken forretningsværdi, implementeringen tilfører.
• Hold trit med udviklingen ved at opbygge og vedligeholde viden omkring do’s and dont’s inden for RPA.
• Opret en portfolio over RPA-robotter og etabler Lifecycle Management. Forslag til implementering af nye robotter bør evalueres af en forretningsenhed, der har det fulde overblik over it-landskabet.
• Robotter bør være identificerbare som separate enheder i it-infrastrukturen – og bør identificeres automatisk.
• Det bør være påkrævet at registrere hver eneste robot, herunder input, output, timing og regler, med det formål at kunne dokumentere og foretage fejlsøgning på tværs af hele it-landskabet.
• Udvid it-governance til også at omfatte RPA-robotter med involvering af it-arkitekter til kvalitetssikring.

Vil du vide mere? 

Så er du velkommen til at kontakte Peter.

Vi stiller gerne op til faglige indlæg og individuelle møder om emnet.