1. Organisatorisk placering #

Når man skal beslutte sig for, hvor et RPA-team skal ligge rent organisatorisk, så er der en væld af muligheder. Jeg tager udgangspunkt her i en fiktiv kommune, hvortil jeg har lavet et organisationsdiagram som vist. Markeret i rød er IT og Digitalisering, hvor det er mest optimalt at ligge sit team. Her kan man låne kompetencer, og undgå flaskehalse i udviklingen. I nogle tilfælde er dette forsat to separate afdelinger, og i det tilfælde er det mest rigtigt at ligge det i IT. Nedenfor er beskrevet tankerne bag dette valg.

Grundlaget for at ligge det i IT, er det know-how og ressourcer der i forvejen eksisterer i en IT-afdeling. Eksempelvis kan noget data, som skal tilgås igennem en brugergrænseflade, findes i en SQL-database, hvor man kan lave udtræk fra i stedet. Ved at have adgang til den viden, og eventuelt de kompetencer som skal bruges hertil fra IT, kan man udvikle hurtigere og mere drift stabilt. Yderligere har IT kendskab til deres IT-infrastruktur, som kan drille RPA software ind mellem. Det kan være alt fra gruppepolitikker, firewall porte, virtuel maskine vedligeholde, daglige udfordringer og lignende. Her er man også med i loopet til dagligt, når der planlægges opdateringer eller sker nedbrud, så man hurtigere kan reagere.

Digitalisering er også en mulighed, da det vil være en naturlig del af RPA-udvikling. Det er ikke ualmindeligt, at man kortlægger en proces, og finder ud af at data ikke er digitale nok til, at robotten kan udføre arbejdet. Herefter er det typisk en opgave for digitaliseringsafdeling, at se om problemet kan løses. Det er typisk blanketter som er problemet, da disse udfyldes på gammeldagsvis med blyant eller kuglepen, scannes og sendes rundt til flere hænder. Hvis man tager blanket-software med ind i sit RPA-team, som eksempelvis Xflow, kan man komme videre uden at involvere digitalisering. Der vil dog være tidspunkter, hvor det ender ud i en reel digitaliseringsopgave.

Som alternativ til disse to, kan man lave en Automatiseringsafdeling, hvis man har størrelsen som organisation. Denne afdeling kan beskæftige sig med RPA, AI, machine learning, procesoptimering samt digitale-blanketter. Man vil dog forsat skulle have et samarbejde med IT og digitalisering, da man vil berøre disse områder. Meget få organisationer er nået til dette punkt, hvor man benytter sig af alle disse emner. Det er dog ikke usandsynligt, at sådanne afdelinger kan blive almindelige ude i fremtiden.

Som den sidste overvejelse, er det muligt i noget RPA-software at have såkaldte citizen developers. Disse er menige medarbejdere, som også kan lave RPA-processer specifikt til deres egen afdeling. Power Automate Desktop er en mulighed til dette, da licensen er inkluderet i mange eksisterende licenser (Education, Business Basic, Enterprise m.f.). Det giver dog kun adgang til selve udviklingssoftwaren, hvor man kan bygge koden, og køre sine robotter i Attended tilstand på sin egen maskine i Default miljøet. Der er dog ikke gode erfaringer med dette, da koden typisk er af ringe kvalitet selvom den virker. Yderligere giver det problemer, når en medarbejder stopper som har ejet sådanne flow, da denne så stopper med at køre. Det vil typisk være RPA-teamet der får opgaven i at vedligeholde sådanne koder, og det giver mere arbejde end gavn. Af denne årsag er det ikke noget der kan anbefales, medmindre man vil investere ressourcer i at lære interne medarbejdere grundigt op.

2. Robotbrugere #

Det ikke er sikkerhedsmæssigt forsvarligt, at have en robotbruger med adgang til alt. Endvidere er det af personlig erfaring meget træls og tidskrævende, at skulle splitte en brugers rettigheder ud til flere, på et senere tidspunkt. Derfor bør man allerede fra starten planlægge, hvordan man vil lave brugerstyring til projektet.  Yderligere kan det også hjælpe med at give et overblik, over hvor mange licenser der skal bruges til projektet foruden RPA-softwarelicenserne. Her tænkes der Office, program specifikke og lignende.

Tankerne herunder bygger på det engelske udtryk compartmentalization, som kan anses som en begrænsning af adgang til oplysninger indenfor forskellige områder. Den ekstreme version af dette er at lave en robotbruger per proces, hvilket efter min egen mening er spild. Om du har 5 robotter som laver fakturering eller 1, så har de typisk de samme adgange i samme program, for at kunne udføre opgaven. Det kan også være svært at overholde adgangskodepolitiker, når man ender med 30+ brugere der skal have skiftet jævnligt. Der er også flere angrebsvinkler fra hackere, da de så har 5 muligheder i stedet, hvor de bare skal have fat i en af brugerne, for at få adgang til samme data. Det kan også gøre at man mister overblikket, når man begynder at have mange robotbrugere.

