Ersatzteil-Obsoleszenzprognose

Das echte Ausmaß des Problems

Aufzüge sind langlebige Anlagen. Eine durchschnittliche Lebensdauer von 20 bis 30 Jahren ist keine Ausnahme, sondern der Normalfall. In Deutschland sind laut VDMA rund 700.000 Aufzüge in Betrieb — ein erheblicher Teil davon älter als 15 Jahre. Das Kernproblem: Steuerungskomponenten, Frequenzumrichter und elektronische Baugruppen werden von Herstellern im Schnitt nach 7 bis 12 Jahren abgekündigt. Wer heute einen Aufzug von 2008 wartet, arbeitet mit Bauteilen, für die die Erstausrüster oft gar keine Originalteile mehr herstellen.

Laut Sparetech-Daten aus industriellen Installed-Base-Analysen liegt bei einem typischen Wartungsunternehmen etwa 22 Prozent des Ersatzteillagers ungenutzt länger als fünf Jahre — Kapital, das in falschen Mengen falscher Teile gebunden ist. Gleichzeitig fehlen genau die Teile, die in den nächsten zwei Jahren kritisch werden.

Die finanziellen Folgen sind erheblich:

• Notbeschaffungsaufschläge: Reaktive Beschaffung abgekündigter Teile kostet laut Branchenerfahrung regelmäßig 200 bis 500 Prozent des ursprünglichen Lieferantenpreises — wenn das Teil überhaupt noch verfügbar ist.
• Ungeplante Stillstandskosten: Ein stillstehender Aufzug in einem Bürogebäude oder Pflegeheim verursacht pro Tag Kosten von 500 bis 5.000 Euro für den Betreiber, die häufig als Schadensersatzforderung beim Wartungsunternehmen landen.
• Erzwungene Modernisierung: Wenn kein Ersatzteil mehr beschaffbar ist, bleibt oft nur die Kompletterneuerung der Steuerung — Kosten: 8.000 bis 25.000 Euro pro Anlage, ungeplant im Budget.
• Reputationsschäden: Für Wartungsunternehmen ist die Abkündigung ohne Frühwarnsystem ein Vertragsrisiko. Kunden, die dreimal innerhalb von zwei Jahren wochenlange Stillstände erleben, kündigen Wartungsverträge.

Die zeitliche Dimension macht es besonders tückisch: Abkündigungsmeldungen kommen oft erst kurz vor dem tatsächlichen Produktionsende — manchmal mit einer Vorlaufzeit von nur drei bis sechs Monaten. Wer keine systematische Überwachung hat, erfährt davon entweder durch einen Lieferanten, der noch einen Restbestand anbietet, oder gar nicht — bis zur nächsten Störung.

Mit vs. ohne KI — ein ehrlicher Vergleich

Die Vergleichswerte im Feld “ohne KI” spiegeln Erfahrungsberichte aus dem deutschen Aufzugservicemarkt wider; die Prognose-Kennzahlen basieren auf Fallstudien von SPARETECH und akademischen Studien zur ML-basierten Obsoleszenzvorhersage (Sandborn et al., 2020).

Einschätzung auf einen Blick

Zeitersparnis — sehr hoch (5/5) Das ist der klare Stärkenbereich dieses Anwendungsfalls. Eine einzige Notbeschaffung eines abgekündigten Teils bindet 5 bis 15 Arbeitsstunden: Lieferantenrecherche, Preisvergleich, Kompatibilitätsprüfung, Ersatzlösung koordinieren, Einbautermin planen. Mit einer funktionierenden Prognose wird daraus eine planmäßige Bestellung in einer halben Stunde. Wenn dein Unternehmen drei bis fünf solcher Fälle pro Quartal hat, summiert sich das auf 15 bis 75 Stunden eingesparte Disponenten- und Beschaffungszeit — pro Quartal.

Kosteneinsparung — hoch (4/5) Direkt messbar: jede vermiedene Notbeschaffung spart den Preisaufschlag, jeder vermiedene Stillstand spart potenzielle Schadensersatzansprüche. Einschränkung: Last-Time-Buy-Bestellungen binden Lagerkapital — wer zu viel bestellt, tauscht Notbeschaffungskosten gegen Kapitalbindungskosten. Das Modell muss also nicht nur das “wann” treffen, sondern auch die richtige Menge empfehlen. In der Praxis gelingt das mit ausreichend historischen Verbaudaten recht gut, aber die Genauigkeit variiert mit der Qualität der Installed-Base-Daten.

