Review technischer Dokumentation: Was geprüft werden muss – und was die meisten Prüfer übersehen

Ich habe in der Konzern-Vorentwicklung hunderte technische Dokumente gelesen, geprüft und freigegeben: Simulationsberichte, Auslegungsnachweise, Lastenhefte, Prüfberichte von Lieferanten. Die meisten waren vollständig. Viele waren gut formatiert. Erstaunlich wenige beantworteten die Frage, für die sie geschrieben wurden.

Das ist der Kern des Problems: Ein Review technischer Dokumentation wird meistens als Vollständigkeitsprüfung durchgeführt. Sind alle Kapitel da, stimmen Versionsnummer und Verteiler, fehlt ein Diagramm? Das ist notwendig – aber es ist nicht das Review. Das Review beginnt dort, wo gefragt wird, ob das Dokument die Entscheidung trägt, die darauf aufbaut.

Drei Ebenen, die ein Review unterscheiden muss

Technische Dokumentation kann auf drei Ebenen scheitern, und jede braucht einen anderen Blick:

• Vollständigkeit. Ist alles da, was das Dokument laut Vorlage, Norm oder Auftrag enthalten muss? Das prüft eine Checkliste. Fachwissen braucht es dafür kaum.
• Richtigkeit. Stimmen Zahlen, Einheiten, Formeln, Bezüge? Passt das Ergebnis zu den Eingangsdaten? Das prüft ein Fachkollege – und findet dabei Rechenfehler, vertauschte Randbedingungen, veraltete Materialwerte.
• Belastbarkeit. Trägt das Dokument die Entscheidung, für die es geschrieben wurde? Sind die Annahmen für diesen Anwendungsfall zulässig? Ist die Aussage so formuliert, dass sie eine Freigabe rechtfertigt – oder nur so, dass sie nicht falsch ist? Das prüft ein Review. Und das ist die Ebene, die in der Praxis am häufigsten fehlt.

Sieben Prüfpunkte für das Review technischer Dokumentation

Die folgenden Punkte gehe ich bei jedem Review durch – unabhängig davon, ob es um einen Simulationsbericht, einen Auslegungsnachweis oder die Dokumentation eines Lieferanten geht. Sie sind bewusst nicht nach Kapiteln sortiert, sondern nach dem, was eine Entscheidung braucht.

1. Steht die Frage im Dokument? Nicht das Thema, die Frage. „Thermische Simulation Steuergerät XY" ist ein Thema. „Bleibt die Sperrschichttemperatur von Bauteil U7 bei 85 °C Umgebung und Dauerlast unter 125 °C?" ist eine Frage. Ein Dokument ohne explizite Frage kann nicht beantwortet werden – und wird deshalb von jedem Leser anders interpretiert. Was ein Auftraggeber dafür vorab festlegen sollte, habe ich im Lastenheft für ein technisches Review beschrieben.

2. Sind die Annahmen explizit – und zulässig? Jedes technische Ergebnis steht auf Annahmen: Materialdaten, Randbedingungen, Lastfälle, Vereinfachungen. Das Review prüft zwei Dinge. Erstens: Sind sie aufgeschrieben, oder stecken sie im Modell und in den Köpfen? Zweitens: Sind sie für den Anwendungsfall zulässig? Ein Wärmeübergangskoeffizient aus dem Lehrbuch ist eine Annahme. Ob er für ein vergossenes Gehäuse im Motorraum gilt, ist eine Frage, die das Dokument beantworten muss – nicht der Leser.

3. Ist die Kette vom Eingang zum Ergebnis nachvollziehbar? Eingangsdaten, Methode, Zwischenergebnisse, Endergebnis. Ein Reviewer muss diese Kette ohne Rückfrage nachgehen können. Wo sie reißt – ein Diagramm ohne Datenquelle, ein Faktor ohne Herleitung, ein Ergebnis aus „einer früheren Untersuchung" – dort ist die Belastbarkeit nicht mehr prüfbar. Und was nicht prüfbar ist, ist für eine Freigabe nicht vorhanden.

