Wir bauten einen schnelleren Airline-Crew-Solver. Er scheiterte nur schneller.
Als ich zum ersten Mal während einer echten Kaskade in einem Operations Control Center einer Fluggesellschaft saß, war es kurz nach 3 Uhr morgens, und ein Wintersturm hatte Stunden zuvor einen wichtigen Flughafen geschlossen. Die Videowand entlang der Stirnseite des Raums füllte sich mit Rot — Annullierung um Annullierung — und woran ich mich am meisten erinnere, ist, dass niemand den millionenschweren Crew-Scheduling-Solver benutzte, für den die Fluggesellschaft bezahlt hatte. Die Disponenten hatten ihre Tastaturen beiseitegeschoben und arbeiteten gebrochene Crew-Pairings von Hand ab, auf Tabellen und einem Whiteboard, genau in dem Moment, in dem die Software sich hätte bezahlt machen sollen.
Dieses Bild ist das, was uns schließlich dazu brachte, airline crew scheduling AI für die IROPS-Recovery zu bauen — aber nicht so, wie ich es erwartet hatte, und nicht, bevor ich auf die falsche Lösung setzte und mit ansah, wie sie scheiterte. IROPS ist, falls Sie noch nie das Vergnügen hatten, das Branchenwort für unregelmäßigen Betrieb: die Stürme, die Schließungen, das kaskadierende Chaos, wenn ein Flugplan auseinanderfällt. Es kostet die Luftfahrtbranche schätzungsweise 60 Milliarden US-Dollar pro Jahr, laut IATA rund 8 % des weltweiten Airline-Umsatzes. Etwa jeder fünfte Flug weltweit ist davon betroffen. Und das schmutzige Geheimnis, das ich in jener Nacht lernte, ist, dass die ausgefeilteste Optimierungssoftware der Luftfahrt im Grunde darauf ausgelegt ist, genau während der Ereignisse nutzlos zu sein, die am meisten kosten.
Der Solver optimierte eine Fluggesellschaft, die es nicht mehr gab
Es hilft zu wissen, was die Legacy-Crew-Solver tatsächlich tun. Sie führen Column Generation aus — eine Branch-and-Price-Optimierungstechnik, die wirklich brillant darin ist, die günstigste legale Art zu finden, einen bekannten Flugplan zu besetzen. Der Haken liegt im Wort bekannt. Der Solver nimmt einen Snapshot des Netzwerks, friert die Zeit ein und berechnet die optimale Crew-Zuteilung für diese eingefrorene Welt. Er läuft in Batch-Zyklen, typischerweise alle 30 bis 60 Minuten.
Im Normalbetrieb ist das in Ordnung. Die Welt bewegt sich zwischen den Zyklen kaum. Doch während einer Kaskade ändert sich der Netzwerkzustand alle paar Minuten. Crews bewegen sich. Verbindungen brechen. Flugzeuge stranden. Bis der Solver eine Lösung liefert, sind die ihm gegebenen Eingaben bereits falsch — und so ist die Antwort ein perfekter Plan für eine Fluggesellschaft, die es nicht mehr gibt.
Ich begann, dies die Optimierungs-Ausführungs-Lücke zu nennen: die Distanz zwischen der Welt, die der Solver annahm, und der Welt, die tatsächlich draußen auf dem Vorfeld existiert. Die Lücke ist bei einer isolierten Verspätung harmlos. Während einer Kaskade ist sie fatal, denn der Solver wurde für Effizienz gebaut — den günstigsten Flugplan in einer bekannten Welt — und was Sie um 3 Uhr morgens verzweifelt brauchen, ist Resilienz: einen überlebensfähigen Flugplan in einer unbekannten Welt.
Das Grausamste an einem Legacy-Crew-Solver ist, dass er während einer Kernschmelze einfach weiterarbeitet — und Ihnen seelenruhig einen makellosen Plan für ein Netzwerk übergibt, das während der Berechnung auseinanderfiel.
Warum konnten wir den Solver nicht einfach schneller machen?
Das ist der Teil, auf den ich nicht stolz bin, und es ist der Teil, auf den es tatsächlich ankommt.
Als mein Team sich das Problem zum ersten Mal ansah, war unsere Diagnose die naheliegende Ingenieursdiagnose: Der Solver ist zu langsam. Die Welt ändert sich alle fünf Minuten, und der Optimierer braucht dreißig Minuten bis zu einer Stunde, also schließt die Lücke — macht ihn schneller. Wir verbrachten echte Zeit damit, eine schnellere Recovery-Engine zu bauen, gestützt auf günstigere Heuristiken, um innerhalb des operativen Entscheidungsfensters eine machbare Antwort zu bekommen, statt auf eine beweisbar optimale zu warten.
Und es funktionierte, im engen Sinne, dass es Antworten schneller lieferte. Dann testeten wir es an echten Störungsdaten, und ich sah zu, wie es selbstbewusst Recovery-Pläne produzierte, die bereits ungültig waren, nur eben früher. Wir hatten eine Maschine gebaut, die eine Phantom-Fluggesellschaft mit höherer Geschwindigkeit optimierte.
Der Fehler bestand darin, Geschwindigkeit als den Engpass zu behandeln. Das war sie nicht. Der Engpass war, dass die Eingaben Fiktion waren. Der Solver — unserer eingeschlossen — braucht harte Fakten: „Captain Smith ist an Gate B7 in Denver.“ Doch während einer Kaskade könnte Captain Smith im Hotel sein, könnte im Mitarbeitershuttle sitzen, könnte einen Wagen gemietet haben und auf halbem Weg nach Colorado Springs sein. Der ehrliche Zustand der Welt ist „wahrscheinlich in Denver“, und ein Column-Generation-Solver kann mit wahrscheinlich nichts anfangen. Wir hatten die Antwort auf eine Frage geschärft, deren Daten Müll waren.
Dieses Scheitern ist der Grund, warum es das Produkt gibt. Hätten wir den schnellen Solver ausgeliefert, hätten wir Fluggesellschaften eine schnellere Art verkauft, denselben teuren Fehler zu machen.
Das schwarze 1,2-Milliarden-Dollar-Datenloch
Wenn Sie genau dieses Scheitern in vollem Umfang sehen wollen, schauen Sie sich an, was im Dezember 2022 mit Southwest geschah. Die Kernschmelze kostete die Fluggesellschaft rund 1,2 Milliarden US-Dollar, annullierte etwa 16.900 Flüge und ließ über die Feiertage nahezu zwei Millionen Passagiere stranden.
Die verbreitete Geschichte lautet „alte Software“. Die wahre Geschichte ist spezifischer und nützlicher. Southwests Crew-Scheduling-System, SkySolver, stieß auf eine kombinatorische Explosion, die es nicht durchrechnen konnte. Doch darunter verlor die Fluggesellschaft den Überblick darüber, wo sich ihre eigenen Piloten und Flugbegleiter physisch befanden. Die Positionsmeldung der Crews lief größtenteils über Telefone — an Außenstationen gestrandete Crews riefen ein Scheduling-Center an, wo die Wartezeiten auf Stunden anstiegen. Diese Latenz erzeugte, was ich mir als schwarzes Datenloch vorstelle: Das System generierte Flugpläne für Crews, die nicht dort waren, wo es sie vermutete. Es optimierte ein Phantom-Netzwerk, und die Point-to-Point-Streckenstruktur bedeutete, dass es keine Hub-„Regenerationspunkte“ gab, an denen Crews und Flugzeuge auf natürliche Weise wieder zusammenkommen, sodass sich der Explosionsradius einfach immer weiter von Station zu Station ausbreitete.
Das ist keine alte Geschichte, die inzwischen jeder behoben hat. Im Juli 2024 erzeugte Spirits Scheduling-System widersprüchliche Zuteilungen für 43 % seiner verfügbaren Flugcrews, ein auf 50–100 Millionen US-Dollar geschätztes Ereignis, weil dem System die Flexibilität fehlte, Crews während der Störung sauber neu zuzuweisen. Das Muster wiederholt sich, weil die zugrunde liegende Architektur — einen eingefrorenen Snapshot optimieren, sichere Eingaben verlangen — branchenweit dieselbe ist.
Southwest reagierte, und das ehrt sie, mit Ausgaben: rund 1,7 Milliarden US-Dollar für Technologie im Jahr 2024 als Teil eines größeren mehrjährigen Programms, eine AWS-Migration, die ihren Rechenzentrums-Fußabdruck drastisch reduzierte, und ein um rund 30 % schnellerer Scheduling-Algorithmus. Das ist der richtige Instinkt. Doch eine schnellere Version derselben Architektur — die Falle, in die wir selbst beinahe tappten — schließt die Geschwindigkeitslücke, während sie die Datengewissheitslücke weit offen lässt.
Was passiert jetzt, wenn eine Verspätung drei Stunden überschreitet?
Über den größten Teil der Luftfahrtgeschichte hinweg kostete Sie eine langsame Recovery Wohlwollen. Verärgerte Passagiere, schlechte Presse, ein paar Gutscheine. Diese Rechnung änderte sich am 28. Oktober 2024.
An diesem Tag trat die Automatik-Erstattungsregel des US-Verkehrsministeriums in Kraft — die allererste verpflichtende Automatik-Erstattungsvorschrift. Jede inländische Verspätung von über drei Stunden (sechs bei internationalen Flügen) löst nun eine Barerstattung aus, gezahlt innerhalb von sieben Werktagen, ohne dass der Passagier auch nur danach fragt. Kein Gutschein. Keine Umbuchung. Bargeld.
Machen Sie die Rechnung für eine mittelgroße Fluggesellschaft, die 300 Abflüge pro Tag durchführt. An einem wirklich schlechten Tag, wenn auch nur ein Sechstel davon — 50 Flüge — die Drei-Stunden-Marke überschreitet, kommen Sie bei einem durchschnittlichen Ticketwert von 280 US-Dollar und 150 Passagieren pro Flug auf ein verpflichtendes Erstattungsrisiko von rund 2,1 Millionen US-Dollar aus einem einzigen Tag. Langsame IROPS-Recovery war früher ein Reputationsproblem. Jetzt ist sie ein Posten, der in derselben Woche zuschlägt.
Es läuft jetzt ein Zähler für jede Stunde, die Ihre Recovery zurückliegt, und seit letztem Oktober zahlt er in bar aus, automatisch, an jeden Passagier, den er berührt.
Das ist der Teil, der die ganze Konversation für mich neu gerahmt hat. Die Kosten der Optimierungs-Ausführungs-Lücke sind nicht länger abstrakt. Sie kumulieren sich, in Dollar, gegen eine Uhr, die in dem Moment zu laufen begann, in dem der Sturm es tat.
Erweitern Sie den Solver, ersetzen Sie ihn nicht
Hier ist die Entscheidung, die unseren Ansatz definiert, und sie ist bewusst unsexy: Wir ersetzen Ihren Solver nicht.
Die etablierten Solver kodieren jahrzehntelanges airline-spezifisches Domänenwissen, und das Feld um sie herum konsolidiert sich, statt zu kollabieren. Jeppesen — der Branchenstandard, mit mehr als hundert Airline-Kunden — wurde im April 2025 von Boeing für 10,55 Milliarden US-Dollar an Thoma Bravo verkauft, eine der größten Tech-Veräußerungen in der Geschichte der Luft- und Raumfahrt, und hat seither Stratosphere gestartet, eine KI-Schicht für prädiktives Störungsmanagement. Die iFlight-Plattform von IBS Software gewinnt moderne, cloud-native Bereitstellungen — Korean Air ging Anfang 2026 live, wobei auch Carrier wie Aeroitalia und die Fluggesellschaften der Groupe Dubreuil auf sie umsteigen — gestützt durch eine Co-Engineering-Vereinbarung mit AWS. Optyms CrewSolver liefert eine dokumentierte Crew-Kostensenkung von 3–7 % auf der Planungsseite.
Keines davon ist der Feind. Doch beachten Sie, worin jedes stark ist: Optimierung in der Planungsphase und prädiktive Analytik — die bekannte Welt, wunderschön berechnet. Das Echtzeit-Recovery-Problem mit unsicheren Eingaben ist die Lücke, die offen bleibt. Ein vollständiger Plattformersatz ist zudem ein 12- bis 18-monatiges Projekt, und kein Operations-Verantwortlicher will das System herausreißen, das an 350 Tagen im Jahr funktioniert, um die 15 zu beheben, an denen es das nicht tut. Für den CIO, der den Vertrag tatsächlich unterschreibt, ist die Rechnung schlimmer als der Kalender: Ein System herauszureißen, in dem jahrzehntelange carrier-spezifische CBA-Logik kodiert ist — genau in dem Moment, in dem Jeppesens eigene Eigentümerschaft gerade für 10,55 Milliarden US-Dollar den Besitzer gewechselt hat und seine langfristige Roadmap eine offene Frage ist — ist eine Wette, die die meisten Tech-Organisationen nicht eingehen werden. Neben der bestehenden Installation zu sitzen, ihre Feeds zu konsumieren, statt ihr Schema zu ersetzen, ist die einzige Integration, die sie freigeben werden.
Also bauten wir eine ML-gestützte IROPS-Recovery-Engine, die neben einer bestehenden Jeppesen- oder IBS-Installation sitzt und das übernimmt, was der Kern-Solver nicht kann: kaskadierende Störungen mit unsicheren Crew-Positionen, netzwerkweite Explosionsradius-Analyse und Recovery-Pläne, die in Minuten erstellt werden statt in den 4 bis 12 Stunden, die eine manuelle Recovery typischerweise dauert. Regionale Fallzahlen deuten darauf hin, dass Automatisierung diese Recovery-Zeit um rund 78 % verkürzen kann. Der Punkt ist nicht, klüger zu sein als der Platzhirsch. Er besteht darin, genau unter den Bedingungen nützlich zu sein, für die der Platzhirsch nie ausgelegt war.
Einem Modell beibringen, mit „wahrscheinlich in Denver“ zu arbeiten
Sobald wir aufhörten zu versuchen, den Solver schneller zu machen, rückte das eigentliche Engineering-Problem in den Fokus: etwas zu bauen, das von Unsicherheit lebt, statt an ihr zu ersticken.
Das erste Element ist Crew-Positions-Intelligenz. Statt einen sicheren Standort zu verlangen, füttern wir ein Modell mit probabilistischen Positionen — indem wir alle vorhandenen Echtzeitsignale mit historischem Verhalten fusionieren, sodass das System darüber schließt, wo eine Crew wahrscheinlich ist, statt auf einen Anruf zu warten, der vier Stunden tief in einer Warteschleife steckt. Genau diese eine Verschiebung — von „sicher oder nichts“ zu „Wahrscheinlichkeitsverteilung“ — ist es, die einen Recovery-Plan den Kontakt mit einer echten Kaskade überleben lässt.
Das zweite Element besteht darin, das Netzwerk als Graph zu behandeln und zu analysieren, wo sich Ausfälle ausbreiten werden, bevor sie es tun — der Explosionsradius, abgebildet auf die spezifische Streckenstruktur dieser Fluggesellschaft, sodass Sie sehen können, welche Stationsschließung in zwei Stunden ab jetzt leise sechs nachgelagerte Flüge annulliert.
Das dritte Element ist ein Szenario-Simulator, faktisch ein digitaler Zwilling des Betriebs, sodass ein Ops-Team ein Wintersturm-Szenario vorab proben und Recovery-Strategien testen kann, wenn es keinen tatsächlichen Sturm und keine tatsächliche Uhr gibt. Die Luftfahrt vertraut digitalen Zwillingen bereits dort, wo die Datenlage reich ist — Lufthansas AVIATAR-Plattform nimmt 23,7 Terabyte pro Tag über 34 Airline-Integrationen auf und erreicht 93,6 % Genauigkeit bei der Vorhersage von Wartungsausfällen. Crew- und Scheduling-Zwillinge stecken noch in den Anfängen, und genau darin liegt die Chance.
Und durch all das zieht sich die Constraint-Engine. Jede Empfehlung muss unter den FAA-Part-117-Ermüdungsregeln legal sein — den 8- bis 9-stündigen Flugzeitgrenzen, den 9- bis 14-stündigen Dienstzeiten — und unter dem Gewerkschaftsvertrag der Fluggesellschaft, der häufig restriktiver ist als die Vorschrift. Die meisten Anbieter behandeln diese Regeln als „Konfiguration“. Wir behandeln die Kodierung des spezifischen Tarifvertrags eines Carriers, nach Flotte und nach Heimatbasis, als Kern-Engineering, denn ein Recovery-Plan, der eine CBA-Klausel verletzt, ist kein Plan — er ist eine Beschwerde.
Warum wir zuerst im Shadow Mode laufen
Die Menschen in dieser Branche tun recht daran, einer Black Box zu misstrauen, die ihnen sagt, wie sie um 3 Uhr morgens Piloten verschieben sollen. Also erzähle ich Ihnen den Einwand, den ich am häufigsten höre, denn ich hatte ihn selbst.
Ein Ops-VP sagte uns früh, mehr oder weniger, dass sie gerade das KI-Störungs-Add-on von ihrem etablierten Anbieter lizenziert hätten und nicht einsähen, warum sie uns brauchten. Fair. Dann kam der nächste Sturm, das Add-on gab ihnen Vorhersagen und keine ausführbare Crew-Recovery, und die Disponenten waren zurück am Whiteboard. Die Unterscheidung, die mich diese Konversation lehrte: Es liegen Welten zwischen agentic AI für passagierseitigen Chat — dem Konferenz-Modewort des Jahres 2026 — und KI, die operative Entscheidungen über Crews und Flugzeuge trifft. Ein Chatbot, der einen Passagier umbucht, ist eine feine Sache. Es ist nicht dasselbe Engineering-Problem wie die Recovery eines Netzwerks.
Deshalb berührt unsere Engine, wenn eine Fluggesellschaft sie zum ersten Mal betreibt, den Betrieb nicht. Sie läuft im Shadow Mode: Die Empfehlung unseres Modells sitzt neben der tatsächlichen Entscheidung des menschlichen Disponenten, und wir messen die Lücke, Tag für Tag, anhand der eigenen Störungen der Fluggesellschaft. Vertrauen wird nicht in einem Sales-Deck behauptet. Es wird auf einem Vergleichsblatt verdient, ohne operatives Risiko, bis das Ops-Team selbst entscheidet, dass die Empfehlungen besser sind als das Whiteboard.
Sie verdienen sich das Recht, jemandes Piloten umzuleiten, nicht mit einem Benchmark. Sie verdienen es sich, indem Sie recht haben, still, neben einem Menschen, über Wochen hinweg, bevor irgendjemand Ihnen glauben muss.
Die ehrliche Wahrheit ist, dass ich beim Beobachten des Shadow Mode verstand, was wir eigentlich verkauften. Keinen Optimierer. Keine Geschwindigkeit. Wir verkauften einem Operations-Verantwortlichen einen Weg, in der schlimmsten Nacht seines Jahres einer Maschine zu glauben — und Glaube muss vor dem Sturm aufgebaut werden, nicht während seiner.
Was die 15 Tage wirklich wert sind
Wenn Sie den Betrieb einer mittelgroßen Fluggesellschaft leiten, funktioniert Ihr Crew-Solver an 350 Tagen im Jahr einwandfrei. Ich bin nicht hier, um das Gegenteil zu behaupten. Die Frage ist, was an den 15 Tagen passiert, an denen er es nicht tut — und das sind die Tage, die die milliardenschweren Schlagzeilen produzieren, die Audits mit 43 % falsch zugewiesener Crews und jetzt, seit letztem Oktober, die stündlich getakteten automatischen Barerstattungen.
Der Fehler, den die ganze Branche immer wieder macht — der Fehler, den ich zuerst machte, mit meinem eigenen schnelleren Solver — besteht darin, diese 15 Tage als ein Geschwindigkeitsproblem zu behandeln, das durch härteres Rechnen zu lösen ist. Das sind sie nicht. Sie sind ein Gewissheitsproblem, und man löst ein Gewissheitsproblem nicht, indem man von einer Welt, die aktiv auseinanderfällt, mehr Gewissheit verlangt. Man löst es, indem man etwas baut, das unter Unsicherheit schlussfolgert, die Katastrophe probt, bevor sie eintritt, und sich im Schatten beweist, bevor ihm je im Licht vertraut wird. Das ist die Engine, die wir gebaut haben, und sie wird vollständig auf unserer airline crew scheduling AI-Lösung beschrieben.
Irgendwo gibt es heute Nacht ein Operations Control Center, wo die Videowand ruhig und grün ist und ein Crew-Solver genau wie vorgesehen durch seinen Batch-Zyklus summt. Die Arbeit, die wir leisten, ist für die Nacht, in der dieser Raum rot wird — wenn die Telefone sich stauen, die Pairings schneller brechen, als irgendjemand sie aufschreiben kann, und ein Disponent zu einem Whiteboard greift, weil die Gewissheit, die die Software verlangt, sich still davongemacht hat. Der ganze Sinn besteht darin, sicherzustellen, dass die Maschine in jener Nacht immer noch ehrlich über eine Fluggesellschaft schlussfolgert, die sie nicht mehr vollständig sehen kann.
