Hoe AI-consultants een interne SaaS-vervanging scopen

Elke consultant die zijn dagtarief waard is, bepaalt de scope van een interne SaaS-vervanging op dezelfde manier: splits elke tool op in de onderdelen die je kunt zien en de onderdelen die elke keer correct moeten zijn. SaaS (software die je per maand huurt) bestaat voornamelijk uit schermen, workflows en rapportages die rusten op een kleinere kern van verslaglegging. AI heeft de eerste helft goedkoop gemaakt om te herbouwen. Op de tweede helft lopen vervangingsprojecten vast, en een goede scope dient om te meten hoeveel van je abonnementsfactuur daar daadwerkelijk bij hoort.

Hier lees je hoe de scope voor een interne SaaS-vervanging stap voor stap tot stand komt, en welke ene vraag het grootste deel ervan beslist. (Namen van leveranciers en onderzoeks-cijfers hieronder zijn nauwkeurig op het moment van publicatie; beschouw de details als een momentopname.)

Wat bevat de scope van een SaaS-vervanging eigenlijk?

Een inventarisatie van taken, geen functionaliteitenlijst. De consultant brengt elke taak in kaart die de tool uitvoert, wie ermee werkt en wat er gebeurt als de uitkomst onjuist is. Goedkeuringsprocessen, dashboards en formulieren komen in de ene kolom. Geldstromen, voorraadtegoeden, belastingen en personeelsgegevens in de andere. Het opleverproduct is die kaart, een risicoscore per taak en een overzicht van elk systeem waar de tool stilzwijgend mee is verbonden.

De beoordelingsvraag bepaalt alles: als deze uitkomst onjuist zou zijn, hoe kom je daar dan achter en wat zou dat kosten? Een verouderd dashboard valt meteen op en kost niets. Een verkeerd uitbetaald totaalbedrag valt pas op bij de belastingaangifte en kost echt geld.

Waarom het product in twee lagen opsplitsen?

Omdat AI de kosten van de ene laag enorm heeft verlaagd, maar de andere ongemoeid heeft gelaten. De interfacelaag (formulieren, dashboards, interne tools, goedkeuringsworkflows) is nu snel te herbouwen; huidige modellen genereren binnen enkele uren werkende webapps. Dat is precies wat we ontdekten toen we onderzochten of GPT-5.6 een werkende POS kon bouwen. De infrastructuurlaag is anders: betalingsverwerking, PCI-naleving (de beveiligingsregels die verwerkers opleggen voor creditcards), voorraadbeheer bij gelijktijdig gebruik (twee kassa's die het laatste artikel verkopen) en rapportages die aansluiten (totalen die overeenkomen met je bankstorting). Die laag is niet lastig omdat de code zo lang is. Die laag is lastig omdat 'bijna goed' daar waardeloos is, en het bewijzen van juistheid meer kost dan het genereren van de code.

Betere modellen nemen die beperking ook niet weg. De knelpunten zijn verificatie en aansprakelijkheid, niet het genereren van code. Een eerlijke scope berekent dus de prijs voor de verificatie. De generatie is de demo. De verificatie is de factuur.

Wat bewees de SaaS-vervanging van Klarna eigenlijk?

Het meest besproken verhaal over "we hebben onze SaaS vervangen door AI" is in werkelijkheid een les in scoping. Eind 2024 kondigde de CEO van Klarna aan dat het bedrijf Salesforce en Workday schrapte als onderdeel van een AI-reorganisatie, en koppen meldden dat AI SaaS volledig verving. Vervolgberichtgeving liet een genuanceerder beeld zien: Klarna verplaatste HR naar een andere leverancier en ving de CRM-behoeften op met een combinatie van alternatieve tools en interne koppelingen, met een AI-laag eroverheen¹. Een gelicentieerde bank met een van de meest agressieve AI-programma's in fintech hield haar bronsystemen (de gezaghebbende kopie van je bedrijfsgegevens) nog steeds op bewezen platforms en herbouwde aan de randen.

Dat was geen gebrek aan moed. Dat was de scope die zijn werk deed.

Welke cijfers rechtvaardigen een vervangingsproject?

Eerst snijden in verspilling, dan pas bouwen. Zylo's SaaS Management Index voor 2026, gebaseerd op meer dan 40 miljoen beheerde licenties, geeft aan dat de mediane SaaS-uitgaven $ 9.455 per werknemer per jaar bedragen. Hieruit blijkt dat gemiddeld 36% van de licenties ongebruikt blijft en dat bedrijfsonderdelen 81% van de SaaS-uitgaven beheren, terwijl IT slechts 15% rechtstreeks beheert². Een consultant vergelijkt jouw softwarepakket met deze cijfers voordat er iets wordt voorgesteld: zeg de ongebruikte licenties op, consolideer overlappende tools en maak pas daarna een selectie van kandidaten voor herbouw.

De tools die op de shortlist komen, delen hetzelfde profiel: hoge terugkerende kosten, taken die zich voornamelijk in de interfacelaag bevinden en een kleine impactcirkel als er iets misgaat. Het project wordt goedgekeurd wanneer de abonnementskosten sneller stijgen dan de kosten om te bouwen en te onderhouden, én elke taak die gegarandeerd correct moet zijn op infrastructuur kan blijven die door iemand anders wordt beheerd.

Waar komt een POS terecht in deze scoping?

Aan het meest onverbiddelijke uiteinde van het spectrum. Een POS lijkt op een interfaceproject — een raster van knoppen en een winkelmandje — dus eigenaren nemen aan dat de scope hetzelfde is als die van een dashboard. De verhouding is echter omgekeerd. Het afrekenscherm is maar een klein deel van het product; de rest bestaat uit betalingen, gecertificeerde pinhardware, voorraadadministratie die standhoudt als twee kassa's tegelijk verkopen, belastingregels en dagrapportages die exact aansluiten. Als een POS een fout maakt, gaat het dagelijks om geld.

Consultants bepalen de scope van een POS-herbouw daarom op dezelfde manier als Klarna haar grootboek aanpakte: een aangepaste interface op een bewezen infrastructuur. Vroeger was voor die opsplitsing een ontwikkeltijdtweed nodig. Nu is het een productcategorie: Build van Final zet een prompt in gewone taal om in een afrekenproces dat je kunt bekijken en implementeren, en je kunt je eigen AI verbinden via MCP om voort te bouwen op dezelfde commerce-infrastructuur. De betalingen, voorraad, rapportages en hardware blijven op de laag die al geverifieerd is.

Hoe moet je de scope van een interne SaaS-vervanging dan bepalen?

Splits elke tool op in de twee lagen, beoordeel elke taak op de kosten van een onopgemerkte fout en prijs de verificatie in plaats van de code. Herbouw interfaces en workflows gerust in eigen beheer; laat bronsystemen op infrastructuur staan die door anderen correct wordt gehouden. Stel jezelf de vraag voordat je een tool in-house herbouwt: als de uitkomst onjuist zou zijn, hoe snel zou ik dat dan merken? Is het antwoord "niet snel", dan blijft die taak op bewezen sporen lopen.

En als het commerce-gedeelte van je softwarepakket het onderdeel is dat je wilt herbouwen, begin dan met een kritische blik op wat de huidige modellen zelfstandig wel en niet kunnen bouwen: Claude vs ChatGPT vs Gemini bij een echte POS-build, of de twee no-code routes in hoe je Gemini 3.6 Flash gebruikt om een aangepaste POS te bouwen.