Robotic Process Automation (RPA) komt het beste tot zijn recht als een integraal onderdeel van Lean. Dit stellen John Maes en Jeroen Schijns, de schrijvers van Lean Robotics.

Hoewel RPA-oplossingen domme administratieve robots zijn, raakt het gebruik ervan hele waardeketens. Daarom is een slimme en slanke (Lean) organisatie nodig voor de toepassing van RPA.

Lean Robotics is een helder boek met veel tips. Wél een kanttekening: je kunt volgens mij het beste éérst Lean worden. Zo doe je alvast ervaring op met multidisciplinaire verbeterteams, die je dan later kunt aanvullen met RPA-specialisten. Door eerst Lean te worden beperk je bovendien het aantal software-robots, en daarmee ook het beheer daarvan.

De titel Lean Robotics zette mij aanvankelijk op het verkeerde been. Ik verwachtte een boek over robotisering in de maakindustrie, en vroeg me vervolgens af of de expertise van de auteurs daarbij wel aansloot.

John Maes en Jeroen Schijns werken namelijk binnen het Lean Excellence Center van de Rabobank. John als vice-president, en Jeroen als bedrijfsinterne Lean Robotics-consultant.

Software-robots
Beide schrijvers werken dus in een financieel-administratieve omgeving. Dat is echter geen probleem, want hun boek gaat over software-robots. Dit zijn programmaatjes, die administratieve taken voor hun rekening nemen. En dan niet via gangbare automatisering, maar via Robotic Process Automation (RPA).

Wat is het verschil, hoor ik u denken!

Macro
Een keiharde definitie van RPA is er niet. Wellicht heeft u echter wel eens een Macro in Word of Excel ingesteld. De volgorde van je toetsaanslagen wordt daarbij opgenomen. Daarna kun je dezelfde handelingen automatisch afspelen, wanneer je maar wilt. Je zou dus kunnen zeggen dat je dan een robotje opstart. Dit is nog geen RPA, want macro’s kun je alleen instellen binnen één applicatie. Er bestaat echter software waarmee je hetzelfde op een applicatie-overstijgende manier kunt doen. Dat is wél RPA.

Domme taken
Met RPA-software kun je software-robots bouwen, die daarba ‘domme’ taken automatisch voor je uitvoeren. Denk aan een robot die gegevens kopieert van de ene naar de andere applicatie, iets wat in ziekenhuizen bijvoorbeeld vaak nodig is. Of denk aan een robot die gegevens van de Kamer van Koophandel voor je ophaalt, of de kredietwaardigheid checkt van mensen die een hypotheek aanvragen. Een ander voorbeeld is een robot die inventariseert wat de prijzen van artikelen op de websites van uw concurrenten zijn, en die vervolgens uw eigen prijzen aanpast.

Voorspelbaar verloop
Om de mogelijkheden van RPA te vergroten, kan uw ICT-afdeling een stukje ‘gewone’ automatisering toevoegen. Daarna kan een software-robot dan méér dan enkel het gedrag van een mens simuleren, via een serie van muiskliks en toetsaanslagen.

Het blijft bij RPA echter altijd gaan om een stapsgewijs programmaatje met een voorspelbaar verloop. RPA is dus geen denkende robot, die zich aanpast aan nieuwe situaties. Het zou daarom op zijn minst handig zijn als zo’n robot veranderingen in de onderliggende applicaties herkent en dan alarm slaat. Een beheerder kan daarna checken welke aanpassingen nodig zijn.

Op termijn zou RPA kunnen evolueren naar artifical intelligence. Daar gaat het boek echter niet over.

Saaie handelingen
In bijna elke organisatie, óók als dit een productiebedrijf is, bestaan er veel saaie administratieve handelingen, die frequent terugkeren. Sommige van die handelingen zijn in feite verspilling van tijd en capaciteit. Een berucht voorbeeld is het ‘overkloppen’ van data van de ene naar de andere applicatie. Zoiets kun je met reguliere automatisering oplossen, waarbij je bijvoorbeeld overstapt naar een centrale database. Zo neem je de root cause van het probleem weg, maar dat vergt wel een forse investering.

RPA is een goed alternatief. Als je al RPA-software hebt, dan kost zo’n oplossing namelijk bijna niets. Ook maakt het de desbetreffende processtap in principe nagenoeg foutloos. Daar kun je tegen inbrengen dat een zinloze taak nu blijft bestaan. Iets wat een software-robot doet, kan echter nauwelijks als verspillend worden gezien.

Bovendien zijn er ook veel repeterende activiteiten die wél waardetoevoegend zijn, en die je op soortgelijke wijze kunt robotiseren.

Geen programmeerkennis
Ook kan RPA een dienst voor een klant 24 uur per dag beschikbaar maken. De capaciteit is bovendien schier eindeloos. Dit maakt extra dienstverlening mogelijk, zoals het versturen van updates via e-mail of whatsapp over de status van bijvoorbeeld een hypotheekaanvraag.

