{"id":3443280,"date":"2026-09-08T14:28:16","date_gmt":"2026-09-08T12:28:16","guid":{"rendered":"https:\/\/datanorth.ai\/?p=3443280"},"modified":"2026-09-08T14:28:07","modified_gmt":"2026-09-08T12:28:07","slug":"hoe-je-een-ai-usecase-scoort-voordat-je-erin-investeert","status":"publish","type":"post","link":"https:\/\/datanorth.ai\/nl\/blog\/hoe-je-een-ai-usecase-scoort-voordat-je-erin-investeert","title":{"rendered":"Hoe je een AI-usecase scoort voordat je erin investeert"},"content":{"rendered":"\n

Scoor elke AI-usecase op twee assen: de waarde die hij oplevert en de complexiteit van het bouwen. Gebruik op allebei een smalle schaal van 1 tot 3, scoor met een groep in plaats van alleen, en bouw alleen wat hoog scoort op waarde en laag op complexiteit. De rest wacht, met de reden erbij vastgelegd.<\/p>\n\n\n\n

Dat klinkt mechanisch, en dat is ook de bedoeling. Het alternatief is dat je de usecase kiest waar de meeste energie op zit, wat de gebruikelijke manier van selecteren is en voor een flink deel verklaart waarom AI-projecten stranden. RAND sprak vijfenzestig ervaren datascientists en engineers voor het onderzoek naar de oorzaken waarom AI-projecten mislukken<\/a> en vond dat ruim tachtig procent faalt, ongeveer twee keer zo vaak als IT-projecten zonder AI. De eerste oorzaak op hun lijst is niet technisch. Het is dat betrokkenen niet begrijpen of niet uitspreken welk probleem er eigenlijk opgelost moet worden.<\/p>\n\n\n\n

Scoren is daar de goedkoopste oplossing voor. Het dwingt af dat het probleem in cijfers wordt uitgedrukt voordat er budget aan vastzit, en het levert een vastgelegde reden op waarom de andere dertig idee\u00ebn opzij gingen. Hieronder staat wat scoren precies inhoudt, hoe je elke as berekent, waar de drempels horen te liggen en welke fouten de exercitie waardeloos maken.<\/p>\n\n\n\n

Wat houdt het scoren van een AI-usecase precies in?<\/h2>\n\n\n\n

Het betekent dat je twee cijfers hangt aan een beschreven proces, niet aan een idee. Dat onderscheid doet het meeste werk. “AI inzetten bij klantenservice” laat zich niet scoren, want dat is een richting en geen taak. “Inkomende servicemails classificeren op productlijn en urgentie, nu gedaan door twee mensen gedurende ongeveer anderhalf uur per dag” laat zich wel scoren, omdat elk onderdeel telbaar is.<\/p>\n\n\n\n

De eerste opbrengst van een scoringsronde is dus een herschreven lijst. Idee\u00ebn komen uit interviews als intenties, en elk idee moet eerst een procesbeschrijving worden met een volume, een frequentie en een huidige eigenaar voordat een score iets betekent. In de praktijk verdwijnt daarmee al tien tot twintig procent van een longlist, omdat sommige idee\u00ebn hetzelfde proces twee keer beschrijven en andere helemaal geen proces beschrijven.<\/p>\n\n\n\n

Het tweede punt om helder te hebben is wat scoren niet is. Het is geen business case, want dat is een volledigere berekening van uren, bouwkosten en terugverdientijd voor \u00e9\u00e9n usecase. Het is ook geen haalbaarheidsonderzoek. Scoren is bewust ondiep en snel, ongeveer vijf minuten per usecase, juist zodat de dure analyse alleen gaat naar wat overblijft.<\/p>\n\n\n\n

Waarom is scoren belangrijker dan de idee\u00ebnlijst zelf?<\/h2>\n\n\n\n

Omdat een lange lijst zonder rangschikking net zo verlammend werkt als geen lijst. In de assessments die wij doen, levert een organisatie met vijf afdelingen doorgaans zeventig tot honderdveertig afzonderlijke kansen op. Ongerangschikt overhandigd wordt dat document \u00e9\u00e9n keer gelezen en daarna stilletjes niet meer gebruikt, want er is geen verdedigbare manier om te beginnen.<\/p>\n\n\n\n

Het faalpatroon dat daarop volgt is goed gedocumenteerd. Gartner verwacht dat ruim veertig procent van de agentic AI-projecten voor eind 2027 wordt stopgezet<\/a>, met oplopende kosten, onduidelijke businesswaarde en gebrekkige risicobeheersing als hoofdredenen. Onduidelijke businesswaarde is een scoringsprobleem onder een andere naam. Als niemand voor de bouw een getal op de waarde heeft gezet, kan niemand de uitgave verdedigen zodra die verdubbelt.<\/p>\n\n\n\n

Er is nog een tweede, minder voor de hand liggend argument. Scoren levert een verantwoordingsspoor op. Een half jaar later vraagt iemand waarom het verzoek van zijn afdeling nooit de roadmap haalde, en het eerlijke antwoord moet meer zijn dan een schouderophalen. Een score met een regel toelichting beantwoordt die vraag op een manier die mensen betrokken houdt in plaats van gepikeerd.<\/p>\n\n\n\n

Hoe scoor je waarde zonder te gokken?<\/h2>\n\n\n\n

Waarde moet een getal zijn dat je opnieuw kunt uitrekenen, en dat schrapt het meeste van wat er op geeltjes belandt. Begin bij de tijd die het proces nu kost, tel daar de kosten bij op van de fouten die het nu oplevert, en kijk pas daarna naar omzet.<\/p>\n\n\n\n

De tijdberekening is eenvoudig zodra de procesbeschrijving precies is. Neem de uren per keer, vermenigvuldig met de frequentie over een jaar, en vermenigvuldig nogmaals met een volledig belast uurtarief in plaats van een salariscijfer. De vermenigvuldiging die mensen laat struikelen is de laatste: het deel van de taak dat automatisering werkelijk wegneemt. Dat is zelden het geheel. Bij documentintensieve processen zien wij doorgaans veertig tot zeventig procent verdwijnen, waarbij de rest verschuift naar controle en uitzonderingen in plaats van weg te vallen. Scoren alsof de taak volledig verdwijnt, is verreweg de meest voorkomende manier waarop waarde wordt overschat.<\/p>\n\n\n\n

Foutkosten zijn de post die de meeste teams overslaan, en die is vaak groter dan de tijdwinst. Een proces met twee procent fouten op twintigduizend transacties levert vierhonderd fouten per jaar op, en elke fout kost herstelwerk, soms een creditnota en soms een klant. Reken het uit en vergelijk. Raakt een proces compliance of veiligheid, dan domineren de foutkosten de berekening volledig en wordt de tijdwinst bijzaak.<\/p>\n\n\n\n

Omzeteffecten zijn echt, maar hoor je behoudend te tellen en alleen wanneer iemand het getal wil dragen. Een sneller offerteproces wint aannemelijk meer werk, maar zolang sales geen huidige conversieratio kan noemen en niet toezegt het achteraf te meten, hoort het als kwalitatieve notitie in de kantlijn en niet in de score. Optimistische omzettoerekeningen zijn precies hoe een scoringsronde zijn geloofwaardigheid bij een financieel directeur verliest.<\/p>\n\n\n\n

Met die drie ingredi\u00ebnten wordt de waardescore simpel. Een usecase scoort 1 als de jaarwaarde onder ongeveer tweehonderd uur ligt of helemaal niet te kwantificeren is, 2 als hij tussen tweehonderd en duizend uur landt of aantoonbare foutkosten heeft, en 3 als hij boven duizend uur uitkomt of een omzeteffect heeft met een eigenaar erbij. Pas die drempels aan op je eigen schaal, maar leg ze vast v\u00f3\u00f3rdat je begint met scoren en niet tijdens.<\/p>\n\n\n\n

Hoe scoor je complexiteit?<\/h2>\n\n\n\n

Complexiteit is de as waarover technische en zakelijke mensen het meest van mening verschillen, dus het helpt om hem op te splitsen in vijf factoren en de slechtste factor te scoren in plaats van het gemiddelde.<\/p>\n\n\n\n

Databeschikbaarheid<\/strong> komt eerst, omdat dit de factor is die een veelbelovende usecase het vaakst verandert in een project van een half jaar. De vraag is niet of de data bestaat, maar of hij bestaat in een vorm die een systeem kan lezen, op een plek die een systeem kan bereiken, met genoeg historie om tegen te testen. Gescande documenten in een netwerkmap en gestructureerde records in een database staan aan tegenovergestelde uiteinden van deze schaal.<\/p>\n\n\n\n

Het aantal koppelingen<\/strong> is de volgende factor, en die schaalt slechter dan mensen verwachten. E\u00e9n systeem is overzichtelijk. Twee systemen met een gedocumenteerde API is te doen. Drie systemen waarvan er \u00e9\u00e9n helemaal geen API heeft is een ander project, en dat hoort bovenaan de complexiteitsschaal ongeacht hoe eenvoudig het AI-deel eruitziet.<\/p>\n\n\n\n

Het uitzonderingspercentage<\/strong> verdient meer gewicht dan het meestal krijgt. Een proces waarin vijfennegentig procent van de gevallen op elkaar lijkt, is een goede automatiseringskandidaat. Een proces waarin elk derde geval iets bijzonders heeft, vraagt uitzonderingsafhandeling die duurder te bouwen is dan de hoofdroute. Vraag aan degene die het werk doet hoe vaak hij moet nadenken, in plaats van aan zijn manager hoe standaard het proces is.<\/p>\n\n\n\n

De risicoklasse<\/strong> telt in Europa mee, omdat de classificatie van hoogrisicosystemen in de AI Act<\/a> bepaalt welke documentatie, menselijk toezicht en tests je verplicht moet inrichten. Een usecase die werving, krediet, onderwijs of essenti\u00eble dienstverlening raakt, brengt verplichtingen mee die de bouwinspanning wezenlijk veranderen, en dat hoort in de complexiteitsscore in plaats van achteraf ontdekt te worden.<\/p>\n\n\n\n

Gedragsverandering<\/strong> is de factor die het vaakst wordt vergeten, en de reden dat sommige technisch triviale usecases nooit landen. Als de uitkomst alleen waarde oplevert wanneer veertig mensen hun ochtend anders inrichten, is de complexiteit hoog terwijl het bouwwerk dat niet is. Tel hoeveel mensen hun gewoonte moeten aanpassen en behandel alles boven \u00e9\u00e9n team als complexiteitsfactor.<\/p>\n\n\n\n

Scoor 1 wanneer de data in \u00e9\u00e9n systeem staat, er geen nieuwe koppelingen nodig zijn en het uitzonderingspercentage laag is. Scoor 2 bij twee of drie systemen met wat databewerking. Scoor 3 wanneer de data nog niet bruikbaar bestaat, wanneer een koppeling geen API heeft, wanneer uitzonderingen veelvuldig zijn, of wanneer de usecase in een hoogrisicoklasse valt.<\/p>\n\n\n\n

Wat doe je met de twee scores?<\/h2>\n\n\n\n

Uitzetten en knippen. De twee assen leveren vier kwadranten op, en er wordt er maar \u00e9\u00e9n van gebouwd in het komende kwartaal.<\/p>\n\n\n\n

\"waarde<\/figure>\n\n\n\n

Hoge waarde met lage complexiteit is waar je begint, en daar zitten er meestal minder in dan iedereen hoopt. Hoge waarde met hoge complexiteit is geen afwijzing maar een opdracht: knip er een kleinere eerste versie uit die je kunt bouwen en meten, en scoor de rest daarna opnieuw. Lage waarde met lage complexiteit is oprecht verleidelijk en de moeite waard om te weerstaan, want een portefeuille met kleine makkelijke winsten kost evenveel managementaandacht als \u00e9\u00e9n serieus project en levert veel minder op. Lage waarde met hoge complexiteit gaat geparkeerd, met een notitie.<\/p>\n\n\n\n

De smalle schaal is een bewuste keuze. Scoren op 1 tot 10 voelt preciezer en levert slechtere beslissingen op, omdat de meeste scores tussen de vier en de zeven landen en de rangschikking daarmee ruis wordt. Drie punten dwingen af dat elke usecase laag, midden of hoog wordt genoemd, en onenigheid daarover wordt dan een nuttig gesprek in plaats van een middeling.<\/p>\n\n\n\n

E\u00e9n regel houdt de knip eerlijk: schrijf bij elke usecase die afvalt \u00e9\u00e9n zin waarom. Dat kost vijftien seconden en het is precies wat de exercitie later verdedigbaar maakt.<\/p>\n\n\n\n

Welke scoringsfouten maken de hele exercitie waardeloos?<\/h2>\n\n\n\n

Vijf patronen veroorzaken de meeste schade, en alle vijf zijn te vermijden.<\/p>\n\n\n\n

    \n
  • Het idee scoren in plaats van het proces.<\/strong> Staat er geen volume, frequentie en naam in de beschrijving, dan valt er niets te scoren. Herschrijf hem eerst.<\/li>\n\n\n\n
  • Waarde scoren op strategisch belang.<\/strong> Strategie telt, maar het is geen getal, en zodra het in de scorekolom komt wordt elk project met een bestuurlijke sponsor een 3. Houd strategisch gewicht apart als doorslaggever n\u00e1 de scoring, niet erbinnen.<\/li>\n\n\n\n
  • De complexiteitsfactoren middelen.<\/strong> Een usecase met perfecte data en \u00e9\u00e9n onbereikbaar systeem is niet middelmatig complex. Hij is geblokkeerd. Scoor de slechtste factor.<\/li>\n\n\n\n
  • Alleen scoren.<\/strong> E\u00e9n persoon produceert zelfverzekerde cijfers zonder gedeelde onderbouwing. Drie tot vijf mensen, onder wie iemand die het proces echt uitvoert, leveren cijfers op die kritiek overleven.<\/li>\n\n\n\n
  • Een hoge score zien als toestemming om te bouwen.<\/strong> Scoren rangschikt kandidaten. Het bevestigt niet dat de data toegankelijk is, dat een eigenaar tijd heeft gekregen of dat succes te meten valt. Dat is een aparte poort, en die overslaan is waar gescoorde roadmaps alsnog stuklopen.<\/li>\n<\/ul>\n\n\n\n

    Hoe houd je de scores een half jaar later eerlijk?<\/h2>\n\n\n\n

    Opnieuw scoren in plaats van heropenen. Omstandigheden veranderen, vooral op de complexiteitsas: een systeemmigratie rondt af, een API komt beschikbaar, een datakwaliteitsproject wordt afgesloten, en een usecase die een 3 scoorde op complexiteit wordt terecht een 2. Dat is een reden om hem in de volgende ronde opnieuw te scoren, niet om hem terug de huidige roadmap op te praten.<\/p>\n\n\n\n

    Leg daar een vast ritme voor vast, in de meeste organisaties per kwartaal, en houd de parkeerlijst ondertussen zichtbaar. Een geparkeerde usecase met een reden en een herzieningsdatum gedraagt zich binnen een organisatie heel anders dan een afgewezen usecase. Mensen blijven idee\u00ebn aandragen zolang ze kunnen zien waar hun vorige zijn gebleven.<\/p>\n\n\n\n

    De andere helft van eerlijk blijven is je eigen schattingen naast de werkelijkheid leggen. Zodra de eerste usecase in productie draait, vergelijk je de waarde die je scoorde met de waarde die je meet. De meeste teams ontdekken dat hun tijdwinst optimistisch was en hun foutkosten te laag ingeschat, en beide correcties maken de volgende scoringsronde beter.<\/p>\n\n\n\n

    Wat een score je niet vertelt<\/h2>\n\n\n\n

    Een score rangschikt kandidaten ten opzichte van elkaar. Hij zegt niet of de bovenste kandidaat klaar is om gebouwd te worden, en dat zijn echt verschillende vragen. Een usecase kan een 3 scoren op waarde en een 1 op complexiteit en alsnog stilvallen, omdat de data in een systeem bleek te zitten waar niemand inloggegevens voor heeft, omdat de business owner geen tijd toegewezen kreeg, of omdat niemand had afgesproken hoe een goed resultaat eruitziet.<\/p>\n\n\n\n

    Daarom hoort scoren direct v\u00f3\u00f3r een gereedheidstoets te staan en niet direct v\u00f3\u00f3r een ontwikkelsprint. Eerst rangschikken, dan verifi\u00ebren. In die volgorde kost het je twee weken en bespaart het je het half jaar dat een goed gekozen maar onvoldoende voorbereide usecase doorgaans opslokt.<\/p>\n\n\n\n

    Veelgestelde vragen over het scoren van AI-usecases<\/h2>\n\n\n\n
    \n
    Welke schaal gebruik je om AI-usecases te scoren?<\/strong><\/summary>\n

    Gebruik 1 tot 3 op zowel waarde als complexiteit. Bredere schalen zoals 1 tot 10 nodigen uit tot slagen om de arm houden, waarna de scores in het midden samenklonteren en niets meer zeggen. Drie punten dwingen een keuze af, en dat is precies het doel.<\/p>\n<\/details>\n\n\n\n

    Hoe bereken je de waarde van een AI-usecase?<\/strong><\/summary>\n

    Vermenigvuldig de uren die het proces nu kost met de frequentie en het volledig belaste uurtarief, en tel daar de kosten van de fouten bij op die het proces vandaag oplevert. Reken alleen het deel mee dat automatisering echt wegneemt, doorgaans veertig tot zeventig procent.<\/p>\n<\/details>\n\n\n\n

    Hoeveel usecases horen de scoring te overleven?<\/strong><\/summary>\n

    Drie tot vijf, van de zeventig tot honderdveertig die een inventarisatie oplevert. Blijven er meer dan vijf over, dan is er te mild gescoord. Een roadmap met tien usecases betekent in de praktijk dat niemand een keuze heeft durven maken.<\/p>\n<\/details>\n\n\n\n

    Vervangt scoren een business case?<\/strong><\/summary>\n

    Nee. Scoren bepaalt welke usecases een business case verdienen, en dat is een uitgebreidere berekening van uren, bouwkosten en terugverdientijd. Scoren is bewust snel en goedkoop, zodat je alleen echte analysetijd steekt in het handjevol dat overblijft.<\/p>\n<\/details>\n\n\n\n

    Wie moet de usecases scoren?<\/strong><\/summary>\n

    Scoor met drie tot vijf mensen, onder wie iemand die het proces uitvoert, iemand die de systemen kent en iemand met budgetverantwoordelijkheid. Alleen scoren levert zelfverzekerde cijfers op die uit elkaar vallen zodra iemand vraagt hoe je eraan komt.<\/p>\n<\/details>\n<\/div>\n