Warum MES-Projekte scheitern — und es meistens nichts mit dem MES zu tun hat
Wenn ein Datenprojekt in der Pharma scheitert — woran liegt es dann wirklich? Aus meiner Erfahrung fast nie an der Technik. Ein paar Muster, ein paar Frühsignale, und die ehrliche Frage, wie die eigenen Projekte dabei abschneiden.
Scheitert ein Projekt rund um ein MES (Manufacturing Execution System — die Software-Ebene zwischen Produktionssteuerung und Unternehmenssystemen) oder eine IDF (Industrial Data Fabric — eine Architektur, die fragmentierte Produktionsdaten über OT und IT hinweg zu einer nutzbaren, kontextualisierten Schicht verbindet), fällt der Blick zuerst auf die Plattform, die Schnittstelle, das Datenmodell. Meine Erfahrung nach vielen dieser Projekte ist eine andere: Der Fehler sitzt selten in der Technik.
Die meisten scheitern nicht, weil Daten fehlen. Sie scheitern, weil Organisationen anfangen, Daten zu sammeln, bevor sie definiert haben, wofür. Rohdaten werden gestreamt — ohne Kontext, ohne Verantwortung, ohne klaren Weg zum operativen Wert.
Das klingt kontraintuitiv. Wer viel Geld in eine Plattform steckt, vermutet das Problem eher bei der Datenmenge oder der Schnittstelle. Vielleicht sehen Sie das aus Ihren eigenen Projekten anders — umso spannender das Gespräch. Ich beschreibe hier, was mir Projekt um Projekt begegnet.
Die Daten sind längst da
In fast jedem Werk existieren die wertvollen Daten bereits — verteilt über MES, Historian, ERP (Enterprise Resource Planning), LIMS (Labor-Informations- und Management-System) und die Automatisierungssysteme. Das Problem ist nicht ihre Abwesenheit.
Das Problem ist, dass sie in Silos liegen, unterschiedlichen Strukturen folgen und keine gemeinsame Bedeutung haben. Verschiedene Standorte nutzen verschiedene Namenskonventionen und Praktiken. Lokale Teams haben über Jahre pragmatische Lösungen gebaut, die für ihre Linie funktionieren — aber nicht über Anlagen, Funktionen und Standorte skalieren. Dieselbe geschäftliche Frage braucht dann Daten aus mehreren, nicht verbundenen Systemen.
Und genau hier wird es schwierig — nicht am Punkt der Konnektivität, sondern am Punkt des belastbaren Geschäftskontexts. Eine IDF ist keine Technik-Trophäe. Sie soll Silos aufbrechen und Daten standortübergreifend in Echtzeit nutzbar machen. Erfolgreiche Initiativen bauen nicht auf Datenintegration allein, sondern darauf, aus fragmentierten Produktionsdaten belastbaren Kontext, Self-Service und bessere Entscheidungen zu machen.
Fünf Muster, an denen Projekte scheitern
Fünf davon sehe ich immer wieder. Vielleicht erkennen Sie das eine oder andere aus dem eigenen Haus wieder.
1. Kein klares Warum
Das Projekt startet mit dem Vorsatz, „Daten zu sammeln" — nicht mit einem konkreten Schmerzpunkt auf dem Shop Floor, nicht mit einer geschäftlichen Frage, nicht mit einer definierten Kennzahl. Damit wird die IDF zur Plattform-Initiative statt zur Wert-Initiative. Was zuerst kommen sollte: opake OEE (Overall Equipment Effectiveness — die Gesamtanlageneffektivität), manuelle Schichtprotokolle, langsames Qualitätsreporting, Altsysteme ohne ERP-Anbindung, fehlende standortübergreifende Sicht.
2. Rohdaten ohne Kontext
Daten werden gestreamt, aber nicht erklärt. Prozesswerte sind verfügbar, aber nicht mit Equipment, Batch, Prozessschritt oder geschäftlicher Bedeutung verknüpft. Der Nutzer bekommt mehr Daten, aber nicht mehr Einsicht. Wert entsteht erst, wenn Daten in ihrer industriellen Realität strukturiert werden — und Kontextualisierung muss früh beginnen, nicht erst, wenn die Plattform schon steht.
3. Enterprise-Komplexität unterschätzt
Ein Pilot funktioniert lokal. Die Skalierung über mehrere Standorte ist ungleich schwerer. Globale IT-Standards und lokale OT-Realitäten passen nicht automatisch zusammen. Datenintegrität muss über den gesamten Lebenszyklus gesichert sein. Und Governance muss sich von lokalen Pilotregeln zu globalen IDF-Regeln entwickeln. Ohne diese Entwicklung wird die Plattform zur nächsten Altlast.
4. Die Umsetzung erreicht die Teams nicht
Die Architektur wird geliefert — aber der Arbeitsalltag ändert sich nicht. Operatoren pflegen die Schichtübergabe weiter in Excel. Qualitätsberichte dauern weiter zu lange. Trends werden weiter manuell abgefragt. Die IDF wird nicht Teil der täglichen Entscheidungen. Echter ROI beginnt erst, wenn Kollegen die Werkzeuge aktiv nutzen, um alltägliche Reibung in der Produktion zu lösen.
5. Kein Weiterentwicklungspfad
Der erste Use Case ist umgesetzt — aber es gibt keinen Prozess, neue Ideen aufzunehmen. Erkenntnisse werden nicht geteilt, Erfolge und Stolpersteine nicht kommuniziert. Die Plattform stagniert. Eine erfolgreiche IDF braucht eine Ideen-Pipeline und sichtbare interne Kommunikation, damit sie sich weiterentwickelt.
Zur Ehrlichkeit gehört auch die Gegenprobe: Ja, es gibt Projekte, in denen die Technik tatsächlich der Engpass ist — eine Altanlage ganz ohne Schnittstelle etwa. Die gibt es. Aber sie sind die Ausnahme. In den meisten Fällen ist das Technische lösbar, und das eigentliche Ringen beginnt woanders. Wo würden Sie widersprechen?
Wann sich entscheidet, ob es funktioniert
Sehr früh. Meist deutlich früher als erwartet — oft schon in den ersten Workshops und in der Scoping-Phase. Nicht, weil sich jede Herausforderung vorhersagen ließe, sondern weil sich beurteilen lässt, ob ein Projekt das Fundament hat, um Herausforderungen zu überstehen und Wirkung zu erzeugen.
Denn jedes größere Projekt läuft in Probleme: Datenqualität, technische Abhängigkeiten, Stakeholder-Konflikte, Ressourcenengpässe, wechselnde Prioritäten. Das ist normal. Diese Probleme entscheiden nicht über Erfolg oder Misserfolg. Das Fundament tut es.
Die vier Frühindikatoren
Klarer Scope, gemeinsames Verständnis
Einigkeit über Ziele und Prioritäten, über die zentralen Geschäftsprobleme und die Erfolgskriterien — und darüber, was ausdrücklich nicht Teil des Projekts ist.
Management-Rückhalt
Sichtbare Unterstützung der Führung, schnelle Entscheidungen, aktives Ausräumen von Blockaden und Rückendeckung, wenn Prioritäten kollidieren.
Realismus bei den Daten
Ein ehrlicher Blick auf die aktuelle Datenqualität, Transparenz über Lücken und Grenzen, Anerkennung der Risiken — statt Wunschdenken.
Das richtige Team, früh dabei
Die relevanten Perspektiven sitzen von Anfang an am Tisch — nicht erst, wenn die Architektur steht.
Der vierte Punkt entscheidet oft mehr als die anderen drei. „Das richtige Team" heißt konkret, dass jede Perspektive vertreten ist, die ein Datenprojekt in der Pharma braucht:
| Rolle | Bringt ein |
|---|---|
| Business | Versteht Geschäftswert, Prioritäten und die erwarteten Ergebnisse. |
| Fertigung | Weiß, wie die Produktion im Alltag tatsächlich läuft. |
| Qualität | Kennt Compliance, Validierung und regulatorische Anforderungen. |
| IT | Verantwortet Enterprise-Architektur, Sicherheit und Langzeitbetrieb. |
| OT | Kennt Equipment, Automatisierung und die Realität auf dem Shop Floor. |
| Technischer Umsetzungslead | Trägt die End-to-End-Verantwortung für Plattform und technische Ausführung. |
| Projekt-/Strategielead | Sorgt für Stakeholder-Alignment, Steuerung, Adoption und Entscheidungen auf Führungsebene. |
Kommt Ihnen einer dieser Sätze aus einem Kickoff bekannt vor? Sie zeigen früh, dass das Fundament noch fehlt:
- „Bauen wir erst mal die Plattform."
- „Die Datenqualität lösen wir später."
- „Jeder soll auf alles zugreifen können."
- „Die Use Cases definieren wir nach der Implementierung."
Was die stärksten Projekte anders machen
Sie starten mit einem konkreten Problem auf dem Shop Floor, nicht mit der Plattform. Sie definieren das Warum, bevor sie über Technik sprechen. Sie verbinden Prozessdaten mit Geschäftszielen und legen Rollen und Verantwortung fest, bevor das erste Datenpaket verschickt wird. Sie kontextualisieren vom ersten Tag an — und nutzen Standards wie ISA-95, um OT und Unternehmenssysteme zu verbinden. Governance behandeln sie als lebendes Betriebsmodell, nicht als einmaliges Setup.
Die stärksten Projekte sind nicht die mit den wenigsten Problemen. Es sind die mit dem stärksten Fundament. Viele Projekte werden gewonnen oder verloren, bevor die erste Schnittstelle steht.
Eine technisch erfolgreiche Implementierung ist ein wichtiger Meilenstein — und kann trotzdem ein geschäftlicher Misserfolg sein. Große technische Herausforderungen lassen sich meist lösen. Organisatorische Unklarheit ist später viel schwerer zu reparieren.
Vieles davon ist bewusst eine These, keine Formel. Jedes Werk ist anders, und ich lerne in jedem Projekt dazu, wo sie an ihre Grenzen stößt. Deshalb interessiert mich weniger, ob Sie mir zustimmen — sondern wo Sie in Ihren eigenen Projekten das Fundament schon stehen sehen und wo noch nicht. Genau darüber möchten wir in Berlin sprechen.
Industrial Data Fabric: Was sie ist, was sie kann — und was sie wirklich gebracht hat
Von der technischen Seite betrachtet: was hinter einer Industrial Data Fabric steckt und woran sich ihr Nutzen messen lässt.
Zum Beitrag →Wir sprechen darüber auf der Pharma MES Europe 2026
cts Group und Xenium AG zeigen in Berlin, warum das Fundament über den Erfolg entscheidet — und wie Strategie, Umsetzung und Adoption zusammenkommen.
Termin am Stand vereinbaren
