EDI vs. KI-BOL-Erfassung
Wann welche Methode für mittelständische Spediteure funktioniert

Fragen Sie einen Berater für Logistiktechnologie, ob ein mittelständischer Spediteur EDI für Konnossementdaten einführen sollte, und die Antwort kommt meist vorgefertigt: „EDI ist der Industriestandard.“ Das ist nicht falsch – EDI ist seit Jahrzehnten das Rückgrat des Datenaustauschs zwischen Carrier und Verlader. Aber es beantwortet eine etwas andere Frage als die, die sich die meisten Spediteure tatsächlich stellen.

Spediteure brauchen kein Datenaustauschprotokoll. Sie brauchen eine Möglichkeit, Sendungsdetails – Konnossementnummern (BOL), Container-IDs, Schiffsnamen, Frachtbeschreibungen, Gewichte, Häfen, Empfängeradressen – aus Dokumenten zu extrahieren, die per E-Mail, Portal-Download und PDF-Anhang eintreffen, und in ihr TMS oder ihre operative Tabellenkalkulation zu überführen. Ob diese Dokumente über eine AS2-Verbindung oder ein Gmail-Postfach reisen, ist für die meisten mittelständischen Betriebe die falsche Diagnosefrage.

Dieser Artikel kartiert den Entscheidungsraum zwischen EDI und KI-gestützter Dokumentenextraktion für die Konnossementverarbeitung. Er erklärt keinen Sieger. Er gibt Ihnen die Kriterien an die Hand, um selbst zu entscheiden – beginnend mit einem ehrlichen Blick darauf, was EDI tatsächlich leistet, was es kostet und ab welchem Punkt die Alternative nicht nur günstiger, sondern auch praktischer wird.

Was EDI für Konnossementdaten tatsächlich leistet

Der Electronic-Data-Interchange-Transaktionssatz, der die Informationen zum Seekonnossement regelt, ist ANSI X12 310 (oder sein internationales Pendant, EDIFACT IFTMIN, definiert von UN/EDIFACT). Es handelt sich um eine standardisierte elektronische Nachricht – einen strukturierten Datenstrom aus Segmenten –, die ein Seefracht-Carrier an einen Verlader, Spediteur oder Terminalbetreiber sendet, um Sendungsdetails zu übermitteln, als Frachtbeleg zu dienen oder als elektronisches Konnossement zu fungieren, wenn die Parteien vereinbart haben, dass Papier nicht erforderlich ist.

Dieser letzte Zusatz ist wichtig. EDI 310 ist kein Dokumentenleser. Es betrachtet kein PDF eines Maersk-Konnossements (BOL) und extrahiert die Containernummer. Es ist ein vorab vereinbartes Datenformat, das zwischen Systemen übertragen wird, die bereits so konfiguriert wurden, dass sie miteinander kommunizieren. Das System des Carriers befüllt definierte Segmente – B3 für den Rechnungskopf des Carriers, N1 für den Parteinamen, R4 für Hafen oder Terminal, V1 für die Schiffsidentifikation – und das System des Spediteurs weiß genau, welches Feld welchem internen Datenpunkt zugeordnet ist. Keine Extraktion findet statt, weil kein Lesen erforderlich ist. Die Daten kommen bereits strukturiert an.

Das ist Stärke und Grenze von EDI in einem Atemzug. Wenn es funktioniert, eliminiert es manuelle Berührungspunkte vollständig: Die Konnossementdaten fließen vom Carrier-TMS zum Spediteur-TMS, ohne dass ein Mensch eine Datei öffnet. Aber es zum Funktionieren zu bringen erfordert etwas, das viele mittelständische Spediteure nicht haben: einen Handelspartner, der denselben Standard ebenfalls implementiert hat, mit kompatiblen Feldzuordnungen, über ein vereinbartes Kommunikationsprotokoll (typischerweise AS2, SFTP oder ein Value-Added-Network).

