Varje bra science fiction-berättelse har minst en robotbutler, en allvetande och allseende ande som kan få alla våra problem att försvinna på en sekund. De som myntade modeordet RPA – robotiserad processautomatisering, eller robotic process automation på engelska – försökte uppenbart spela på denna känsla. Kunder som köper in RPA-plattformar förväntar sig att kunna överlämna sina sysslor till en datorbutler så att människorna som finns kvar bland personalen kan koncentrera sig på de större utmaningarna.

Den goda nyheten är att det finns många exempel på att modeordet håller vad det lovar. Företag förenklar arbetsflöden och bygger sofistikerade instrumentpaneler som suger upp data och spottar ut användbara infografik. RPA-verktyg har visat sig vara framgångsrika när det gäller att göra det möjligt för datorn att utföra några av de mest betungande uppgifterna som irriterat alla i näringskedjan.

RPA-verktyg ger också äldre system nytt liv genom att lägga till ett nytt lager som kan manipulera den gamla koden på ett intelligent sätt och hjälpa till att förlänga livslängden. Många RPA-verktyg kan också användas av icke-programmerare, vilket ger dem som vet hur jobbigt det är att arbeta med äldre verktyg möjligheten att bara dra och släppa ikoner för att förbättra sina arbetsflöden. Välj rätt verktyg och implementering, och alla som kan skriva kalkylarkmakron kan effektivisera arbetsprocesser med RPA.

Magin är tydlig och ger en underbar fasad utan slit och slitage. Men under den blanka ytan som RPA lägger på dina system döljer sig flera problem som kan visa sig vara problematiska över tiden.

Det oundvikliga skjuts upp

En av de stora fördelarna med RPA är dess förmåga att bygga ett nytt lager för att klistra ihop äldre mjukvarupaket. Visst, du kan skriva om allt från grunden för att harmonisera det hela, men en bra RPA-lösning kan åstadkomma mycket av samma sak på mycket kortare tid. Det är den digitala versionen av häftmassa och ståltråd.

Detta tillvägagångssätt kan göra underverk. Produktivitetshöjningen kan vara fantastisk att se. Men du blir inte av med den äldre koden. Den dols bara djupare där den blir dammigare och konstigare.

Stöd för riktiga korrigeringar minskar

När det vackra RPA-skiktet fixar de störande momenten hos de som klagar mest är det en stor vinst. Men eftersom de djupare problemen inte har försvunnit, kan det lagande lagret ha ett annat dolt problem: Uppmärksamheten försvinner.

Tillfälliga korrigeringar som hjälper här och nu kan till och med skada alla ansträngningar att hitta budgeten för att fixa den äldre koden en gång för alla, eftersom ledningen slutar höra akuta klagomål. De kommer att anta att RPA:s lager av smink gjorde jobbet och de kan spendera sin budget någon annanstans.

Komplexiteten ökar

Den genomsnittliga användaren kanske tror att RPA-lösningen förenklar allt men under ytan blir allt lite mer komplicerat. Där det en gång fanns N lager av stökig kod finns det nu N+1 lager. Detta gör felsökning och underhåll så mycket svårare. När ett problem uppstår tvingas man gräva genom N+1 lager i hopp om att hitta felet.

Äldre buggar kvarstår

RPA-lösningar kan dölja den risiga äldre koden, men de kan inte fixa begränsningar eller buggar som finns djupt inuti. Den goda nyheten är att ett smart RPA-lager kan fånga upp några av de potentiella problemen. Ibland blir lösningen underbar och stabil. Ibland blir det som ett nytt lager färg på en ruttnande veranda.

Dataöversättningar kan stå dig dyrt

En hel del kodning kan ofta handla om att ordna om bitar för att passa ett dataformat som krävs av något bibliotek och sedan, när svaret kommer tillbaka, omorganisera bitarna igen för att lagra dem i ett annat format någon annanstans. En del av koden vill ha året först i datumet; en annan vill att året ska komma sist. Någon med tveksam humor skapade en gång Java-verktygen för att starta månadsmatrisen med noll så att februari är månad ett. Det första datumet i månaden är dock en etta.

Många RPA-stackar automatiserar några av dessa översättningar så att du inte behöver oroa dig för dem. Detta gör det lättare att bygga fungerande programvara, men det eliminerar inte det underliggande arbete som behövs för att utföra dessa oändliga översättningar. Servrarna måste vara mer kraftfulla och du betalar bokstavligen för all denna data, och med högre elräkningar. I många fall kan det här bara vara några ören, så det är inte värt att oroa sig för det. Men om du kör en stor verksamhet kan kostnaden för att skala upp bli väsentlig. Till slut kan det vara värt att anställa ett team av programmerare för att skriva ren, handgjord kod.

