We bouwden een snellere crewsolver voor luchtvaartmaatschappijen. Hij faalde alleen sneller.

De eerste keer dat ik tijdens een echte cascade in een operationeel controlecentrum van een luchtvaartmaatschappij zat, was het even na 3 uur 's nachts en had een winterstorm een paar uur eerder een cruciaal station gesloten. De videowand langs de voorkant van de ruimte liep vol met rood — annulering na annulering — en wat me het meest is bijgebleven, is dat niemand de miljoenen kostende crewplanningssolver gebruikte waarvoor de maatschappij had betaald. De dispatchers hadden hun toetsenborden opzij geschoven en werkten verbroken crewkoppelingen met de hand uit, op spreadsheets en een whiteboard, precies op het moment dat de software haar waarde had moeten bewijzen.

Dat beeld heeft er uiteindelijk toe geleid dat we AI voor luchtvaartcrewplanning voor IROPS-herstel gingen bouwen — maar niet op de manier die ik verwachtte, en niet voordat ik op de verkeerde oplossing had ingezet en die zag falen. IROPS, als je het genoegen nog nooit hebt gehad, is de branchterm voor onregelmatige operaties: de stormen, de sluitingen, de cascaderende chaos wanneer een dienstregeling uit elkaar valt. Het kost de luchtvaartsector naar schatting 60 miljard dollar per jaar, ruwweg 8% van de wereldwijde luchtvaartomzet, volgens IATA. Ongeveer één op de vijf vluchten wereldwijd wordt erdoor geraakt. En het vuile geheim dat ik die nacht leerde, is dat de meest geavanceerde optimalisatiesoftware in de luchtvaart in wezen ontworpen is om nutteloos te zijn tijdens precies die gebeurtenissen die het meest kosten.

De Solver Optimaliseerde een Luchtvaartmaatschappij Die Niet Meer Bestond

Het helpt om te weten wat de verouderde crewsolvers eigenlijk doen. Ze draaien column generation — een branch-and-price-optimalisatietechniek die echt briljant is in het vinden van de goedkoopste legale manier om een bekende dienstregeling te bemannen. Het addertje zit in het woord bekende. De solver maakt een momentopname van het netwerk, bevriest de tijd en berekent de optimale crewtoewijzing voor die bevroren wereld. Hij draait in batchcycli, doorgaans elke 30 tot 60 minuten.

Tijdens normale operaties is dat prima. De wereld verandert nauwelijks tussen de cycli. Maar tijdens een cascade verandert de netwerkstatus om de paar minuten. Crews verplaatsen zich. Aansluitingen breken. Vliegtuigen komen vast te zitten. Tegen de tijd dat de solver een oplossing teruggeeft, kloppen de invoergegevens die hij kreeg al niet meer — dus het antwoord is een perfect plan voor een luchtvaartmaatschappij die niet meer bestaat.

Ik begon dit de Optimalisatie-Uitvoeringskloof te noemen: de afstand tussen de wereld die de solver veronderstelde en de wereld die daadwerkelijk buiten op het platform is. De kloof is onschadelijk tijdens een geïsoleerde vertraging. Tijdens een cascade is hij fataal, want de solver was gebouwd voor efficiëntie — de goedkoopste dienstregeling in een bekende wereld — en wat je om 3 uur 's nachts wanhopig nodig hebt, is veerkracht: een dienstregeling die overleeft in een onbekende wereld.

Het wreedste aan een verouderde crewsolver is dat hij tijdens een meltdown gewoon blijft werken — en je kalm een vlekkeloos plan overhandigt voor een netwerk dat uiteenviel terwijl hij nog aan het rekenen was.

Waarom Konden We de Solver Niet Gewoon Sneller Maken?

Dit is het deel waar ik niet trots op ben, en het is het deel dat er eigenlijk toe doet.

Toen mijn team het probleem voor het eerst bekeek, was onze diagnose de voor de hand liggende ingenieursdiagnose: de solver is te traag. De wereld verandert om de vijf minuten en de optimizer doet er dertig minuten tot een uur over, dus dicht de kloof — maak hem sneller. We hebben echt tijd gestoken in het bouwen van een snellere herstelengine, waarbij we leunden op goedkopere heuristieken om binnen het operationele beslissingsvenster een haalbaar antwoord te krijgen in plaats van te wachten op een bewijsbaar optimaal antwoord.

En het werkte, in de beperkte zin dat het sneller antwoorden opleverde. Toen testten we het tegen echte verstoringsdata en ik zag het zelfverzekerd herstelplannen produceren die al ongeldig waren, alleen sneller. We hadden een machine gebouwd die met hogere snelheid een spookluchtvaartmaatschappij optimaliseerde.