Die DCSA — deren neun Mitgliedsreedereien (Maersk, MSC, CMA CGM, Hapag-Lloyd, ONE, Evergreen, HMM, Yang Ming und ZIM) für etwa drei Viertel des weltweiten Containerhandels verantwortlich sind — hat sich verpflichtet, bis 2027 eine elektronische Konnossement-Nutzung von 50 % und bis 2030 von 100 % zu erreichen, basierend auf den Open-Source-eBL-Standards der DCSA. Stand Anfang 2025 waren etwa 5,7 % der Konnossemente im Containerhandel digitalisiert. Die FIT-Alliance-Umfrage 2024 unter 279 Teilnehmern aus 37 Ländern ergab, dass 49 % der Befragten eBLs in irgendeiner Form nutzen — diese Zahl umfasst jedoch auch Dual-Format-Nutzer, die weiterhin Papier neben digitalen Dokumenten verarbeiten. Nur 5 % sind vollständig umgestiegen.

Die praktische Konsequenz für einen mittelständischen Spediteur ist: Selbst wenn Sie morgen EDI 310 implementieren, werden die meisten BOLs, die in Ihrem Posteingang ankommen, weiterhin PDFs sein. Die Reedereien bewegen sich — aber Sie sind Jahre von einer Welt entfernt, in der EDI Ihr gesamtes eingehendes Dokumentvolumen abdeckt.

Die tatsächlichen Kosten einer EDI-Implementierung für einen mittelständischen Spediteur

EDI-Preise sind bekanntermaßen intransparent, aber die Kostenstruktur ist jedem bekannt, der den Prozess durchlaufen hat. Sie gliedert sich in vier Ebenen, und jede einzelne summiert sich.

Ebene 1: Plattform und Infrastruktur. Ob Sie eine On-Premise-Lösung wählen (IBM Sterling B2B Integrator, typischerweise 500–5.000+ $ an Lizenzkosten) oder einen Cloud-Anbieter (Cleo, TrueCommerce, SPS Commerce, Orderful) — Sie zahlen eine monatliche Abonnementgebühr, die von etwa 200 $/Monat für Basistarife bis zu 1.200 $+/Monat für Enterprise-Stufen mit Managed Services reicht. Cloud-basierte Bereitstellungen machen inzwischen über 55 % der neuen EDI-Implementierungen aus, und ihr Abonnementmodell reduziert die anfänglichen Kapitalausgaben — aber die wiederkehrenden Kosten steigen schnell, wenn Sie Handelspartner hinzufügen.

Ebene 2: Einrichtung pro Handelspartner. Hier skalieren die Kosten. Jede Reederei oder jeder Kunde, mit dem Sie sich verbinden, erfordert die Abbildung Ihrer internen Datenfelder auf deren spezifische EDI-Spezifikation. Moderne Anbieter verlangen 750–1.500 $ pauschal pro Handelspartner für die Einrichtung; Legacy-Anbieter kalkulieren regelmäßig 3.000–5.000 $ pro Partner. Ein Spediteur, der mit acht Seefrachtreedereien arbeitet, muss mit 6.000–40.000 $ allein für Einrichtungskosten rechnen, abhängig von der Anbietertarifstufe.

Ebene 3: Zeit — die Kosten, die niemand im Voraus nennt. Die Integration eines einzelnen Handelspartners in EDI dauert in traditionellen Umgebungen 8–12 Wochen (laut Cleos Ökosystem-Integrationsumfrage 2023 berichteten 44 % der Befragten 1 Woche bis 1 Monat pro Partner; 16 % berichteten mehr als einen Monat). Moderne API-gesteuerte Plattformen haben dies für einfache Szenarien auf 2–9 Tage verkürzt, aber jeder Partner mit nicht standardkonformem Datenmapping oder individuellen Geschäftsregeln verlängert den Zeitrahmen wieder. Während dieser Wochen verarbeitet Ihr Team die BOLs dieser Reedereien weiterhin manuell, während Sie für eine Integration zahlen, die noch nicht live ist.

Ebene 4: Laufende Wartung. Reedereien ändern ihre EDI-Spezifikationen — fügen Felder hinzu, modifizieren Segmentanforderungen, aktualisieren Compliance-Regeln. Jede Änderung erfordert Neumapping und Tests. Anbieter verlangen 500–2.000 $ pro Compliance-Update, wenn es nicht in Ihrem Vertrag enthalten ist. Der Mordor-Intelligence-Marktbericht 2025 für EDI-Software stellt fest, dass verwaltete EDI-Dienste — bei denen ein Anbieter Mapping, Compliance und Überwachung übernimmt — mit einer CAGR von 12,6 % wachsen, gerade weil die Wartungslast für interne Teams für die meisten mittelständischen Organisationen nicht tragbar ist.

