Zucht … het is weer eens zover. Dat het (IT-)project in de “escalatie-fase” zit is niet volgens plan, maar wel volgens verwachting. Achteraf wist iedereen dat het fout zou gaan en dat de planning te krap was voor de gewenste verandering. De stuurgroep en de projectmanager dachten vooraf dat, eenmaal onderweg, alles maakbaar zou zijn. Alleen blijken de besluitvorming en veranderprocessen net zo stroperig als normaal. Ondanks dat het project prioriteit heeft. De ambitie en drive van de initiators leven niet bij de medewerkers, die juist nog harder moeten werken. De beste mensen waren al overboekt en alles heeft prioriteit. De “sense-of-urgency” in de organisatie is, net als het communicatieplan, een papieren tijger. Enorme bakken met geld en tijd worden verspild met overleg, escalaties en alignment, zonder enig positief effect op de voortgang. Medewerkers worden ziek en de performance van de organisatie holt achteruit. Conclusie van het management is dat “onze eigen medewerkers niet deugen, of het werk niet aan kunnen” en dus wordt er nog maar een blik extra externe consultants opengetrokken.

Met regelmaat praat ik met vrienden en collega’s over hun werk. Het begint altijd positief en eigenlijk zou je na twee minuten het volgende onderwerp aan moeten snijden, want daarna begint bovenstaande klaagzang. Wat opvalt is dat, zo goed als in elk werkgerelateerd gesprek, IT en verandering negatieve thema’s zijn. IT wordt nog steeds als breekijzer gebruikt om mensen en organisaties te veranderen, ondanks dat ervaren professionals de gevaren hiervan kennen en de ervaring hebben dat dit zelden goed afloopt. In dit tweede stuk over software robots (Robotic Process Automation en/of Intelligent Process Automation) gaan we daarom verkennen of je organisatie klaar is voor RPA/IPA, of de software robots in je IT landschap gaan passen en wat er gedaan kan worden om te zorgen dat RPA/IPA beheersbaar blijft. Kortom: hoe voorkom je dat RPA/IPA op een teleurstelling uit loopt?

Introductie van software robots is geen IT-project

Het introduceren van software robots is geen IT project. Het is een business en HR project, waarbij nieuwe elektronische medewerkers geacquireerd worden. Deze nieuwe medewerkers hebben een functie, moeten voldoen aan de spelregels van de administratieve organisatie en security en ze moeten ingewerkt worden. Als brandjes blussen bijna fulltime gebeurt en er zelfs functies op gebaseerd zijn, wordt het moeilijk om robots te introduceren die brandjes voorkomen. Complexiteit schept belang en expertise levert status op. De medewerkers die aanzien als brandweermannen opgebouwd hebben of die het middelpunt zijn van vraagstukken die alleen zij kunnen oplossen, vanwege jarenlange ervaring met de eigenaardigheden van het IT-landschap, vormen vaak een enorm obstakel voor veranderingen. Dit zal eerst geadresseerd en overwonnen moeten worden, voordat ook maar gedacht kan worden aan veranderen. Niet alleen zullen zij een rol moeten spelen bij de introductie van RPA/IPA, maar ook moet nagedacht worden over hun veranderende rol als gevolg hiervan. RPA/IPA verandert functies en rollen en dat betekent in bijna alle gevallen dat medewerkers (ook via de ondernemingsraad) betrokken moeten worden bij vragen als: hoe ziet het nieuwe systeem inclusief robots er uit? Verschuiven rechten, plichten en verantwoordelijkheden? Hoe worden de nieuwe medewerkers aangestuurd?

Elke organisatie die RPA/IPA wil introduceren raad ik aan om bij de organisatorische verandering te beginnen. Verken het ecosysteem samen met de medewerkers en zorg dat ze niet overpowered maar empowered worden. Begin niet met een financiële businesscase, die is van latere zorg. De beste businesscase is niet die ene met het hoogst geplande financiële gewin, maar het plan met de beste kans op succesvolle implementatie. Nummer één zorg is dan ook: zorg dat de medewerkers gecommitteerd zijn aan de verandering, anders wordt de implementatie een tranendal.

Stap 1: Heeft jouw bedrijf RPA/IPA nodig?

Stel, de eerste horde is genomen. De organisatie heeft besloten dat een test met software robots zinvol is en de medewerkers zijn meegenomen en gecommitteerd. Maar past RPA/IPA technisch en organisatorisch in het IT-landschap? Is het nodig en waar?

In een goed geautomatiseerd en flexibel landschap zullen software robots weinig toegevoegde waarde leveren. Aan een goed functionerend informatie-ecosysteem voegt RPA/IPA geen businessfunctionaliteit toe. RPA/IPA faciliteert dat businessprocessen sneller en met minder fouten verlopen en kwalitatief betere informatie opleveren. Als de businessprocessen al optimaal zijn, heeft introductie van RPA/IPA weinig nut. Je kunt het RPA/IPA potentieel te meten met het beantwoorden van de volgende vragen:

Stap 2: Past RPA/IPA in je IT landschap?

Als blijkt dat inzet van RPA/IPA zinvol kan zijn, stel jezelf dan de volgende vragen: past het in mijn landschap? Zo nee, wat moeten we doen om het passend te maken?

