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.