Über alle vier Ebenen hinweg übersteigt ein EDI-Projekt im Mittelstand laut demselben Marktbericht häufig 100.000 $ vor dem Go-live. Für einen Spediteur, der 500 Sendungen pro Monat bei durchschnittlichen manuellen Dateneingabekosten von 25 $ pro Sendung verarbeitet (eine konservative Schätzung unter Berücksichtigung von Personalkosten, Fehlerkorrektur und verspäteter Rechnungsstellung — hier im Detail erläutert), bedeutet das, dass rund 8 Monate des Budgets für manuelle Verarbeitung allein für die EDI-Einrichtung ausgegeben werden — bevor das System auch nur eine Minute Arbeit einspart.

Nichts davon macht EDI zu einer schlechten Investition. Für Spediteure mit stark frequentierten Routen und wiederkehrenden Carrier-Partnern sowie Kunden, die elektronischen Dokumentenaustausch vorschreiben, zahlt sich EDI aus. Die Frage ist, ob es sich für Ihre spezifische Carrier-Mischung und Ihr Volumenprofil lohnt — und ob es eine leichtere Option gibt, die die Lücke für die Carrier schließt, die Ihnen nie eine EDI 310 senden werden.

Wo KI-Dokumentextraktion passt — und wo nicht

KI-Dokumentextraktion geht das BOL-Problem aus der entgegengesetzten Richtung an. Statt von Carriern zu verlangen, Daten in einem vorab vereinbarten Format zu senden, liest sie jedes eingehende Format — einen PDF-Scan von Maersk, einen Portalscreenshot von CMA CGM, ein fotografiertes Papier-Konnossement (BOL) von einem kleineren regionalen Carrier — und extrahiert die von Ihnen festgelegten Felder mithilfe semantischen Verständnisses statt Vorlagenabgleich.

Der Mechanismus unterscheidet sich grundlegend von EDI und herkömmlicher OCR. Bei template-basierter OCR zeichnen Sie Rechtecke um die Position jedes Feldes auf einem bestimmten BOL-Layout — wechseln Sie den Carrier, schlagen die Rechtecke fehl. Bei KI-basierter Extraktion definieren Sie die gewünschten Spalten — „BOL-Nummer", „Container-ID", „Bruttogewicht", „Entladehafen", „Empfängername" — und die KI lokalisiert jeden Wert, indem sie versteht, was er bedeutet, nicht wo er auf der Seite steht. Dies wird manchmal als Spaltennamenextraktion bezeichnet: Die von Ihnen eingegebenen Feldnamen werden zu den Kopfzeilen Ihrer Ausgabetabelle, und die KI füllt jede Zeile, indem sie jedes Dokument liest — ob ein 3-seitiges Maersk-Original, eine einseitige Hapag-Lloyd-Express-Freigabe oder ein handschriftlicher Lieferschein eines Feeder-Port-Agenten.

Drei Dinge passieren, wenn Sie diesen Ansatz auf einen Multi-Carrier-BOL-Workflow anwenden:

Carrier-Formatvielfalt ist kein Kostenmultiplikator mehr. EDI berechnet pro Handelspartner, weil sich die Implementierung von X12 310 bei jedem Carrier unterscheidet — unterschiedliche Segmentnutzung, unterschiedliche Codelisten, unterschiedliche Pflicht-/Optionalfeld-Aufteilungen. KI-Extraktion behandelt jedes BOL-Format als dasselbe Problem: Felder nach Bedeutung lokalisieren, nicht nach Koordinaten. Ein Spediteur, der mit Maersk, MSC, CMA CGM, Hapag-Lloyd und drei regionalen Carriern arbeitet, definiert seine Ausgabespalten einmal. Die Extraktionsengine übernimmt die Formatunterschiede bei jedem Dokument ohne zusätzliche Konfiguration pro Carrier. Wenn die Arbeit die Stapelverarbeitung dutzender oder hunderter BOLs in eine einzige Tabelle umfasst, steigen die Zeitersparnisse direkt mit dem Volumen — nicht mit der Anzahl der Carrier.

