Maschinenbauer reduziert Stillstand um 42 % — durch KI-Wartung und Wissens-RAG

Ausgangslage

Der Mandant ist ein in dritter Generation geführter Sondermaschinenbauer im Bergischen Land. Das Kerngeschäft ist die Entwicklung und der Bau hochpräziser Antriebs- und Förderkomponenten für die Verpackungs- und Lebensmittelindustrie. Das Unternehmen baut pro Jahr rund 35 Sondermaschinen und betreut die installierte Basis von etwa 480 Anlagen weltweit. Der Service ist ein wesentlicher Profit-Center und macht etwa 28 % des Konzernumsatzes aus.

Im Service standen die Verantwortlichen Anfang 2025 vor zwei deutlich spürbaren Problemen. Erstens: Ungeplante Stillstände bei wichtigen A-Kunden führten zu Pönalen und gefährdeten Folgegeschäft. In den 12 Monaten vor Projektstart hatten 7 % der installierten Anlagen mindestens einen ungeplanten Stillstand von mehr als 24 Stunden — bei einigen A-Kunden bedeutete das Lieferausfälle in deren Produktion. Zweitens: Servicetechniker — überwiegend langjährige Mitarbeiter mit jeweils 12–28 Jahren Erfahrung — verbrachten im Schnitt 2,5 Stunden pro Service-Einsatz mit der Suche nach historischen Fehlerbehandlungen, Schaltplänen, Hersteller-Spezifikationen und früheren Reparaturberichten. Diese Suche fand teils im Auto, teils beim Kunden, teils erst nach Rückkehr in die Werkstatt statt.

Beide Probleme hingen miteinander zusammen: Wenn ein Servicetechniker beim ersten Einsatz nicht alle relevanten Informationen hatte, kam es zu einem zweiten Anfahrtsbesuch — und währenddessen stand die Maschine. Die Ersteinsatz-Erfolgsrate lag im Service-Cockpit bei 71 %.

Ziele & Erfolgsmetriken

Im Kick-off-Workshop haben wir vier KPIs als verbindlich definiert. Diese KPIs waren die Grundlage für die Pilot-Akzeptanz nach 8 Wochen und für die spätere Roll-out-Entscheidung.

• Reduktion ungeplanter Stillstandzeit um mindestens 25 % auf den Pilot-Maschinen (≥30 Anlagen) innerhalb von 6 Monaten Live-Betrieb.
• Steigerung der Ersteinsatz-Erfolgsrate um mindestens 15 Prozentpunkte (von 71 % auf ≥86 %).
• Reduktion der Suchzeit pro Service-Einsatz um mindestens 50 % (von 2,5 h auf ≤1,25 h).
• Akzeptanzquote im Service-Team ≥75 % („Würde ich weiterempfehlen“) nach 90 Tagen Live-Betrieb.

Die Lösung im Überblick

Wir haben gemeinsam mit dem Service-Leiter und einer Pilotgruppe von vier Servicetechnikern ein zweistufiges System entworfen, das die beiden Schmerzpunkte (ungeplante Stillstände, Wissenssuche) parallel adressiert. Diese Trennung in zwei eigenständige, aber datenseitig verbundene Komponenten war eine bewusste Entscheidung — sie erlaubt es, jede Komponente unabhängig zu pflegen und auch unabhängig zu deaktivieren, falls eine davon Probleme macht.

Komponente 1: Predictive Maintenance (klassisches ML)

Auf Basis von Sensordaten (Lager-Temperatur, Vibrations-Frequenzspektrum, Stromaufnahme, Zyklenzahl) wird die Wahrscheinlichkeit eines Lager-Ausfalls in den nächsten 7, 14 und 30 Tagen berechnet. Modell-Architektur ist ein Gradient-Boosting-Ensemble (LightGBM) mit zusätzlichen Frequenzraum-Features. Wir haben bewusst kein Deep-Learning-Modell gewählt, weil die Datenmenge das nicht hergegeben hätte und weil Erklärbarkeit für die Service-Disposition wichtig war.

Ergebnis-Reife heute: 84 % Recall bei 91 % Precision für Vorlaufzeiten ≥ 7 Tage. Bei kürzeren Vorlaufzeiten sinken beide Werte deutlich, weshalb das System bewusst nur Warnungen mit ≥7 Tagen Vorlauf an die Disposition meldet. Falsche Alarme würden Vertrauen zerstören.

Komponente 2: Wissens-RAG (LLM-basiert)

