Ongestructureerde klantafspraken migreren: Vrije notitievelden omzetten naar harde data

Het fundament van een stabiele uitrol

Elke ERP- of TMS-migratie volgt een voorspelbaar patroon. Het projectteam bouwt nieuwe datamodellen, test koppelingen en plant de cutover. En dan duikt er een categorie data op die zich niet in kolommen laat persen: de vrije notitievelden. Memo’s, opmerkingsvelden, klantspecifieke instructies — vaak tientallen, soms honderdduizenden regels tekst die medewerkers in de loop der jaren handmatig hebben ingevoerd.

Die velden bevatten operationele afspraken die nergens anders zijn vastgelegd. Laadtijden, voertuigvereisten, contactpersonen per locatie, seizoensgebonden uitzonderingen. Bij een directe overbrenging naar een nieuw systeem veranderen die notities in onleesbare strings die geen enkele geautomatiseerde workflow kan interpreteren. Het gevolg: planners vallen terug op telefoon en e-mail, chauffeurs staan voor gesloten poorten, en de beloofde efficiencywinst van het nieuwe systeem verdampt nog voor de livegang.

Het fundament voor een geslaagde migratie ligt daarom niet in de technische infra, maar in de datakwaliteit die eronder zit. Om uw klantdata opschonen of migreren succesvol te laten verlopen, moet u eerst begrijpen wat er in die vrije velden schuilgaat — en hoe je die informatie vertaalt naar harde, bruikbare parameters.

De operationele risico’s van een lift-and-shift strategie

Een 1-op-1 migratie — alle data ongewijzigd overzetten van oud naar nieuw — lijkt de snelste route. In de praktijk creëert die aanpak blinde vlekken die pas zichtbaar worden wanneer het nieuwe systeem live draait en geautomatiseerde workflows de overgenomen vrije tekst proberen te verwerken.

Wat er misgaat in de operatie:

• Distributiecentra en laad-/loslocaties hanteren specifieke tijdvensters, ingangsroutes en voertuigbeperkingen. Wanneer die instructies begraven liggen in een ongestructureerd tekstveld, kan een TMS ze niet meewegen bij routeplanning of slotboeking. Het resultaat: wachturen, afwijzingen aan de poort en handmatige escalaties.

• Facturatie en tariefberekeningen leunen op klantspecifieke condities. Als die condities alleen als vrije tekst bestaan (“korting bij volle vracht, toeslag bij weekend”) mist het systeem de logica om ze automatisch toe te passen. Handmatige correcties na facturatie kosten tijd en schaden de klantrelatie.

• Geautomatiseerde alerts en rapportages werken op gestructureerde velden. Vrije tekst valt buiten elk filter, elke KPI-dashboard en elke uitzondering-trigger.

Gartner publiceerde in december 2021 een persbericht waarin de gemiddelde jaarlijkse kosten van gebrekkige datakwaliteit voor organisaties werden geschat op 12,9 miljoen dollar. Dat cijfer omvat niet alleen directe fouten, maar ook de tijd die medewerkers besteden aan het opsporen, corrigeren en omzeilen van slechte data. Bij een systeemmigratie concentreren die kosten zich in een kort tijdsbestek — precies het moment waarop de organisatie het minste rek heeft.

Een nuance is hier op zijn plaats: organisaties die al volledig gestandaardiseerd via EDI opereren zonder manuele tussenkomst, ervaren deze problematiek in mindere mate. Hun klantafspraken zitten al in gecodeerde berichtformaten. Maar voor de meerderheid van bedrijven die historisch met vrije tekstvelden hebben gewerkt — en dat zijn er veel in transport, expeditie en warehousing — is de lift-and-shift route een recept voor operationele stilstand, mede door het risico op fouten bij de invoer van ERP-gegevens.

Taxonomie: De vertaalslag van tekst naar TMS-parameters

De kern van de oplossing is een taxonomie: een gecontroleerd vocabulaire dat de inhoud van vrije tekstvelden vertaalt naar gedefinieerde databasevelden met vaste invoermogelijkheden. Geen interpretatie meer door individuele medewerkers, maar eenduidige waarden die een systeem kan lezen, filteren en verwerken.

De methodologie verloopt in drie stappen:

1. Inventarisatie: breng met gerichte query’s in kaart welke patronen in de historische data voorkomen. Welke termen duiken herhaaldelijk op? Welke afkortingen worden gebruikt? Welke informatie-categorieën zijn te onderscheiden?

2. Velddefinitie: definieer op basis van die patronen harde variabelen. Denk aan velden als Type Voertuig, Temperatuurrange, Laadklep benodigd (ja/nee), Tijdvenster levering, Contactpersoon locatie.

3. Invoerbegrenzing: richt de nieuwe velden in met drop-down menu’s en strikte validatieregels. Vrije tekst wordt daarmee structureel onmogelijk gemaakt voor toekomstige invoer, wat herhaling van datavervuiling voorkomt.