Die Implementierungszeit sinkt von Monaten auf Minuten. Es gibt keinen Mapping-Workshop, keinen Austausch von Spezifikationsdokumenten, keine AS2-Zertifikatseinrichtung und keinen End-to-End-Testzyklus. Der Spediteur lädt einige Beispiel-BOLs hoch, definiert die gewünschten Spalten, prüft die Ausgabe und beginnt mit der Verarbeitung echter Dokumente. Das ist keine Übertreibung – es ist der operative Unterschied zwischen einem Tool für System-zu-System-Integration (EDI) und einem Tool für Dokument-zu-Daten-Konvertierung (KI-Extraktion).

Aber – und hier kommt es auf einen ehrlichen Vergleich an – KI-Extraktion ersetzt kein EDI. Sie sendet keine Daten zurück an den Carrier. Sie generiert keine 997 Functional Acknowledgment automatisch. Sie integriert nicht bidirektional mit dem Buchungssystem eines Carriers. Wenn Ihr Kunde vorschreibt, dass Sie Sendungsstatus-Updates per EDI 214 empfangen oder Frachtrechnungen per EDI 210 senden, hilft Ihnen KI-Extraktion nicht, diese Anforderung zu erfüllen. Sie nimmt eine spezifische Position in der Datenpipeline ein: die Erfassung eingehender Dokumente. Für ausgehenden Datenaustausch und System-zu-System-Automatisierung bleibt EDI das richtige Werkzeug.

Die strukturellen Gründe, warum manuelle BOL-Erfassung in der Spedition fortbesteht, sind hier wichtig zu verstehen – sie erklären, warum viele mittelgroße Spediteure in der Lücke zwischen „zu klein für vollständiges EDI“ und „zu groß für rein manuelle Erfassung“ feststecken. KI-Extraktion füllt genau diese Lücke für die Eingangsseite des Workflows.

Der Entscheidungsrahmen – Wählen Sie nach Integrationstiefe, nicht nach Sendungsvolumen

Die herkömmliche Faustregel ist falsch. Die meisten Spediteure formulieren die Wahl instinktiv als „Wie viele Sendungen brauche ich, bevor EDI sinnvoll ist?“ – als ob das Volumen allein die Antwort bestimmt. Tut es nicht. Ein Spediteur, der 2.000 Sendungen pro Monat mit 20 Carriern abwickelt, von denen nur zwei EDI anbieten, zieht aus einer EDI-Implementierung weit weniger Nutzen als ein Spediteur mit 500 Sendungen pro Monat, bei dem vier große Carrier, die 80 % des Volumens abdecken, bereits EDI-fähig sind.

Die bessere Diagnose läuft über zwei Achsen:

Achse 1: Partner-Standardisierung. Wie viel Prozent Ihres eingehenden BOL-Volumens stammt von Carriern, die (a) bereits EDI 310/IFTMIN unterstützen und (b) ausreichend standardisiert sind, um das Mapping unkompliziert zu machen? Wenn vier Carrier 70 % Ihres Volumens abdecken und alle vier saubere EDI-Feeds bieten, funktioniert die Integrationsrechnung. Wenn acht Carrier 70 % abdecken und keiner ausgereifte EDI-Programme hat, zahlen Sie für Infrastruktur, die sich nicht mit den Dokumenten verbindet, die Sie tatsächlich erhalten. Die FIT-Alliance-Umfragedaten sind hier nützlich: Da nur 5,7 % der BOLs im Containerhandel derzeit digital sind und 49 % der Organisationen sich noch im Dual-Format-Modus befinden, ist die Realität für die meisten Spediteure, dass die Mehrheit ihrer Carrier-Partner Jahre von stabilen EDI-310-Feeds entfernt ist.

Achse 2: Anforderung an die Integrationstiefe. Benötigen Sie die BOL-Daten, um nachgelagerte Systemereignisse auszulösen – eine Zollanmeldung automatisch auszufüllen, ein Kundenportal zu aktualisieren, einen Rechnungsworkflow anzustoßen – oder benötigen Sie die Daten organisiert und durchsuchbar, damit Ihr Betriebsteam darauf reagieren kann? Der Wert von EDI steigt mit der Integrationstiefe: Je mehr automatisierte nachgelagerte Aktionen davon abhängen, dass BOL-Daten in einem bestimmten strukturierten Format an einem bestimmten Systemendpunkt ankommen, desto mehr rechtfertigen sich die Einrichtungskosten pro Partner. Der Wert der KI-Extraktion erreicht seinen Höhepunkt, wenn der primäre Bedarf darin besteht, genaue, strukturierte Daten aus Dokumenten in ein nutzbares Format zu bringen – eine Tabelle, einen CSV-Import, einen manuellen TMS-Upload – ohne den Integrationsaufwand.