Wenn ein Servicetechniker einen Einsatz vorbereitet (oder vor Ort eine Frage hat), kann er das System per Smartphone, Tablet oder Desktop befragen. Beispielfragen aus dem Live-Betrieb:

• „Antriebsbaugruppe XY läuft heiß bei 4.200 U/min — wer hatte das schon?“
• „Welche Schmierstoffe sind für Lager-Typ ABC in Lebensmittelumgebung freigegeben?“
• „Anlage 0814 — was waren die letzten drei Service-Einsätze?“

Das System recherchiert in 11.400 historischen Service-Berichten (1998–2026), 380 Hersteller-Handbüchern, 1.200 internen Schulungsunterlagen und im Anlagen-Stammdatensystem. Antwort kommt mit Quellenangabe (Berichts-Nr., Datum, Komponente, Abschnitt) und konkretem Lösungsvorschlag, der explizit als „Vorschlag — Servicetechniker entscheidet“ gelabelt ist.

Architektur (vereinfacht)

Wir teilen die Architektur in vier Schichten:

1. Datenerfassung: OPC-UA-Anbindung an die SPS der überwachten Maschinen via lokalem IoT-Gateway (Hailo Embedded Linux). Sensordaten werden anonymisiert (kein Kundenname, kein Standort) in Echtzeit an einen Hetzner-Server in Nürnberg gestreamt.
2. ML-Schicht: Predictive-Maintenance-Modell läuft auf Hetzner-CPU-Server, alle 60 Sekunden Inferenz, Speicherung der Anomalie-Scores in einer TimescaleDB-Instanz.
3. Wissens-Schicht: Vektor-DB (pgvector auf PostgreSQL) mit ca. 1,9 Millionen Embedding-Chunks. RAG-Pipeline mit hybridem Retrieval (BM25 + Vektor) und Re-Ranking via Cohere Rerank Multilingual.
4. LLM-Schicht: Antwortgenerierung primär über Mistral Large via La Plateforme (EU-Hosting), fallback auf selbst gehostetes Llama 3.1 70B auf Hetzner GPU-Server (für sensible Anfragen oder bei Mistral-Ausfall).

Das gesamte System ist über zwei Web-Interfaces zugänglich: ein Servicetechniker-Frontend (Mobile-First, PWA) und ein Disponenten-Cockpit (Desktop, Übersicht aller Anlagen mit Risiko-Heatmap). Beide kommunizieren mit dem Backend über eine REST-API mit Zertifikats-basierter Authentifizierung.

Vorgehen & Zeitplan

Im Pilot haben wir bewusst zuerst die Wissens-RAG-Komponente gebaut, obwohl die Predictive-Maintenance-Komponente das wirtschaftlich größere Potenzial hatte. Der Grund: RAG-Erfolg lässt sich schneller demonstrieren und schafft Akzeptanz im Service-Team — und dieses Team ist später der zentrale Datenlieferant für die Verbesserung des ML-Modells (jeder Einsatz produziert neue Service-Berichte mit Labels).

Ergebnisse nach 12 Monaten Live-Betrieb

Im Detail: Die ungeplante Stillstandzeit auf den 84 überwachten Maschinen ist von durchschnittlich 4,2 % der Verfügbarkeitszeit auf 2,4 % gefallen. Die Ersteinsatz-Erfolgsrate ist von 71 % auf 91 % gestiegen — das bedeutet, dass von 100 Service-Einsätzen heute 91 ohne zweiten Anfahrtsbesuch abgeschlossen werden. Die durchschnittliche Suchzeit pro Einsatz ist von 2,5 Stunden auf 38 Minuten gefallen.

Die wirtschaftliche Bewertung — gemeinsam mit dem CFO des Mandanten erstellt — kommt für Jahr 1 auf 1,2 M € messbare Einsparung. Diese teilt sich auf in 720.000 € reduzierte Pönale-Kosten, 280.000 € eingesparte Servicetechniker-Zeit (umgerechnet auf 22 Personen) und 200.000 € reduzierte Reise- und Übernachtungskosten durch weniger Zweiteinsätze. Nicht miteingerechnet, aber qualitativ klar positiv: gestiegene Kundenzufriedenheit (NPS bei A-Kunden +12 Punkte) und bessere Recruiting-Position (im Service-Bewerbungsgespräch wird das System aktiv erwähnt).

„Wir hatten den Bericht eigentlich schon abgeschrieben. Wartungstechniker wussten, dass es 2019 mal etwas Ähnliches gab — niemand wusste mehr, in welchem Bericht. 30 Sekunden nach der Frage hatte das System ihn gefunden, samt der Reparaturlösung. So etwas verändert die Arbeit grundlegend.“
— Werkstattleiter, Mai 2026