De fout was dat we snelheid als het knelpunt behandelden. Dat was het niet. Het knelpunt was dat de invoergegevens fictie waren. De solver — de onze inbegrepen — heeft harde feiten nodig: "Captain Smith staat bij Gate B7 in Denver." Maar tijdens een cascade zou Captain Smith in het hotel kunnen zijn, in het personeelsbusje kunnen zitten, of een auto gehuurd kunnen hebben en halverwege Colorado Springs kunnen zijn. De eerlijke toestand van de wereld is "waarschijnlijk in Denver", en een column-generation-solver kan niets doen met waarschijnlijk. We hadden het antwoord aangescherpt op een vraag waarvan de gegevens rommel waren.

Dat falen is de reden dat het product bestaat. Als we de snelle solver hadden uitgebracht, hadden we luchtvaartmaatschappijen een snellere manier verkocht om dezelfde dure fout te maken.

Het Datazwarte Gat van 1,2 Miljard Dollar

Als je dit exacte falen op volledige schaal wilt zien, kijk dan naar wat er in december 2022 met Southwest gebeurde. De meltdown kostte de maatschappij ruwweg 1,2 miljard dollar, annuleerde rond de 16.900 vluchten en liet bijna twee miljoen passagiers tijdens de feestdagen stranden.

Het populaire verhaal is "oude software". Het echte verhaal is specifieker en nuttiger. Southwest's crewplanningssysteem, SkySolver, liep tegen een combinatorische explosie aan die het niet kon doorrekenen. Maar daaronder verloor de maatschappij het overzicht over waar haar eigen piloten en cabinepersoneel zich fysiek bevonden. De positierapportage van de crews liep grotendeels via telefoons — crews die op buitenstations gestrand waren belden een planningscentrum waar de wachttijden opliepen tot uren. Die vertraging creëerde wat ik zie als een datazwart gat: het systeem genereerde dienstregelingen voor crews die niet waren waar het dacht dat ze waren. Het optimaliseerde een spooknetwerk, en de point-to-point-routestructuur betekende dat er geen hub-"regeneratiepunten" waren waar crews en vliegtuigen op natuurlijke wijze weer samenkomen, dus de blast radius bleef zich maar station na station verspreiden.

Dit is geen oude geschiedenis die iedereen sindsdien heeft opgelost. In juli 2024 creëerde Spirit's planningssysteem conflicterende toewijzingen voor 43% van zijn beschikbare vluchtcrews, een gebeurtenis van naar schatting 50–100 miljoen dollar, omdat het systeem niet de flexibiliteit had om crews tijdens de verstoring netjes opnieuw toe te wijzen. Het patroon herhaalt zich omdat de onderliggende architectuur — optimaliseer een bevroren momentopname, eis zekere invoergegevens — in de hele sector hetzelfde is.

Southwest reageerde, tot hun eer, door te investeren: ongeveer 1,7 miljard dollar aan technologie in 2024 als onderdeel van een groter meerjarig programma, een AWS-migratie die hun datacenter-footprint drastisch verkleinde, en een ongeveer 30% sneller planningsalgoritme. Dat is het juiste instinct. Maar een snellere versie van dezelfde architectuur — wat de valstrik is waar we zelf bijna in trapten — dicht de snelheidskloof terwijl het de datazekerheidskloof wagenwijd open laat.

Wat Gebeurt Er Nu Wanneer een Vertraging de Drie Uur Overschrijdt?

Voor het grootste deel van de luchtvaartgeschiedenis kostte een traag herstel je goodwill. Boze passagiers, slechte pers, wat vouchers. Die rekensom veranderde op 28 oktober 2024.

Dat is wanneer de regel voor automatische terugbetaling van het Amerikaanse ministerie van Transport van kracht werd — de allereerste verplichte automatische terugbetalingseis. Elke binnenlandse vertraging van meer dan drie uur (zes voor internationaal) leidt nu tot een contante terugbetaling, betaald binnen zeven werkdagen, zonder dat de passagier er zelfs maar om vraagt. Geen voucher. Geen omboeking. Contant geld.

Reken het uit voor een middelgrote maatschappij die 300 vertrekken per dag uitvoert. Op een echt slechte dag, als zelfs maar een zesde daarvan — 50 vluchten — voorbij de drie-uurgrens glipt, kom je bij een gemiddelde ticketwaarde van $280 en 150 passagiers per vlucht uit op ongeveer 2,1 miljoen dollar aan verplichte terugbetalingsblootstelling op één enkele dag. Traag IROPS-herstel was vroeger een reputatieprobleem. Nu is het een kostenpost die dezelfde week toeslaat.

Er loopt nu een meter op elk uur dat je herstel achterloopt, en sinds afgelopen oktober keert die contant uit, automatisch, aan elke passagier die het raakt.

