Waarom een demo nog geen invoering is

Een demo leest een voorbeeldfactuur, haalt het bedrag eruit en maakt een keurige samenvatting voor goedkeuring. In het echte proces komen facturen via drie kanalen binnen, horen sommige bij een andere juridische entiteit en accepteert het goedkeuringssysteem alleen gebruikers met een bepaalde rol. De extractie werkt nog steeds. De workflow niet. Dit is een illustratief geval, geen klantverslag.

Een gesprek over AI invoeren in oudere bedrijfssystemen noemt gegevens, bestaande software en lokale gewoonten als het weerbarstige deel van invoering. De spreker beschrijft de praktijk van één bedrijf, geen algemeen succespercentage. Het nuttige onderscheid is dat tussen een onderdeel bewijzen en het in het werk laten functioneren.

De demo kiest zijn omgeving

Een demo kan schone invoer kiezen. Hij kan een account vooraf rechten geven, de wachtrij overslaan, een mislukte run opnieuw starten en de maker een dubbelzinnige uitkomst laten uitleggen. Dat is redelijk om een mogelijkheid te tonen. Het wordt gevaarlijk als het team die test als bewijs ziet dat de operatie klaar is.

Bij de factuur is extractie maar één stap. De organisatie moet vastleggen welke inbox gezaghebbend is, hoe ze duplicaten herkent, of een bedrag na indiening mag veranderen, wie mag goedkeuren en waar een mislukte verzending terechtkomt. Een gegenereerde samenvatting beantwoordt die vragen niet doordat ze welsprekender wordt.

De grens zie je het duidelijkst als je één werkitem van binnenkomst tot geaccepteerd resultaat volgt:

Demomogelijkheid voorbereide invoer

Lokale integratie gegevens rechten herstel

Workflow van medewerkers geaccepteerd resultaat

Een gedemonstreerde mogelijkheid wordt pas nuttig werk wanneer lokale gegevens, rechten en herstel haar verbinden met de echte workflow van medewerkers.

Fase	Vraag in de demo	Vraag bij invoering
Invoer	Kan het model dit voorbeeld lezen?	Kan het elk toegestaan formaat ontvangen en de rest weigeren?
Context	Kan het een bedrag vinden?	Kan het de juiste leverancier, entiteit en beleidsversie koppelen?
Handeling	Kan het een samenvatting maken?	Kan het alleen toegestane acties uitvoeren en duplicaten vermijden?
Fout	Kan de presentator opnieuw proberen?	Wie ziet een vastgelopen item, corrigeert het en gaat veilig verder?
Gebruik	Ziet de uitvoer er nuttig uit?	Gebruikt en vertrouwt de verantwoordelijke persoon haar in de echte wachtrij?

Deze vergelijking is conceptueel. Ze zegt niets over een gemeten faalpercentage van AI-projecten.

Volg de lokale toestand

Gegevensintegratie heet vaak de laatste stap, alsof het een kabel is die je aansluit als het product klaar is. Het lokale gegevensmodel kan veranderen wat het product betekent. Bij het ene bedrijf geldt een factuur als “ontvangen” zodra ze in een inbox staat; bij een ander pas na een koppeling met een inkooporder. Als het systeem op de verkeerde toestand handelt, kan een technisch geldige API-aanroep toch een zakelijke fout zijn.

Vraag waar elk feit vandaan komt en wie het kan corrigeren. Vraag daarna wat het systeem doet als feiten elkaar tegenspreken. Moet een conceptgoedkeuring ongeldig worden als het bronrecord verandert nadat het model haar opstelde? Controleert een worker opnieuw de rechten als die worden ingetrokken terwijl een taak in de wachtrij staat? Deze vragen vormen de invoering. Ze zijn geen afwerking achteraf.

Het artikel over workflowonderzoek begint eerder, bij het waarnemen van wat medewerkers echt doen. Hier is de vraag wat waar moet zijn zodat een getoonde mogelijkheid in die workflow blijft werken.

Bouw een prototype van de mogelijkheid, test daarna de workflow

Een klein prototype kan de snelste manier zijn om te ontdekken of een model de kerntaak kan uitvoeren. Op de eerste dag hoeft het nog niet alle productiecontroles te hebben. De fout is het overige werk als een klein afrondingsklusje plannen zonder het te onderzoeken.

Een bruikbaar prototype benoemt zijn grens. Het kan zeggen: “Dit leest goedgekeurde voorbeeldfacturen, stelt velden voor en voert geen externe handeling uit.” De volgende test kan toegestane echte records gebruiken terwijl schrijven naar het goedkeuringssysteem nog uitstaat. Pas als gegevenskoppeling, rechten en herstel duidelijk zijn, mag het naar het goedkeuringssysteem schrijven. Elke stap beantwoordt een andere vraag.

Invoering heeft ook een menselijke kant. Iemand die al dubbelzinnige facturen oplost, moet een voorstel kunnen corrigeren, zien wat is veranderd en weten of het systeem dezelfde fout zal herhalen. Als de nieuwe workflow meer controlewerk toevoegt dan hij wegneemt, zal het gebruik dat laten zien. Leid gebruik niet af uit een geslaagde demonstratie.

De vrijgavevraag kan heel praktisch zijn: kan een andere bevoegde medewerker één werkitem afronden en herstellen zonder dat de maker van de demo erbij is? Die medewerker moet de oorspronkelijke invoer vinden, het voorgestelde handelen zien, de basis voor de rechten herkennen en een fout kunnen doorzetten. Een geoefende manier om terug te draaien telt, want een geslaagde eerste run zegt niets over een duplicaat of gedeeltelijke schrijfactie. De gids voor AI in bestaande workflows biedt een breder kader voor invoering. Houd deze test smal en herhaal haar voor de uitzondering die de normale route waarschijnlijk het eerst breekt.

Tel geen gegenereerde uitvoer als resultaat. Tel een geaccepteerd werkitem in het echte proces, met een bekende route voor uitzonderingen. Tot die route werkt, is de demo waardevol bewijs voor één onderdeel. Niet voor een afgeronde taak.