Wat kost het onderhoud van een software-robot?

Onderhoud van een software-robot is al het werk dat nodig is om hem na de livegang betrouwbaar te laten draaien: monitoren (de uitvoering volgen), mislukte runs afhandelen, aanpassen als een applicatie of het proces verandert, en wachtwoorden, licenties en de robotsoftware bijhouden. Hoeveel dat kost, hangt vooral af van hoe vaak de applicaties veranderen die de robot bedient, hoeveel uitzonderingen het proces heeft en hoe goed de robot gebouwd en vastgelegd is. Een vast percentage van de bouwkosten zegt daar weinig over. Reken liever per onderdeel, zoals hieronder.

Wat onderhoud inhoudt

Een software-robot is geen industriële robot: hij werkt via de schermen van andere applicaties, zoals een medewerker dat doet. Hij hangt dus af van alles wat in die applicaties en op zijn eigen machine verandert. Onderhoud bestaat uit deze onderdelen:

Spreek af wat onderhoud is en wat een wijziging. Onderhoud houdt werkend wat er is: de robot na een schermupdate weer laten draaien, of het bestand van een bestaande klant opnieuw herkennen. Een wijziging voegt iets toe, zoals een nieuwe klant met een eigen bestandsformaat of een tweede proces, bijvoorbeeld stuklijsten (de onderdelen van een product) uit het PDM-systeem (voor tekeningen en revisies) overnemen in het ERP (het bedrijfssysteem voor orders en administratie). Hoe wijzigingen in de begroting passen, leest u in wat het automatiseren van een bedrijfsproces kost.

Waarom een robot via schermen meer onderhoud vraagt dan een koppeling

Een robot herkent een veld of knop aan kenmerken van het scherm. UiPath noemt die beschrijving een selector. Volgens de documentatie van UiPath vindt een selector het element niet meer als een kenmerk bij elke start van de applicatie een andere waarde krijgt. Bij sommige webapplicaties met een wisselende opbouw moet de bouwer selectors met de hand maken. Microsoft noemt voor Power Automate nog meer oorzaken waardoor een selector faalt: updates en schermwijzigingen van de applicatie, een andere schermresolutie of schaal, een andere Windows-versie, een andere venstergrootte en andere gebruikersrechten. Hoe dat verschil uitpakt bij de keuze voor een techniek, staat in RPA of API-koppeling: wat is de beste keuze?

Voor het onderhoud telt vooral dit: een scherm is gemaakt voor mensen. De leverancier mag het veranderen zonder iemand te waarschuwen. Een medewerker past zich zonder moeite aan, een robot niet vanzelf. Beide grote platforms gaan er daarom van uit dat schermen veranderen. UiPath laat u schermelementen in een bibliotheek bewaren, zodat u de selectors na een nieuwe versie van een applicatie in één keer bijwerkt. Microsoft raadt bij Power Automate verzamelingen van schermelementen aan: na een update past u de verzameling één keer aan, en alle desktopstromen die haar gebruiken, nemen de wijziging over.

Een koppeling via een API (een vaste ingang waarmee software met andere software praat) is een afspraak tussen de leverancier en andere software. Ook die verandert, maar meestal met versies en een aankondiging. Microsoft markeerde bijvoorbeeld versie 1.0 van de API van Business Central in 2024 als verouderd en verwijderde hem in 2026 (release wave 1, versie 28.0). Wie een koppeling op die versie had, moest migreren, maar wist dat twee jaar van tevoren. Een koppeling vraagt ook eigen onderhoud: sleutels en certificaten verlopen, en de koppeling moet omgaan met limieten op het aantal verzoeken. Business Central geeft bij te veel verzoeken bijvoorbeeld een foutcode terug, en de koppeling moet het dan later opnieuw proberen.

Rekenvoorbeeld: een onderhoudsjaar voor een orderrobot

Deze 4 uur per maand zijn dezelfde onderhoudsuren als in de begroting in het kostenartikel. Twee posten staan niet in de tabel. De dagelijkse controle door de binnendienst kost bij 230 werkdagen ongeveer 58 uur per jaar. Dat is tijd van uw eigen medewerker, en die trekt u af van de tijd die vrijkomt, zoals in de berekening van het rendement. Daarnaast lopen de licenties en de machine door.

Wat de tabel niet laat zien, is de spreiding. In een rustig jaar blijft het hierbij. Maar een webportaal dat zonder aankondiging een nieuw scherm krijgt, of een ERP-update die de orderinvoer verandert, kan in één maand meer uren vragen dan dit hele jaarbudget. Reserveer daarom naast de vaste uren een buffer, en spreek af hoe die wordt afgerekend.

Wat de onderhoudskosten bepaalt

