Störungsmanagement bei Unwettern: ML re-routet Hunderte Flüge in Minuten

Das echte Ausmaß des Problems

Im Sommer 2024 erlebten fast 40 % aller europäischen Passagiere eine Verspätung oder Stornierung — der schlechteste Wert seit der COVID-19-Pandemie, wie Amadeus in einer eigenen Studie mit Führungskräften aus Airline und Airport-Branche dokumentierte. Rund 218.000 Flüge wurden in Europa 2024 storniert oder mit mehr als drei Stunden Verspätung durchgeführt.

Das Kostenmodell dahinter ist präzise aufgearbeitet. EUROCONTROL veröffentlicht mit dem jährlichen Standard-Inputs-Dokument (aktuelle Ausgabe: Edition 10.0, Mai 2024) Referenzwerte für Verspätungskosten: taktische Bodenkosten bei einer Verspätung am Gate kosten die Airline im Schnitt 166 Euro pro Minute und Flugzeug — dieser Wert schließt die Reaktionsverspätungen im restlichen Netzwerk (sogenannte Reactionary Delays) bereits ein. Für eine airborne Umleitung liegen die Werte noch höher: bis zu 212 Euro pro Minute en route.

Klingt abstrakt? Für einen Hub mit 50 gleichzeitig betroffenen Flugzeugen und jeweils 45 Minuten durchschnittlicher zusätzlicher Bodenzeit ergibt sich: 50 × 45 × 166 Euro = 373.500 Euro für ein einziges Unwetterereignis. Größere Disruptions, die mehrere Hubs gleichzeitig betreffen oder sich über Nacht erstrecken, überschreiten rasch die Millionengrenze.

Global schätzt die Branche die jährlichen Disruption-Kosten auf rund 60 Milliarden US-Dollar — etwa 8 % des weltweiten Airline-Umsatzes. Davon entfallen rund 30–40 % auf direkt steuerbare operative Folgekosten: Hotelunterbringung, Umbuchungsgebühren, Crew-Überstunden, Slot-Verluste und Passagierentschädigungen nach EU 261/2004.

Das Kernproblem ist kein Informationsproblem. Die Dispatcher wissen, welche Flüge betroffen sind. Das Problem ist die kombinatorische Komplexität: Jede Umplanungsentscheidung — ein Flug wird gestrichen, ein anderes Flugzeug übernimmt eine Rotation — verändert die Ausgangslage für alle anderen Entscheidungen gleichzeitig. Flugzeugverfügbarkeit, Crew-Dienstzeitvorgaben (FTL/EU-OPS), Wartungsfenster und ATFM-Slots am Network Manager sind keine unabhängigen Variablen, sondern ein verflochtenes Constraint-Netz. Wer sequenziell von Flugzeug zu Crew zu Passagier vorgeht — wie es heute Standard ist — optimiert jeden Schritt lokal und produziert damit eine globale Lösung, die teurer ist als nötig.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ KLM/BCG-Partnerschaft, BCG-Publikation “How Digital Operations Put The World’s Oldest Airline In The Lead” (2019): KLM berichtete 15–25 % weniger Passagier-Disruptions sowie eine Reduktion der Delay-Minuten um mindestens 20 % durch den gleichzeitigen Einsatz mehrerer ML-basierter OCC-Werkzeuge. Die genaue Attributierung auf einzelne Module wurde nicht separat publiziert.

Einschätzung auf einen Blick

Zeitersparnis — sehr hoch (5/5) Von 3–8 Stunden auf 5–15 Minuten für eine vollständige Recovery-Option — das ist keine graduelle Verbesserung, sondern ein Sprung in eine andere Reaktionsklasse. Kein anderer Anwendungsfall in dieser Kategorie bietet eine vergleichbar transformative Beschleunigung. Der Effekt ist besonders dann entscheidend, wenn eine Disruption weitere Disruptions auslöst: Das System berechnet innerhalb von Sekunden nach jeder Änderung neu.

