Eine effiziente Dokumentenfreigabe stellt eine der wichtigsten Voraussetzungen für ein wirkungsvolles Qualitätsmanagementsystem dar.
Lesen Sie in diesem Artikel, wie Sie mit einer effizienten Dokumentenfreigabe die Produktivität Ihres Teams verbessern und die Qualität Ihrer Produkte und Prozesse erhöhen können.
Dieser Artikel beschreibt, wie Sie Dokumente auch in der Entwicklung effizient prüfen und freigeben. Sie erfahren zudem, ob ein Vier-Augen-Prinzip notwendig ist.
1. Was man unter einer Dokumentenfreigabe versteht
Dokumente definiert die ISO 9000:2015 als „Information einschließlich des Trägermediums“. Sie nennt als Beispiele Aufzeichnungen und Vorgabedokumente z.B. Spezifikationen und Verfahrensanweisungen.
Dokumente unterliegen einem Dokumentenlebenszyklus (s. Abb. 1)
Die Dokumentenprüfung soll sicherstellen, dass das Dokument konform mit zuvor gestellten Anforderungen ist. Diese Anforderungen stammen beispielsweise aus Normen oder eigenen Vorgaben wie Verfahrens- oder Arbeitsanweisungen.
Hingegen stellt die Dokumentenfreigabe eine Erlaubnis dar, dass man zur nächsten Stufe übergeht. Genauso definiert es auch die ISO 9000:2015:
Die Freigabe einer Software Requirements Specification kann beispielsweise die Erlaubnis darstellen, mit der Erstellung der Software-Architektur fortzufahren.
Die Norm merkt an, dass der englische Begriff („release“) im Zusammenhang mit Software und Dokumenten häufig mit der Version dieser Software bzw. dieses Dokuments verwendet wird. Auch die IEC 62304 nutzt den Begriff der Software-Freigabe („software release“) entsprechend.
Lesen Sie hier mehr zum Thema Dokumentenlenkung.
2. Weshalb effiziente Dokumentenfreigaben wichtig sind
Unnötiges Warten
Mit einer schwergewichtigen Dokumentenfreigabe können Sie Ihr ganzes Team stilllegen: Es wartet auf die Prüfung und Freigabe durch überlastete Experten und Vorgesetzte. Das Projekt steht.
Fehlende „Quality Gates“
Schlimmer noch: Das Team wartet nicht und arbeitet (z.B. entwickelt) ohne den Schritt einer Prüfung und Freigabe einfach weiter. Die Dokumentation hat ihre Funktion als Element der Qualitätssicherung verloren.
QM-Bürokratie
Das Erstellen der Dokumente wird damit zu Recht als eine ebenso aufwändige wie sinnfreie Tätigkeit empfunden; als Auswüchse einer QM-Bürokratie.
Regulatorische Risiken
Wenn Hersteller die Dokumente nicht oder nicht zum richtigen Zeitpunkt prüfen oder freigegeben, verstoßen sie gegen die regulatorischen Anforderungen. Die Gefahr, dass dies zum Audit oder der Zulassung zum Problem wird, ist hoch.
Die Folgen sind aufwändige und kostspielige Nacharbeiten, verzögerte Zulassungen oder gar juristischer Ärger.
3. Regulatorische Anforderungen an die Dokumentenfreigabe
a) ISO 13485:2016
Die ISO 13485:2016 erwähnt den Begriff der Freigabe nicht bei der Dokumentenlenkung. Sie fordert allerdings im Kapitel 4.2.4 zur Dokumentenlenkung, dass die Dokumente sowohl bewertet als auch genehmigt werden müssen. Diese Genehmigung („approve“) entspricht der bzw. führt zur Freigabe.
Im Kapitel 7.3.4 fordert die Norm explizit die Genehmigung der Entwicklungsergebnisse vor der Freigabe des Produkts und die Bewertung der Entwicklungsergebnisse in Kapitel 7.3.5.
Mit Bezug zum Vier-Augen-Prinzip ist das Kapitel 5.5.1 relevant:
„Die oberste Leitung muss die gegenseitigen Beziehungen aller Personen dokumentieren, die Arbeiten, die sich auf die Qualität auswirken, leiten, durchführen und bewerten, und muss die erforderliche Unabhängigkeit und Befugnis zur Durchführung dieser Aufgaben sicherstellen.“
ISO 13485:2016. Kapitel 5.5.1
Damit ist ausgeschlossen, dass sich eine Person selbst überprüft.
b) IEC 62304
Die IEC 62304 verwendet den Begriff der Freigabe nicht mit Bezug auf die Dokumente, sondern mit Bezug zur Software. Die Norm verlangt aber explizit, dass die Hersteller im Entwicklungsplan festlegen:
„Für jedes identifizierte Dokument […] müssen […] referenziert werden […] Verfahren und Verantwortlichkeiten für Entwicklung, Überprüfung, Genehmigung und Änderung.“
DIN EN IEC 62304:2016, Kapitel 5.1.8
Die Genehmigung entspricht der Freigabe. Auf welche Kriterien hin die Dokumente zu prüfen (nicht freigeben) sind, beschreibt die IEC 62304 in den folgenden Kapiteln:
- Software-Anforderungen in Kapitel 5.2.6
- Software-Architektur in Kapitel 5.3.6
- Detailliertes Design in Kapitel 5.4.4
- Software-Units in Kapitel 5.5.2 ff.
- Software (insgesamt) in Kapitel 5.8
c) EU GMP
Die Leitlinien der EU zur „Good Manufacturing Practice“ (GMP) wenden sich zwar an die Hersteller von Arzneimitteln und nicht an die von Medizinprodukten. Dennoch stellen diese den Stand der Technik dar.
Im Kapitel 4 dieser Leitlinien fordert die EU beispielsweise:
- Kapitel 4.3 „Erzeugung und Kontrolle der Dokumentation“: „Unterlagen, die Anweisungen enthalten, sollten von geeigneten, befugten Personen genehmigt, unterzeichnet und datiert werden.“
- Kapitel 2.5 „Der Leiter der Herstellung“ und Kapitel 2.6 „Der Leiter der Qualitätskontrolle“ konkretisieren die Verantwortlichkeit des Schlüsselpersonals: „Genehmigung von Anweisungen … und anderen Verfahren [zur Qualitätskontrolle].“
d) FDA
Die FDA dokumentiert Ihre Anforderungen an die Dokumentenlenkung im 21 CFR part 820.40:
„Document approval and distribution. Each manufacturer shall designate an individual(s) to review for adequacy and approve prior to issuance all documents established to meet the requirements of this part. The approval, including the date and signature of the individual(s) approving the document, shall be documented.”
FDA: 21 CFR part 820.40
Im 21 CFR part 211.194 fordert die Behörde:
„(8) The initials or signature of a second person showing that the original records have been reviewed for accuracy, completeness, and compliance with established standards.“
FDA; 21 CFR part 211.194
Das ist die Forderung nach einem Vier-Augen-Prinzip. Diese wendet sich streng genommen aber nicht an Medizinproduktehersteller. Für diese ist allerdings 21 CR part 820.20(1) relevant:
„Responsibility and authority. Each manufacturer shall establish the appropriate responsibility, authority, and interrelation of all personnel who manage, perform, and assess work affecting quality, and provide the independence and authority necessary to perform these tasks.“
FDA: 21 CR part 820.20(1)
4. Gibt es die Forderung nach einem 4-Augen-Prinzip?
Auch wenn keine der regulatorischen Anforderungen den Begriff des 4-Augen-Prinzips verwendet, so ist doch klar, dass zumindest zwei Personen (vier Augen) notwendig sind, um ein Dokument zu schreiben, zu prüfen und freizugeben.
Es ist aber weder gefordert, dass mehrere Personen das Dokument prüfen, noch verbieten die Regularien, dass die Dokumentenprüfung und Dokumentenfreigabe von einer Person durchgeführt werden.
Wenn die Freigabe jedoch zum Ziel hat, die Korrektheit, Existenz und Vollständigkeit der Prüfung zu bewerten, dann kann man die geforderte Unabhängigkeit von Prüfer und „Freigebender“ nicht unterstellen, wenn das die gleiche Person ist.
Unabhängigkeit der zweiten Person
Häufig führt der Grad der Unabhängigkeit der zweiten Person zu Diskussionen. Einen Hinweis dazu gibt das FDA Guidance Document:
„In a small company, complete independence is very difficult to obtain. Within the context of formal design reviews, the practical solution is simply to ensure a fresh perspective, based on the principle that those who are too close to the design may overlook design errors. Thus, reviewers will often be from the same organization as the developers, but they should not have been significantly involved in the activities under review.“
Ein Leser (siehe Kommentare) schlussfolgerte:
Somit darf ein Software Entwickler, der an der gleichen Software arbeitet durchaus ein Review durchführen, er sollte aber keinen „signifikanten“ Anteil am Reviewobjekt geleistet haben. Wobei signifikant wieder ein dehnbarer Begriff ist.
5. Wie Sie herausfinden, ob Ihre Dokumentenfreigaben effizient sind
Wenn Sie herausfinden wollen, ob Sie die Effizienz Ihrer Prozesse durch schwergewichtige Freigaben behindern, dann prüfen Sie folgende Aspekte:
- Verlangen Sie möglichst viele Unterschriften? Je mehr, umso „besser“.
- Haben Sie darauf geachtet, dass alle Top-Level Manager und die Geschäftsführer unterschreiben müssen?
- Haben Sie sichergestellt, dass diese Personen schlecht verfügbar sind, idealerweise selten vor Ort sind? Fehlende Stellvertreterregelungen wären ein weiterer „Tipp“.
- Machen Sie die Freigaben auf Papier im Umlaufverfahren? Ideal wären mehrere Standorte.
- Definieren Sie eine erneute Freigabe als Nicht-Erreichen eines bereits erreichten Meilensteins?
- Lassen Sie das QM- oder Regulatory-Affairs über technische Inhalte entscheiden?
- Nutzen Sie Werkzeuge zur Dokumentenverwaltung, die möglichst unbeliebt sind, beispielsweise weil sie niemand bedienen kann, weil sie regelmäßig nicht verfügbar sind und weil sie den Ausdruck und die manuelle Unterschrift nicht ersparen?
Klingt das zynisch? Wie viele dieser Punkte treffen bei Ihnen zu?
Das ist die Realität, die das Johner Institut häufig beobachtet.
6. Wie Sie Ihre Dokumentenfreigabe effizient gestalten
Die Gestaltung der Dokumentenfreigaben hängt ab von der Größe des Teams, dessen Verteilung, der Organisation der Firma, der Art der Produkte usw. Die folgenden Best Practices helfen aber unabhängig von diesen Faktoren.
a) Die richtigen Personen beteiligen
Dokumentenfreigabe
Mit der Freigabe wird die Erlaubnis erteilt, den nächsten Prozessschritt zu beginnen. Diese Freigabe kann eine Person bzw. eine Rolle erteilen beispielsweise der „Process Owner“ (z.B. Entwicklungsleiter), ein Projektleiter oder ein mit dem Prozess bzw. dem Projekt vertrauter Regulatory Affairs oder Qualitätsmanager.
Sie benötigen nur eine Person. Ein Vier-Augen-Prinzip ist weder vorgeschrieben noch sinnvoll. Wenn es nur eine Rolle gibt, ist diese verantwortlich. Es besteht keine Gefahr, dass sich jeder auf den anderen verlässt.
Dokumentenprüfung
Anders sieht das bei der vorausgegangenen Dokumentenprüfung aus. Bei solchen Reviews benötigen Sie mehrere Personen.
Doch auch hier sollten Sie die Anzahl der Personen so weit wie möglich reduzieren. Daran sollten bei Entwicklungsprojekten i.d.R. nur teilnehmen:
- Der Autor bzw. die für die jeweilige Aktivität/Phase verantwortliche Person. Bei einer Software-Architektur wäre das der Software-Architekt.
- Der Auftraggeber dieser Phase bzw. dieses Dokuments. Bei einer Software-Architektur ist das der- oder diejenige, der/die die Systemspezifikation geschrieben hat, beispielsweise ein Produktmanager.
- Der Auftragnehmer dieser Phase bzw. dieses Dokuments. Um bei unserem Beispiel der Software-Architektur zu bleiben, wären das die Entwickler, die diese Architektur umsetzen müssen.
- Die für die Tests verantwortliche Person, die prüfen kann, ob das Geschriebene auch testbar ist. Das wäre bei einer Software-Architektur der Integrationstester, falls es den gibt.
Sonderfall Qualitätsmanagement und Regulatory Affairs
Eine Sonderrolle kommt den Regulatory Affairs und Qualitätsmanagern zu: In die Freigabe von Produktanforderungen und Spezifikationen müssen diese ebenso wenig involviert werden wie die Geschäftsführung.
Wenn die Dokumente hingegen einen Prozessaspekt haben, sollten Sie die Qualitätsmanager und ggf. Regulatory Affairs Manager an der Prüfung beteiligen. Das betrifft insbesondere:
- Pläne: Entwicklungsplan, Software-Entwicklungsplan, Risikomanagementplan etc.
- Prozessbezogene Freigaben z.B. die Software-Freigabe gemäß IEC 62304 Kapitel 5.8
- Verfahrens- und Arbeitsanweisungen
Tester als Teil der Qualitätssicherung sind häufig dem Qualitätsmanagement organisatorisch zugeordnet. Dann ist das Qualitätsmanagement gemäß den obigen Tipps indirekt beteiligt.
Für das Qualitätsmanagement gibt es ein weiteres Instrument, um die „Process Compliance“ zu prüfen: Das Design Review.
Lesen Sie hier mehr zum Thema Design Review.
Sonderfall Risikomanagement
Die Risikomanager können, aber müssen nicht eingebunden werden, das hängt in der Tat vom Projekt bzw. Produkt ab.
Fazit
An einem Review sollten nicht mehr als vier oder fünf Personen teilnehmen. Also ein etwa Acht-Augen-Prinzip :-).
Sie können in Ihrer SOP die zu beteiligenden Personen auch davon abhängig machen, ob das Dokument initial erstellt oder überarbeitet wurde.
Aus dem Review fliegt jede Rolle raus, die keinen Beitrag leisten kann, aber die Terminfindung erschwert.
b) Werkzeuge und Hilfsmittel nutzen
Erniedrigen Sie die Hürden für die Dokumentenprüfung und Dokumentenfreigabe durch einfache Werkzeuge.
Checklisten und Werkzeuge
Nutzen Sie Checklisten, die maximal ein beidseitig bedrucktes Blatt umfasst. Nutzen Sie entweder ein ALM-Werkzeug (z.B. MedPack oder JIRA) oder Papier.
Im letzteren Fall sollten die Checklisten ausgedruckt in einem Hängeordner oder einer Schublade bei jedem am Platz liegen. Dann bedarf es nur eines Handgriffs, um mit dem Review bzw. der Dokumentenfreigabe zu beginnen.
Nutzen Sie unseren Auditleitfaden, die Checkliste, die das Johner Institut für benannte Stellen entwickelt hat.
Insbesondere bei verteilten Teams sollten Sie auf webbasierte ALM-Werkzeuge zurückgreifen.
Binär entscheidbare Prüfkriterien
Gleich ob auf Papier oder im Werkzeug: Nehmen Sie nur ganz konkrete und überprüfbare Punkte mit in die Checklisten mit auf. Ein Punkt „Ist das Dokument vollständig?“ ist ziemlich wertlos.
Eine Frage „Gibt es am Ende des Dokuments eine zweispaltige Tabelle, in deren linker Spalte alle IDs der Systemanforderungen aufgeführt und in deren rechte Spalte ein Stichwort oder einen Halbsatz zur Umsetzung in der Architektur steht?“ lässt sich hingegen genau prüfen.
Kompakte Dokumente
Vermeiden Sie Monsterdokumente. Zerlegen Sie die Dokumente! Eine Systemarchitektur muss die Systemkomponenten (z.B. programmierbare elektronische Subsysteme PESS) und deren Zusammenspiel beschreiben. Die Anforderungen an die PESS hingegen lassen sich pro PESS formulieren. Analog gilt das für die Software-Architektur.
Je kleiner ein Dokument, umso schneller und besser ist es prüfbar. Dokumente, an denen mehrere Rollen mitschreiben, sollten Sie möglichst vermeiden.
Vermeiden Sie auch lange „Document Headers“. Alle Querschnittsaspekte wie Glossare gehören „rausfaktorisiert“. Das erschwert die Prüfung und Freigabe der Dokumente.
Bilder und Modelle
Vermeiden Sie langen Fließtext in den zu prüfenden und freizugebenden Dokumenten. Bilder, Tabellen, Modelle sind kompakter und lassen sich schneller und einfacher prüfen.
c) Prüfung und Freigabe sowie Produkt- und Prozessaspekte trennen
Trennen Sie Prüfungen und Freigaben. Bei der Prüfung geht es um die inhaltliche Vollständigkeit, Korrektheit und Verständlichkeit.
Bei der Freigabe geht es meist um die Projektsteuerung und um die „Process Compliance“.
Beide Aktivitäten bedürfen anderer Prüfkriterien. Für die beiden Aktivitäten sind unterschiedliche Rollen zuständig (s.o.).
e) Das richtige Setup wählen
Die Dokumentenprüfung und die Dokumentenfreigabe sind Aktivtäten, die einer hohen Konzentration bedürfen. Achten Sie daher auf das Folgende:
- Alleine statt (nur) im Team
Prüfen Sie zuerst alleine und nicht in großen Team-Meetings. Bei den Meetings tragen Sie die Ergebnisse der einzelnen Prüfer zusammen, gleichen diese ab und kommen zu einem abschließenden Urteil. - Regelmäßige kurze Prüfungen
Bevorzugen Sie regelmäßige, zeitnahe und kurze Reviews (< 30 Minuten). Nach 45 Minuten intensiver Prüfung sind die meisten Hirne ermüdet. - Ungestörtes Arbeiten
Schaffen Sie Orte, an denen man in Ruhe bzw. sich im Team zusammensetzen kann. Störungen durch Telefon oder E-Mail müssen tabu sein.
f) Wertschätzende Kultur schaffen
Als Geschäftsführer und Projektleiter drücken Sie Wertschätzung für diese Review-Tätigkeiten aus. Wenn Sie glauben, nur ein programmierender Programmierer sei ein guter Entwickler, sind Sie falsch auf Ihrem Posten.
Bei Google werden übrigens Reviews genauso hoch bewertet wie das Schreiben von Dokumenten und das Programmieren.
7. Fazit
Ineffiziente Prozesse durch ineffiziente Prüfungen und Freigaben
Mit einer schwergewichtigen Dokumentenfreigabe legen Sie Ihre ganze Firma still. Ineffiziente Prozesse haben meist etwas damit zu tun, dass die Prüfung und Freigabe der Dokumente nicht klug geregelt wurden.
Auf eine (rechtzeitige) Freigabe von Dokumenten zu verzichten, ist nicht klug:
- Man hat immer noch die Arbeit mit den Dokumenten.
- Man verzichtet auf den Nutzen, den eine präzise Prüfung und Freigabe im Sinne eines „Quality Gates“ hat.
- Man setzt sich hohen regulatorischen Risiken aus.
Vier-Augen-Prinzip
Verwechseln Sie Dokumentenprüfung nicht mit der Dokumentenfreigabe. An einer Prüfung sollten Sie mehrere Personen beteiligen. Hier ist das Vier-Augen-Prinzip ggf. hilfreich aber nicht zwingend vorgeschrieben. Bei einer Dokumentenfreigabe hingegen nicht.
Wenn die Freigabe die Überprüfung der Bewertung zum Ziel hat, dürfen der Freigebende und der Bewertende nicht die gleiche Person sein. Dann ist ein Vier-Augen-Prinzip de-facto vorgeschrieben, auch wenn die Regularien diesen Begriff nicht verwenden.
Der Ersteller und der Prüfer eines Dokuments dürfen nie die gleiche Person sein. Hier ist ein Vier-Augen-Prinzip unumgänglich.
Unterstützung
Haben Sie das Gefühl, dass Ihre Prozesse und Ihre Dokumentenprüfungen und -freigaben nicht effizient genug sind? Scheut Ihr Team diese Aktivitäten und schiebt sie deshalb vor sich her? Dann melden Sie sich bei uns. Wir helfen gerne, Ihre Prozesse schlanker zu gestalten und damit Ihre Produkte sicherer zu entwickeln und schneller in den Markt zu bringen.
Danke an Norbert Pauli und Markus Gehart für den wertvollen Input!
Guten Tag Herr Johner,
ich habe an der Erstellung der IEC 62304 mitgewirkt, wir kennen uns aus entsprechenden Meetings bei der DKE in Frankfurt.
Von Ihrem Beitrag zur Dokumentenfreigabe habe ich erfahren, weil ein Kollege ihn firmenintern zitiert hat, genauer gesagt den Abschnitt b).
Da stieß mir dann doch Ihre Anmerkung zu der Einbindung von QM und RA auf Unverständnis. Ich denke, das liegt aber wahrscheinlich daran, dass Sie nur einen bestimmten Dokumententyp im Auge hatten, in etwa Softwarespezifikationen und ihre schrittweise Umsetzung in Code.
Aus der Praxis heraus kann ich aber sagen, dass es für andere Dokumententypen und je nach Organisation des Herstellers es durchaus Dokumente im QM-System und gemäß IEC 62304 gibt, die inhaltlich vom QM/RA bewertet werden können, z.B. der Development Plan.
Ich denke, es wäre sinnvoll und würde Missverständnisse vermeiden, wenn dies in Ihren Ausführungen Erwähnung finden könnte.
Einen ähnlichen Aspekt sehe ich bei den konkret vorgeschlagen Teilnehmern für ein Review. Ihren Ansatz mit den abstrakten Rollen unterstütze ich voll und ganz. QM ist aber keine abstrakte Rolle mehr, sondern spiegelt die (jeweils unterschiedliche) Organisation eines Herstellers wider. Es könnte da z.B. sein, dass ein Tester dem QM organisatorisch zugeordnet ist.
Bei Freigaben hat sich bei uns bewährt, dass für jede freigebende Rolle, z.B. im Rahmen der (elektronischen) Unterschrift, angegeben ist, welchen Aspekt des Dokuments die Freigabe durch diese spezifische Rolle abdeckt. Das soll auch, wie in der Praxis häufig gesehen, eine „kollektive“ Freigabe verhindern, wo jeder sich auf den anderen verlässt.
Mit freundlichem Gruß
Norbert Pauli
Lieber Herr Pauli,
ich danke Ihnen herzlich für Ihren wichtigen Input! Ich stimme Ihnen absolut zu, dass einige Stellen missverständlich sein können, insbesondere wenn es um Rollen und Organisationseinheiten geht. Ich werde Ihren wertvollen Kommentar zum Anlass nehmen, ihn gleich am Wochenende zu überarbeiten. Ich würde Sie dann gleich mit einbeziehen. Ich fände es auch wertvoll, wenn man ggf. unterschiedliche Sichtweisen thematisiert. Insofern würde ich mich über Ihre weitere Unterstützung sehr freuen.
Mit nochmaligem Dank, mit herzlichen Grüßen und bis sehr bald, Christian Johner
Guten Tag Herr Johner,
was für uns und unsere Kunden immer wieder ein Diskussionspunkt ist, ist die Unabhängigkeit des zweiten Augenpaares. Muss der Reviewer komplett unabhängig sein? Sogar aus einem anderen Projektteam? Darf er an der gleichen Software gearbeitet haben? Hier hilft mir jeweils die FDA Design Control Guidance (https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm070642.pdf) wo auf Seite 26 steht:
„In a small company, complete independence is very difficult to obtain. Within the context of formal design reviews, the practical solution is simply to ensure a fresh perspective, based on the principle that those who are too close to the design may overlook design errors. Thus, reviewers will often be from the same organization as the developers, but they should not have been significantly involved in the activities under review.“
Somit darf ein Software Entwickler der an der gleichen Software arbeitet durchaus ein Review durchführen, er sollte aber keinen „signifikaten“ Anteil am Reviewobjekt geleistet haben. Wobei signifikant wieder ein dehnbarer Begriff ist.
Vielleicht hilft dieser Guidance-Absatz einem anderen Leser ja auch.
Grüsse
Beat Keller
Lieber Herr Keller,
das ist ein großartiger Hinweis, den ich so gleich ergänze!
Vielen Dank!!
Beste Grüße, Christian Johner
Guten Morgen Herr Johner,
ich weiß, dass in der Industrie gerne Begriffe verwässert, gedehnt und vermischt werden, bitte aber doch bestimmte Dinge zu unterscheiden.
4-Augen-Prinzip/2-men-rule und die von der Norm geforderte unabhängige Freigabe sind nicht identisch.
4-Augen bedeutet eigentlich 2 Paar „Prüfaugen“, idealerweise beauftragt mit der gleichen Prüfung (oder zumindest gleichen Kriterien, wenn verkürzt). Der Autor bzw. dessen Augen zählen grundsätzlich nie dazu, er ist nicht objektiv und zu nah dran („betriebsblind“), da seine Arbeit gereviewed wird.
Die Norm fordert dementsprechend, wie Sie bereits in 4. schreiben, dass eine 2. Person mit einbezogen werden muss. Das 4-Augen-Prinzip ist eine noch höhere Stufe, gefolgt vom 6-Augen-, … , Mehraugenprinzip.
Beispiele für 4-Augen-Prinzipien wären
-Erst- und Zweitprüfer einer Dissertation oder
-die doppelte Absicherung durch doppelte Verifikation eines Autorisierungsschlüssels vor Abschuss von Atomraketen.
-die 2.Kontrolle der Prüfergebnisse durch einen erfahrenen QC-Kollegen bei einem neuen Kollegen
[Autor alleine -> 0.Ebene]
[Autor plus unabhängiger Prüfer -> 1. Ebene] (von der mind. Norm gefordert)
[Autor plus 2 unabhängige Prüfer -> 2. Ebene] (4-Augen-Prinzip)
…
Nimmt es genau, dann wäre durch die Redundanz der Prüfung die erhöhte Sicherheit gewährleistet, dementsprechend wäre bei nicht-rundundanten Prüfungen (formal, fachlich) nicht sicher, dass der eine fachliche Prüfer nicht etwas übersehen hat (und somit 1. Ebene).
Beste Grüße,
Christian Baudis
Sehr geehrter Herr Prof. Johner,
vielen Dank für die sehr guten Ausführungen.
Bzgl. des Dokumentenlebenszyklus würde ich sagen, dass das Schulen vor der Freigabe stattfindet, denn wenn das Dokument freigegeben ist, dann ist es gültig. Das heißt, es muss danach gearbeitet werden. Das alte Dokument wird ja aus dem Verkehr gezogen (nicht vernichtet, muss ja ggf. mit in die technische Dokumentation). Oder? Wir das Dokument vor oder nach der Freigabe geschult? Mit der Freigabe ist es ja gültig, nicht wahr?
Man könnte noch einen Zwischenschritt einfügen:
Freigabe — dann hat man z. B. 2-3 Wochen Zeit, dieses Dokument zu schulen
In der 3. bzw. 4. Woche wird das Dokument als „aktiv“ gesetzt (Datum der Gültigkeit) und das alte Dokument aus dem Verkehr gezogen.
Der Punkt ist die Definition der „Freigabe“: Ist diese identisch mit dem Datum der Gültigkeit?
Eine Ungenauigkeit kann im Audit / in der Inspektion als Mangel aufschlagen.
Was meinen Sie?
Vielen Dank.
MfG
Ayfer Bektas
Sehr geehrte Frau Bektas,
ich stimme Ihnen absolut zu! Danke für den wertvollen Hinweis. Wir werden das gleich nächste Woche präzisieren.
Danke, dass Sie uns darauf aufmerksam und damit ermöglicht haben, den Beitrag weiter zu verbessern!
Viele Grüße, Christian Johner
Sehr geehrter Herr Prof. Johner,
vielen Dank für die interessanten Ausführungen.
wie ist die Prüfung und Freigabe von Dokumenten denn in sehr kleinen Unternehmen umsetzbar, wenn der QM/ QMB selbst der Prozesseigner ist? Er darf ja dann nicht der Prüfer sein. Bei uns ist es so geregelt, dass der QMB, in einzelnen Fällen auch die PRRC QM-Dokumente auf die Einhaltung mit den regulatorischen Anforderungen prüft, bevor sie freigegeben werden. Die Ersteller sind die Prozesseigner mit der fachlichen und technischen Kompetenz.
Wenn nun aber QM/ QMB selbst der Prozesseigner ist, ist es sehr schwer eine sinnvolle fachliche Prüfung durch einen anderen Mitarbeiter durchführen zu lassen. Oder kann man in solch einem Fall auf eine Prüfung verzichten und lässt das Dokument nur formell freigeben?
Was meinen Sie?
MfG
M. Schmidt
Sehr geehrte Frau Schmidt,
eine Prüfung durch sich selbst entspricht nicht den Grundsätzen des Qualitätsmanagements. Ob allerdings überhaupt eine Prüfung notwendig ist, legen Sie in Ihren Vorgabedokumenten fest, typischerweise anhand des Risiko für Konformität Ihrer Produkte und Ihre QM-Systems.
Eine Möglichkeit besteht darin, Dokumente durch qualifizierte Personen außerhalb des Unternehmens (z.B. Berater, befreundete Unternehmen) prüfen zu lassen.
Viele Grüße
Christian Johner
Sehr geehrter Herr Prof. Johner,
mir hat sich folgende Frage gestellt: Wenn nun ein Dokument bearbeitet wird, also eine neue Version erstellt wird, wer gilt dann als Autor, und wer als Prüfer. Ist der Bearbeiter des Dokuments der neue Autor oder bleibt der Autor des urspünglichen Dokuments bestehen?
MfG
C. Altmann
Sehr geehrte Frau Altmann,
üblicherweise bleibt der Autor der Autor, und die Person, die die Änderungen durchgeführt hat, erscheint in der Änderungshistorie. Sie können das aber für sich auch anders regeln. Wichtig ist nur, dass die Nachvollziehbarkeit gegeben bleibt. D.h. es sollte immer nachvollziehbar sein, wer in welcher Version etwas geschrieben/geändert, geprüft und freigeben hat.
Herzliche Grüße, Christian Johner
Guten Tag,
möglicherweise bin ich nun mit meiner Frage etwas ’spitzfindig‘, möchte diese aber dennoch in den Raum werfen:
Bedeutet das 4-Augen-Prinzip nicht eigentlich auch, dass zum Zeitpunkt des Geschehens (bspw. einer Testdurchführung) vier Augen zugegen sein müssen? Das würde bedeuten, man hätte einen „Zeugen“.
Alle anderen Vorgehensweisen wäre dann ja eher unter dem Label „Review“, „Peer-Review“ oder mehrfache Überprüfung zu verstehen…
Ab wann unterscheidet man – auch zeitlich? – 4-Augenprinzip von Bezeugung?
Freundliche Grüsse,
Chr. Kunath
Liebe/r Frau/Herr Kunath,
herzlichen Dank für Ihre sehr treffende Frage. Sie haben recht, dass mit dem 4-Augen-Prinzip auch die physische Anwesenheit eines zweiten Mitarbeitenden gemeint sein kann. Dies kann insbesondere während der Produktion, der Qualitätskontrolle oder Verifizierung und Validierung erforderlich sein. In der Regel identifiziert man diese kritischen Prozessschritte, die nicht auf andere Art verifiziert werden können und durch das 4-Augen-Prinzip bestätigt werden müssen, mittels einer Risikoanalyse.
Mögliche Vorgehensweisen zur Überprüfung und Freigabe eines Dokuments werden im GMP-Umfeld konkreter beschrieben und stellen den Stand der Technik der Dokumentenlenkung dar. So heißt es im GMP-Berater in Kapitel 15.A. „Dokumente müssen vor Ihrer Verwendung durch die dafür Verantwortlichen genehmigt werden. Die Genehmigung setzt eine Überprüfung der Geeignetheit des Dokuments (Richtigkeit, Aktualität, Zweckmäßigkeit) voraus.“ Im Kapitel 15.A.5.2 wird der Lebenszyklus eines Dokuments vom Erstellen, über das Prüfen bis zur Genehmigung erläutert: „Das Erstellen neuer oder Ändern bestehender Dokumente sollte von dem Personal durchgeführt werden, das sich in der Praxis mit den Regelungen des Dokuments beschäftigt und mit den relevanten Verfahren vertraut ist.“ „Danach ist das Dokument formal und inhaltlich zu prüfen. Die formale Prüfung auf Einhaltung von Aufbau- und Formatvorgaben kann durch die Qualitätssicherungsabteilung vorgenommen werden. Die fachliche Überprüfung sollte von einer dem Autor unabhängigen Person vorgenommen werden, die aufgrund ihrer Fachkenntnisse und Erfahrungen die Geeignetheit des Dokuments bewerten kann.“ „Die Genehmigung soll durch die Person erfolgen, die für den Regelungsbereich des Dokuments verantwortlich ist“.
Mit herzlichen Grüßen,
Catharina Bertram
Guten Tag,
wir haben intern immer wieder Diskussionen welche Vorgabedokumente geschult werden müssen. Wir haben Verfahrens- und Arbeitsanweisungen im Einsatz sowie zahlreiche Formulare und Listen. Diese Dokumente werden übers DMS gelenkt. Meist gehören solche Formulare und Listen zu einer Arbeitsanweisung, ist aber nicht immer der Fall. Inwieweit entsteht hier ein Schulungsbedarf, wenn nur rein das Formular oder eine Liste geändert wird und die Arbeitsanweisung nicht? Beispiel: es gibt eine Arbeitsanweisung und ein separates Formular zu dieser. Es wird im Formular eine Spalte ergänzt, die neue Version des Formulars wird freigegeben, die Arbeitsanweisung wird nicht angepasst. Inwieweit und welcher Schulungsbedarf würde in dem Fall entstehen? Da wir eine große Anzahl an Formularen und Listen haben, würde mich Ihre Meinung dazu sehr interessieren.
MfG
F. Stillebacher
Lieber Herr Stillebacher,
vielen Dank für diese Frage, die immer wieder gestellt wird, und leider nicht pauschal zu beantworten ist.
Die ISO 13485 beschreibt hier keine expliziten Anforderungen, vielmehr wird unter 6.2 b) gefordert: „Die Organisation muss (…) zum Erreichen oder Aufrechterhalten der notwendigen Kompetenzen für Schulungen sorgen oder andere Maßnahmen ergreifen.
Dies bedeutet, Sie müssen von Fall zu Fall entscheiden, ob die Änderung an dem Formular oder der Liste so signifikant ist, dass eine Schulung durchgeführt werden muss, um die Kompetenz Ihrer Mitarbeiter aufrechtzuerhalten. Im gleichen Zug sollten Sie dann entscheiden, welche Art von Schulung nötig ist, einfachsten Fall ist dies eine Selbstschulung, bei komplexen Änderungen sind aufwendigere und umfangreichere Schulungen nötig.
Zusammengefasst: Sie sollten bei jeder Änderung risikobasiert entscheiden, ob eine Schulung nötig ist, und wenn ja, wie diese aussehen soll, egal ob diese eine Verfahrensanweisung oder ein Formular betrifft. Die Entscheidung inklusive Rationale ist zu dokumentieren, und sollte auf Kriterien, die in der Verfahrensanweisung beschrieben sind, basieren.
Ich hoffe diese Antwort hilft Ihnen weiter, bitte lassen Sie mich wissen, wenn hier noch Klärungsbedarf ist!
Schöne Grüße,
Andreas Kalchschmid-Lehmann