Een RPA-applicatie bouwen is volgens Maes en Schijns erg makkelijk. Je hoeft er geen programmeerkennis voor te hebben.

Er zijn dus én veel toepassingsmogelijkheden, én die liggen voor het oprapen, zo lijkt het!

Proof of concept
Maes en Schijns zijn daarom erg enthousiast over RPA. Toch geven zij óók een waarschuwing af: er komt veel meer bij kijken dan je denkt.

Een proof of concept (PoC) is snel geleverd: je bouwt zo’n robot, en dan blijkt ongetwijfeld dat die de betreffende taak veel sneller uitvoert dan een mens. Dat zegt echter niet zo veel.

Het kan bijvoorbeeld zijn dat je een activiteit hebt gerobotiseerd, die je beter helemaal niet zou kunnen hebben. Daarom kun je beter éérst een value stream map maken van het proces dat je wilt verbeteren, en zo overbodige stappen opsporen en uit het proces halen.

Ten tweede omvat RPA meer dan het automatiseren van één stap. Die staat immers niet los van de overige werkzaamheden.

Is een administratieve productieketen Lean, dan moet de hele keten na de introductie van RPA opnieuw worden gebalanceerd. Je hebt immers niets aan een robot die heel snel werkt, maar daarmee enkel tussenvoorraad genereert. Ook verandert de inhoud van het werk. Daar moeten dus nieuwe werkstandaarden voor worden ontwikkeld.

Andere taken
Je moet ook goed nadenken over wat je doet met de vrijgekomen capaciteit. Welke andere taken kunnen mensen oppakken, als een deel van hun werk wordt overgenomen door RPA? Als het goed is verdwijnen vervelende en repetitieve handelingen. Dat vergroot dan het werkplezier, en werknemers kunnen de vrijgekomen tijd inzetten voor betere dienstverlening. Het kan echter ook zijn dat sommige mensen hun baan verliezen, vooral als zij niet zijn voorbereid op de meer uitdagende taken die resteren. Tenslotte is een plek die wordt ingevuld door RPA in feite een gewone, zij het nu virtuele, werkplek. Die vraagt dus ook om beheer, en om continu aanpassen en verbeteren.

Kortom: RPA raakt zowel de processen, het management, de organisatie alsmede de taakverdeling.

Procesmanagement
Alle reden dus om RPA te positioneren als een onderdeel van procesmanagement en Lean. Dit verklaart meteen de titel van het boek, Lean Robotics.

Maes en Schijns pleiten voor een holistische benadering, waarbij RPA een integraal onderdeel wordt van Lean. RPA geeft je dan een extra mogelijkheid om verspilling in waardeketens te reduceren, niets meer en niets minder. Een mens iets laten doen wat een software-robot kan, wordt daarbij ook gezien als verspilling.

Intrigerend is, dat je zo breekt met een gangbare gedachte binnen Lean. Die verbetermethode beschouwt mechanisering en robotisering namelijk meestal als last resort. Je begint er pas mee als de verbetermogelijkheden zijn uitgeput. Zo voorkom je onnodige investeringen in dure machines.

RPA verschilt echter op twee aspecten van gewone robotisering: de kosten zijn laag, én het maakt niet uit of een RPA-robot een op papier verspillende taak uitvoert. Een softwareprogrammaatje laten draaien kost namelijk nauwelijks energie, én RPA wordt nooit moe.

Eerst Lean
Maes en Schijns pleiten er voor om Lean en RPA hand-in-hand toe te passen. Bij verbeterprojecten hanteren zij de bekende volgorde: eerst elimineren (van verspillingen), dan simplificeren (van processtappen), dan standaardiseren en tenslotte robotiseren.

Ik zou echter een stap verder willen gaan: volgens mij kun je het beste éérst Lean worden, en daarna pas Smart Industry technieken zoals RPA gaan inzetten. Waarom? Omdat je RPA dan alleen gebruikt waar dat echt nuttig is.

Dat lijkt misschien strijdig met het idee dat het weinig uitmaakt of een software-robot al dan niet een waardetoevoegende activiteit uitvoert. Er is volgens mij echter alle reden om het aantal robots zo veel mogelijk te beperken. Het liefst vervangt zo’n robot bovendien één werkstation (schakel) in een waardeketen. Dan hoef je die keten namelijk niet opnieuw te balanceren qua werkbelasting.

Willekeurige adverteerder gekozen uit de categorie: Lean

KSL Solutions

KSL-Solutions is een team van 7 specialisten in operationele strategie en daarmee in het significant verbeteren van prestaties van de operationele organisatie in de maak- en procesindustrie.

Naast het leren en trainen van verbetertools mensen ook te inspireren en te laten snappen waarom ze wat doen, waardoor verbeteren een intrinsieke motivatie wordt, dat is de kunst en bij ons een basisvoorwaarde.

Een autonome verbeterorganisatie neerzetten met blijvende resultaten, dat is waar wij voor staan. Dat is onze missie!

> Naar website

> Toon andere adverteerders in de categorie Lean

