MRO-Ersatzteilprognose: Just-in-Time für teure Rotable Parts

Das echte Ausmaß des Problems

Die Luftfahrtindustrie verliert jährlich schätzungsweise 30 Milliarden US-Dollar durch AOG-Situationen (Aircraft on Ground) — direkte Betriebskosten, Passagierentschädigungen und verpasste Verbindungen zusammengerechnet. Ein signifikanter Teil davon entsteht nicht durch unvorhergesehene Teileausfälle, sondern durch das systematische Scheitern der Bestandsplanung: Das richtige Teil ist im falschen Lager, beim falschen Lieferanten oder gar nicht vorhanden.

Gleichzeitig liegt das Problem auf der anderen Seite: 22 bis 30 Prozent der Rotable-Bestände sind zu einem gegebenen Zeitpunkt überschüssig oder veraltet. Für einen Betrieb mit 100 Flugzeugen entspricht das 8 bis 15 Millionen Euro an gebundenem Kapital, das keinerlei Rendite erzielt — aber vollständige Kapitalbindungs- und Lagerkosten trägt (laut oxmaint.com, Aviation MRO Analysis 2026). Diese Teile wurden eingekauft, weil jemand auf der sicheren Seite sein wollte. Sie liegen im Regal, weil niemand vorhersagen konnte, dass sie in den nächsten zwei Jahren nicht gebraucht werden.

Das ist das grundlegende Paradox der Rotable-Planung: Zu wenig bedeutet AOG-Risiko, zu viel bedeutet Kapitaltod. Und klassische Prognosemodelle können dieses Paradox nicht auflösen, weil sie für genau diesen Bedarfstyp nicht gebaut wurden.

Was das Problem für Planungssysteme besonders schwer macht:

• Sporadischer Bedarf: Ein CFM56-Stage-1-Disc wird vielleicht zweimal im Jahr verbraucht — über eine Flotte von 80 Flugzeugen. Zwischen den Ereignissen liegen Wochen ohne Verbrauch. Klassische Prognosen, die auf Wochen- oder Monatsdurchschnitte basieren, liefern hier Phantomzahlen.
• Verkoppelter Bedarf: Heavy Checks (C-Check, D-Check) erzeugen konzentrierten Bedarf für viele Teile gleichzeitig. Wer den Checkplan kennt, kann den Bedarf 8–12 Wochen voraussagen. Wer ihn nicht integriert, plant am Bedarf vorbei.
• Altersabhängiger Drift: Die Ausfallwahrscheinlichkeit eines Avionik-LRUs nach 20.000 Flugstunden ist eine andere als nach 5.000. Flotten altern — das ändert das Verbrauchsmuster jedes Jahr, aber klassische Modelle lernen das nicht.
• Robustheit des Lagerwertes: Ein einzelnes Hydraulik-Servo für einen A330 kostet 180.000 Euro. Ein Fehlgriff in der Prognose — entweder in die falsche oder in die richtige Richtung — ist sofort in der Bilanz sichtbar.

Warum Croston-Methode und Winters-Smoothing scheitern

Für Lagerplaner in der Luftfahrt ist die Croston-Methode seit Jahrzehnten der Standard für sporadische Bedarfe. Croston modelliert Nachfragehäufigkeit und Nachfragegröße getrennt — ein eleganter Ansatz für Teile, die gelegentlich, aber dann immer in ähnlichen Mengen verbraucht werden.

Das Problem: Rotable Parts in der Luftfahrt haben einen anderen Bedarfscharakter.

Croston scheitert bei “erratischem” Bedarf — also Bedarfsmustern, bei denen nicht nur die Häufigkeit, sondern auch die Menge pro Ereignis stark schwankt. Eine Komponente, die dieses Jahr einmal und mit drei Einheiten, nächstes Jahr dreimal und mit je einer Einheit verbraucht wird — das ist für Croston mathematisch schwer zu greifen. Die akademische Forschung ist hier eindeutig: Künstliche Neuronale Netze (ANN) und LSTM-Modelle übertreffen Croston-basierte Methoden bei erratischem Bedarf konsistent (Syntetos et al., IEEE 2012; Bregant et al., Aerospace 2023).