Diese beiden Achsen ergeben vier grobe Quadranten, jeweils mit einer anderen Standardempfehlung:

Die meisten mittelständischen Spediteure befinden sich in den beiden unteren Quadranten: unterschiedliche Carrier, oft aus Notwendigkeit (Kunden routen Fracht je nach Tarif und Verfügbarkeit über verschiedene Linien), und Integrationsanforderungen, die zwar real sind, aber keine Echtzeit-System-zu-System-Auslöser für jede Sendung erfordern. Für einen Spediteur, der die BOL-Verarbeitung von 100 auf 1.000 Sendungen skaliert, ohne ein formelles Integrationsprojekt, ist der untere rechte Quadrant der häufigste Ausgangspunkt – und genau dort liefert die KI-Extraktion das höchste Verhältnis von Wert zu Implementierungsaufwand.

Ein weiterer Gesichtspunkt, den es zu berücksichtigen gilt: die eBL-Zeitachse. Das 100-%-bis-2030-Ziel der DCSA-Carrier, kombiniert mit der BIMCO-Kampagne „25 by 25“ (die ihr Ziel frühzeitig übertraf und bis Mitte 2024 eine eBL-Einführungsrate von 25,1 % bei Eisenerzsendungen erreichte), bedeutet, dass sich die Carrier-Landschaft verändert. Spediteure, die jetzt in EDI investieren, positionieren sich für eine Zukunft, in der standardisierte elektronische Konnossemente (BOL) die Norm sind. Spediteure, die jetzt in KI-Extraktion investieren, lösen das heutige Problem – die PDFs, die weiterhin 94,3 % der Konnossemente (BOL) im Containertransport ausmachen – und halten sich die EDI-Entscheidung für später offen, wenn mehr Carrier ihre digitale Umstellung abgeschlossen haben.

Häufig gestellte Fragen

Kann KI-Dokumentenextraktion EDI für einen Spediteur vollständig ersetzen?

Nein – und dieser Unterschied ist wichtig. KI-Extraktion ersetzt den Schritt der manuellen Dateneingabe: das Lesen von BOL-Feldern aus einem Dokument und deren Eingabe in ein System. EDI ersetzt den Schritt des Dokumentenaustauschs: das Senden und Empfangen strukturierter Daten zwischen Systemen. Wenn Ihre Kunden verlangen, dass Sie Daten im EDI-Format (X12 310, 210, 214 usw.) empfangen oder senden, kann KI-Extraktion das nicht ersetzen. Was sie leisten kann, ist die Verarbeitung der BOL-Daten von Carrieren, die kein EDI anbieten – was für die meisten mittelständischen Spediteure den Großteil ihres eingehenden Dokumentenvolumens ausmacht.

Wie lange dauert es tatsächlich, EDI mit einem Carrier einzurichten?

Planen Sie in einer traditionellen EDI-Umgebung 8–12 Wochen pro Handelspartner ein, einschließlich Anforderungsanalyse, Feldzuordnung, interner Tests, Zertifizierungstests mit dem Partner und Stabilisierung nach dem Go-live. Moderne API-basierte EDI-Plattformen (Orderful, Stedi) haben dies für gängige Partnervorlagen auf wenige Tage reduziert, aber jeder Carrier mit nicht standardkonformen Anforderungen oder individuellen Geschäftsregeln verlängert den Zeitrahmen wieder auf Wochen. Die Abweichung hängt fast vollständig davon ab, wie genau die EDI-Spezifikation des Carriers mit der vorgefertigten Vorlage des Anbieters übereinstimmt – nicht von Ihrer internen Bereitschaft.

Was kostet KI-Extraktion im Vergleich zu EDI?