Patroonherkenning in ruwe data

Grote volumes vrije tekst laten zich niet handmatig scannen. De eerste stap is daarom het uitvoeren van gerichte queries op de legacy-database om frequente termen, afkortingen en structuren te identificeren.

Zoek bijvoorbeeld op:

• Tijdsaanduidingen: patronen als “voor 14:00”, “niet op vrijdag”, “alleen ochtend”

• Voertuigreferenties: “bakwagen”, “koeler”, “mega-trailer”, “busje”

• Locatie-instructies: “achteringang”, “dock 3”, “via slagboom links”

• Contactgegevens: telefoonnummers, namen, functietitels

• Conditionele afspraken: “mits”, “alleen bij”, “niet in combinatie met”

Uit dit soort queries ontstaat een frequentietabel die laat zien welke informatiecategorieën het vaakst voorkomen. Die categorieën vormen de basis voor de nieuwe veldstructuur. Volgens IBM’s definitie van ongestructureerde data maakt dit type informatie naar schatting het overgrote deel uit van alle bedrijfsdata — en groeit het sneller dan gestructureerde data. Zonder actieve conversie blijft die informatie onbenut in elk nieuw systeem.

Praktijkvoorbeeld: Vrije tekst ontleden

Neem de volgende notitie uit een legacy-systeem:

“B12 via achteringang, niet vr. 1400u, koelwagen verplicht”

Voor een ervaren planner is dit leesbaar. Voor een TMS is het een string zonder betekenis. De vertaling naar gestructureerde velden ziet er als volgt uit:

Vrije tekst fragmentDoelveldGestructureerde waardeB12Locatiecode / DockB12via achteringangToegangsrouteAchteringangniet vr. 1400uTijdvensterLevering vóór 14:00 uitgesloten op vrijdagkoelwagen verplichtType voertuigKoelwagen (verplicht)

Eén zin wordt vier discrete, doorzoekbare en filterbare velden. Het TMS kan nu automatisch een koelwagen toewijzen, de routeplanning afstemmen op de juiste ingang, en de planning engine waarschuwen wanneer een vrijdaglevering vóór 14:00 wordt ingepland voor deze klant.

Dit voorbeeld is relatief helder. In de praktijk bevatten notities regelmatig tegenstrijdigheden, verouderde instructies en intern jargon dat per vestiging verschilt. Dat brengt ons bij de vraag waar technologie ophoudt en menselijke interpretatie begint.

Balans tussen RPA en handmatige interpretatie

Extractie van gestructureerde data uit vrije tekst is deels te automatiseren — maar niet volledig. De effectieve aanpak combineert technologie voor het voorwerk met menselijke expertise voor de uitzonderingen.

De grenzen van algoritmes en basis NLP

Reguliere expressies (regex) and basale Natural Language Processing (NLP) zijn effectief als eerste extractielaag. Ze herkennen patronen met een voorspelbare structuur:

• Tijdstippen in formaten als “14:00”, “voor 2 uur”, “ochtend”

• Postcodes en nummerreeksen

• Veelvoorkomende afkortingen die in een woordenlijst zijn vastgelegd

• Ja/nee-indicatoren (“verplicht”, “niet toegestaan”)

Waar de technologie vastloopt:

• Ambiguïteit: “Niet op vrijdag leveren” versus “Niet vóór vrijdag leveren” — één woord verschil, compleet andere instructie.

• Sarcasme en informeel taalgebruik: notities als “liefst gisteren” of “de gebruikelijke chaos bij dock 4” bevatten relevante context die geen algoritme betrouwbaar kan coderen.

• Tegenstrijdige informatie: een veld dat zowel “koelwagen” als “open trailer” vermeldt, waarschijnlijk door een wijziging die nooit correct is bijgewerkt.

• Bedrijfsjargon: interne afkortingen die per vestiging, per team of zelfs per medewerker verschillen. Zonder extensieve domeintraining kan geen enkel taalmodel die betrouwbaar vertalen.

Deloitte beschrijft in een analyse over de combinatie van AI en RPA hoe intelligente automatisering pas waarde levert wanneer de onderliggende data voldoende gestructureerd is. Bij vrije tekstvelden met hoge variabiliteit in taal en context is de foutmarge van puur geautomatiseerde extractie te groot voor operationele beslissingen.

Beslisboom voor data-extractie

De routekaart voor het verwerkingsproces volgt een helder pad:

1. Geautomatiseerde pre-scan: regex en NLP extraheren alle herkenbare patronen (tijden, codes, standaard termen) uit het vrije tekstveld.

2. Betrouwbaarheidsbeoordeling: per geëxtraheerd gegeven wordt getoetst of het eenduidig is. Past het resultaat binnen de gedefinieerde taxonomie zonder interpretatie? → Door naar geautomatiseerde mapping.