Winters-Smoothing (Holt-Winters-Exponentialglättung) ist für saisonale Nachfragemuster mit regelmäßigem Verbrauch entwickelt. Es setzt voraus, dass Daten eine erkennbare Periodizität haben. Bei Rotable Parts gibt es keine solche Saisonalität im klassischen Sinne — der Bedarf richtet sich nach Betriebsstunden, Zyklen und Checkplänen, nicht nach Kalenderwochen.

Das fundamentale Problem beider Methoden ist ihre Ignoranz gegenüber externen Treibern. Weder Croston noch Winters-Smoothing kann integrieren:

• Den bevorstehenden C-Check von MSN 1234 in Woche 8
• Die überalternde Avionik-Fleet auf dem CFM56-Typ, die gerade in die kritische Verschleißphase einläuft
• Den Wechsel der Flottenzusammensetzung, weil drei neue A320neo eingehen und drei alte B737-300 ausscheiden

Machine Learning-Modelle — insbesondere Gradient-Boosting-Methoden wie XGBoost oder LightGBM — können genau diese externen Features als Eingabevariablen verarbeiten. Das ist ihr struktureller Vorteil.

Eine Studie, die an einem europäischen MRO-Servicecenter validiert wurde (ScienceDirect, 2026), erreichte mit einem ML-Rahmenwerk in 99,2 % der analysierten SKUs die genaueste Prognose im Vergleich zu klassischen Basismodellen — darunter Croston, gleitender Durchschnitt und exponentielles Smoothing. Das ist keine akademische Randstudie, das ist das reale Messergebnis in einem laufenden Betrieb.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Laut oxmaint.com (Aviation MRO Spare Parts Demand Forecasting Guide, 2026) und ScienceDirect (2026).
² Richtwert aus mehreren Praxisberichten; abhängig von Flottenhomogenität und Datenqualität.

Einschätzung auf einen Blick

Zeitersparnis — niedrig (2/5)
Für Techniker, Piloten oder Fluggäste spart ein Prognosemodell keine direkte Arbeitszeit — es verlagert den Aufwand von reaktiver Panikbeschaffung zu geplanter Bestandspflege. Die Zeit, die ein Material Planner für manuelle Bestandsprüfungen und AOG-Notfallbestellungen aufwendet, sinkt. Aber das ist kein großer Tagesstunden-Hebel; der Wert liegt in vermiedenen AOG-Situationen, nicht in beschleunigten Abläufen.

Kosteneinsparung — herausragend (5/5)
Das ist der stärkste ROI-Hebel im luft-raumfahrt-Bereich. 8–15 Millionen Euro freigesetztes Kapital aus Überbeständen, vermiedene AOG-Kosten (50.000–150.000 €/Tag) und niedrigere Notfallbeschaffungspreise summieren sich für einen mittelgroßen Betrieb auf Einsparungen im siebenstelligen Bereich jährlich. Dieser Effekt ist direkt messbar — er erscheint in der Bilanz.

Schnelle Umsetzung — mittel (3/5)
Die eigentliche ML-Modellentwicklung ist technisch handhabbar, aber die Datenvorbereitung dominiert den Zeitplan. CMMS-Historien mit 3–5 Jahren sauberer Verbrauchsdaten, saubere Anbindung an Flugplanungssysteme, validierte Teilenummern-Stammdaten — das dauert. Pilotbetrieb ist nach 6–9 Monaten realistisch; Vollbetrieb eher nach 12–18 Monaten. Im Vergleich zu anderen Prognose-Use-Cases im Bereich ist das Mittelfeldniveau.

ROI-Sicherheit — herausragend (5/5)
Der Nutzen ist direkt messbar: Du zählst, wie viel Lagerkapital freigesetzt wird (Bestandswert vor vs. nach), und du protokollierst AOG-Vorfälle mit und ohne System. Das ist kein indirekter Effekt — anders als bei der KI-Wartungsdokumentation, wo der Nutzen hauptsächlich in Zeitersparnis und Fehlerreduktion liegt, erscheinen die Lagereinsparungen unmittelbar in der Bilanz.

Skalierbarkeit — hoch (4/5)
Je mehr Flugzeuge im Betrieb, desto mehr Verbrauchsereignisse pro Teilnummer — das macht das ML-Modell genauer, nicht ungenauer. Neue Flugzeugtypen können als Features hinzugefügt werden, sofern ausreichend Historiendaten vorhanden sind. Nicht ganz maximal bewertet, weil Modell-Retraining bei Flottenveränderungen (Typ-Zukauf, Retirement) manuelles Eingreifen erfordert und nicht vollautomatisch läuft.

