Automatisering

Det er op til den enkelte kunde, hvilket automatiseringsværktøj man vælger til automatisering. Det er dog ikke alle processer eller opgaver, hvor RPA er det bedste valg værktøj til opgaven. Statens It bruger UiPath som RPA-software. 

I øjeblikekt understøtter Robot it-arbejdsplads (RIA) kun UiPath, hvor flere kunder kan have hver deres tenant (del af styringsserveren, Orchestrator). Statens It følger løbende RPA-markedet og tester forskellige typer af software.

Vi vil anbefale, at du starter med en fysisk computer og gratis prøvelicens fra fx UiPath for at lære mere om krav til processer og automatisering via software robotter. Det kræver derefter modenhed i RPA-kode og organiseringen omkring, før man idriftsætter unattended robotter og Orchestrator.

Kunden forestår selv indkøb af licenser til robot-software efter rådgivning fra deres kundeprojektleder i Statens It.

I UiPath hedder de licenser, som I skal bruge, ’Studio’ til udviklere og ’run-time’ eller ’Unattended’ for en robot-licens til en klient. Disse licenser kan købes via statens indkøbsaftaler eller fx igennem et konsulentfirma.

Eneste undtagelse er UiPath Orchestrator-licensen, som Statens It har indkøbt til den fælles Orchestrator-server. Her kan der udstedes en ’tenant’, som er kundens egen Orchestrator, som deler licens med andre Orchestrator-kunder men ellers er kundens egen, hvor Statens It ikke har adgang.

Statens It opdaterer løbende UiPath Orchestrator samt UiPath Studio og Assistant.

Det er planen at holde platformen løbende opdateret på seneste 'stable' release. Hvis du mangler en software-pakke, så kontakt vores Orchestrator-administrator.

Vi vil altså IKKE anbefale at du bare henter nyeste Studio og Assistant fra UiPath og begynder at udvikle. UiPath siger at deres produkter er bagudkombatible, men vi anbefaler at I bruger samme version.

Argumentet for at benytte en særlig robotbruger til automatisering er, at det på den måde er tydeligt for både fagsystemejer og kunde, ’hvem’ der har udført et arbejde eller en proces. Om det er udført af en ’menneske-brugere’ eller en ’robot-bruger’.

Adgangskoden til en J-bruger skal være mere kompliceret end hos en almindelig bruger, fordi den tit deles mellem fx flere udviklere. Det er kun tilladt at bruge J-brugeren på Statens It’s robotinfrastruktur.

Statens it-arbejdsplads (SIA) er en fysisk bærbar computer, som bruges af alle Statens It’s kunder. En Robot it-arbejdsplads (RIA) er en virtuel Windows-computer, der udelukkende bruges til kørsel af robot-software.

Ofte er en SIA-computer et godt sted at starte sin robotudvikling, da man ikke behøver at vide, hvilke fagsystemer og rettigheder man skal have adgang til, inden man går i gang. Det er også muligt at bestille administratorrettigheder på en SIA, men det er det ikke på en RIA. Når man har udviklet og testet sin robotkode med succes, er det nemt at udgive denne kode til fx en Orchestrator som en UiPath-pakke.

Der er væsentlige forskelle på en almindelig SIA-computer og en virtuel RIA-arbejdsplads. En almindelig SIA-computer rammes (afhængigt af kunden) af flere hundrede såkaldte gruppepolitikker, der udstikker regler og politikker på en computer. Mange af de regler der rammer en menneskebruger kan forvirre en robot, og derfor er RIA-arbejdspladsen lavet med så få rettigheder og regler som muligt. Det betyder færre pop-up-vinduer, som kan få robotten til at gå i stå. Det betyder også, at du skal tildele eventuelle rettigheder og adgange manuelt, som en normal bruger får adgang til via gruppepolitikker på en SIA-computer. Firewall-regler kopieres fra kundens fysiske netværk til det virtuelle, men der kan være ekstra adgange eller porte, der skal åbnes på robottens arbejdsplads.

Ligesom på fysiske SIA-maskiner, vil eventuelle revisioner altid slå ned på unødvendige administrative rettigheder. Det betyder, at det ikke er muligt at opnå administrative/eleverede rettigheder på en RIA-desktop. Den mangel kan man typisk programmere sig udenom, og Statens It’s deler altid gerne viden om dette.

Statens It har ikke ansvar for kundens egenudviklede robotter, og vi kan ikke overvåge, om robotterne gør deres arbejde, eller om de gør noget forkert. Se servicebeskrivelsen for Robot it-arbejdsplads for en udførlig gennemgang af ansvarsfordelingen via en såkaldt RACI-model.

Vores Servicedesk tager, ligesom på andre fællesservices, imod incidents eller nedbrud på infrastrukturen ud fra devisen: ”det virkede i går”. Servicedesken kan visitere et incident til det relevante team i Statens It.

Er der tale om nyudvikling (=”det har ikke virket endnu”), så vil robotudvikling foregå i et kundeprojekt med deltagelse af en robot-projektleder fra Statens It’s kundeområde, som kan formidle opgaver til relevante ressourcer i vores organisation. Det er bl.a. vigtigt at afgøre, om opgaven handler om platformen (det virtuelle miljø) eller generelle Windows- eller UiPath-udfordringer.

Afhængigt af hvad dine robotter udfører, bør du lave en risikovurdering eller en konsekvensanalyse af, hvad dine robotter kan påvirke. Det er vigtigt at tænke på, at hvis jeres robotter gør noget galt, kan de komme til at gøre det galt mange tusinde gange.

Læs evt. Datatilsynets vejledning til konsekvensanalyser.

Gå til Datatilsynets vejledning til konsekvensanalyse