Schnelle Umsetzung — gering (2/5) Das ist der schwierige Teil: Bevor das Modell arbeiten kann, müssen die Eingangsdaten stimmen. Viele Aufzugserviceunternehmen haben ihre Installed-Base-Daten in SAP PM, aber der Detaillierungsgrad variiert stark. Wenn Servicetechniker über Jahre hinweg Komponenten unter Sammelpositionen gebucht haben (“Steuerungsbaugruppe allgemein” statt mit exakter Artikelnummer), fehlt die Grundlage. Realistische Zeit bis zum produktiven Pilotbetrieb: 10 bis 16 Wochen, davon oft 6 bis 8 Wochen nur für die Datenbereinigung. Unter den verglichenen Aufzugbau-Anwendungsfällen gehört dieser Einstieg zu den anspruchsvolleren.

ROI-Sicherheit — mittel (3/5) Der Nutzen ist prinzipiell messbar — aber du musst ihn aktiv messen. Was hat eine Notbeschaffung im letzten Jahr gekostet, und hätte das Modell sie vorhergesagt? Diese Baseline braucht ein sauberes Tracking im ERP. Unternehmen ohne historische Kostenerfassung für Notbeschaffungen können den ROI nicht rückwirkend belegen. Wer das Tracking vor dem Rollout einführt, hat nach 12 Monaten Betrieb belastbare Zahlen.

Skalierbarkeit — begrenzt (2/5) Das ist die ehrliche Einschränkung dieses Ansatzes: Die Prognosequalität hängt stark von der Homogenität des Anlagenparks ab. Ein Unternehmen, das 300 Aufzüge eines Typs von einem Hersteller wartet, hat viel bessere ML-Grundlagen als eines mit 300 völlig verschiedenen Aufzügen. Bei sehr diversen Flotten muss für jeden wesentlichen Anlagentyp ein separates Modell trainiert und gepflegt werden. Das System skaliert in der Breite (mehr Anlagen des gleichen Typs) gut — in der Tiefe (neue Anlagentypen integrieren) weniger gut.

Richtwerte — stark abhängig vom Homogenitätsgrad des Anlagenparks und der Qualität bestehender ERP-Daten.

Was das Prognosemodell konkret macht

Das technische Fundament ist Machine Learning auf mehreren Datenschichten gleichzeitig:

Schicht 1 — Installed-Base-Daten: Für jede verwaltete Anlage erfasst das System, welche Komponenten in welchem Baujahr verbaut sind. Das umfasst Steuerungen, Frequenzumrichter, Sicherheitsbaugruppen und mechanische Verschleißteile. Quelle ist typischerweise das vorhandene ERP (SAP PM, IBM Maximo) oder ein dediziertes Wartungssystem.

Schicht 2 — Hersteller-Lifecycle-Daten: Hersteller wie Siemens, Schneider Electric oder KONE geben Abkündigungsmeldungen (End-of-Life-Notices) heraus. Diese kommen über Lieferanten-Portale, E-Mail-Verteiler oder Plattformen wie SPARETECH, die diese Daten systematisch aggregieren und mit ERP-Artikelnummern verknüpfen.

Schicht 3 — Bestellhistorie und Verbrauchsraten: Wie oft wurde welches Teil in den letzten drei bis fünf Jahren verbaut? Welche Teile hatten steigende Verbauraten (weil der Verschleiß zunimmt) und welche sinkende (weil die Anlage zunehmend modernisiert wird)?

Das Modell kombiniert diese drei Datenschichten und berechnet für jedes Teil einen Obsoleszenz-Risiko-Score mit Zeithorizont. Teile, die eine hohe Verbaurate haben, eine absehbare Abkündigung zeigen und in vielen Anlagen verbaut sind, landen oben auf der Last-Time-Buy-Liste. Teile, die theoretisch abgekündigt sind, aber in einer Anlage die seit Jahren nicht mehr gewartet wird stecken, landen unten.

Das Ergebnis ist kein automatischer Kaufbefehl, sondern eine priorisierte Liste mit Empfehlungen: „Diese 12 Teile solltest du in den nächsten sechs Monaten bestellen. Für Teil A empfehlen wir 8 Einheiten, für Teil B 2 Einheiten.” Die Einkaufs- oder Disponeentscheidung liegt weiterhin beim Menschen — das Modell beseitigt die Informationslücke, nicht die Verantwortung.

Was das System nicht kann

Es kann keine Abkündigungen vorhersagen, über die noch kein Hersteller kommuniziert hat. Es kann keine individuellen Qualitätsabweichungen einzelner Komponenten erkennen. Und es kann nicht die Nachfolgeteil-Kompatibilität automatisch bestätigen — das braucht nach wie vor den Techniker. Ein Prognosemodell ist ein Frühwarnsystem, kein Autopilot.

Obsoleszenzmanagement als gesetzliche Pflicht