Wirtschaftlichkeit im Detail

Investition (alle Beträge netto):

• Pilot 39.900 € (8 Wochen, erweiterter Pilot mit ML- und RAG-Komponente)
• Implementation 184.000 € (16 Wochen, vollständige Systemausführung)
• Managed Service 7.900 €/Monat (Premium-Stufe)
• LLM- und Hosting-Lizenzen ca. 1.700 €/Monat
• Hardware (IoT-Gateways, lokale Edge-Server) 28.000 € einmalig
• Interne Aufwände (Service-Leiter 30 % Zeit, 4 Pilot-Techniker je 10 %, IT-Owner 20 %) ca. 110.000 € im ersten Jahr

Total Cost of Ownership Jahr 1: rund 425.000 € (extern + intern). Realisierte Einsparung Jahr 1: 1,2 M €. Net Benefit Jahr 1: 775.000 €. ROI Jahr 1: 182 %. Vollständige Methodik in unserem ROI-Leitfaden.

Stolpersteine — was wir nicht erwartet hatten

Drei Punkte haben uns überrascht und uns Mehraufwand gekostet, den wir hier offen benennen, weil sie typisch für vergleichbare Projekte sind.

1. OCR-Qualität bei Service-Berichten 1998–2010: Wir hatten mit 80 % brauchbarer OCR-Qualität gerechnet, real waren es 58 %. Der Grund: viele Berichte waren Faxausdrucke oder schlecht eingescannte Kopien. Wir haben einen zweistufigen Prozess gebaut: schnelle OCR mit Tesseract, danach manuelle Nacharbeit auf 1.200 Berichte mit hoher Suchrelevanz (von uns identifiziert über Anlage-Nutzungsfrequenz).
2. Falsch-Positiv-Toleranz im ML-Modell: Im Pilot war das Modell auf 78 % Recall / 82 % Precision eingestellt. Nach drei Wochen Live-Betrieb meldete sich der Service-Leiter: „Das System schreit zu oft, niemand hört mehr hin.“ Wir haben den Confidence-Threshold deutlich angehoben (jetzt 91 % Precision), den Recall bewusst etwas reduziert. Lernung: Im Service ist Precision (keine falschen Alarme) wichtiger als Recall (alle Vorhersagen treffen).
3. Akzeptanz älterer Servicetechniker: Drei der erfahrensten Techniker (jeweils >25 Jahre Erfahrung) haben das System anfangs konsequent ignoriert. Nicht aus Skepsis gegen KI, sondern weil sie ihren eigenen mentalen Wissensspeicher schneller fanden als das System. Die Wende kam, als einer von ihnen einem jüngeren Kollegen die Antwort nicht aus dem Kopf geben konnte und das System spontan ausprobierte. Heute nutzen alle drei das System aktiv. Lernung: Akzeptanz erzwingt man nicht, man wartet darauf.

Was wir daraus gelernt haben

• Erst Wissens-RAG, dann Predictive Maintenance. Der RAG-Erfolg schafft Akzeptanz im Team — und dieses Team liefert die Daten, die das ML-Modell langfristig besser machen. Umgekehrt geht selten gut: Ein ML-Modell ohne Akzeptanz im Team verfällt.
• Quellenangaben sind nicht verhandelbar. Jede Antwort braucht Quelle und Kontext. Sonst sinkt das Vertrauen schneller, als man denkt.
• Mobile-First ist kein Bonus, sondern Pflicht. Servicetechniker arbeiten am Smartphone — der Desktop-Auftritt war im Live-Betrieb fast irrelevant.
• OCR-Aufwand realistisch ansetzen. Bei historischen Bestände mit gemischten Quellen mindestens 30 % Puffer einplanen.
• Hosting-Hoheit als Vertriebsargument. Der Mandant nutzt heute aktiv das Argument „unser KI-System steht in Deutschland“ gegenüber A-Kunden. Was zunächst eine Compliance-Maßnahme war, ist zum Verkaufsargument geworden.

Wenn Sie einen vergleichbaren Use Case erwägen — Service-Wissen, Predictive Maintenance, Maschinendatenanalyse — ist der einfachste nächste Schritt ein kostenfreies 30-Minuten-Erstgespräch. Wir teilen unsere Erfahrungen aus diesem und vergleichbaren Projekten und prüfen offen, ob ein Pilot bei Ihnen Sinn macht. Eine erste Selbsteinschätzung Ihres Reifegrads liefert auch unser KI-Readiness-Check.