Tillvägagångssätt

“För att få en lyckad förändringsprocess så måste man göra den med arbetsgruppen – i nära samverkan. Annars är den dömd att misslyckas.” (G1)

Samtliga respondenter har beskrivit projektens övergripande tillvägagångssätt på snarlika sätt. Aktiviteterna som respondenterna nämnde var: inhämtat kunskap från andra kommuner som redan slutfört liknande projekt; gjort nyttokalkyler; definierat mål; fastställt politikers

förväntningar och förändringsmottagares inställning till organisationsförändring; uppskattat kostnader; förberett intressenter; skapat avtal med eventuella leverantörer; formulerat och startat upp projektgrupper, inklusive pilotgrupper; upprättat formella, styrande dokument som exempelvis förändringsplaner och processkartor.

Just processkartor nämndes i samtliga respondenters redogörelser över tillvägagångssätt, och lyftes upp som extra viktigt. Dessa beskrevs vara inventeringar över det händelseförlopp som projektet avser automatisera. En respondent beskriver arbetet med processkartor såhär:

“Det var ju det stora [förberedande] arbetet, för det är ju utifrån de processerna som man sen väljer ut vilka aktiviteter vi skulle kunna använda RPA:n till. ‘Vad är möjligt?’ Sen när vi väl satt aktiviteterna så får man välja vilken vi ska börja med, ‘Vad blir bäst?’ och ‘Vilket är viktigast?’ Så den aktiviteten vi har valt att börja med, det är en sån aktivitet som tar väldigt mycket tid för handläggarna att göra men väldigt lite tid för roboten.” (B1)

Majoriteten av respondenterna uppgav att de utfört processkartläggningen själva, medan andra har tagit hjälp av leverantören av automatiseringslösningen för detta. Här har det ofta funnits ett samarbete med de ansvariga IT-teknikerna, där verksamheten “översatt” processerna till “IT-termer”. Respondenterna har även uppgett att processkartorna legat till grund för automatiseringslösningens kravspecifikation.

“[Vi började med att] inventera verksamhetens process - ‘Hur ser flödet ut?’ - och sätta oss ner med IT- teknikerna för att översätta processerna till IT-termer, eller vad man ska säga, och sen göra kravspecifikationer till IT-enheten där vi beskriver exakt vad vi vill RPA:n ska göra. Att när bilden i verksamhetssystemet ser ut ‘såhär’ så förväntar vi oss att ‘då ska RPA:n agera såhär och såhär’, om RPA:n stöter på ‘det här problemet’, då förväntar vi oss att den ska agera på ‘det här viset’. Så vi har försökt förutse och skriva ner alla tänkbara scenarion och lösningar, och försökt verkligen beskriva på en väldigt detaljerad nivå vad för slags information som RPA:n ska hämta och varifrån.” (A1)

I samband med att dessa detaljerade beskrivningarna har arbetats fram har vissa respondenter även uppgett att jurister har involverats för att försäkra sig om att det blir juridiskt korrekt.

“När vi har gjort det här, alla bedömningar, och processkartor och så - så har vi också haft jurister med, utifrån GDPR - så att det är säkrat.” (E1)

5.4.1 Involvering av förändringsmottagare och löpande utvärdering

Samtliga respondenter har beskrivit hela arbetsprocessen som agil och iterativ, där justeringar hela tiden behöver göras för att projektet ska kunna fortskrida. Den kontinuerliga utvärdering som återkommande uppkommit i respondenternas utsago har dock framförallt belysts i samband med att respondenterna beskrev hur pilotgrupper nyttjats inom projekten:

“Sen har vi haft en grupp av handläggare som är lite piloter som får testa att RPA:n utför deras ärenden. Vi träffar dem regelbundet, och då får de återkoppla med att ‘här hade RPA:n gjort såhär i ett ärende, det ser konstigt ut’, eller ‘här behöver vi sätta den här regeln för att det ska fungera’, till exempel. Så vi utvärderar löpande och kommer på fler saker och ändrar i dem här kravspecifikationerna.” (A1)

