Workshop om RPA (Robotic Process Automation)

Workshopen om RPA följde en konferensdag som avhandlade RPA & AI för offentlig sektor – läs anteckningarna här. Som nästan alltid när det utannonseras en “workshop” är inte jag och arrangören direkt överens om vad det innebär. Så även denna gång. Denna workshop var en grupp på cirka tjugo personer där nästan alla jobbade inom offentlig sektor, åtminstone en hade offentlig sektor som sin vanligaste typ av kund.

Det blev en dag av föreläsning med frågor till oss åhörare om vi hade något att dela med oss av. Men det var inte fel det heller, vi gick från ax till limpa när det gäller att komma igång med RPA, från prototyp till hur man skalar upp ordentligt.

Om workshopen

Workshopledare: Tomislav Andric, EY

Är RPA en väg mot AI? Sätter man rätt förväntningar om man gör den kopplingen gentemot verksamheten?

”People are worried about Artificial Intelligence and job losses but a far bigger problem in the world is natural stupidity. Tech is advancing, our wisdom isn’t.”
Michael Jordaan på Twitter

De största leverantörerna – Blue Prism, UiPath och Automation Anywhere

Blue Prism och UiPath är två kända leverantörer. Automation Anywhere är större i USA. Microsoft har inte sin egen plattform, däremot ett partnerskap med Blue Prism, då kan man konsumera Microsofts Azure-tjänster också.

Gartner erbjuder en jämförelse mellan de olika RPA-leverantörerna. De har också en bra definition i mitt tycke av RPA, nämligen:

”Robotic process automation (RPA) tools perform ”if, then, else” statements on structured data, typically using a combination of user interface (UI) interactions, or by connecting to APIs to drive client servers, mainframes or HTML code.”

Vad jag förstått är det RPA-verktyget NICE via använt inom Västra Götalandsregionen under vår förstudie. Under workshopen är det endast UiPath som visas upp och det ser ut som en variant på Microsofts Visio i mångt och mycket.

RPA är snarlikt att göra gränssnittstester

RPA är en mjukvara som på sätt och vis är integrerad med de grafiska gränssnitt som IT-infrastruktur erbjuder och härmar det en medarbetare. Integrerad i så måtto att den gör detsamma som en medarbetare skulle ha gjort, den kräver alltså ingen “integration” i teknisk bemärkelse. De kan förstås också använda mer tekniska gränssnitt likt en webbservice eller webb-API.

För oss med utvecklarbakgrund har detta enorma likheter med hur man säkerställer att ett gränssnitt eller webbplats fungerar. Inte sällan har man använt tekniker som Selenium, webscraping eller screenscraping.

”Screen scraping is normally associated with the programmatic collection of visual data from a source, instead of parsing data as in Web scraping.”
Wikipedia om data scraping

Strikt sett är RPA dummare än tåget

En RPA-robot är extremt regelstyrd och gör inga som helst egna bedömningar. Därför är det dumt att klumpa ihop RPA och AI som att de vore lite av samma sak. Ett stående skämt är att AI, och även machine learning, bara är en massa if-satser. När det gäller RPA är det inte ens särskilt många.

Men det är förstås fullt möjligt för en robot att dra nytta av extern intelligens, sen om det är en AI-tjänst eller att invänta en människas naturliga intelligens ändrar inte faktum att RPA enbart är automatisering.

På vilken nivå av digitalisering/automatisering lämpar sig RPA?

För att lista ut när RPA är ett bra alternativ behöver man fundera på om inte behovet är så pass stort att det ska lösas av något annat system. Ett sätt att tänka på det är om hur ofta uppgiften behöver utföras och hur specifik den är.

Är det något som görs extremt ofta är det troligen lämpligare att låta det ske i respektive verksamhetssystem, som kundsystem (CRM), affärssystem (ERP) eller ett processverktyg (BPMS). I andra änden av skalan är väldigt specifika arbetsuppgifter eller sådant de anställda snickrat ihop i Excel. Tänk affärssystem kontra makron i Excel.

