CRM of ERP wijzigen: hoe test u uw AI-automatisering vóór ingebruikname?

Begin met het bewijs dat u vóór de wijziging nodig heeft

Wilt u vóór een CRM- of ERP-wijziging controleren of uw AI-automatisering blijft werken zoals bedoeld? Inventariseer welke processtappen, gegevensvelden, koppelingen en rechten veranderen. Test vervolgens de bestaande en aangepaste werking met dezelfde representatieve situaties. Leg vooraf de verwachte uitkomsten vast en laat de verantwoordelijke afwijkingen én ontbrekend bewijs beoordelen voordat u de wijziging in gebruik neemt.

Maak het vrijgavebesluit concreet: welke gewijzigde versie mag welk werk uitvoeren, met welke bevoegdheden? Een ontvangen systeemantwoord is daarbij één controlepunt. Controleer ook of de juiste gegevens zijn gebruikt, het resultaat inhoudelijk klopt en alleen toegestane vervolghandelingen plaatsvinden.

Hieronder werken we een praktische beslisroute uit die u met uw proceseigenaar en technisch beheerder kunt toepassen. Het is een ontwerpvoorstel; bepaal per systeem welke testvoorzieningen beschikbaar zijn en welke controles uitvoerbaar zijn. Bij onze aanpak voor bedrijfsprocessen automatiseren met AI brengen we stappen, systemen, beslissingen en uitzonderingen in kaart en testen we stapsgewijs met representatieve praktijksituaties.

Volg de wijziging van invoer tot vervolghandeling

Neem de geplande wijziging als vertrekpunt. Schrijf precies op wat anders wordt: bijvoorbeeld een veldnaam, statuswaarde, gegevensindeling, koppeling of toegangsrol. Volg daarna ieder geraakt gegeven door het proces. Waar wordt het opgehaald, geïnterpreteerd, verwerkt en eventueel teruggeschreven?

Maak per betrokken stap een korte vergelijking tussen de huidige en gewenste situatie. Laat de technisch beheerder beschrijven wat verandert in de gegevensuitwisseling. Laat de proceseigenaar bevestigen wat die gegevens betekenen voor het dagelijkse werk. Neem ook de eerstvolgende afhankelijke stap mee in de test.

Stel bijvoorbeeld dat een statusveld voortaan onderscheid maakt tussen ‘gecontroleerd’ en ‘goedgekeurd’. Leg dan eerst vast welke status nodig is om een concept te maken en welke status toestemming geeft voor uitvoering. Laat de automatisering dat verschil vervolgens aantoonbaar respecteren.

• Processtap: welk werk gebruikt het gewijzigde onderdeel en wie is daarvoor verantwoordelijk?
• Gegevens: welke namen, typen, verplichte waarden en betekenissen veranderen?
• Koppeling: welke aanvraag gaat naar het systeem en welk antwoord verwacht de volgende stap?
• Rechten: welke gegevens mag de automatisering lezen en welke handelingen mag zij uitvoeren?
• Overdracht: wat moet een medewerker ontvangen bij een uitzondering of onvolledig resultaat?

Schrijf de verwachte uitkomst op voordat u test

Selecteer situaties die samen het geraakte werk vertegenwoordigen. Gebruik een gewone volledige invoer, relevante uitzonderingen en gevallen waarin de automatisering moet stoppen. Kies testgegevens die voor dit doel gebruikt mogen worden. Noteer bij ieder geval de invoer, beginstatus, verwachte uitvoer en toegestane eindstatus.

Voer dezelfde gevallen uit tegen de bestaande en aangepaste inrichting. Houd instructies, bronnen en andere instellingen zoveel mogelijk gelijk en registreer welke versies u gebruikt. Moet de invoer door de systeemwijziging anders worden aangeleverd, leg dan vast hoe beide invoervormen dezelfde bedrijfssituatie voorstellen.

