Skärmdump föreställande programmeringskod

Automatisera bort arbete som är nonsens

Begreppet RPA är extremt hajpat nu. Men hur gör man något strategiskt av det, och vad mer inom automatisering finns?

RPA är hett nu, åtminstone inom offentlig sektor där jag jobbar. Och nej, RPA är inte en ny företeelse, men kanske mer produktifierad än tidigare.

RPA är en förkortning som för en gångs skull blir detsamma om man översätter till svenska – Robotiserad ProcessAutomatisering, eller Robotic Process Automation. Ok, det är lite fusk då alla tre orden är utländska låneord, men jag jublar ändå :)

Det kommer en mer noggrann definition senare av RPA, men i all korthet betyder det att man har en mjukvara i en dator någonstans och den mjukvaran imiterar enkla handgrepp en människa kan göra med hjälp av en dator. Det kan handla om att flytta text mellan olika program, klicka runt och kombinera vissa sysslor. Ett exempel kan vara att hämta årets prisbasbelopp på någon myndighetswebbplats, stoppa in den siffran i ett visst fält i ett särskilt Excel-ark och göra lite beräkningar. Sedan sparas Excel-arket till något dokumenthanteringssystem. Rutinmässiga sysslor, typ.

Faror med RPA - asfalterade kostigar, bland annat

Johan Magnusson på Göteborgs Universitet skrev det bra i Linkedin-inlägget RPA och Kung Midas hand. Bland annat att:

“Löftena är många och vackra, och innefattar enorma effektiviseringsvinster genom automatisering av tidigare manuella rutiner. På så sätt blir RPA en snabb lösning på digitaliseringsutmaningen, och svarar samtidigt upp mot kraven på ökad effektivitet inom offentlig sektor.

Tyvärr så är allt inte guld som glimmar. Själva tekniken i sig bygger på att man automatiserar utifrån användargränssnittet, dvs undviker kostsamt och tidskrävande grundarbete i de underliggande systemen. Istället lägger man ett nytt lager av automatisering av rutiner på toppen av teknikstacken.”

Kostig 2.0 (och mycket jidder om vissa vägars evolution)

Detta ytterligare lager är inte gratis, inte heller är det en magisk lösning utan problem. Du som har åkt på småvägar i glesbygd har själv prövat en motsvarighet inom transport. Jag talar förstås om kostigar. En stig som en gång i tiden har röjts upp av tamboskap, en rutt om minsta friktion eller efter där det fanns något spännande eller mumsigt nog för en avstickare. Kossorna tog enbart genvägar. Ingen av dem behärskade heller mer kreativa lösningar som dynamit för att spränga bort stora stenbumlingar som var i vägen.

Så vad händer sen? Kostig 2.0 är en väg som inte främst är till för kossor. Det kan handla om vagnar eller de första bilarna. Så låt oss jobba med underlaget. Visst var det romarna som la sten som underlag och byggde ett extremt omfattande nätverk av vägar? Alla vägar leder ju trots allt till Rom, så något rätt gjorde de väl. Sen kom någon skotsk ingenjör fram till ännu ett lite bättre sätt att använda sten för att bygga vägar, därför har vi vägunderlaget kallat makadam. Ja, skotten hette McAdam.

Kostig 3.0? Asfalt ovanpå makadam testades åtminstone i Västerbotten till min morfars förtret. Ett till lager av något modernt löser nog biffen, eller? Sen att vägens sträckning från början valdes av en flock djur som skiter ner sig om man nyser intill dem gör den inte framtidssäkrad för saker som rör sig obegripligt mycket snabbare. Men som en parentes, nöjesåkande motorcyklister gillar verkligen dessa vägar, och säkert fler med dem, men inte jag när det är blixthalka och jag vill hälsa på vännerna i grannbyn.

Ibland vill man ha en asfalterad kostig

Och nej, RPA har inte enbart nackdelar, vilket man skulle kunna tro med allt ovanstående, väg-associerande, gnäll. Det finns absolut nyttor, men det är inte något jag har egen erfarenhet av så för min del är det mestadels teoretiska strategitankar. Eller snarare taktiska tankar. Jag brukar beskriva just RPA som en taktisk lösning och försöka förtydliga att det inte är så långsiktigt som vissa verkar hoppas på.