Dina ”superanvändare” har inte utvecklarkrafter

Alla från C-nivå till inhoppare kommer att kunna köra ett RPA-verktyg och åstadkomma något med bara lite jobb. Automatiseringen fungerar verkligen. Men även om de här superkrafterna är verkliga, kommer de inte med kunskapen att förstå hur man använder dem effektivt.

Programmerare känner till datastrukturer och de har redan tillbringat mycket tid på att få en känsla för det idiosynkratiska sättet som datorer kan balla ur av till exempel ett datum i fel format. Programmerare förstår nätverk och de förstår de grundläggande reglerna för dator- och systemarkitektur. Alla dessa kunskaper är ovärderliga när det gäller att koka ihop de olika besvärjelser som driver RPA.

Programmerare är fortfarande din bästa investering

Trots försäljningsargumentet att företagsanvändare kommer att bli dina RPA-implementatorer är programmerare fortfarande de mest effektiva användnarna av RPA-verktyg. De har många års erfarenhet av att arbeta på varje lager i stacken. De vet vilka frågor som kan besvaras snabbt av databasen och vilka kommer att vara fulla av JOINs som gör maskinen till sirap. Allt hår som de har slitit under åren har gett dem insikter om de bästa sätten att ställa frågor så att systemen ger givande svar.

Om RPA-verktygen är en kraftmultiplikator på, säg, 10x och du ger dem till en stjärnprogrammerare som redan levererar 10 gånger mer än den genomsnittliga kodaren, kan du se 100 gånger så stor leverans. Hävstången kan verkligen utnyttjas.

Bredden på stödet har sina nackdelar

De flesta RPA-verktyg lovar att de har gränssnitt till en miljard olika produkter som talar en miljard olika API-format. Påståendet är vanligtvis korrekt, men resultaten är ofta långt ifrån perfekta. RPA-leverantörer möter kraven på brett stöd, men denna bredd är svår att stödja och upprätthålla.

Det är till exempel vanligt att hitta buggar eller luckor i data som strömmar genom anslutningarna. Ibland kan datumet vara i ett udda format. Ibland kommer ”null” -resultat att krypa in. Det finns hundratals fel som dyker upp. Dessa kanske inte är katastrofala, men du kommer att lägga till ytterligare ett lager för att rensa upp misstagen eller kanske bara klara dig med enstaka hål.

Datorer kan inte ta bort all byråkrati

RPA-verktyg lovar att effektivisera arbetsflöden, men de flesta processflaskhalsar har inget att göra med datorer eller RPA. Steg läggs ofta till i arbetsflöden för att någon människa strulat till det - och ofta hände denna olycka för flera decennier sedan. Kanske någon på Kansas-kontoret förlorade en miljon dollar för att de inte fick rätt råd från Portland. Kanske visade någon praktikant sig vara en skurk.

Den bästa RPA-programvaran kan måla över en del av dessa problem, men inte bli av med dem. Om någon bestämde att teamet i Hongkong behövde godkänna alla fakturor, ja då kommer RPA-sviten bara att göra det lite enklare att visa dokumentationen för folket i Hongkong. Programvaran kommer inte att kunna klippa ut Hongkong-folket ur ekvationen. Den verkliga komplexiteten kommer från människor. Att luta sig för hårt mot RPA som en magisk lösning kan göra din organisation blind för det verkliga arbetet med att effektivisera dess processer.

För mycket automatisering kan vara farligt

Naturligtvis har många av de byråkratiska hindren i dina arbetsflöden placerats där av en anledning. En av de hemliga farorna är att en RPA-implementering kommer att påskynda saker till den punkt att problem kommer att segla förbi mänskliga övervakare som kommer att anta att RPA gör det tunga lyftet. De loggar in på sin instrumentpanel och går igenom sidorna medan de tittar på tv eller lyssnar på en podcast. Varför lägga tid på detaljerna om RPA-systemet kommer att flagga de konstiga fallen?

Det finns inget enkelt sätt att verkligen automatisera många av de svåra uppgifter som handlar om regelefterlevnad eller skydd mot bedrägerier. Skurkarna kommer att undersöka systemet och utnyttja varje liten svaghet i automatiseringen. Ibland måste det finnas viss friktion i systemet. Ibland är det ett misstag att göra saker för enkla.

Läs också: Sex fallgropar inom automatisering – så undviker du dem
Fyra sätt att nå snabb och säker automatisering