Richtwerte — stark abhängig von Flottengröße, Datenqualität und vorhandenem CMMS-System.

Was das Prognosemodell konkret macht

Ein ML-Bedarfsprognosemodell für Rotable Parts ist im Kern ein Predictive Analytics-System, das auf vier Datenquellen gleichzeitig hört:

1. Historische Verbrauchsdaten aus dem CMMS
Welches Teil wurde wann, wie oft und in welchem Flugzeug verbraucht? Die Verbrauchshistorie ist die Basisschicht — aber sie allein reicht nicht aus.

2. Flugprogramm und Flugstunden je Flugzeug
Wieviele Flugzyklen und -stunden sammelt jedes Flugzeug der Flotte? Hochintensiv genutzte Maschinen auf Kurzstrecken akkumulieren Druckzyklen schneller als Langstreckenflieger — das beschleunigt bestimmte Ausfallmuster. Das Modell lernt diese Kopplung.

3. Heavy-Check-Kalender
Wann stehen C-Check und D-Check für welche Maschine an? Diese Ereignisse erzeugen den größten konzentrierten Einzelbedarf. Ein Modell, das den Check-Kalender kennt, kann 8–12 Wochen im Voraus Bestandsempfehlungen erzeugen, anstatt erst nach dem ersten Defect-Report zu reagieren.

4. Flottenzustand: Alter, Bauteillebenszyklen, offene Work Orders
Wie alt ist die Avionik auf MSN 1234? Wann wurde das Fahrwerk zuletzt überholt? Welche offenen defects liegen noch nicht geschlossen? Diese Zustands-Features verlagern die Prognose von rein vergangenheitsbasierter auf zustandsbasierte Vorhersage.

Das Modell — in der Praxis meist ein Gradient Boosting-Verfahren wie XGBoost oder LightGBM, optional kombiniert mit Prophet für die Zeitreihenkomponente — erzeugt daraus eine Wahrscheinlichkeitsverteilung: Für Teilenummer 12-345-6789 gibt es eine Chance von X % auf einen Verbrauch in den nächsten 4 Wochen, Y % auf 2+ Einheiten in 8 Wochen.

Aus dieser Verteilung werden Bestandsempfehlungen abgeleitet: Liegt der aktuelle Lagerbestand unter dem Modell-Threshold, wird eine Bestellempfehlung ausgelöst — rechtzeitig genug, um normale Lieferzeiten zu nutzen und teure AOG-Expresslieferungen zu vermeiden.

Was das Modell nicht tut: Es prognostiziert keine unbekannten Ausfallmodi (Vogelschlag, strukturelle Schäden) und ersetzt keine technische Urteilsfähigkeit des Ingenieurs. Es ist ein statistisches Planungswerkzeug, kein Diagnose-KI.

Konkrete Werkzeuge — was wann passt

Die Frage ist nicht “KI ja oder nein” — sie ist, welche Ebene der Lösung zu eurem bestehenden System-Stack passt.

AMOS (Swiss AviationSoftware) — Das meistgenutzte MRO-System in der Luftfahrt hat keine nativen ML-Prognose-Features, liefert aber die CMMS-Datengrundlage, auf der Prognosemodelle aufgebaut werden. Wenn ihr AMOS als Kernsystem habt, ist die Datenqualität für ML-Forecasting in der Regel gegeben — der Schritt ist die Integration einer Forecasting-Schicht obendrauf (eigene Entwicklung oder Drittanbieter). AMOS-Kosten: sechsstellig im Jahr für mittlere Flotten, plus Implementierung.

Ramco Aviation Suite — Ramco hat eingebettete AI/ML-Funktionen für Predictive Maintenance und Komponentenzuverlässigkeit, die über reines Regelwerk hinausgehen. Das ist der vollständigste Out-of-the-Box-Ansatz: ERP, MRO und eingebettete Prognose in einer Plattform. Vorteil: keine Schnittstellenkosten zwischen CMMS und Forecast-Engine. Nachteil: Ramco ist in DACH kaum vertreten, deutschsprachiger Support fehlt. Geeignet für große Betriebe ab 50+ Flugzeugen mit eigenem IT-Team.