Dit is het deel dat het hele gesprek voor mij in een ander licht plaatste. De kosten van de Optimalisatie-Uitvoeringskloof zijn niet langer abstract. Ze stapelen zich op, in dollars, tegen een klok die begon te lopen op het moment dat de storm dat deed.

Versterk de Solver, Vervang Hem Niet

Dit is de beslissing die onze aanpak definieert, en het is een bewust onspannende: we vervangen je solver niet.

De gevestigde solvers coderen decennia aan luchtvaartspecifieke domeinkennis, en het veld eromheen consolideert, het stort niet in. Jeppesen — de industriestandaard, met meer dan honderd luchtvaartklanten — werd in april 2025 door Boeing verkocht aan Thoma Bravo voor 10,55 miljard dollar, een van de grootste techafstotingen in de geschiedenis van de luchtvaart, en heeft sindsdien Stratosphere gelanceerd, een AI-laag voor voorspellend verstoringsbeheer. IBS Software's iFlight-platform wint moderne, cloud-native implementaties — Korean Air ging begin 2026 live, met maatschappijen als Aeroitalia en de luchtvaartmaatschappijen van Groupe Dubreuil die er ook op overstappen — ondersteund door een co-engineering-samenwerking met AWS. Optym's CrewSolver levert een gedocumenteerde kostenreductie van 3–7% aan de planningskant.

Geen van die is de vijand. Maar let op waar ze elk sterk in zijn: optimalisatie in de planningsfase en voorspellende analyse — de bekende wereld, prachtig doorgerekend. Het realtime herstelprobleem met onzekere invoer is de kloof die openblijft. Een volledige platformvervanging is ook een project van 12 tot 18 maanden, en geen enkele operationele leider wil het systeem dat 350 dagen per jaar werkt eruit rukken om de 15 dagen die dat niet doen te repareren. Voor de CIO die het contract daadwerkelijk tekent, is de rekensom erger dan de kalender: het eruit rukken van een systeem met decennia aan maatschappijspecifieke cao-logica erin gecodeerd — juist op het moment dat de eigendom van Jeppesen zelf net van eigenaar is gewisseld voor 10,55 miljard dollar en zijn langetermijnroadmap een open vraag is — is een gok die de meeste tech-organisaties niet willen wagen. Naast de bestaande installatie zitten, de feeds ervan consumeren in plaats van het schema te vervangen, is de enige integratie waar ze groen licht voor zullen geven.

Dus bouwden we een ML-aangedreven IROPS-herstelengine die naast een bestaande Jeppesen- of IBS-installatie zit en het ding aanpakt dat de kernsolver niet kan: cascaderende verstoringen met onzekere crewposities, netwerkbrede blast-radius-analyse en herstelplannen die in minuten worden geproduceerd in plaats van de 4 tot 12 uur die handmatig herstel doorgaans kost. Regionale casusdata suggereren dat automatisering die hersteltijd met ongeveer 78% kan terugbrengen. Het punt is niet om slimmer te zijn dan de gevestigde speler. Het is om nuttig te zijn in precies de omstandigheden waarvoor de gevestigde speler nooit ontworpen was.

Een Model Leren Werken Met "Waarschijnlijk in Denver"

Zodra we stopten met proberen de solver sneller te maken, kwam het eigenlijke technische probleem scherp in beeld: bouw iets dat gedijt op onzekerheid in plaats van erin te stikken.

Het eerste stuk is crewpositie-intelligentie. In plaats van een zekere locatie te eisen, voeden we een model met probabilistische posities — waarbij we alle realtime signalen die er zijn combineren met historisch gedrag, zodat het systeem redeneert over waar een crew waarschijnlijk is in plaats van te wachten op een telefoontje dat vier uur diep in een wachtrij zit. Die ene verschuiving — van "zeker of niets" naar "kansverdeling" — is wat een herstelplan het contact met een echte cascade laat overleven.

Het tweede stuk is het netwerk als een graaf behandelen en analyseren waar storingen zich zullen voortplanten voordat ze dat doen — de blast radius, in kaart gebracht op de specifieke routestructuur van deze luchtvaartmaatschappij, zodat je kunt zien welke stationssluiting stilletjes zes stroomafwaartse vluchten over twee uur annuleert.

Het derde stuk is een scenariosimulator, in feite een digital twin van de operatie, zodat een ops-team van tevoren een winterstormscenario kan oefenen en herstelstrategieën kan testen wanneer er geen echte storm en geen echte klok is. De luchtvaart vertrouwt al op digital twins waar de data rijk is — het AVIATAR-platform van Lufthansa verwerkt 23,7 terabyte per dag over 34 luchtvaartintegraties en haalt 93,6% nauwkeurigheid op het voorspellen van onderhoudsstoringen. Crew- en planningstwins staan nog in de kinderschoenen, wat precies is waar de kans ligt.

