1. Introduktion

Här beskrivs en metod för hur arkitekter kan utföra arbete och stötta projekt som handlar om Robotic Process Automation (RPA) eller automation. Metoden riktar sig till arkitekter och ersätter inte projektmetoder och förvaltningsmetoder utan ger arkitekten stöd genom råd om analysmetoder och beskrivningsmodeller för RPA.

Metoden är beskriven enligt fyra faser

• Identifiera potential

• Utarbeta målarkitektur

• Planering & införande

• Uppföljning & kvalitet

Arkitektens huvudsakliga arbetsinsats behövs i dom inledande faserna, men arkitekten bör delta under hela projektet.

Arbetet med att verksamhetsutveckla med stöd av RPA-teknik handlar till stora delar av att beskriva och analysera processer. Arkitektens ansvar är handlar om att beskriva och analysera processer. Metoden refererar till vanliga sätt att göra detta och ger specifik vägledning angående aspekter som bör beaktas i ett RPA-scenario.

Vad gäller teknisk lösning bör det påpekas att RPA är en av flera möjliga tekniker för att automatisera och optimera processer. Metoden nedan ger vägledning till arkitekten hur olika alternativ kan utvärderas för att besluta om den lämpligaste lösningen.

2. Identifiera potential

Denna fas av ett RPA-initiativ syftar till att hitta de huvudområden och processer som har potential för automatisering. Det kan liknas vid en förstudie och kan normalt sett genomföras på 2-4 veckor beroende på hur mycket underlag som redan finns tillgängligt. 

Analysen kan drivas av en eller två arkitekter i samverkan med ledare och nyckelpersoner ur organisationen, gärna på ett strukturerat sätt som exempelvis beredningsråd eller motsvarande. Arbetet sker på strategisk nivå och blir därför inte särskilt detaljerat då syftet är att identifiera potentiella processer eller processområden som ska analyseras vidare.

Analysen omfattar tre huvudområden som ska ge svar på följande frågor: 

• Vilka är intressenter och vilka intressen har dom? (Intressentanalys)

• Vilka förmågor har vi behov av att förbättra? (Förmågeanalys)

• Vilka processer eller processområden ska analyseras vidare? (Processanalys)

2.1 Intressentanalys

Intressentanalys är en metod för att kartlägga vem som kommer bli berörd eller har ett behov av förändring, i detta fall en ökad grad av automatisering av processer. Intressentanalys är vanligt förekommande och ingår bl.a. i Metod för Nyttorealisering.

Open

I intressentanlaysen identifierar man de viktigaste intressenterna och deras intressen. Intressenterna består oftast av organisationer eller roller såsom kund, medarbetare, leverantör etc. Analyser görs vanligtvis genom intervjuer där arkitekten och potentiella intressenter (exempelvis verksamhetsansvariga) diskuterar vad dessa vill ha ut av ett RPA/automatiseringsinitativ. Ofta är detta kopplat till de mål eller uppdrag som intressenterna har.

Resultatet av intressentanalysen används främst för att få en gemensam förståelse för vem som behöver vara med i ett kommande projekt/initiativ, antingen i styrningen eller som utförare, och vilka mål projektet ska ha. Intressentanalysen används ofta som input till framtagande av projektdirektiv. 

Intressentanalysen infogas även normalt sett i början av en arkitekturbeskrivning och det är viktigt att arkitekturbeskrivningen kan svara på hur intressenternas intressen adresseras i arkitekturen. Det enklaste sättet att göra detta är i form av en läsanvisning som berättar vilka delar (vyer) av arkitekturen som är relevanta för respektive intressent. Det är också möjligt att dokumentera detta i modellform genom att koppla intressen till arkitekturvyer. 

Intressen kan grovt kategoriseras i två områden:

• Intressen som handlar om nytta och effekt av lösningen.
  Nyttor är effekter som uppnås vid genomförande av ett RPA-projekt, dvs både kortsiktiga nyttor och effekter på längre sikt. Denna typ av intressen kan med fördel omvandlas till projektmål och har vanligtvis sin grund i verksamhetsmål eller strategier. Intressenter som uttrycker denna typ av intressen bör ingå i styrgrupp eller motsvarande.