Hvis vi tager udgangspunkt i organisationsdiagrammet fra tidligere, kan man eksempelvis sætte brugere op således:

Man kan lave en bruger, hvor det giver mest mening. I ovenstående tilfælde er det lavet på forvaltningsniveau, da de ligner hinanden meget, og typisk vil have adgang/rettigheder til de samme ting. Ved stabene er det dog splittet op til flere brugere, da disse kan ende med at have adgange der er ekstra følsomme, og helst ikke skal krydse hinanden.

Små noter til tankerne bag dette:

• En servicekonto kan være rar at have, til tilfælde hvor man kun kan få en fælles adgang til et system (KMD Nexus som eksempel)
• Servicekontoen behøver ikke nødvendigvis en Office licens, de 7x ender nok med at skulle have det, plus eventuelt andre lignende licenser. Det skal regnes med i økonomidelen.
• Noget gammelt software har en maksimalt karakterantal på 6 i brugernavne
• Man behøver ikke oprette hver enkelt robot før den reelt skal bruges
  • Af erfaring er det ikke alle afdelinger som kommer lige hurtigt med på ideen, og derfor kan man fokusere på dem som vil i starten

3. Økonomi #

Der er omkostninger når man kører RPA-projekter, både til software, løn og eventuel hardware / licenser robotterne skal bruge. Af samme årsag bør man tænke på, hvordan man vil dække disse omkostninger løbende. RPA-software licenser er relativt billige. I skrivende stund kan man få en Power Automate unattended robot samt 2x udvikler licenser til knap 1.200 kr om måneden. Som nævnt i robotbrugere afsnittet, er en anden typisk licens der skal bruges en Office-licens.

I forhold til løn af medarbejdere, så starter næsten alle RPA-projekter op i en pilotfase. Her inddrager man eksisterende medarbejdere, på x antal timer om ugen. Så det kan være svært at beregne lønnen med ind som omkostning til at starte med. Når man kommer ud af pilot-fasen derimod, og man skal have fuldtidsansatte til sit RPA-projekt, skal der også bruges et noget større projekt. Licenserne er småpenge, kontra hvad det koster, at have fuldtidsmedarbejdere siddende.

Af samme årsag bør man undersøge, hvordan man eventuelt vil finansiere sit projekt. Man kan i starten køre en “ingen kvaler IT betaler“, og yde det som en ekstra service fra IT-afdelingens side. Når projektet først er kommet op og stå, og det kræver fuldtidsansatte til at køre det, så løber regningen årligt hurtigt op i hundredtusinder hvis ikke millioner kroner primært til løn. Herfra kan det være svært at budgettere det, uden at få ekstra midler til formålet et sted fra.

For at forklare hvordan de bedste erfaringer ser ud, er det nemmest at starte med en af de dårlige. Det er forsøgt med en ordning, hvor en afdeling skal betale for udviklingen, og senere løbende drift af en RPA-proces. På papiret lyder det som en udmærket ide, det kan dog være svært at fastsætte en pris på begge ydelser. Endvidere risikerer man, at RPA-projektet går i stå, da man så vil konkurrere på lige fod med konsulenthuse, som tilbyder samme service ude i byen. Samtidigt får man en flaskehals, da der går bureaukrati i hver gang en afdeling skal udvælge en proces til RPA. Her vi der blive opvejet med tid og kroner, om det overhovedet kan betale sig, at få udviklet RPA-processen. Nogle processer sparer ikke kroner eller tid, men kvalitetssikre noget arbejde. Et eksempel jeg selv har haft, var en rapport der skulle sende til borgmesteren en gang i måneden. Det var en proces der ikke tog medarbejderen lang tid at lave, den blev dog tit nedprioriteret eller glemt blandt vigtigere opgaver. En sådan RPA-proces tager måske en dag at udvikle, men hvad skal drifte koste? Hvis det koster mere at få udviklet end timelønnen for medarbejderen, så kan det fra afdelingen side sjældent betale sig at få den lavet. Så man risikerer, at gå glip af mange processer med RPA-potentiale, blot fordi der er en pris på at få det udviklet.

De bedste erfaringer derimod, er hvor man skal tænke så lidt på økonomien som muligt. Eksempelvis kan afdelingen med RPA-projektet få øget budgettet, for at kunne udbyde denne service. Hvor pengene skal tages fra, er op til eventuelle ledere, og budgetforhandlinger. Alternativt kan man hente et fast beløb, fra de afdelinger som vil være med i projektet, for at kunne sprede omkostningerne ligeligt ud. Dette kan også være med til at opfordre afdelinger til at udnytte servicen, da de betaler for den alligevel. Yderligere er det de enkelte afdelinger som får en gevinst, typisk i form af timer frigivet, kroner sparet eller en kvalitetssikring der mindsker fejl og forglemmelser.

4. Team #

Navn	Note	Link
Gartner	En mere fyldestgørende liste, over hvad RPA-software der eksisterer	https://www.gartner.com/reviews/market/robotic-process-automation
Belbin	Oversigt over Meredith Belbins teori om team roller, kan bruges til rekruttering af medarbejdere til RPA	https://www.belbin.com/about/belbin-team-roles