Exempelvis kan det vara helt rätt lösning om man inte vågar röra vissa tekniska system eller att de ändå ska skrotas inom något enstaka år. Då är det en del av planen att avskaffa något.

Varför är RPA en taktisk lösning?

Johans inlägg ovan kan kompletteras med en annan mytisk figur. Eller snarare tänket med Damokles svärd. Damokles avundades sin kungs ställning i samhället, men fick chansen att pröva kungens plats. Baksidan var att det hela tiden hängde ett skarpslipat svärd i ett ynka hårstrå från ett hästdjur ovanför hans huvud. Poängen är att det finns en skörhet ibland. Bland annat när man bygger RPA-botar.

Visst, det tar typ 1-3 månader att bygga en ny RPA-bot och det är imponerande snabbt i situationer där det tar nära på ett år att förbereda att ett gammalt system bara ska uppdateras. Men den här RPA-boten har beroenden av allt runt omkring sig på ett annat sätt än en människa. RPA-boten är nämligen hur korkad som helst. Den kan köra fast på att en knapp som förut hade texten “Submit” efter en systemuppdatering har texten “Skicka”, eller annat som en genomsnittlig människa sällan har bekymmer med.

En liknelse med människor är dock att även RPA-botar kan bli “sjukskrivna”. Om något förändras kommer den att sluta fungera. Därför kan man inte se detta som ett sätt att permanent lösa något. Om RPA-boten blir sjukskriven måste det fortfarande finnas kapacitet att göra arbetet manuellt. Människor med andra ord. Ibland får dessa människor dessutom gå in och fixa även gammalt arbete där RPA-boten gjort fel under en längre period. Ett sådant exempel var när Arbetsförmedlingen kom på att de tagit tiotusentals felaktiga beslut (2). Hoppas de inte hade sparkat alla människor som visste hur det jobbet utfördes..?

Man jobbar alltså på lånad tid. Medan RPA-boten gör något kan man ägna sig åt något annat, men måste vara beredd på att återgå till sina gamla sysslor.

RPA är bara automatisering

Eva Kongshöj, Vd på Bitoreq, är en av profilerna inom ämnet jag stött på. Hon envisas med att kalla det för automatisering och har förstås helt rätt. Jag tänkte med denna bloggpost gå igenom några av de andra produktifierade varianterna av automatisering, då de inte nämns fullt så ofta som RPA just idag.

Andra profiler inom RPA jag stött på, och som jag tror du kan diskutera dina behov med, är:

RPA: en definition - skärmflöde

RPA är en form av imitation av vad som kan utföras på en skärm av en människa som behärskar mus och tangentbord. En (ganska korkad) mjukvara som gör exakt på det sätt som den instruerats på förhand. Den öppnar program och webbplatser i en på förhand bestämd ordning, och utför saker enligt en instruktion. Lite som ett recept för att koka ägg:

  1. Lägg äggen försiktigt med hjälp av en sked i kokande vatten i en kastrull. Vattnet ska precis täcka äggen.
  2. Sjud äggen ca 3 min för löskokt ägg, ca 6 min för mjukkokt och ca 10 min för hårdkokt ägg.
  3. Spola äggen i kallt vatten någon min innan de serveras så att kokningen avstannar.

Vill man verka märkvärdig så javisst, detta är en algoritm. Samtidigt är alla former av instruktioner någon form av algoritm. Så som Wikipedia beskriver algoritmer:

“En algoritm är, inom matematiken och datavetenskapen, ändlig uppsättning (mängd) otvetydiga instruktioner som efter exekvering löser ett problem”

Eller en förenklad version: En algoritm är en beskrivning av instruktioner, som utan tvetydigheter, löser någon form av problem. Som att koka ägg, eller räkna ut momsen på din reseräkning.

Makro 2.0