• Intressen som handlar om behov relaterat till lösningen.
  Denna typ av intressen handlar om hur arkitekturen ska utformas och beskrivas. Det kan exempelvis omfatta hur lösningen önskas användas, fungera eller förvaltas. Kom ihåg att dessa ofta är uttryckta på en övergripande nivå och därmed ofta behöver brytas ner till konkreta krav i arkitekturarbetet. Intressenter som har denna typ av intressen är ofta deltagare i utvecklingsprojektet eller referensgrupp, men kan naturligtvis också ingå i styrgrupp.

Nedan är några exempel på intressenter och deras intressen i ett RPA-initiativ

2.2 Strategianalys

Syftet med en strategianalys är att hitta områden i verksamheten som har störst behov av förbättring och där automation kan vara en möjliggörare för denna förbättring. Här rekommenderas arkitekten att jobba med två huvudsakliga koncept: Förmåga och Mål som finns beskrivna i Metamodell Strategi.

Open

Förmågor är ett bra sätt att diskutera med beslutsfattare och viktiga intressenter utan att gå ner på hur verksamheten är organiserad. Ett automationsprojekt sträcker sig ofta över flera olika organisationer och det är därför viktigt att få en förankring av förbättringsbehov och potential utan att peka på specifika organisationsenheter som kan vilja optimera endast sin verksamhet.

En tillämpbar metod är Metod för förmågebaserad planering som beskriver hur förmågor utformas och hur förmågekartor av nuläge och framtid kan beskrivas. Det viktigaste i denna fas av projektet är att beskriva förmågeutvecklingen, dvs. vilka förmågor som har störst avstånd mellan befintlig mognad och önskad mognad. 

En verksamhet har ofta många olika förmågor vilket kan göra det svårt att förstå vilka som kan ha störst nytta av automatisering. Följande kriterier rekommenderas i urvalsprocessen:

• Förmågor som är prioriterade av ledningen eftersom det finns större chans att få finansiering

• Förmågor som finns i många olika typer av verksamheter eller företag eftersom dom ofta är standardiserade, exvis stödjande förmågor inom områdena ekonomihantering, personalhantering, inköp, marknadsföring etc.

• Förmågor som inte ändras ofta eftersom en automation då kan leva länge

• Förmågor som har många avnämare/kunder eftersom det kan finnas skalbarhetseffekter av automationen

• Förmågor som kostar mycket eftersom det kan finnas stora besparingspotentialer 

Kom dock ihåg att i denna fas är det bättre att välja för många förmågor än för få eftersom det behövs mer analys innan man kan besluta om att automatisera och därmed kommer en del att försvinna som kandidater.

Om inga befintliga förmågekartor finns i verksamheten kan man utgå från dom som finns beskrivna i arkitekturbibiloteket. Fördelen med detta är förutom att det går fortare också att det finns en möjlighet att enklare hitta andra som gjort automationsprojekt inom samma förmågeområden och därmed kunna ta del av deras erfarenheter.

Det är också mycket lämpligt att leta efter verksamhetsmål som kan inrikta analysen. När det gäller RPA ska man leta efter mål som handlar om besparingar, optimeringar och ökad kapacitet. Mål som handlar om utveckling av nya tjänster och verksamheter är inte av lika stort intresse då man i denna utveckling oftast försöker automatisera så mycket som möjligt från början i de lösningar som implementeras. 

Finns inga dokumenterade mål kan man utgå från de behov som identifierades i intressentanalysen och bryta ner dessa till mål. Beakta då den vägledning som finns i Metamodell Strategi. Det finns också vägledning i metod för Nyttorealisering.

2.3 Processidentifiering

I fasen Identifiera potential är det också viktigt att komma fram till en lista med processer som ska analyseras vidare i nästa fas. 

I bästa fall finns en koppling mellan de förmågor som identifierats och processer enligt de relationer som finns beskrivna i Metamodell Strategi och Metamodell Verksamhet.

