TL;DR: Die meisten Abweichungen bei der Benannten Stelle entstehen nicht, weil Daten fehlen, sondern weil Reviewer sie nicht finden. Gut strukturierte Technische Dokumentation mit klaren Belegen, erklärendem Kontext und konsistenter Argumentationsstrategie reduziert Abweichungen drastisch. Der entscheidende Unterschied zur internen Prüfung: Reviewer der Benannten Stelle fragen nicht nach. Wenn eine Information nicht sofort auffindbar ist, gibt es eine Abweichung.
Vielleicht kennen auch Sie das Gefühl: Das Review ist abgeschlossen, die Abweichungsliste liegt vor, und die erste Reaktion ist Unverständnis. Die Daten waren doch alle da. Die Tests wurden durchgeführt. Die relevanten Normen wurde berücksichtigt. Und trotzdem: Abweichungen bei der Benannten Stelle, eine nach der anderen.
Das Problem liegt selten im Produkt. Es liegt in der Dokumentation. Genauer gesagt: darin, wie die Dokumentation auf jemanden wirkt, der das Produkt nicht kennt und keine Zeit hat, nachzufragen.
Reviewer der Benannten Stelle arbeiten unter Zeitdruck. Sie lesen, suchen, haken ab. Was sich ihnen nicht innerhalb weniger Sekunden erschließt, landet als Abweichung. So funktioniert das System und Abweichungen werden nicht aus böser Absicht vermerkt, sondern aus strukturellen Gründen.
Dieser Artikel zeigt, was Ihre Technische Dokumentation leisten muss, damit Reviewer der Benannten Stelle finden, was sie suchen, ohne nachfragen zu müssen.
Warum entstehen Abweichungen bei der Benannten Stelle überhaupt?
Abweichungen entstehen meist nicht durch fehlende Daten, sondern durch schlechte Auffindbarkeit oder eine mangelhafte Darstellung. Reviewer haben keine Zeit zu suchen. Wenn eine Information nicht klar zugänglich ist, dokumentieren sie eine Abweichung, unabhängig davon, ob die Information irgendwo existiert.
Das klingt hart, ist aber die Realität des Reviewprozesses. Ein Reviewer einer Benannten Stelle prüft Dokumente nach einem strukturierten Schema. Er hat ein Zeitbudget pro Dokument. Findet er einen Parameter nicht dort, wo er ihn erwartet, fragt er gegebenenfalls nicht beim Hersteller nach. Er notiert eine Abweichung und geht weiter.
Interne Reviewer oder externe Berater können nachfragen. Das ist der einzige, aber wesentliche Unterschied. Wer diese Lücke vor dem offiziellen Review schließen will, muss seine Technische Dokumentation aus der Perspektive eines fachkundigen Fremden aufbauen.
Was leistet eine gute Technische Dokumentation im Audit?
Eine gute Technische Dokumentation gibt dem Reviewer Kontext, ohne dass er suchen muss. Jede relevante Aussage ist durch einen eindeutigen Dokumentverweis belegt. Die Struktur folgt der Erwartung des Reviewers, nicht der internen Logik des Herstellers.
Gerade bei Legacy-Produkten ist das eine Herausforderung. Das Produkt wurde über Jahre entwickelt, getestet und verbessert. Das Wissen darüber ist tief verankert, beim Entwicklungsteam, in alten Testberichten, in mündlichen Überlieferungen. Für einen Außenstehenden ist davon wenig sichtbar und auch die Dokumentation ist über Jahre „gewachsen“.
Was hilft: Eine kurze, erklärende Beschreibung der relevanten Produktdetails an den richtigen Stellen in den Kerndokumenten. Schemazeichnungen und Bilder leisten dabei oft mehr als mehrere Textabsätze. Auch konsistente Textblöcke mit Kernaussagen über verschiedene Dokumente hinweg können für Klarheit und ein einheitliches Bild sorgen (natürlich mit korrekter Referenz zum Quelldokument).
Welche Dokumentationsfehler produzieren zuverlässig Abweichungen?
Drei Fehler treten besonders häufig auf:
- thematischer Mischmasch in einzelnen Dokumenten,
- langer Text ohne präzise Kernaussagen und
- eine inkonsistente regulatorische Argumentationsstrategie.
Jeder dieser Fehler macht es Reviewern schwer, Informationen zuzuordnen und zu bewerten.
Dokumente ohne klare Zuordnung sind ein klassisches Problem. Ein Dokument namens „V&V“ enthält Teile der Softwareakte, Cybersecurity-Nachweise und allgemeine Verifikationsprotokolle. Was für das interne Team übersichtlich wirkt, ist für einen Reviewer ein Orientierungsproblem. Dokumente sollten thematisch scharf abgegrenzt sein. Ein Normenmischmasch ist in den seltensten Fällen hilfreich.
Langer Text um des Textes willen verschlimmert das Problem. Mit KI-Unterstützung lassen sich heute in kurzer Zeit umfangreiche Textpassagen generieren. Das Ergebnis klingt vollständig, ist aber schwer zu lesen. Reviewer überfliegen. Relevante Informationen, die in einem langen Absatz vergraben sind, werden übersehen. Weniger, aber präziser, schützt Sie besser.
Inkonsistente Argumentation ist die dritte häufige Ursache. Mal beruft sich die Dokumentation auf diese Nachweisroute, mal auf jene, je nach verfügbaren Daten. Das wirkt nicht flexibel, sondern unsicher. Eine klare regulatorische Strategie, die von Anfang an durchgehalten wird, ist einer der stärksten Schutzmechanismen gegen Abweichungen.
Wie strukturiere ich Kerndokumente reviewerfreundlich?
Kerndokumente sollten die Begriffe und die Struktur der einschlägigen Normen spiegeln. Jede Aussage braucht einen eindeutigen Beleg. Kontext wird knapp, aber vollständig geliefert. Der Reviewer soll lesen und abhaken können, nicht interpretieren müssen.
Normkonforme Begriffe in der Dokumentation erfüllen zwei Funktionen gleichzeitig. Sie helfen dem Reviewer, Inhalte schnell zuzuordnen. Und sie signalisieren, dass der Hersteller die regulatorischen Anforderungen verstanden hat.
Belege sollten direkt im Text verankert sein, als Dokumentverweis mit Versionsnummer und Kapitelangabe. Nicht als Anhang, den niemand aufschlägt. Der Reviewer soll den Beleg sofort sehen, nicht danach suchen.
Der Fremde-Augen-Test: Wie finden Sie Lücken vor dem Review?
Lassen Sie jemanden ohne Produktkenntnis ein zentrales Dokument überfliegen und beobachten Sie, wo er stockt. Diese Stellen sind die Schwachpunkte. Genau dort wird auch der Reviewer der Benannten Stelle stolpern.
Der Test kostet wenig Zeit und liefert präzises Feedback. Ein*e Kollege*in aus einer anderen Abteilung, neue Mitarbeitende oder eine externe Beraterin eignen sich gut. Die einzige Bedingung: Die Person darf das Produkt nicht kennen.
Wo sie ins Stocken gerät, fehlt Kontext. Wo sie falsch abbiegt, fehlt Struktur. Wo sie eine Aussage nicht belegen kann, fehlt ein Dokumentverweis. Diese drei Kategorien decken die meisten Abweichungsursachen ab. Wer diesen Test konsequent vor jedem Audit durchführt, kommt mit deutlich weniger Abweichungen heraus.
FAQ: Abweichungen bei der Benannten Stelle
Können Abweichungen entstehen, obwohl alle Daten vorhanden sind?
Ja. Abweichungen entstehen häufig nicht wegen fehlender Daten, sondern wegen schlechter Auffindbarkeit. Wenn ein Reviewer eine Information nicht klar lokalisieren kann, dokumentiert er eine Abweichung, auch wenn die Information technisch gesehen im Dokument enthalten ist.
Fragt die Benannte Stelle nach, wenn etwas unklar ist?
In der Praxis selten. Reviewer arbeiten unter Zeitdruck und folgen einem strukturierten Prüfschema. Unklare oder schwer auffindbare Informationen werden als Abweichung dokumentiert, nicht durch Rückfragen beim Hersteller geklärt.
Wie viel Kontext braucht ein Kerndokument?
So viel, dass ein fachkundiger Reviewer ohne Produktkenntnis die relevanten Aussagen versteht und belegen kann. Schemazeichnungen und Bilder ersetzen dabei oft mehrere Textabsätze. Knapp und präzise ist besser als ausführlich und unübersichtlich.
Wie gefährlich ist eine inkonsistente Argumentationsstrategie in der Technischen Dokumentation?
Sehr. Inkonsistente Argumentation signalisiert dem Reviewer Unsicherheit auf Herstellerseite. Sie erschwert die Nachvollziehbarkeit und produziert Abweichungen, selbst wenn die zugrunde liegenden Daten solide sind. Eine durchgehaltene Argumentationsstrategie ist ein wesentlicher Schutz.
Was ist der schnellste Weg, Schwachstellen in der Dokumentation zu finden?
Der Fremde-Augen-Test: Eine Person ohne Produktkenntnis liest ein zentrales Dokument und markiert, wo sie stockt. Diese Stellen zeigen zuverlässig, wo Reviewer der Benannten Stelle ebenfalls Probleme haben werden.
Fazit
Die meisten Abweichungen bei der Benannten Stelle sind vermeidbar. Sie entstehen nicht, weil Hersteller ihre Produkte schlecht entwickeln oder testen, sondern weil die Technische Dokumentation nicht für fachkundige Fremde ohne Zeitpuffer geschrieben ist.
Drei Hebel helfen am meisten: Kontext, der keine Fragen offenlässt. Belege, die direkt im Text verankert sind. Eine Argumentationsstrategie, die von Anfang bis Ende konsistent bleibt.
Wer seine Dokumentation vor dem nächsten Review auf diese drei Punkte prüft, reduziert Abweichungen strukturell, nicht durch Glück.
Sie wollen wissen, wo Ihre Dokumentation aktuell steht? Eine Gap-Analyse zeigt Ihnen die wichtigsten regulatorischen Lücken mit konkreten Verbesserungsvorschlägen, ohne dass Sie direkt alles neu aufsetzen müssen. Was Sie danach tun, liegt bei Ihnen: eigenständig nachbessern oder gemeinsam mit mir.