Hur stort glapp man har mellan dessa standardsystem och medarbetarnas hemmasnickrade lösningar i Excel varierar garanterat, men det är där man nog hittar en roll för RPA.

Begränsningar

Roboten ändrar inte befintliga system. Önskemål på befintliga system löser man inte med RPA, om man inte bygger ett nytt system som roboten bistår att föda med data. Men då har man påbörjat en helt annan typ av projekt.

RPA är inte smart. Den begriper exempelvis inte ostrukturerad text. Men roboten kan samverka med AI-tjänster och låna smarthet, vilket kan vara enkla saker som att hitta fakturanummer i en inskaffad faktura.

En annan begränsning är att roboten lägger beslag på datorn eftersom den styr muspekaren, startar webbläsare och program för att få sysslan utförd.

Förfarande i Blue Prism…

De olika rollerna under en körning av RPA:

  1. En utvecklare har tagit de funktionella kraven och instruerat maskinen hur den ska göra.
  2. Utvecklaren definierar när och hur roboten ska köras, exempelvis varje natt klockan 5:00.
  3. Själva roboten körs. Roboten körs i en virtuell miljö om man inte kör den på sin egen dator.
  4. En controller ser till att roboten fortsätter köra, övervakar och skickar eventuella felkoder till utvecklaren. (Det är högst troligt att man löpande kommer stöta på fel).
  5. En annan syssla för den som är controller är att kolla resultatet av körningarna och om roboten presterar enligt plan eller om man måste prata med utvecklaren på nytt. Hanterar också systemundantag.

Robotics är ”inte den stabilaste av lösningar”. Alla ändringar i de inblandade systemen gör att roboten kommer att misslyckas lite då och då, men den drabbas förstås också av strul med nätverk och annat IT-strul.

Blue Prism ser rätt mycket ut som Microsoft Visio. Det finns en möjlighet att gå in i bakomliggande kod om man har den kompetensen.

Att gå till förvaltning

När man tar sin lösning till förvaltning upptäcker man om det finns skillnader mellan produktionsmiljö och den testmiljö man använt.

Vad händer om roboten är nere? Säg ett dygn. Finns en reservplan?

Om systemen man kör roboten mot senare erbjuder ett API blir frågan vad som är smidigast. Inte helt givet att man väljer att fortsätta med RPA, men det hänger mycket på vad API:et erbjuder.

Nyttorealisering är inom cirka 2-8 veckor.

Hur gör man med lösenordshantering? Vem får lov att ha dessa lösenord med tanke på att man med dem kanske når typ vad som helst i respektive system.

Hur ser rollerna ut när man skalat upp?

Var finns mandatet med ägandeskap för en befintlig process? Utvecklaren vågar aldrig ta över den rollen. Någon behöver vara beredd att göra en sign-off på det den virtuella kollegan ska göra.

De olika rollerna som är specifika för ett RPA-projekt kan kategoriserar till följande:

  1. RPA-specialister, som:
    1. Processanalytiker – den som är expert på var processautomatisering kan appliceras och vilka begränsningar som finns.
    2. Utvecklaren – designar, tränar, felsöker och rättar roboten.
    3. Controllern – övervakar roboten, tar fel vidare till utvecklaren, håller kontakt med IT-avdelningen och står för den kontinuerliga kontakten med verksamheten.
  2. Processpecialister, vilket är följande roller:
    1. Processens ämnesexpertis (SME – Subject-Matter Expert) – är den som bäst vet hur det funkar idag och hur processen kan designas om för att vara möjlig att automatisera. Är också inblandad i respektive sprint i RPA-projektet.
    2. Processägare – inblandad i hur processen designas om, tar på sig ägandet av den automatiserade processen, ger sign-off på lösningen och bevakar att värdet uppstår.
  3. Stödjande roller är alla de andra som behövs för att komma i mål, som dessa:
    1. Den som leder robotisering/automatisering inom organisationen.
    2. Applikationsägare – de kan om inte annat sätta sig på tvären om de inte blir involverade (och lyssnade på).
    3. Rick- och säkerhetsfolk – lämpligt att ha med så man följer intern praxis och intention när det gäller behörighet samt inte utsätter organisationen för risker.
    4. Den som axlar IT-ledarrollen när det gäller RPA – vilket beroende på var utvecklaren återfinns kan vara den enda vägen in om IT-avdelningen.