Det är inte ovanligt att organisationer saknar förmågekartor och inte arbetar med förmågebaserad planering. I dessa fall finns dock allt som oftast en beskrivning av organisationsstruktur, funktioner och de processer som dessa stödjer genom sin medverkan. Processidentifieringen kan då ske genom att beskriva följande element. 

Tänk på att processer ofta stöds av flera verksamhetsfunktioner inom olika organisationsenheter/ verksamhetsområden.

För att utvärdera processers automationspotential kan man använda samma typ av kriterier som för förmågorna. Dessutom är det av största vikt att varje process har en tydlig processägare och mätetal. Utan dessa kommer det vara svårt att utreda om det finns automationspotential och visa på den effekt som kan uppnås genom automationen.

2.4 Sammanfattning av fasen Identifiera potential

I denna fas har vi beskrivit hur man tar sig från intressenter till identifierade processer med automationspotential, men ofta kommer direkta förslag på processer som man vill applicera RPA på. Arkitekter kan då bidra med värde genom att värdera och dokumentera automationspotentialen för processen samt analysera och beskriva hur processen relaterar till övergripande mål och strategi.

De typer av arkitekturelement som använts under fasen visas i bilden nedan.

3. Utarbeta och validera målarkitektur

När man väl har en uppfattning om vilka förmågeområden och processer som är kandidater för fortsatt analys börjar det mest intensiva arbetet för arkitekter att tillsammans med verksamhetsutvecklare och användare ta fram en målarkitektur. Denna syftar till att underbygga beslut om vad som ska automatiseras och hur automationen ska göras vilket är viktigt för ett implementationsprojekt att veta.

Metoden beskriven nedan har två huvudområden - verksamhets och processanalys samt val av teknisk lösning. De två områdena är beskrivna separat för att ge tydlighet i metodbeskrivningen, men oftast görs både verksamhetsanalysen och den tekniska analysen samtidigt och i ett flertal iterationer. Det kan också hända att ett RPA-projekt redan är i full gång och har påbörjat implementation utan att ha arbetat enligt den beskrivna metoden. Använd då tillämpbara steg och verktyg ur metoden för att säkerställa kvalitet i projektet, exempelvis genom att i efterhand dokumentera nyttan som automationen åstadkommer.

3.1 Verksamhets och processanalys

Huvudsyftet med en verksamhets och processanalys för ett RPA-projekt är att beskriva den process och processteg som ska automatiseras och nyttan med detta. Erfarenheter från RPA projekt visar dock att det inte endast är själva automatiseringen som ger positiva effekter utan också att man ser över och effektiviserar själva processen. Därför rekommenderas det att jobba med både nulägesbeskrivningar och nylägesbeskrivningar (målarkitektur) av processer.

Fem olika aktiviteter utförs i analysen:

1. Övergripande processbeskrivning av nuläget

2. Värdering av automationspotentialen för nuvarande processer

3. Övergripande beskrivning av den framtida processen (förändring)

4. Beskrivning av nyttan och effekter av den framtida processen

5. Detaljerad processbeskrivning

Mellan dessa aktiviteter ligger ofta beslutspunkter, framförallt mellan det att den övergripande målarkitekturen och nyttan är beskriven och den mer detaljerade processbeskrivningen påbörjas. Beslutspunkterna kan dock variera beroende på projektmodell och redan tagna beslut i ledning etc.

Övergripande processbeskrivning av nuläget

En beskrivning av nuvarande process är nödvändig dels för att kunna identifiera vilka steg i processen som kan automatiseras men även för att kunna identifiera förbättringspotential i själva processen. Processer beskrivs ofta i två olika former;

1. Processnedbrytning där processer bryts ner i nivåer från processområde till processgrupp och vidare till processer och underprocesser/aktiviteter.

2. Processflödesbeskrivning där olika steg i processen dokumenteras och interaktion mellan stegen beskrivs.

I ett RPA-initiativ är det främst processflödesbeskrivningen som är relevant att ta fram och i denna beskriva:

1. Det som triggar igång processen (Se elementtypen Händelse)

