RPA verkopen is makkelijker dan RPA beheren. Dat merk je niet tijdens de demo, en wel in het jaar daarna.
De demo duurt twintig minuten en alles werkt. De robot logt in, vult het formulier in, slaat op. In de zaal knikt iedereen. Wat niemand vraagt: wat gebeurt er als de applicatieleverancier volgende maand een knop verplaatst?
RPA-leveranciers zijn er in twee soorten. De platformleverancier verkoopt de software waarmee robots worden gebouwd. De implementatiepartner bouwt en beheert ze, vaak op het platform van een ander. Voor een MKB-bedrijf is de tweede partij meestal belangrijker, want daar zit het werk dat na de oplevering begint.
Wat een demo niet laat zien
Een demo draait op een testomgeving met invoer die precies past. Een scherm, een route, geen uitzonderingen. Dat is geen misleiding, het is hoe een demo werkt. Het zegt alleen niets over de vraag die je eigenlijk stelt: blijft dit werken in mijn omgeving, met mijn rommelige invoer?
Vraag naar het aantal uitzonderingen per honderd transacties. Weet de leverancier dat niet en weet jij het ook niet, dan is de procesbeschrijving nog niet klaar voor een robot. Dat is geen detail dat je later invult; het bepaalt of je een wachtrij, een correctiescherm of een halve medewerker nodig hebt.
Een robot die om zes uur 's ochtends een exportbestand verwacht dat de vorige leverancier pas om negen uur aanlevert, faalt elke dag. Niet omdat het scherm is veranderd, maar omdat niemand naar de volgorde van de systemen had gekeken. Zulke dingen komen pas boven bij de eerste echte run.
Na zo'n demo weet je nog steeds niet of de robot met een foutmelding kan omgaan. Vraag hoe de leverancier dat test.
Vier vragen over het proces
Voordat je naar prijzen kijkt, wil je vier dingen over je eigen proces weten. Het antwoord bepaalt of RPA überhaupt de moeite waard is.
- Hoe vaak verandert het scherm dat de robot bedient? Vraag naar de releasefrequentie van de applicatie en naar de laatste drie wijzigingen aan het formulier.
- Hoeveel transacties lopen er per dag, en is dat volume vlak of piekerig? Een robot is voordelig bij gelijkmatig volume, niet per definitie bij pieken aan het einde van de maand.
- Hoeveel uitzonderingen zijn er per honderd transacties, en wie handelt die nu af?
- Is er een API, nu of binnen een jaar? Zo ja, vraag dan waarom de leverancier toch een schermrobot voorstelt.
Die laatste vraag is de belangrijkste van het gesprek. Een schermrobot is soms de enige route: een oud pakket dat alleen via een terminal werkt, of een leverancier die geen koppeling levert en dat ook niet van plan is. Maar als er een API ligt en niemand hem gebruikt, is RPA vaak een dure omweg.
Beheer: wie kijkt er om zeven uur naar?
Na de oplevering moet iemand weten dat een run is gefaald, en dat die persoon binnen een redelijke tijd kan ingrijpen. Hier ligt het verschil tussen een werkende robot en een duur abonnement.
Wat je wilt zien:
- Een monitoringscherm of alert dat de leverancier zelf kan openen, niet een scherm dat speciaal voor de demo is klaargezet.
- Wie de selectors onderhoudt als de applicatie een update krijgt. Meestal de partij die de bot bouwde, maar niet altijd, en die kosten zitten lang niet altijd in het licentiebedrag.
- Documentatie waaruit blijkt welke stappen de robot zet, welke uitzonderingen hij doorstuurt en hoe je een vastgelopen run opnieuw start.
- Een storing van de afgelopen zes maanden, met datum en oplossing. Wie blijft hangen op "dat komt eigenlijk nooit voor" heeft of een uitzonderlijk goede bot, of geen idee.
Neem de antwoorden op in het contract, niet in de notulen van het gesprek.
De rekensom voorbij de licentie
De licentie is het zichtbaarste deel van de kosten en zelden het grootste.
Laat de leverancier een prijslijst geven voor twee volumes, bijvoorbeeld vijf en vijftien bots, want de staffel is bijna nooit lineair. Reken daar de Windows-omgeving bij waarop de robot draait, inclusief licenties en beheer. Tel het onderhoud van selectors en updates per jaar mee, en de interne uren voor het beschrijven en testen van het proces. Voor dat laatste heb je iemand nodig die het proces echt kent, niet de stagiair die toevallig tijd heeft.
En de vraag die vaak blijft liggen: wat gebeurt er als je stopt? Blijven de scripts en documentatie van jou, ook na afloop van het contract? Leg de overdracht vast; bij een leverancierswissel bepaalt die afspraak hoeveel je opnieuw moet laten bouwen.
Dezelfde vragen over monitoring en eigenaarschap spelen bij elke geautomatiseerde workflow, ook buiten RPA. Ze staan uitgewerkt in Onderhoud en monitoring van AI-workflows: voorkom stille uitval.
Wanneer je de vraag anders moet stellen
Er zijn processen waarin "welke RPA-leverancier" simpelweg de verkeerde vraag is.
Wisselende documenten, e-mails met vrije tekst, offertes in drie formaten: daar is een schermrobot niet het juiste gereedschap, ongeacht de partij die hem bouwt. De robot leest wat op het scherm staat, niet wat er in een pdf staat. Voor dat werk is documentverwerking een logischer start.
Zijn de systemen wel via een API te benaderen, dan verschuift de vraag. Dan gaat het niet meer om welke robot je kiest, maar om welke stappen je aan elkaar knoopt en wie de foutafhandeling doet als een koppeling een dag stil ligt. Dat is het terrein van werkstroomorkestratie: systemen die niet met elkaar praten, toch laten samenwerken zonder dat er iemand tussen zit te klikken.
Het technische onderscheid tussen beide technieken staat in RPA uitgelegd voor het MKB en in AI-automatisering vs RPA. Wie vooral wil weten of hij dit zelf moet bouwen of moet uitbesteden, kan verder lezen in AI-workflows zelf bouwen of uitbesteden.
Veelgestelde vragen
Mag ik een leverancier vragen om een proef met mijn eigen gegevens?
Ja, en dat zegt meer dan een demo met voorbeelddata. Laat de proef draaien op een kopie van je testomgeving, niet op productie, en vraag welke versie van de applicatie daar staat. Een proef op een verouderde testkopie bewijst weinig over de maandag daarna. Leg in de opdracht vast wie de testdata na afloop verwijdert.
Hoe lang duurt een eerste RPA-traject?
Voor een enkel proces meestal vier tot acht weken, maar de bouwtijd is zelden de bottleneck. De doorlooptijd wordt bepaald door toegang tot een testomgeving en door de vraag wie de procesbeschrijving schrijft. Bij bedrijven waar de proceseigenaar zelf meeschrijft, gaat het doorgaans sneller dan bij een traject waarin de leverancier alles uit interviews moet reconstrueren.
Wat kost een RPA-licentie per jaar?
Dat loopt sterk uiteen en hangt af van of je per bot betaalt, per gelijktijdige sessie of per omgeving, en of de facturatie per maand of per jaar gaat. Vraag ook naar de kosten van een aparte testomgeving, de machine waarop de robot draait en eventueel Windows-beheer. Die posten staan niet altijd op de licentieprijslijst; neem ze mee bij het vergelijken van offertes.
Kan dezelfde leverancier ook de AI-stappen bouwen?
Soms. Veel implementatiepartners bouwen naast RPA ook koppelingen en AI-workflows, maar niet allemaal met dezelfde kwaliteit. Vraag welke stappen in het voorstel echt een model gebruiken en wie de prompts onderhoudt als de output verschuift. Zet dat in het contract, want promptonderhoud valt zelden onder "beheer" tenzij je het benoemt.
Wat als de leverancier ermee stopt?
Dat hangt af van je contract en van het platform. Spreek af welke scripts en documentatie je meekrijgt, hoe lang je toegang houdt tot de omgeving en wat ondersteuning bij een overstap kost. Zo voorkom je dat je pas bij vertrek ontdekt welke onderdelen je opnieuw moet laten bouwen.