Ett exempelprojekt mätt i tid

Vanligen är ett team på 1-5 personer. Om man ser uppskattningen i tid kan man räkna med 2-8 veckor för att definiera processen och att designa den som en pappersprodukt. Sedan går det vanligtvis 3-8 veckor för att utveckla roboten till en teknisk lösning, acceptanstester och sedan produktionssättning.

Att skala upp en icke-strategisk lösning?

Som ett flertal nämnt angående RPA så är det en taktisk lösning för det som varken är värdigt ett standardiserat system med enorma volymer och inte heller de små “fulhack” var och en gör på sina egna datorer.

Därför är det klokt att jobba strukturerat, det är sällan något man behöver vid sin första lösning men samtidigt blir det aldrig attraktivt att stanna upp och få det gjort då surdegen bara växer till sig.

Saker att jobba med är inriktning och governance, som i att jobba med roller, ansvar och hantering av de tillgångar/assets man tar fram på grund av robotiseringen.

En annan del är processens livscykel. Hur en process kvalificerar sig till att automatiserar och vilka man låter bli, men också hur utveckling och produktionssättning går till. Den senare kan te sig väldigt teknisk, men ska man verkligen stapla bärbara datorer på hög? En dator per robotiserad process? Eller ska man köra virtuella maskiner i någon molnmiljö, eller går det att paketera i containers som Docker eller Kubernetes? Alla har sina egna förtjänster och nackdelar.

Att mäta skapat värde ska man inte missa. Dels behöver man på förhand ha en uppfattning om hur mycket effektivitet som krävs för att insatsen ska vara värd att ens påbörja, men sedan gäller det att kunna visa att administrationen av roboten i förvaltning skapat bestående nytta. Detta behöver rapporteras och det är bra om man på förhand kommit överens om mätetal/KPI:er som definierar nytta eller värde.

Som alla förändringar är det klokt att ha folk som jobbar med just förändring, men också att tänka in är att detta är en föränderlig värld även när det gäller vilken kompetens RPA-teamet behöver bestå av – nu och i den nära framtiden. Den eller de som axlar detta jobb tar också hand om intressenterna, kommunikationen och förändringsledningen i stort.

Lite närmre IT, digitaliseringsavdelningar eller techfolk i största allmänhet landar frågor om hur man hanterar de olika teknikleverantörerna. Det är inte otroligt att man kommer ha fler än en lösning, inte minst genom att befintliga leverantörer och produkter får dessa funktioner inbyggda helt plötsligt. Detta gäng behöver hålla igång ett testlabb, se till infrastrukturen och arkitektur.

Sist men inte minst är det övriga verksamhetsfrågor som risk, säkerhet och omställning. Här kommer frågor om autentisering och behörighet in, reservplaner för när robotarna slutar fungera och mycket mer.

Ha en inriktning för när man använder RPA

Exempelvis om man vet om att systemen ändras så pass ofta att det inte är lönt att försöka då roboten kommer att gå sönder för ofta.

Viktigt med löpande kontakt med systemägare så man är redo när det kommer justeringar i systemen man är beroende av.

Unhappy path

När roboten kör fast ska den ha en ”unhappy path”, det är den utväg den tar när något går snett. Dess fokus är då primärt att ge ett bra felmeddelande till den som övervakar roboten. Det är vettigt med en etablerad praxis för hur meddelanden skrivs så det underlättar förvaltningen senare, att man har något matnyttigt att gå på vid felsökning.

