Automatiseringsprocesser eller Robotic Process Automation (RPA) vinder mere og mere frem og er for kontor-, bogholderi- og administrationsarbejde, hvad robotter er for produktionsvirksomheder, en automatiseret proces, der varetages af software i stedet for menneskelig behandling.

Der er en lang række fordele ved at indføre RPA, bl.a. nedbringelse af lønudgiften, sagsbehandling 24/7 med en ekstrem hurtig leveringstid samt fejlminimering - naturligvis forudsat, at det hele er opsat korrekt, og at løsningen kører.

Der, hvor automatiseringsprocesser umiddelbart giver mening, er i sektorer eller for arbejdsopgaver, der involverer mange ensartede rutinemæssige opgaver, og hvor man altså i princippet kan digitalisere arbejdsopgaverne ved at beskrive dem i et procesdiagram. Det kan være afstemningsrutiner, betalings- og opkrævningsrutiner, import af data fra et system til et andet, eller overvågning af fejldata. Hvis der er tale om meget få data, der måske ovenikøbet er ustrukturerede, eller skal der udøves skøn ved vurderingerne, så taler det imod anvendelse af automatiseringsprocesser. En del beskriver også RPA som kunstig intelligens - AI - hvilket må betragtes som en fejlopfattelse af, hvad AI egentlig er. RPA udfører ikke egne autonome handlinger, men udfører i princippet alene de opgaver, der er klart beskrevet i processen.

Anvendelse af RPA
Anvendelse af automatiseringsprocesser kan groft beskrevet ske på to måder; enten via en leverandør, der på vegne kunden bearbejder kundens data - også kaldet “managed service” -  hvilket også kan ske via en cloud/ASP løsning, eller ved at kunden erhverver licens til selve “robotten” - softwaren - som kunden kan installere i eget it-miljø.

Uanset hvilken model der vælges, bør anskaffelsen anskues som en forholdsvis kompliceret it-anskaffelse og understøttes af den rette kontrakt med de håndtag, der er nødvendig for at sikre kunden.

Kontrakten bør set fra kundesiden bl.a. navnlig have fokus på følgende områder:

Hvem installerer og sætter processerne op? Er det kundens eget ansvar, og er kunden sikker på, at RPA-løsningen i det hele taget kan køre på det it-miljø, kunden råder over? Hvem sætter automatiseringsprocesserne op? Er det noget, kunden skal eller kan selv, eller forudsætter det fx uddannelse i brug af løsningen?

Test- og overtagelsesprøve. Har kunden opsat krav, som RPA-løsningen skal overholde, fx navnlig hvis leverandøren skal implementere løsningen og opsætte processer, så bør der være aftalt en afprøvning med succeskriterier, og først ved godkendelse af prøven er løsningen leveret. Navnlig hvor der forudsættes en vis ”oplæring” og brug, før det kan konstateres, hvorvidt RPA-løsningen er opsat som aftalt, skal der tages højde for dette ved aftestningsprocedurerne.

Indsigt i processor og mulighed for selv at ændre. Har kunden indsigt i processerne, og kan kunden verificere og forklare resultaterne/output’et? Har kunden selv mulighed for at ændre processerne og inden for hvilke rammer?

Kompatibilitet og API’er. Som oftest skal RPA-løsningen hente/afgive data fra/til andre systemer via export/import grænseflader også kaldet API’er. Er kundens eksisterende systemer i stand til det - og er de kompatible med RPA-løsningen fx ved brug af åbne standarder? Hvis ikke, hvem har ansvaret for at tilvejebringe API’erne? Hvad sker der, hvis kundens øvrige systemer udskiftes eller fx bare opdateres med patches, nye releases eller nye versioner, og risikerer kunden så, at RPA-løsningen ikke længere fungerer eller skal tilrettes? Kan/vil leverandøren afgive garantier i den henseende?

Pris. Hvordan afregnes brugen af RPA-løsningen? Er der en del af betalingen, der sker efter forbrug fx mængden af behandlet data eller antallet af afstemninger, udsendelser af regninger eller lignende? Er det så regnet igennem med faktiske tal? Navnlig hvis der skal ske opjusteringer som følge af øget brug, er det også vigtigt at fastlægge, hvordan der igen kan “skrues ned” for brugen.

Fall-back. Rent internt bør kunden vurdere alle risici ved overgangen til RPA-løsningen, navnlig såfremt det betyder afskedigelse af medarbejdere, for hvordan kan kunden opretholde sin forretning og drift, hvis RPA-løsningen skulle fejle eller være helt nede? Er der mulighed for at indsætte andre systemer eller manuel behandling for en del af processerne?

Sikkerhed. Er der sket grundig aftestning, og er det muligt at overvåge processerne? Sker behandlingen af data hos leverandøren er der også spørgsmål om sikkerhed hos leverandøren og kommunikationen til/fra kunden. Det drejer sig både om “leverancesikkerhed”, fx redundante linier, backup m.v., men også fx krav til kryptering og beskyttelse mod hacking, virus m.v. Det gælder navnlig, hvis der er tale om særlig sensitive og afgørende data eller fx persondata.

Driftseffektivitet og oppetid. Hvilke garantier vil leverandøren give i forhold til, at RPA-løsningen skal være kørende og tilgængelig? Er driftstiden opdelt i fx primær og sekundær driftstid, og er der aftalt servicevinduer, inden for hvilke leverandøren skal iværksætte afhjælpning og opdatere løsningen, eller måske har ret til at tage RPA-løsningen ud af drift?

Svartider. Kan der garanteres for performance? Hvilke svartider/processerhastigheder må kunden kunne forvente?