2. Vem som utför aktiviteter i processen (Se elementtyperna Aktör och Roll)

3. Respektive steg i processen (Se elementtypen Process)

4. Det som utbyts mellan stegen i processen (Se elementtyperna Verksamhetsobjekt och Informationsobjekt)

5. De IT-resurser som stödjer processen (Se elementtyperna Applikation, Applikationstjänst och Informationslager) 

De elementtyper som används i beskrivningen och deras relationer visas i bilden nedan.

Ett vanligt sätt att uttrycka processflödesbeskrivningar är enligt standarden Business Process Modelling Notation (BPMN) där diagramtypen, översatt från engelska, kallas kollaborationsdiagram. Elementtyperna som nämns ovan används på följande sätt i processflödesbeskrivningen:

• Den händelse som initierar processen läggs in i diagrammet. I ett RPA-initativ är det händelser som kan fångas av IT-system som är relevanta att beskriva, exempelvis att en ansökan skickas in via email eller liknande. Händelser som inte sker i IT-system är inte möjliga för robotar att fånga upp. 

• Aktörer eller Roller visas som "banor" (horisontella eller vertikala) i diagrammet och därefter läggs de olika processerna/aktiviteterna som respektive aktör/roll utför i banorna. På detta sätt kan man utläsa vem som gör vad.

• Processtegen kopplas ihop med hjälp av flödesrelationer vilka kan gå mellan aktiviteter i en bana eller mellan aktiviteter i olika banor. Viktigast här är att fånga sådana som går mellan banor eftersom det ofta är där som den största automationspotentialen för RPA finns.

• Verksamhetsobjekt som produceras eller används av processtegen infogas. Dessa kan detaljeras till informationsobjekt om så önskas och därmed är det också möjligt att visa hur flera objekt hänger ihop i en informationsmodell (separat diagram/modelltyp). Se metoden för https://inera.atlassian.net/wiki/spaces/AIA/pages/3110205 för mer detaljer om beskrivning av begrepp och informationsmodeller.

Man brukar säga att stegen ovan tillhör verksamhetsarkitektur eller verksamhetsmodell. Utöver detta så är det i ett RPA-scenario också viktigt att beskriva hur processerna stöds av IT-system för att kunna analysera befintlig automationsgrad och eventuella automationsmöjligheter. Därför kompletteras processflödesbeskrivningen med följande:

• Applikationstjänster kopplas till de processer eller processteg som tjänsterna stödjer. Värt att tänka på är att en applikationstjänst kan stödja många olika processer/aktiviteter och ska då kopplas till dessa. En applikationstjänst som kopplas till flera steg i en process i en nulägesbeskrivning tyder ofta på att det finns en automation på plats eller att det är möjligt att anpassa tjänsten för att åstadkomma en automation. En process där de olika stegen stöds av olika applikationstjänster har ofta en större automationspotential för RPA då det i vanliga fall är flera tekniska system inblandade.

• Informationslager kan också infogas i diagrammet för att indikera var informationsobjekten lagras. Samma princip gäller här som för tjänsterna: om flera informationsobjekt finns i samma lager så är en automation förmodligen redan på plats eller kan åstadkommas med en förändring i applikationen som hanterar informationslagret. 

Tänk på att inte beskriva processerna för detaljerat i detta skede då det kan resultera i mer arbete än nödvändigt för att fatta beslut om fortsatt arbete eller inte. Det viktiga är att hitta interaktioner mellan aktörer (användargrupper, avdelningar etc.), speciellt sådana som inte stöds på ett bra sätt av dagens IT-lösningar (applikationstjänster).

Ett exempel på processflödesbeskrivning visas nedan. Notera att diagrammet inte följer BPMN notation utan syftar till att beskriva vilka elementtyper som används och exemplifiera dessa. 

Värdering av automationspotentialen för nuvarande processer

Ett viktigt steg i analysen är att bedöma hur stor potential en process har i termer av automation. Här kan man titta både på det rent verksamhetsmässiga perspektivet, men även det tekniska.  Ett enkelt sätt att värdera potentialen är att fylla i nedanstående matris.

