RPA - köpa som tjänst eller inte?

Automatisering och robotic process automation (RPA), är något som många pratar om och som allt fler vill investera i. Det är inte konstigt i och med att många fördelar kan uppnås, såsom kostnadsbesparingar, effektivisering och en förbättrad arbetsmiljö när repetitiva arbetsuppgifter flyttas från medarbetarna. I princip alla delar av verksamheten kan dra nytta av RPA – T.ex. HR med kontroller och uppdatering av masterdata i olika källsystem. 

Automatisering och robotic process automation (RPA), är något som många pratar om och som allt fler vill investera i. Det är inte konstigt i och med att många fördelar kan uppnås, såsom kostnadsbesparingar, effektivisering och en förbättrad arbetsmiljö när repetitiva arbetsuppgifter flyttas från medarbetarna. I princip alla delar av verksamheten kan dra nytta av RPA – T.ex. HR med kontroller och uppdatering av masterdata i olika källsystem. 

Potentialen med att automatisera processer är generellt sett väldigt hög, men de positiva effekterna kommer inte per automatik. Det är viktigt att lösningen implementeras på rätt plats och hanteras på rätt sätt för att kunna dra nytta av de potentiella positiva effekterna. Men hur ska man avgöra vad som är rätt? 

När verksamheten är ny inom RPA konfronteras man med beslutet om hur RPA-satsningen ska genomföras. Ska man låta en leverantör hantera infrastruktur och utveckling? Ska man i stället bygga upp detsamma med sin egen IT-enhet? Eller kanske göra en hybrid? Alla tre valen är möjliga och kan vara den lösning som passar din verksamhet bäst. Läs mer om automation inom IT-infrastruktur här.

Vilka viktiga saker finns att tänka på inför att välja mellan RPA on-prem eller att köpa RPA som tjänst eller en hybrid – Vad är rätt för just min verksamhet? 

Det finns ett antal betydelsefulla faktorer som kan hjälpa oss svara på den frågan. Nedan beskrivs dessa utan rangordning, men där tyngdpunkten kan variera utifrån just den egna verksamhetens förutsättningar 

• Stödet från egen IT- organisation 
  Hur ser stödet ut från den egna IT-organisationen? Ser de RPA som en möjlighet att göra något nytt och vara delaktiga i eller är det mer ett avvaktande och ”- Vi har inte tid” svar, eller kanske rentav ett ”- Nej, det vill vi inte hålla på med”. Är det något av de två senare alternativen har vi en stark faktor som pekar på att inte göra en egen lokal infrastruktur. Design, byggande och drift av en RPA-miljö som klarar normala verksamhetskrav kommer behöva stöd från IT. 

• Hur stor är organisationen och hur ambitiösa är vi? 
  Om vi tänker oss en målsättning med en produktionsmiljö med 10-20 % och några få robotar så håller vi oss inom en omfattning där det inte finns något stort behov av flexibilitet kapacitetsmässigt. Flexibiliteten är en av de stora fördelarna med leverantörernas molnplattformar. Läs mer om vikten av rätt molnstrategi här.

  Tänker vi istället att målet är en stor global enterprisemiljö med 300-400% och många robotar i en diversifierad organisation är både on-prem och Saas möjliga bra svar. Det som händer i en så stor miljö är att man ser ett behov av en mycket aktiv förvaltning av de applikationer som är installerade på robotarna (alltid saker som måste uppgraderas och patchas). 
   
  Detta görs ofta enklare i en on-prem miljö där man har kontrollen själv i stället för att behöva förlita sig på en leverantör som kanske måste jobba mot en annan applikationspartner för att kunna göra uppgraderingen. Schemaläggning av processer är en annan sak som har stor betydelse och det blir enklare ju närmare man sitter verksamheten. 

• Kan vi ha egna utvecklare 
  För att bygga och förvalta verksamhetsprocesser är det viktigt att bygga relationer och förtroende med verksamheten. Om det inte finns kommer de inte vilja eller våga automatisera fungerande verksamhetsprocesser. 
   
  Detta görs enklast om man har egen personal som sitter nära verksamheten. I jämförelse kan man ställa en extern tjänst med verksamhetsanalytiker och utvecklare, och där man antagligen stöter på nya personer varje gång man önskar få något gjort. Väljer man en extern tjänst kommer detta att kräva mycket aktivt arbete för att fungera, både som kund liksom för leverantören.  

• Vilken typ av information ska behandlas? 
  Att informationsklassificera den information som ska behandlas är av avgörande betydelse. Är informationen av sådant värde att det inte är lämpligt att lämna den till en extern leverantör så är man förvisad direkt till att bygga något eget. 
   
  Eftersom det är verksamhetsprocesser som automatiseras så behöver man säkerställa att verksamhetens krav återspeglas på den tjänst man använder. Uppfylls alla dessa? Har vi brister så kommer man troligen vid något tillfälle att få lida för det. 

• Har vi legala krav att ta hänsyn till? 
  Att klargöra legala krav på den information som kommer behandlas är ett grundläggande steg som helt kan avgöra vad som är möjligt att göra. Myndigheter har speciellt många lagkrav som styr hur de ska arbeta och vad de får göra. 
   
  Att använda RPA i molntjänster kan vara direkt omöjligt utan att bryta mot legala krav. Privata organisationer har andra förutsättningar men även här måste legal hänsyn styra – även om i mindre omfattning. Dataskyddsförordningen är ett exempel som så gott som alla berörs av.  

