QM Dokumentenlenkung: Wie viele im Audit scheitern

Unter Dokumentenlenkung verstehen die meisten ein dokumentiertes Verfahren, das festlegt, wie Dokumente erstellt, geprüft, genehmigt, gekennzeichnet, verteilt und aktualisiert werden. Während die ISO 13485 die Lenkung von Dokumenten und die Lenkung von Aufzeichnungen unterscheidet, fasst die ISO 9001:2015 beide Typen als „dokumentierte Informationen“ zusammen, die natürlich auch gelenkt werden müssen.

Inhalt

• Ziel der Dokumentenlenkung
• Regulatorische Anforderungen an die Dokumentenlenkung
• Typische Probleme bei der Dokumentenlenkung
• (Technische) Möglichkeiten, um Dokumente zu lenken
• Ein Vorschlag. Aber nur für Techies

Ziel der Dokumentenlenkung

Für viele Auditoren gilt: Was nicht dokumentiert ist, das existiert nicht. Entsprechend wichtig sind Dokumente und Aufzeichnungen auch im Audit.

Was unter der Dokumentenlenkung zu verstehen ist, wird im Englischen mit „Control of Document“ klarer: Man stellt sicher, dass

• nur die richtigen Informationen
• zum richtigen Zeitpunkt
• bei den richtigen Adressanten

verfügbar sind. Das wiederum bedingt, dass

• keine ungültigen Informationen verteilt werden,
• ungültige Informationen zurückgezogen werden,
• man weiß, wer diese Informationen erhalten muss,
• diese Personen über neue, geänderte oder gelöschte Dokumente informiert und
• sicherstellt, dass diese Personen, diese Informationen auch verstehen.

Regulatorische Anforderungen an die Dokumentenlenkung

Genau die eben genannten Aspekte finden sich in den Normen wie der ISO 13485. Sie fordern, dass man festlegt (dokumentiert natürlich :-)),

• wie man Dokumente bewertet, bevor man sie verteilt,
• wie man Dokumente aktualisiert und genehmigt,
• wie man sicherstellt, dass Änderungen erkennbar sind,
• wie man sicherstellt, dass die Dokumente verfügbar sind (und auch lesbar bleiben),
• wie man sicherstellt, dass keine alten Versionen im Umlauf sind und
• wie lange man Dokumente aufbewahren will (wobei es hier konkrete Mindestanforderungen gibt).

Typische Probleme: Was im Audit immer wieder schief geht

In den Audits stoßen wir immer wieder auf ähnliche Probleme:

• Die Dokumente bzw. Informationen sind unbekannt. Fragen Sie mal einen Mitarbeiter am Band, was die Qualitätspolitik ist…
• Am Arbeitsplatz liegt eine veraltete Arbeitsanweisung.
• Die internen Audits haben die Dokumentenlenkung nicht geprüft.
• Es ist nicht eindeutig, auf welche Produkt- oder Software-Version sich Dokumente beziehen.
• Für eine Produkt- oder Software-Version gibt es keine aktualisierten Dokumente.
• Die Entwicklungs-Dokumente wurden freigegeben, nachdem die Entwicklung längst gestartet war.
• Die Verfahrensanweisung legt nicht fest, wie lange welche Dokumententypen wie aufzubewahren sind, oder sie ignoriert gesetzliche Vorgaben.
• Es fehlen festgelegte Kriterien, anhand die verschiedenen Dokumententypen jeweils zu bewerten sind. Eine Unterschrift alleine genügt nicht.
• Im Dateisystem oder im SharePoint finden sich Dokumente, die den Status (z.B. Entwurf, freigegeben, zurückgezogen) nicht erkennen lassen.
• Im Dateisystem befinden sich mehrere Dateien des gleichen Namens aber mit verschiedenen Inhalten.
• Der Hersteller kann nicht erklären, ob und wie er Dokumente wie Arbeits- oder Verfahrensanweisungen geschult hat bzw. weshalb das nicht notwendig war.

Wir erleben selten Audits, in denen die Dokumentenlenkung nicht zu Abweichungen führt. Diese Beanstandungen sind nicht Ausdruck eines überbordenden Formalismus, sondern meist eines Chaos beim Medizinprodukte-Hersteller, das nicht auf die Dokumente beschränkt ist.

Möglichkeiten, um Dokumente zu lenken

Die Hersteller stehen zahlreiche technische Möglichkeiten zur Verfügung, um ihre Dokumente zu lenken. Dazu zählen

