QM Dokumentenlenkung: Wie viele im Audit scheitern

Montag 1. Februar 2016

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

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.

Dokumentenlenkung Dokumenten-Lebenszyklus

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).

Kategorien: Regulatory Affairs
Tags:

3 Kommentare über “QM Dokumentenlenkung: Wie viele im Audit scheitern”

  1. Thomas Zschaeck schrieb:

    Sie haben eine sehr interessante Lösung für ein extrem wichtiges Thema gefunden!
    Wie/ mit welchem Aufwand haben Sie denn das Thema Validierung der einzelnen Systeme und ihr Zusammenwirken auditsicher gelöst? Und wie funktioniert die Validierung bei neuen Versionen der Einzeltools, die ja mindestens teilweise Freeware sind?
    Freundliche Grüße
    Thomas Zschaeck

  2. Christian Johner schrieb:

    Besten Dank für die spannende Frage, Herr Zschaeck!

    Ob ein Werkzeug Freeware ist oder nicht, hat keine wirkliche Auswirkung auf die Validierung. Die meisten Tools sind sogar Open Source, d.h. eine Überprüfung im Code wäre — im Gegensatz zu den typischen kommerziellen Werkzeugen — möglich.

    Da es aber um eine Validierung und nicht eine Verifizierung geht, ist sogar das — zum Glück — nur bedingt relevant.

    Relevant ist v.a. die Frage, ob eine Validierung überhaupt notwendig ist. Das würde man immer dann bejahen, wenn man dem Endergebnis nicht oder nicht leicht „ansehen“ kann, ob es den Anforderungen genügt. Bei einem Word-Dokument dürfte so eine Prüfung durch Inspektion gut möglich sein.

    Dennoch halte ich für Ihren Gedanken für sehr, sehr wichtig. Das Zusammenspiel würde ich — insbesondere da viele Systeme zusammenspielen — validieren. Der Aufwand für so eine Validierung ist aber sehr endlich. Wir erledigen das in solche einem einfachen Fall in wenigen Stunden.

    Falls Ihnen meine Antwort nicht ausreicht oder Sie weitere Fragen haben, wissen Sie ja, wie Sie mich erreichen.

    Beste Grüße, Christian Johner

  3. Wiesener schrieb:

    Sehr interessanter Ansatz mit pandoc.
    Haben Sie eine Möglichkeit bei sich gefunden, wie Dokumente / Anforderungen verlinkt werden können. Und wie man dann eine tracebility herstellen kann?

    Ich denke auch die Validierung ist eher ein kleines Problem bei solch einfachen Tools.

    Gruß,

    Wiesener

Kommentar schreiben