Kosteneinsparung — sehr hoch (5/5) Die Setup-Kosten sind erheblich (18–36 Monate Implementierung, Enterprise-Lizenz, Integrationsaufwand). Der ROI rechtfertigt diese Investition dennoch: Bei einer mittelgroßen europäischen Network-Airline mit 8–12 größeren Disruptions pro Jahr und durchschnittlichen Folgekosten von 300.000–1.000.000 Euro je Ereignis amortisiert sich das System typischerweise innerhalb von 1–2 Betriebsjahren nach Produktivgang. Die absolute Kosteneinsparung ist unter den Anwendungsfällen dieser Kategorie die höchste.

Schnelle Umsetzung — sehr niedrig (1/5) 18–36 Monate ist kein Worst-Case, sondern eine realistische Erwartung für eine vollständige OCC-Integration. Das liegt nicht an der Technologie, sondern an der erforderlichen Vorarbeit: Crew-Regulierungen müssen vollständig digital codifiziert werden, historische Disruption-Daten für das Modell aufbereitet werden, Schnittstellen zu EUROCONTROL Network Manager und bestehenden AIMS-Systemen müssen gebaut und validiert werden. Sicherheitsvalidierung kommt dazu.

ROI-Sicherheit — hoch (4/5) Der ROI lässt sich via Disruption-Kostentracking messen: Vergleich der Disruption-Folgekosten je Ereignis vor und nach dem Produktivgang. Was die Messung erschwert: Wetterereignisse sind in Häufigkeit und Intensität von Jahr zu Jahr unterschiedlich — ein milder Sommer nach einer starken Unwettersaison könnte einen Rückgang der Kosten fälschlicherweise dem System zuschreiben (oder umgekehrt). Carrier, die mit normalisierter Disruption-Intensität rechnen oder einen statistisch soliden Vor/Nach-Vergleich aufsetzen, sehen einen klaren ROI. Für alle anderen bleibt eine Attributionslücke.

Skalierbarkeit — mittel (3/5) Innerhalb einer Airline skaliert das System gut: mehr Flüge, mehr Rotationen, mehr Crew — das Modell wächst mit. Was nicht skaliert: die Implementierung selbst ist nicht portierbar. Jede Airline hat eigene Flottenmix-Regeln, eigene Tarifverträge für Crews, eigene Slot-Profile. Ein Carrier kann das System nicht einfach an eine Partnerairline weiterlizenzieren und sofort nutzen. Das ist der wesentliche Unterschied zu SaaS-Lösungen in anderen Branchen.

Richtwerte — stark abhängig von Flottengröße, Hub-Komplexität und vorhandener OCC-Infrastruktur.

Was der Optimierer konkret macht

Das Kernproblem trägt in der Fachliteratur den Namen Aircraft-Crew-Passenger-Recovery-Problem (ACPRP). Es ist das schwierigste kombinatorische Optimierungsproblem im kommerziellen Luftverkehr — weil es drei bisher sequenziell gelöste Subprobleme gleichzeitig adressieren muss.

Das Flugzeug-Subproblem: Welches Flugzeug übernimmt welche Rotation? Welche Flüge werden gestrichen oder verzögert? Welche Tail-Nummer wird welchem Slot zugeordnet?

Das Crew-Subproblem: Welche Besatzungen können welche Flüge legal abfliegen? Wann laufen Dienstzeiten aus (FTL-Compliance, EU-OPS)? Welche Hotels müssen bezahlt werden?

Das Passagier-Subproblem: Welche Passagiere verpassen welche Anschlüsse? Welche alternativen Verbindungen gibt es? Wer hat EU 261/2004-Entschädigungsanspruch, und welche Umbuchung verhindert diesen?

Warum MILP und ML zusammengehören