Gebruik de bestaande uitkomst als vergelijkingsmateriaal, maar toets beide versies aan de vooraf afgesproken verwachting. Ook een bestaande fout moet zichtbaar blijven. Als de wijziging juist nieuw gedrag beoogt, beschrijf dan vooraf welk verschil gewenst is en waarom.

Onze aanpak voor een AI-agent laten bouwen omvat testsets, evaluatiecriteria en representatieve scenario’s met uitzonderingen. Voor een geplande systeemwijziging kunt u dat vertalen naar een vaste verzameling gevallen die u na herstel opnieuw doorloopt.

Toets vaste voorwaarden en inhoud afzonderlijk

Laat harde voorwaarden met vaste controles toetsen waar dat mogelijk is. Denk aan een verplicht klantkenmerk, een toegestane statuswaarde, het juiste uitvoerformaat en een expliciete lijst toegestane acties. Formuleer per controle wat er gebeurt bij een afwijking: blokkeren, terugsturen of voorleggen aan een medewerker.

Microsoft beschrijft gestructureerde uitvoer als basis voor programmatische validatie en adviseert validatie vóór ingebruikname in Process to build agents across your organization. Vertaal dat naar controleerbare afspraken met uw bouwer: welke velden worden gecontroleerd, op welk moment en met welke vervolgactie?

Laat daarnaast iemand met proceskennis de inhoud beoordelen. Hoort het voorstel bij de juiste klant en aanvraag? Ondersteunen de gebruikte gegevens de conclusie? Blijft ontbrekende informatie herkenbaar? Een ingevuld veld of geldig formaat beantwoordt die vragen nog niet.

Anthropic beschrijft in Building effective agents programmeerbare tussencontroles in opeenvolgende werkstappen. Gebruik dat principe bijvoorbeeld om onvolledige uitvoer tegen te houden voordat een volgende stap ermee verdergaat. Leg het inhoudelijke oordeel daarna bij de aangewezen beoordelaar.

• Harde controle: verplichte velden aanwezig, waarden toegestaan en acties binnen de afgesproken rechten.
• Inhoudelijke controle: juiste betekenis, passende conclusie en zichtbare onzekerheden.
• Vrijgavecontrole: bevoegde verantwoordelijke, beoordeelde versie en expliciet besluit over ingebruikname.

Een fictief testgeval: een gewijzigd klantkenmerk

Stel dat uw automatisering een klantaanvraag leest, gegevens uit het CRM ophaalt en een intern opvolgvoorstel maakt. In de geplande wijziging wordt het oude klantnummer vervangen door een nieuw relatiekenmerk. Dit fictieve voorbeeld laat zien hoe u verwachtingen kunt vastleggen.

Neem een aanvraag waarvan de juiste klantrelatie bekend is. Verwacht in beide inrichtingen een voorstel bij diezelfde klant, met dezelfde relevante informatie. Controleer afzonderlijk welk kenmerk is gebruikt en bij welk dossier het voorstel terechtkomt. Spreek af dat de automatisering alleen een concept mag opslaan.

Voeg daarna een aanvraag zonder relatiekenmerk toe. Leg als verwachting vast dat geen klant wordt gegokt en geen voorstel aan een willekeurig dossier wordt gekoppeld. De medewerker ontvangt een gerichte melding over het ontbrekende gegeven.

Test ook een onbekend kenmerk en een geweigerde toegang. Verwacht bij beide een herkenbare blokkade van de afhankelijke stap, met voldoende informatie voor de verantwoordelijke. Deze verwachtingen zijn ontwerpkeuzes die u vooraf met uw team vastlegt.

Neem de lastige routes mee in dezelfde vergelijking

Werk de uitzonderingen uit op basis van uw impactinventarisatie. Verandert vooral de gegevensstructuur, besteed dan aandacht aan ontbrekende velden en afwijkende waarden. Veranderen rechten, test dan zowel toegestane als geweigerde handelingen. Verandert de overdracht, controleer dan wat de volgende medewerker daadwerkelijk ontvangt.