ePlane.ai — Fokus liegt auf der Beschaffungsseite: automatisierte RFQ-Verarbeitung, Angebotsvergleich und AOG-Eskalation. ePlane.ai integriert sich in SAP, Oracle und Ramco und kann Bestellvorschläge aus ML-Prognosemodellen automatisiert verarbeiten. Ab 1.499 USD/Monat im Starter-Plan. Sinnvoll, wenn die Prognoseschicht bereits steht und jetzt der Beschaffungsprozess automatisiert werden soll.

SAP IBP (Integrated Business Planning) — Für Betriebe, die SAP S/4HANA als ERP-Backbone nutzen, ist SAP IBP der naheliegende Weg für ML-gestützte Demand Planung — mit integrierter Gradient-Boosting- und Neural-Network-Forecast-Engine. EU-Hosting verfügbar, DSGVO-konform mit AVV. Nachteil: Implementierung dauert 6–18 Monate, Lizenz- und Beratungskosten im sechs- bis siebenstelligen Bereich. Nur sinnvoll, wenn SAP bereits vorhanden ist.

Eigene ML-Pipeline (scikit-learn + Prophet) — Für Betriebe mit eigenem Data-Engineering-Team ist die Open-Source-Route oft die flexibelste. Infrastrukturkosten: typisch 0–500 €/Monat. Die CMMS-Daten werden exportiert, in Python verarbeitet, das Modell trainiert und die Ergebnisse zurück in das CMMS gespielt. Vorteil: vollständige Datenkontrolle, keine Vendor-Abhängigkeit, DSGVO-sauber. Nachteil: erfordert Python-kompetentes Personal und laufende Modellpflege.

Zusammenfassung: Wann welcher Ansatz

• Ihr nutzt AMOS und wollt die Prognoseschicht ergänzen → eigene ML-Pipeline oder Drittanbieter-Integration
• Ihr evaluiert ein neues MRO-System mit eingebetteter KI → Ramco Aviation Suite
• Ihr habt SAP S/4HANA und wollt im Stack bleiben → SAP IBP
• Ihr wollt die Beschaffungsautomatisierung nach der Prognose → ePlane.ai ergänzend
• Ihr habt ein Data-Science-Team und wollt volle Kontrolle → scikit-learn + Prophet selbst gehostet

Datenschutz und Datenhaltung

MRO-Bedarfsdaten sind zunächst keine personenbezogenen Daten im DSGVO-Sinne — Teilenummern, Verbrauchshistorien und Flugzeugkennungen enthalten in der Regel keine personenbezogenen Informationen. Die DSGVO-Relevanz steigt, wenn Mitarbeiterdaten einbezogen werden: Zertifizierungsnachweise, Qualified-Inspector-Signaturen, Schichtpläne. Sobald diese Daten in ein ML-System fließen, greift DSGVO vollständig.

Für die gängigen Systeme gilt:

• AMOS (Swiss AviationSoftware, Schweiz/EU): EU-Datenhosting bei AMOScloud-Option. On-Premise ist vollständig selbst kontrolliert. AVV-Abschluss ist Standard im Enterprise-Vertrag. Empfehlung für EU-Betriebe: AMOScloud mit explizit vereinbartem EU-Rechenzentrum.

• Ramco Aviation Suite: Globales Hosting, EU-Datenhaltung möglich, aber nicht Standard — muss vertraglich explizit fixiert werden. Für DSGVO-sensitive Betriebe: EU-Serverstandort schriftlich vereinbaren und AVV nach Art. 28 DSGVO abschließen.

• ePlane.ai: US-Hosting. GDPR-zertifiziert und SOC 2-konform — aber für Betriebe mit strikter EU-Datenhaltungspflicht kritisch zu prüfen. Flugzeugkennungen und Beschaffungsdaten sind in der Regel keine personenbezogenen Daten, aber interne Beschaffungspreise und Lieferantenkonditionen können als Betriebsgeheimnisse schutzwürdig sein.

• SAP IBP: EU-Hosting in Frankfurt/Niederlande wählbar, AVV standardmäßig im Cloud-Vertrag. ISO 27001, SOC 2 — compliance-seitig der stärkste Track Record unter den genannten Tools.

• Eigene ML-Pipeline: Vollständige Datensouveränität bei Self-Hosting auf EU-Infrastruktur (z. B. AWS Frankfurt, Azure Germany). Das ist für regulierte Luftfahrtbetriebe häufig die bevorzugte Lösung.

