Warum Pharmadaten fragmentiert sind — und was das wirklich kostet
„Everybody needs data. Nobody speaks the same language." Der Satz beschreibt den Alltag in vielen Pharmawerken genauer als jede Statistik. Nicht fehlende Daten sind das Problem, sondern fehlender gemeinsamer Kontext. Warum das so ist — und wo ein Datenprojekt wirklich anfängt.
Wer in ein Pharmawerk kommt und auf die Datenlage schaut, sieht selten ein System. Er sieht viele. Getrennte Linien, einzelne Package Units, Anlagen unterschiedlicher Hersteller mit unterschiedlichen Steuerungen. Jede SPS (speicherprogrammierbare Steuerung, englisch PLC) spricht ihre eigene Sprache. Anders als in der Chemie fehlt meist ein zentrales Prozessleitsystem (DCS, Distributed Control System), das alles zusammenführt.
Was bleibt, ist eine gewachsene, uneinheitliche Datenlandschaft — das logische Ergebnis, wie diese Werke über Jahre entstanden sind.
Wenn Sie das aus Ihrem eigenen Werk wiedererkennen: So sieht es in vielen Werken aus. Und es ist der Ausgangspunkt, an dem sich entscheidet, ob aus Daten je Nutzen wird.
Wie die Fragmentierung entsteht
Anlagen in der Pharmafertigung werden Stück für Stück beschafft, nicht als integriertes Ganzes. Der Fokus im Einkauf liegt auf dem Prozess: Die Maschine muss ihr Produkt zuverlässig herstellen. Datenanbindung war im ursprünglichen Design meist kein Kriterium.
Dazu kommt eine lange Historie. Viele Standorte tragen Jahrzehnte an Technik in sich, gewachsen über einzelne Investitionen. Lokale Teams haben über die Jahre pragmatische Lösungen gebaut, die für ihre Linie funktionieren. Nur skalieren diese Insellösungen nicht über Anlagen, Funktionen und Standorte hinweg.
Der entscheidende Punkt liegt früher, als die meisten denken: Anlagen werden als Produktionsmittel gekauft, nicht als Datenquellen. Niemand fragt beim Kauf: Was wollen wir später mit diesen Daten anfangen? Der Datenkontext wird nachträglich angeschraubt — statt von Anfang an mitgedacht.
Das eigentliche Problem ist nicht, dass Daten fehlen
Die wertvollen Daten sind längst da. Sie liegen im MES (Manufacturing Execution System), im Historian, im ERP (Enterprise Resource Planning), im LIMS (Labor-Informations- und Management-System) und in den Automatisierungssystemen. Das Problem ist nicht ihre Menge.
Das Problem ist, dass sie in Silos liegen, unterschiedlichen Strukturen folgen und keine gemeinsame Bedeutung haben. Verschiedene Standorte nutzen verschiedene Namenskonventionen, Standards und Betriebspraktiken. Dieselbe geschäftliche Frage braucht dann Daten aus mehreren, nicht verbundenen Systemen.
Und genau hier trennen sich die Erwartungen. Fertigung, Qualität, IT und Management sind sich einig, dass Daten wichtig sind. Aber nicht, warum sie wichtig sind. Jede Abteilung definiert Erfolg anders. Jede optimiert auf ein anderes Ziel.
Alle brauchen dieselben Daten — und trotzdem greift jeder ins Leere. Nicht, weil die Daten fehlen, sondern weil niemand dieselbe Sprache spricht. Das ist kein Datenproblem. Es ist ein Kontext- und Abstimmungsproblem.
Machen Sie ruhig einmal die Probe aufs Exempel: Fragen Sie Fertigung, Qualität, IT und Management getrennt, was „gute Datennutzung" für sie konkret bedeutet. Kommen vier verschiedene Antworten, liegt dort das eigentliche Projekt — nicht in der nächsten Schnittstelle.
Warum mehr Daten hier nicht helfen
Die naheliegende Reaktion lautet: einfach alles anbinden, dann haben wir die Daten. Das greift zu kurz. Konnektivität allein erzeugt keinen Wert. Rohdaten ohne Kontext sind Rauschen — nur eben in großem Maßstab.
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. Schlimmer noch: Daten ohne Kontext erzeugen falsche Sicherheit. Man glaubt zu wissen, was passiert — und liegt daneben.
Vor zehn Jahren hat die Industrie alles in Data Lakes gekippt und den Nutzen später gesucht. Damals kostete das Speicher. Heute läuft dasselbe Muster erneut — nur werden statt Speicher jetzt Rechenzeit und KI-Token verbrannt. Erst sammeln, dann fragen wofür: Das war schon damals der falsche Weg.
Wo ein Datenprojekt wirklich anfängt
Nicht auf der Ebene einzelner Datenpunkte. Sondern beim geschäftlichen Kontext, bei der Datenlandschaft und bei den Anwendungsfällen. Bevor über eine Plattform gesprochen wird, stehen vier Fragen:
Erst danach folgt die Bewertung der Datenlage — und die läuft entlang von vier Dimensionen. Sie entscheiden, ob ein Projekt schon starten kann oder ob zuerst eine Grundlage fehlt.
Verfügbarkeit
Welche Daten existieren — und welche nicht? Woher kommen sie, wie fragmentiert ist die Landschaft, wie leicht sind sie zugänglich? Fehlende Daten erzeugen blinde Flecken.
Qualität
Vollständigkeit, Konsistenz, Verlässlichkeit, Rückverfolgbarkeit. Erzählen „gleiche" Daten aus verschiedenen Quellen dieselbe Geschichte? Lässt sich jeder Wert auf seinen Ursprung zurückführen?
Kontext
Zu welchem Batch, welchem Equipment, welchem Prozessschritt gehört ein Wert? Sind Datendefinitionen über Standorte hinweg konsistent? Ohne diesen Bezug bleibt der Wert bedeutungslos.
Governance
Wer besitzt welche Daten, wer verantwortet ihre Pflege? Governance ist kein einmaliges Setup, sondern ein lebendes Betriebsmodell — vom lokalen Pilot bis zur unternehmensweiten Regel.
Was es kostet, diesen Schritt zu überspringen
Projekte, die mit „wir sammeln erst mal Daten" starten, werden zu Plattforminitiativen statt zu Wertinitiativen. Die Architektur wird geliefert — aber der Arbeitsalltag ändert sich nicht. Operatoren pflegen ihre Schichtübergabe weiter in Excel. Qualitätsberichte dauern weiter zu lange. Trends werden weiter manuell abgefragt.
Fehlt zudem ein Weg, aus dem ersten Use Case den nächsten zu machen, stagniert die Plattform. Erkenntnisse werden nicht geteilt, neue Ideen nicht aufgenommen. Am Ende ist die teure neue Datenplattform die nächste Altlast — dieselbe Falle, nur mit modernerer Technik.
Aus der Praxis: Datenqualitätsprobleme lassen sich fast immer in den Griff bekommen. Fehlender Geschäftskontext ist später viel schwerer nachzurüsten. Deshalb gehört die Kontextualisierung an den Anfang — nicht ans Ende, wenn die Plattform längst steht.
Der gemeinsame Nenner
Das Problem ist also selten die Datenmenge. Es ist der fehlende gemeinsame Kontext, die unklare Verantwortung und die fehlende gemeinsame Sprache zwischen OT (Operational Technology, die Technik der Produktion) und IT (Information Technology, die Unternehmens-IT).
Und genau deshalb braucht es zwei Blickwinkel, die sonst selten an einem Tisch sitzen: die technische Grundlage — Konnektivität, OT/IT-Integration, Kontextualisierung — und die organisatorische Richtung — das Warum, die Governance, die Adoption. Fehlt einer der beiden, bleibt die beste Datenplattform ein technisch gelungenes, geschäftlich folgenloses Projekt.
In den nächsten Beiträgen dieser Serie gehen wir den Weg Schritt für Schritt: von der GxP-konformen Anbindung über die Frage, warum Datenprojekte scheitern, bis zu den Fällen, in denen aus verbundenen Daten echte Entscheidungen wurden.
Vielleicht sehen Sie einzelne Punkte aus Ihrer Praxis anders — das ist der Sinn der Sache. Uns interessiert weniger, wer recht behält, als die Frage, wo bei Ihnen die gemeinsame Sprache fehlt. Genau darüber sprechen wir gern in Berlin.
GxP-konform und trotzdem nutzbar: Warum Compliance kein Datenproblem ist
Wie Daten fließen können, ohne validierte Systeme anzufassen — und warum Compliance vor allem eine Frage des Kontexts ist.
Zum Beitrag →Wir sprechen darüber auf der Pharma MES Europe 2026
cts Group und Xenium AG zeigen in Berlin, wie aus fragmentierten Produktionsdaten eine nutzbare Grundlage wird — von der Strategie bis zur laufenden Anlage.
Termin am Stand vereinbaren