Respektive produkts support är tydligen lite svår att nå men de stora produktleverantörerna har välanvända användarforum där man kan hitta tips och hjälpa varandra.

Vilken organisationsmodell föredrar man

Som alltid kan man lägga upp arbetet och ägandet av frågan på. Huvudspår är:

  • Decentraliserad modell, vars styrka är närheten till där processen hör hemma, men bland annat med nackdelen att det är svårt att få igen organisatorisk praxis och mindre samkörningsbesparande.
  • Centraliserad modell ger fördelen att man har god styrning, men nackdelar kan bli att man centralt och lokalt gnabbas om beslut.
  • Federerad innebär att man har en centraliserad Center of Excellence (CoE) men att mycket arbete sker decentraliserat. Fördelen är att man ute i verksamheten äger processen och har autonomi, nackdelen är ansträngningen och att man initialt måste lägga energi centralt.

Hur bra fungerar det om man är konsultberoende?

Det är nog smidigast att kunna allt själva och inte bara ha beställarkompetens. Men då förändringarna ligger så nära verksamheten är det smart att utbilda de man redan har. Alternativet är väl att outsourca hela klabbet.

Risken med konsultberoendet är att processägaren inte når insikt i möjligheten. I små organisationer blir det lite knepigt då man har en RPA-generalist som måste låtsas vara utvecklare, specialist på processerna, controller och visa på nyttan – samtidigt.

Det finns ett gäng ansvar och delaktighet man inte kan slippa undan även om man outsourcat eller låter IT göra jobbet.

Återanvändbarhet

Det bör rimligen gå att importera andra organisationers färdiga robotisering. Man bygger upp ett bibliotek av skript. Men ofta är det inte den delen som tar tid, snarare det som rör processen, lära av mänskliga användare och få ok att sätta igång.

Kostnad och besparingar för ett RPA-projekt

Ett typiskt projekt där man blandar in konsulter kan handla om 250-1500 tkr, där den låga siffran skulle handla om att ta fram en genomarbetad proof of concept.

Vanliga nyttor man eftersträvar är bland annat:

  • Att låta människor göra det de är bäst på. Folk läser inte till ett vårdyrke för att brottas med IT-system. Idag är människan integrationen mellan de olika systemen. Datorn jobbar inte för människan.
  • Minska personalomsättning och maximera nyttan av medarbetarnas talang. Få saker tråkar ut kunskapsarbetare mer än hjärndött arbete, dessutom stjäl det tid som kunde lagts på något mer värdeskapande.
  • Öka kvaliteten och minska de kostsamma felen. Rent generellt stödja kvalitetsarbetet, bli mer konsekvent och ta kontroll över felbenägna aktiviteter.
  • Få mer gjort snabbare och ta bort flaskhalsar. Att ge sig själv mer kapacitet vid säsongsbetonade toppar samt under vanliga dagar ha tid för bättre kundvård.
  • Öka kundnöjdhet. Kanske genom att snabbare expediering av ärenden eller inte vara så systemberoende.

Vilka nyttor som appellerar på de du behöver övertyga varierar förstås.

Det är fullt möjligt att ha en halvtidsperson som jobbar med RPA. Man blir förstås än mer personberoende då.

Hur säljer man in en robot på de anställda så de inte blir rädda om sina jobb, så kallad “automation anxiety”. Vad innebär det för de anställda, vad kan de förvänta sig? Gör man det för att kunna sparka folk, för att göra jobbet mer hanterbart, uppnå bättre kvalitet, eller något annat?

Idégenerering – vad är en bra idé för robotisering?