Skalan som används för att gradera möjligheterna kan variera, men en Låg/Medel/Hög-skala är att föredra eftersom den ger en indikation samtidigt som det inte blir för komplext att definiera nivåer.

Matrisen används som ett stöd till utvärderingen, men det är inte möjligt att använda den för att matematiskt svara på om vidare analys ska göras eller inte. Se den som ett verktyg att diskutera runt för att belysa olika viktiga aspekter som komplement till processbeskrivningen.

Övergripande beskrivning av den framtida processen (förändring)

Erfarenheter från RPA-projekt visar att en ren automation av befintlig process ger begränsad nytta. Den stora potentialen ligger i att samtidigt genomföra processoptimering. I detta har arkitekten en viktig roll att vägleda verksamheten i processutveckling och dokumentation av det önskade läget. Här kan exempelvis LEAN vara en bra metod då den är inriktad på att minimera slöseriet av resurser genom rationalisering och effektivisering. 

Det framtida läget beskrivs på samma sätt som nuläget, med processflödesdiagram. I exemplet nedan visas hur ett processteg lagts till och en önskan om automation av en manuell överföring av information mellan två processteg.

Beskrivning av den förväntade nyttan och effekter av den framtida processen

Samtidigt som den nya processen beskrivs är det bra att identifiera de nyttor som förväntas uppstå. Nytta är en positiv mätbar effekt av en förändring. I arkitekturtermer används elementen Indikator och Mål för att definiera vilka ekonomiska eller kvalitativa effekter nyttan skapar. Aktör används för att beskriva vem eller vilka som får nyttan när den väl är realiserad genom Milstolpar som ingår i förändringsprojekt.

I många fall kan nyttor vara samma eller relaterade till intressen som uttryckts av de olika intressenterna. Att arbeta med nyttor kan därmed vara ett bra tillfälle att återknyta till intressenterna och detaljera deras förväntningar och kvantifiera nyttorna med indikatorer. Processägaren är en av de viktigaste intressenterna då denna definierar KPI:er för processen som ska optimeras. Exempel på vanliga indikatorer är

• Kundnytta/nöjdhet

• Antal sparade FTE - nyckel-KPI för ROI

• Hastighetsökning i processutförande

• Kapacitetsökning i processutförande

• Minskad risk i verksamheten genom färre manuella aktiviteter

Notera att det redan här kan vara relevant att definiera milstolpar som kan användas i kommande projektplanering, även om denna inte är startad.

Ytterligare detaljer finns i metodbeskrivningen för Nyttorealisering.

Detaljerad processbeskrivning

För en lyckad implementation av en RPA-robot behöver processen som roboten ska utföra beskrivas på en betydligt mer detaljerad nivå än vad som visats ovan. I princip behöver varje musklick och textinmatning som roboten ska utföra dokumenteras vilket de olika leverantörerna av RPA-system och deras partners normalt sett har mallar för.

Dessa mallar omfattar ofta en steg-för steg beskrivning av användarhandgrepp och skärmklipp som används av de som ska implementera robot-systemen. Även felfall och alternativa flöden bör beaktas i denna beskrivning.

Denna nivå av dokumentation ingår normalt sett inte i arkitekturbeskrivning, men arkitekter bör granska och godkänna dessa för att säkerställa att roboten inte divergerar från den tänkta processen.

Det är också viktigt att inte börja med denna detaljerade beskrivning för tidigt då det endast är den robotiserade delen av processen som beskrivs på denna nivå. Valet av teknisk lösning måste alltså vara gjort. 

3.2 Val av teknisk lösning

RPA innebär i grunden som bekant att en mjukvarurobot automatiserar manuella handgrepp som annars genomförs av en människa. Automation går dock att uppnå på fler sätt, kanske framförallt genom klassiska integrationer, och arkitekten bör alltid göra en teknisk bedömning av övriga tekniker innan ett RPA-införande beslutas. För att göra en så bra bedömning som möjligt är det lämpligt att följande arkitektkompetenser involveras i arbetet:

