Wat kost een automatisering? Deel 2: de prijs opbouwen en uw garanties

Terugverdienregel, een becijferd voorbeeld, acceptatiecriteria, garanties en eigendom van de code

Gepubliceerd: 11 min read

In het eerste deel van dit artikel gaven we ordegroottes, beschreven we het verloop van onze audit en toonden we hoe wij een proces in kaart brengen en meten wat het elk jaar werkelijk kost. We legden ook uit waarom complexe gevallen bewust onder menselijke validatie blijven. Dit tweede deel vertrekt van die meting en beantwoordt de vragen die er logisch op volgen: waarom twee gelijkaardige projecten niet dezelfde prijs hebben, hoe wij de onze opbouwen, en wat u beschermt als het resultaat niet aan de criteria voldoet.

De technische complexiteit inschatten

Twee automatiseringen die dezelfde waarde creëren, kunnen een heel verschillende realisatie-inspanning vragen. Een eenvoudige workflow rijgt een e-mail, een data-extractie, het genereren van een document en de verzending ervan aan elkaar. Een andere loopt door een bedrijfsapplicatie, een externe API, bedrijfsregels, een AI-model, een menselijke validatie, een elektronische handtekening en een archivering. In het tweede geval komt de complexiteit zelden van de kunstmatige intelligentie zelf, maar van de integraties. Er moeten authenticaties, toegangsrechten, onvolledige data, storingen bij externe diensten, beveiliging en herstelmechanismen beheerd worden.

Een prototype dat het doet tijdens een demo vertegenwoordigt vaak minder dan 20% van het werk. De overige 80% (foutafhandeling, onvolledige data, storingen bij derde partijen, beveiliging, herstel na incident) blijft onzichtbaar in een demo, maar het is net dat deel dat het verschil maakt tussen een systeem dat tien minuten indruk maakt en een systeem waaraan u elke dag uw klanten toevertrouwt. Dat verschil verklaart waarom eenzelfde behoefte twee tot drie keer zoveel kan kosten, naargelang het vereiste kwaliteitsniveau. Figuur 1 laat zien waar de waterlijn ligt.

IJsberg: het zichtbare topje draagt de 20% van het werk die een demo toont, de onderwatermassa de onzichtbare 80%, aangeduid met pictogrammen voor waarschuwing, beveiliging en herstel
Figuur 1. Het onzichtbare deel valt niet op tijdens een demo, maar het houdt het systeem overeind als een externe dienst uitvalt of data ontbreken.

De prijs opbouwen

Wij berekenen de prijs van een project niet door simpelweg een aantal dagen met een dagtarief te vermenigvuldigen. Die methode bevat een paradox: hoe efficiënter een leverancier wordt, hoe minder hij zou moeten factureren. Toch kan een automatisering die enkele dagen ontwikkeling vraagt, jaarlijks tienduizenden euro’s aan waarde creëren, terwijl een zeer technische integratie veel werk kan vragen voor een bescheiden economische waarde.

Wij beoordelen elk project daarom op drie dimensies. De realisatiecomplexiteit dekt de ontwikkeling, de integraties, de tests en de uitrol. Het operationele risico meet het belang van het proces voor uw activiteit en de gevolgen van een fout. De economische waarde telt de vrijgemaakte tijd, de gecreëerde capaciteit, de vermeden fouten en de mogelijke extra inkomsten samen.

Concreet passen we een eenvoudige regel toe: de projectprijs wordt zo opgebouwd dat de investering terugverdiend is in het eerste of het tweede exploitatiejaar, op basis van de cijfers die we samen tijdens de audit hebben vastgelegd. Slagen we er niet in om die redenering op te bouwen, dan bevelen we het project niet aan. Die regel staat in het auditrapport: u kunt ze nakijken en ons eraan houden.

Net als in de meting van de jaarlijkse kostprijs uit het eerste deel schuilt ook in die regel een objectief belang aan onze kant, en we zeggen het liever ronduit: hoe duurder uw proces is, hoe hoger de verdedigbare prijs, bij gelijke ontwikkelinspanning. Dat is het principe van een prijs die gekoppeld is aan de gecreëerde waarde in plaats van aan onze werkdagen. De keerzijde beschermt u: diezelfde regel plafonneert de prijs op één of twee jaar besparingen, hoe complex ons werk ook is.

Een concreet voorbeeld

Nemen we het proces uit het eerste deel er weer bij: 80 uitvoeringen per week, gemiddeld 12 minuten menselijk werk, ofwel ongeveer € 25.760 aan menselijke capaciteit die elk jaar vastzit. Dit voorbeeld is fictief en vereenvoudigd: het toont de redenering, het belooft geen resultaat, en naargelang de complexiteit en de waarde die op het spel staat, kan een echt project merkbaar minder of merkbaar meer kosten. In echte projecten varieert de haalbare reductie sterk van geval tot geval, en het gebeurt dat we besluiten dat ze te klein is om de investering te verantwoorden. Dan zeggen we dat aan de klant voor hij investeert.

