Migration unstrukturierter Kundenvereinbarungen: Freitextfelder in harte Daten umwandeln

Das Fundament eines stabilen Rollouts

Jede ERP- oder TMS-Migration folgt einem vorhersehbaren Muster. Das Projektteam entwickelt neue Datenmodelle, testet Schnittstellen und plant den Cutover. Und dann taucht eine Datenkategorie auf, die sich nicht in Raster pressen lässt: Freitextfelder. Memos, Bemerkungen, kundenspezifische Anweisungen – oft Dutzende, manchmal Hunderttausende von Textzeilen, die von Mitarbeitern im Laufe der Jahre manuell eingegeben wurden.

Diese Felder enthalten operative Vereinbarungen, die sonst nirgends dokumentiert sind. Ladezeiten, Fahrzeuganforderungen, Kontaktpersonen pro Standort, saisonale Ausnahmen. Bei einer direkten Übertragung in ein neues System verwandeln sich diese Notizen in unlesbare Zeichenfolgen, die von keinem automatisierten Workflow interpretiert werden können. Die Folge: Disponenten greifen notgedrungen auf Telefon und E-Mail zurück, Fahrer stehen vor verschlossenen Toren und die versprochenen Effizienzgewinne des neuen Systems verpuffen bereits vor dem Go-Live.

Das Fundament für eine erfolgreiche Migration liegt daher nicht in der technischen Infrastruktur, sondern in der zugrunde liegenden Datenqualität. Um das Vorhaben, Ihre Kundendaten zu bereinigen oder zu migrieren, erfolgreich abzuschließen, müssen Sie zunächst verstehen, was sich in diesen Freifeldnotizen verbirgt – und wie Sie diese Informationen in belastbare, nutzbare Parameter übersetzen.

Die operativen Risiken einer Lift-and-Shift-Strategie

Eine 1:1-Migration – die unveränderte Übertragung aller Daten vom alten ins neue System – erscheint meist als der schnellste Weg. In der Praxis entstehen durch diesen Ansatz jedoch blinde Flecken, die erst dann sichtbar werden, wenn das neue System live ist und automatisierte Workflows versuchen, den übernommenen Freitext zu verarbeiten.

Was im operativen Geschäft schiefgeht:

• Distributionszentren und Be-/Entladeorte wenden spezifische Zeitfenster, Zufahrtswege und Fahrzeugbeschränkungen an. Wenn diese Anweisungen in einem unstrukturierten Textfeld vergraben sind, kann ein TMS sie bei der Routenplanung oder Slotbuchung nicht berücksichtigen. Das Ergebnis: Wartezeiten, Abweisungen an der Laderampe und manuelle Eskalationen.

• Abrechnungen und Tarifberechnungen stützen sich auf kundenspezifische Konditionen. Liegen diese Bedingungen nur als Freitext vor („Rabatt bei Komplettladung, Wochenendzuschlag“), fehlt dem System die Logik, sie automatisch anzuwenden. Manuelle Korrekturen nach der Rechnungsstellung kosten Zeit und schaden der Kundenbeziehung.

• Automatisierte Alerts und Reportings basieren auf strukturierten Feldern. Freitext fällt durch jedes Raster, entgeht jedem KPI-Dashboard und löst keine vordefinierten Warnungen aus.

Gartner veröffentlichte im Dezember 2021 eine Pressemitteilung, in der die durchschnittlichen jährlichen Kosten mangelhafter Datenqualität für Unternehmen auf 12,9 Millionen Dollar geschätzt wurden. Diese Zahl umfasst nicht nur direkte Fehler, sondern auch die Zeit, die Mitarbeiter damit verbringen, unzuverlässige Daten aufzuspüren, zu korrigieren und zu umgehen. Bei einer Systemmigration konzentrieren sich diese Kosten in einem kurzen Zeitfenster – genau zu dem Zeitpunkt, an dem die Organisation am wenigsten Spielraum für Verzögerungen hat.

Eine kleine Nuance ist hier angebracht: Unternehmen, die bereits vollständig standardisiert über EDI ohne manuelle Eingriffe arbeiten, sind von dieser Problematik weniger betroffen. Ihre Kundenvereinbarungen liegen längst in codierten Nachrichtenformaten vor. Doch für die Mehrheit der Unternehmen, die historisch bedingt mit Freitextfeldern arbeiten – und das sind im Bereich Transport, Spedition und Warehousing besonders viele – ist der Lift-and-Shift-Ansatz ein Garant für operativen Stillstand, nicht zuletzt durch das erhöhte Risiko für Fehler bei der Eingabe von ERP-Daten.

Taxonomie: Die Übersetzung von Text in TMS-Parameter