Det kan være svært at finde ud af hvem, og hvilke kvalifikationer man skal bruge til en RPA-medarbejder, da det stadig er et meget nyt. Min egen holdning er, at man ikke kan køre det som et traditionelt projekt med almindelige roller. Typisk vil man have et lille team på 1-3 medarbejdere, de første par år man kører projektet. Typisk starter man på halvtid med RPA, indtil der kommer så mange processer, at man kan beskæftige sig med det på fuldtid. Af den grund er det vigtigt, at alle i teamet kan dække de forskellige roller til en vis grad. Hvis man eksempelvis deler op i en projektleder (projektledelse, find processer til RPA), og en udvikler (kodning af robotter, ansvar for softwaren), så bliver projektet sårbart hvis man får mandefald senere. Dermed sagt kan man godt have en primær rolle i teamet, men samtidigt kunne varetage nogle af de andre også, når behovet opstår. Forsætter man eksemplet fra tidligere, kunne det tænkes en projektleder har ansvar for, at finde og trykteste processer til eventuelt RPA-udvikling. Vedkommende bør også kunne lave simple processer i RPA-softwaren, eventuelt med hjælp i form af UserLibraries / skabeloner lavet og vedligeholdt af udvikleren. Samtidigt kan der også opstå tider, hvor der kommer mange anmodninger fra organisationen, hvor udvikleren også skal hjælpe med at finde og afdække processer.

Det vil være svært i fritekst at forklare, hvad man skal bruge i et RPA-team af roller og kompetencer. Hertil har jeg valgt at tage udgangspunkt i Meredith Belbins 9 roller i et team. Det skal nævnes, at en medarbejder godt kan have flere roller. Disse giver et meget godt indblik, hvad der er behov for, og kan eventuelt bruges af rekrutteringspersonale. Herunder er der skitseret hvad det handler om. Af hensyn til rollerne bliver byttet rundt / lavet om når de oversættes, tager dette udgangspunkt i det engelske titler.

Jeg tænker der er to primære roller i et RPA-team: udvikler og proces-dyrker (af mangel på ord). Da man ikke har brug for en traditionel projektleder, kan en af de to roller også have denne under sig. Yderligere beskæftiger RPA sig med low-code, så man behøver ikke direkte være programmør, for at kunne lave RPA-udvikling. Af samme årsag vil begge roller, have nogle ting tilfælles.

En udvikler har typisk de tekniske kompetencer, i form af IT-kendskab indenfor programmering (primært scripting sprog) og software. Der findes ikke i skrivende stund en uddannelse indenfor RPA, men udvikleren kan typisk findes i en IT-afdeling, hvor de har nogle af de nedenstående kompetencer i tabellen. Det kan være alt fra database-hajer til programmører. IT-supportelever opfylder også kravene, da de får mange af kompetencerne på skolebænken, og kan bruges i RPA-projektet også i denne rolle. Det er en klar fordel, hvis vedkommende kan lave såkaldte UserLibraries (kodestumper som kan genbruges) som proces-dyrkeren også let kan bruge. Et eksempel kan være nedenstående, hvor koden er lavet og vedligeholdt bagved af udvikleren. Her skal proces-dyrkeren blot indsætte en adresse, og får herefter et BFE (bestemt fast ejendom) nummer ud, de kan bruge videre i deres egen kode.

En proces-dyrker har kompetencer til at finde potentielle RPA-processer, og holde relationen ud til procesejerne. Det er typisk en medarbejder internt i virksomheden, som har et stort kendskab til arbejdsgange, procedurer, lovgivning og lignende der kan bidrages med til RPA-teamet. De kan også være systemejere eller superbrugere på noget af det software, som medarbejderne bruger i virksomheden.

Herunder er et overblik over de to roller, og hvad hver eventuelt kan byde ind med. Det skal tænkes som en ønskeliste, og kompetencer behøver ikke være på ekspert-niveau men til husbehov.

	Udvikler	Proces-dyrker	Fælles
Belbin type	Tænkning	Social	Handling
Kompetencer	Scripting Powershell Python VBScript API Database / SQL Regular Expressions	Bekendt med organisationen i forvejen Relevant lovgivning Arbejdsgange Gode relation til flere afdelinger	Grundforståelse for kodning Forståelse for flow / processer Superbruger/systemejer på software i organisationen Digitale blanketter
Noter	Findes i IT-afdelinger. IT-supportelever er en god ressource, da de opfylder mange af ovenstående krav. Kan også findes ude i byen.	Denne rolle er mere vigtig at finde i egen organisation, da den kræver forudgående kendskab om organisationen.*

* Med personlig erfaring fra flere organisationer, så tager det tid at skabe relationer, og kendskab til organisationen når man kommer udefra. Yderligere er det nemmere at sælge RPA som en service til medarbejdere, hvis man har relationerne og tilliden på plads. Medarbejdere i organisationen kan være mistroiske i starten, og tænke at det er en spare øvelse, hvor der kommer en fyringsrunde efterfølgende.