Die klassische Lösung ist ein Mixed-Integer-Optimierer (MILP): Das Problem wird als mathematisches Modell formuliert, alle Constraints (Flugzeugverfügbarkeit, Crew-Stunden, Wartungsfenster, Slots) werden als Gleichungen und Ungleichungen kodiert, und ein Solver findet die kostenminimale Lösung. Das funktioniert — aber bei großen Netzwerken kann ein reines MILP-Modell für einen Hub mit 100+ betroffenen Flügen mehrere Stunden Rechenzeit benötigen. Das ist in einer Disruption-Situation nicht akzeptabel.

Moderne Systeme kombinieren MILP deshalb mit Machine Learning-Heuristiken: Ein ML-Modell, trainiert auf historischen Disruption-Lösungen, schränkt den Suchraum drastisch ein, bevor der MILP-Solver die exakte Lösung berechnet. Aus einer Review der Transportation Science (INFORMS, 2025) geht hervor, dass dieser hybride Ansatz bei Large-Scale-Crew-Recovery-Problemen den Lösungsraum so stark reduziert, dass Qualitätslösungen in operativ akzeptabler Zeit erreichbar sind — ohne auf Optimalität verzichten zu müssen.

Das Ergebnis: Der Dispatcher sieht nicht eine Lösung, sondern typischerweise drei bis fünf Szenarien — geordnet nach Gesamtkosten, Passagier-Impact und Wahrscheinlichkeit der Slot-Zuteilung. Er wählt, das System setzt um und berechnet sofort neu, wenn sich die Situation verändert.

Was der Network Manager limitiert

Bevor ein Optimizer eine Lösung ausgeben kann, muss er wissen, welche Slots noch verfügbar sind. Hier kommt eine externe Wand ins Spiel, die viele OCC-Einführungsprojekte unterschätzen.

Das EUROCONTROL Network Management Operational Centre (NMOC) in Brüssel — früher CFMU, heute Network Manager — koordiniert alle ATFM-Maßnahmen (Air Traffic Flow Management) im europäischen Luftraum. Wenn ein Hub überlastet ist oder wegen Unwetter gesperrt wird, vergibt der Network Manager Slots: neue Abflugzeiten, von denen eine Airline nicht mehr als 5 Minuten früher und nicht mehr als 10 Minuten später abfliegen darf.

Das bedeutet: Ein ACPRP-Solver kann nicht einfach neue Flugzeiten berechnen und annehmen, dass die Slots verfügbar sind. Er muss in Echtzeit die aktuellen ATFM-Maßnahmen vom Network Manager abrufen (via ICAD-Schnittstelle), die verfügbaren Slot-Fenster in sein Constraint-Modell einbauen und prüfen, ob beantragte Slots realistisch genehmigt werden.

Diese Integration ist technisch aufwendig und erfordert Zertifizierung. Airlines, die keinen Echtzeit-Feed vom Network Manager haben — oder die den Feed haben, ihn aber nicht in ihr OCC-System integriert haben — können keinen vollständig legalen Recovery-Plan berechnen. Das ist einer der häufigsten Gründe, warum frühe ACPRP-Implementierungen nur “Empfehlungen” produzieren, die die Dispatcher anschließend noch manuell mit dem Network Manager abklären müssen.

Konkrete Werkzeuge — was wann passt

Für das ACPRP-Problem gibt es keinen Consumer-Markt. Die relevanten Lösungen sind Enterprise-Software, die in der Regel als Multi-Jahres-Projekte implementiert werden. Preise werden nicht veröffentlicht; alle genannten Anbieter verlangen Anfragen über ihren Vertrieb.

Jeppesen Ops Control — Die Lösung von Jeppesen (Boeing-Tochter) ist global am weitesten verbreitet bei großen Netzwerk-Airlines. Das Aircraft Recovery Solver-Modul generiert MILP-basierte Recovery-Szenarien, die Dispatcher im Scenario Manager vergleichen können. Besonders stark, wenn die Airline bereits andere Jeppesen-Systeme für Crew-Optimierung nutzt — die Integration ist dann erheblich einfacher. Nachteil: US-Daten-Hosting erfordert für EU-Carrier ein sorgfältiges AVV- und EU-Data-Boundary-Setup.

