Zusammenfassung
Viele in der EU ansässige Pharmaunternehmen arbeiten nach wie vor mit isolierten Datenmodellen, bei denen Stammdaten, Transaktionsdaten und Prozessverantwortlichkeiten auf einzelne Abteilungen wie Beschaffung, Qualitätssicherung, Fertigung oder Finanzen beschränkt sind. Dieses Modell mag sich zwar organisch entwickelt haben, steht jedoch zunehmend im Widerspruch zu den Realitäten moderner ERP-Systeme, den regulatorischen Anforderungen der EU und datengesteuerten Betriebsmodellen.
ERP-Implementierungen – insbesondere SAP S/4HANA und vergleichbare Tier-1-Plattformen – zwingen Unternehmen dazu, sich einer grundlegenden Frage zu stellen:
Automatisieren wir bestehende Silos oder gestalten wir das Unternehmen rund um End-to-End-Prozesse neu?
In diesem Artikel wird erläutert, wie Pharmaunternehmen eine ERP-Implementierung als Katalysator nutzen können, um von einem silobasierten Datenmodell zu einem prozessgesteuerten Datenmodell überzugehen, das auf Prozessarchitekturen der Stufen 1 bis 6 basiert und mit den GxP-Validierungs-, Datenintegritäts- und EU-Compliance-Anforderungen im Einklang steht.
1. Kontext: Warum ERP-Programme Schwächen des Datenmodells in der Pharmaindustrie aufdecken
ERP-Implementierungen in pharmazeutischen Umgebungen sind aufgrund folgender Faktoren von Natur aus komplex:
- GxP-Validierungsanforderungen (IQ/OQ/PQ)
- Erwartungen an die Datenintegrität (ALCOA+)
- Regulierte Stammdaten (Materialien, Chargen, Lieferanten, Spezifikationen)
- EU-weite Aktivitäten an mehreren Standorten und in mehreren Ländern
- Starke Trennung zwischen Qualität und Betrieb
In siloartigen Organisationen decken ERP-Projekte häufig Folgendes auf:
- Widersprüchliche Stammdatendefinitionen
- Doppelte Datenverantwortung
- Inkonsistente Prozessvarianten
- Manuelle Abstimmung zwischen Systemen
- Hoher Validierungsaufwand aufgrund unkontrollierter Schnittstellen
Ohne eine Auseinandersetzung mit dem zugrunde liegenden Datenmodell laufen ERP-Programme Gefahr, zu teuren Systemmigrationen statt zu Geschäftstransformationen zu werden.
2. Das isolierte Datenmodell in Pharmaunternehmen verstehen
2.1 Was ist ein isoliertes Datenmodell?
Ein isoliertes Datenmodell liegt vor, wenn:
- Jede Abteilung ihre eigenen Stammdaten besitzt und pflegt
- Datenstrukturen organisatorische Grenzen widerspiegeln, nicht Prozesse
- Der Datenaustausch ist begrenzt, manuell oder schnittstellenabhängig
- Die Prozessverantwortung endet an den Abteilungsgrenzen
Typische Beispiele für Silos in der Pharmaindustrie
Abteilung Silo-Datenverantwortung
Beschaffung Lieferantenstamm, Preise, Verträge
Qualität Spezifikationen, Abweichungen, Änderungsprotokolle
Fertigung Stücklisten, Arbeitspläne, Chargen
Lieferkette Prognosen, Bestandsparameter
Finanzen Kostenstellen, Bewertung, GL-Zuordnungen
Jeder Datensatz ist lokal optimiert, aber global nicht aufeinander abgestimmt.
2.2 Warum Silo-Modelle in der Pharmaindustrie bestehen bleiben
Silo-Datenmodelle sind oft das Ergebnis von:
- Historisch gewachsenen Best-of-Breed-Systemlandschaften
- Regulatorischer Vorsicht und Risikovermeidung
- Starker Abteilungsautonomie (insbesondere QA)
- Inkrementellen System-Upgrades statt Neugestaltung
- Validierungsbedenken, die funktionsübergreifende Änderungen einschränken
Diese Strukturen sind zwar verständlich, führen jedoch zu systemischen Ineffizienzen.
2.3 Risiken der Beibehaltung isolierter Datenmodelle während der ERP-Implementierung
Aus ERP-Sicht führen isolierte Datenmodelle zu:
- Komplexen Anpassungen, um „alte Verhaltensweisen anzupassen”
- Übermäßigen Stammdatenvarianten
- Erhöhtem Test- und Validierungsaufwand
- Schwacher End-to-End-Berichterstattung
- Begrenztem Automatisierungspotenzial
Aus regulatorischer Sicht erhöhen sie:
- Risiken für die Datenintegrität
- Auditergebnisse aufgrund unklarer Datenverantwortlichkeiten
- Manuelle Kontrollen und Workarounds
3. Das prozessgesteuerte Datenmodell: Eine strategische Alternative
3.1 Definition: Was ist ein prozessgesteuertes Datenmodell?
Ein prozessgesteuertes Datenmodell organisiert Daten anhand von End-to-End-Geschäftsprozessen und nicht nach Abteilungen.
Wichtige Merkmale:
- Prozesse gehen über organisatorische Einheiten hinaus
- Daten werden einmal erstellt und prozessübergreifend wiederverwendet
- Die Eigentumsverhältnisse werden auf Prozessebene definiert
- Das ERP-System wird zum System der Aufzeichnung und nicht zum Datenaggregator
Abteilungen „besitzen” keine Daten mehr – sie interagieren mit Daten über Prozesse.
3.2 Prozessarchitektur: Stufe 1 bis Stufe 6
Ein robustes prozessgesteuertes Modell basiert auf einer strukturierten Prozesshierarchie:
Stufe 1 – Wertschöpfungskette
- Von der Beschaffung bis zur Bezahlung
- Von der Planung bis zur Produktion
- Von der Bestellung bis zum Zahlungseingang
- Von der Aufzeichnung bis zum Bericht
- Von der Idee bis zur Markteinführung
Ebene 2 – End-to-End-Prozesse
- Purchase to Pay (P2P)
- Fertigungsausführung
- Chargenfreigabe
- Änderungskontrolle
- Finanzabschluss
Ebene 3 – Teilprozesse
- Lieferanten-Onboarding
- Bestellanforderung
- Wareneingang
- Rechnungsprüfung
Ebene 4 – Aktivitäten
- Lieferanten anlegen
- Bestellanforderung genehmigen
- Wareneingangskontrolle durchführen
Ebene 5 – Transaktionen
- SAP ME21N, MIGO, MIRO
- QM-Prüflosanlage
Stufe 6 – Datenobjekte
- Lieferantenstamm
- Materialstamm
- Chargenprotokolle
- Prüfmerkmale
Daten sind das Ergebnis der Prozessausführung – nicht der Präferenzen einer Abteilung.
4. Praktisches Beispiel: Purchase to Pay (P2P)
4.1 Silo-basiertes P2P-Modell
In einer silo-basierten Umgebung
- Die Beschaffung verwaltet die Lieferantendaten
- Die Qualitätssicherung verwaltet die Lieferantenqualifikation separat
- Die Finanzabteilung verwaltet die Zahlungsbedingungen unabhängig
- Die Fertigung verwaltet die Materialverbrauchsregeln
Ergebnisse:
- Doppelte Lieferantendatensätze
- Inkonsistenter Genehmigungsstatus
- Manuelle Abstimmungen
- Prüfungsrelevante Lücken
4.2 Prozessgesteuertes P2P-Modell
In einem prozessgesteuerten Modell:
- Purchase to Pay ist das primäre Konstrukt
- Lieferantenstammdaten unterstützen:
- Beschaffung
- Qualitätsqualifikation
- Finanzabrechnung
- Der Qualitätsstatus ist in den Lieferanten- und Materialstamm integriert
- Die Kontrollen werden über Workflows automatisiert
Ergebnis:
- Einzige Quelle der Wahrheit
- Klare Datenverantwortung
- Reduzierter Validierungsumfang
- Stärkere Compliance
5. ERP als Wegbereiter – nicht als Treiber
Ein häufiger Fehler ist die Annahme, dass ERP-Systeme eine Prozessorientierung schaffen.
In Wirklichkeit
- ERP-Systeme sorgen für Konsistenz
- Sie decken Fehlausrichtungen auf
- Sie belohnen Standardisierung
- Sie bestrafen Fragmentierung
ERP sollte behandelt werden als:
Eine treibende Kraft für Prozessdisziplin – nicht als Workaround-Plattform.
6. Übergangsstrategie: Vom Silo zum Prozess während der ERP-Implementierung
6.1 Phase 1 – Prozessermittlung vor dem Systemdesign
Wichtige Aktivitäten:
- Definition der Prozesse der Stufen 1–3
- Identifizierung der regulatorisch relevanten Prozessschritte
- Einigung auf globale vs. lokale Prozessvarianten
- Zuordnung der aktuellen Datenverantwortung zur zukünftigen Prozessverantwortung
Ergebnisse:
- Prozessarchitektur
- RACI pro Prozess
- Datenverantwortungsmodell
6.2 Phase 2 – Harmonisierung der Stammdaten
Schwerpunkte:
- Materialstamm
- Lieferantenstamm
- Stücklisten und Arbeitspläne
- Qualitätsstammdaten
Grundsätze:
- Ein Objekt, ein Eigentümer
- Ein Erstellungsprozess
- Eine Genehmigungslogik
6.3 Phase 3 – Auf Prozesse abgestimmte ERP-Konfiguration
ERP-Designentscheidungen sollten folgenden Grundsätzen folgen:
- Prozess zuerst
- Konfiguration vor Anpassung
- Standard-Workflows, wo möglich
- Klare Aufgabentrennung
6.4 Phase 4 – Validierung (IQ/OQ/PQ) mit Fokus auf Prozesse
Prozessgesteuerte Modelle reduzieren den Validierungsaufwand durch:
- Reduzierung der Schnittstellen
- Vereinfachung der Testfälle
- Ausrichtung der Tests auf reale Geschäftsabläufe
- Verbesserung der Rückverfolgbarkeit
Die Validierung verlagert sich von Transaktionstests hin zur Prozesssicherung.
7. Regulatorische und EU-spezifische Überlegungen
7.1 Ausrichtung an GxP und Datenintegrität
Prozessgesteuerte Datenmodelle unterstützen:
- ALCOA+-Prinzipien
- Klare Datenherkunft
- Definierte Verantwortlichkeiten
- Automatisierte Kontrollen
7.2 Regulatorische Erwartungen der EU
Relevante Rahmenwerke sind unter anderem:
- EU-GMP Anhang 11
- EU-GMP Kapitel 4 (Dokumentation)
- EMA-Leitlinien zur Datenintegrität
- ISO 9001 / ICH Q10
Prozesstransparenz wird zunehmend erwartet – sie ist keine Option mehr.
8. Häufige Fallstricke und wie man sie vermeidet
Fallstrick Minderung
Automatisierung von Silos Zuerst Prozesse neu gestalten
Übermäßige Anpassung Standard-ERP-Prozesse verwenden
QA-Isolation Qualität in Prozesse einbetten
Lokale Optimierung Globale Prozess-Governance durchsetzen
Späte Datenentscheidungen Daten frühzeitig definieren
9. Rolle des Änderungsmanagements
Prozessgesteuerte Modelle erfordern:
- Kulturellen Wandel
- Wechsel von „meine Daten” zu „unser Prozess”
- Starke Unterstützung durch die Führungskräfte
- Klare Kommunikation der Vorteile
Ohne Change Management lässt sich der technische Erfolg nicht in geschäftlichen Nutzen umsetzen.
10. Warum dies für die langfristige Digitalisierung wichtig ist
Ein prozessgesteuertes Datenmodell ermöglicht:
- Fortschrittliche Analysen
- KI-gestützte Qualitätseinblicke
- Durchgängige Transparenz
- Skalierbare digitale Transformation
- Schnellere Reaktion auf regulatorische Anforderungen
Es macht das Unternehmen über das ERP-Programm hinaus zukunftssicher.
Fazit
Der Übergang von einem isolierten Datenmodell zu einem prozessgesteuerten Datenmodell ist keine Nebentätigkeit – es ist einer der wichtigsten Erfolgsfaktoren für ERP-Implementierungen in EU-basierten Pharmaunternehmen.
Diejenigen, die erfolgreich sind, implementieren nicht nur ERP-Systeme.
Sie gestalten die Arbeitsweise des Unternehmens neu.
Wichtige Erkenntnisse und Empfehlungen
- ERP-Implementierungen decken Schwächen des Datenmodells auf – nutzen Sie dies strategisch
- Siloartige Datenmodelle erhöhen Kosten, Risiken und Validierungsaufwand
- Prozessgesteuerte Datenmodelle passen sich auf natürliche Weise an ERP- und EU-Vorschriften an
- Beginnen Sie mit Prozessen der Stufen 1–3, bevor Sie mit dem Systemdesign beginnen
- Definieren Sie die Datenverantwortung auf Prozessebene, nicht auf Abteilungsebene
- Integrieren Sie Qualität und Compliance in Prozesse, nicht in parallele Systeme
- Behandeln Sie das Änderungsmanagement als Kernaufgabe, nicht als Nebensache