Inom vissa program har det länge funnits ett liknande koncept kallat makro. Att en väldigt repeterbar syssla “spelas in” och kan spelas upp av datorn gång på gång. Sådant använde jag under mina år som konsertfotograf, att ha ett antal makron för bildbehandling. Jag spelade in de tråkiga sysslorna i bildbehandlingsprogrammet som ett makro, gav makrot ett kortkommando. Så ville jag spara ner alla foton från en konsert, vilket kunde handla om hundratals per dag, tryckte jag bara på snabbkommandot för varje bild. Det sparade massor med klick och letande i menyer. Bilderna blev i rätt storlek för att publiceras på webben, optimerades så de blev så små som möjligt, och lades ordnat och fint i en viss katalog på datorn.

RPA är egentligen bara nästa steg. EN RPA-bot hade kunnat gjort samma sak i Photoshop/bildbehandlingsprogram men också laddat upp bilderna på webbplatsen det handlade om. Jag har exempelvis tagit 8000 fotografier från Roskildefestivalen 2007 och skulle jag gjort alla dessa grejer manuellt hade jag nog inte hunnit sova över huvud taget på den festivalveckan.

Ja, makron inom program är kraftfullt, men de kan också kombineras med programöverskridande lösningar som RPA.

En nivå ner: Enterprise Service Bus (ESB) - ett dataflöde

Nästa nivå ner i kaninhålet för automatisering är ESB. Till skillnad från RPA, som gör exakt det som en människa skulle gjort och med samma mjukvaror, så är ESB istället en produktifierad variant att bearbeta flödet av data.

Jag har också hört kollegor inom området IT-integration kalla det för en dataväxel. Det är väl ett bra ord då en ESB kan agera växel mellan olika dataflöden, olika informationsstandarder och knyta ihop gamla sätt att göra saker med nyare sätt.

Ett användningsområde är att översätta mellan flera olika tekniska “språk”. På 1990-talet var alla övertygade om att precis allt löstes med hjälp av ett format/språk som heter XML. Det hette för jösse namn Extensible Markup Language (XML), så hur kunde det inte funka för all evig framtid? Eller som Wikipedia skriver:

“…XML, är ett universellt och utbyggbart märkspråk…”

Äntligen, det sista språket vi behöver. Så blev det förstås inte. Det dröjde ett gäng år och så ville mer eller mindre alla istället ha ett annat format, nämligen JSON, då det har andra fördelar. Bland annat ökade efterfrågan på JSON/JSONP när man byggde första generationens appar för Iphone och Android.

En ESB kan dock hjälpa till här. ESB:n kan konsumera information i XML-format från ett gammalt system och erbjuda exakt samma innehåll i JSON-format till nyare system. På så sätt kan man omvandla gammalt till nytt. Gamla skitsystem behöver inte förändras men innehållet kan ändå hämtas in till en app eller modernt webbgränssnitt, via en ESB.

En ESB kan göra mer än bara förändra data, exempelvis:

  • Se till att det gamla systemet inte blir överbelastat vid toppar av efterfrågan från alla nya grejer. En lastbalansering och/eller cache-hantering som skyddar det gamla systemet från extra tung belastning vid eventuella toppar av efterfrågan.
  • Den kan mixa ihop flera olika informationskällor och erbjuda en samlad bild. Knyter bokstavligen ihop olika trådar.
  • Hantera multipla behörigheter men kan också bygga ut behörighetsfunktionalitet som inte finns i källsystemet, exempelvis erbjuda (ofarliga och) öppna data utan behörighet, men ännu mer om behörighet finns.
  • Övervakning av komplexitet och säkerhet, exempelvis att ett tekniskt beroende börjar krångla, eller att en avvikelse i användningsmönster inträffat.

Ibland hör man folk kalla ESB för en API gateway, men jag är inte säker på att alla avser exakt samma typ av lösning. Du som är noob kan läsa mer om Application Programming Interface (API) hos Wikipedia.

Fler varianter av automatisering

Det finns förstås fler varianter, men dessa har jag inte någon värst bra koll på. Kanske för att de mer rör sig på en managementkonsults nivå i diskussionen med deras kunder och av vad jag förstår när jag nu gjort research så verkar det vara mer på en ledningsnivå än där jag rört mig för det mesta i konsultlivet (som börjar kännas väldigt avlägset).

Men en sak jag stöter på är BPMS (Business Process Management Systems), något för större och mer välstrukturerade aktivitetsflöden. BPMS är inte nödvändigtvis ett enskilt system, ibland mer av ett ekosystem. Min tolkning är att detta är ett fluffigt koncept och inget man köper som en enskild lösning. Men jag har gärna fel.

