Vad RPA är, och när det är fel verktyg
4 min läsning
RPA står för Robotic Process Automation. Namnet låter mer avancerat än vad det är: en robot som styr musen och tangentbordet i era befintliga program, precis som en person hade gjort. Den loggar in, klickar sig fram, läser av rutor och skriver in värden i andra rutor.
Det låter primitivt, och det är det. Men ibland är det den enda vägen in.
När RPA är rätt
När systemet inte har något API. Gamla affärssystem, branschprogram och myndighetsportaler saknar ofta ett sätt att prata maskinellt. Då finns bara gränssnittet, och då är gränssnittet vägen.
När det som ska automatiseras är stort och stabilt. Ett moment som görs hundra gånger i veckan, ser likadant ut varje gång och inte kommer att ändras inom överskådlig tid. Där tjänar en robot in sig snabbt.
När leverantören inte tänker hjälpa till. Ibland finns ett API men det är låst bakom en partnernivå eller en avgift som inte står i proportion. Då är klickvägen en förhandlingsposition lika mycket som en teknisk lösning.
Varför vi oftast gör tvärtom
En robot som klickar i ett gränssnitt går sönder när gränssnittet ändras. Inte om, utan när. En knapp flyttas i en uppdatering, en dialogruta får ett extra steg, en lista laddar en halv sekund långsammare än förut. Roboten märker inte att något är fel. Den klickar på fel ställe och fortsätter som om allt gick bra.
Det är den verkliga kostnaden med RPA, och den syns inte i offerten. Den syns i förvaltningen, ett år senare, när någon upptäcker att fakturor legat fel i tre veckor.
Går samma sak att göra mot ett API eller direkt mot en databas är kopplingen inte bara stabilare. Den märker också när den misslyckas, för då kommer det ett felmeddelande i stället för ett tyst fel.
Vår ordning är därför alltid densamma: API om det finns, databas eller filexport om det inte gör det, och klickvägen sist.
Frågan att ställa en leverantör
Om någon föreslår RPA, fråga varför de inte går mot API:et.
Får ni svaret att det inte finns, be dem visa var de letat. Vi har fått höra "det går inte att integrera" om system som haft ett fullt dokumenterat API hela tiden. Ibland stämmer det förstås, och då är det bra att veta att det kontrollerats.
Fråga också vad som händer när systemet uppdateras, och vem som betalar då.
Det som ofta är det egentliga svaret
Många uppdrag som börjar som "vi vill automatisera det här" slutar inte i en robot alls. De slutar i att två system får prata med varandra, eller i att ett kalkylblad ersätts av något som räknar rätt av sig självt.
Det som beskrivs som ett automatiseringsproblem är påfallande ofta ett integrationsproblem, och integrationer går sällan sönder av en flyttad knapp. Mer om hur vi går till väga står på sidan om automatisering.
När vi säger nej
Om flödet ändras varje månad. Då fastnar ni i ändringar i stället för i det manuella arbetet, och har bytt ett problem mot ett dyrare.
Om momentet tar tio minuter i veckan. Räkna på det innan ni beställer: åtta timmar om året är sällan värt sextio tusen kronor och ett beroende till.