1. Kanban-tavle #

En af de ting man har mest behov for, er en kanban board af den ene eller anden slags. Dette gør dagligdagen nemmere, da dokumentation på igangværende og udførte opgaver er gemt. Herunder er et par eksempler på software, man kan bruge til dette formål. Der findes dog en uendelig mængde af muligheder.

Navn	Note	Link
Microsoft Teams Microsoft Planner	Begge er inkluderet i de fleste O365 licenser til virksomheder. Teamet kan indeholde en Planner, og yderligere kan man lave kanaler som robotterne kan skrive debugging ind i, såfremt man bruger Power Automate som sit RPA-software.	https://www.microsoft.com/da-dk/microsoft-365/business/task-management-software https://www.microsoft.com/da-dk/microsoft-teams/group-chat-software?ms.url=teamscom Intern Power Automate – Introduktion
Microsoft Devops Board	Et mere hardcore værktøj fra Microsoft, nok mest tiltænkt større teams/organisationer.	https://azure.microsoft.com/da-dk/products/devops/boards/
Monday	En online platform, hvor man kan skræddersy en løsning til projektstyring. De har et godt værktøj til at lave kanban tavler, hvor man kan tilpasse kolonner og trin i disse.	https://monday.com/work-management https://support.monday.com/hc/en-us/articles/115005317249-The-basics-of-a-board
Eksempel på dokumentation	Proces dokumentation eksempel til afsnit 4	Kodning – Modular Opbygning – RPA Help

Et eksempel fra Monday om hvordan man kan sætte dette op.

2. Gevinstrealisering #

Når robotter overtager arbejde, så er det typisk en gevinstrealisering. Dette kan være sparet tid, penge, øget kvalitet af udført arbejde (mindske fejl, meget svær at følge op på) og lignende. Typisk er det noget afdelingerne selv, ledere eller lignende gerne vil følge med i. Man kan lave en kolonne i sit kanban board, og skrive en cirka årlig besparelse i denne. Det vil kun være et estimat, og kan være svært at tracke over robottens levetid.

Hvis man vil have et mere præcist tal, som også er gemt når en robot eventuelt pensioneres, så kan man eksempelvis bruge en database. Denne kan indeholde tabeller som en robot logger data i, hver gang den er færdig med en kørsel. På den måde kan man se mere præcist, hvad der bliver sparet løbende efter robotten er sat i drift. Det giver også historiske data, som man kan sortere i. Derfor er det en god idé at sætte dette op fra starten, selvom man ikke tænker man skal bruge det.

Det skal nævnes, at man ikke kan bruge disse tal til at måle produktiviteten i RPA-teamet. Hvorimod man kan sige at et årsværk i timer er 1924 timer, så kan det ikke forventes, at hver enkelt udvikler kan levere dette indenfor det første år af projektet. Yderligere når man har været gang i en årrække, kan man have et år, hvor der ikke bliver udviklet meget nyt, men hvor tidligere robotter forsat tæller op i timerne. Det er heller ikke alle processer som har en direkte tidsbesparelse eller monetær værdi. Mindre robotter kan være en kvalitetssikring, der mindsker fejl af udført arbejde, som ellers ville have kostet tid/penge i den anden ende. Yderligere vil der gå tid med læring og øvelse, og det vil være en løbende proces igennem årene. Endvidere jo flere robotter man har, jo mere vedligehold vil man også have. Der kan også være tidspunkter, hvor man investere tid til at udvikle skabeloner (genbrugligt kode, API-opsætninger m.m.), hvor gevinsten først ses senere i forløbet. Hvis man har robotter kørende i årevis, tjener de deres udviklingstid tilbage, og vil give et naturligt overskud fremover. Af denne årsag burde man over en årrække kunne se, at man får flere årsværk ud af projektet end det man har investeret.

Tabel til logning af kørsler. Antal vil være hvad robotten udfører. Det kan være man måler besparelsen per delopgave der udføres, eksempelvis +1 per faktura der laves. I andre scenarier hvor det kan være svært at måle i delopgaver, men man ved cirka hvad total besparelsen i tid er per gang robotten kører, kan man notere antal som 1 altid per kørsel. Man kan også tage en gevinst for at robotten starter, og tjekker om den har noget at lave. Som eksempel kan det være at tjekke en indbakke for relevante mails, som skal behandles, ligesom en medarbejder ville sætte tid af til.

ID

Robotnavn

Dato

Antal

Tabel til besparelse per kørt antal for en robot. Heri vil man have en række per robot, som man så kan koble op med den anden tabel og regne total besparelsen sammen. Sekunder er den besparelse der er i sekunder per antal kørsler der findes (eksempelvis 300 sekunder per udfyldt faktura), og det samme med kroner hvis dette er relevant.

ID

Robotnavn

Fagområde

Sekunder

Kroner

Ajourføring

Kommentar

Procesejer

Udvikler

Hvis man vil udstille sin data (datavisualisering), kan man benytte nedenstående til formålet.

Navn	Note	Link
Power Pivot	Indbygget funktionalitet i Excel	https://www.rpahelp.org/docs/microsoft-excel/#7-toc-title
Microsoft Power BI		Power BI – Introduktion – RPA Help https://www.microsoft.com/en-us/power-platform/products/power-bi
Metabase		https://www.metabase.com/

3. Procesdokumentation #

Det er svært at sige hvad og hvor meget dokumentation, man reelt skal bruge til sine robotter. Der er ikke nogen faste krav, man skal dog have noget liggende omkring hver robot. Der er ikke behov for at tage billeder af hver enkelt klik, som man laver med musen eller lignende. Det er meget tidskrævende at lave sådan dokumentation, og samtidigt er det heller ikke retvisende for, hvordan robotten reelt udfører opgaven. Det kan være procesejeren skal igennem en brugergrænseflade for at udføre opgaven, hvor robotten kan gøre det via scripts med API-kald.

Herunder er hvad jeg selv benytter af afsnit, og en kort beskrivelse af hvad disse indeholder. Selve dokumentationen er linket på et kanban board, hvor der findes yderligere information om procesejeren, gevinstrealisering m.m..

1. Procesbeskrivelse – En kort overordnet beskrivelse af processen, som robotten skal udføre.
2. Beskrivelse af kode – En kort beskrivelse af hver subflow i koden, og hvad denne foretager sig.
3. Flow diagram – Et flow diagram som viser processen. Denne afspejler også relationen imellem nogle subflows i koden.
4. GDPR overvejelser – Et afsnit der kun findes, såfremt der har været GDPR-overvejelser med i processen.
5. Eventuelle bilag