Wichtig für alle Setups: Wer ML-Modelle auf Wartungshistorien trainiert, die auch Qualifikationsnachweise oder Zertifizierungsdaten von Certifying Staff enthalten, muss prüfen, ob ein Verarbeitungsverzeichnis gemäß Art. 30 DSGVO angepasst werden muss. Das ist kein pauschales Hindernis, aber ein Schritt, der vor dem Produktivbetrieb erledigt sein sollte.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

• Datenaufbereitung und CMMS-Historienbereinigung: 2–4 Monate interner Aufwand (Datenpflege, Mapping von Teilenummern, Bereinigung von Duplikaten). Dieser Schritt ist nicht delegierbar — er verlangt Domänenwissen aus der eigenen Technik.
• Externe Unterstützung für ML-Modellentwicklung (wenn kein internes Data-Science-Team): 40.000–120.000 €, abhängig von Flottengröße und Systemkomplexität.
• Integration ins CMMS (AMOS, Ramco oder SAP): 15.000–50.000 € Schnittstellen-Entwicklung, oft durch den CMMS-Anbieter oder einen Implementierungspartner.

Laufende Kosten (monatlich)

• Eigene ML-Pipeline: 500–2.000 €/Monat Infrastruktur (Cloud-Computing, Hosting)
• ePlane.ai Starter: 1.499 USD/Monat (für Beschaffungsautomatisierung zusätzlich zur Prognose)
• SAP IBP: 80.000–200.000 €/Jahr Lizenz für mittlere Implementierungen, plus Implementierungskosten

Konservatives ROI-Szenario für einen 80-Flugzeug-Betrieb

• Aktueller Rotable-Bestandswert: angenommen 120 Mio. €
• Überschussbestand (25 % des Bestands): 30 Mio. €
• Realistisch reduzierbarer Überschuss durch bessere Prognose (50 % davon): 15 Mio. €
• Kapitalkosten-Einsparung bei 6 % Zinskosten: 900.000 €/Jahr
• Vermiedene AOG-Vorfälle (–30 %, à durchschnittlich 80.000 € Folgekosten, 5 Vorfälle im Jahr): 120.000 €/Jahr
• Gesamteinsparung konservativ: 1,02 Mio. €/Jahr
• Investition (Einrichtung + erstes Betriebsjahr): 150.000–350.000 €
• Amortisation: 4–8 Monate nach Vollbetrieb

Zum Vergleich: Qatar Airways berichtete 2023 über 38,5 Millionen Dollar Jahreseinsparungen aus einem KI-basierten MRO-Optimierungsprogramm — 310 % ROI innerhalb von 18 Monaten. Das ist ein Großbetrieb; Richtwerte für mittlere Betriebe liegen tiefer, aber die Struktur des ROI ist identisch.

Wie du den Nutzen wirklich misst
Messe nicht nur Kosten, sondern drei konkrete Kennzahlen:

1. Excess Stock Ratio: Bestandswert von Teilen ohne Verbrauch in den letzten 24 Monaten — sinkt bei guter Prognose messbar.
2. AOG-Vorfälle nach Ursache: Wie viele AOGs waren auf fehlende Teile zurückzuführen? Wird das besser?
3. Notfallbeschaffungsquote: Anteil der Bestellungen unter AOG-Bedingungen (Express, höherer Preis) — sinkt, wenn Bedarfe früher erkannt werden.

Typische Einstiegsfehler

1. Das Modell mit zu wenig Daten pro Teilnummer trainieren.
ML-Forecasting für Rotable Parts braucht pro Teilnummer eine ausreichende Verbrauchshistorie — Faustregel: mindestens 20–30 Verbrauchsereignisse über den Trainingszeitraum. Bei einer seltenen Komponente, die über eine 50-Flugzeug-Flotte nur dreimal pro Jahr verbraucht wird, hat man nach zwei Jahren Historienbetrachtung gerade mal 6 Datenpunkte. Das reicht für kein belastbares Modell. Lösung: Für solche Teile bleiben statistische Methoden (Croston mit angepassten Safety-Stock-Buffern) überlegen — ML soll dort eingesetzt werden, wo Dichte und Varianz stimmen. Eine kluge Segmentierung des Teilebestands (ABC-XYZ-Analyse) vor dem Modellaufbau ist Pflicht.

