Im Werk eines ATX-Industriebetriebs in Oberösterreich hängt seit März 2025 ein Bildschirm in der Leitwarte, der nicht aussieht wie etwas Besonderes: zwölf Balken, ein Ampel-System, ein paar Live-Charts. Was nicht zu sehen ist: dahinter laufen 13 ML-Modelle, 412 Sensoren, eine SAP-PM-Integration, und ein Team, das in 14 Monaten gelernt hat, ML- Modelle nicht einmal zu bauen, sondern dauerhaft zu betreiben. Dieser Fall ist anonymisiert, aber zahlenmäßig real.
1. Ausgangslage — €40k pro Stillstand-Stunde, aber kein Live-Bild
Der Betrieb produziert Maschinenkomponenten in Serie, drei Schichten, 24/5-Betrieb. Zwölf Produktionslinien, jede mit zwischen 15 und 60 einzelnen Aggregaten (Spindeln, Pressen, Förderbänder, Wärme- behandlungs-Öfen). Vor dem Projekt war Wartung klassisch zeitbasiert geplant — alle X Betriebsstunden ein Service-Eingriff, unabhängig vom tatsächlichen Zustand.
Die Schmerzpunkte aus den ersten zwei Workshop-Tagen:
- Ungeplante Ausfälle 2023: 187 Stunden im Jahr, im Schnitt €58.000/h Wertschöpfungsverlust — also rund €10,8 Mio. an vermeidbarem Schaden.
- Geplante Wartungen waren häufig unnötig: Stichproben zeigten, dass 30 bis 40 Prozent der ausgetauschten Komponenten noch 6 bis 12 Monate Restlebensdauer gehabt hätten.
- Reklamation des Produktionsleiters wörtlich: "Ich weiß nicht, wo meine Maschinen wirklich stehen." Die Daten kamen verzögert über Schicht-Protokolle, nicht in Echtzeit.
Es gab schon Sensorik — Vibration, Temperatur, Stromaufnahme — auf etwa 60 Prozent der kritischen Aggregate. Aber die Daten lagen in einem SCADA-System, das niemand außer einem Spezialisten lesen konnte, und flossen nicht in irgendeine Entscheidungs-Logik ein.
2. Audit-Ergebnis — der Use Case ist hochrisiko-relevant, aber machbar
Das Audit L dauerte sechs Wochen. Drei zentrale Erkenntnisse:
Erstens: Datenlage ist tragfähig, aber unstrukturiert. Es gab zwei Jahre historische Sensor-Daten plus drei Jahre Wartungs- Protokolle in SAP PM. Mit Aufwand verknüpfbar — aber nicht trivial.
Zweitens: Klassifizierung nach EU AI Act. Predictive Maintenance in kritischer Infrastruktur kann hochrisiko-relevant sein. Wir haben mit der Rechtsabteilung geprüft: in diesem Fall fiel der Use Case auf "Begrenztes Risiko" — die Maschinen sind keine kritische Infrastruktur im Sinne des Anhangs III, die Empfehlungen werden nicht autonom umgesetzt, sondern von einem menschlichen Instandhalter freigegeben.
Drittens: ein einziges Modell wird nicht funktionieren. Diese Erkenntnis war die wichtigste. Die zwölf Produktionslinien sind sich ähnlich, aber nicht gleich — unterschiedliche Aggregate, unterschiedliche Materialien, unterschiedliche Lastzyklen. Ein "One-Size-Fits-All"- Modell hätte auf den Top-Linien ordentlich performt, auf den Spezialitäten-Linien aber gefährlich danebengelegen.
ein XGBoost-Modell pro Linie plus ein globales Anomalie-Detection-Modell — wichtig: nicht alles auf einem Modell, sonst tarnt das System echte Probleme als Ausreißer einer Durchschnitts-Linie
3. Architektur — Sensor-Pipeline, Modell-Familie, SAP-PM-Handover
Die Architektur in vier Bausteinen:
Sensor-Pipeline. Bestehendes SCADA wurde nicht abgelöst, sondern ergänzt. Die Sensor-Daten fließen weiterhin ins SCADA, parallel schreibt ein Edge-Gateway pro Linie die relevanten Messpunkte (Vibration, Temperatur, Stromaufnahme, Drehmoment, Schmierdruck) in eine Time- Series-DB. Sampling: 100 ms für kritische Messpunkte, 1 s für weniger kritische.
Feature-Engineering. Aus den Rohwerten werden alle 30 Sekunden Features berechnet — gleitende Mittelwerte, FFT-basierte Frequenz- Features, Trend-Indikatoren. Das ist die Schicht, die in praktisch jedem Predictive-Maintenance-Projekt unterschätzt wird: ohne saubere Features ist auch das beste Modell blind.
Modell-Familie. Ein XGBoost-Klassifikator pro Linie, trainiert auf den historischen Ausfall-Labels, plus ein globales Anomalie- Modell (Isolation Forest), das ungewöhnliche Muster identifiziert, die noch nie in den Trainingsdaten waren. Wichtig: die globalen Anomalien werden als "Frühwarnung" markiert, nicht als Vorhersage — sie triggern eine menschliche Sichtprüfung, keine automatische Wartungs-Order.
SAP-PM-Integration. Wenn ein Modell eine Wartungsempfehlung ausspricht, wird automatisch eine SAP-PM-Meldung erzeugt — mit Prognose-Begründung, Restlebensdauer-Schätzung und Konfidenz-Wert. Der Instandhaltungs-Planer entscheidet final, ob und wann er den Eingriff einplant. Diese menschliche Schleife war Voraussetzung für die Akzeptanz im Werk.
4. Implementation — vier Monate, drei Phasen
Nach dem Audit lief das Projekt als Enterprise-Build:
Monat 1: Daten-Backbone. Edge-Gateways an allen 12 Linien installiert, Time-Series-DB aufgebaut, historische Daten aus SCADA und SAP migriert. Hier sind wir zwei Wochen über Plan gelaufen, weil das Mapping zwischen SAP-PM-Komponenten und Sensor-IDs in 60 Prozent der Fälle händisch geklärt werden musste. Lektion: bei Industriedaten immer zwei Wochen Puffer einplanen.
Monate 2–3: Modell-Entwicklung. Pro Linie ein eigenes Modell, trainiert auf 24 Monaten historischer Daten. Cross-Validation, Feature-Selection, Hyperparameter-Tuning. Außerdem das globale Anomalie-Modell. Parallel dazu: SAP-PM-Schnittstelle gebaut und getestet.
Monat 4: Pilot, Rollout, Schulung. Drei Wochen Shadow-Mode auf zwei Pilot-Linien — Modelle generieren Empfehlungen, aber die werden nur intern verglichen, nicht umgesetzt. False-Positive-Rate in Woche 1: 18 Prozent. Nach zwei Wochen Re-Training mit Feedback: 9 Prozent. Akzeptabel für den Start.
Go-Live mit allen 12 Linien März 2025. Parallel dazu: Schulung der Instandhalter — zwei halbe Tage pro Person, plus laufendes Coaching durch unseren MLOps-Lead in den ersten acht Wochen.
5. ROI nach 12 Monaten
Stand März 2026, ein Jahr nach Go-Live:
- Ungeplante Ausfälle: 187 h/Jahr → 108 h/Jahr, also −42 Prozent. Wertschöpfungsgewinn rechnerisch rund €4,6 Mio.
- Wartungskosten: −18 Prozent. Weniger unnötig getauschte Komponenten, klügeres Ersatzteil-Management.
- OEE (Overall Equipment Effectiveness): von 71 auf 77 Prozent.
- Investment: €280.000 (Audit L + Enterprise-Build), €34.000/Jahr laufende Kosten (Modell-Betrieb, Re-Training, Edge-Hardware).
- Amortisation: rund 14 Monate.
Wichtig: Diese Zahlen sind Werks-intern verifiziert und in der internen Wirtschaftlichkeitsrechnung verbucht. Sie sind nicht "Marketing-ROI", sondern aus den SAP-PM- und MES-Daten rekonstruiert. Der Vorstand hat das Projekt 2026 als Referenz für zwei weitere Standorte freigegeben.
6. Was die Stunde-1-Lessons waren
Erstens: Datenqualität ist 70 Prozent der Arbeit. Wir haben mehr Zeit in Datenkuration und Sensor-Mapping investiert als in Modell-Training. Das ist normal und richtig. Wer hier abkürzt, zahlt es später drei Mal.
Zweitens: Modelle haben ein Verfallsdatum. Die XGBoost-Modelle werden alle drei Monate re-trainiert, weil sich Produktionsmix, Materialchargen und Wartungs-Patterns verändern. Ohne MLOps- Pipeline ist Predictive Maintenance ein Einmal-Effekt, der nach sechs Monaten verschwindet.
Drittens: Die Instandhalter sind der eigentliche Erfolgsfaktor. Ohne ihre fachliche Akzeptanz wird das System nicht genutzt. Wir haben in den ersten acht Wochen wöchentliche Feedback-Runden mit den Schicht-Instandhaltern gemacht, ihre Anmerkungen direkt in die Modelle eingespielt. Heute sehen sie sich nicht als "Daten- lieferanten", sondern als Co-Trainer.
Viertens: Sensor-Ausfälle sind real. In den ersten 12 Monaten Vollbetrieb sind insgesamt 14 Sensoren ausgefallen oder defekt geworden. Wir haben eine Sensor-Health-Überwachung dazugebaut, die fehlende oder fehlerhafte Daten erkennt und das Modell auf "vorsichtigen Modus" umschaltet, bis Ersatz da ist.
7. Was das für andere ATX- und Industrie-Setups bedeutet
Aus diesem und zwei weiteren Industrie-Projekten 2024/26 in Österreich und Süddeutschland ergibt sich ein konsistentes Bild:
- Predictive Maintenance rechnet sich ab einem Ausfall-Schaden von rund €15.000 pro Stunde aufwärts und einer Anlagenzahl, die einen Pipeline-Build rechtfertigt (Daumenregel: ab 5 vergleichbaren Linien).
- Reduktion ungeplanter Ausfälle in der Größenordnung 30 bis 50 Prozent ist realistisch, alles darüber ist meist Marketing.
- Die größten Kostenpunkte sind Daten-Engineering und MLOps-Betrieb, nicht das Modell selbst.
- Amortisation in 12 bis 18 Monaten ist machbar — wer mit "ROI in drei Monaten" pitcht, lügt.
Häufige Fragen
Was Produktions- und Werks-Leiter zu Predictive Maintenance fragen.
Wie lange müssen Daten gesammelt werden, bevor sinnvolles Modell-Training möglich ist?
Was ist mit False-Positives passiert — und wie hat das Werk reagiert?
Wer betreibt das Modell nach Go-Live? Bleibt der externe Partner?
Wie integriert sich das System mit SAP PM technisch?
Was passiert, wenn ein Sensor ausfällt — kollabiert dann das Modell?
Was als Nächstes?
Wenn du einen Industriebetrieb mit signifikanten Ausfall-Kosten führst und Predictive Maintenance als Option auf dem Tisch hast — der saubere Einstieg ist ein Audit L mit Daten-Reifegrad-Bewertung und ROI-Schätzung. Sechs Wochen, klare Architektur-Empfehlung, ehrliche Aussage, ob das Setup heute trägt oder ob erst die Sensorik nachgezogen werden muss. Discovery-Call dauert 30 Minuten und kostet nichts.