NetLine/Ops++ (Lufthansa Systems) — Der IT-Arm der Lufthansa Group bietet mit NetLine/Ops++ ein KI-gestütztes OCC-System mit europäischem Daten-Hosting als Standard. Stärke liegt im NetLine-Ökosystem: Carrier, die bereits NetLine für Crew oder Network nutzen, teilen sich Stammdaten und Crew-Status mit den anderen NetLine-Modulen ohne separate Schnittstellensynchronisation. Deutschsprachiger Support ist ein konkreter Vorteil für DACH-Carrier. Sinnvoll ab ca. 30–35 Flugzeugen.

Amadeus Disruption Management — Amadeus adressiert explizit das vollständige ACPRP: Amadeus Schedule Recovery (Flugzeug-Umlaufplan) plus Amadeus Passenger Recovery (automatisierte Umbuchung) in einem System. Kunden: Air Canada, Air France, Finnair. Besonderer Vorteil für Amadeus-Altéa-PSS-Nutzer — keine Schnittstelle zwischen Booking System und Recovery-Tool nötig. Crew Recovery ist ein separates Modul; bei reinem Aircraft+Passenger-Focus ist Amadeus gut positioniert.

IFS MODS (Maintenance Operations & Disruption System) — Speziell für Carrier, bei denen Wartungsfenster die entscheidende Constraint in der Aircraft-Recovery sind. IFS MODS integriert Maintenance Planning direkt in die Disruption-Logik, sodass kein Flugzeug in eine Recovery-Lösung eingeplant wird, das zu einem MX-Check muss. Spezialprodukt mit kleinerer Installationsbasis als Jeppesen oder Amadeus.

Zusammenfassung: Wann welcher Ansatz

• Bestehende Jeppesen-Crew-Systeme → Jeppesen Ops Control
• Europäischer Carrier, DSGVO-Priorität, NetLine-Umgebung → NetLine/Ops++
• Amadeus-Altéa-PSS-Nutzer mit Fokus auf Passagier-Recovery → Amadeus Disruption Management
• Wartungsintensive Flotte als primärer Constraint → IFS MODS

Datenschutz und Datenhaltung

Ein ACPRP-Solver verarbeitet mehrere Datenkategorien, von denen einige unter die DSGVO fallen:

Operationelle Flugdaten: Flugpläne, Tail-Nummern, Slot-Daten — kein Personenbezug, keine DSGVO-Relevanz.

Crew-Daten: Namen, Dienstzeiten, Qualifikationen, Erreichbarkeit — klar personenbezogen. Hier gilt Art. 28 DSGVO (AVV), und die Übertragung an US-gehostete Systeme (Jeppesen Ops Control) erfordert zusätzlich einen Transfer Impact Assessment (TIA) und gegebenenfalls Standard Contractual Clauses (SCCs).

Passagierdaten (PNR): Name, Buchungsklasse, Anschlussverbindungen, Kontaktdaten — sensibel. Airlines sind ohnehin verpflichtet, PNR-Daten nach EU-PNR-Richtlinie zu verwalten. Systeme, die Passagierumbuchung integrieren (wie Amadeus Disruption Management), müssen in den bestehenden PNR-Datenschutzrahmen eingebettet werden.

Für EU-Carrier empfiehlt sich grundsätzlich eine EU-gehostete Lösung (NetLine/Ops++, Amadeus mit EU-Data-Center-Option) oder eine On-Premise-Installation im eigenen Rechenzentrum. US-gehostete Systeme sind nicht ausgeschlossen, erfordern aber mehr Compliance-Aufwand und müssen mit dem betrieblichen Datenschutzbeauftragten abgestimmt werden.

Was es kostet — realistisch gerechnet

Einmalige Implementierungskosten Zahlen werden von keinem Anbieter öffentlich kommuniziert. Basierend auf Projektberichten aus dem AGIFORS-Netzwerk (Airline Group of IFORS) und Branchenberichten:

• Softwarelizenz Enterprise: typisch im siebenstelligen Bereich (1–3 Mio. Euro) für eine mittelgroße Airline, abhängig von Flottengröße und Modulumfang
• Implementierungsdienstleistungen (Integration, Konfiguration, Validierung): 500.000–1.500.000 Euro
• Interne Projektkosten (Datenaufbereitung, IT-Ressourcen, Change Management): 6–18 Personenmonate

Laufende Kosten

• Jährliche Softwarewartung: typisch 15–20 % der Lizenzkosten
• Betrieb und Monitoring: 1–2 FTE OCC-IT-Spezialist
• Modell-Retraining und Regelwerk-Updates: quartalsmäßig empfohlen, bei Flotten- oder Tarifvertragsänderungen ad hoc

Konservative ROI-Rechnung Eine Airline mit 80 Flugzeugen, 10 größeren Disruptions pro Jahr (je ≥30 betroffene Flüge), durchschnittliche Disruption-Folgekosten vor Optimierung: 500.000 Euro je Ereignis.

Bei 20 % Kosteneinsparung (unteres Ende der KLM/BCG-Range): 100.000 Euro je Ereignis × 10 Ereignisse = 1.000.000 Euro jährlich. Bei Implementierungskosten von 3–5 Mio. Euro Gesamtinvestition ergibt sich ein Amortisationshorizont von 3–5 Jahren — konservativ gerechnet, ohne Berücksichtigung besserer Passagier-NPS-Werte und reduzierter EU-261-Entschädigungen.

Wie du den Nutzen tatsächlich misst Der methodisch sauberste Ansatz ist ein kontrollierter Parallelbetrieb in der Einführungsphase: Das System berechnet Recovery-Empfehlungen, Dispatcher entscheiden manuell, beide Szenarien werden dokumentiert. Nach 6–12 Monaten lassen sich Kostenunterschied je Disruption-Typ direkt berechnen — unabhängig von Schwankungen in der Wetterhäufigkeit.

Typische Einstiegsfehler

1. Den Solver einschalten, bevor das Datenmodell stimmt. Ein ACPRP-Solver ist nur so gut wie die Constraints, die er kennt. Wenn die Crew-Regulierungen (FTL, EU-OPS, Tarifvertrag) nicht vollständig und korrekt digital codiert sind, produziert der Solver Recovery-Lösungen, die der Dispatcher ablehnen muss — weil sie Crew-Regeln verletzen, die das System nicht kennt. Das zerstört das Vertrauen in das System innerhalb von Wochen. Vor Go-Live muss mindestens ein vollständiger Disruptions-Simulationstest mit echten Historien-Daten durchgeführt werden, bei dem jede generierte Lösung manuell auf Legalität geprüft wird.

2. Die Network-Manager-Integration als letzten Schritt behandeln. Teams, die zuerst das Kern-Optimierungsmodell bauen und die ATFM-Slot-Schnittstelle zu EUROCONTROL “am Ende noch dranbauen” wollen, erfahren in der Praxis, dass diese Integration das kritischste Element der gesamten Architektur ist. Ohne Echtzeit-Slot-Verfügbarkeit rechnet der Solver mit fiktiven Annahmen und produziert Recovery-Pläne, die bei der Einreichung beim Network Manager abgelehnt werden. Die ICAD-Zertifizierung allein kann 3–6 Monate in Anspruch nehmen.

3. Dispatcher übergehen statt einbeziehen. Erfahrene OCC-Dispatcher verfügen über implizites Erfahrungswissen, das in keiner Dokumentation steht: Welche Codeflug-Partner bevorzugen bestimmte Recovery-Optionen? Welche Crew-Basis reagiert träge auf Kurzfrist-Änderungen? Welche Strecken haben inoffizielle “Verbindungsschutz”-Absprachen mit Lounges oder Boden-Partnern? Systeme, die ohne dieses Wissen konfiguriert werden und die Dispatcher als Benutzer statt als Experten behandeln, werden umgangen — die Dispatcher kehren zu Excel zurück und nutzen das System nur für die Dokumentation.