Fotnot: Ovanstående tabell nämner fler roller än de som arkitekturgemenskapen beskriver i Roller. Dessa specialiserade roller förekommer kanske huvudsakligen i större organisationer. I mindre organisationer kan det motsatta förhållandet naturligtvis även förekomma.

3.2.1 Att jämföra RPA och övriga automationslösningar

RPA ses ofta som en snabb och kostnadseffektiv lösning att uppnå automation. Beroende på vilken sorts process, ingående system samt organisationens övriga IT-kapabilitet kan det dock finnas anledningar att överväga fler alternativ.

Nedanstående tabell försöker belysa styrkor och svagheter hos RPA kontra andra metoder.

Styrkorna hos RPA ligger bland annat i

• Snabbt införande

• Låg startkostnad

• Lägre IT-expertkunskapskrav 

• Inga krav på integrations/automationsmotorer

• Inga krav på förändringar i befintliga system

• Hanterar legacysystem (äldre produkter)

Ett snabbt införande till låg startkostnad som dessutom ger möjlighet för ett äldre legacysystem att agera mer autonomt är trumfkorten. Verksamheten kan även ta ett större ansvar för utvecklingen av automationen än vad som normalt sker vid integrationsprojekt då de på ett enkelt sätt ser och styr agerandet hos roboten.

Några nackdelar är

• Svårighet att hantera komplexa scenarion (mappning/transformering)

• Känslighet för förändringar/störningar i system (UI och klientmiljöer)

• Risk att system och processer inte längre förbättras och utvecklas

Om en process involverar att transformera information (via mappning, översättning eller informationsutökning) blir det ofta komplext för en robot, något som integrationsmotorer normalt klarar relativt enkelt.

En robot är väldigt känslig för förändringar i såväl applikationer som operativsystem. Robotmiljöer kräver därför strikt överseende rörande versionsuppgraderingar. Mer om detta senare.

Vidare finns det även en inbyggd risk i att utveckling av nya arbetssätt och funktioner glöms bort när robotiserade processer fortsätter att jobba på samma manuella sätt som människor gjort tidigare.

3.2.2 Övriga tekniska aspekter

Även om ett införande av RPA kan ses som en snabb och kostnadseffektiv lösning så tillkommer även nya tekniska utmaningar för IT-avdelningen. 

Robotens klientmiljö

Roboten behöver en stabil miljö att arbeta i. Med detta menas att även små förändringar i utseende eller beteende hos såväl applikationer som operativsystem kan medföra att robotens arbete stannar upp eller i värsta fall utförs felaktigt.

En stabil klientmiljö innebär:

• Kontrollerade OS-uppdateringar

• Kontrollerade programuppdateringar

• Säkerställd upptid, exempelvis via maskinvirtualisering

• Nedlåsning av onödig funktionalitet (group policies)

En separat förvaltningsmodell för robotklienter kan därför rekommenderas. Där bör ovanstående åtgärder finnas definierade och väl dokumenterade.

Robotens säkerhet

Ytterligare ett sätt att stärka stabiliteten hos roboten är att styra dess behörigheter väldigt strikt. En princip som brukar nämnas är POLP, eller “Principle Of Least Privilege”. Roboten ska aldrig ges mer behörighet än vad som behövs för att den ska kunna agera i de valda automationsprocesserna. Detta gäller såväl i operativsystem som i applikationer och system.

• Behöver roboten kunna starta en webbläsare? Eller ens ha tillgång till internet?

• Vilka interna nätverksresurser behöver roboten ha åtkomst till? Plocka bort onödiga enhetsmappningar.

• Se över vilka möjligheter som finns internt i varje applikation rörande behörighet. Kanske behöver roboten inte komma åt allt som en vanlig användare anser vara nödvändigt

• Lokalt i operativsystemet ska roboten inte kunna förstöra eller förändra förutsättningarna för dess operationer.