2. Das Heavy-Check-Programm nicht als Feature integrieren.
Das ist der häufigste und teuerste Fehler. Wer eine ML-Prognose baut, die nur auf Verbrauchshistorie trainiert ist und den C-Check-Kalender ignoriert, bekommt eine Prognose, die in Wochen ohne Check präzise ist und in den 4 Wochen vor einem Check systematisch zu niedrig liegt. Konkret: Ein C-Check an einem A320 erzeugt typischerweise Bedarf für 30–60 Rotable-Positionen gleichzeitig. Fehlt dieser Spike in der Prognose, entstehen innerhalb einer einzigen Check-Woche 5–15 Notfallbestellungen mit Express-Aufschlägen von 20–40 % gegenüber normalen Beschaffungspreisen. Wenn der Check-Kalender nicht als Modell-Input eingebaut ist, wird der Effekt als Anomalie behandelt — und kann nicht antizipiert werden. Lösung: Check-Datum und Typ (C/D) als Pflicht-Feature von Tag 1 einbauen, bevor das erste Modell trainiert wird.

3. Modellpflege nach dem Go-Live vergessen.
Das ist der stille Killer: Nach Inbetriebnahme läuft das Modell, die Prognosen kommen raus, und niemand überprüft mehr systematisch, ob das Modell noch stimmt. In der Luftfahrt ändert sich das Umfeld ständig: neue Flugzeugtypen in der Flotte, Retirement alter Maschinen, veränderte Flugrouten, neue OEM-Reliability-Bulletins. Forschungsergebnisse zeigen, dass ML-Modelle ohne Retraining über 18 Monate bis zu 14–19 % an Prognosegenauigkeit verlieren. Lösung: Vierteljährliches Modell-Review als festen Prozessschritt einplanen. Wer der Verantwortliche für das Modell ist, muss namentlich festgelegt sein — nicht “die IT” oder “das Data-Team”.

4. Zu kleinen Piloten starten, der keine Erkenntnisse liefert.
Manche Betriebe starten mit einem Piloten auf 3–5 Teilnummern, die sowieso gut planbar sind (hoher Verbrauch, gleichmäßige Häufigkeit). Das funktioniert gut, beweist aber nichts. Der wirkliche Test ist genau andersherum: Die schwersten Fälle — seltene, teure Rotables mit sporadischem Bedarf — sollten im Piloten sein. Nur dort zeigt sich der echte Mehrwert gegenüber Croston.

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

Die technische Implementierung ist der kleinere Teil dieser Einführung. Der größere Teil ist Vertrauen.

Material Planner, die seit 15 Jahren Bestandsentscheidungen nach Bauchgefühl und Excel-Tabellen treffen, werden einem neuen System nicht sofort vertrauen — zumal das System manchmal empfiehlt, einen teuren Rotable nicht auf Lager zu legen, obwohl der Planer “weiß”, dass er gebraucht werden wird. Dieser Konflikt ist unvermeidbar.

Drei typische Widerstands-Muster:

Die “Wir wissen es besser”-Gruppe. Erfahrene Planer haben Jahrzehnte domänenspezifisches Wissen aufgebaut. Sie werden Fälle finden, wo das Modell daneben liegt — und diese Fälle werden intern zirkulieren. Keine Reaktion darauf zu haben ist gefährlich. Hilfreiche Gegenmaßnahme: Das Modell dokumentiert, warum es eine Empfehlung macht — welche Features haben die Prognose getrieben. Wenn ein Planer sieht, dass das Modell den bevorstehenden C-Check als Haupttreiber nennt, versteht er die Logik. Und wenn er eine Empfehlung überstimmt, wird das protokolliert — als Trainingsdaten für das nächste Modell.

Die “AOG-Trauma”-Gruppe. Nach einem schweren AOG-Vorfall werden manche Planer tendieren, Safety-Stock-Buffer zu erhöhen — auch wenn das Modell dagegen empfiehlt. AOG-Trauma ist eine psychologische Realität in MRO-Betrieben. Das Modell kann das nicht weg-optimieren. Was hilft: Klare Verantwortungsverteilung. Das Modell gibt Empfehlungen, der Planer trifft die Entscheidung und unterschreibt. Diese Verantwortungsstruktur muss explizit gemacht werden.