4. Das Modell nicht regelmäßig neu trainieren. Das ist der stille Fehler, der sich erst nach 12–18 Monaten zeigt. Flottenmix ändert sich, Tarifverträge werden neu verhandelt, neue Codeshare-Verbindungen verändern die Passagierverbindungs-Prioritäten. Ein Solver, der mit Daten von vor 18 Monaten trainiert wurde, optimiert für eine Airline, die es nicht mehr gibt. Einige Implementierungen haben nach dem Erstprojekt kein Retraining-Budget mehr vorgesehen — mit der Folge, dass die Lösung-Qualität langsam abnimmt, ohne dass es auffällt.

Was mit der Einführung wirklich passiert — und was nicht

Ein OCC-Solver nimmt den Dispatchern nichts weg. Er gibt ihnen Zeit zurück — für die Entscheidung, die keinen Algorithmus hat: Welchen Flug stellt man bei einem politisch sensiblen Großkunden nicht ab? Welcher Partner-Airline kommuniziert man persönlich vor der Ankündigung? Was tut man, wenn der Network Manager keine freien Slots mehr hat und alle rechnerisch guten Optionen wegfallen?

In der Einführung begegnen typischerweise drei Widerstands-Muster:

Die erfahrenen Dispatcher, die “die Route kennen”. Sie haben 15 Jahre lang jeden FRA-Hub-Disruption-Typ gesehen und sind in ihrer Intuition meist besser als das Modell in der Early-Stage-Phase. Das ist keine Feindseligkeit gegen das System — das ist berechtigtes Fachurteil. Was hilft: Diese Dispatcher aktiv in die Modell-Validation einbinden. Ihr Feedback beim Vergleich von Modell-Output und eigener Einschätzung ist das wertvollste Kalibrierungs-Signal für die erste Phase.

Das IT-Team, das das System als “fertig” erklärt, wenn die Software läuft. Technische Inbetriebnahme und operativer Produktivgang sind zwei unterschiedliche Meilensteine. Ein System, das läuft, aber dessen Output die Dispatcher zu 40 % manuell korrigieren müssen, ist kein Produktiv-System. Der Übergang zu echtem Produktivbetrieb dauert typischerweise 3–6 Monate nach dem technischen Go-Live.

Das mittlere Management, das Erfolg nach der Einführungs-Anekdote misst. “Beim letzten großen Sturm hat das System hervorragend funktioniert” reicht als ROI-Nachweis nicht. Sinnvoller: Disruption-Kosten pro ereignisbereinigte Stunde im 12-Monats-Vergleich. Das erfordert ein Dashboard, das parallel zur Einführung aufgebaut werden muss — nicht ein Jahr später.

Was konkret hilft:

• Mindestens drei erfahrene Dispatcher in das Konfigurationsteam einbinden, bevor die erste Regelwerk-Codierung startet
• Historische Disruptions-Daten der letzten 3 Jahre für das Modell aufbereiten (kein Schritt, der sich abkürzen lässt)
• Parallelbetrieb als Standard-Phase planen: mindestens 6 Monate, bevor der Solver eigenständig Lösungen “empfiehlt”
• Retraining-Budget und -Verantwortlichkeit von Anfang an in den Vertrag schreiben

Realistischer Zeitplan mit Risikohinweisen

Gesamtlaufzeit realistisch: 18–36 Monate ab Projektstart bis operativer Routineeinsatz.

Häufige Einwände — und was dahintersteckt

“Wir haben das schon immer manuell gelöst und sind damit zufrieden.” Manuelles OCC produziert Lösungen, die funktionieren — aber nicht die günstigsten sind. Das Problem ist nicht, dass Dispatcher schlechte Arbeit machen. Das Problem ist, dass ein Mensch bei 80+ simultanen Constraint-Variablen nicht die global günstigste Lösung finden kann — er findet eine, die ausreichend ist. Die Frage ist nicht “funktioniert es?”, sondern: Wie viel Euro bleiben bei jedem Disruptions-Ereignis auf dem Tisch liegen, weil die manuell gewählte Lösung 15–20 % teurer ist als die mathematisch optimale?