• Dateisystem, Netzwerklaufwerke
  Hier sollten Sie Lese- und Schreib-Berechtigungen klar regeln und sicherstellen, dass alle Personen auch Zugriff haben. Das ist besonders in der Produktion ein Thema.
• Cloudspeicher
  Mit Diensten wie Dropbox oder Google Drive und deren Mobil-Clients können Ihre Mitarbeitenden leicht auf Dokumente zugreifen. Die Einschränkung von Lese- oder Schreibrechten gelingt aber nicht so einfach.
• Dokumentenmanagementsysteme
  Anwendungen wie Microsoft Sharepoint (auch als Cloud-Service verfügbar) oder Alfresco vereinfachen die Versionierung und erlauben die Definition von Dokumenten-Workflows zum Erstellen, Prüfen, Freigeben, Veröffentlichen und Zurückziehen von Dokumenten. Die Schwierigkeiten liegen meist im Detail, im Aufsetzen und Konfigurieren der Werkzeuge sowie in deren Schulung.
• Wiki -> PDF
  Einige Firmen arbeiten mit Wiki-Systemen wie Confluence und nutzen entweder Plug-ins zur Freigabe (elektronische Unterschrift) oder exportieren die Dokumente nach PDF — d.h. sie nutzen das Wiki „nur“ als Editor.
• Versionsverwaltungssysteme
  Bei Firmen, die entwicklungsnah arbeiteten, setzen meist bereits Versionsverwaltungssysteme wie SVN oder GIT ein. Diese Systeme eigenen sich aber eher für rein textuelle Dokumente. Die Benutzerfreundlichkeit ist für technophobe Menschen oft ein Thema. Andererseits eröffnen Feature wie Branching, Tagging, Commit-Kommentare und die Einbindung in Build-Tools neue Möglichkeiten. Mehr dazu finden Sie im nächsten Kapitel beschrieben.

Dokumentenlenkung (nur für Techies)

Workflow mit GIT, Pandoc und Jenkins

Am Institut setzen wir eine Kombination der Werkzeuge GIT, Pandoc und Jenkins ein. Damit erreichen wir folgenden Workflow:

• Dokument in Markdown
  Der Autor erstellt ein Dokument in Markdown. Das ist eine sehr einfache rein textbasierte Sprache, die sehr einfach zu erlernen ist. Beispielsweise Unterstreicht man einen Text mit Gleichheitszeichen („=======“), um ihn als Überschrift zu kennzeichnen. Diese Texte sind direkt sehr gut lesbar, werden zudem in Systemen wie Github als schön formatierte Webseiten angezeigt.
• Speicherung der Dokumente in GIT (mit entsprechenden Branches)
  Der Autor commited seine Änderungen bzw. sein neues Dokument auf einen Entwicklungs-Branch. Sobald er freigegeben wird, werden die Änderungen auf den Master-Branch „gemerged“. Wenn wir an Kunden-Dokumenten arbeiten erzeugen wir eigene Branches.
• Erzeugen von Word-Dokumenten
  Jeder Commit triggert einen Build-Prozess, der mit Hilfe von Pandoc automatisch die Word-Dokumente erzeugt, weil unsere Kunden lieber mit Word arbeiten. Diese Word-Dokumente werden beim Build automatisch versioniert und im Versionsverwaltungssystem gespeichert.
• Arbeiten mit den Word-Dokumenten
  Optional können Anwender diese Dokumente mit ihrem Rechner synchronisieren

Bewertung

Vorteile

• Klarer, transparenter Workflow
• Einfaches Nachvollziehen von Änderungen über die Git-Bordmittel (das ist bei Word nur über Vergleichsfunktion aufwendiger möglich)
• Einheitliches Dokumentenlayout. Durch ein Anpassen des Templates bekommen alle Dokumente ein entsprechendes Layout.
• Arbeiten mit mehreren Versionen parallel: Wir können Verbesserungen, die wir für einen Kunden erarbeitet haben, einfach in unseren Master-Branch zurück-mergen.
• Die Dokumente stehen den Anwendern im gewohnten Word-Format zur Verfügung
• Eine Konvertierung in PDF, LaTeX, HTML usw. ist „built-in“

Nachteile

• Das System aus Git, Pandoc und Jenkins (einschließlich Build-Skript) muss aufgesetzt und eine entsprechende Tool-Landschaft gepflegt werden.
• Das Erstellen und Ändern von Dokumenten bedarf mehr als nur Word-Kenntnisse.
• Die Markdown-Sprache erlaubt nur eingeschränkte Layout-Anpassungen (obwohl selbst Text-Ausrichtungen in Tabellen, Listen in Listen, Fußzeilen usw. möglich sind).