När en robot arbetar reaktivt blir det även nödvändigt att ha kontroll över de händelser/event som kan trigga automationen. Exempelvis om roboten reagerar på mailmeddelande så kan regler rörande godkända avsändare eller andra rimlighetskontroller (sanity checks) bli nödvändiga. Likaså kan numerära gränsvärden behöva definieras för att upptäcka eventuella oegentligheter i robotens agerande. Interaktionsdiagram kan vara en hjälp för att beskriva dessa sorters flöden.

Slutligen behöver roboten även följa de regler som gäller för uppdelning av ansvarsområden (Separation of Duties), vilket exempelvis innebär att samma individ inte ska kunna agera både sak- och beställarattestant. Även om roboten programmeras korrekt i sådana sammanhang så innebär det även att den som har tillgång till robotens inloggningsuppgifter teoretiskt kan agera illvilligt.

Spårbarhet

Att kunna redogöra för robotens arbete är viktigt av såväl verksamhetsmässiga som tekniska skäl. En vanlig komponent hos många RPA-produkter är därför en central koordinationsmekanism (orchestrator) som ser till att styra arbetet och samla in resultat och eventuella loggar från från robotiserade processer. I denna funktion bör även larm samlas upp och distribueras till avsedda mottagare inom organisationen.

Traditionella integrationsmotorer har ofta inbyggd funktionalitet för att spåra meddelanden och innehåll, men hos RPA-system kan detta bli mer komplext. Beroende på behoven kan en lösning vara att bygga egendefinierad loggning som ett separat steg i den automatiserade processen.

IT-säkerhetspolicyn kan behöva uppdateras för att ta hänsyn till robotens agerande och loggningen bör kunna visa spår av vilka operationer som har utförts.

Utveckling

Programkoden som styr robotens agerande bör behandlas med samma försiktighetsåtgärder som övrig egenutvecklad programkod. Eftersom den troligtvis innehåller en mängd känsliga uppgifter behöver behörighetsstyrningen vara tydlig och åtkomsten begränsad.

Vid utvecklingen kommer programmeraren behöva åtkomst till de berörda systemen, men redan i detta skede är det viktigt att tänka på de punkter som nämndes under rubriken “säkerhet”. Organisationens programutvecklingsstrategi bör således även inkludera området RPA avseende releaser och versionshantering.

4. Planering och införande

I grunden är det inte mycket som särskiljer ett RPA-införande från ett vanligt projekt. Arkitekter kan här bidra till planeringen genom användandet av de arkitekturelement som finns beskrivna i Metamodell Realisering. Vi har ovan nämnt att milstolpar är de tidpunkter då nytta realiseras. Dessa milstolpar ägs av projekt som modelleras med elementtypen Arbetspaket och vid milstolpar frisläpps systemelement, exempelvis en RPA-applikation. På så sätt kan arkitekter tillsammans med projektledare beskriva när i tiden olika saker ska vara klara.

En modelltyp som kan vara applicerbar i detta sammanhang är Förmågeutvecklingsplan. Denna beskriver hur förmågor utvecklas över tiden och hur projekt bidrar till dessa förmågor.

En annan sak som kan vara relevant för ett RPA-projekt är att definiera förvaltningsmodell och organisation runt detta. RPA-system är i dagsläget ofta något nytt i många organisationer och det finns ingen existerande förvaltning för dessa system. Förvaltningsmodeller kan naturligtvis skilja sig åt mellan olika organisationer så det är svårt att rekommendera en generisk modell som fungerar för alla. Däremot så är det viktigt att påpeka att i RPA-sammanhang är det viktigt att definiera relationen mellan IT och verksamheten då RPA-systemen är IT-system som vilka andra som helst och därmed förvaltas och driftas av IT, men vad roboten gör och hur den konfigureras eventuellt kan hanteras av olika delar av organisationen, exempelvis i olika kommunförvaltningar.

5. Uppföljning och kvalitet

Även i denna fas är det inte mycket som är unikt för RPA-införande. Vi kan dock påpeka vikten av tydligt definierade nyttor och indikatorer som beskrivs i kapitel 3. 

Det kan även vara relevant att få in indikatorer runt processerna i balanserade styrkort om sådana används i organisationen. Se metoden Balanserat styrkort och Strategikartor för mer detaljer runt detta.