“Die Technologie ist noch nicht reif genug für echte OCC-Entscheidungen.” Das war bis circa 2017 ein berechtigter Einwand. KLM nutzt seit 2018 ML-basierte OCC-Unterstützung im Produktiveinsatz, Air France und Air Canada setzen Amadeus Disruption Management produktiv ein. Die Technologie ist reif — was nicht reif ist, sind OCC-Integrations-Projekte, die mit zu kleinem Budget, zu wenig Dispatcher-Einbindung und zu optimistischen Timelines gestartet werden.

“Das Datenschutzrisiko ist zu groß.” Der Datenschutz-Aufwand ist real, aber lösbar. Für Crew-Daten: AVV nach Art. 28 DSGVO, bei US-Hosting zusätzlich SCCs und TIA. Für Passagier-PNR: bestehende DSGVO-Compliance muss auf das Recovery-System ausgedehnt werden. EU-gehostete Lösungen (Lufthansa Systems NetLine/Ops++, Amadeus EU-Data-Center) reduzieren den Compliance-Aufwand erheblich.

Woran du merkst, dass das zu dir passt

Mindestvoraussetzungen — alle müssen erfüllt sein:

• Flottengröße mindestens 50 Flugzeuge. Das ist keine willkürliche Grenze, sondern die Schwelle, ab der die kombinatorische Komplexität eines Disruption-Ereignisses eine manuelle Lösung messbar schlechter macht als eine optimierte. Unter 50 Flugzeugen ist das OCC überschaubar genug, dass erfahrene Dispatcher nah an der optimalen Lösung bleiben. Die Implementierungskosten von 3–5 Mio. Euro lassen sich unter dieser Flottengröße nicht amortisieren.

• Hauptsächlich Hub-and-Spoke-Struktur. Point-to-Point-Carrier oder reine Low-Cost-Carrier mit wenigen Umsteigeverbindungen haben deutlich weniger kaskadierende Auswirkungen bei einer Disruption. Das ACPRP-Problem wird durch Anschlussverbindungen und Crew-Rotationen, die über den Hub laufen, exponentiell komplexer. Wer hauptsächlich A→B ohne Umstieg fliegt, braucht keinen ACPRP-Solver.

• Bestehendes AIMS-System mit vollständiger Crew-Datenintegration. Ein Recovery-Solver ohne digitale Crew-Dienstzeiten, Qualifikationen und aktuelle Positionsdaten rechnet blind. Wer noch mit hybriden Systemen (teils digital, teils Papier oder Telefon) arbeitet, muss zuerst diese Lücke schließen.

• Crew-Regulierungen vollständig digital codifiziert (FTL, EU-OPS, Tarifvertrag). Das ist die häufigste Überraschung im ersten Projektquartal: Tarifvertragsdetails, die “alle kennen, aber niemand aufgeschrieben hat”, können die Constraint-Codierung um 6–12 Monate verzögern.

• Langfristiges Commitment der OCC-Leitung. Ein 18–36-monatiges Projekt, das mit dem Wechsel der OCC-Führung sein Sponsor-Commitment verliert, ist die häufigste Abbruchursache. Das System braucht einen namentlichen internen Champion mit Budget-Hoheit.

Wer das noch nicht tun sollte — drei harte Ausschlusskriterien:

1. Flotte unter 50 Flugzeugen. Das Disruption-Volumen rechtfertigt weder die Lizenzkosten noch die Implementierungsaufwände. Eine gut trainierte OCC-Mannschaft mit soliden Prozessen und einem einfachen Szenario-Tool (Excel-basiert oder leichte Software) ist die bessere Investition.

2. Keine vollständig digitale Crew-Disposition. Wenn Crew-Assignments noch per Telefon koordiniert werden oder kein AIMS-System mit vollständiger Datenbasis vorhanden ist, fehlt die Grundlage. Ein Solver, der nicht weiß, wo welche Crew steht, rechnet Fantasielösungen.