Die “Bereichsdenken”-Fraktion. Prognosemodelle optimieren über die gesamte Flotte. Das bedeutet manchmal, dass ein bestimmtes Teil für Station A empfohlen wird, weil dort die Wahrscheinlichkeit höher ist — obwohl Station B das gleiche Teil in letzter Zeit häufiger gebraucht hat. Station-B-Planer werden das als “unfair” empfinden. Hier braucht es entweder eine Station-eigene Modellinstanz oder eine transparente Kommunikation über die Optimierungslogik.

Was konkret funktioniert:

• Modell-Output immer mit Begründung ausgeben: “Empfehle 2 Einheiten, weil: C-Check MSN 4782 in Woche 9 + erhöhte Ausfallrate im letzten Quartal”
• Erste 6 Monate im “Advisory Mode”: Planer treffen die Entscheidungen, Abweichungen werden aber dokumentiert
• Vierteljährliches Feedback-Meeting: Wo lag das Modell falsch? Was war der Grund?

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

“Wir haben dafür keine Daten.”
Das stimmt meistens nicht ganz — aber oft sind die Daten nicht in der erwarteten Qualität. AMOS, Ramco und ähnliche CMMS-Systeme speichern seit Jahren jeden Teileaustausch. Die Frage ist, ob die Einträge konsistent sind: Sind Teilenummern standardisiert? Sind Timestamps zuverlässig? Ist die Zuordnung zu Flugzeug-MSN lückenlos? In der Praxis fehlt häufig nicht die Verbrauchshistorie, sondern die verknüpfte Kontextinformation — wann war welches Flugzeug in welchem Check? Dieses Mapping ist der eigentliche Aufwand, nicht das Datenvolumen.

“ML-Empfehlungen können wir nicht erklären.”
Das ist ein legitimes Problem — und lösbar. Gradient-Boosting-Modelle liefern Feature-Importance-Werte: Das System kann für jede Empfehlung ausgeben, welche Faktoren den Ausschlag gegeben haben. “Empfehle Lageraufstockung: C-Check in Woche 8 (Beitrag 52 %), erhöhte Ausfallrate in letzten 90 Tagen (Beitrag 31 %), saisonales Muster (Beitrag 17 %).” Diese Erklärbarkeit ist nicht nur für Planer wichtig — sie ist auch für EU AI Act-Compliance relevant, da High-Risk-KI-Systeme nachvollziehbare Entscheidungslogik brauchen.

“Was passiert, wenn das Modell falsch liegt — und wir haben kein Teil?”
Das Modell ist ein Planungswerkzeug, kein Versicherungsprodukt. Die Entscheidung, einem Modell zu folgen, trifft der Planer. Was sich ändert: Das Modell gibt eine begründete Risikoabschätzung, und der Planer kann entscheiden, ob er ihr folgt oder einen anderen Safety-Stock-Puffer setzt. Die Alternative — kein Modell, dafür Bauchgefühl und Excel — hat schlechtere Trefferraten, wie die Datenlage zeigt. Ein Modell mit 85 % Genauigkeit ist besser als keines mit 61 %.

Woran du merkst, dass das zu dir passt

• Deine Flotte umfasst mindestens 30–50 Flugzeuge — erst ab dieser Größe entstehen genug Verbrauchsereignisse pro Teilnummer für belastbare ML-Prognosen
• Ihr habt ein CMMS, das Teileaustausche mit Timestamp, Teilenummer und MSN-Zuordnung dokumentiert — und das seit mindestens 3 Jahren läuft
• Ihr erlebt regelmäßig AOG-Situationen, die auf fehlende oder nicht beschaffte Teile zurückzuführen sind — mindestens 3–5 pro Jahr ist ein Signal, dass Prognose und Beschaffung nicht synchron laufen
• Dein Lagerbestand wächst, obwohl die Flottengröße stabil bleibt — ein Zeichen für Überbevorratung durch übervorsichtige Planungslogik
• Ihr habt C-Check und D-Check-Termine in einem planbaren Horizont von 6–12 Monaten — diese Daten können sofort als Modell-Feature genutzt werden und sind der wichtigste Einzelhebel für Prognosegenauigkeit

Wann dieses Projekt noch nicht das richtige ist — drei harte Ausschlusskriterien:

1. Unter 30 Flugzeugen in der zu prognostizierenden Flotte. Bei kleinen Flotten entstehen für die meisten Rotable-Teilenummern einfach nicht genug Verbrauchsereignisse für ML-Training. Croston mit gut kalibrierten Safety-Stock-Buffern und regelmäßiger manueller Revision ist dann tatsächlich die bessere Wahl — günstiger, transparenter und schwerer falsch zu kalibrieren.