En door dit alles heen loopt de constraint-engine. Elke aanbeveling moet legaal zijn onder de FAA Part 117-vermoeidheidsregels — de vliegtijdlimieten van 8 tot 9 uur, de dienstperioden van 9 tot 14 uur — en onder het vakbondscontract van de maatschappij, dat vaak meer beperkend is dan de regelgeving. De meeste leveranciers behandelen die regels als "configuratie". Wij behandelen het coderen van de specifieke collectieve arbeidsovereenkomst van een maatschappij, per vloot en per standplaats, als kern-engineering, want een herstelplan dat een cao-clausule schendt, is geen plan — het is een grief.

Waarom We Eerst in Shadow Mode Draaien

Mensen in deze sector hebben gelijk om een black box te wantrouwen die hun vertelt hoe ze om 3 uur 's nachts piloten moeten verplaatsen. Dus ik zal je het bezwaar vertellen dat ik het vaakst hoor, want ik had het zelf ook.

Een ops-VP vertelde ons in het begin, min of meer, dat ze net de AI-verstoringsuitbreiding van hun gevestigde leverancier hadden gelicentieerd en niet inzagen waarom ze ons nodig hadden. Terecht. Toen kwam de volgende storm, gaf de uitbreiding hun voorspellingen en geen uitvoerbaar crewherstel, en zaten de dispatchers weer aan het whiteboard. Het onderscheid dat dat gesprek me leerde: er is een wereld van verschil tussen agentic AI voor passagiersgerichte chat — het modewoord van het conferentiecircuit van 2026 — en AI die operationele beslissingen neemt over crews en vliegtuigen. Een chatbot die een passagier omboekt, is een prima ding. Het is niet hetzelfde technische probleem als het herstellen van een netwerk.

Daarom raakt onze engine, de eerste keer dat een luchtvaartmaatschappij hem draait, de operatie niet aan. Hij draait in shadow mode: de aanbeveling van ons model staat naast de daadwerkelijke beslissing van de menselijke dispatcher, en we meten de kloof, dag na dag, op de eigen verstoringen van de maatschappij. Vertrouwen wordt niet beweerd in een verkooppresentatie. Het wordt verdiend op een vergelijkingsblad, zonder operationeel risico, totdat het ops-team zelf besluit dat de aanbevelingen beter zijn dan het whiteboard.

Je verdient het recht om iemands piloten om te leiden niet met een benchmark. Je verdient het door gelijk te hebben, stilletjes, naast een mens, weken achtereen, voordat wie dan ook je hoeft te geloven.

De eerlijke waarheid is dat het kijken naar shadow mode het moment was waarop ik begreep wat we eigenlijk verkochten. Geen optimizer. Geen snelheid. We verkochten een manier voor een operationele leider om een machine te geloven op de ergste nacht van hun jaar — en geloof moet vóór de storm worden opgebouwd, niet tijdens de storm.

Wat de 15 Dagen Echt Waard Zijn

Als je de operatie van een middelgrote luchtvaartmaatschappij runt, werkt je crewsolver 350 dagen per jaar prima. Ik ben hier niet om het tegendeel te betogen. De vraag is wat er gebeurt op de 15 dagen dat dat niet zo is — en dat zijn de dagen die de miljardenkoppen produceren, de audits van 43%-van-de-crews-verkeerd-toegewezen, en nu, sinds afgelopen oktober, de automatische contante terugbetalingen die per uur worden afgemeten.

De fout die de hele sector blijft maken — de fout die ik als eerste maakte, met mijn eigen snellere solver — is het behandelen van die 15 dagen als een snelheidsprobleem dat opgelost moet worden door harder te rekenen. Dat zijn ze niet. Het zijn een zekerheidsprobleem, en je lost een zekerheidsprobleem niet op door meer zekerheid te eisen van een wereld die actief uit elkaar valt. Je lost het op door iets te bouwen dat redeneert onder onzekerheid, de ramp oefent voordat die arriveert, en zichzelf in de schaduw bewijst voordat het ooit in het licht wordt vertrouwd. Dat is de engine die we bouwden, en die volledig wordt beschreven op onze AI-oplossing voor luchtvaartcrewplanning.

Ergens vanavond is er een operationeel controlecentrum waar de videowand kalm en groen is, en een crewsolver door zijn batchcyclus zoemt precies zoals ontworpen. Het werk dat wij doen is voor de nacht dat die ruimte rood wordt — wanneer de telefoons vollopen, de koppelingen sneller breken dan iemand ze kan opschrijven, en een dispatcher naar een whiteboard grijpt omdat de zekerheid die de software eist stilletjes het pand heeft verlaten. Het hele punt is om ervoor te zorgen dat de machine, op die nacht, nog steeds eerlijk redeneert over een luchtvaartmaatschappij die hij niet langer volledig kan zien.