Hier passiert oft ein Denkfehler: Viele Wartungsunternehmen betrachten die Ersatzteil-Obsoleszenzplanung als freiwillige Optimierung. Das stimmt nicht vollständig.

Die Betriebssicherheitsverordnung (BetrSichV) verpflichtet den Betreiber einer Aufzugsanlage zur lückenlosen Instandhaltung. „Instandhaltung” umfasst laut §4 BetrSichV auch die Sicherstellung, dass die Anlage in einem betriebssicheren Zustand bleibt — was im Umkehrschluss bedeutet: Wenn ein Wartungsunternehmen im Rahmen eines Vollwartungsvertrags die Instandhaltungsverantwortung übernimmt, trägt es auch das Risiko, wenn eine Anlage stillsteht, weil ein Teil nicht mehr beschaffbar war.

Die Aufzugsrichtlinie 2014/33/EU schreibt vor, dass Originalteile für eine neue Anlage üblicherweise 20 Jahre nach Markteinführung verfügbar bleiben — aber das gilt nur für den Erstausrüster, nicht für die Instandhaltung älterer Anlagen jenseits dieser Frist. Bei Anlagen, die älter als 20 Jahre sind, gibt es keinen normativen Schutz durch die Richtlinie.

Was das für die Praxis bedeutet: Wer einen Vollwartungsvertrag auf eine Anlage von 2001 unterschreibt, hat ohne proaktives Obsoleszenzmanagement ein stilles Haftungsrisiko. Das ist kein Schreckensszenario, sondern ein Planungsargument: Die Kosten eines Frühwarnsystems sind deutlich geringer als ein ungeplanter Stillstand mit Schadensersatzanspruch vom Betreiber.

Last-Time-Buy: Wie viel kauft man eigentlich auf Vorrat?

Das ist die praktisch schwierigste Frage — und eine, die ein einfaches Prognosemodell allein nicht beantworten kann.

Die Rechnung aus der Bestellmenge: Grundlage ist immer die Kombination aus zwei Faktoren: Wie viele Anlagen haben dieses Teil verbaut, und wie hoch ist die historische Ausfallrate? Ein Teil, das in 80 Anlagen verbaut ist und statistisch alle 8 Jahre ausfällt, wird im Durchschnitt 10 Mal pro Jahr gebraucht. Wenn die Anlage noch 6 Jahre im Betrieb bleibt, sind das 60 Einheiten Bedarf — aber nicht alle gleichzeitig.

Die Lagerhaltungskosten dagegen: 60 Einheiten auf einmal kaufen bedeutet Kapitalbindung. Bei einem Teil, das 300 Euro pro Stück kostet, wären das 18.000 Euro im Lager. Das Modell muss deshalb nicht nur den Gesamtbedarf schätzen, sondern auch den zeitlichen Verlauf: Wann werden die Anlagen wahrscheinlich modernisiert? Wann fallen die meisten Teile tatsächlich aus?

Ein realistischer Ansatz in der Praxis: Erfahrungsbasiert empfehlen Instandhaltungsexperten bei abgekündigten Teilen mit hoher Verbaurate: Zwischen 50 und 70 Prozent des geschätzten Gesamtbedarfs für die Restlaufzeit der betroffenen Anlagen. Den Rest kann man entweder nachordern (wenn noch möglich), aus Modernisierungen zurückgewinnen oder durch Nachfolgelösungen ersetzen. Ein ML-Modell mit guten historischen Verbaudaten kann diese Schätzung erheblich präzisieren — aber niemals auf Null-Restrisiko drücken.

Häufig unterschätzter Faktor: Lagerkosten für Spezialteile sind nicht trivial. Elektronische Baugruppen brauchen oft klimatisierte Lagerbedingungen, Feuchteschutz und Entladungsschutz. Die Lagerkosten können bei sensitiven Teilen 5 bis 10 Prozent des Teilepreises pro Jahr betragen — das gehört in die Last-Time-Buy-Kalkulation.

Die Qualität der Installed-Base-Daten: Was Servicetechniker wirklich dokumentieren

Das ist der Abschnitt, über den kein Softwarehersteller gerne spricht — weil er zeigt, warum Projekte scheitern, bevor das erste Modell trainiert ist.

In der Theorie ist das ERP der Single Point of Truth: Jede Anlage hat einen Datensatz mit allen verbauten Komponenten inklusive Artikelnummern, Baujahr und Letztaustauschdatum. In der Praxis sieht es oft so aus:

• Sammelpositionen: Techniker buchen auf „Steuerungskomponente” oder „Antriebstechnik”, weil das schneller geht als die Suche nach der exakten Artikelnummer.
• Historische Lücken: Anlagen, die vor der ERP-Einführung gewartet wurden, haben keine strukturierte Komponentenhistorie. Was vor 2015 verbaut wurde, steht oft nur im Papierstapel.
• Freitext-Notizen: „Neuen Wechselrichter von Lager eingebaut” — welcher genau? SAP-Nr.? Seriennummer? Keine Angabe.
• Unstrukturierte Bilder: Viele Techniker machen beim Einbau Fotos — gut gemeint, aber für eine ML-Pipeline nicht verwertbar ohne OCR und Klassifikation.

Diese Datenqualitätsprobleme sind kein Versagen der Techniker — sie sind das Ergebnis von Arbeitsabläufen, die für Geschwindigkeit optimiert wurden, nicht für Datenstruktur. Wer ein ML-Modell auf schlechten Installed-Base-Daten trainiert, bekommt schlechte Prognosen.

Was konkret hilft:

1. Vor dem ML-Projekt: Audit der Installed-Base-Daten für eine Pilotgruppe von 50–100 Anlagen. Wie viele haben vollständige Komponentendetails? Das ergibt den realistischen Startpunkt.
2. Ab Pilotstart: Neue Wartungsaufträge mit Pflichtfeld für Artikelnummer bei Teileaustausch. Erfordert Techniker-Training, aber es reicht auch nachzurüsten was neu hinzukommt.
3. Für Altbestände: Gezielte Nacherfassung bei der nächsten Hauptprüfung. Der TÜV-Besuch ist ein natürlicher Anlass, eine gründliche Dokumentation anzulegen.
4. Erwäge SPARETECH mit eigenem Katalog-Matching: Das System kann aus Artikelnummern im ERP automatisch Lifecycle-Informationen anreichern — und erkennt dabei auch Artikelnummern, die noch nicht vollständig klassifiziert sind.

Konkrete Werkzeuge — was wann passt

Die richtige Werkzeugwahl hängt vor allem davon ab, welches ERP-System bereits vorhanden ist und wie strukturiert die Installed-Base-Daten vorliegen.

SPARETECH — wenn ein strukturierter SAP-Stamm vorhanden ist SPARETECH ist die spezialisierte Lösung für Obsoleszenz-Management in der Industrie. Das 2018 in Stuttgart gegründete Unternehmen betreibt den größten industriellen Ersatzteilkatalog mit direktem Herstellerdaten-Feed zu Abkündigungen. Integration in SAP PM ist der Standard-Anwendungsfall. Das System erkennt automatisch, welche Artikelnummern im Materialstamm Abkündigungs-Risiken haben, und empfiehlt Nachfolgeteile mit technischem Spezifikationsvergleich. Die Kunden umfassen Bosch, Porsche und Airbus Helicopters. Preise auf Anfrage; für mittelständische Wartungsunternehmen typisch ab 20.000–40.000 Euro/Jahr.

IBM Maximo Application Suite — wenn ein umfassendes CMMS aufgebaut wird IBM Maximo ist das marktführende Enterprise Asset Management System. Es verwaltet nicht nur Ersatzteile, sondern den gesamten Asset-Lebenszyklus. Die Maximo Application Suite enthält Predictive Maintenance-Module, die auch Obsoleszenz-Risiken verwalten können — allerdings weniger spezialisiert als SPARETECH. Sinnvoll, wenn ein Unternehmen ohnehin eine vollständige CMMS-Einführung plant und Obsoleszenz als eines von mehreren Features mitnimmt. Kosten: typisch 3.000–8.000 USD/Monat für kleinere Deployments, plus erhebliche Implementierungskosten. Wirtschaftlich erst ab ~200 Mitarbeitenden.

SAP IBP mit eigenem Obsoleszenz-Add-on — für SAP-Unternehmen mit Demand-Planning-Kapazität SAP IBP bietet Supply-Chain-Planungsfunktionen, die auch für Ersatzteilprognosen genutzt werden können. Der Vorteil: native SAP-Integration ohne Daten-Export. Der Nachteil: SAP IBP ist ein generisches Supply-Chain-Tool, kein spezialisiertes Obsoleszenz-System. Es braucht erhebliche Konfigurationsarbeit, um für Ersatzteil-Lifecycle-Management geeignet zu sein. Wirtschaftlich ab 50.000 Euro/Jahr aufwärts — nur sinnvoll, wenn SAP IBP ohnehin für andere Planungsprozesse genutzt wird.