3. Uitvalbak: records waar de extractie meerdere mogelijke interpretaties oplevert, waar velden tegenstrijdig zijn, of waar onbekende termen voorkomen, gaan naar de menselijke verwerkingslijn.

4. Domeinexpert-review: menselijke specialisten toetsen de uitvalrecords aan actuele verkoopdossiers, klantovereenkomsten en operationele kennis. Zij bepalen de correcte vertaling en vullen de gestructureerde velden handmatig in.

5. Terugkoppeling naar het model: patronen die de domeinexperts herhaaldelijk tegenkomen, worden als nieuwe regels aan de geautomatiseerde pre-scan toegevoegd. Zo wordt de uitvalbak bij elke iteratie kleiner.

Dit hybride proces voorkomt twee extremen: volledig handmatige verwerking (te traag en te duur bij grote volumes) and volledig geautomatiseerde verwerking (te foutgevoelig bij complexe notities). De sleutel zit in het scherp definiëren van de grens — en die grens verschuift naarmate het model meer domeinkennis opbouwt.

Validatie voor de definitieve datamigratie

Gestructureerde data is pas bruikbaar als ze klopt. Voordat het oude systeem wordt afgesloten, moet de nieuwe datastructuur bewezen hebben dat ze de operatie correct kan aansturen.

Schaduwdraaien met operationele data

De meest betrouwbare validatiemethode is schaduwdraaien: de nieuwe datastructuur naast het bestaande systeem laten meelopen op historische of actuele zendingen. Concreet betekent dit:

• Herberekening op historische orders: neem een representatieve set voltooide zendingen en laat het nieuwe systeem — gevoed met de gestructureerde data — de planning, routering en facturatie opnieuw doorrekenen. Vergelijk het resultaat met de werkelijke uitvoering.

• Discrepantie-analyse: elk verschil tussen de oorspronkelijke orderafhandeling en de herberekening is een signaal. Was de afwijking het gevolg van een fout in de brondata, een interpretatieverschil bij de conversie, of een tekortkoming in de nieuwe veldstructuur?

• Iteratieve correctie: gevonden discrepanties worden teruggevoerd naar het conversieteam. De taxonomie wordt bijgesteld, extractieregels worden aangescherpt, en de schaduwberekening wordt herhaald tot de afwijkingen binnen acceptabele marges vallen.

Accenture beschrijft in een publicatie over intelligente datamigratie dat organisaties die een parallelle testfase overslaan, een verhoogd risico lopen op kostbare rollbacks na livegang. Het schaduwdraaien kost tijd, maar die investering weegt niet op tegen de kosten van een systeem dat live gaat met foutieve klantafspraken.

Criteria voor formele systeembevriezing

Het legacy-systeem wordt pas bevroren — definitief op read-only gezet — wanneer aan een reeks voorwaarden is voldaan:

• Ordercompleteness: de geschoonde dataset reproduceert de uitkomsten van historische orders binnen vooraf vastgestelde toleranties. Geen openstaande discrepanties zonder verklaring.

• Stakeholder-aftekening: zowel operationele teams (planning, warehouse, transport) als financiële afdelingen (facturatie, contractbeheer) hebben de resultaten van het schaduwdraaien gereviewed en formeel goedgekeurd.

• Terugvalscenario gedocumenteerd: er ligt een plan voor het geval de nieuwe omgeving onvoorziene problemen geeft in de eerste weken na go-live. Dat plan omvat toegang tot de legacy-data in read-only modus, niet het heropenen van het oude systeem voor bewerkingen.

• Nieuwe invoerprocessen actief: de gestructureerde invoer met validatieregels en drop-downs is operationeel. Medewerkers zijn getraind. Vrije tekstvelden zijn afgesloten of verwijderd uit de invoerschermen.

Pas wanneer al deze elementen op groen staan, is de bevriezing van de oude database verantwoord. Een te vroege cutover — gedreven door projectdruk of deadlines — is een van de meest voorkomende oorzaken van mislukte migraties.

Conclusie en volgende stappen

Het converteren van vrije klantnotities naar gestructureerde TMS-parameters is geen bijzaak van een migratie — het bepaalt of het nieuwe systeem de operatie daadwerkelijk kan aansturen. Technologie versnelt de extractie, maar levert alleen betrouwbare resultaten wanneer de basisdata door menselijke experts is gevalideerd. Schaduwdraaien op historische orders biedt de laatste controlelaag voordat het oude systeem wordt afgesloten.

Wie wil voorkomen dat specifieke laad- en losinstructies verloren gaan of foutief in een nieuw systeem belanden, kan het werk omtrent klantdata opschonen of migreren uitbesteden aan DataMondial. Hun team structureert complexe logistieke data vanuit beveiligde EU-productielocaties in Roemenië, met een combinatie van geautomatiseerde extractie en domeinexpertise.