Stel dat de analyse een mogelijke reductie van 75% van de aan het proces bestede tijd aantoont. De vrijgemaakte menselijke capaciteit vertegenwoordigt dan ongeveer € 19.300 per jaar. Stel dat het project € 7.500 aan opzet vraagt, waarbij de al betaalde audit van dat bedrag wordt afgetrokken, en daarna € 250 per maand voor infrastructuur, monitoring en onderhoud. De totale kostprijs van het eerste jaar komt zo op € 10.500. Bij die € 10.500 komt nog de tijd die uw teams aan het project besteden (afbakening, tests, opleiding), doorgaans het equivalent van € 1.000 tot € 1.500, en de volledige reductie wordt pas bereikt na een inloopperiode van enkele weken. Zelfs met die elementen erbij blijft het break-evenpunt binnen het eerste jaar. Figuur 2 zet die twee cumulatieve lijnen uit over 24 maanden.

Deze aannames vragen twee verduidelijkingen. We houden 75% aan, niet de 95% uit het eerste deel: die 95% telt automatisch verwerkte dossiers, geen tijd, want de dossiers die in menselijke validatie blijven, zijn de meest tijdrovende, en het geautomatiseerde proces behoudt een stuk toezicht. De € 7.500 zit bovenaan de prijsvork van € 3.000 tot € 8.000 uit het eerste deel: het proces blijft een lineaire keten rond één bedrijfsapplicatie, zonder AI-model om te integreren, en dat houdt het onder de drempel van automatiseringen over meerdere systemen.

Break-evencurve over 24 maanden: de gecumuleerde vrijgemaakte capaciteit kruist de gecumuleerde kosten rond de zevende maand en bereikt daarna ongeveer 37 k€ tegenover 14 k€
Figuur 2. De cumulatieve vrijgemaakte capaciteit haalt de cumulatieve kosten in na zes of zeven maanden. Daarna stijgen alleen nog de exploitatiekosten. Het verschil wordt zo steeds groter.

Op papier ligt dat break-evenpunt rond de zes maanden, of op zes tot zeven maanden als we de interne kosten en de inloopperiode meerekenen. Maar die berekening steunt op een voorwaarde die we samen met u nagaan voor we het project goedkeuren: de vrijgemaakte uren moeten daadwerkelijk naar nuttige activiteiten gaan. Vrijgemaakte capaciteit die nergens toe dient, is niets waard, en dat zeggen we liever vóór de offerte dan erna. Vanaf het tweede jaar beperkt de kost zich tot de exploitatie, ongeveer € 3.000 per jaar, tegenover een vrijgemaakte capaciteit die rond de € 19.300 blijft.

Toont de analyse daarentegen dat een proces slechts enkele duizenden euro’s per jaar vertegenwoordigt en een complexe integratie van € 15.000 zou vragen, dan besluiten we dat automatisering niet verantwoord is, en die conclusie hoort bij ons werk. Sommige taken komen te zelden voor, sommige procedures zijn te veranderlijk, en sommige integraties zijn te duur in verhouding tot het verwachte voordeel. Ons doel is niet om koste wat het kost een automatisering te vinden, maar om te bepalen of ze een rationele investering is.

De initiële prijs en de exploitatiekost zijn twee verschillende dingen

Wij maken een onderscheid tussen twee soorten kosten, en we becijferen ze apart. De opzet omvat de audit, het ontwerp van de workflow, de ontwikkeling, de integraties, de tests, de uitrol, de documentatie en de opleiding van de teams: dat is een initiële investering. De exploitatie dekt daarna de infrastructuur, de oproepen naar API’s en AI-modellen, de opslag, de monitoring, het onderhoud en de ondersteuning.

Die terugkerende kosten worden vanaf het begin in kaart gebracht. Wij hebben liever dat een klant precies weet wat zijn systeem kost om te draaien, dan dat hij maand na maand een reeks technische uitgaven ontdekt die moeilijk te doorgronden zijn.

Hoe weten we dat een project af is?

Zeggen dat een automatisering “naar behoren moet werken” volstaat niet. Wij leggen daarom waarneembare acceptatiecriteria vast, bijvoorbeeld:

Wanneer een volledige aanvraag binnenkomt, identificeert het systeem de klant, haalt het de nodige informatie op, genereert het het document en bewaart het dat automatisch in het overeenkomstige dossier.

Wanneer verplichte informatie ontbreekt, wordt het dossier niet automatisch verwerkt en komt het in een wachtrij voor menselijke validatie terecht.

Die criteria laten zowel de klant als ons team precies weten wat het systeem moet doen, en ze maken de tests en de validatie veel eenvoudiger.

En als het niet werkt?