Ett annat begrepp jag snubblat över ibland är BPA (Business Process Automation) vilket skulle kunna inkludera RPA om man vill, åtminstone om man enbart automatiserar affärsprocesser. Men det sätter också lite fingret på att allt på något sätt är en teknisk lösning på ett behov av integration av diverse IT-verktyg.

Kanske gömmer sig här svaret på frågan som aldrig ställts i denna text. Att man ska börja med att anlita en processkonsult? Någon som har inventerat processer tidigare, någon som har hjälpt till med prioritering av processer att automatisera, med mera?

Automatisering på webben eller internet

När jag själv bygger grejer är det nästan uteslutande för webben som plattform. Att webben var den plattform som hade framtiden för sig under mina tonår gör väl sitt till, men samtidigt var webben en ganska orörd marknad när jag började jobba med teknik 1998, även fast man då använde begrepp som elektronisk publicering och multimedia. De begreppen är minst sagt stendöda idag, men delar av arbetssätten lever vidare - häng med…

Cron-job - automatisering 1.0 alpha

En av teknikerna från 1990-talet som fortfarande lever som koncept är cron-jobs. Det är ett halvknepigt namn på att ett jobb görs enligt en kronologi, det vill säga vid en given tidpunkt, eller schemaläggning om du föredrar det. Den typen av automatisering är supersimpel. Den anropar något annat vid en viss tidpunkt. Du har säkert hört talas om “körningar” som görs nattetid? Det här är i samma anda. Så som jag använt det är att vid låg belastning på webbplatser göra tekniska “städjobb”, som att räkna ut saker inför morgondagen. Ett exempel var när jag drev en festivalcommunity jag inte längre direkt vill kännas vid (sålde den för 12 år sedan och den har inte alls följt med tiden) så var det nästan ingen som var aktiv på webbplatsen mellan klockan 5-7 på morgonen. Helt enkelt ett utmärkt tillfälle att summera statistik som arrangörerna var intresserade av, eller köra andra tunga frågor mot den databas som var magin bakom hela webbplatsen.

Webben plus något annat

Det är väl säkert tio år sedan mitt team med utvecklare byggde en kampanjwebb för ett av Göteborgs kommunala bostadsbolag. De skulle bygga en ny stadsdel i Gårda och allt var inte klart när webbplatsen skulle lanseras. Eftersom kunden i sitt arbete med byggnationen redan hade valt en del teknik så anpassade vi oss förstås.

Det slutade med en lösning med en Microsoft Excel-integration mot webbpubliceringssystemet Episerver CMS. De hade redan en Excel-fil som innehöll fakta om de lägenheter som de höll på att uppföra, men denna Excel-fil förändrades ständigt. Ibland var det småsaker som att de gjorde ett “upplevelserum” av en balkong, men det kunde också bli större ändringar. För att inte behöva ändra det inarbetade arbetssättet var det inte konstigare än att vi webbutvecklare anpassade oss.

Vi kom överens med kunden om att det inte skulle bli fler kolumner i Excel-arket, att vi bara tittade på det första arket, att de kunde ha så många rader de ville och att varje rad var en lägenhet. Baserat på det så kunde de enkelt ladda upp en Excel-fil till kampanjwebben och på någon sekund återspeglade webbplatsen de förändringar som Excel-filen innehöll. Varför låta kunden ändra sitt arbetssätt när de redan jobbar på ett strukturerat och tillräckligt digitaliserat sätt?

Det hela var inte konstigare än att vara nästa steg från när jag 1999, på WM-data, senare Logica, numera CGI, byggde för den tiden väldigt omfattande produktwebbplatser utifrån Excel-filer, genom webbkunskap och ett svart bälte i sök och ersätt. En av webbplatserna har inte förändrats så värst mycket rent visuellt på dessa 20 år, hmm 🤔 Specialfälgar - Sveriges snyggaste fälgar

Selenium - för att använda webben som en datakälla

