Eine Traceability Matrix – im Deutschen oft Rückverfolgbarkeitsmatrix genannt – beantwortet eine einfache Frage: Wurde jede relevante Anforderung umgesetzt und nachweislich geprüft? So simpel die Frage ist, so aufwendig wird ihre Beantwortung, wenn die Verknüpfungen zwischen Anforderungen, Risikobewertung, Spezifikationen und Prüfprotokollen erst am Projektende rekonstruiert werden müssen. Dieser Beitrag zeigt, wie eine Traceability Matrix aufgebaut ist, wie fein sie sein sollte und wie Sie sie über den Lebenszyklus eines Systems pflegen.
Wozu dient die Traceability Matrix?
Die Matrix ist das Bindeglied der Qualifizierungsdokumentation. Sie verbindet die Anforderungen aus der User Requirement Specification mit den Ergebnissen der Risikoanalyse, den technischen Spezifikationen und den Prüfungen in DQ, IQ, OQ und PQ. Daraus ergeben sich drei Funktionen:
- Vollständigkeitsnachweis: Jede Anforderung hat mindestens einen Nachweis. Das muss nicht immer ein eigener Test sein. Auch eine Prüfung in der DQ oder ein begründet übernommenes Ergebnis aus FAT oder SAT zählt.
- Risikobezug: Es wird sichtbar, dass kritische Anforderungen intensiver geprüft werden als unkritische. Das entspricht dem risikobasierten Ansatz, wie ihn der EU-GMP-Leitfaden in Anhang 15 und GAMP 5 für computergestützte Systeme beschreiben.
- Navigationshilfe: Prüfer, Auditoren und später auch das Betriebspersonal finden über die Matrix schnell den Beleg zu einer bestimmten Anforderung.
Ausdrücklich gefordert ist die Rückverfolgbarkeit in Anhang 11 (4.4): Nutzeranforderungen an computergestützte Systeme sollen über den gesamten Lebenszyklus rückverfolgbar sein. Eine Matrix als Form schreibt kein Regelwerk vor. Sie ist aber der übliche Weg, diese Rückverfolgbarkeit und den Nachweis jeder URS-Anforderung zu zeigen.
Aufbau: die typischen Spalten
Bewährt hat sich eine Struktur, die dem Weg einer Anforderung durch das Projekt folgt:
- URS-ID und Kurzbeschreibung – eindeutig, identisch mit der Nummerierung in der URS.
- Kritikalität oder Risikoklasse – Ergebnis der GMP-Risikoanalyse, z. B. hoch, mittel, gering.
- Verweis auf Funktions- oder Designspezifikation (FS/DS) – wo und wie die Anforderung technisch umgesetzt ist.
- Testfall – Protokoll- und Prüfpunktnummer in DQ, IQ, OQ oder PQ, oder Verweis auf ein begründet übernommenes FAT/SAT-Ergebnis.
- Ergebnis und Status – bestanden, nicht bestanden, offen, mit Verweis auf eine Abweichung.
Je nach Projekt kommen weitere Spalten hinzu, etwa eine Risiko-ID, die Prüfmethode, je Qualifizierungsphase eine eigene Spalte, eine Abweichungsreferenz, ein Verweis auf Lieferantendokumente oder eine Bemerkungsspalte.
In der Praxis haben sich einige Regeln bewährt. Auch eine Anforderung ohne Risikobezug, etwa aus einer SOP, braucht einen Prüfweg. Trifft ein Feld nicht zu, steht dort „N/A“ mit kurzer Begründung statt einer Leerstelle. Die Matrix ist kein Prüfprotokoll: Akzeptanzkriterien und Ergebnisse stehen im Protokoll, die Matrix verweist nur darauf. Die ID-Konventionen für Anforderungen, Risiken und Prüfpunkte werden am besten vorab im Qualitätsplan festgelegt.
Beispiel: Reinraum mit Überwachungssystem
Die folgende Tabelle ist ein fiktives, vereinfachtes Beispiel für einen Reinraumbereich mit HVAC-Anlage und Monitoringsystem:
| URS-ID | Anforderung (kurz) | Risiko | FS/DS | Testfall | Ergebnis / Status |
|---|---|---|---|---|---|
| URS-012 | Differenzdruck zwischen Reinraum und Schleuse gemäß Druckkaskade der URS | hoch | FS-4.2, DS Regelung Zuluft | OQ-07 Differenzdruckmessung; PQ-03 Dauerüberwachung | OQ bestanden; PQ offen |
| URS-018 | Partikelkonzentration im Ruhezustand entspricht der festgelegten Reinraumklasse | hoch | DS Filterauslegung, Luftführung | OQ-11 Partikelmessung „at rest“ | bestanden |
| URS-025 | Alarm bei Unterschreitung des Differenzdruck-Grenzwerts mit Verzögerung und Quittierung | hoch | FS-6.1 Alarmmanagement | OQ-14 Alarmtest | nicht bestanden, Abweichung AB-003 |
| URS-031 | Wand- und Deckenoberflächen glatt, porenfrei und beständig gegen die eingesetzten Desinfektionsmittel | mittel | Raumbuch, DS Ausbau | IQ-05 Sichtprüfung und Materialnachweis | bestanden |
Schon an diesem kleinen Ausschnitt wird der Nutzen sichtbar: Der offene PQ-Punkt und die Abweichung beim Alarmtest fallen sofort auf, und die Kritikalität zeigt, dass beide vor der abschließenden Freigabe geklärt sein müssen. Soll die nächste Qualifizierungsstufe schon vorher beginnen, geht das nach Anhang 15 (2.10) nur als bedingte Freigabe, gestützt auf eine dokumentierte Bewertung, dass die offenen Punkte keinen wesentlichen Einfluss auf die nächste Tätigkeit haben.
Vorwärts und rückwärts lesen
Eine Traceability Matrix sollte in beide Richtungen funktionieren. Vorwärts gelesen zeigt sie, ob jede Anforderung einen Nachweis hat. Rückwärts gelesen zeigt sie, ob jeder Testfall auf eine Anforderung zurückgeht. Diese zweite Richtung wird häufig übersehen. Prüfpunkte ohne Bezug zur URS sind nicht automatisch falsch, sie deuten aber oft auf Anforderungen hin, die nie formal festgelegt wurden, oder auf Prüfaufwand ohne erkennbaren Zweck. Beides sollte bewusst entschieden werden: Entweder wird die Anforderung in der URS nachgetragen, oder der Prüfpunkt entfällt mit Begründung.
Die richtige Granularität
Eine häufige Frage lautet, wie fein die Matrix sein soll. Zu grob – etwa „HVAC-Anlage“ in einer Zeile – verliert sie ihre Aussagekraft. Zu fein – jede Schraube, jedes Kabel – wird sie unübersichtlich und kaum noch pflegbar.
Pragmatisch ist folgender Grundsatz: Eine Zeile pro prüfbarer Anforderung. Enthält eine URS-Anforderung mehrere unabhängige Aussagen, ist das meist ein Hinweis, dass sie in der URS selbst aufgeteilt werden sollte. Für unkritische Anforderungen kann eine Gruppierung sinnvoll sein, solange der Nachweis eindeutig zuzuordnen bleibt.
Pflege über den Lebenszyklus
Eine Traceability Matrix ist kein Abschlussdokument, sondern ein Arbeitsinstrument:
- Projektstart: Anlegen mit URS-IDs und Risikobewertung.
- Design: Ergänzen der FS/DS-Verweise; Lücken zeigen frühzeitig, wo eine Anforderung nicht umgesetzt ist.
- Testplanung: Zuordnen der Testfälle vor Freigabe der Prüfpläne.
- Durchführung: Nachführen von Ergebnis und Status, Verknüpfen von Abweichungen.
- Abschluss: Vollständigkeitsprüfung als Voraussetzung für den Qualifizierungsbericht.
- Betrieb und Changes: Bei jeder Änderung über Change Control prüfen, welche Zeilen betroffen sind, welche Tests wiederholt werden müssen und ob neue Anforderungen hinzukommen. Die Matrix wird versioniert und neu freigegeben.
Gerade der letzte Punkt wird oft vernachlässigt. Eine Matrix, die den Zustand bei Inbetriebnahme zeigt, aber drei Änderungen später nicht mehr stimmt, ist im Audit eher ein Risiko als eine Hilfe.
Werkzeug: Tabellenkalkulation oder Tool?
Für die meisten technischen Qualifizierungsprojekte ist eine gut strukturierte Tabellenkalkulation ausreichend. Sie ist für alle Beteiligten zugänglich, lässt sich filtern und als freigegebenes PDF archivieren. Wichtig sind feste Spaltendefinitionen, eine gesperrte Struktur, eine Versionskennung und eine klare Regel, wer Änderungen vornehmen darf. Wird die Tabellendatei selbst als GMP-Aufzeichnung genutzt, fällt sie unter Anhang 11. Andernfalls wird der freigegebene Stand als PDF archiviert und gilt als maßgeblich.
Ein spezialisiertes Anforderungs- oder Validierungstool lohnt sich eher bei großen Projekten, vielen Schnittstellen oder komplexen computergestützten Systemen. Wird ein solches Tool selbst GMP-relevant eingesetzt, gelten die Anforderungen von Anhang 11 an computergestützte Systeme, darunter die Zugriffskontrolle (12.1) und, je nach Risikobewertung, ein Audit Trail (9).
Typische Fallstricke
- Nachträgliche Erstellung: Die Matrix wird kurz vor dem Bericht zusammengestellt; Lücken lassen sich dann nur noch mit Aufwand schließen.
- Abweichende IDs: URS, Matrix und Protokolle verwenden unterschiedliche Nummerierungen.
- Status „bestanden“ trotz offener Abweichung: Der Status muss die Abweichungslage ehrlich widerspiegeln.
- Pauschale Verweise: „siehe OQ“ statt Protokoll- und Prüfpunktnummer.
- Fehlender Risikobezug: Alle Anforderungen werden gleich behandelt, die Prüftiefe ist nicht begründet.
- Keine Versionierung: Unklar, welcher Stand der Matrix freigegeben ist.
Nutzen im Audit
Im Audit oder bei einer behördlichen Inspektion wird häufig stichprobenartig gefragt: Wo ist der Nachweis für diese Anforderung? Mit einer gepflegten Traceability Matrix lässt sich diese Frage in kurzer Zeit beantworten – mit Verweis auf Spezifikation, Protokoll, Rohdaten und gegebenenfalls Abweichung. Das schafft Vertrauen in die gesamte Qualifizierungsstruktur. Welche weiteren Punkte in der Vorbereitung wichtig sind, lesen Sie im Beitrag zu typischen Fehlern in der GMP-Dokumentation.
Wenn Sie eine prüfbare Qualifizierungsstruktur mit durchgängiger Traceability aufbauen möchten, finden Sie Informationen dazu unter Qualifizierung.