Voor antwoorden zijn interviews met materie- en procesdeskundigen nodig die samen met IT-professionals het informatielandschap verkennen . Door o.a. het beantwoorden van bovenstaande vragen wordt een eerste beeld gecreëerd van het laaghangend fruit. Het gaat initieel vooral over het automatiseren van processen door het inzetten van RPA/IPA. Procesoptimalisatie door proces redesign is hier (nog) niet aan de orde; het proces blijft in grote mate hetzelfde, maar wordt “handsfree”. Het businessproces dat vaak de beste kandidaat lijkt, is Procure-2-Pay. Dit heeft veel gebruikers en transacties en wordt over verschillende afdelingen door meerdere systemen bediend. De complexiteit van dit proces wordt echter vaak onderschat. Zelfs als het een goede kandidaat is, zou ik willen aanraden om te beginnen met een kleiner en simpeler proces. Een proces met maximaal drie verschillende systemen, waarin bijvoorbeeld mail, Excel en veel handmatig werk gebruikt worden. Informatiekwaliteit in processen gaat vaak verloren als via deze wegen informatie wordt doorgegeven. Deze zogenaamde “draaistoel integraties” zijn analoge overdrachtspunten en per definitie gaat informatie en context verloren en/of verliest de informatie integriteit.

Het IT landschap in je organisatie moet aan de linker voorwaarden voldoen om de inzet van RPA/IPA zinvol te laten zijn:

Als je niet op elke voorwaarde kan zeggen: “Ja, dit is aanwezig.”, dan is er werk aan de winkel. Een grootschalige RPA/IPA introductie is nog niet mogelijk. Echter experimenteren en kleinschalige introducties kunnen helpen om bovenstaande horden sneller of weg te nemen. Een voorbeeld is RPA/IPA inzetten om de datakwaliteit te verhogen in een deel van een proces met veel overdrachtspunten. Robotiseer één overdrachtspunt per keer en finetune dit om het vak te leren.

Stap 3: Hoe kies je een oplossing?

We zijn nu zover dat de organisatie overtuigd is van het nut en de noodzaak van RPA/IPA. De medewerkers zijn gecommitteerd en we hebben een proces gekozen dat past binnen de capabilities van de RPA/IPA functie. Maar hoe kiezen we nu een oplossing? Ik ga in dit stuk geen productvergelijkingen doen. Gezond verstand is een superpower, d.w.z. koop of huur geen Rolls Royce als het met een fiets ook lukt. “To SAAS or not to SAAS” hangt af van het vertrouwen dat uw organisatie heeft in extern gehuisveste applicaties, maar is op dit moment nog van secundair belang en biedt geen onderscheidend vermogen omdat er genoeg aanbieders zijn die beide kunnen. Ook geld speelt in eerste instantie een ondergeschikte rol, begin met een proef of gratis editie. Twee belangrijkere vragen gaan we eerst beantwoorden.

Is de tool intuïtief in gebruik? Er is geen andere manier om daar achter te komen dan simpelweg meerdere tools proberen. Het is aan te raden hiervoor een multifunctionele groep te maken met zowel IT-professionals als business experts. Bij tools die weken opleiding vergen zouden op zijn minst de wenkbrauwen gefronst moeten worden.

De tweede vraag is: wat is de technische impact op het IT landschap op de lange termijn? Met andere woorden, hoe gracieus veroudert alles dat met RPA/IPA gemaakt wordt en wat is het exit-scenario? Om dat te beantwoorden is een combinatie van solution architecture expertise en business expertise nodig. Zo kan de technische impact en de ontwikkeling van de businessbehoefte worden geplot op IT en op de RPA/IPA capability. Het landschap mag niet op slot schieten door hogere complexiteit of introductie van meer harde afhankelijkheden tussen systemen. In plaats daarvan zouden losse koppelingen eenvoudige exit-scenario’s mogelijk moeten maken.

Stap 4: Co-creatie in het voortbrengingsproces

De laatst stap voor de introductie van RPA/IPA is het inrichten van het voortbrengingsproces, d.w.z. het proces waarmee businessprocessen geselecteerd en met RPA/IPA geautomatiseerd worden. Ook hier is co-creatie belangrijk. Technische vraagstukken zijn relatief makkelijk op te lossen. Maar zoals in het begin van dit stuk gemeld is de introductie van RPA/IPA geen IT-project. Net zoals er niet zonder reden nieuwe medewerkers aangenomen worden, dient er een goede reden te zijn om een software robot “aan te nemen”. De manier waarop dat gebeurt verschilt met die van menselijke medewerkers. Het nieuwe voortbrengingsproces werkt het beste als medewerkers de ruimte krijgen om te experimenteren en om de mogelijkheden en nieuwe ideeën te verkennen. Wellicht is de meest elegante manier om dat te doen het per proces oprichten van multifunctionele groepen (IT & Business). Laat de medewerkers en materiedeskundigen maar vertellen waar en waarom ze extra hulp (lees: robots) nodig hebben. Met experimenten kan hiervoor een case gemaakt worden, zodat beslissingen rationeel en niet op basis van een onderbuikgevoel genomen worden. Beheersbaarheid betekent in dit kader snel kunnen bijsturen en dat lukt het beste als het stuur in handen is van diegenen die de impact gaan voelen.

Gezond verstand en Co-creatie

Samenvattend zou ik aanbevelen om RPA/IPA introductie als een organisatorisch verandertraject aan te vliegen. Co-creatie, heldere selectiecriteria  en veel aandacht voor organisatorische- en menselijke veranderingen zijn de sleutels voor succes. De beste keuzes in dit traject worden onderbouwd met hands-on, kleine experimenten van het type “don’t boil the ocean”. Dat vergt een nieuw voortbrengingsproces waarin ruimte voor ontdekkingsreizen is. Een aanpak die spannender is, maar ook grootser resultaat zal opleveren dan het bewandelen van de bekende wegen.

Houd jij je kennis graag up to date?

Mis niets meer van onze kennisdocumenten, events, blogs en cases: ontvang als eerste het laatste nieuws in je inbox!

Fijn dat we je op de hoogte mogen houden!