Fejlafhjælpning og support. Hvad tilbyder leverandøren af support, og inden for hvilke tidsmæssige rammer skal leverandøren fx påbegynde fejlafhjælpning, og hvilke eskaleringsprocedurer er der. Kan/skal kunden tegne en vedligeholdelses- eller opdateringsaftale for softwaren, og hvor afhængig vil kunden være af leverandørens fortsatte support og vedligehold af RPA-løsningen?

 
Robotter-BechBruun

Ansvar for fejl i resultaterne. Fejl og udeblevne resultater kan groft sagt skyldes 4 årsager. Fejl i afgive/modtage-systemer, fejl i data, fejl i den opsatte proces eller fejl i selve RPA-softwaren. Der bør være opsat overvågning, der kan opdage sådanne fejl, men placeringen af ansvaret skal parterne tage stilling til. I de første to forhold må kunden nok være nærmest til at bære risikoen for, hvilket også som udgangspunkt gælder, hvis kunden selv har opsat processerne. Fejl i RPA-softwaren må være leverandørens ansvar, og det samme gælder, hvis leverandør har opsat processerne (forudsat at kundens beskrivelser er korrekte).

Rettigheder til softwaren. Som oftest vil kunden alene erhverve en licens til selve RPA-softwaren og dermed få tildelt en eller anden form for brugsret. Den brugsret skal vurderes; er det fx en virksomhedslicens, sitelicens eller licens pr. bruger. Endvidere bør det overvejes, om kunden som minimum kan få kildekoden deponeret til frigivelse, hvis kunden senere måtte ophæve aftalen som følge af leverandørens ophævelse.

Rettigheder til processerne og opsætningen. Det er vigtigt at sondre mellem rettighederne til selve RPA-softwaren og så processerne og opsætningen heraf. Det kan være tvivlsomt, hvorvidt de konkrete processer kan beskyttes efter de immaterielle regler, fx ophavsret, men desto mere er det vigtigt at få rettighederne til processerne klarlagt i aftalen. Som udgangspunkt bør det være kunden, der har rettighederne til de færdige processer, og parterne bør tage stilling til, hvorvidt leverandøren fx kan anvende/kopiere kundens procesbeskrivelser og processer til brug hos andre kunder. Procesbeskrivelserne og processerne kan være helt simple standardoperationer, men de kan også af kunden betragtes som kundens forretningshemmeligheder, og de arbejdsgange og procesbeskrivelser har kunden brugt mange ressourcer på at beskrive, og dem ser kunden naturligvis ikke gerne kopieret af nærmeste konkurrent.

Hvor er dine data og GDPR?
Er der tale om managed service eller en cloud/ASP-løsning, bør det være klarlagt, hvor kundens (person)data befinder sig, når de behandles, og der bør naturligvis indgås databehandleraftaler med leverandøren, hvis der behandles persondata. Af sikkerhedsmæssige årsager bør kunden i det hele taget bekymre sig om, hvor kundens data befinder sig, da det kan være sensitive data eller direkte forretningshemmeligheder. Kunden skal derfor lave en risikovurdering. Hvis der er der tale om persondata, skal det overvejes, om der er tale om en automatiseret individuel afgørelse, eller om der skal laves DPIA. 

Rettigheder til data og brug af dem. Har leverandøren ret til at bruge dine data, evt. i anonymiseret form eller som grundlag for benchmarking? Som kunde skal man være yderst opmærksom på, at kundens data er kundens ejendom, og hvis de overgives til leverandøren, fx i form af en cloud-løsning, så bør udlevering sikres, og leverandøren bør ikke kunne foretage tilbagehold i kundens data. Forbeholder leverandøren sig endvidere at kunne anvende kundens data til egne formål, så kan det give persondataretlige udfordringer, fx i form af videregivelse af persondata og/eller etablering af fælles dataansvar, uden at der er et retligt grundlag for leverandørens behandling af de pågældende persondata.

Misligholdelse. Hvad er misligholdelse, og hvornår kan kunden hæve aftalen? Er det et meget lavt serviceniveau, længere nedetid eller væsentlige fejl, der ikke afhjælpes? Hvordan er kunden stillet ved misligholdelse fra leverandørens side? Kan kunden få sine data ud af løsningen? Hvordan og med hvilket varsel? Hvad er business continuity-planen, hvis leverandøren skulle gå konkurs, slukke for adgangen, hvis det fx. en cloud løsning eller leverandøren bare holder op med at tilbyde support?

Ansvarsbegrænsninger. Som oftest har leverandøren begrænset sit ansvar i kontrakten, og oftest både fraskrevet sig fx indirekte tab, herunder mistet avance, driftstab m.v. samt begrænset ansvaret beløbsmæssigt. Navnlig mistet avance og driftstab vil netop være tab, som brugerne af RPA-løsningerne lider. Kunden bør overveje bod på servicemål, og aftale rammerne for udgifterne, som kunden kan få dækket til manuel behandling af data, hvis systemet ikke performer som aftalt.

Emnerne ovenfor er på ingen måde udtømmende, og alt efter om der er tale om køb af en løsning eller managed service, cloud eller ASP-løsning, vil der være særlige forhold, man bør overveje, og det kan være en god ide at søge inspiration i sædvanlige it-kontrakter. Der er dog al mulig grund til at forberede brugen af RPA grundigt, også set fra et juridisk perspektiv og ikke blot med fokus på den effektiviseringsgevinst, der lokker i horisonten, da en for kunden dårlig kontrakt kan få fatale konsekvenser for kundens virksomhed.