Der Kern der Lösung ist eine Taxonomie: ein kontrolliertes Vokabular, das den Inhalt von Freitextfeldern in definierte Datenbankfelder mit festen Eingabemöglichkeiten übersetzt. Keine Interpretation mehr durch einzelne Mitarbeiter, sondern eindeutige Werte, die ein System maschinell lesen, filtern und verarbeiten kann.

Die Methodik verläuft in drei Schritten:

1. Bestandsaufnahme: Kartieren Sie mithilfe gezielter Queries die Muster, die in den historischen Daten vorkommen. Welche Begriffe tauchen wiederholt auf? Welche Abkürzungen werden verwendet? Welche Informationskategorien lassen sich klar separieren?

2. Felddefinition: Auf Basis dieser Muster werden harte Variablen definiert. Zu denken ist hier an Felder wie Fahrzeugtyp, Temperaturbereich, Hebebühne erforderlich (Ja/Nein), Zeitfenster Lieferung oder Ansprechpartner vor Ort.

3. Eingabebeschränkung: Die neuen Felder werden mit Dropdown-Menüs und strikten Validierungsregeln eingerichtet. Freitext wird damit fürzukünftige Eingaben strukturell unmöglich gemacht, was eine erneute Datenverschmutzung dauerhaft verhindert.

Mustererkennung in Rohdaten

Große Volumina an Freitext lassen sich nicht manuell erfassen. Der erste Schritt ist daher die Ausführung gezielter Queries über die Legacy-Datenbank, um häufige Begriffe, Abkürzungen und Strukturen zu identifizieren.

Suchen Sie beispielsweise gezielt nach:

• Zeitangaben: Muster wie „vor 14:00“, „nicht am Freitag“, „nur vormittags“

• Fahrzeugreferenzen: „Kofferfahrzeug“, „Kühler“, „Megatrailer“, „Transporter“

• Standortanweisungen: „Hintereingang“, „Tor 3“, „über Schranke links“

• Kontaktdaten: Telefonnummern, Namen, Positionsbezeichnungen

• Bedingte Vereinbarungen: „sofern“, „nur bei“, „nicht in Kombination mit“

Aus derartigen Queries entsteht eine Häufigkeitstabelle, die zeigt, welche Informationskategorien am öftesten vorkommen. Diese Kategorien bilden die Grundlage für die neue Feldstruktur. Gemäß der Definition von IBM für unstrukturierte Daten macht diese Art von Information schätzungsweise den Löwenanteil aller Unternehmensdaten aus – und wächst schneller als strukturierte Daten. Ohne aktive Konvertierung bleiben diese essenziellen Informationen in jedem neuen System ungenutzt.

Praxisbeispiel: Freitext dekonstruieren

Betrachten Sie die folgende Notiz aus einem alten System:

„B12 über Hintereingang, nicht Fr. 1400 Uhr, Kühlfahrzeug zwingend“

Für einen erfahrenen Disponenten ist das leicht zu entschlüsseln. Für ein TMS ist es ein String ohne Bedeutung. Die Übersetzung in strukturierte Felder sieht wie folgt aus:

FreitextfragmentZielfeldStrukturierter WertB12Standortcode / DockB12über HintereingangZugangswegHintereingangnicht Fr. 1400 UhrZeitfensterLieferung vor 14:00 Uhr am Freitag ausgeschlossenKühlfahrzeug zwingendFahrzeugtypKühlfahrzeug (obligatorisch)

Ein unscheinbarer Satz wird so zu vier diskreten, durchsuchbaren und filterbaren Feldern. Das TMS kann nun vollautomatisch ein Kühlfahrzeug zuweisen, die Routenprüfung auf den richtigen Eingang abstimmen und die KI-gestützte Planung warnen, wenn für diesen Kunden eine Freitagszustellung vor 14:00 Uhr vorgesehen wird.

Dieses Beispiel ist vergleichsweise übersichtlich. In der Praxis enthalten Notizen jedoch regelmäßig Widersprüche, veraltete Anweisungen und internen Fachjargon, der sich sogar von Standort zu Standort unterscheidet. Das führt unausweichlich zu der Frage, wo Technologie endet und menschliche Interpretation beginnt.

Die Balance zwischen RPA und manueller Interpretation

Die Extraktion strukturierter Daten aus Freitexten lässt sich teilweise automatisieren – jedoch niemals vollständig. Der bewährteste und effektivste Ansatz kombiniert Automatisierungstechnologien für die Vorarbeit mit tiefgreifender menschlicher Expertise für die Ausnahmen.

Die Grenzen von Algorithmen und Basis-NLP

Reguläre Ausdrücke (Regex) und elementares Natural Language Processing (NLP) sind als erste Extraktionsschicht überaus wirkungsvoll. Sie erkennen vorhersehbare Strukturen:

