Praxiswissen · Praxisleitfaden

Validierungsmasterplan und Systemplan sinnvoll trennen

Für jedes neue System entsteht ein ausführlicher Plan. Trotzdem bleiben Prioritäten, gemeinsame Regeln und Zuständigkeiten unklar. Häufig fehlen die Entscheidungen zwischen Unternehmensportfolio und Einzelprojekt. Ein sinnvoller Masterplan und ein konkreter Systemplan schließen genau diese Lücke.

Daniel Herrmann
Compliance-Experte für Life Sciences
Fachlicher Stand: 7 Minuten Lesezeit
Inhaltsverzeichnis

Das Wichtigste vorab

Was unterscheidet Validierungsmasterplan und Systemvalidierungsplan?

Der Validierungsmasterplan oder eine geeignete gleichwertige Dokumentation beschreibt die übergreifende Strategie, Zuständigkeiten und Organisation der Qualifizierungs- und Validierungsaktivitäten. Der Systemvalidierungsplan konkretisiert Scope, Risiken, Nachweise, Kriterien und Ablauf für ein bestimmtes Systemvorhaben. Beide Ebenen müssen zusammenpassen. Eine bestimmte Dateibezeichnung ersetzt keine vollständige Planung; dreißig wiederholte Grundsatzseiten helfen dem Einzelprojekt selten.

Zwei Planungsebenen mit unterschiedlichen Entscheidungen

Annex 15 beschreibt die Organisation von Qualifizierungs- und Validierungsaktivitäten in einem Validierungsmasterplan oder einer geeigneten gleichwertigen Dokumentation. Für computergestützte Systeme wird der spezifische Rahmen aus Annex 11 einbezogen. Die konkrete Dokumentenarchitektur richtet sich nach Qualitätssystem, Umfang und Komplexität. Daraus folgt weder ein pauschaler Verzicht auf übergreifende Planung noch die Pflicht, für jedes IT-Projekt denselben umfangreichen Mastertext neu zu erstellen.

Die übergreifende Ebene beantwortet: Wie steuern wir das Portfolio und nach welchen Regeln arbeiten wir? Die Systemebene beantwortet: Was weisen wir für diesen Einsatz und diesen Stand nach? Prüfen Sie vorhandene Qualitätsdokumente, bevor eine neue Datei entsteht. Ein gut integriertes Konzept kann mit Verweisen arbeiten. Die Informationen müssen jedoch auffindbar, aktuell und verantwortlich genehmigt sein. Ein verstreuter Satz unverbindlicher Notizen ist keine gleichwertige Planung.

Quellen: [1] [2]

Was auf die übergreifende Ebene gehört

Beschreiben Sie Organisation, Rollen, grundlegende Strategie und Steuerung der relevanten Aktivitäten. Ergänzen Sie den Zusammenhang zum Systeminventar, zur Risikobewertung, Änderungssteuerung und regelmäßigen Überprüfung. Gemeinsame Regeln zu Lieferantennachweisen, Dokumentenlenkung und Abweichungen können zentral definiert werden. Der Masterplan sollte Orientierung liefern, ohne jedes technische Detail eines Einzelprojekts zu wiederholen.

Für mehrere Systeme werden Abhängigkeiten und Prioritäten sichtbar gemacht. Ein ERP-Wechsel kann Laborintegration, Lagerprozess und Archivierung betreffen. Die Planung muss erkennen lassen, welche Entscheidungen zusammengehören. Berücksichtigen Sie Kapazitäten und Verantwortlichkeiten. Eine Liste aller Systeme ohne Reihenfolge und nächsten Schritt ist eher Inventar als steuernder Plan. Die konkrete Form ist eine methodische Entscheidung und muss im Unternehmen ausführbar bleiben.

Quellen: [1] [3]

Was der Systemvalidierungsplan konkretisieren muss

Der Systemplan beschreibt den vorgesehenen Einsatz, Systemgrenzen, relevante Risiken, Nachweisstrategie und Akzeptanzkriterien. Er legt fest, welche Lieferantenunterlagen genutzt, welche eigenen Prüfungen ausgeführt und wie Ergebnisse bewertet werden. Ergänzen Sie Verantwortliche, Voraussetzungen und Übergang in den Betrieb. Ein Projektterminplan allein beantwortet diese fachlichen Fragen nicht, kann aber kontrolliert mit dem Validierungsplan verbunden sein.

Verweisen Sie auf übergreifende Regeln, statt sie unverändert zu kopieren. Beschreiben Sie die projektspezifischen Entscheidungen und begründeten Abweichungen. Bei einer konfigurierten SaaS-Anwendung können andere Nachweise angemessen sein als bei eigener Software. Die gewählte Strategie muss zu tatsächlicher Komplexität und Risiko passen. Halten Sie außerdem fest, welche Bedingungen vor Test, vor Nutzung und für den späteren Betrieb erfüllt sein müssen.

Quellen: [2] [1]

Konstruiertes Beispiel: ERP, Excel und Archiv im Portfolio

Im Beispiel plant ein Unternehmen die Einführung eines ERP, die Überarbeitung kritischer Excel-Berechnungen und die Stilllegung eines alten Archivs. Die übergreifende Planung legt gemeinsame Rollen, Prioritäten und Regeln fest. Der ERP-Systemplan beschreibt die konkreten Geschäftsprozesse und Schnittstellen. Die Excel-Nachweise behandeln ihre Berechnungs- und Versionsrisiken. Das Archivvorhaben prüft die spätere historische Recherche. Kein einzelner Systemplan soll diese unterschiedlichen Fragen pauschal erschlagen.

Eine wichtige Abhängigkeit lautet: Das alte Archiv darf erst beendet werden, wenn der benötigte Zugriff im Zielkonzept nachgewiesen ist. Das ERP-Projekt benötigt frühzeitig bestimmte Stammdaten und Entscheidungen. Die folgende Matrix ist eine eigene Arbeitshilfe. Sie zeigt, wie gemeinsame Strategie und spezifische Umsetzung verbunden werden können. Die genannten Vorhaben und Reihenfolgen sind konstruiert; sie stellen keine allgemeine gesetzliche Priorisierung dar.

Eigene Arbeitshilfe: Konstruiertes Beispiel: ERP, Excel und Archiv im Portfolio
EntscheidungÜbergreifende EbeneSystem- beziehungsweise Vorhabenebene
VerantwortungRollenmodellBenannte Verantwortliche
PrioritätPortfolio und AbhängigkeitenKonkreter nächster Schritt
NachweiseGrundsätze und ÜbernahmeverfahrenAusgewählte Prüfungen und Kriterien
AbweichungBewertungs- und EskalationsregelKonkreter Befund mit Auswirkung
BetriebGemeinsame MindestprozesseSystemspezifische Durchführung
AbschlussGovernance und ReviewBegründete Nutzungsentscheidung

Quellen: [2]

Unternehmensziele mit Complianceentscheidungen verbinden

Ein Plan sollte erklären, welchen betrieblichen Zweck das Vorhaben erfüllt: System verfügbar machen, Wissen im Team erhalten, Nachweise schneller finden oder einen geordneten Systemwechsel ermöglichen. Diese Ziele unterstützen eine sinnvolle Reihenfolge und Ausgestaltung. Sie ersetzen jedoch keine notwendigen Qualitäts- und Datenkontrollen. Ein Termin- oder Kostenziel darf ein unvertretbares Risiko nicht legitimieren.

Auch ein Behördenfinding wird in diesen Zusammenhang eingeordnet. Zuerst werden erforderliche Sofortmaßnahmen und verbindliche Fristen bearbeitet. Danach werden Ursache, ähnliche Schwachstellen und strategisch passende Verbesserung betrachtet. Eine isolierte zusätzliche SOP kann das Symptom dokumentieren, ohne den Prozess wirksam zu verbessern. Der Plan verbindet deshalb Befundbearbeitung mit nachhaltigen Verantwortlichkeiten und umsetzbaren Regeln. Die konkrete Behördenantwort und deren Fristen werden gesondert anhand des tatsächlichen Falls bewertet.

Quellen: [3] [2]

Schlanke Dokumentenarchitektur statt Wiederholung

Ordnen Sie jede Information einem führenden Ort zu. Die zentrale Regel zur Testabweichung muss nicht in jedem Systemplan vollständig wiederholt werden. Der Systemplan nennt den passenden Verweis und die projektspezifischen Ergänzungen. So entstehen weniger widersprüchliche Fassungen. Prüfen Sie allerdings, ob der Leser mit dem Verweis tatsächlich arbeiten kann und ob die referenzierte Regel zum geplanten Vorgehen passt.

Schlank bedeutet entscheidungsfähig. Eine kurze Tabelle kann Scope, Verantwortlichen, Nachweis und Kriterium klarer verbinden als viele Seiten allgemeiner Definitionen. Fehlende Entscheidungen dürfen aber nicht mit dem Hinweis auf Pragmatismus verschwinden. Fragen Sie im Review: Was kann das Team nach der Lektüre konkret tun, und welche wesentliche Frage bleibt offen? Die Seitenzahl ist weder Qualitätsnachweis noch geeignete pauschale Obergrenze.

Quellen: [2] [4]

Änderungen, Restpunkte und Freigaben nachvollziehbar halten

Ein Plan entwickelt sich mit dem Projekt. Änderungen an Scope, Risiken oder Nachweisen werden kontrolliert bewertet. Bewahren Sie den maßgeblichen historischen Stand, damit später verständlich ist, welche Strategie für die ausgeführten Tests galt. Eine nachträglich umgeschriebene Planung darf nicht vortäuschen, dass alle Entscheidungen schon vor der Durchführung vorlagen. Abweichungen und begründete Anpassungen bleiben transparent.

Legen Sie die Bewertung offener Punkte und zuständige Entscheidung fest. Ein administrativer Restpunkt und ein kritischer Funktionsmangel sind nicht gleich zu behandeln. Annex 15 beschreibt unter bestimmten Bedingungen einen begründeten Übergang zur nächsten Qualifizierungsstufe; daraus folgt keine pauschale Erlaubnis zur produktiven Nutzung trotz unvertretbarer Risiken. Die konkrete Nutzungsentscheidung berücksichtigt Anforderungen, Ergebnisse und wirksame Betriebsbedingungen.

Quellen: [2] [1]

Steuerungsfähigkeit im Betrieb erhalten

Der Masterplan beziehungsweise das übergreifende Konzept wird mit Portfolioänderungen und relevanten Erfahrungen gepflegt. Der Systemplan geht in kontrollierte Betriebsinformationen und die Abschlussbewertung über. Zuständigkeiten für Änderung, Störung, Zugriff, Review und Stilllegung bleiben erhalten. Ohne diese Übergabe endet die Planung oft mit dem Projektteam, während der Betrieb die eigentlichen Entscheidungen neu erarbeiten muss.

Bewerten Sie die Wirkung anhand praktischer Fragen: Sind kritische Systeme priorisiert, Nachweise auffindbar und Entscheidungen rechtzeitig getroffen? Werden wiederkehrende Lücken tatsächlich reduziert? Eine hohe Zahl abgeschlossener Dokumente kann hilfreich sein, sagt allein aber wenig über Prozessqualität aus. Gute Planung verbindet strategische Richtung und konkrete Umsetzung. Sie ermöglicht dem Team, notwendige Nachweise gezielt zu erzeugen und dauerhaft verantwortlich zu nutzen.

Quellen: [2] [3]

Häufige Fragen zu Validierungsmasterplan für Computersysteme

Ist ein Validierungsmasterplan immer eine separate Datei?

Annex 15 sieht einen VMP oder geeignete gleichwertige Dokumentation vor. Die konkrete Struktur hängt vom Qualitätssystem und Umfang ab. Vorhandene Dokumente können zusammenwirken, wenn Strategie, Zuständigkeiten und Organisation nachvollziehbar abgedeckt sind. Ein anderer Dateiname allein macht die Planung weder ausreichend noch unzureichend.

Quellen: [1]

Kann der Systemvalidierungsplan den Masterplan ersetzen?

Ein Einzelplan beantwortet zunächst die Fragen eines konkreten Systems. Übergreifende Organisation, Prioritäten und gemeinsame Regeln können damit unvollständig bleiben. Prüfen Sie beide Ebenen. Bei kleinem Umfang kann eine integrierte Dokumentation geeignet sein, sofern die erforderlichen Entscheidungen klar und vollständig erkennbar sind.

Wie lang sollte ein Systemvalidierungsplan sein?

So lang wie für Scope, Strategie, Verantwortlichkeiten und überprüfbare Entscheidungen nötig. Verweisen Sie auf passende zentrale Regeln und beschreiben Sie projektspezifische Punkte. Eine feste Seitenzahl ist kein Qualitätsmaßstab. Viel allgemeiner Text kann ebenso ungeeignet sein wie eine kurze Liste ohne Akzeptanzkriterien.

Gehören Unternehmensziele in die Validierungsplanung?

Ja, als Kontext für sinnvolle Ausgestaltung, Prioritäten und betrieblichen Nutzen. Sie ersetzen keine erforderlichen Qualitätskontrollen. Verbinden Sie beispielsweise Systemeinführung, Wissenstransfer und Archivzugriff mit den notwendigen Nachweisen. Termin- und Kostenziele dürfen unvertretbare Risiken nicht rechtfertigen.

Wie wird ein Behördenfinding in den Plan aufgenommen?

Bearbeiten Sie zunächst erforderliche Sofortmaßnahmen und konkrete Fristen. Verbinden Sie anschließend Ursache und nachhaltige Verbesserung mit dem Portfolio. Prüfen Sie ähnliche Systeme und strategische Abhängigkeiten. Eine isolierte Dokumentergänzung sollte nicht als dauerhafte Lösung gelten, wenn der zugrunde liegende Prozess weiterhin ungeeignet bleibt.

Quellen: [3]

Woran erkennt man, dass die Planung im Alltag funktioniert?

An klaren Verantwortlichen, begründeten Prioritäten, rechtzeitig verfügbaren Nachweisen und verständlichen Entscheidungen. Prüfen Sie außerdem die Übergabe in den Betrieb und den Umgang mit Änderungen. Die Anzahl unterschriebener Dokumente allein belegt keine Steuerungsfähigkeit oder nachhaltige Verbesserung.

Quellen & fachlicher Stand

Stand: 14. Oktober 2026. Regulatorische Einordnung und Herstellerfunktionen sind getrennt belegt. Beispiele, Testmatrizen und Vorlagen sind eigene Arbeitshilfen; sie werden für den tatsächlichen Einsatzzweck angepasst.

  1. Europäische Kommission: EU-GMP Annex 15, Qualification and Validation (2015)
  2. Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)
  3. EMA / ICH: Q10 Pharmaceutical Quality System, Step 5 (2008)
  4. Europäische Kommission: EU-GMP Chapter 4, Documentation (2011)

Zuletzt fachlich geprüft am 14.10.2026.

Daniel Herrmann, Daniel Herrmann Consulting

Daniel Herrmann Consulting

Wie wir Sie dabei unterstützen

Daniel Herrmann Consulting verbindet die fachliche Bewertung mit der Arbeit am konkreten System. Im Erstgespräch klären wir Ihren Einsatzzweck, vorhandene Nachweise und den nächsten sinnvollen Schritt.

Ihr Vorhaben besprechenEinblicke in unsere Projektarbeit →