Custom ML mit Azure Machine Learning und Microsoft Power BI — für Unternehmen mit eigenem Daten-Team Wer in-house Data-Science-Kapazität hat (oder aufbauen kann), kann ein maßgeschneidertes Prognosemodell auf den eigenen Daten trainieren. Azure Machine Learning bietet die Trainings- und Deployment-Infrastruktur, Microsoft Power BI das Reporting-Dashboard. Vorteil: vollständige Kontrolle über Daten und Modell-Logik; keine Abhängigkeit von Drittanbieter-Katalogen. Nachteil: erheblicher Aufbauaufwand (4–8 Monate für erste produktive Version), laufende Modellpflege intern. Geeignet für Unternehmen mit mehr als 1.000 verwalteten Anlagen, bei denen die wirtschaftliche Eigenentwicklung die Lizenzkosten übersteigt.

Zusammenfassung: Wann welcher Ansatz

• SAP PM vorhanden, strukturierte Stammdaten → SPARETECH
• Vollständiges CMMS gesucht, Obsoleszenz als ein Feature → IBM Maximo
• SAP IBP bereits im Einsatz, Supply-Chain-Team vorhanden → SAP IBP-Erweiterung
• 1.000+ Anlagen, internes Data-Science-Team → Custom ML auf Azure Machine Learning

Für alle Ansätze gilt: Es gibt kein sinnvolles kostenloses Einstiegsprodukt für produktiven Betrieb. Die kostenlose Variante ist die Excel-Tabelle mit manueller Abkündigungsverfolgung — sinnvoll als Übergangslösung für Unternehmen unter 150 Anlagen.

Datenschutz und Datenhaltung

Obsoleszenz-Prognosemodelle verarbeiten in erster Linie technische Bestandsdaten und Einkaufshistorien — keine personenbezogenen Daten im klassischen Sinne. Das macht die DSGVO-Lage einfacher als bei vielen anderen KI-Projekten.

Dennoch gibt es relevante Datenschutzaspekte:

Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO: Wenn ein externer Dienstleister (wie SPARETECH) auf Daten deines ERP-Systems zugreift — auch wenn es nur technische Stammdaten sind — ist zu prüfen, ob ein AVV erforderlich ist. In der Praxis sollte bei jeder Cloud-basierten Integration ein AVV abgeschlossen werden, um auf der sicheren Seite zu sein.

Geschäftsgeheimnisse: Die Installed-Base-Daten deines Anlagenparks sind wettbewerblich sensibel. Welche Aufzüge welcher Kunden du wartest, welche Vertragskonditionen gelten, welche Teile du in welchen Mengen bestellst — das sind Informationen, die nicht in US-amerikanischen Rechenzentren ohne Prüfung landen sollten.

• SPARETECH: Deutsches Unternehmen, EU-Datenhaltung — aus Datenperspektive die unproblematischste Option.
• IBM Maximo: IBM Cloud EU-Region verfügbar; On-Premise-Deployment für maximale Kontrolle möglich. KRITIS-Kompatibilität nachgewiesen.
• SAP IBP: SAP nutzt EU-Rechenzentren für europäische Kunden. DSGVO-konform, AVV über SAP-Standard-Prozess erhältlich.
• Azure Machine Learning: Microsoft EU Data Boundary-Programm verfügbar; Daten können in deutschen Rechenzentren (Frankfurt, Berlin) gehalten werden. AVV über Microsoft Online Services Terms automatisch enthalten.
• Custom ML on-premise: Maximale Datensouveränität, keine Drittanbieter-Abhängigkeit. Empfohlen, wenn der Anlagenpark KRITIS-nahe Gebäude (Krankenhäuser, Justizgebäude, Infrastruktur) umfasst.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

Der größte Kostenblock ist oft nicht die Software, sondern die Datenbereinigung:

• Audit und Bereinigung der Installed-Base-Daten: 4–8 Wochen interner Aufwand + optional externer Dienstleister (5.000–15.000 Euro)
• Software-Implementierung: abhängig vom Ansatz — SPARETECH 15.000–30.000 Euro Einführungsprojekt; Custom ML 40.000–100.000 Euro Entwicklung
• ERP-Integration: 10.000–25.000 Euro je nach SAP-Komplexität

Laufende Kosten (monatlich/jährlich)

• SPARETECH: ca. 20.000–40.000 Euro/Jahr (Wartungsunternehmen mit 500–1.000 Anlagen)
• IBM Maximo: 3.000–8.000 USD/Monat SaaS + laufende Adminkosten
• Custom ML auf Azure Machine Learning: 500–2.000 Euro/Monat Infrastruktur + interner Modellpflegeaufwand (5–10 Stunden/Monat)

Was du dagegenrechnen kannst

Annahme: 500 verwaltete Anlagen, 4 Notbeschaffungsfälle pro Quartal, durchschnittlich 8 Stunden Disponenten-Aufwand pro Fall, durchschnittlicher Beschaffungs-Aufschlag 150 Euro pro Notfall:

• Eingesparte Dispositionszeit: 4 × 8 Std. × 4 Quartale × 35 Euro/Std. = 4.480 Euro/Jahr (Orientierungswert)
• Vermiedene Notaufschläge: angenommen 2 von 4 Fällen pro Quartal verhinderbar × 4 Quartale × 150 Euro Durchschnittsaufschlag = 1.200 Euro/Jahr (konservativ; in der Praxis bei teuren Komponenten deutlich höher)
• Vermiedene Stillstandskosten: 1 vermiedener Stillstand pro Quartal × 2 Tage × 1.000 Euro/Tag Betreiberrisiko = 8.000 Euro/Jahr (stark situationsabhängig)

Das sind im konservativen Szenario rund 14.000 Euro Nutzen — die sich einem SPARETECH-Abonnement von 20.000–40.000 Euro/Jahr gegenüberstehen. Der ROI tritt erst ein, wenn das Unternehmen groß genug ist und die Notbeschaffungskosten hinreichend dokumentiert sind.

Ehrliches Fazit: Die Wirtschaftlichkeit des Einsatzes eines spezialisierten Tools wie SPARETECH beginnt realistisch bei 300 bis 500 verwalteten Anlagen. Darunter ist eine gut gepflegte Excel-Liste mit Abkündigungsmonitoring oft das bessere Kosten-Nutzen-Verhältnis.

Drei typische Einstiegsfehler

1. Mit dem Modell starten, bevor die Daten stimmen. Das ist der häufigste Fehler bei ML-Projekten in der Industrie — und er ist bei diesem Anwendungsfall besonders destruktiv. Wenn 40 Prozent der Installed-Base-Einträge unvollständige Komponentendetails haben, ist das Modell für genau diese 40 Prozent blind. Es wird Teile als “kein Risiko” einschätzen, weil es schlicht keine Daten hat — nicht weil kein Risiko besteht. Das Ergebnis ist ein System, das Sicherheit suggeriert, die nicht existiert. Besser: Erst für eine Pilotgruppe von 50–100 Anlagen die Daten vollständig bereinigen, dann pilotieren.

2. Abkündigungsmeldungen als einzige Datenquelle behandeln. Hersteller kommunizieren Abkündigungen manchmal erst sehr spät — oder gar nicht förmlich, wenn ein Produkt einfach “nicht mehr lieferbar” ist. Wer nur auf offizielle End-of-Life-Notices wartet, bemerkt den Lieferausfall oft erst, wenn der Lieferant eine Bestellung nicht mehr bestätigt. Besser: Lieferanten-Feedback und Bestelldaten als zweite Signalquelle einbeziehen. Steigen Lieferzeiten, fallen Rückmeldungsquoten oder nehmen Preissteigerungen bei bestimmten Artikeln zu, sind das frühe Warnsignale für bevorstehende Abkündigungen.

3. Das Modell wird eingeführt und dann nicht gepflegt. Das ist der gefährlichste Fehler — weil er still passiert.

Ein Obsoleszenz-Prognosemodell, das sechs Monate nach dem Launch nicht mehr aktualisiert wird, hat veraltete Hersteller-Lifecycle-Daten und veraltete Installed-Base-Daten. Es produziert weiterhin Outputs — aber diese spiegeln nicht mehr die aktuelle Situation wider. Statische ML-Modelle zeigen einen dokumentierten Qualitätsabfall über Zeit, wenn sie keine neuen Daten integrieren (laut akademischer Forschung zu Konzept-Drift in Zeitreihenmodellen). Im besten Fall ignorieren Einkäufer die veralteten Empfehlungen — im schlimmsten Fall vertrauen sie ihnen.

Was einen Review auslöst: jede ERP-Änderung (neue Artikelnummern, Lieferantenwechsel), jede größere Modernisierungswelle im Anlagenpark, und mindestens einmal jährlich ein manueller Abgleich zwischen Modellvorhersagen und tatsächlich eingetretenen Abkündigungen. Diese Wartungsaufgabe braucht eine namentlich benannte Zuständigkeit — nicht “der Einkauf”, sondern eine Person.

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

Ein Obsoleszenz-Prognosemodell ist ein Hilfssystem für den Einkauf — kein autonomes System. Das klingt selbstverständlich, wird aber in der Einführungsphase oft falsch eingeschätzt.

Das Adoptionsproblem: Erfahrene Disponenten haben über Jahre intuitive Abkündigungskenntnis aufgebaut. Sie wissen: “Bei allem von Siemens MicroMaster-Serie aufpassen” oder “Den alten Regler von Honeywell bekommt man seit zwei Jahren nicht mehr.” Ein System, das plötzlich formelle Empfehlungen produziert, kann sich anfühlen wie eine Kritik an der bisherigen Arbeitsweise — auch wenn das nie so gemeint ist.

