Die richtige PdM-Lösung wählen: Eigenentwicklung vs. Kauf

Sie haben entschieden, dass sich die Investition in Predictive Maintenance lohnt. Die nächste Frage: Selbst entwickeln oder eine Plattform kaufen?

Beide Wege funktionieren. Die richtige Wahl hängt von Ihrem Team, Ihrem Zeitrahmen und Ihren Optimierungszielen ab.

Der Eigenentwicklungsweg

Was Sie brauchen: Ein Data-Engineering-Team (2-3 Ingenieure) plus einen ML-Engineer, 6-12 Monate für ein MVP, laufende Wartung.

Wo Eigenentwicklung überzeugt

Volle Kontrolle über die Modelle. Sie trainieren auf Ihren exakten Anlagen und Fehlermodi.
Integrationsflexibilität. Proprietäres SCADA von 2008? Sie bauen genau die passenden Konnektoren.
Keine Pro-Anlage-Lizenzkosten. Bei sehr großer Skalierung (10.000+ Anlagen) bestehen die Grenzkosten nur aus Infrastruktur.

Wo Eigenentwicklung schmerzt

Time-to-Value. Anlagen fallen aus, während Sie die Pipeline bauen.
Das 80-%-Problem. Data Engineering verschlingt 80 % des Aufwands. Sie bauen kein Modell — Sie bauen eine verteilte Echtzeit-Datenplattform.
Laufende Wartung. Modelle driften. Kafka braucht Upgrades. Das ist permanent gebundenes Personal.
Cold Start für ML. Ohne vortrainierte Baselines starten Ihre Modelle bei null.

Der Kaufweg

Was Sie brauchen: Anbieterevaluierung (2-4 Wochen), Pilot-Deployment (1-2 Wochen), Produktionsrollout (2-4 Wochen).

Wo Kauf überzeugt

Sofortige Time-to-Value. Vortrainierte Modelle erkennen Anomalien ab dem ersten Tag.
Operative Reife. Der Anbieter hat Edge-Erfassung, Feature Engineering, Model Serving und Alarm-Deduplizierung bereits gelöst.
Branchenübergreifendes Lernen. Modelle, die über mehrere Kunden trainiert wurden, transferieren Wissen.
Planbare Kosten. Pro-Anlage-Preise bedeuten, dass Sie die Kosten vor dem Start kennen.

Wo Kauf schmerzt

Anbieterabhängigkeit. Ihre Vorhersagen hängen von einem Dritten ab.
Weniger Anpassung. Sie möchten vielleicht eine bestimmte Modellarchitektur, die die Plattform nicht unterstützt.
Daten verlassen Ihr Netzwerk. (Wobei Edge-Hybrid-Architekturen dies adressieren.)

3-Jahres-Gesamtbetriebskosten (TCO)

Das Argument „Eigenentwicklung ist bei Skalierung günstiger" ist verbreitet, wird aber selten mit realen Zahlen belegt. Hier ist ein realistischer TCO-Vergleich über drei Skalierungsstufen:

| Kostenkomponente | Eigen (100 Anlagen) | Kauf (100 Anlagen) | Eigen (500 Anlagen) | Kauf (500 Anlagen) | Eigen (2.000 Anlagen) | Kauf (2.000 Anlagen) | |---|---|---|---|---|---|---| | Jahr 1: Entwicklung | 350.000 € | 0 € | 350.000 € | 0 € | 450.000 € | 0 € | | Jahr 1: Infrastruktur | 40.000 € | Inklusiv | 80.000 € | Inklusiv | 180.000 € | Inklusiv | | Jahr 1: Lizenz/SaaS | 0 € | 60.000 € | 0 € | 180.000 € | 0 € | 480.000 € | | Jahr 2: Wartung/Entw. | 180.000 € | 0 € | 220.000 € | 0 € | 280.000 € | 0 € | | Jahr 2: Infrastruktur | 40.000 € | Inklusiv | 80.000 € | Inklusiv | 180.000 € | Inklusiv | | Jahr 2: Lizenz/SaaS | 0 € | 60.000 € | 0 € | 180.000 € | 0 € | 480.000 € | | Jahr 3: Wartung/Entw. | 180.000 € | 0 € | 220.000 € | 0 € | 280.000 € | 0 € | | Jahr 3: Infrastruktur | 40.000 € | Inklusiv | 80.000 € | Inklusiv | 180.000 € | Inklusiv | | Jahr 3: Lizenz/SaaS | 0 € | 60.000 € | 0 € | 180.000 € | 0 € | 480.000 € | | 3-Jahres-Summe | 830.000 € | 180.000 € | 1.030.000 € | 540.000 € | 1.550.000 € | 1.440.000 € |

Zentrale Annahmen: Die Eigenentwicklungskosten umfassen 2 VZÄ Data Engineers (je 90.000 €/Jahr) + 1 VZÄ ML-Engineer (100.000 €/Jahr) für die Entwicklung, reduziert auf 1,5 VZÄ für die laufende Wartung. Der Kaufpreis geht von 50 €/Anlage/Monat mit Mengenrabatten bei Skalierung aus. Infrastruktur umfasst Cloud-Compute, Speicher, Kafka, Datenbanken.

Der Break-even-Punkt — ab dem Eigenentwicklung pro Jahr günstiger wird — liegt typischerweise bei 1.500-2.000 Anlagen, und nur wenn Sie bereits das Team haben. Bei 100-500 Anlagen gewinnt Kauf mit weitem Vorsprung bei den reinen Kosten. Bei jeder Skalierung gewinnt Kauf bei der Time-to-Value (Wochen statt Monate).

Das Integrationsproblem

Hier ist die Zahl, die die meisten Build-vs-Buy-Analysen übersehen: Die Integration mit bestehenden Systemen verschlingt 60-70 % der gesamten Projektzeit, unabhängig davon, ob Sie die PdM-Plattform selbst bauen oder kaufen.

CMMS-Integration

Ihr Predictive-Maintenance-System muss Arbeitsaufträge erstellen, Wartungshistorien prüfen und Anlagendatensätze aktualisieren. Die großen CMMS-Plattformen haben jeweils eigene Integrationsherausforderungen:

SAP PM: RFC/BAPI-Schnittstellen sind gut dokumentiert, aber komplex. Das Erstellen einer Wartungsmeldung (IW21-Äquivalent) via API erfordert das Mapping auf SAPs spezifische Datenstrukturen (Technischer Platz, Equipment-Nummer, Schadenscodes). Planen Sie 4-6 Wochen für eine zuverlässige bidirektionale Integration ein.
IBM Maximo: Die REST-API ist modern und gut gestaltet, aber das Feldmapping zwischen Ihrem Anlagenmodell und Maximos Hierarchie benötigt Zeit. Maximos Workflow-Engine bedeutet, dass Ihre Arbeitsaufträge bestehende Freigabeketten respektieren müssen.
Infor EAM / Hexagon: Die API-Qualität variiert erheblich je nach Version. Ältere Installationen erfordern möglicherweise individuelle Middleware.

Historian-Integration

Die meisten Werke haben jahrelange wertvolle Sensordaten in einem Historian gespeichert:

OSIsoft PI (AVEVA PI): Die PI Web API ist leistungsfähig, erfordert aber sorgfältige Authentifizierungskonfiguration (Kerberos oder Basic Auth). Die Extraktion historischer Daten für ML-Training im großen Maßstab (Millionen von Messwerten) erfordert Batch-Requests und Rate Limiting, um den PI-Server nicht zu überlasten. Planen Sie 2-3 Wochen ein.
Honeywell PHD: Ältere API, erfordert oft einen On-Premises-Integrationsserver. Datenextraktion ist langsamer als bei PI.
GE Proficy Historian: OPC-HDA-Schnittstelle, generell unkompliziert, aber beschränkt auf Pull-basierten Datenzugriff.

ERP-Integration

Für Ersatzteilbeschaffung und Kostenverfolgung benötigen Sie ERP-Konnektivität:

SAP-MM-Integration für automatisierte Bestellanforderungen basierend auf RUL-Vorhersagen
Kostenstellen-Mapping für die Wartungs-ROI-Verfolgung
Synchronisation der Werksstruktur

Die Konsequenz: Ob Sie die PdM-Engine selbst bauen oder kaufen — planen Sie erhebliche Zeit und Expertise für die Integration ein. Eine Plattform mit vorgefertigten CMMS-Konnektoren und dokumentierten Historian-Integrationsmustern spart 3-6 Monate im Vergleich zum Eigenbau.

Entscheidungsrahmen

| Faktor | Tendenz Eigenbau | Tendenz Kauf | |--------|-----------|----------| | Data-Engineering-Team? | Ja, 3+ Ingenieure | Nein oder < 3 | | Zeitrahmen bis zum ersten Ergebnis? | 6+ Monate akzeptabel | Ergebnisse in Wochen erforderlich | | Anlagentypen | 1-2 gut verstandene | Viele, diverse Anlagen | | ML-Infrastruktur | Kubernetes, MLflow etc. | Aufbau von null | | Skalierung | 10.000+ Anlagen | 50-5.000 Anlagen | | Budgetmodell | CapEx (einmal bauen) | OpEx (planbar monatlich) |

Bewertungsmatrix mit Punktsystem

Für eine strukturiertere Bewertung vergeben Sie 1-5 Punkte pro Faktor für Ihr Unternehmen:

| Faktor | Gewichtung | Punktzahl 1 (Tendenz Kauf) | Punktzahl 5 (Tendenz Eigenbau) | |---|---|---|---| | Time-to-Value | 25 % | Ergebnisse in < 3 Monaten erforderlich | 12+ Monate akzeptabel | | Anpassungsbedarf | 20 % | Standard-Anlagentypen | Einzigartige Prozesse/Anlagen | | Teamfähigkeit | 20 % | Kein ML-/Data-Eng.-Team | Erfahrenes ML- + Data-Team | | Datensensibilität | 15 % | Cloud-OK, Standard-AVV | Air-gapped, klassifizierte Daten | | Skalierung (Anlagenzahl) | 10 % | < 500 Anlagen | > 5.000 Anlagen | | Budgetstruktur | 10 % | OpEx bevorzugt (monatlich) | CapEx bevorzugt (einmalig) |

Berechnungsbeispiel — mittelgroßes Chemiewerk (300 Anlagen):

Time-to-Value: 2 (Vorstand will dieses Quartal Ergebnisse) × 25 % = 0,50
Anpassung: 3 (einige proprietäre Reaktoren) × 20 % = 0,60
Teamfähigkeit: 2 (ein Data Analyst, kein ML) × 20 % = 0,40
Datensensibilität: 3 (Standard-Cloud OK, EU-Residenz erforderlich) × 15 % = 0,45
Skalierung: 2 (300 Anlagen) × 10 % = 0,20
Budget: 2 (OpEx bevorzugt) × 10 % = 0,20
Summe: 2,35 → Starkes Kaufsignal

Ein Wert unter 2,5 deutet auf Kauf hin. Über 3,5 auf Eigenentwicklung. Zwischen 2,5 und 3,5 liegt die Hybridzone.

Die Hybridoption

Viele Teams beginnen mit dem Kauf und bauen dann drumherum. Das ist oft die pragmatische Wahl — besonders im Bewertungsbereich 2,5-3,5. Hier ist ein phasenweiser Zeitplan:

Monat 1-3: Bereitstellen und validieren. Stellen Sie eine Plattform für die sofortige Anomalieerkennung an Ihren kritischsten Anlagen bereit. Nutzen Sie diese Phase, um der Geschäftsleitung den Mehrwert zu belegen, interne Datenkompetenz aufzubauen und Baseline-Kennzahlen zu etablieren (aktuelle Ausfallraten, Stillstandskosten, Ersatzteilausgaben). Das ist Ihre „Quick Win"-Phase — versuchen Sie nicht, alles auf einmal zu lösen.

Monat 3-6: Integrieren und erweitern. Nutzen Sie die Plattform-API, um Vorhersagen in individuelle Dashboards und bestehende CMMS-/ERP-Workflows einfließen zu lassen. Exportieren Sie Trainingsdaten für spezialisierte Analysen. Beginnen Sie mit dem Aufbau interner Expertise, indem Sie neben den Modellen der Plattform arbeiten — verstehen Sie, was sie erkennen, was sie übersehen und warum.

Monat 6-12: Anpassen und optimieren. Trainieren Sie spezialisierte Modelle für Anlagen, die die Plattform nicht gut abdeckt (proprietäre Prozesse, ungewöhnliche Fehlermodi). Erstellen Sie individuelle Integrationen mit Legacy-Systemen. Zu diesem Zeitpunkt haben Sie 6+ Monate gelabelter Daten (Vorhersagen, die von Ihrem Team bestätigt oder korrigiert wurden), was Gold wert für das Training ist.

Jahr 2+: Unabhängigkeit evaluieren. Mit 12+ Monaten gelabelter Daten, trainierten Modellen und interner ML-Kompetenz können Sie eine fundierte Entscheidung treffen: Weiterhin die Plattform nutzen (weil die betriebliche Belastung des Eigenbetriebs inzwischen klar ist), auf eine selbst gehostete Lösung migrieren oder einen Hybrid fahren, bei dem die Plattform Standardanlagen abdeckt und Ihr Team die spezialisierten Fälle bearbeitet.

Worauf Sie bei einer Plattform achten sollten

Bei der Evaluierung von PdM-Anbietern trennen diese Fähigkeiten produktionsreife Plattformen von Demos:

Erklärbarkeit — SHAP-Werte, Feature-Beiträge. Wenn der Anbieter seine Vorhersagen nicht erklären kann, können Sie es auch nicht. Bitten Sie um eine echte Alarmanzeige mit Feature-Attribution — keine Marketing-Folie.
Multi-Modell — Anomalieerkennung, RUL-Schätzung und Fehlerklassifikation. Eine Plattform, die nur Anomalieerkennung beherrscht, löst 30 % des Problems. Sie brauchen alle drei, um von „etwas stimmt nicht" zu „hier ist das Problem und wann der Ausfall eintritt" zu gelangen.
Cold-Start-Handling — Vortrainierte Baselines, die ab dem ersten Tag funktionieren, nicht „warten Sie 6 Monate auf genügend Daten". Fragen Sie, auf welchen Benchmark-Datensätzen die Modelle trainiert wurden und welche Genauigkeit sie sofort erzielen.
Mandantenisolation — Kryptographische Datentrennung. Fragen Sie gezielt nach Row-Level Security vs. Filterung auf Anwendungsebene. Wenn der Anbieter „Anwendungsebene" sagt, bedeutet das, dass ein einziger Bug Ihre Daten anderen Kunden offenlegen kann.
Edge-Unterstützung — Inferenz mit niedriger Latenz, Datensouveränität, Offline-Fähigkeit. Wenn Ihr Standort intermittierende Konnektivität oder strenge Datenresidenz-Anforderungen hat, ist Edge-Inferenz keine Option, sondern Pflicht.
API-first-Architektur — Wenn Sie es nicht via API automatisieren können, werden Sie es überwachsen. Prüfen Sie, ob Arbeitsauftragserstellung, Modellstatus, Alarmmanagement und Datenexport programmatisch verfügbar sind.
Transparente Preisgestaltung — Kein „Vertrieb kontaktieren" für Basisinformationen. Pro-Anlage-Preise, die Sie vor der Vertragsunterzeichnung kalkulieren können. Versteckte Kosten (Datenspeicher-Überschreitung, API-Call-Limits, Premium-Support-Stufen) sollten von Anfang an sichtbar sein.

Prevly bietet ein kostenloses Pilotprojekt für bis zu 10 Maschinen. Starten Sie hier — sehen Sie echte Vorhersagen auf Ihren Anlagen in unter einer Woche.

Weiterführende Artikel: Edge vs. Cloud für PdM · Der ROI vorausschauender Wartung · Predictive Maintenance vs. CMMS