Bewaar per test de verwachte uitkomst, waargenomen uitkomst en concrete afwijking. Schrijf bijvoorbeeld ‘concept opgeslagen bij verkeerd dossier’ in plaats van ‘test mislukt’. Laat ook zien wanneer een verwachte blokkade correct heeft gewerkt.

Als de AI-stap bij herhaling verschillende formuleringen oplevert, beoordeel die dan aan dezelfde inhoudelijke criteria. Leg meerdere uitvoeringen vast waar variatie relevant is voor het besluit. Kies vooraf welke verschillen acceptabel zijn en welke een nieuwe beoordeling vragen.

• Ontbrekend verplicht veld: verwacht geen afhankelijke uitvoering en een gerichte melding.
• Onbekende statuswaarde: verwacht de afgesproken uitzonderingsroute, zonder stilzwijgende vervanging.
• Geweigerde toegang: verwacht behoud van de toegangsgrens en een zichtbare blokkade.
• Onvolledig systeemantwoord: verwacht herkenbare ontbrekende informatie en geen ongefundeerde aanvulling.
• Herhaalde aanbieding van dezelfde invoer: controleer of ongewenste dubbele vervolgacties ontstaan.
• Gewijzigde aanvraag tijdens verwerking: controleer welke versie uiteindelijk ter beoordeling wordt aangeboden.

Beslis expliciet over vrijgave, herstel of uitstel

Geef de verantwoordelijke een compact beslisoverzicht. Vermeld de geteste wijziging, gebruikte versies, gedekte situaties, afwijkingen en ontbrekende controles. Koppel iedere open afwijking aan een eigenaar en een benodigde herstelactie. Vermijd een algemene melding als ‘alles getest’ wanneer onderdelen buiten de proef zijn gebleven.

Spreek vooraf af welke uitkomsten ingebruikname blokkeren. Neem in dit ontwerp ongeoorloofde acties, verkeerde dossierkoppelingen en falende verplichte controles als blokkerende afwijkingen op. Laat een gunstige totaalscore zulke afzonderlijke fouten niet verhullen.

Ontbreekt een representatieve testomgeving of noodzakelijke systeeminformatie? Noteer precies welk gedrag daardoor onbewezen blijft. Een controle van losse onderdelen biedt dan alleen bewijs voor die onderdelen. Stel de geraakte ingebruikname uit wanneer een essentiële voorwaarde niet kan worden getoetst.

Een kleinere vrijgave is alleen een zinvolle optie als u het ongeteste deel aantoonbaar kunt uitsluiten en de resterende route afzonderlijk heeft getest. Laat de bevoegde verantwoordelijke de reikwijdte daarvan vastleggen. Veronderstel ook geen herstelmogelijkheid: bespreek vooraf of terugzetten technisch mogelijk is en welke gevolgen dat heeft.

• Vrijgeven: de afgesproken controles zijn uitgevoerd, de resultaten voldoen en de verantwoordelijke keurt de exacte versie en reikwijdte goed.
• Herstellen en opnieuw testen: een afwijking heeft een concrete oorzaak of herstelvraag; herhaal daarna de betrokken testgevallen en afhankelijke stappen.
• Uitstellen: essentieel bewijs ontbreekt, een blokkerende afwijking blijft open of de bevoegdheid om te beslissen is onduidelijk.

Maak uw geplande wijziging bespreekbaar

Verzamel de wijzigingsbeschrijving, een overzicht van geraakte processtappen en enkele representatieve invoervoorbeelden. Voeg de huidige rechten, gewenste uitkomsten en open testvragen toe. Benoem wie het proces inhoudelijk kent en wie over ingebruikname beslist.

Wilt u de gevolgen voor uw automatisering met ons onderzoeken? Gebruik bedrijfsprocessen automatiseren met AI als vertrekpunt en neem één geplande CRM- of ERP-wijziging mee. Dan kunnen we bespreken welke afhankelijkheden onderzocht moeten worden en welk bewijs nog nodig is voor uw besluit.