Was hilft: Die erfahrenen Disponenten aktiv in die Modellvalidierung einbinden. Ihre intuitive Liste der “Problemteile” ist ein wertvoller Testdatensatz: Tauchen diese Teile oben in den Modellempfehlungen auf? Wenn nicht, ist das ein Qualitätssignal für das Modell, nicht für die Disponenten. Wer das System mitvalidiert hat, vertraut ihm mehr.

Das Einkaufsproblem: Last-Time-Buy-Bestellungen binden Budgets. Die Genehmigung einer Bestellung von 25 Einheiten eines Teils, das gerade nicht gebraucht wird, erfordert eine andere Prozesslogik als reaktive Einkäufe. Das Budget muss prospektiv reserviert werden — was Finance-Freigaben nach sich zieht, die in der Einführungsplanung oft vergessen werden.

Was nicht passiert: Das System wird keine Lieferantenbeziehungen automatisch managen, keine Bestellungen autonom auslösen und keine Kompatibilitätsprüfungen für Nachfolgeteile durchführen. Es priorisiert — die Entscheidung trifft weiterhin der Mensch. Wer das vorab klar kommuniziert, vermeidet Enttäuschungen.

Realistischer Zeitplan mit Risikohinweisen

Wichtig: Dieser Zeitplan gilt für einen SPARETECH-basierten Ansatz. Ein Custom-ML-Projekt beginnt deutlich später produktiv — realistisch 5 bis 8 Monate bis zum ersten produktiven Einsatz.

Häufige Einwände — und was dahintersteckt

„Wir bekommen die Abkündigungen doch sowieso vom Lieferanten gemeldet.” Das stimmt manchmal — aber unzuverlässig. Große Lieferanten mit strukturierten Produktmanagement-Prozessen senden tatsächlich formelle End-of-Life-Notices. Kleine Lieferanten oft nicht. Und selbst wenn eine Meldung kommt: Wer prüft, ob sie in deinen ERP-Bestand gegen alle betroffenen Artikelnummern gegengeprüft wurde? In der Praxis landet die E-Mail im Postfach der Einkäuferin, wird gelesen, weitergemailed und dann vergessen — weil kein System die Verbindung zu den installierten Anlagen zieht.

„Das lohnt sich nur für große Unternehmen.” Für Unternehmen unter 150 Anlagen stimmt das wahrscheinlich — eine Excel-Liste mit manueller Abkündigungsverfolgung reicht. Ab 300 Anlagen beginnt das Verhältnis zu kippen: zu viele Teile, zu viele Hersteller, zu viele Anlagentypen, um das manuell zuverlässig zu überblicken. Und ab 500 Anlagen ist eine systematische Lösung keine Luxusoption mehr, sondern ein betriebliches Erfordernis.

„Unsere Techniker wissen, welche Teile kritisch sind.” Das ist oft wahr — für die Teile, die in letzter Zeit kritisch waren. Aber das Erfahrungswissen von Technikern deckt typischerweise die letzten drei bis fünf Jahre ab. Abkündigungen, die noch zwei Jahre entfernt liegen, sind nicht im aktiven Wissensradar. Und wenn der erfahrene Techniker das Unternehmen verlässt, geht dieses Wissen mit. Ein Prognosemodell ist unter anderem eine Möglichkeit, dieses Wissen aus Köpfen in ein System zu übertragen.

Woran du merkst, dass das zu dir passt

• Du hast mehr als 300 Aufzüge im Wartungsvertrag, davon ein erheblicher Anteil älter als 15 Jahre
• Du erlebst mindestens einen Notbeschaffungsfall pro Quartal, bei dem ein Teil reaktiv gesucht wird, weil es nicht im Lager ist
• Dein ERP enthält strukturierte Installed-Base-Daten mit Komponentendetails auf Artikelnummern-Ebene — oder du bist bereit, diese in einer Pilotgruppe zu vervollständigen
• Du hast im letzten Jahr mindestens eine ungeplante Modernisierung durchgeführt, weil kein Ersatzteil mehr beschaffbar war
• Dein Einkaufsteam verbringt messbare Zeit mit der Suche nach Alternativen für schwer beschaffbare Teile

Wann es sich (noch) nicht lohnt — drei harte Ausschlusskriterien:

1. Unter 150 verwalteten Anlagen. Die Menge der abzupflegenden Teile und Hersteller-Beziehungen ist bei dieser Größe noch manuell handhabbar. Der Aufwand für Datenbereinigung und Tool-Einführung übersteigt die erzielbare Zeitersparnis. Eine strukturierte Excel-Liste mit einem jährlichen Abkündigungs-Check reicht vollständig.