Hur man kommer fram till en gångbar och prioriterad lista med robotar? Ett sätt är att ta fram ett betygsystem för att bedöma en idé på en abstrakt nivå. Den mall som visades under workshopen hade två huvudsakliga kategorier. Om vi först tittar på Benefits of RPA skulle varje process delprocesser antecknas så här:

  • Subprocessens namn: Manuella fakturor
  • Antal heltidsanställda (FTE, Full-time equivalent): 5 st
  • Volym per månad: 4000
  • Genomsnittlig tid att hantera ett ärende: 4 minuter
  • Automatiseringspotential: 100%
  • Sparade timmar / månad: 266

Den andra bedömningsgrunden handlar om hur tekniskt komplext det är, Ease of implementation. Där graderas respektive sak enligt hög, medel, låg när det gäller hur enkla de är att realisera. Saker att notera är då:

  • Applikation eller system: x & y
  • Regelbaserat: hög, medel, låg
  • Standardiserad input: hög, medel, låg
  • Digitalt redan: hög, medel, låg
  • Komplexitet: hög, medel, låg

Beroende på vad man får fram räknar ett lämplighetsbetyg fram för om RPA är rätt lösning.

Kan behövas en grupp med folk som bollar detta på återkommande basis, det kommer ju nya förslag löpande som behöver beaktas.

Dashboards och folk som övervakar robotarna dygnet runt

För monitorering kan man säkert dra hjälp av andra under den tid man inte har egen personal i tjänst. EY (där workshopledare jobbar) är världens största köpare av Blue Prism och de har ett automatiseringscenter i Indien.

Dashboards är en översikt för att dels hålla koll på alla robotar, men det är också en plats där man ser hur robotarna presterar på den förväntan de har på sig. Om deras effektivitet sjunker tillräckligt mycket kanske de inte lönar sig längre och antingen behöver justeras eller skrotas.

Viktiga insikter

Några punkter att beakta:

  • Vara överens om vad man gör när något inte funkar.
  • Nog mer intensivt arbete för verksamhetsfolket än man först tänker sig.
  • Hur stort behöver det vara för att vara värt ett lite större försök?
  • Arbetet och ägandet ligger oftast i verksamheten, inte IT.

Dokumentation

Script-guide som en dokumentation utan att ge sig in i respektive verktyg. Flödet för när allt går bra är inte direkt ansträngande, mer energi brukar behöva läggas på hur man hanterar alla undantag. Exempelvis om ett program inte startas, det kraschar under körning, en webbsida ger inte ett komplett resultat, etc.

En övergripande dokumentation för vilka robotar som finns, när de körs, hur/om de reagerar på externa signaler och så vidare.

Egna tankar

Skillnaden mellan cron-jobs är inte enorm när det gäller schemaläggning, sen kan de triggas av händelser, men det finns i produkter som Beats i ELK-stacken och Splunk som har andra nyttor. Är resten ett produktifierat sätt att manipulera användargränssnitt? Lite så verkar det.

Det kan tyckas vara extremt resurskrävande och slösaktigt att emulera en vanlig användare genom att ha en komplett dator igång. Om man kör detta virtuellt kan man fundera på alla extra processer i operativsystemet som inte är absolut nödvändiga. Bör man köra virusskydd, exempelvis? Ska den köra Windows Update?

Kanske finns slimmade operativsystem att köra dessa på så man inte slösar processorns klockcykler på saker som inte strikt har med roboten att göra. Då de flesta klänger fast vid Windows har detta säkert med hur Microsoft väljer att ta betalt, men det finns bantade alternativ som Server Core och Windows 10 IoT Core som kan köras på hårdvara, likt Raspberry Pi, som kostar några hundralappar, som förstås har något sämre hårdvara än många andra datorer.

Men handlar det om att automatisera enbart webbsystem kan man helt strunta i Windows och köra Ubuntu med Selenium. Eventuellt i en Docker-container, det är faktiskt det som händer när man (som jag på fritiden) använder öppna projekt som Sitespeed.io

Skriv gärna en kommentar om dina tankar kring detta, och har du inte läst anteckningarna från konferensdagen om RPA& AI i offentlig sektor finns de här (långläsning).

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *