Ihr Global Validiertes System Verbrennt Geld — Weil Sie Kein Nachfragemanagement Haben

Einführung: Wenn „Go-Live“ erst der Anfang ist

Viele Pharma-Führungskräfte betrachten den Go-Live eines validierten globalen Systems (LIMS, EM, QMS, ERP, MES usw.) immer noch als das Ziel. Das System ist validiert, auf mehrere Standorte ausgerollt, und die Anwender haben Zugang zu einem Ticketing-Tool für „Verbesserungen“ und Probleme. Auf dem Papier ist das Projekt ein Erfolg.

Was in der Realität passiert:

• Jeder Standort beginnt, eigene Verbesserungstickets einzureichen. Das Ticketsystem wird stillschweigend zum de facto globalen Bedarfstool. Niemand stimmt Anforderungen standortübergreifend ab. Niemand bündelt sie in kontrollierten Releases. Niemand sorgt dafür, dass Entscheidungen nachvollziehbar, fair und konform sind.
• Das Ergebnis ist ein langsames Verbrennen von Geld: redundante Arbeit, frustrierte Standorte, politische Konflikte und ein steigendes Risiko, dass Ihr validierter Zustand mehr Fiktion als Fakt ist.
• Dieser Artikel beleuchtet, warum das passiert, wie Regulierungsbehörden darauf schauen und wie ein robustes Demand- und Release-Management für validierte globale Systeme in großen Organisationen (3+ Standorte) aussehen sollte.

1. Das versteckte Problem: Tickets sind kein Demand Management

Die meisten globalen Implementierungsprogramme geben den Fachanwendern ein Ticketing-Tool für Vorfälle und Verbesserungen. Das ist für Break/Fix in Ordnung. Für strategische Change-Kontrolle und Demand ist es eine Falle.

Typisches Muster in großen Organisationen:

• Nach dem globalen Go-Live kann jeder Standort direkt Verbesserungstickets an das globale Systemteam richten.
• Es gibt keinen formalen globalen Demand-Prozess, kein strukturiertes Portfolio und keinen verantwortlichen Demand Manager.
• Das Ticket-Tool wird zur „Wahrheit“ für Demand: Wenn es in Jira/ServiceNow ist, existiert es; wenn nicht, dann nicht.

Dies schafft mehrere strukturelle Probleme:

• Die Standorte haben keinerlei Transparenz: Sie können nicht sehen, welche Anforderungen andere Standorte gestellt haben, ob ähnliche Themen existieren oder ob ein Thema bereits bewertet wird.
• Redundante Problemlösungen: Unterschiedliche Standorte investieren Zeit, Energie und Geld, um dasselbe Problem zu unterschiedlichen Zeitpunkten zu beschreiben und „zu verkaufen“.
• Insellösungen: Das globale Team setzt standortspezifische Verbesserungen ad hoc um, ohne einen harmonisierten Blick auf die globalen Geschäftsanforderungen.
• Überlasteter Product Owner: Ein Product Owner oder technischer Owner wird in eine quasi-politische Entscheiderrolle gedrängt, ohne klaren Auftrag oder Governance.

Aus GMP-Perspektive ist dies mehr als nur ein Effizienzproblem. Jede unkontrollierte oder schlecht begründete Änderung untergräbt Ihren dokumentierten validierten Zustand und die Nachverfolgbarkeit, die die Aufsichtsbehörden nach EU GMP Annex 11 und vergleichbaren FDA-Erwartungen an computergestützte Systeme verlangen. Public Health+1

2. Wie sich das in der Praxis zeigt: Frustration, Politik und CAPAs

Dies sind typische Symptome, die wir in großen, globalen Unternehmen sehen:

2.1. Mehrere Standorte entdecken denselben Schmerz erneut

Beispiel:

• Standort A kämpft mit dem Workflow zur Chargenfreigabe in Ihrem globalen LIMS. Sie reichen ein Ticket ein, um ihre Schwierigkeiten zu erklären, schlagen eine Verbesserung vor und haben mehrere Workshops mit dem globalen Team.
• Drei Monate später meldet Standort C dasselbe Kernproblem aus einem leicht anderen Blickwinkel und durchläuft eine weitere vollständige Runde von Scoping und Begründung.
• Parallel dazu hat Standort B einen lokalen Workaround-Prozess in Excel erstellt, der nun seit Monaten stillschweigend genutzt wird.

Drei Standorte, drei unterschiedliche Anstrengungen, ein zugrunde liegendes Problem. Niemand verknüpft die Punkte, weil es keinen einzelnen Demand Manager gibt, der diese Themen überwacht und bündelt.

2.2. Empfundene „zufällige“ Ablehnungen

Weil der Product Owner oder technische Leiter keinen strukturierten Entscheidungsprozess hat, lehnt er Tickets oft informell ab: zu komplex, nicht nötig, „wir haben keine Kapazität“ oder „das ist ein lokales Problem“.

Was die Standorte sehen:

• Sie investieren Zeit, um einen Bedarf zu dokumentieren.
• Sie erhalten eine kurze Ablehnung ohne klare Begründung.
• Sie erfahren nicht, ob ähnliche Themen von anderen Standorten eingebracht wurden oder ob ihr Problem vielleicht schon im Rahmen eines anderen Changes gelöst wird.

Das führt zu:

• Beschwerden im Hintergrund („Global kümmert sich nicht um uns“).
• Vertrauensverlust in das globale Team und in das System selbst.
• Zunehmenden politischen Spannungen zwischen globaler und lokaler Führung.

2.3. Intransparente Priorisierung

In Wirklichkeit sind manche Standorte und Produkte geschäftskritischer als andere. Das ist in Ordnung. Das Problem beginnt, wenn dies informell gehandhabt und nicht professionell kommuniziert wird.

Wenn Standort X seine Anforderungen schnell akzeptiert und umgesetzt bekommt, während Standort Y monatelang wartet, ohne Erklärung, entsteht bei Y der Eindruck: „Global unterstützt nur den Favoriten.“

2.4. Regulatorische Konsequenzen

Bei Inspektionen konzentrieren sich die Behörden häufig auf:

• Änderungskontrolle und Nachvollziehbarkeit für validierte Systeme.
• Begründungen dafür, warum bestimmte Änderungen durchgeführt oder abgelehnt wurden.
• Nachweise, dass Änderungen für alle betroffenen Regionen risikobasiert beurteilt wurden (z. B. EU- vs. US-Anforderungen an Chargenfreigabe und Dokumentation). U.S. Food and Drug Administration+1

Typische Beobachtungen und CAPAs in diesem Bereich:

• Kein ganzheitlicher Überblick über Änderungen im globalen System.
• Keine dokumentierte Begründung für die Ablehnung geschäftskritischer Verbesserungsanfragen.
• Lokale Workarounds, die nicht in der globalen Validierungsdokumentation abgebildet sind.
• Uneinheitliche Umsetzung regulatorischer Anforderungen über verschiedene Standorte hinweg.

Diese Themen enden oft als CAPAs, in denen genau das gefordert wird, was von Anfang an fehlte: ein strukturiertes, risikobasiertes Demand- und Release-Management-Konzept.

3. Schnelle Selbstdiagnose: Haben Sie tatsächlich Demand- und Release-Management?

Nutzen Sie diese Checkliste als schnellen Realitätscheck. Wenn Sie mehrere Punkte mit „Nein“ oder „Nicht sicher“ beantworten, läuft Ihr globales validiertes System wohl ohne einen echten Demand-Prozess.

Prüfen Sie, was zutrifft:

• Sie können eine einheitliche, konsolidierte Liste globaler Änderungsanfragen für Ihr validiertes System erzeugen, gruppiert nach Themen und Standorten.
• Jede Anfrage hat eine dokumentierte Entscheidung (akzeptiert / abgelehnt / geparkt) und eine kurze, geschäftsverständliche Begründung.
• Die Standorte können zumindest auf Zusammenfassungsebene sehen, welche Anfragen in Prüfung sind und welche bereits entschieden wurden.
• Es gibt eine klare, dokumentierte RACI, die zeigt, wer in jedem Prozessbereich (z. B. Stabilität, Chargenfreigabe, EM-Trending) über Anforderungen entscheidet.
• Regulatorische Auswirkungen (EU vs. US vs. andere Regionen) werden bei kritischen Anforderungen systematisch berücksichtigt.
• Release-Pakete werden proaktiv geplant (z. B. vierteljährlich oder halbjährlich) und den Standorten im Voraus kommuniziert.
• Jedes Release wird von strukturierten Release Notes begleitet, in denen erklärt wird, was sich ändert, warum es sich ändert und welche ursprüngliche Anforderung dies ausgelöst hat.
• Lokale Standorte können ihre lokalen Change-Kontrollaktivitäten auf Basis rechtzeitiger Release-Informationen planen, ohne ständige Ad-hoc-Anrufe beim globalen Team.

Wenn Ihnen mehrere dieser Punkte schwerfallen, wird Ihr System eher über Tickets als über eine Demand- und Release-Strategie gesteuert.

4. Wie „gutes“ Demand Management für validierte globale Systeme aussieht

4.1. Ein benannter, kompetenter Demand Manager

Ein funktionierendes Modell hat immer einen eigenen Demand Manager oder Demand Lead, nicht nur „den Product Owner obendrauf“. Diese Person:

• Überwacht das globale Demand-Backlog und gruppiert Tickets zu Themen.
• Erkennt frühzeitig Duplikate und ähnliche Anforderungen an verschiedenen Standorten.
• Bereitet strukturierte Entscheidungsvorlagen für das Governance-Gremium vor (nicht nur rohe Tickets).
• Kommuniziert Entscheidungen und nächste Schritte standortübergreifend auf transparente und geschäftsgerechte Weise.

Soft Skills sind hier genauso wichtig wie technische Fähigkeiten. Der Demand Manager muss in der Lage sein:

• Mehrere widerstreitende Sichtweisen (5–7 verschiedene Stakeholder, manchmal mehr) zusammenzuführen.
• Zu unterscheiden, was den Standorten mitgeteilt werden muss und was intern bleibt.
• Managementprioritäten in respektvolle, verständliche Botschaften an die Standorte zu übersetzen („Ihre Anfrage ist für Q4 geplant“ statt „Sie sind weniger wichtig“).

4.2. Governance, verankert in der globalen Prozessverantwortung

Entscheidungen über prozessbezogene Verbesserungen dürfen nicht bei einer einzelnen IT- oder Technikperson liegen. Zum Beispiel:

• Änderungen am Stabilitätsworkflow: Der globale Prozessverantwortliche für Stabilität + Business Owner des Systems + Technischer Systemverantwortlicher entscheiden gemeinsam.
• Änderungen für Chargenfreigaben: Globale QA, Regulatory und Supply Chain müssen vertreten sein, um die EMA- und FDA-Anforderungen an Freigabeentscheidungen und Dokumentation angemessen abzubilden. Public Health+1

Diese Governance sollte in einer klaren RACI-/RACI-ähnlichen Matrix dokumentiert und in Ihrem Qualitätssystem verankert sein (z. B. in der globalen SOP zum Lifecycle Management computergestützter Systeme, im Einklang mit GAMP 5 2nd Edition). ISPE+1

4.3. Von Tickets zu Demand-Paketen

Anstatt ein Ticket nach dem anderen umzusetzen, fasst der Demand Manager ähnliche oder verwandte Themen zu Demand-Paketen zusammen, zum Beispiel:

• „Globale Verbesserungen der Chargenfreigabe“
• „Harmonisierung des Stabilitätsworkflows“
• „Erweiterungen im EM-Trending“

Jedes Paket wird bewertet hinsichtlich:

• Globaler Geschäftsauswirkungen über alle Standorte.
• Regulatorischer Auswirkungen (welche Regionen, welche Vorschriften).
• Technischer Machbarkeit und Validierungsaufwand.

Erst dann entscheidet man, welche Pakete in die nächsten Releases einfließen.

4.4. Strukturiertes Release Management

Ein kontrolliertes Release-Konzept für validierte Systeme sollte Folgendes umfassen:

• Release-Planung: ein definierter Rhythmus (z. B. vierteljährlich) mit Luft für dringende Fixes.
• Release Notes: rechtzeitig vor Go-Live an alle betroffenen Standorte verteilt, einschließlich:

• Übersicht über die Änderungen.
• Verweise auf die ursprünglichen Anforderungen.
• Überblick über Prozessauswirkungen.
• Erforderliche Maßnahmen der Standorte (z. B. lokale SOP-Updates, Schulungen).

Validierungsdokumentation: Change Control, Risikoanalyse, aktualisierte Tests, wie es Ihr risikobasierter Validierungsansatz (im Einklang mit GAMP 5 2nd Edition und Annex 11) erfordert. ISPE+1

Richtig gehandhabt werden Releases sowohl zu einem Kommunikationsinstrument als auch zu einem Compliance-Werkzeug. Die Standorte wissen, was kommt, und Inspektoren sehen eine nachvollziehbare Kette von der Anforderung über die Change-Kontrolle bis zum Release.

5. Klarheit in puncto Compliance: Wie FDA und EMA das sehen werden

Aus Sicht der Behörden geht es nicht in erster Linie darum, ob Sie einen Demand Manager haben, sondern darum:

• Wird der validierte Zustand über den gesamten Lebenszyklus des Systems aufrechterhalten?
• Werden Änderungen kontrolliert, begründet und dokumentiert?
• Sind Datenintegrität und Patientensicherheit geschützt, wenn sich das System weiterentwickelt?

Wichtige Referenzen, die ein strukturiertes Demand- und Release-Konzept unterstützen:

• EU GMP Annex 11 — erfordert validierte Anwendungen, qualifizierte Infrastruktur sowie angemessene Change-Kontrolle und Dokumentation über den Lebenszyklus von Computersystemen. Public Health+1
• FDA „Data Integrity and Compliance With Drug CGMP: Questions and Answers“ — betont Nachverfolgbarkeit, Begründung und Kontrolle von Änderungen, die CGMP-relevante Daten beeinflussen. U.S. Food and Drug Administration+1
• ISPE GAMP 5 2nd Edition — propagiert einen Lifecycle- und risikobasierten Ansatz für GxP-Computersysteme, der kritisches Denken und eine strukturierte Governance fördert, um Systeme für ihren vorgesehenen Zweck einsatzfähig zu halten. ISPE+1

Inspektoren achten zunehmend auf:

• Unkontrollierte lokale Workarounds, weil globale Änderungen „zu schwierig“ zu bekommen sind.
• Uneinheitliche Funktionalität oder Kontrollen über mehrere Standorte hinweg, die „dasselbe“ validierte System nutzen.
• Lange, undokumentierte Backlogs von Verbesserungsanfragen ohne klare Entscheidungsbegründungen.

Ein gut definiertes Demand- und Release-Verfahren zeigt, dass:

• Geschäftsanforderungen systematisch erfasst und bewertet werden.
• Änderungen basierend auf Risiko und geschäftlicher Priorität und nicht nach Politik festgelegt werden.
• Entscheidungen und Begründungen dokumentiert, nachvollziehbar und kommuniziert sind.

6. Handeln: Wie Sie Ihr globales Demand- und Release-Management verbessern

Folgend ein praktischer Ansatz für Führungskräfte:

Schritt 1: Erkennen, dass Tickets allein nicht genügen

Machen Sie es im Steuerkreis explizit: „Wir brauchen ein strukturiertes Demand- und Release-Modell für unsere validierten Systeme.“ Ohne diese Entscheidung bleibt alles andere ein Nebenprojekt.

Schritt 2: Erfassen Sie Ihre aktuelle Situation

Fragen Sie Ihr globales Team:

• Wo liegt der aktuelle Backlog? (Tickets, Tabellen, SharePoint-Listen)
• Wie viele Anforderungen sind Duplikate oder ähnlich und kommen von verschiedenen Standorten?
• Welche Entscheidungen wurden von einer Einzelperson ohne formale Governance getroffen?
• Wie oft werden Release Notes an die Standorte geschickt und wie ist deren Qualität?

Schritt 3: Definieren Sie Governance und Rollen

Erstellen oder aktualisieren Sie eine globale SOP, die beschreibt:

• Den Demand-Management-Prozess (vom Ticket bis zur Entscheidung).
• Governance-Gremien und ihre Zusammensetzung (pro Prozessbereich).
• RACI für wichtige Entscheidungsarten (Stabilität, Chargenfreigabe, EM usw.).
• Schnittstellen zwischen globalem und lokalem Change-Management.

Schritt 4: Benennen Sie einen Demand Manager

Wählen Sie eine Person mit ausgeprägten Kommunikations- und Strukturierungsfähigkeiten. Geben Sie ihr:

• Einen klaren Auftrag des Top-Managements.
• Zugriff auf den gesamten Demand-Backlog.
• Die Befugnis, Tickets zu hinterfragen, zu gruppieren und neu zu bewerten, bevor sie ins Governance-Gremium gehen.

Schritt 5: Führen Sie Release-Pakete und Release Notes ein

Einigen Sie sich auf einen praktikablen Release-Rhythmus und beginnen Sie mit schlanken, aber konsistenten Release Notes, die Folgendes enthalten:

• Umfang des Releases.
• Verweise auf die ursprünglichen Anforderungen.
• Geschätzte Prozessauswirkungen.
• Erforderliche lokale Maßnahmen und empfohlene Zeitpläne.

Schritt 6: Integrieren Sie das Ganze in Ihr Validierungsframework

Harmonisieren Sie den neuen Prozess mit Ihrer Validierungsstrategie:

• Aktualisieren Sie Ihre SOP zum Lifecycle computergestützter Systeme, um auf Demand- und Release-Management zu verweisen.
• Passen Sie Test- und Dokumentationsaufwand dem Risiko der Änderung an, wie es GAMP 5 2nd Edition und aktuelle CSA-Ansätze fördern. ISPE+1

Schritt 7: Kommunizieren, kommunizieren, kommunizieren

Erklären Sie schließlich das neue Konzept an Ihre Standorte:

• Was sie erwarten können.
• Wie ihre Anforderungen behandelt werden.
• Wie und wann sie Informationen zu kommenden Releases erhalten.

Sobald die Standorte sich wahrgenommen und informiert fühlen, reduzieren sich politische Spannungen und die Qualität der Anforderungen steigt.

7. Führung und Strategie: Wie Sie aus Demand-Chaos einen strategischen Vorteil machen

Gutes Demand- und Release-Management ist nicht einfach nur „mehr Governance“. Es ist ein strategischer Hebel. Für Führungskräfte bietet ein belastbares Verfahren drei Vorteile:

• Bessere Investitionsentscheidungen: Ein transparenter, konsolidierter Blick auf globale Anforderungen zeigt, wohin Ihr Budget tatsächlich fließen sollte.
• Schnellere, sauberere Rollouts: Wenn Anforderungen harmonisiert und priorisiert sind, profitiert jeder neue Standort beim Onboarding von den Erfahrungen der anderen; Sie vermeiden, dieselbe Lösung immer wieder neu zu bauen.
• Stärkere Compliance: Ein kontrollierter, dokumentierter Lebenszyklus für Ihre globalen Systeme besteht bei Inspektionen, reduziert CAPAs und schützt Ihre Lizenz, am Markt zu agieren.

In vielen Unternehmen tauchen die Kosten für schlechtes Demand Management in keiner einzelnen Budgetzeile auf. Sie verstecken sich in verlorener Zeit, unnötigen Meetings, Nacharbeit und lokalen Workarounds. Führungskräfte, die in diesem Bereich für Struktur sorgen, sehen schnell sowohl qualitative als auch finanzielle Vorteile.

Eine einfache Faustregel: Wenn Ihr globales validiertes System bereits in mehreren Standorten in Betrieb ist und Sie nicht innerhalb weniger Minuten darstellen können, wie der globale Bedarf gesteuert und wie Releases entschieden und kommuniziert werden, haben Sie eine strategische Lücke. Diese zu schließen ist einer der effektivsten Wege, sowohl Compliance als auch geschäftlichen Nutzen zu schützen.

Wenn Sie möchten, könnte der nächste Schritt darin bestehen, diesen Artikel auf ein bestimmtes System (z. B. LIMS/EM, QMS, MES) anzupassen oder anonymisierte Beispiele aus Ihren Takeda- oder anderen Projekterfahrungen einzubauen, um ihn noch konkreter zu machen.