• Het aantal applicaties dat de robot bedient. Elke applicatie heeft een eigen updatemoment en een eigen inlog. Een robot die het ERP, het PDM-systeem en het portaal van een klant bedient, volgt drie updatemomenten.
• Hoe vaak die applicaties veranderen. Een ERP met een vaste releaseplanning is beter te volgen dan het webportaal van een klant dat zonder aankondiging verandert. Business Central online krijgt bijvoorbeeld elk jaar twee grote updates, in april en oktober, en in de andere maanden een kleine update.
• Het aantal uitzonderingen en varianten in de invoer. Elke variant is een plek waar een wijziging de robot kan laten struikelen.
• De kwaliteit van de bouw. Een robot die bij een storing precies meldt waar hij stopte, kost minder zoekwerk dan een robot die alleen "mislukt" meldt.
• Het inlogbeleid. Wachtwoorden die vaak verlopen en tweestapsverificatie maken automatisch draaien lastiger en vragen meer beheer.
• Een testomgeving. Zonder testomgeving test u updates in de echte omgeving, met extra controles en meer risico.
• De gewenste reactietijd. Moet een storing binnen een uur opgelost zijn, of mag het de volgende werkdag? Snelle beschikbaarheid kost meer, ook in maanden zonder storing.
• Documentatie. Wie de robot niet heeft gebouwd, moet hem kunnen begrijpen. Zonder documentatie begint elke storing met uitzoeken hoe de robot werkt.

Zo houdt u het onderhoud laag

Robuuste selectors en centrale schermelementen

UiPath adviseert selectors te bouwen op kenmerken met een vaste waarde. Microsoft adviseert voor Power Automate hetzelfde, plus reserveselectors voor als de eerste het element niet vindt, en een herhaalbeleid in de foutafhandeling. Bewaar schermelementen daarnaast centraal, in een bibliotheek of verzameling. Dan past u een gewijzigd scherm op één plek aan, en niet in elk proces apart.

Foutafhandeling die onderscheid maakt

UiPath maakt onderscheid tussen een technische fout, zoals een applicatie die niet reageert, en een fout in de gegevens, zoals een telefoonnummer waarin een cijfer ontbreekt. Bij een technische fout heeft een nieuwe poging zin. UiPath Orchestrator (het beheerprogramma dat robots start en volgt) probeert zo'n geval automatisch opnieuw als dat bij het aanmaken van de wachtrij is ingesteld. Een fout in de gegevens probeert Orchestrator standaard niet opnieuw. Die hoort bij een mens, met een duidelijke reden. Een robot die dit onderscheid maakt, lost een deel van zijn storingen zelf op en stuurt de rest naar de juiste persoon.

Werk met een wachtrij

In een wachtrij is elk geval, bijvoorbeeld een order, een apart item met een status. In UiPath Orchestrator ziet u per item of het gelukt is, mislukt of opnieuw geprobeerd. Een item dat ongeveer 24 uur in behandeling blijft zonder verwerkt te worden, krijgt de status "Abandoned" (verlaten). Zo ziet u meteen welke orders blijven hangen, in plaats van ze te moeten zoeken.

Een logboek met betekenis

Laat de robot vastleggen welk geval hij verwerkt, in welke stap en met welke uitkomst. In UiPath komen zelfgeschreven meldingen via de activiteit Log Message op de Logs-pagina van Orchestrator. Daar filtert u op niveau, van Trace tot Fatal. Een melding als "Order 4711: tekening 123 heeft revisie B, vrijgegeven is C, naar werkbak" scheelt bij een storing veel zoekwerk.

Wachtwoorden en sleutels op één plek

Zet inloggegevens niet in de robot zelf. In UiPath Orchestrator kunnen ze als asset van het type Credential centraal staan, versleuteld in de database. Verschillende processen kunnen dezelfde asset gebruiken. Verloopt een wachtwoord, dan past u het op één plek aan. Zet ook de vervaldatums van wachtwoorden, certificaten en sleutels in een agenda. Microsoft beperkt bijvoorbeeld de geldigheid van een client secret (een wachtwoord voor een applicatie) in Microsoft Entra tot hooguit 24 maanden, en raadt minder dan 12 maanden aan.

Een testomgeving en de release notes van uw applicaties

Test een update eerst in een testomgeving, voordat hij in de echte omgeving komt. Volg de releaseplanning en de release notes van de applicaties die de robot bedient. Dan weet u wanneer een update komt, en kunt u de robot vooraf testen in plaats van achteraf repareren. Sommige leveranciers maken dat makkelijk. Microsoft biedt voor een grote update van Business Central ongeveer een maand vooraf een previewversie aan in een testomgeving, en raadt sterk aan de belangrijkste processen te testen voordat de echte omgeving wordt bijgewerkt.

De robotsoftware bijhouden