2. Keine strukturierten Installed-Base-Daten im ERP. Wenn Servicetechniker bisher Komponenten nur unter Sammelpositionen buchen (ohne Artikelnummer, ohne Seriennummer), fehlt das Fundament für jedes ML-Modell. In diesem Fall ist der erste Schritt nicht das Prognosemodell, sondern die Einführung strukturierter Wartungsdokumentation. Ein Prognosemodell auf schlecht strukturierten Installed-Base-Daten produziert falsche Sicherheit — das ist gefährlicher als gar kein System.

3. Kein Anlagenpark mit Typ-Homogenität — jeder Aufzug ist ein Unikat. Wenn das Unternehmen einen sehr diversen Park verwaltet (viele verschiedene Fabrikate, Baujahre und Steuerungstypen in Kleinstmengen), trainiert das ML-Modell auf zu wenigen Beispielen pro Typ. Die Prognosequalität wird für die seltenen Typen gering sein — genau jene, die oft die schwierigsten Obsoleszenzfälle verursachen. Für Unternehmen mit sehr heterogenem Park ist ein stärker manuell gestützter Ansatz (monatliche Lieferantenchecks, Branchenvernetzung) oft realitätsnäher als ein ML-Modell.

Das kannst du heute noch tun

Beginne mit einem kostenlosen Daten-Audit, das du selbst machen kannst — ohne Tool-Entscheidung, ohne Budget-Freigabe.

Exportiere aus deinem ERP alle Wartungsaufträge der letzten drei Jahre, bei denen ein Ersatzteil ausgetauscht wurde. Dann frage für jede Zeile: Steht dort eine vollständige Artikelnummer des Herstellers — oder nur eine interne SAP-Materialnummer ohne Herstellerreferenz? Welcher Anteil der Einträge ist vollständig auflösbar?

Das Ergebnis gibt dir in zwei Stunden den realistischsten Startpunkt: Wenn 70 Prozent oder mehr deiner Bestellungen vollständige Artikelnummern enthalten, ist der Weg zu einer ML-gestützten Obsoleszenzprognose realistisch. Wenn weniger als 40 Prozent vollständig sind, beginnt das Projekt mit einer Datenpflegekampagne.

Für eine erste strukturierte Selbstanalyse hilft der folgende Prompt — damit kannst du die Ausgabe eines ERP-Exports durch eine KI-gestützte Analyse laufen lassen:

Quellen & Methodik

• SPARETECH-Daten zu Lagerbestand-Ineffizienz: Sparetech GmbH, „Spare Parts Obsolescence Management: How to Avoid Downtime” (sparetech.io, 2024). Kernaussage: 22 % des Industrieersatzteillagers liegt länger als fünf Jahre ungenutzt. Aussagen zu Notbeschaffungsaufschlägen basieren auf SPARETECH-Kundendaten und sind als Erfahrungswerte aus dem Industrieumfeld einzuordnen.
• Fallstudie Aufzug-Ersatzteillager: „A Case Study of Spare Parts Inventories in the Elevator Industry”, OSCM Forum Journal, Vol. 11, No. 3 (2018). Untersuchung von Bestandsstrategien in der Aufzugsbranche mit Empfehlungen für Sicherheitsbestände bei kurzen Produktlebenszyklen.
• ML-Obsoleszenzprognose: Peter A. Sandborn et al., „Forecasting Obsolescence Risk and Product Lifecycle Using Machine Learning”, ResearchGate (2020). Dokumentiert Genauigkeit und Einschränkungen datengetriebener Obsoleszenzmodelle — inkl. Degradation bei fehlendem Modell-Update.
• Regulatorischer Rahmen: BetrSichV (Betriebssicherheitsverordnung) in gültiger Fassung; Aufzugsrichtlinie 2014/33/EU; Normen- und Vorschriftenübersicht KONE Deutschland (kone.de, abgerufen April 2026).
• Notbeschaffungsaufschläge und Stillstandskosten: Erfahrungsbasierte Angaben aus deutschem Aufzugservicemarkt; kein repräsentativer Querschnitt, aber konsistente Größenordnungen aus mehreren Branchengesprächen.
• Preisangaben Tools: Veröffentlichte und auf Anfrage erhältliche Tarife von SPARETECH, IBM, SAP und Microsoft (Stand April 2026).

Du willst wissen, wie gut deine Installed-Base-Daten für eine Obsoleszenzprognose geeignet sind — und welches Tool für deinen Anlagenpark am besten passt? Meld dich — das klären wir in einem kurzen Gespräch.