Warum die meisten Industrial Data Fabric Projekte scheitern — und das 6-Säulen-Framework, das es verhindert
Von Tools wie inmation zum vollständigen IIoT-Ökosystem: wie die cts Group Industrial Informatics für Skalierbarkeit strukturiert — und warum der PoC nie das eigentliche Problem ist.
Wir sind seit Jahrzehnten in der industriellen Automatisierung tätig. In dieser Zeit haben wir ein Muster beobachtet, das sich mit bemerkenswerter Regelmäßigkeit wiederholt: Ein Unternehmen investiert in eine Datenplattform, führt einen erfolgreichen Proof of Concept durch, feiert intern — und dann skaliert nichts. Der PoC wird zur Dauerlösung. Die Daten bleiben isoliert. Die Investition trägt sich nie weiter.
Das ist kein Technologieproblem. Die Werkzeuge existieren. inmation als Process Historian und Industrial Data Fabric ist ausgereift, bewährt und leistungsfähig. Das Problem ist fast immer struktureller Natur. Branchenweit zeigen Analysten und Praktiker auf dieselbe Ursache: Umsetzungsteams, die isoliert arbeiten — abgekoppelt von Entscheidungsträgern, dem Anlagenbetrieb und der zentralen IT —, die Transformation als theoretische Übung statt als operative Aufgabe betreiben. Die Technologie wird zur Lösung auf der Suche nach einem Problem.
Diese Erkenntnis hat uns bei der cts Group dazu geführt, das zu entwickeln, was wir das 6-Säulen-Framework für Industrial Informatics nennen. Es ist das Fundament, auf dem alles andere aufbaut — von Architekturentscheidungen über Use-Case-Priorisierung bis hin zum langfristigen Lifecycle-Management.
„Der PoC ist nicht das Problem. Das Fehlen eines Frameworks zur Skalierung ist es."
Die fünf Muster, die wir in scheiternden Projekten sehen
Bevor wir zur Lösung kommen, lohnt es sich, die Versagensmuster klar zu benennen. Das sind keine hypothetischen Szenarien — es sind Muster, denen wir branchenübergreifend immer wieder begegnen: in der chemischen Verarbeitung, in der Pharmafertigung und in der diskreten Produktion.
Das Framework: 6 Säulen, die alles tragen
Was folgt, ist keine Methodik im Beratungssinne — keine Abfolge von Schritten, die man abarbeitet und dann vergisst. Es ist ein Satz struktureller Prinzipien, die gleichzeitig aktiv sein müssen. Man sollte sie weniger als Roadmap verstehen, sondern eher als tragende Wände: Entfernt man auch nur eine davon, wird die gesamte Struktur schwächer.
Die interaktive Grafik unten zeigt, wie die Säulen miteinander und mit dem Gesamtökosystem zusammenhängen. Ein Klick auf eine Säule zeigt die detaillierte Begründung dahinter.
Transparenz
Rückverfolgbarkeit
Maintenance
Effizienz
Reporting
Wo anfangen: die Reifegrad-Einschätzung
Eine der häufigsten Fragen, die wir von Kunden hören, lautet: „Mit welcher Säule fangen wir zuerst an?" Die ehrliche Antwort ist: Das hängt davon ab, wo Sie auf Ihrer Industrial-Informatics-Reise gerade stehen. Das Tool unten hilft dabei, den Ausgangspunkt zu bestimmen.
Praktische Konsequenzen: Was sich dadurch verändert
Die Einführung dieses Frameworks bedeutet nicht, von vorn anzufangen. In den meisten Projekten, die wir begleiten, ist der erste Schritt eine ehrliche Bestandsaufnahme: Welche Säulen sind bereits teilweise vorhanden — und welche fehlen vollständig?
Für Unternehmen in regulierten Branchen — Pharma, Chemie, Lebensmittel und Getränke — sind die Säulen 03 und 06 (Kostenbegründung und Lifecycle-Management) häufig am wenigsten entwickelt. Der Druck, schnell Use Cases zu liefern, verdrängt konsequent die Investition in nachhaltige Architektur.
Für Fertigungsunternehmen, die noch früher in ihrer Digitalisierungsreise stehen, ist Säule 05 (Vermeidung von Organisationssilos) typischerweise der entscheidende Engpass. Die IT/OT-Trennung ist kein technisches Problem, das sich durch den Kauf einer besseren Integrationsschicht lösen lässt. Sie erfordert Organisationsarbeit: gemeinsame KPIs, gemeinsame Workshops und explizite Dateneigentümerschaftsvereinbarungen.
„Industrielle Datenplattformen scheitern, wenn Ingenieure für Ingenieure bauen. Endanwender in den Designprozess einzubinden ist keine Soft Skill — es ist eine technische Anforderung."
Säule 02 — die Vermeidung von Analyse-Lähmung — verdient besondere Aufmerksamkeit, weil sie dem Instinkt technisch exzellenter Teams widerspricht. Die Versuchung, die perfekte Architektur zu entwerfen, bevor irgendetwas deployed wird, ist real und verständlich. Unsere Erfahrung ist eindeutig: Teams, die klein anfangen, in Wochen statt Monaten Mehrwert nachweisen und kontinuierlich iterieren, übertreffen Teams, die auf Perfektion planen — jedes Mal.
Das ist kein Argument gegen rigorose Architektur. Das Fundament muss solide sein. Aber es ist ein Argument dafür, „die Architektur, die von Anfang an stimmen muss" von „den Use Cases, die zunächst grob sein dürfen und später verfeinert werden" zu trennen.
Die Rolle von inmation und dem Data Fabric
Am technischen Fundament dieses Frameworks steht inmation als Process Historian und Industrial Data Fabric Engine. Der Grund, warum wir unsere Industrial-Informatics-Praxis rund um inmation aufgebaut haben, ist genau dieser: inmation löst das Infrastrukturproblem, von dem alle anderen Schichten abhängen — ein einziger, einheitlicher, echtzeitfähiger und historischer Datenspeicher, der OT-Ebenen überspannt und Daten für IT-Systeme verfügbar macht, ohne maßgeschneiderte Punkt-zu-Punkt-Integrationen.
Das Industrial Data Fabric ist nicht nur eine Datenspeicherschicht. Es ist die Infrastruktur, die Self-Service ermöglicht (Säule 04), einheitliches Lifecycle-Management unterstützt (Säule 06) und das Bindegewebe zwischen OT-Protokollen und ERP-Systemen bereitstellt, das verhindert, dass Organisationssilos (Säule 05) zu dauerhaften technischen Grenzen werden.
Über dem Data Fabric liegt die Visualisierungs- und Analyseschicht — der Ort, an dem rohe Prozessdaten zu etwas werden, auf das ein Anlagenbediener, ein Qualitätsingenieur oder ein Werkleiter tatsächlich reagieren kann. Das bedeutet zweckgebundene Dashboards für OEE-Monitoring, Echtzeit-Alarmanalyse, Batch-Reporting und Compliance-Dokumentation. Der Unterschied ist entscheidend: In inmation gespeicherte Daten sind nur dann wertvoll, wenn sie zugänglich, interpretierbar und mit den Entscheidungen verknüpft sind, die auf dem Shopfloor und in der Führungsetage getroffen werden müssen.
Eine Anmerkung zu Zeiträumen: in Jahrzehnten denken
Säule 01 fordert Unternehmen dazu auf, in Jahrzehnten statt in Geschäftsjahren zu denken. Das ist in industriellen Umgebungen echte Herausforderung, wo Investitionszyklen in Drei-bis-Fünf-Jahres-Bändern laufen und IT-Budgets jährlich neu aufgesetzt werden.
Was das praktisch bedeutet, ist nicht, jede Entscheidung auf zwanzig Jahre hinaus zu planen, sondern dass die Architekturentscheidungen von heute — welcher Historian, welches Integrationsmodell, welche Dateneigentümerschaftsstruktur — Sie nicht in fünf Jahren in eine Sackgasse führen. Wir haben Unternehmen erlebt, die gesamte Dateninfrastrukturschichten ersetzt haben, weil die ursprünglichen Entscheidungen auf den aktuellen Use Case statt auf die Entwicklungsrichtung optimiert waren.
Eine langfristige Roadmap muss nicht detailliert sein, um nützlich zu sein. Was sie leisten muss, ist eine klare Richtung: Wohin entwickelt sich die Organisation in puncto Automatisierungsreife, welche Datenfähigkeiten werden benötigt, wenn sie dort ankommt, und welches Fundament muss jetzt vorhanden sein, damit diese Zukunft ohne vollständigen Neuaufbau erreichbar ist.
Bereit, Ihren Framework-Reifegrad einzuschätzen?
Sprechen Sie mit unserem Industrial-Informatics-Team bei der cts Group. Wir erarbeiten gemeinsam mit Ihnen, welche Säulen bereits vorhanden sind — und wo die kritischen Lücken liegen.
