Standardisierung komplexer Carrier Sheets: So erstellen Sie in 4 Stunden fehlerfreie Angebote
Die Auswirkungen unstrukturierter Daten auf die Durchlaufzeiten
Die Geschwindigkeit, mit der ein Spediteur eine Seefrachtrate kalkulieren und anbieten kann, diktiert die Erfolgsquote (Hit-Rate) der Angebote. Reedereien und NVOCCs verteilen ihre Frachtraten in einer Vielzahl von Formaten: von strukturierten Excel-Dateien über flache PDF-Dokumente bis hin zu unformatierten E-Mail-Texten. Das rechtzeitige Verarbeiten von Seefrachtraten durch automatische Extraktion, Interpretation und Übertragung in ein Transport Management System (TMS) verhindert direkte Verzögerungen im operativen Prozess. Dies führt zu deutlich kürzeren Durchlaufzeiten für Vertriebsteams, die auf aktuelle Einkaufsdaten angewiesen sind.
Der Schwerpunkt dieser Verzögerung liegt in der Komplexität der Surcharges (Zuschläge). Während die Basis-Seefrachtrate (Ocean Freight) übersichtlich ist, schwanken lokale Zuschläge wie Terminal Handling Charges (THC), der ISPS-Zuschlag und Schwergutzuschläge je nach Hafen und Carrier enorm [1]. Das manuelle Entschlüsseln der Gültigkeit und der spezifischen Bedingungen dieser Nebenkosten führt zu einem hohen Risiko für Kalkulationsfehler und Margenverluste.
Ein hybrides Verarbeitungsmodell, das Robotic Process Automation (RPA) mit menschlicher Qualitätskontrolle kombiniert, reduziert die Verarbeitungszeit eines komplexen Carrier Sheets auf maximal vier Stunden.
| Prozessschritt (Batch von 500 Tarifzeilen) | Manuelle Verarbeitung (Stunden) | Hybrides Verarbeitungsmodell (Stunden) |
|---|---|---|
| Dokumenteneingang und Triage | 2,5 | 0,2 |
| Datenextraktion der Basisraten | 6,0 | 0,5 |
| Interpretation und Eingabe von Surcharges | 8,5 | 1,0 |
| Validierung und Datenbereinigung | 4,0 | 1,8 |
| Export in TMS / Datenbank | 1,0 | 0,1 |
| Gesamte Verarbeitungszeit | 22,0 Stunden | 3,6 Stunden |
Schritt 1: Klassifizierung eingehender Dateiformate
Bevor mit der automatischen Datenextraktion begonnen wird, durchlaufen alle eingehenden Dokumente eine strenge Triage. Automatisierungstools funktionieren primär auf Basis von Vorhersehbarkeit. Jede eingehende E-Mail-Anlage ungesehen an eine Optical Character Recognition (OCR) Engine weiterzuleiten, führt unweigerlich zu fehlerhaften Daten und Systemausfällen.
Triage ist der Prozess, bei dem Dokumente vorab anhand ihrer Dateistruktur getrennt werden. Ein Mitarbeiter oder ein Klassifizierungsalgorithmus scannt den Posteingang und trennt die PDF-Matrizen von abweichenden Excel-Dateien. Sobald die Struktur ermittelt ist, erfolgt die Zuweisung zur passenden Extraktionsmethode. Strukturierte Dokumente fließen direkt in den RPA-Prozess ein. Dateien ohne logisches Layout werden an ein spezialisiertes BPO-Team zur manuellen Aufbereitung oder direkten Eingabe weitergeleitet.
Kriterien für die Sortierung von Dateien zur direkten Extraktion:
- Dateiendungstyp (.xlsx, .csv, iteratives .pdf)
- Vorhandensein von vektorisiertem Text statt Rastergrafiken
- Erkennbarkeit des Absenders (gekoppelt an bekannte Carrier-Templates)
- Konsistente Zeilen- und Spaltenstruktur ohne wechselnde Zellverbindungen pro Seite
Kategorisierung eingehender Quelldateien
Dokumententypen bringen beim Auslesen jeweils eigene technische Herausforderungen mit sich. Eine .csv- oder saubere Excel-Tabelle enthält Daten in klar definierten Zellen. Ein Skript kann diese Spalten direkt einlesen. Ein Vektor-PDF (generiert aus einem digitalen System) enthält Text, der von der Software als Textebene erkannt wird. Hier kann ein OCR-Tool mit hoher Genauigkeit Koordinaten bestimmen.
Ein gescanntes PDF (Raster) ist aus technischer Sicht lediglich ein Bild. Dessen Extraktion erfordert einen zusätzlichen Übersetzungsschritt, bei dem die Software Pixel in Zeichen umwandelt. Dies erhöht die Fehlerquote, insbesondere bei kleinen Schriftarten oder Kompressionsartefakten. Unformatierte E-Mail-Texte, in denen Raten als Fließtext in wechselnden Absätzen stehen, bieten keine Ankerpunkte für Templates und blockieren die reguläre Mustererkennung.
Checkliste: Bewertungskriterien für OCR-Readiness
Ein Carrier Sheet muss spezifische Voraussetzungen erfüllen, um ohne manuelle Korrekturschleife von einer Text-Mining-Anwendung verarbeitet werden zu können.
- Minimale Auflösung von 300 DPI: Zwingend erforderlich bei gescannten Dokumenten, um Verwechslungen von Zeichen (z. B. den Buchstaben ‚rn‘ mit dem Buchstaben ‚m‘) zu vermeiden.
- Auswählbarer Text (Vektorbasiert): Textebenen müssen digital generiert sein, damit die Extraktionssoftware Zeichen liest und nicht Pixel raten muss.
- Konsistente Tabellenstruktur: Spalten für ‚Origin‘, ‚Destination‘, ’20FT‘ und ’40FT‘ müssen auf jeder Folgeseite auf exakt derselben horizontalen Achse liegen.
- Keine verschachtelten oder verbundenen Datenfelder: Cell Merging, bei dem ein Hafen an mehrere Preise über verschiedene Zeilen gekoppelt ist, stört den linearen Datenfluss.
- Einheitliche Typografie: Verwendung von Standard-Schriftarten ohne handschriftliche Anmerkungen, Wasserzeichen oder überlappende Carrier-Logos in den Datenfeldern.
Schritt 2: Datenextraktion und Validierungsregeln definieren
Nach der Klassifizierung fließen die OCR-Ready-Daten in die RPA-Infrastruktur. Ein RPA-Bot liest Dokumente mithilfe vordefinierter Extraktionsregeln (Templates). Diese Templates enthalten Koordinaten und ‚Regular Expressions‘ (RegEx), die nach spezifischen Textmustern suchen. Der Bot identifiziert eine Spaltenüberschrift, sucht nach dem zugehörigen Datenwert und extrahiert diesen in eine temporäre Staging-Datenbank.
Während dieses Schritts führt die Software Validierungen auf Basis von Stammdaten (Master Data) durch. Das System gleicht die extrahierten Datumsfelder mit logischen Bandbreiten ab (z. B. darf eine Gültigkeitsdauer nicht in der Vergangenheit liegen). Währungscodes werden mit dem ISO-4217-Standard abgeglichen. Notiert eine Reederei ‚USD‘ als ‚$‘ oder ‚US Dollars‘, normalisiert das Skript diesen String wieder auf den Datenbankstandard ‚USD‘. Diese strikte Normalisierung ist eine Grundvoraussetzung, um Kalkulationen im FMS (Freight Management System) reibungslos durchführen zu können.
Extraktionsregeln für Hafenterminologie
Reedereien verwenden oftmals interne Abkürzungen für dieselben logistischen Knotenpunkte. Um Lade- und Löschhäfen (Port of Loading / Port of Discharge) fehlerfrei zuzuordnen, greift ein RPA-Skript auf ein festgelegtes Data Dictionary zurück, das meist auf dem UN/LOCODE-Standard basiert.
Ein Template übersetzt ‚RTM‘, ‚NLROT‘ oder ‚Rotterdam Port‘ einheitlich zu ‚NL RTM‘. Die Extraktionsregel sucht in der Zeichenfolge zunächst nach dem naheliegendsten UN/LOCODE. Wird dieser nicht gefunden, prüft das System geografische Ankerpunkte innerhalb der Zelle. Durch diese Art des Mappings wird ausgeschlossen, dass eine Rate für den ‚Port of Shanghai‘ scheitert, nur weil eine Reederei ihn als ‚CN SHA‘ schreibt, während das Zielsystem ausschließlich ‚CNSHA‘ akzeptiert.
Mapping komplexer Surcharges
Die Basisfrachtrate (Core Freight) ist innerhalb des Gültigkeitszeitraums in der Regel statisch, Surcharges jedoch nicht. Die Konfiguration der Logik für diese Zusatzkosten erfordert bedingte Anweisungen (Conditional Instructions) innerhalb der Extraktionsplattform.
Der Bunker Adjustment Factor (BAF) ist ein Zuschlag für schwankende Treibstoffpreise. Das Flexport-Glossar definiert BAF als: „a fee to adjust for the fluctuating costs of fuel“. Extraktionssoftware muss erkennen, ob ein BAF im Blatt inklusive oder exklusive des Basisbetrags ausgewiesen ist. Durch den Aufbau einer Wenn-Dann-Logik (If-Then) liest das System die Fußnoten des Carrier Sheets. Steht dort „BAF subject to monthly review“, ordnet das Skript diesem spezifischen Datenfeld eine begrenzte Gültigkeit (Valid to) zu – unabhängig von der Gültigkeit der Basisrate. Diese aufgeschlüsselten Daten werden anschließend per API in die richtigen Kostenzeilen der internen Plattform injiziert.
Schritt 3: Hybride Qualitätskontrolle anwenden
Eine vollständig automatisierte Lösung stößt schnell an die Grenzen der unbeständigen Realität globaler Supply Chains. RPA-Algorithmen arbeiten rein auf der Basis programmierter Regeln; ihnen fehlt die kontextuelle Intelligenz. Reedereien ändern regelmäßig das Layout ihrer Dokumentationen, fügen ohne Vorankündigung neue oder temporäre lokale Gebühren (wie Wartezeitzuschläge bei Hafenstau) hinzu oder ändern unerwartet die Währung einer spezifischen Route.
In solchen Momenten gerät ein Algorithmus ins Stolpern. Das System liest Daten aus einer verschobenen Spalte aus oder ignoriert einen neuen Zuschlag gänzlich. Dies verursacht unsichtbare Kalkulationsfehler. Genau hier greift das hybride Modell: Der Algorithmus ist mit Vertrauenswerten (Confidence Levels) programmiert. Fällt ein Zellwert oder ein Muster unter einen zuvor festgelegten Schwellenwert, stoppt der Bot die Verarbeitung dieser spezifischen Zeile, und der Vorgang wird zur Eskalation an ein Dashboard gesendet.
Geschulte Datenexperten bearbeiten diese Ausnahmefälle umgehend. Die Ansiedlung dieser Fachkräfte innerhalb der europäischen Zeitzone stellt sicher, dass Korrekturen während der regulären Bürozeiten erfolgen. Dies ermöglicht die Einhaltung straffer SLA-Vorgaben. Das Modell garantiert, dass der Betrieb nicht durch Verzögerungen außerhalb der Kernarbeitszeiten ins Stocken gerät, und gewährleistet gleichzeitig die strenge Einhaltung der EU-Compliance im Datenmanagement. So können Teams, die Seefrachtraten verarbeiten, die gestoppten Zeilen validieren, direkt im Quellsystem korrigieren und den Daten-Upload innerhalb der vorgegebenen vier Stunden abschließen.
Verifizierung abweichender Zuschläge durch Datenexperten
Sonderfälle, wie etwa ein manueller Zusatz in einem PDF, der besagt „Zuschlag Y gilt nicht für Kunde X“, fallen aus dem Raster der regulären Mustererkennung. Der Datenexperte betrachtet die Quelle im Validierungs-Dashboard parallel zu den extrahierten Feldern. Der Spezialist interpretiert die kommerzielle Bedeutung dieser Anmerkung, fügt die entsprechende Ausnahme durch eine manuelle Korrektur ein (Human-in-the-loop) und trainiert damit in einigen Fällen den zugrundeliegenden Algorithmus direkt für eine künftige Konfrontation mit genau dieser Ausnahme.
Wenn vollständige Standardisierung nicht ausreicht
Für die Verarbeitung langfristiger Verträge mit monatlichen Updates bietet die Automatisierung eine unübertroffene Effizienz. Es gibt jedoch Szenarien, in denen eine reine Datenstandardisierung wirtschaftlich unvernünftig ist.
Ein Spediteur erhält täglich Ad-hoc-Anfragen und Spot Rates für Gelegenheitsladungen. Diese Tarife erreichen die Einkaufsabteilung häufig über Plattformen wie WhatsApp, WeChat oder stark fragmentierte, kurzlebige E-Mail-Verläufe. Das Erstellen, Testen und Implementieren eines RPA-Skripts oder eines komplexen OCR-Templates für ein einmaliges Format verschlingt unnötig viele Entwicklerstunden.
Wenn eine Frachtanfrage kein festes, wiederkehrendes Layout aufweist oder ein extrem geringes Volumen hat, übersteigen die Betriebskosten der Automatisierung ihren Nutzen. Die Interpretation einer einmaligen, unstrukturierten E-Mail und die anschließende Dateneingabe in das TMS wird von einem qualifizierten Mitarbeiter in der halben Zeit und zu einem Bruchteil der Programmierkosten erledigt. Eine effiziente Backoffice-Strategie leitet massenhafte, wiederkehrende Tarifblätter durch die RPA-Infrastruktur – und reserviert die menschliche Kapazität explizit für den dynamischen, unstrukturierten Spotmarkt.
Direkte Implementierung für ein skalierbares Ratenmanagement
Der Einsatz einer strikten Dateiklassifizierung und maßgeschneiderter Extraktionsregeln verwandelt einen schwerfälligen manuellen Prozess in einen vorhersehbaren Datenstrom. Durch die Isolierung abweichender Zuschläge und den Einsatz gezielter, menschlicher Qualitätskontrolle bei diesen Ausnahmen, sichern Sie die Datenintegrität (Data Accuracy) innerhalb Ihres TMS – ohne die Flexibilität Ihres Einkaufs einzubüßen. Die strukturelle Datenverarbeitung führt unweigerlich zu Skalierbarkeit: Ihr Pricing-Desk kann höhere Angebotsvolumina bei reduziertem operativem Risiko und geringeren Kosten dank Nearshoring und intelligentem BPO abwickeln.
Verhindern Sie, dass Account Manager unproduktive Stunden auf Dateneingaben verschwenden. Um Ihre Wettbewerbsposition zu stärken, können Sie jetzt die Verarbeitung von Seefrachtraten über die hybride Lösung von DataMondial abbilden, bei der fortschrittliche RPA-Systeme Hand in Hand mit zertifizierten Datenexperten aus unserem Operations Center in Rumänien arbeiten. Unsere Arbeitsweise ermöglicht es Spediteuren, eingehende Tarifblätter kontinuierlich innerhalb von vier Stunden strukturell zu verarbeiten und zu aktualisieren – in vollem Einklang mit den europäischen Compliance-Standards (DSGVO). Fordern Sie noch heute eine Prozessanalyse an oder laden Sie unser neuestes Whitepaper zur nahtlosen Integration extrahierter Frachtdaten in Ihre bestehende TMS-Architektur herunter.