Zo min mogelijk
Waarom zo min mogelijk software-robots? Omdat dit ook minder beheer betekent. In het boek wordt niet ingegaan op de veiligheid van RPA. Dat vind ik een omissie. Als je bijvoorbeeld een RPA bouwt die gegevens ophaalt van een externe website, dan loop je al gauw het risico dat je ook de omgekeerde route openzet. Een hacker komt dan gemakkelijk jouw bedrijfsnetwerk binnen. De betreffende RPA moet immers permissie hebben om het internet te bezoeken, en is vervolgens ook nog eens geautoriseerd om daarna bijvoorbeeld een ERP-systeem te benaderen.

Ook als je aanneemt dat je voldoende security inbouwt, dan nog is er alle reden om te waken voor wildgroei van software-robots. RPA mag dan volgens Maes en Schijns geen automatisering heten, het ís dit in feite wel. Feitelijk is elke RPA-oplossing een stukje maatwerk, zij het geprogrammeerd in een hogere programmeertaal waardoor je geen code hoeft te schrijven. RPA is daardoor eenvoudiger maatwerk, en maatwerk dat je zelf kun aanpassen. Het is echter wel nog steeds maatwerk.

Dit brengt dezelfde probleem met zich mee als bij elke maatwerksoftware. Bij elke update van één van de applicaties die een RPA-oplossing gebruikt, moet worden gecheckt of dit gevolgen heeft voor het functioneren van de betreffende robot. Het boek noemt dit probleem terloops wel. Het stelt ook dat er een robot-eigenaar moet zijn, en een goed ITIL-proces voor het afhandelen van storingen. Mijns inziens moet je die storingen echter zo veel mogelijk vóór zijn. Dat lukt het beste als er zo min mogelijk te beheren robots zijn. Die situatie krijg je, als je eerst geruime tijd enkel Lean toepast.

DevOps-team
Je hebt dan ook het voordeel dat je al kunt wennen aan multidisciplinaire ‘Kaizen’-verbeterteams, die processen stapsgewijs verbeteren. Later wordt RPA dan tijdens de value stream mapping, waarbij je probeert overbodige stappen uit het proces te halen, gewoon een extra optie. Een taak die wordt uitgevoerd door een mens, maar die een robot ook en beter kan, wordt vanaf dat moment ook gekenmerkt als verspilling. Zelfs als de betreffende activiteit waarde-toevoegend is.

In het verbeterteam moeten daartoe dan wel IT- en RPA-specialisten worden opgenomen, zodat duidelijk wordt welke IT-autorisaties de te bouwen robots nodig hebben. Ook kunnen deze experts er voor zorgen dat het Kaizen-team de mogelijkheden van RPA realistisch inschat.

Maes en Schijns willlen de bouw en het beheer van de robots vervolgens laten doen door een development/operations team. Oftewel een DevOps-team in Scrum-terminologie. Het Scrum-team trekt daarbij steeds een ‘sprintje’ zodat functionaliteit stapsgewijs wordt opgeleverd. Het Lean-team geeft na elke sprint feedback, zodat eventuele aanpassingen tijdig kunnen worden doorgevoerd.  Voor het uitvoeren van eventuele IT-aanpassingen kunnen zondodig aparte sprints worden ingepland.

Herbruikbare stukjes
John Maes en Jeroen Schijns zijn soms wel érg positief over de mogelijkheden van RPA. Zo stellen zij dat je een bibliotheek kunt aanleggen met herbruikbare stukjes software, zónder te vermelden dat zoiets veel voeten in de aarde heeft. Als je dit wilt, dan moet je bijvoorbeeld steeds goed in kaart brengen welk programmaatje generiek toepasbaar is, en met welke randvoorwaarden. Door hergebruik maak je programmaatjes bovendien afhankelijk van elkaar, en dat stelt extra eisen aan het beheer ervan. Mensen die in de voedingsmiddelenindustrie werken met variaties van recepten zullen deze uitdaging herkennen.

Ook over sommige toepassingen van RPA is het boek erg optimistisch, Neem bijvoorbeeld het automatisch inlezen van factuurgegevens. Een leesbare pdf zou daartoe volstaan. Mijns inziens lukt het inlezen van facturen echter alleen als die allemaal voldoen aan een standaard zoals EDI.

Helder boek
Ondanks de bovengenoemde kanttekeningen vind ik Lean Robotics een helder en vlot lezend boek. Het zet alle aspecten rond RPA, inclusief de organisatorische, goed uitéén. Het boek is daardoor een blauwdruk of stappenplan voor de toepassing van RPA. Van voorbereiding tot de planning: welke processen bieden het grootste besparingspotentieel door de inzet van RPA. En van de uitvoering door multidisciplinaire verbeterteams, tot het beheer en het verandermanagement.

De vele (hoewel helaas geanonimiseerde) case-bedrijvingen die in kaders zijn toegevoegd, dragen bij aan het heldere betoog. Ik kon uit deze cases veel tips halen, waarvan ik er een aantal in een kader aan dit artikel heb toegevoegd. Wie meer van dit soort tips wil, leze het boek!