Plan upgrades van het platform. Voor de producten die u zelf installeert (on-premises) geeft UiPath een LTS-versie twee jaar standaardondersteuning (mainstream support) en daarna een jaar beperkte ondersteuning (extended support). Daarna stopt de ondersteuning voor de meeste klanten, en moet u upgraden om weer hulp te krijgen. Ook een upgrade zelf vraagt aandacht. Microsoft meldt dat Power Automate for desktop achterwaarts compatibel is, maar dat een update acties kan wijzigen, en dat een stroom die met een nieuwere versie is gemaakt niet op een oudere versie hoeft te werken. Houd de versie op de bouwmachine en op de robotmachine daarom gelijk, en test na elke upgrade.

Documentatie

Leg vast wat de robot doet en wat niet, welke accounts hij gebruikt, waar het logboek staat en wat iemand moet doen bij een storing. Zo kan ook een ander de robot onderhouden.

Wat een onderhoudsafspraak moet regelen

• Wat erbij hoort. Monitoren, storingen oplossen, aanpassen na updates, wachtwoorden vernieuwen, platformupgrades. En wat er niet bij hoort: nieuwe functies en nieuwe processen.
• Wie monitort. Kijkt de beheerder elke dag, of uw eigen medewerker? Wie krijgt de melding bij een storing?
• Reactietijden. Binnen welke tijd begint iemand aan een storing, op welke dagen en tussen welke uren?
• Hoe u betaalt. Een vast aantal uren per maand, een urenbundel of per melding. Vast geeft voorspelbaarheid. Per melding is goedkoper in rustige maanden en duurder in drukke. Leg vast wat er gebeurt met uren die over blijven of tekortkomen.
• Uw meldplicht. Laat de beheerder op tijd weten wanneer een applicatie een update krijgt of het proces verandert.
• Licenties. Op wiens naam staan ze, en wie verlengt ze op tijd?
• Testen bij updates. Wie test, in welke omgeving, en wie geeft akkoord?
• Toegang en eigendom. U houdt toegang tot de robot, de broncode, de accounts en de documentatie, ook als de samenwerking stopt.
• Continuïteit. Wie neemt het over bij ziekte of vakantie van de beheerder? Bij een kleine leverancier of één interne bouwer is dat een reële vraag. Goede documentatie en uw eigen toegang zijn dan de verzekering.
• Overdracht. Hoe draagt de beheerder alles over als u stopt of overstapt?

Besliskader

Vragen om intern te stellen

• Hoe vaak veranderen de applicaties die de robot gebruikt, en wie hoort dat als eerste?
• Wie kijkt elke dag of de robot zijn werk heeft gedaan?
• Hoe snel moet een storing opgelost zijn: binnen een uur, of de volgende werkdag?
• Is er een testomgeving voor de belangrijkste applicaties?
• Is er een API die het schermwerk voor een deel kan vervangen?

Wat het zwaarst weegt

Hoe vaak de applicaties veranderen, en hoe goed de robot gebouwd is. Een robot op een stabiel ERP, met goede foutafhandeling en een logboek, vraagt weinig onderhoud. Een robot op een webportaal dat vaak verandert, zonder logboek, vraagt veel, hoe goedkoop de bouw ook was. Blijft het onderhoud structureel hoger dan verwacht, onderzoek dan of een koppeling het schermwerk kan overnemen.

Wanneer externe hulp zinvol is

Als niemand intern tijd heeft om dagelijks te monitoren en storingen op te lossen. Of als de bouwer vertrokken is en de robot niet is vastgelegd. Laat de robot dan eerst doorlichten: is hij goed te onderhouden, of is opnieuw bouwen goedkoper? Wat beheer na de livegang inhoudt, ziet u op de oplossingenpagina, bij beheer en support.

Eerlijk over de grenzen

Onderhoud blijft nodig. Ook een goed gebouwde robot hangt af van schermen die een ander beheert. Sommige wijzigingen komen zonder aankondiging, en dan staat de robot stil tot iemand hem aanpast. Een robot zonder eigenaar kan bij de eerste wijziging stukgaan, soms zonder dat iemand het meteen merkt. Dat is een van de bekende oorzaken waardoor RPA-projecten mislukken. Neem onderhoud daarom vanaf het begin op in de businesscase, als vaste post naast de licenties.

Bronnen

• UiPath Documentation: About selectors
• Microsoft Learn: Troubleshoot unattended desktop flow execution failures
• Microsoft Learn: Prerequisites and limitations (Power Automate for desktop)
• UiPath Documentation: Reusing objects and UI libraries
• Microsoft Learn: Optimize end-to-end process performance (Power Automate)
• Microsoft Learn: Deprecated features in the application (Business Central)
• Microsoft Learn: Update cycles (Business Central)
• Microsoft Learn: Working with API limits in Dynamics 365 Business Central
• UiPath Documentation: Business exception vs application exception
• UiPath Documentation: Queue item statuses
• UiPath Documentation: About logs
• UiPath Documentation: About assets
• Microsoft Learn: Add and manage app credentials in Microsoft Entra ID
• UiPath Documentation: Product lifecycle support terms