4. Wurde validiert – und wogegen? Ein Ergebnis ohne Abgleich ist eine Hypothese. Das gilt für Simulationen besonders: Ohne Netzunabhängigkeitsnachweis, ohne Vergleich mit Messung, Referenzfall oder analytischer Abschätzung ist ein farbiges Temperaturbild eine Illustration, kein Nachweis. Das Review fragt nicht, ob validiert wurde, sondern wogegen – und ob dieser Vergleich für die Fragestellung relevant ist.

5. Sind Unsicherheit und Abstand zum Grenzwert benannt? „Maximaltemperatur 118 °C, Grenzwert 125 °C, Anforderung erfüllt." Dieser Satz steht in vielen Berichten – und sagt nichts, solange die Unsicherheit fehlt. 7 K Reserve sind komfortabel, wenn die Streuung der Eingangsgrößen 2 K ausmacht. Sie sind nichts, wenn allein die Kontaktwiderstände 10 K verschieben können. Ein belastbares Dokument nennt die Reserve und die Unsicherheit. Fehlt die zweite, muss das Review sie einfordern.

6. Stimmen Versionsstand und Bezüge? Der unspektakulärste Punkt – und der, an dem in der Praxis am meisten schiefgeht. Bezieht sich der Bericht auf den Konstruktionsstand, der freigegeben werden soll? Oder auf den von vor drei Änderungsschleifen? Sind referenzierte Normen, Spezifikationen und Vorgängerdokumente in der genannten Version noch gültig? Ein Nachweis für den falschen Stand ist kein Nachweis.

7. Ist die Schlussfolgerung so formuliert, dass sie eine Entscheidung trägt? Der letzte Absatz eines technischen Dokuments ist der wichtigste – und oft der schwächste. „Die Ergebnisse zeigen, dass die Auslegung grundsätzlich geeignet erscheint" ist keine Aussage, hinter die sich jemand stellt. Das Review prüft, ob die Schlussfolgerung eindeutig ist, ob sie aus den Ergebnissen folgt, und ob offene Punkte als solche benannt sind – statt in Konjunktiven zu verschwinden.

Woran Reviews in der Praxis scheitern

Der Prüfer ist der Autor. Wer das Modell gebaut und die Annahmen gesetzt hat, findet die Schwachstelle darin nicht – nicht aus Nachlässigkeit, sondern weil er sie längst nicht mehr als Annahme wahrnimmt. Ein Review technischer Dokumentation braucht Distanz zum Dokument. Das kann ein Kollege aus einem anderen Team leisten, ein Fachbereich mit anderer Perspektive – oder ein externes Review, wenn intern die Distanz oder die Zeit fehlt.

Das Review kommt zu spät. Ein Dokument, das drei Tage vor dem Meilenstein zur Prüfung kommt, wird durchgewinkt. Nicht weil der Prüfer nachlässig ist, sondern weil ein Befund zu diesem Zeitpunkt den Meilenstein kostet – und niemand das verantworten will. Das Review muss so früh angesetzt werden, dass ein Befund noch bearbeitet werden kann.

Der Prüfumfang ist nicht definiert. „Schau mal drüber" erzeugt ein Review, das Tippfehler findet. Wer ein belastbares Ergebnis will, muss vorher festlegen, welche Frage das Review beantworten soll, welche Unterlagen dazu gehören und in welcher Form der Befund erwartet wird. Wie das konkret abläuft, steht in Wie läuft ein technisches Review ab?

Was das für die Praxis bedeutet

Ein Review technischer Dokumentation ist keine Korrekturlesung und keine Formatprüfung. Es ist die Frage, ob ein Dokument die Entscheidung trägt, für die es geschrieben wurde. Die sieben Prüfpunkte lassen sich in einer Stunde durchgehen – und sie zeigen in den meisten Fällen bereits, ob ein Dokument freigabefähig ist, nachgebessert werden muss oder ob die eigentliche Frage nie gestellt wurde.

Wer diese Prüfung intern verankert, spart sich später die teure Variante: die Erkenntnis nach der Freigabe, dass der Nachweis den falschen Stand, die falsche Annahme oder gar keine Frage beantwortet hat. Und wer sie extern beauftragt, sollte genau diese sieben Punkte als Prüfumfang vorgeben – dann ist das Ergebnis vergleichbar, dokumentiert und belastbar.

Genau so arbeite ich in meinen technischen Reviews: entlang einer definierten Frage, mit dokumentierten Prüfpunkten, mit einem Befund, hinter dem ich stehe.