Det finns förstås även för webben produkter och lösningar som är långt mer avancerade än Unix-världens cron-jobs. Ett av dem är Selenium. Det är en av de viktigare lösningarna för Webperf som jag byggde på semestern 2018. Webperf är som många moderna IT-lösningar ett intressant exempel på automatisering, då detta är något självklart när utvecklare bygger något de inte vill ha onödig handpåläggning för. Webperf utvärderar hur bra webbplatser är som är viktiga för Sverige och då behöver man hämta innehåll från åtminstone 1600 webbplatser och kontrollera innehållet enligt ett gäng faktorer. Selenium låter mig hämta en webbplats så som den skulle presenterat sig för en mänsklig användare. Det senaste året har 350 000 tester körts mot dessa webbplatser. Tror du jag hunnit med detta som en kul grej på kvällstid om jag varit tvungen att göra nästan tusen tester varje kväll? Jag har jobb, fru, tvååring, torp och icke-tekniska hobbies. Nope, knappast…

Det är nämligen så att på webben är det här med mjukvaru-robotar extremt utbrett, och inte bara genom spammare eller hackare, bland annat genom alla sökmotorer som förstås behöver titta på de flesta webbplatserna med jämna mellanrum. Om något är en webbläsare med en människa vid skärmen eller ej är en särskild diskussion, men konceptet med användaragenter är bra att känna till. Det är väl lite som en vakt på krogen måste avgöra om en person har en falsk legitimation eller inte.

Egen automatisering

Webperf funkar på så sätt att det är ett Python-program som körs kontinuerligt i Terminalen (kommandoprompten, cmd.exe, för er på Windows) på min Mac Mini. Programmet anropar andra funktioner som den behöver, bland annat följande färdiga tjänster som:

  • Sitespeed.io via deras Docker-container, alltså ett sätt att låna program från andra, där det kommer information i Terminal-fönstret som jag gör data scraping på.
  • Yellow Lab Tools via deras Docker-container, men som blir en webbplats lokalt på min dator som jag sedan, likt Google mfl, kör webscraping på.
  • Webbstandardorganisationen W3C erbjuder tester på deras webbplats. Så där postas formulär över det jag vill testa och sedan webscraping från den publika webben (och inte något lokalt på min dator).
  • NodeJS paketsystem npm där jag, som helst undviker språket Javascript, kan ladda hem och “enkelt” använda andras resultat. För webperf handlar detta om pa11y-ci och axe-cli för att testa tillgänglighet.

Med andra ord, det jag med ganska begränsad ansträngning kombinerat/automatiserat är nyttan av följande grejer jag inte själv behärskar särskilt väl:

  • Javascript som programmeringsspråk
  • NodeJS och npm
  • Docker och de lösningar de listar på Docker Hub
  • Andras publika webbtjänster, som W3C och Webbkoll
  • Andras webbtjänster, som jag kan köra lokalt på min dator för maximal prestanda

Google och andra inom tech

Det Google och andra IT-företag gör genom att samla in all information från webben är ännu ett exempel på webbautomatisering. Ibland går de samman och föreslår webbstandarder för att göra livet enklare för sig själva, exempelvis schema.org

Och du som kollade på Google i/o i maj såg ett lager av automatisering av webbformulär så de kunde fyllas i enklare. Det kallas för Google Duplex och är en fortsättning på förra årets presentation där en maskin via telefon bokade in saker när det var en människa i andra änden. Snart kommer samma lösning även till webben där, åtminstone amerikaner, kan boka en hyrbil och biobiljetter.

Amerikanska bolag visar gärna exempel som har med att boka flyg, hyrbilar, restauranger och liknande att göra. Har de inte hört talas om flygskam och Greta Thunberg? Google is bringing Duplex to the web to help book car rentals and movie tickets - The Verge

Sammanfattat

  • RPA-botar är en “ful-integration” som imiterar människors användning av en dator, kanske därav att de ibland kallas för digitala medarbetare. En RPA-bot klickar runt i olika program precis som en människa skulle ha gjort.
  • En ESB är en plattform som knyter ihop trådar, men där en människa initialt agerar översättare mellan två eller fler system. ESB fokuserar på data.
  • Det finns flera andra lösningar på automatisering och integration.
  • Varken RPA eller automatisering är något nytt.

Mer om RPA och annan form av automatisering