Zeven vragen die je moet stellen voordat je AI op je ERP loslaat

Een AI die je ERP-database leest geeft altijd een antwoord. Dat is precies het probleem: je ziet aan het antwoord niet of het klopt. Deze zeven vragen leggen het verschil bloot tussen een systeem dat je kunt vertrouwen en een systeem dat goed klinkt.

1. Waar komt dit getal vandaan?

Vraag om de query. Bij elk antwoord dat een bedrag of een aantal noemt hoort de opdracht die de database kreeg zichtbaar te zijn. Niet omdat je zelf SQL leest, maar omdat je hem aan je eigen ERP-partner kunt voorleggen als je twijfelt.

Kan een leverancier dat niet laten zien, dan koop je een cijfer zonder herkomst.

2. Wie heeft vastgelegd wat onze begrippen betekenen?

In elke ERP-database staan velden waarvan de betekenis niet in de database zelf staat. Telt een offerte mee als klant? Is omzet inclusief of exclusief btw, en meet je hem op de order of op de factuur? Zijn gerealiseerde uren de geschreven uren of het urenveld op de order?

Die keuzes zijn niet uit de data af te leiden. Iemand moet ze maken. De vraag is wie, en of het is vastgelegd op een plek die je kunt nalezen en corrigeren.

3. Wat gebeurt er als het antwoord er niet is?

Dit is de scherpste vraag van de zeven. Taalmodellen zijn getraind om te antwoorden, niet om te zwijgen. Vraag om een demonstratie met een vraag die de data niet kan beantwoorden en kijk wat eruit komt. Een bruikbaar systeem zegt wat het niet weet. De rest vult het gat met iets plausibels.

4. Wordt het antwoord nagerekend, en waartegen?

Nakijken klinkt geruststellend, maar het gaat om de vraag waartegen. Laat een systeem hetzelfde model een controlequery schrijven bij de query die het antwoord opleverde, dan controleert het zichzelf. Deelt het model in beide gevallen dezelfde denkfout, dan zijn beide uitkomsten gelijk en verschijnt er een groen vinkje bij een fout getal.

Een controle is pas iets waard als hij ergens op steunt dat niet uit hetzelfde model komt. Een telling kan bijvoorbeeld nooit hoger uitvallen dan het aantal rijen in de brontabel. Dat soort grenzen vangt precies de fout die een tweede query mist.

5. Wie merkt het als de ERP-inrichting verandert?

Er komt een nieuwe orderstatus bij. Iemand gaat uren anders boeken. Een veld dat altijd leeg was wordt in gebruik genomen. Vanaf dat moment klopt de vastlegging niet meer, en het vervelende is dat de cijfers gewoon door blijven lopen. Ze zijn alleen stilaan onjuist.

Vraag hoe dat wordt opgemerkt. Draait er periodiek een controle op de aannames, of merk je het pas als iemand toevallig struikelt over een getal dat niet kan.

6. Waar gaat onze data naartoe?

Twee losse vragen die vaak op één hoop gaan. Waar staat de database, en waar gaat de vraag naartoe die het taalmodel verwerkt. Het eerste kan bij jou op kantoor staan terwijl het tweede over de oceaan gaat.

Vraag ook welke gegevens het model te zien krijgt. Een systeem dat alleen de uitkomst van een berekening verstuurt is iets anders dan een systeem dat hele tabellen doorstuurt.

7. Wat houden we over als we stoppen?

De vastlegging van wat jullie begrippen betekenen is het waardevolste dat in zo'n traject ontstaat. Vraag of je die krijgt in gewone taal, in een bestand dat je zelf kunt lezen. Zit die kennis alleen in het systeem van de leverancier, dan begin je bij een overstap opnieuw.

De rode draad

De zeven vragen komen op hetzelfde neer: kan het systeem aantonen dat het gelijk heeft, of moet je het geloven. Bij een dashboard dat een consultant heeft gebouwd is het antwoord traceerbaar, alleen duurt elke wijziging weken. Bij een chatbot op je database is het antwoord er meteen, alleen kun je het niet nalopen.

Wat je zoekt is het antwoord van het tweede met de controleerbaarheid van het eerste.