KI-Extraktionstools berechnen in der Regel pro Seite oder pro verarbeitetem Dokument, wobei die Abonnementstufen nach monatlichem Volumen statt pro Handelspartner skalieren. Ein Spediteur, der 500 BOLs pro Monat verarbeitet, kann mit Kosten im Bereich von $50–$300/Monat rechnen, je nach Anbieter und Funktionsstufe – ungefähr die Kosten der monatlichen Abonnementgebühr eines EDI-Handelspartners, aber abdeckend für Dokumente aller Carrier ohne Einrichtungsgebühren pro Partner. Das Fehlen von Zuordnungs-, Test- und Wartungskosten ist der strukturelle Unterschied: Die Kostenkurve der KI-Extraktion ist linear zum Volumen, während die von EDI gestuft ist – jeder neue Handelspartner fügt unabhängig davon, wie wenige Dokumente dieser Partner sendet, diskrete Einrichtungskosten hinzu.

Wie geht die KI-Extraktion damit um, dass jedes Konnossement (BOL) der Carrier anders aussieht?

Indem sie Feldsemantik statt Dokumentlayout versteht. Traditionelle OCR erkennt „den Wert in der oberen rechten Ecke von Seite 1“ – was scheitert, wenn Hapag-Lloyd die BOL-Nummer an einer anderen Position platziert als MSC. KI-Extraktion erkennt „den Wert, der auf diesem Dokument als Konnossementnummer fungiert“ – was carrierübergreifend funktioniert, weil jedes BOL eine BOL-Nummer, eine Container-ID, einen Empfänger und einen Entladehafen hat, unabhängig davon, wo auf der Seite diese Felder erscheinen. Die zugrunde liegende Technologie ist ein visuelles Sprachmodell, das das Dokument ganzheitlich liest und Felder nach Bedeutung statt nach Koordinaten lokalisiert.

Sollte ich warten, bis die eBL-Einführung eine kritische Masse erreicht hat, bevor ich in einen der beiden Ansätze investiere?

Wahrscheinlich nicht. Das 100%-eBL-Ziel der DCSA-Carrier ist 2030 – fünf Jahre entfernt – und selbst dann werden regionale Carrier, NVOCCs und nicht-containerisierte Fracht hinter den großen Containerlinien zurückbleiben. In der Zwischenzeit werden die 94,3 % der BOLs, die weiterhin in Papier- oder PDF-Form vorliegen, sich nicht von selbst verarbeiten. Der pragmatische Weg für die meisten mittelständischen Spediteure besteht darin, das heutige Problem der Dokumentenerfassung mit KI-Extraktion zu lösen, während man die eBL-Einführung auf den eigenen Handelsrouten beobachtet und EDI gezielt für Carrier-Beziehungen mit hohem Volumen ergänzt, sobald deren EDI-Programme ausgereift sind.

Kann die KI-Extraktion Daten direkt in mein TMS ausgeben?

Das hängt vom Tool und Ihrem TMS ab. Die meisten KI-Extraktionsplattformen geben nach Excel, CSV oder JSON aus – Formate, die praktisch jedes TMS importieren kann. Einige bieten API-Endpunkte, die extrahierte Daten mit zusätzlichem Integrationsaufwand in ein TMS oder ERP einspeisen können. Was sie in der Regel nicht bieten, ist die bidirektionale, ereignisgesteuerte Integration, die EDI bietet: das automatische Auslösen einer Zollanmeldung, wenn BOL-Daten eintreffen, oder das Aktualisieren eines Kundenportals in Echtzeit. Wenn Ihr Workflow dieses Maß an Automatisierung erfordert, sind EDI oder eine individuelle API-Integration das richtige Werkzeug. Wenn Ihr Workflow strukturierte, importbereite Daten benötigt, deckt die KI-Extraktion das ab.

Die Wahl zwischen EDI und KI-Extraktion für Konnossementdaten dreht sich nicht in erster Linie darum, welche Technologie „besser“ ist. Es geht darum, welches Problem Sie heute lösen – und welches Sie in drei Jahren lösen werden. Für das Problem der eingehenden Dokumente, mit dem die meisten mittelständischen Spediteure derzeit konfrontiert sind, bei dem Carrier-BOLs in Formaten eintreffen, die kein vorab vereinbarter Standard kontrolliert, schließt die KI-Extraktion eine Lücke, die EDI nie füllen sollte. Für das Problem der ausgehenden Integration – die bidirektionale Verbindung Ihrer Systeme mit denen Ihrer Kunden und Carrier – bleibt EDI das branchenübliche Werkzeug, und das wird sich so schnell nicht ändern.