3. Kein Budget oder kein Mandat für einen 3-Jahres-Horizont. Wer ACPRP-Optimierung als 6-Monats-Projekt plant, wird scheitern — nicht wegen der Technologie, sondern wegen der Integrationsrealität. Die Einführung eines ML-basierten Disruption-Solvers ist strukturell vergleichbar mit der Einführung eines neuen Crew-Management-Systems: ein Transformationsprojekt, keine Tool-Einführung.

Das kannst du heute noch tun

Wenn du OCC-Leiter oder Head of Operations bei einer Network-Airline bist: Starte nicht mit einem Vendor-Gespräch, sondern mit einer Disruption-Kosten-Analyse. Ziehe die letzten 12 Monate OCC-Logs für die fünf teuersten Disruption-Ereignisse und beantworte diese Fragen:

1. Wie lange hat es von Disruptions-Beginn bis zur ersten vollständigen Recovery-Option gedauert?
2. Welche Constraints haben die Dispatcher am häufigsten manuell nachgeprüft?
3. Welche Entscheidungen wurden im ersten Disruptions-Fenster getroffen und mussten danach revidiert werden?

Die Antworten zeigen dir, wo dein größtes Verbesserungspotenzial liegt — und welcher Solver-Fokus (Aircraft-heavy, Crew-heavy oder Passenger-heavy) für deine spezifische Situation am wertvollsten wäre.

Für eine erste Einschätzung, ob das Optimierungspotenzial für deine Flottengröße realistisch ist, hilft dieser Rahmen-Prompt für ein Analyse-Gespräch mit einem OCC-Berater:

Quellen & Methodik

• EUROCONTROL Standard Inputs for Economic Analyses, Edition 10.0 (Mai 2024): Taktische Verspätungskosten 166 €/Min. (Gate, inkl. Netzwerkeffekte), 212 €/Min. (en route). URL: ansperformance.eu

• KLM / Boston Consulting Group: “How Digital Operations Put The World’s Oldest Airline In The Lead” (BCG, 2019). KLM berichtete 15–25 % weniger Passagier-Disruptions, mindestens 20 % weniger Delay-Minuten durch ML-basierte OCC-Werkzeuge. URL: bcg.com

• INFORMS Transportation Science (2025): “Large-Scale Airline Crew Recovery Using Mixed-Integer Optimization and Supervised Machine Learning” — Nachweis, dass ML-Heuristiken den MILP-Lösungsraum bei Large-Scale-Recovery-Problemen operativ handhabbar machen. URL: pubsonline.informs.org

• Maxapress / Digital Transportation and Society (2024): “Review of optimization problems, models and methods for airline disruption management from 2010 to 2024” — Überblick zur Forschungsentwicklung ACPRP; Lösungszeiten von 0,3 bis >8.000 Sekunden bei reinem MILP. URL: maxapress.com

• Amadeus (2024): “Better together: rethinking how to manage disruption in aviation” — Branchenstudie mit Airline- und Airport-Führungskräften; Befund: Sommer 2024 war mit fast 40 % betroffener Passagiere der schlechteste Wert seit COVID. URL: amadeus.com

• EUROCONTROL CFMU / Network Manager: Technische Dokumentation zu ATFM-Slot-Zuteilung und ICAD-Schnittstelle. URL: eurocontrol.int

• Preisangaben und Implementierungsparameter: Keine Anbieter veröffentlichen Listenpreise. Kostenangaben in diesem Artikel basieren auf branchenüblichen Schätzwerten aus dem AGIFORS-Netzwerk (Airline Group of the International Federation of Operational Research Societies) und Branchenberichten (Stand Mai 2026). Individuelle Angebote können erheblich abweichen.

Du leitest das OCC einer Network-Airline und willst einschätzen, ob ein ACPRP-Solver die Investition rechtfertigt? Meld dich — wir schauen gemeinsam auf deine Disruption-Historien-Daten und geben dir eine ehrliche Einschätzung.