• Uhrzeiten in logischen Formaten wie „14:00“, „vor 2 Uhr“, „früher Vormittag“

• Postleitzahlen und festgelegte Nummernkreise

• Typische Abkürzungen, die in einer hinterlegten Datenbank existieren

• Ja/Nein-Indikatoren („verpflichtend“, „nicht zugelassen“)

Woran die Technologie hingegen scheitert:

• Ambiguität: „Nicht am Freitag liefern“ im Vergleich zu „Nicht vor Freitag liefern“ – ein kleines Wort macht in der Logistik einen gewaltigen Unterschied.

• Sarkasmus und umgangssprachliche Formulierungen: Notizen wie „am besten gestern“ oder „das übliche Chaos bei Rampe 4“ enthalten wichtigen Kontext, den kein Algorithmus verlässlich decodieren kann.

• Widersprüchliche Informationen: Ein Feld, das aus historischen Gründen sowohl „Kühlfahrzeug“ als auch „Offener Trailer“ erwähnt – höchstwahrscheinlich, weil ein Update nie bereinigt wurde.

• Unternehmensjargon: Interne Abkürzungen, die sich je nach Niederlassung, Team oder sogar Mitarbeiter unterscheiden. Ohne tiefgreifendes und teures Custom-Training kann ein Standard-Sprachmodell das niemals zuverlässig zuordnen.

Deloitte beschreibt in einer Analyse über das Zusammenspiel von KI und RPA sehr treffend, dass intelligente Automatisierung erst dann wirklich Mehrwert liefert, wenn die zugrunde liegenden Daten in ausreichender Struktur vorliegen. Bei Freitextfeldern, die stark in Sprache und Kontext variieren, ist die Fehlerquote einer rein automatisierten Extraktion für echte operative Entscheidungen schlichtweg zu hoch.

Entscheidungsbaum für die Datenextraktion

Die strategische Roadmap für den Verarbeitungsprozess folgt einem zweigeteilten, klaren Pfad:

1. Automatisierter Pre-Scan: Regex und NLP extrahieren in Millisekunden alle offensichtlich erkennbaren Muster (Zeiten, Logistikcodes, Standardbegriffe) aus dem Freitextfeld.

2. Konfidenzprüfung: Für jedes extrahierte Ergebnis wird geprüft, ob es wirklich eindeutige Treffer aufweist. Fügt sich das Ergebnis zweifelsfrei in die definierte Taxonomie ein? → Automatisiertes Mapping findet statt.

3. Ausnahme-Queue (Exception Handling): Sämtliche Datensätze, bei denen die Software mehrere Interpretationen zulässt, widersprüchliche Felder entdeckt oder auf komplett unbekannte Begrifflichkeiten stößt, flattern direkt in die Warteschlange der menschlichen Sachbearbeitung.

4. Prüfung durch Domain-Experten: Menschliche Spezialisten gleichen die markierten Datensätze mit aktuellen Vertriebsakten, Rahmenverträgen und ihrem operativen Fachwissen ab. Erst sie definieren die korrekte Übersetzung ins System und befüllen die strukturierten Einzelfelder fehlerfrei.

5. Rückkopplung zum Datenmodell: Jeder wiederkehrende Sonderfall, die den Experten auffällt, wird dem Algorithmus in Form von neuen Regeln zur Verfügung gestellt. Auf diese Weise lernt das System und die Fehlerquote in der Ausnahmeliste sinkt beständig.

Solch ein hybrider Prozess bewahrt Unternehmen vor zwei toxischen Extremen: vollflächig manueller Verarbeitung (kostet bei hohen Volumen viel zu viel Zeit und Budget) und vollständig automatisierter Verarbeitung (provoziert in der Praxis chaotische operative Fehler bei komplexen Kundenwünschen). Der Erfolg liegt im Feintuning dieser Grenze – eine Schwelle, die sich kontinuierlich verschiebt, je besser das Modell trainiert wird.

Validierung vor der definitiven Datenmigration

Strukturierte Daten entfachen ihren Wert nur dann, wenn sie nachweislich stimmen. Bevor das Altsystem vom Netz geht, muss in der neuen Datenumgebung absolut sichergestellt sein, dass das operative Tagesgeschäft nicht ins Straucheln gerät.

Shadow-Testing mit echten Betriebsdaten

Der sicherste und robusteste Validierungsansatz ist das sogenannte Shadow-Testing: Man lässt das neue Datenset exakt parallel zu realen, teilweise historischen Sendungsabwicklungen im Sandkasten mitlaufen. Konkret umfasst das:

• Prüfung durch Neuberechnung vergangener Aufträge: Füttern Sie das frisch strukturierte TMS mit einer repräsentativen Stichprobe real abgeschlossener Sendungen. Überlassen Sie der Engine die Disposition, das Routing und auch das Pricing anhand der neuen Felder. Vergleichen Sie dieses theoretische Resultat messscharf mit der tatsächlichen, historischen Ausführung.

• Diskrepanzanalyse: Jeder Abweicher – sei es ein falsch priorisierter LKW oder ein ungültiger Zuschlag – funktioniert als Alarmsignal. Entstand das Problem durch schlechte historische Quelldaten, wurde bei der Feldstrukturiereung eine Nuance verfälscht oder mangelt es dem neuen TMS schlicht an einer bestimmten Variable?

• Iterative Korrektur der Regeln: Identifizierte Defizite gehen umgehend in die Feedback-Schleife der Datenexperten. Taxonomien werden nachgeschärft, Extraktionsregeln verfeinert und Shadow-Tests erneut gefahren, bis alle Abweichungen in die geschäftlich tolerierbare Marge absinken.

Accenture unterstreicht dies in entsprechenden Publikationen über Datenstrategien sehr deutlich: Jede Großorganisation, die aus Zeitnot auf dedizierte Paralleltests verzichtet, provoziert damit nach dem Go-Live teurste Fehler und schlimmstenfalls umfassende Rollbacks. Das Shadow-Testing bindet zwar Ressourcen, schützt jedoch das Unternehmen vor systemweiten Ausfällen oder tiefgreifendem Kundenärger durch vermurkste Lieferanweisungen.

Kriterien für den formalen System-Freeze

Erst, wenn bestimmte Meilensteine sicher abgenommen sind, wird das alte Legacy-System formal auf Read-Only gesetzt – sprich: für neue Eingaben eingefroren:

• Order Completeness Data: Das massiv gesäuberte Daten-Set spuckt im Paralleltest Resultate aus, die sich bis auf tolerierbare Kommastellen mit historischen Wahrheiten decken. Unerklärte Leerstellen oder systematische Routenfehler existieren nicht mehr.

• Offizielle Stakeholder-Freigabe: Repräsentanten der operativen Ausführung (Disposition, Warehousing, Fuhrparkleitung) sowie der Financials (Abrechnung und Controlling) haben das Shadow-Testing abgenommen und per Unterschrift verifiziert.

• Klares Fallback-Szenario: Es existiert ein Worst-Case-Handbuch für Kinderkrankheiten in den kritischen Wochen eins und zwei des Go-Lives. Dieses gewährt Einsicht in alte Auftragsstrukturen im Read-Only-Format (Sichtprüfung), erlaubt aber keineswegs ein konzeptionelles Aufweichen und Rückwechseln ins Altsystem.

• Schulung der neuen Erfassungslogik: Die neuen, mit Dropdowns limitierten Systeme sind nicht nur live geschaltet, sondern das operative Team versteht auch den Zwang der validierten Formularfelder. Freitextfelder sind für die Zukunft blockiert oder softwareseitig gänzlich beschnitten worden.

Wenn alle diese Kriterien auf Grün stehen, ist das Ausschalten der alten Systeme vertretbar. Wer aus reinem Projektdruck vorzeitig in ein unzureichend getestetes Datenumfeld springt, ebnet den wohl häufigsten Weg für grandios gescheiterte IT-Migrationen.

Fazit und nächste Schritte

Die Konvertierung freitextlicher Kundeninformationen in strukturierte Parameter eines Transportmanagement-Systems ist folglich keine zweitrangige Begleiterscheinung. Sie ist vielmehr die Grundvoraussetzung dafür, dass Hightech-Algorithmen und Disponenten effizient agieren können. KI-basierte Technologie ist zwar in der Lage, Datengewinnung stark zu komprimieren und vorzufiltern – doch wirklich vertrauenswürdig wird dieses Material erst, wenn es im Zweifel durch menschliche Branchenkenner plausibilisiert wird. Das abschließende Shadow-Testing simuliert schließlich das unerbittliche Alltagsgeschäft.

Manager, die kompromisslos sicherstellen wollen, dass sensible Lade- und Entladevorschriften im Zuge moderner IT-Projekte weder durchs Raster fallen noch chaotisch ins neue Setup migriert werden, lagern die Aufgabe aus. Wenn es darum geht, Kundendaten zu bereinigen oder zu migrieren, stellt DataMondial den strategischen Partner dar. Das BPO-Experten-Team analysiert und strukturiert von hochkomplexen EU-Standorten in Rumänien aus schwerfällige Logistik-Datensätze. Dabei verschmelzen wir das rasante Tempo KI-gestützter Skripte mit jahrelanger, tief verwurzelter Erfahrung und Branchenkompetenz.