Die acceptatiecriteria zijn geen versiering: ze bepalen de betaling. Een deel van de betaling, vastgelegd in de offerte, is pas verschuldigd na een gezamenlijke validatie van de acceptatiecriteria onder reële omstandigheden. Die validatie volgt een tijdschema dat in de offerte staat, en ze veronderstelt uw medewerking: toegang tot echte data, beschikbaarheid van de betrokken personen en de afgesproken volumes. Zonder gemotiveerd voorbehoud van uw kant binnen de afgesproken termijn, doorgaans vijftien werkdagen na de ingebruikname onder reële omstandigheden, wordt de aanvaarding als verworven beschouwd. Dat is de logische tegenhanger van onze verbintenis.

Een garantieperiode, doorgaans van vier weken en in elke offerte vermeld, dekt zonder extra kosten de correctie van afwijkingen ten opzichte van die criteria. De metingen vooraf en achteraf worden samen vastgelegd, zodat elk van beide partijen ze kan nagaan: de hypothesen worden tijdens de audit gevalideerd, en de resultaten worden gezamenlijk vastgesteld.

Als de acceptatiecriteria een automatische verwerking van 95% van de dossiers vastlegden en het systeem er tijdens de garantieperiode en onder de in de offerte voorziene omstandigheden maar 60% verwerkt, dan is dat ons probleem om op te lossen en niet het uwe om te financieren.

Van wie is het systeem, en kunt u vertrekken?

De specifieke ontwikkelingen, dat wil zeggen de code en de workflows die voor u gebouwd zijn, zijn uw eigendom zodra ze betaald zijn. Twee zaken blijven buiten die overdracht: de tools van derden houden de licenties van hun eigen leveranciers, en de herbruikbare componenten die wij voor uw project bezaten of daar los van hebben ontwikkeld blijven de onze, in licentie zolang u het systeem exploiteert. Beide worden u meegedeeld voor er iets gebouwd wordt. Onderhoud is niet verplicht: het is opzegbaar met één maand opzegtermijn, en het systeem draait ook zonder ons. Wij leveren documentatie waarmee een andere leverancier het systeem kan overnemen.

Wat data betreft, gebeurt de hosting in Europa, wordt met elke verwerker een verwerkersovereenkomst (DPA) afgesloten, ook met de leveranciers van AI-modellen, en wordt de AVG-conformiteit van uw situatie tijdens de audit onderzocht. De lijst van verwerkers wordt u bezorgd vóór elke uitrol.

Die waarborgen tellen dubbel in de zorgsector, waarmee wij geregeld samenwerken. Het voorbereiden van patiëntendossiers, ontslagbrieven of de receptie raakt aan gevoelige gegevens, en de waarderedenering uit deze twee artikelen geldt daar op dezelfde manier, met strengere conformiteitseisen. Onze zelfbedieningszuil voor patiëntinschrijving laat zien hoe wij die eisen in de praktijk aanpakken.

Hoelang duurt het, en hoeveel tijd vraagt het van uw teams?

Deze doorlooptijden zijn indicatief, maar ze geven houvast om te plannen. De audit loopt over één tot drie weken. Een eenvoudige workflow staat doorgaans vier tot acht weken na goedkeuring van de offerte in productie, terwijl een automatisering over meerdere systemen eerder drie tot zes maanden vraagt. Een programma van begin tot eind wordt tijdens de audit gepland, fase per fase. Van uw kant moet u enkele uren voorzien tijdens de audit, en daarna het equivalent van twee tot vijf dagen gespreid over het project voor de afbakening, de tests en de opleiding. Die interne kost wordt in het auditrapport geraamd.

Onze aanpak samengevat

Een project bij transtorm.ai volgt altijd dezelfde logica:

  1. het proces begrijpen;
  2. de kostprijs en de beperkingen ervan meten;
  3. de automatiseerbare stappen identificeren;
  4. de complexiteit en de risico’s inschatten;
  5. de gecreëerde waarde ramen;
  6. de oplossing en de prijs ervan bepalen;
  7. meetbare acceptatiecriteria vastleggen;
  8. uitrollen en de resultaten meten.

De eerste drie stappen komen overeen met het eerste deel van dit artikel, de volgende met dit deel. Deze methode beantwoordt een nuttigere vraag dan die van de prijs alleen: is deze automatisering een goede investering voor uw organisatie? De eerste stap in die keten is precies wat onze audit oplevert.

De volgende stap verbindt u tot niets: een gesprek van 30 minuten, gratis, volstaat meestal om te bepalen of uw proces een goede kandidaat voor automatisering is, of net niet. In beide gevallen krijgt u een antwoord. Schrijf ons onderaan deze pagina of boek meteen een moment in onze agenda.

Klaar om uw processen te automatiseren?

Laten we uw behoeften bespreken en kijken hoe transtorm.ai kan helpen