• Vilken kostnadsbild är mest fördelaktig? 
  Detta beror i mångt och mycket på målbilden. Exempelvis, hur många automatiserade verksamhetsprocesser tror vi att det finns ett behov av? Pratar vi ett 10-tal? 100? 200? Mer ändå? Med många processer kommer det finnas ett behov av flexibilitet, och då inte enbart i antal robotar som kan tas fram. 
   
  Detsamma gäller för vilka applikationer som måste supportas och vilken information som kan behandlas i lösningen utifrån verksamhetens kravbild på konfidentialitet, integritet och tillgänglighet. 
   
  Bilden blir mycket mer komplex än vad som visas i en enkel beräkning baserad på antal robotar. Implementationskostnader verkar ibland frestande låga när man köper RPA som tjänst, men det är i driftskostnader över tid som ackumuleringen av kostnadsmassa sker. Och detta är avhängigt på ambitionsnivån. Det blir därmed helt avgörande att förstå denna för att kunna göra prognoser av kostnad över tid och jämföra alternativen på ett rättvist sätt. Det går självfallet att migrera mellan on-prem till tjänst eller tvärtom, men det är ett tecken på att man inte förstod målbilden ordentligt. 

• Verksamhetskunskap 
  Alla processer som automatiseras kommer fortfarande att behöva ägas och förvaltas av verksamheten. RPA-teamet tar inte över detta bara för att en robot utför arbetsmomenten. En konsekvens som blir tydlig relativt snabbt är att kunskaper om verksamhetsprocesser snabbt blir sämre hos verksamheten när de inte längre själva utför den.  
   
  På lång sikt kan konsekvensen bli att kunskaperna om vissa verksamhetsprocesser nu främst befinner sig utanför den egna organisationen och i stället hos verksamhetsanalytiker och utvecklare hos en leverantör. Och ju fler processer man automatiserar desto större blir denna effekt. Den kommer inte att märkas första året, men däremot år 2 och 3 kommer den framträda.  

• Inlåsningseffekt 
  Har man lagt tusentalstimmar på att automatisera processer i ett visst verktyg eller tjänst så är det ett stort arbete att flytta det till något annat. Förutom den rent tekniska biten så kommer även den organisation och de relationer man byggt upp att behöva förändras. Det finns en stark inlåsningseffekt när man väl byggt upp volym. Det är lätt att ändra sig men svårt att genomföra i praktiken. 

• Säkerhet 
  Att upprätthålla en tillräcklig säkerhetsnivå i RPA-lösningar är ett steg som ofta förbises. Som för alla IT-system och tjänster finns dock samma krav på detta. Utifrån informationsklassning av behandlad informationsmängd klargörs värdet som det har i verksamheten, vilket i sin tur utgör grunden till vilka skyddsåtgärder som är rimliga att sätta på plats. Givetvis klargör man också i detta steg möjliga legala begränsningar (vilket vi redan berört).  
   
  När det gäller behandling av personuppgifter finns också tydliga krav i dataskyddsförordningen på att beskriva denna i en registerförteckning samt att göra konsekvensbedömningar när det finns en risk för den registrerade i och med behandling av dennes personuppgifter. Det här kräver en systematisk insats men prioriteras ofta bort. 

• Flexibilitet 
  Det finns olika typer av flexibilitet. I Saas-tjänster är det enkelt att förändra kapacitet i antal robotar och antal utvecklingsmaskiner, medan man i en on-prem lösning kan modifiera alla delar av sin infrastruktur om man tycker det ger fördelar. Det finns en styrka i att standardisera, men ibland krävs undantag för att möjliggöra effektiva lösningar. Målbilden är vad som kan avgöra vad som är bäst för organisationen.  

• Ny funktionalitet 
  Machine Learning, AI och andra nya funktioner är något som först kommer att finnas tillgängligt i molntjänster. Att supporta detta med egna resurser i en on-prem lösning kräver en stor organisation och kommer därmed inte vara ett alternativ för många om man inte väljer just en molntjänst. I detta område kommer det finnas funktionalitet i framtiden som skapar nytt värde i organisationen och det blir därmed en tung faktor när valet om att köpa RPA som en tjänst eller inte. Läs mer om varför en molnstrategi behövs här.

• Samverkan med verksamheten 
  Kommunikation med verksamheten är en tydlig framgångsfaktor. Lyckas man bra här är mycket åstadkommit. Det motsatta förhållandet gäller också. Eftersom det är verksamhetens processer som går i RPA-lösningen kommer det hela tiden finnas ett starkt behov från verksamheten att kunna följa och förändra sina processer. Ofta önskar de att det ska ske med kort framförhållning och kommunikation från supportteam, utvecklare och ledare blir helt avgörande för om RPA-lösningen kommer upplevas som en tillgång eller ett hinder 

Summering 

Många väljer att köpa RPA som tjänst och det finns som sagt många fördelar med det, men det är inte rätt val för alla. Det bästa man kan göra är att förstå sin målbild med RPA, då det är avgörande för att kunna göra ett klokt och överlagt val. Man kan givetvis alltid ändra sig under vägen, men om man byggt en viss volym kommer snabbt inlåsningseffekter som kräver mycket arbete att hantera. Den tid man lägger i början på att göra ett bra val kommer att betala sig över tid. Det kan dock vara svårt att själv hitta vilka frågor som bör besvaras och här kan Midagon använda sin erfarenhet för att göra det för just din organisation. 

Vill du veta mer? Kontakta gärna oss på Midagon här så berättar vi mer.