Detta kapitel presenterar studiens resultat och analys. Kapitlet innehåller bakgrund om verksamheten, avgränsning av process, beskrivning av processen som önskas transformeras till RPA och insamlad empiri från datainsamlingstillfällen. Avsnittet består av sammanfattade stycken med citat av den insamlade empiri som har genererats under studiens workshops, intervju och observation. Utifrån den empiri som presenteras har en tematisk analys utförts. Empirin ställs mot tidigare presenterade teorier genom teoridriven analys. För att generera nya insikter har datadriven analys utförts.
4.1 Bakgrund om verksamheten
Processen för denna studie är handläggning av personuppgiftsincident som i denna studie förkortas med PUI. En anmälan om PUI görs i syfte av att en organisation anser att en eller flera personers uppgifter hamnat hos obehörig part, förstörts, gått förlorade eller ändrats. Dessa anmälningar rapporteras till den offentliga verksamheten. PUI-anmälningar kan utföras genom att skicka in dem via e-tjänst, e-post, post, eller upprättas vid besök av ingivare. Dessa incidenter diarieförs i verksamhetens ärendehanteringssystem som ärenden. I detta system kommer ärendena befinna sig hela tiden. I samband med att GDPR trädde i kraft har organisationer en skyldighet att anmäla personuppgiftsincidenter till den offentliga verksamheten.
4.2 Avgränsning av process
Verksamheten hade identifierat två processer som ansågs lämpliga för RPA. Den ena processen var PUI-processen och den andra var processen för att maska ärenden. Vid tillfället för denna studie maskas ärenden vid utlämning av ärenden. När ett ärende har förfrågats om att begäras ut skriver en handläggare ut ärendet och maskar sekretessbelagda fält för hand. Därefter kopieras ärendet och kopian postas till den som begärt ut ärendet. Vid val av process för att utveckla RPA valdes processen för maskning av ärenden bort. Av den anledningen att kunna göra det möjligt att digitalisera och automatisera denna process måste en mjukvara som kan säkerställa att det inte går att avmaska sekretessbelagda fält nyttjas.
PUI-processen blev den slutgiltiga processen för denna studie. Vid analys av processen framkom det att diarienummer inte skickas ut vid utlämning av ärende. Detta innebär att när en komplettering till ett ärende skickas in kan en registraturen inte koppla ihop en
20
komplettering till rätt diarienummer genom att ange diarienummer. Registraturen kan då söka på andra variabler som kommer med komplettering för att identifiera rätt ärende. På grund av detta avgränsades RPA-implementation till att automatisera handläggningsprocessen.
4.3 Processbeskrivning
Processen börjar med att ingivaren skickar in en incident via den nya e-tjänsten, post, e-post eller besök. Registraturen tar emot alla nya incidenter och diarieför dem i ärendehanteringssystemet. Handläggaren går in i diariet och undersöker om nya incidenter har tillkommit. Vid handläggning av incidenter ska handläggaren bedöma incidentens allvarlighetsgrad och ta beslut om hur denna incident ska hanteras. Om handläggaren anser att incidenten är komplett, dvs att ingen komplettering krävs för att avsluta ärendet, är ärendet redo för att avslutas och sammanställer då ett beslut som skickas ut till ingivaren via post.
Om handläggaren däremot anser att en incident inte är fullständig för att göra en bedömning kommer ingivaren behöva skicka in en komplettering. Skulle detta vara fallet väljer handläggaren beredningsstatus ”Komplettering” och inväntar att incidenten kompletteras. Ett annat sätt för att ärendet ska få beredningsstatusen ”Komplettering” är att ingivare kryssar i en checkbox för komplettering vid anmälan om incident. När kompletteringen är inkommen ska den kopplas ihop som en handling under samma ärende som incidenten, de får då samma diarienummer.
Handläggaren kan även ta beslut om att ärendet behöver behandlas av berörd enhet och väljer beredningsstatus ”Till enhet”. Om handläggaren känner sig tveksam angående vad som bör göras med en specifik incident väljer handläggaren ”Fortsatt bedömning”. Genom denna process kan handläggaren överlägga med en annan handläggare för att tillsammans komma fram till vad som bör göras.
21
4.4 Empiri jämfört med teori
I denna del av resultat och analys ställs empirin mot teorin. För denna del kommer det teoridrivna perspektivet att appliceras. Identifierande teman i teorin har ställts mot empirin som samlats in i denna studie.
Det är viktigt att välja rätt process för en RPA-implementation
I mars 2020 lanserade den offentliga verksamheten sin nya en e-tjänst för PUI-processen. Denna e-tjänst gör det nu möjligt för ingivare att fylla i incidenten online och skicka in den digitalt i form av en PDF. Detta har tidigare utförts fysiskt med anmälningar inkomna i pappersformat.Systemförvaltaren förklarade följande:
”Den nya processen har tagits fram i samband med att vi utvecklade e-tjänsten för PUI-anmälan. E-tjänsten lanserades den 9 mars i år och processen började användas först i och
med det, så den är med andra ord helt ny.”
Vid införandet av e-tjänsten uppdaterades processen för att stämma överens med den nya tjänsten. Detta skiljer mot de egenskaper som Rutaganda et al. (2017) och Lacity et al. (2015) uppger att en process ska besitta; stabil och oföränderlig. Utöver detta beskriver Geyer-Klingberg (2018) att en process ska vara standardiserad. Tidigare processbeskrivning visar på att processen följer en standard. Processen utförs upprepat och repetitivt enligt samma standard. Detta går i linje med det krav som Geyer-Klingberg (2018) har på en process.
PUI-processen är en process som utförs flera gånger om dagen hos verksamheten. Processen går igenom samma steg varje gång men på olika sätt baserat på handläggarens beslut. Detta tyder på att processen inte är regelstyrd men att den är repetitiv, vilket stämmer överens med de krav som Asatiani et al. (2016) har på en process som ska hanteras av RPA.
PUI-processen hanterar ett system och ingen data förflyttas inom eller utanför systemet, utan data modifieras endast. Denna data som kommer in i systemet kommer från de incidenter som skickas in till verksamheten. En del av de fält som en ingivare fyller i incidenten är fritextfält, det vill säga att det finns inga fasta svarsalternativ. För att en process ska lämpa sig för att hanteras av RPA ska processen hantera flera olika system (Asatiani et al., 2016), förflytta data (Geyer-Klingeberg, 2018) och inte innefatta en stor del av undantag (Willcocks et al., 2015).
22
Detta innebär att PUI-processen bryter mot kraven om att processen ska hantera flera system och förflytta data. Processen innefattar även en del undantag i form av att fritextfält som en RPA inte kan hantera. Dessa fritextfält måste hanteras av en handläggare vilket utgör ett avbrott i processen. Detta avbrott betyder att processen inte uppfyller Willcocks et al. (2015) kriterium om att processen inte får innehålla en stor del undantag.
Verksamheten bedömde att det inte var lämpligt att automatisera beslut för denna process eftersom beslut gällande incidenter baseras till största del utav fritextfält. Detta kan understrykas med citat förklarat av systemförvaltare:
“Vi har bedömt att det inte är lämpligt att tillämpa helt automatiserade beslut när det gäller anmälda personuppgiftsincidenter då viktig information om incidenten samt den
personuppgiftsansvariges hantering av incidenten i huvudsak anges i fritextfält.”
Automatisering av beslutsfattande med hjälp av en RPA innebär att uppgifterna som utförs ska vara regelstyrda och bearbeta data på ett förbestämt sätt (Willcocks et al., 2015). I fritextfälten kan ingivaren skriva och formulera sig på olika sätt vilket gör att en RPA inte kan ta självständiga beslut. På grund av detta togs beslutet att endast ett beslutsunderlag skulle tas fram som handläggaren sedan kunde granska och ta det slutgiltiga beslutet. Denk et al. (2019) förklarar att ett automatiserat beslutsfattande inte behöver innebära att en dator tar ett självständigt beslut utan det kan även innefatta generering av beslutsunderlag. Trots förvaltningslagen som ger offentliga verksamheter rätten till att automatisera beslutsfattande helt utan granskning av en människa (Sveriges Kommuner och Landsting, 2018) lämpade sig inte detta på grund av de begränsningarna som en RPA har.
Värdera lönsamheten för kunden
Beslutstiden för ett ärende tar längre tid än önskat enligt verksamheten. Orsaken till detta är på grund av att det tar tid att läsa igenom alla incidenter som kommer in till verksamheten. Varje incident är 14 sidor som innehåller 37 frågor. En del av dessa frågor är fritextfält och andra fördefinierade svarsalternativ. Av dessa orsaker har verksamheten sett ett behov att undersöka huruvida det är möjligt att automatisera delar av denna process för att reducera arbetsbelastningen. Systemförvaltaren redogjorde behovet av automatisering:
23
”Vi har en ganska stor volym av PUI-anmälningar och många av dem påminner om varandra. Önskan är att göra handläggningen av incidenterna enklare och mer effektiv.”
Under en workshop fattades ett gemensamt beslut om att försöka förkorta handläggningstiden genom att ta fram ett preliminärt beslutsunderlag med hjälp av RPA. Denna del valdes på grund av att det ännu inte går att garantera att digital maskning inte går att avmaska och att diarienummer får inte lämnas ut, vilket innebär att sammankoppling av ett ärende och dess komplettering måste ske manuellt.
Handläggaren förklarade för att komma ihåg innehållet i en incident noterar handläggaren de viktigaste nyckelorden på en post-it lapp. Denna lapp placerades sedan på den fysiska incidenten. Av denna orsak diskuterades möjligheten till att skapa ett beslutsunderlag baserat på hela incidenten likt post-it lappen som handläggaren använder sig av. Dock visade det sig att detta skulle innebära att ett stort antal variabler skulle behöva läggas till på ärendekortet i ärendehanteringssystemet. Att lägga in alla dessa värden skulle göra sammanställningen av incidenten svårläst och inte bidra med någon större fördel enligt handläggarna. Denna iakttagelse avgränsade automatiseringen till att hantera ärenden som är harmlösa eftersom det krävs färre variabler för att bedöma om en incident är harmlös. Ärende som är harmlösa kan avslutas direkt efter att handläggaren verifierar beslutsunderlaget som tagits fram genom automatisering. Detta skulle innebära att handläggaren inte behöver öppna och läsa igenom hela incidenten. Incidenterna som klassificeras som harmlös tilldelas benämningen ”Sannolikt harmlös”.
Beslutet om automation av beslutsunderlag gällande ”Sannolikt harmlösa” incidenter är ingen omfattande automation av processen. Det är en liten del av den långa handläggningsprocessen. Trots detta ser handläggaren detta som ett stort hjälpmedel för att minska arbetsbelastningen. Detta understryks med citat uttryckt av handläggaren:
”Det ser inte mycket ut, men det skulle göra stor skillnad för mig”.
Om denna belastning skulle minska hade det varit värdeskapande för verksamheten. Detta går i linje med kravet som Asatiani et al. (2016) har beskrivit om att värdera lönsamheten för kunden innan ett beslut om RPA-implementation fattas. En automatisering av PUI-processen skulle skapa stort värde i verksamheten i form av att minska handläggningstid. Denna aspekt
24
fyller även kravet som Rutaganda et al. (2017) har om att tydligt klarlägga varför verksamheten behöver en RPA istället för hur den ska implementeras.
Verksamheten ska ha en avgörande roll
Under den första workshopen tillsammans med verksamheten presenterades alla involverade i projektet och verksamheten fick berätta om sin organisation samt de mål dem har med RPA. Därefter har konsultföretaget och verksamheten arbetat iterativt ihop. Representanter från konsultföretaget och verksamheten har medverkat vid varje workshop. De roller som har deltagit från verksamheten är digital samordnare, systemförvaltare och handläggare. Från konsultföretaget har affärsutvecklare och systemutvecklare varit delaktiga. Detta uppfyller kravet om att alla intressenter ska involveras tidigt i projektet (Lacity et al., 2015) och att olika avdelningar inom organisationen ska delta under projektets gång (Rutaganda et al., 2017)
Vid utvecklingen av RPA för denna verksamhetsprocess det blivit känt att tidigare digitala initiativ gällande RPA har funnits inom verksamheten. Likt lösningen som tagits fram för denna studie har tidigare automatiserings idéer varit att klassificera ärenden. Detta kan understrykas med följande citat framfört av systemförvaltaren:
”Tankar på att märka upp inkomna ärenden utifrån vilka svarsalternativ som angetts i anmälan har funnits länge, men i och med anmälningarna inte har hanterats digitalt förrän
nu så har vi inte gjort någon utveckling kring detta.”
Genom hela studien har samtliga respondenter från verksamheten visat stort engagemang. Alla deltagare har haft en positiv inställning gällande RPA och automatisering. De har visat ett driv gällande utveckling och digitalisering av verksamhetens system och har deltagit i alla workshops med stort intresse för att automatiseringen ska bli lyckad. Rutaganda et al. (2017) har poängterat att organisationen ska ha ett stort engagemang i projektet, vilket verksamheten har påvisat.
Initiativet om att implementera RPA i verksamheten kommer delvis från konsultföretaget och delvis från offentliga verksamheten. Verksamheten hade kollat på dessa lösningar vid ett tidigare skede. Tillsammans kom de fram till att inleda RPA-implementation hos verksamheten.
25
Under en workshop tillsammans med systemutvecklare var målet att identifiera vilka underliggande system som utför processen. Utvecklarna förklarade flödet för hur en PUI-anmälan hanteras av systemet. Det framkom under denna workshop att denna process endast hanterar ett system.
Systemutvecklarna beskrev flödet som följande; en PUI-anmälan kommer in i form av en PDF via E-tjänsten. Därefter sparas värden om komplettering, nyckelord och sekretess från PDF: en i databasen. I ärendehanteringssystemet skapas ett nytt ärende, PDF: en sparas som en bilaga i ärendet. Den lösning som verksamheten önskade att automatisera var som tidigare nämnt ”Sannolikt harmlösa” incidenter. För att klassificera dessa incidenter behöver handläggaren kontrollera vad ingivaren angett på vissa frågor. Systemutvecklarna förklarade att det är möjligt att exekvera logik när en ny incident inkommer, vilket är innan värden sparas i databasen. De tydliggjorde även att det är möjligt att använda sig av utrymme i databasen för att spara den nya preliminära bedömningen ”Sannolikt harmlös”. Detta skulle innebära att RPA i detta fall kan ersättas med att utveckla lösningen i befintliga system utan att implementera en RPA. Slutligen togs beslutet om att automatisera med hjälp av underliggande system.
Faktumet att systemutvecklare tillsammans med verksamheten har kommit överens om en process där en RPA kan implementeras och systemutvecklarnas lösningsförslag visar på att Rutaganda et al. (2017) krav om att initiativet om att implementera en RPA ska komma från verksamheten och att IT-avdelningen ska vara en stark allierad medarbetare uppfylls.
Utvecklingsmetod
Utvecklingen av en RPA har varit iterativ process i form av tät kontakt och regelbunden avstämning med verksamheten. Under utvecklingen har workshops med jämna mellanrum planerats. Syftet med dessa workshops har varit att validera och stämma av med verksamheten och att säkerställa att slutprodukten faktiskt blir som de önskat. Vid början av utvecklingen presenterades nuläget av PUI-processen, varpå vi skulle kartlägga den för att sedan kunna ta fram ett önskat börläge. Med hjälp av en tät kontakt med verksamheten har de krav som verksamheten haft kunnat appliceras på lösningen. Nya insikter skapades i takt med att projektet fortlöpte och kravbeskrivningen blev mer detaljerad.
Lamberton et al. (2017) och Rutaganda et al. (2017) enas om att agila-utvecklingsmetoder lämpar sig bra för att utveckla RPA. Under denna studie har ett iterativt arbete utförts nära
26
verksamheten där konsultföretaget och offentliga verksamheten gemensamt diskuterat och fattat beslut. Enligt Gustavsson (2007) är agil utveckling att iterativt leverera resultat och upprätthålla rörlighet i kravbilden. Fowler et al. (2001) beskriver även att ett agilt arbetssätt innebär att arbeta med en tät kontakt med kunden för att säkerställa att det kunden önskar är det som levereras. Utifrån denna teori kan det styrkas att utvecklingsprocessen under denna studie har utförts agilt. Detta betyder att kravet för hur robotstyrd process automation ska utvecklas uppfylls.
4.5 Nya upptäckter
I denna del av resultatet och analys presenteras nya upptäckter. Dessa har genererats genom datadriven analys. Nya upptäckter är nya iakttagelser som framkommit vid analys av den insamlade empirin från de olika datainsamlingstillfällena.
Känsliga uppgifter
Diarienummer identifierar ärenden och varje ärende har ett unikt diarienummer. Enligt verksamheten kan de inte lämna ut diarienummer digitalt, varken till ingivaren eller allmänheten. Detta på grund av att själva vetskapen om att en anmälan gjorts kan vara känsligt i sig, diarienumret är en indikation på att en anmälan gjorts. Verksamheten bedömer att ett diarienummer kan anses som en hemlig uppgift. I Offentlighets- och sekretesslagen (2009:400) uppges att om en myndighet antar att en handling innehåller hemliga uppgifter sekretessmarkeras handlingen (Bergström et al., 2018). En uppgift som är sekretessbelagd får inte röjas hur det än sker (Sveriges Riksdag, 2018). Skulle ingivaren önska att få uppgift om diarienumret meddelas diarienumret via telefon. Utöver det kan ingivaren se diarienumret i beslutet som skickas via post. Eftersom diarienummer inte får kommuniceras digitalt finns heller inget normalfall för hur kompletteringar ska kopplas ihop till tidigare skapat ärende. Detta försvårar registraturens arbete när en nyinkommen komplettering ska diarieföras i ett befintligt ärende. Registraturen måste istället försöka hitta ärendet genom att söka på ingivarens namn, e-post, in-datum, registreringsdatum eller liknande värden för att hitta ärendet. Registraturen kan även söka på diarienummer om registraturen vet vilket ärende kompletteringen hör till. Eventuellt kan registraturen söka på en referens om ingivaren angett det i incidenten. Hantering av diarienummer är således en säkerhetsrisk och begränsar möjligheterna till automatisering.
27 Digital maskning
Tidigare RPA initiativ som gjorts hos verksamheten är försök till maskning av sekretessbelagda fält i ett ärende med hjälp av UI-Path som är ett RPA-verktyg. Utlämningen av ärenden kan behöva sekretessmarkeras då det kan beröra känslig information. Detta innebär att inga utomstående ska kunna tyda vissa fält i en handling. Denna maskning görs i nuläget för hand. Incidenten skrivs ut, känsliga uppgifter stryks över för hand och sedan kopieras handlingen. Orsaken att tidigare RPA initiativ gällande sekretessmarkering inte har verkställts beror på att de önskar att nyttja en PDF-mjukvara som är tillräckligt säker för att sedan även kunna skicka ut beslut digitalt. Det vill säga att beslut av incidenter med sekretessmarkering inte är möjlig att avmaska. Möjligheten till att maska sekretessbelagda fält är möjlig under tiden som besluten skickas ut i pappersform. Trots tidigare RPA initiativ tog verksamheten beslutet att först börja med att sätta e-tjänsten i drift. Eftersom anmälningarna har hanterats i pappersformat fram tills mars 2020 förklarar verksamhetens systemförvaltare följande:
”Eftersom vi hanterat PUI-anmälningar i pappersform fram tills helt nyligen så valde vi att bygga en e-tjänst för anmälan och digitalisera handläggningsprocessen först, innan vi
eventuellt går vidare med RPA”.
Maskning av sekretessbelagda fält var ett moment som verksamheten ansåg vara en arbetsbelastning. Trots tidigare försök till automatisering av denna aktivitet kunde de som tidigare nämnt inte säkerställa att det var helt säkert. Det vill säga att de inte kunde garantera att maskningen var omöjlig att avmaska. Enligt Sveriges Riksdag (2018) får en sekretessbelagd uppgift inte röjas på något sätt, om det så sker muntligt eller i skrift. Av denna anledning kan inte beslut skickas ut digitalt.
28
4.6 Sammanfattning av resultat och analys
Tabellen visar hur detta fall förhåller sig till de femton teoretiska koncept som sammanfattades i teorin.
Det är viktigt att välja rätt process för en RPA-implementation I linje med tidigare studier
1. Repetitiv (Asatiani et al., 2016). X
2. Regelstyrd (Asatiani et al., 2016).
3. Hantera flera system (Asatiani et al., 2016).
4. Oföränderlig (Rutaganda et al., 2017; Lacity et al., 2015). 5. Stabil (Rutaganda et al., 2017; Lacity et al., 2015).
6. Standardiserad (Geyer-Klingberg, 2018). X
7. Förflytta data (Geyer-Klingeberg, 2018).
8. Inte innefatta en stor del av undantag (Willcocks et al., 2015). Värdera lönsamheten för kunden
9. Värdera lönsamheten för kunden innan ett beslut om RPA-implementation fattas (Asatiani et al., 2016).
X
10. Tydligt klarlägga varför verksamheten behöver en RPA istället för hur den ska implementeras (Rutaganda et al., 2017).
X
Verksamheten ska ha en avgörande roll