2. Keine digitalisierte Wartungshistorie mit mindestens 3 Jahren Dichte. Wenn das CMMS erst kürzlich eingeführt wurde, historische Daten hauptsächlich auf Papier oder in Excel liegen, oder Teilenummern nicht konsistent erfasst wurden, fehlt die Trainingsgrundlage. ML setzt hier früher an als tatsächlich nötig — der bessere erste Schritt wäre, das CMMS sauber aufzubauen und 2–3 Jahre Daten zu sammeln.

3. Kein Zugriff auf Flugplanungsdaten oder Check-Kalenderdaten in maschinenlesbarer Form. Ohne diese Kontextvariablen baut man ein Modell, das nur auf Vergangenheitsverbrauch schaut. Das ist besser als nichts, aber der größte Mehrwert — Antizipation von Check-bedingtem Bedarf — entfällt komplett. In diesem Fall würden die Projektkosten nicht den vollen ROI rechtfertigen.

Das kannst du heute noch tun

Bevor irgendein Tool evaluiert oder Budget beantragt wird: Mach die Daten-Inventur. Lade aus deinem CMMS alle Teileaustausche der letzten 36 Monate herunter — Teilenummer, MSN, Datum, Menge — und öffne die Datei. Zähle, wie viele Teilenummern in diesem Zeitraum weniger als 10 Verbrauchsereignisse haben. Das ist dein “Croston-Rest” — ML wird dort nicht viel bringen. Zähle dann, wie viele Teilenummern 20+ Ereignisse haben und im dreistelligen Euro-Bereich oder höher liegen. Das ist dein ML-Scope.

Diese Übung dauert 2–3 Stunden und gibt dir mehr Klarheit über das Potenzial als jede Vendor-Präsentation.

Für die technische Machbarkeitsstudie kannst du mit dem folgenden Prompt starten, der eine erste Einschätzung deiner Datenlage strukturiert:

Quellen & Methodik

• ScienceDirect (2026): “Intermittent demand forecasting of aerospace rotable parts. A framework for unpredictable flight patterns.” Framework mit historischen Verbrauchsdaten eines europäischen MRO-Servicecenters — 99,2 % SKU-Genauigkeit gegenüber klassischen Baselines.
• oxmaint.com, “AI-Powered Spare Parts Demand Forecasting for Aviation MRO” (2026): Überschussbestand 22–30 %, $8–15 Mio. stranded capital bei 100-Flugzeug-Betrieb; Forecast-Genauigkeit 94 % (ML) vs. 61 % (Moving Average).
• Qatar Airways (berichtet via MarketsandMarkets/oxmaint, 2023): $38,5 Mio. Jahreseinsparungen aus AI-basierter MRO-Optimierung; 310 % ROI in 18 Monaten.
• easyJet (Branchenberichte 2025): 1.343 vermiedene Flugstreichungen und 171 vermiedene Verspätungen 2019–2025 durch Predictive-Maintenance-KI.
• Syntetos, Boylan & Croston (IEEE, 2012): “A Review of Croston’s method for intermittent demand forecasting.” Dokumentiert Schwächen bei erratischem (nicht nur sporadischem) Bedarf.
• Bregant et al. (Aerospace, 2023): “Forecasting Aviation Spare Parts Demand Using Croston Based Methods and Artificial Neural Networks.” ANN übertrifft Croston-Methoden bei sporadischem Luftfahrtbedarf — akademisches Rückendeckung für ML-Ansatz.
• innoverdigital.com (2024): Modell-Genauigkeitsverlust von 14–19 % über 18 Monate ohne Retraining; Retraining reduziert diesen Verlust auf ~2,4 %.
• Lokalpreise und Implementierungsaufwände: Erfahrungswerte aus MRO-Projekten (Stand Mai 2026). Lizenzkosten AMOS, Ramco, SAP IBP, ePlane.ai: veröffentlichte Tarife und Branchenberichte (Stand Mai 2026).

Du willst einschätzen, ob eure Datenlage für ML-Bedarfsprognose ausreicht — und was der erste konkrete Schritt wäre? Meld dich — das klären wir in einem kurzen Gespräch, ohne Vendor-Demos und ohne Verkaufsgespräch.