Maschinenbauer unterschätzen ihre eigene KI-Position systematisch. Sie vergleichen sich mit Softwarefirmen und sehen ein Defizit: weniger Data Scientists, ältere IT, konservative Kunden. Was sie übersehen, ist das Asset, das Softwarefirmen nicht nachbauen können: Jahrzehnte proprietärer Daten von den eigenen Maschinen im Feld, und das Engineering-Wissen, sie zu deuten. Niemand sonst weiß, wie sich eine gesunde Spindel auf Ihren Maschinen anhört, welche Fehlercodes welchen Ausfällen vorausgehen oder was Toleranzdrift für Ihren Prozess bedeutet. Für einen Hidden Champion heißt KI nicht, das Silicon Valley einzuholen, sondern einen Vorteil zu monetarisieren, der bereits existiert. Das ist das Playbook.
Die fünf Use Cases, nach realistischem Payback geordnet
Für Maschinenbauer kommt Payback in zwei Währungen: interne Einsparung und neuer Service-Umsatz. Das Ranking unten gewichtet beides, als Planungsannahmen für einen typischen mittelständischen OEM mit Maschinen im Feld und laufendem Servicegeschäft.
| Rang | Use Case | Typischer Payback-Horizont | Woher das Geld kommt |
|---|---|---|---|
| 1 | Predictive Maintenance als Serviceprodukt | 12-18 Monate (dann wiederkehrender Umsatz) | Zustandsbasierte Serviceverträge, weniger Notfalleinsätze, verkaufte Maschinenverfügbarkeit |
| 2 | Qualitätsprüfung (Vision, inline) | 6-12 Monate | Weniger Ausschuss und Nacharbeit, weniger durchgerutschte Fehler, weniger manuelle Prüfung |
| 3 | Engineering-Dokumenten-Intelligenz | 6-12 Monate | Schnellere Angebote und Konstruktions-Wiederverwendung; Servicehandbücher, Normen und Altprojekte werden durchsuchbares Wissen |
| 4 | Aftermarket- & Ersatzteil-Optimierung | 9-18 Monate | Höhere Teileverfügbarkeit bei weniger gebundenem Kapital, weniger veraltete Teile |
| 5 | Prozessparameter-Optimierung an Maschinen | 12-24 Monate | Energie, Taktzeit und Werkzeugstandzeit, oft als Feature an Kunden zurückverkauft |
Der Vorteil der proprietären Maschinendaten, und seine Reife-Realität
Das strategische Asset ist echt, aber es kommt selten analysebereit daher. Flottentelemetrie existiert, liegt aber in Silos je Kunde mit unklaren vertraglichen Nutzungsrechten; die Ausfallhistorie lebt als Freitext in den Berichten der Servicetechniker; die wahren Labels, was tatsächlich kaputtging, wann, und was es behoben hat, verteilen sich auf ERP, Ticketsysteme und Gedächtnis. Der Datenvorteil wird durch das Verbinden verdient, nicht durch den Besitz von Sensoren.
| Datendomäne | Typische Realität | Mindestmaßnahme vor KI |
|---|---|---|
| Maschinentelemetrie (Feldflotte) | Gesammelt, aber je Kunde siloisiert; Nutzungsrechte oft unklar | Datennutzungsklauseln in Serviceverträgen klären; Signale je Maschinentyp vereinheitlichen |
| Ausfall- & Servicehistorie | Freitext-Technikerberichte, uneinheitliche Kodierung | Strukturierte Ausfall-Taxonomie; Labeling am Pilot-Maschinentyp beginnen |
| Qualitätsdaten (Produktion) | Messungen vorhanden, selten mit Prozessparametern verknüpft | Prüfergebnisse je Teil/Charge mit Maschineneinstellungen verbinden |
| Engineering-Dokumente (CAD, Handbücher, Normen) | Vollständig, aber über Jahrzehnte von Formaten unauffindbar | Zentraler Dokumentenindex mit Extraktion für die Pilot-Produktlinie |
| Ersatzteil-Bedarfshistorie | Im ERP, verzerrt durch Fehlmengen und Sammelbestellungen | Saubere Bedarfsreihen je Teil; echten Bedarf von Bestell-Artefakten trennen |
Das Scheitermuster: der Sensor-Friedhof
Das typische Scheitern im Maschinenbau ist Sammeln zuerst, Denken später. Ein Retrofit-Projekt hängt Sensoren an alles, ein Dashboard zeigt Kurven, auf die niemand reagiert, und nach drei Jahren gibt es Terabytes ungelabelter Schwingungsdaten und keinen einzigen verhinderten Stillstand. Die fehlende Zutat waren nie mehr Daten, es waren Ausfall-Labels, eine Entscheidung, die die Daten auslösen sollen, und eine Serviceorganisation, die auf Prognosen reagieren kann.
| Symptom | Ursache | Gegenmaßnahme |
|---|---|---|
| Terabytes an Telemetrie, null verhinderte Ausfälle | Keine Labels, keine Zielentscheidung definiert | Von einem Ausfallmodus starten, der Kunden wehtut; Labels gezielt sammeln |
| Dashboard existiert, der Service fährt weiter reaktiv | Prognose nicht in Einsatzplanung und Verträge verdrahtet | Service-Workflow und Vertragsmodell mit dem Modell entwerfen, nicht danach |
| Pilot auf einem Maschinentyp, kein Weg zur Flotte | Jeder Maschinentyp anders instrumentiert | Signalbenennung und Datenverträge für neue Maschinen jetzt standardisieren |
| Kunden verweigern die Datenweitergabe | Werteverteilung nie explizit gemacht | Etwas zurückgeben: Verfügbarkeitszusagen, Reports, bessere Servicekonditionen |
Das Team: kaufen, leihen oder ausbilden
Auch hier starten Maschinenbauer mit einem versteckten Vorteil: Die Domänenexperten existieren bereits, Anwendungsingenieure, Servicetechniker, Qualitätsingenieure. Was fehlt, ist ein kleiner ML- und Datenkern, der ihr Wissen ernst nimmt. Condition-Monitoring-Spezialist:innen sind knapp; Engineers, die Ihre Maschinen lernen können, nicht, stellen Sie nach Nachweisen auf Industriedaten ein, nicht nach Branchen-Buzzwords.
| Rolle | Kaufen / leihen / ausbilden | Warum |
|---|---|---|
| Senior ML Engineer (Zeitreihen/Condition Monitoring) | Kaufen, oder erst leihen, dann kaufen | Der dauerhafte Kern; muss neben der Maschine stehen wollen, nicht nur neben dem Notebook |
| Data Engineer (OT-/IT-Integration) | Kaufen | SPS-zu-Cloud-Pipelines und das Flotten-Datenmodell sind dauerhafte Infrastruktur |
| Domänen-Lead (Anwendungs-/Servicetechnik) | Ausbilden (intern) | Ausfallmodus-Wissen und Kundenvertrauen lassen sich nicht extern einkaufen |
| Computer-Vision-Engineer (Qualitätsprüfung) | Leihen | Abgegrenzter Aufbau je Prüfstation; der Betrieb geht ans interne Team über |
| Service-Produktmanager:in (Verträge, Pricing) | Ausbilden, mit externem Sparring | Aus Prognosen verkaufbare Serviceprodukte zu machen ist ein kommerzielles Handwerk |
Pragmatische erste 90 Tage
Das erste Quartal sollte nicht versuchen, das Predictive-Maintenance-Produkt zu bauen. Es sollte an einem Maschinentyp und einem Ausfallmodus beweisen, dass Ihre Daten Ausfälle kommen sehen, und das Labeling und die Datenanbindung aufsetzen, die das Produkt brauchen wird. Qualitätsprüfung oder Dokumenten-Intelligenz können als schneller Parallelgewinn laufen, wenn die Kapazität es erlaubt, nicht stattdessen.
| Phase | Wochen | Was passiert |
|---|---|---|
| Zuschnitt & Baseline | 1-2 | Einen Maschinentyp und einen teuren Ausfallmodus wählen; Baseline messen (Ausfallhäufigkeit, Stillstandsstunden, Kosten der Notfalleinsätze); Datennutzungsrechte prüfen |
| Datenfundament | 3-6 | Telemetrie für die Pilotflotte vereinheitlicht; Ausfall-Labels gemeinsam mit den Technikern aus der Servicehistorie rekonstruiert; Ausfall-Taxonomie vereinbart |
| Machbarkeits-Modell | 7-10 | Erstes Anomalie-/Prognosemodell im Backtest gegen bekannte Ausfälle; ehrliche Bewertung von Vorwarnzeit und Fehlalarmquote |
| Pilot & Produktskizze | 11-13 | Schattenmodus-Alarme ans Serviceteam auf Live-Daten; Entwurf des Serviceprodukt-Konzepts (Vertrag, Pricing, Workflow); Entscheidungsvorlage: skalieren, nachbessern oder stoppen |