“Jag brukar tänka på [arbetsprocessen] som en sån här ‘evighetsåtta’ - du vet en sån där liggande åtta. Där man har verksamheten på ena sidan och utvecklingsteamet i den andra bubblan - och där mitt emellan så sitter huvudprocessledare, kravanalytiker och arkitekt - som kan hjälpa till och liksom stämma av att ‘ja, men vi fattar verksamhetsbehoven’ och så går verksamhetsbehoven över till utvecklarna - som kommer tillbaka med ett lösningsförslag som verksamheten får titta på och förfina. Så fortsätter vi så i ett agilt, fint, evighetshetskretslopp. Så vi försöker ju att lägga systemutveckling och verksamhetsutveckling som två komponenter i samma evighetsåtta. (I1)

Deltagandet i dessa pilotgrupper har härstammat från förändringsmottagarnas individuella intresse, men man har också uppmanat framförallt de förändringsmottagare man ansett husera stor kunskap inom handläggningsförfarandet att ingå i grupperna. Pilotgrupperna har beskrivits kommunicera med de involverade IT-teknikerna regelbundet genom såväl formella som informella möten.

Respondenterna uppgav unisont att förändringsmottagarnas involvering var av yttersta vikt i projekten och att de ville involvera dem redan i samband med projektens initiala fas. Vissa respondenter nämnde att detta varit en lärdom de själva tagit med sig från tidigare förändringsprojekt, medan andra uppgav att detta var kunskap som förmedlats av kommuner som redan genomfört automatiseringsprojekt. Genom att involvera förändringsmottagarna redan från projektens början ämnade man ta till vara på den detaljkunskap de besitter kring arbetsprocesserna som projekten ska automatisera. Den tidiga involveringen av förändringsmottagarna var också ett sätt att skapa upplevelsen av gemensamt ägande över projektet; att hålla en god nivå av transparens mellan förändringsledare och förändringsmottagare; samt som en förberedelse inför stundande organisationsförändring, där lärdomar som successivt växer fram ska stötta förändringsmottagarna inför framtiden.

“Det vi hört av kommuner som vi pratat med är ju INVOLVERA MEDARBETARE SÅ MYCKET SOM DET BARA GÅR! Dels för att de ska känna att de faktiskt kan påverka det dem arbetar med, men också [för att] det blir ju liksom som en förberedelse. Att de redan nu är insatta, snarare än att de ska sätta sig in senare, när vi ska köra igång. [...] Och tanken nu - när e-tjänsten kommer på plats - är att vi samtidigt som vi arbetar med att implementera RPA:n ska ha en testperiod. Och att MED MEDARBETARNA testa hela tiden. [Dels för att ta del av allas input] och det här med att de ska känna sig delaktiga. Det blir ju som en implementering för dem också, så att de är förberedda på hur saker och ting ser ut och fungerar när det väl är dags.” (H1)

För att stärka känslan av gemensamt ägande involverades förändringsmottagarna också i det iterativa framtagandet av riktlinjerna som styrt kravspecifikationerna. Detta har skett i olika konstellationer, där vissa respondenter uppgav att alla förändringsmottagare suttit med vid dessa tillfällen och varit delaktiga, medan andra respondenter menar att de haft dedikerade representanter för förändringsmottagarna som varit mer involverade i projektet. Dessa representanter har i sin tur samtalat med resterande förändringsmottagare, för att på så vis involvera samtliga berörda intressenter i processen.

“I och med att det har varit sådana kontinuerliga avstämningar och [förändringsmottagarna] har varit så involverad så har de ju haft möjlighet att ställa sina frågor hela tiden. Och jag tror också att det har handlat om att det har varit vi som drivit processen tillsammans och inte vi från ledningen som driver det - som bara ploppar ner det till dem - utan att det har varit vår gemensamma process.” (B1)

“Hon som jobbar som förste socialsekreterare jobbar ju lite som talesperson för hela enheten. [...] Hon fick liksom gå tillbaka till sin arbetsgrupp när man behövde fundera kring olika vägval eller inhämta synpunkter. Då var det hon som gick tillbaka till verksamheten och samlade in det och tog det med sig.” (A1)