Grundsätzlich korrekt!

Text: Marco Hattemer Roland Schmeling

Informationen müssen sachlich richtig und aktuell sein. Das gilt für jede Technische Dokumentation. Die Korrektheit ist daher ein Grundsatz der Informationsqualität nach DIN EN IEC/IEEE 82079-1. Für die redaktionellen Prozesse ergeben sich daraus wesentliche Konsequenzen.

Inhaltsübersicht

Lesedauer: 11:33 Minuten

Funktionsbeschreibungen müssen die tatsächlichen Funktionen und Leistungen eines Produkts widerspiegeln. Abbildungen müssen den Gegebenheiten entsprechen, mindestens bei den Bildinhalten, die für den kommunikativen Zweck eine Rolle spielen. Beschreibungen von Handlungen und Störungsbehebungen müssen tatsächlich so ausführbar sein wie beschrieben und zum versprochenen Ziel führen. Lieferantendokumente müssen zu den tatsächlich verbauten Teilen und Komponenten passen. 

Korrektheit wird in der DIN EN IEC IEEE 82079-1:2021 (im Folgenden „82079-1“) so erklärt: „Nutzungsinformationen müssen fachlich korrekt sein und die neuesten Informationen zum unterstützten Produkt enthalten, auf das sich die Nutzungsinformation bezieht.“

Korrektheit und Präzision

„Streng genommen hat die Bohrung ja gar nicht 4 mm, sondern 4,05 mm Durchmesser.“ Ist deshalb die Angabe von 4 mm in der Anleitung inkorrekt? Eher nicht: Soweit für den Zweck der Information die Genauigkeit der präziseren Angabe keine Rolle spielt, würden wir sagen, dass „Durchmesser der Bohrung = 4 mm“ korrekt ist. Insofern hängt die Präzision als Teil der Korrektheit vom Informationsbedarf ab.

Der Informationsbedarf ist zwar grundsätzlich abhängig von der Zielgruppe; ein direkter Zusammenhang zwischen Präzision und Zielgruppe ergibt sich aber nicht. Wie präzise eine Angabe sein muss, ergibt sich aus dem Beschreibungsgegenstand und nicht aus den Eigenschaften einer Zielgruppe. Korrektheit in unserem Sinne ist unabhängig von der Zielgruppe, weshalb korrekte Angaben auch von Personen geprüft werden, die nur wenig Kenntnisse über die Zielgruppen haben. Das ist wichtig zu wissen, denn so ist es möglich, die Verantwortung für Korrektheit mit Personen zu teilen, die weniger einen Blick auf die Zielgruppe und mehr auf die Technik des Produkts haben.

Die Präzision ist kein eigener Qualitätsgrundsatz der Norm (wie in anderen Qualitätsmetriken, zum Beispiel bei Martin Eppler, „Managing Information Quality“, 2006). Wenn wir die Grundsätze der Norm als Rahmen für die Informationsqualität von Nutzungsinformationen betrachten, sollten wir beim Qualitätsgrundsatz der Korrektheit das richtige Maß an Präzision stets mitdenken.

Korrektheit und Aktualität

Korrektheit schließt ausdrücklich die Aktualität ein: „Wenn das unterstützte Produkt modifiziert wird, muss der Bedarf an Änderungen an der Nutzungsinformation evaluiert werden.“, heißt es in der 82079-1. Eine Produktänderung durch Entwicklung und Konstruktion und damit Auslöser der Aktualisierung kann auch in einer späteren Phase des Produktlebenszyklus liegen. Das ist oft bei Maschinen oder Software der Fall.

Ähnlich wie die Vollständigkeit wird Korrektheit im Prozess sichergestellt (Inf. 01). Genauer gesagt passiert dies in der funktions- oder abteilungsübergreifenden Zusammenarbeit, insbesondere zwischen Redaktion („Informationsentwicklung“) und den übrigen Disziplinen der Produktentwicklung (Mechatronik, Elektrokonstruktion und Programmierung).

Bisher erschienen

Ausgabe 01/22, „Eine Norm mit Grundsätzen“, S. 45–50. 
Ausgabe 02/22, „Grundsätzliches zur Zielgruppe“, S. 37–42.
Ausgabe 03/22, „Grundsätzliches zur Sicherheit“, S. 35–38.
Ausgabe 03/22, „Sicherheit im Überfluss?“, S. 39–41.
Ausgabe 04/22, „Konform durch Benutzungsinformation“, S. 36–40.
Ausgabe 05/22, „Grundsätzliches zur Vollständigkeit“, S. 36–40.

Inf. 01

Korrektheit bei Welt-Wort-Bezug

Was bedeutet Korrektheit bei einem Warnhinweis? Kann ein Warnhinweis „wahr“ oder „falsch“ sein? Ist der Warnhinweis nur dann „korrekt“, wenn die „zugesagten“ Folgen tatsächlich eintreten? Und was bedeutet Korrektheit bei Anforderungen an die Personalqualifikation?

Vorhersagen, Anforderungen und Aufforderungen sind keine Aussagesätze im Sinne der Logik. Sie können daher keinen Wahrheitswert haben. Soweit der Begriff „Korrektheit“ sich nur auf den Wahrheitswert bezieht, ist er auf diese Inhalte nicht anwendbar. Aber spielt Korrektheit deshalb keine Rolle? Immerhin sind auch in diesen Nicht-Aussagesätzen implizit Aussagen verborgen.

Intuitiv würden wir bei einer Handlungsbeschreibung, die mit dem Produkt in dieser Weise nicht ausführbar ist, durchaus sagen: „Das ist nicht korrekt, das geht so nicht.“ Oder bei einem überzogenen Warnhinweis, der bei einer Stromquelle hinreichend geringer Leistung Lebensgefahr verspricht: „Das stimmt so nicht, davon wird man nicht sterben.“

Der Begriff der Korrektheit in der 82079-1 sollte in diesem erweiterten Sinn verstanden werden: Unter Korrektheit bei handlungsauffordernden Inhalten sollten wir die Kohärenz zwischen den Handlungsschritten und dem versprochenen Handlungsziel verstehen. Einen Warnhinweis sollten wir im weitesten Sinne als „korrekt“ ansehen, wenn die impliziten Aussagen korrekt sind und die möglichen Folgen mit einer hinreichenden Aufrichtigkeit in der Sache ermittelt und formuliert werden. Übertriebene Warnhinweise sind in diesem Sinne nicht mehr ganz „korrekt“ – ganz abgesehen vom „Overwarning“ (Inf. 01).

Das kann schiefgehen

Aus Videoprojekten wird deutlich, dass immer wieder bestehende Handlungsanleitungen sachlich nicht stimmen, obwohl sie professionell erstellt und von der Produktentwicklung geprüft und freigegeben wurden. Die Ursache liegt darin, dass für eine Prüfung die Zeit fehlt (mehr dazu in den Abschnitten über das Review).

Verantwortung für Korrektheit

Wer ist im Unternehmen für die Korrektheit der bereitgestellten Nutzungsinformationen verantwortlich? Zunächst scheint die Antwort klar: Die für das beschriebene Produkt Verantwortlichen aus Entwicklung und Konstruktion. Ist der Fall damit geklärt und die Redaktion kann die Verantwortung für die Korrektheit bequem auf Produktentwicklung und Konstruktion abwälzen? Die Antwort auf die Frage ist ein klares „Nein“.

Die Technische Redaktion trägt für die Erfüllung aller Grundsätze der Informationsqualität gemäß 82079-1 die Verantwortung, auch für die Korrektheit der Nutzungsinformationen. Sie ist jedoch auf die Zusammenarbeit angewiesen. Dieser Zusammenarbeit kann sich die Produktentwicklung nicht entziehen. Die 82079-1 formuliert im Abschnitt 5.2.2 deutlich: „Die Nutzungsinformation ist ein integraler Bestandteil des unterstützten Produkts und muss die gleiche Aufmerksamkeit und Bedeutung erhalten wie jeder andere Teil des Produkts“.

Verzahnung als Erfolgsfaktor

Nur durch die Zusammenarbeit von Technischer Redaktion und Produktentwicklung kann die Korrektheit von Nutzungsinformationen sichergestellt werden – und die Technische Redaktion kann durch das Gestalten der notwendigen Prozesse die Arbeit der Produktentwicklung steuern und vereinfachen. Anders formuliert: Informationsmanagementprozess (IMP) und Produkt­entstehungsprozess (PEP) müssen verzahnt werden. Dazu finden sich die wesentlichen Anforderungen zur Korrektheit im Text der 82079-1 im Kapitel 6 „Informationsmanagementprozess“.

In der Praxis lassen sich aus Sicht des Prozessmanagements für die Verzahnung von IMP und PEP folgende Anforderungen ableiten:

  • Alle Schnittstellen und Verantwortungs­übergänge zwischen den Prozessen sind sauber definiert und dokumentiert.
  • Alle Prozessbeteiligten und -verantwortlichen stimmen über die definierten Prozesse und Schnittstellen überein.
  • Informations- und Produktentwicklung stimmen sich regelmäßig über offene Fragen zu den Produkten und Inhalten sowie über den aktuellen Stand der Prozesse und anstehende Aufgaben ab. Hier besteht Potenzial für Automatisierung.

Bereits an der Quelle

Lasten- und Pflichtenhefte, Entwicklungsspezifikationen, Zeichnungen, Risikobeurteilung und Prototypen gehören (neben der direkten Kommunikation mit der Produktentwicklung) zu den Informationsquellen der Technischen Redaktion. In diesen Quellen werden im PEP bereits zu einem frühen Zeitpunkt Zielgruppen, bestimmungsgemäße Verwendung, Aufbau- und Funktionsbeschreibungen, grundlegende Sicherheitsvorkehrungen und Maßnahmen zur Risikominimierung spezifiziert.

Im Idealfall werden diese Spezifikationen von der Redaktion parallel zur Produktentwicklung redigiert und später in die Nutzungsinformation übernommen. Dafür muss die Redaktion in die Erstellung dieser Spezifikationen eingebunden werden. Sprich: Redaktion und Entwicklung arbeiten frühzeitig zusammen, und die Redaktion stellt die notwendige Informationsqualität, terminologische Konsistenz und Einhaltung von Schreib- und Formulierungsregeln sicher – zumindest bei den als relevant identifizierten Inhalten.

Dies hört sich zunächst nach einer erheblichen Zeit- und Arbeitsbelastung an. Im weiteren Projektverlauf machen sich diese Belastungen aber durch weniger Abstimmungen, Rückfragen und Korrekturen sowie schnellere und reibungslosere Review­prozesse bezahlt. Auch hier gilt: Je später im Prozess ein Fehler identifiziert wird, desto höher ist der Aufwand, ihn zu beheben.

Zudem wird die Verzahnung von Entwicklung und Technischer Redaktion gestärkt, und die Wahrnehmung des Beitrags der Redaktion zum Unternehmenserfolg verbessert.

Automatisierung erhöht Korrektheit

Für bestimmte Inhaltstypen kann die Korrektheit über die Implementierung von Schnittstellen sichergestellt werden. Voraussetzungen für diese Prozesssicherheit sind, dass es für diese Inhalte ein definiertes „Single Source“ im Unternehmen gibt. Außerdem, dass die Korrektheit der Inhalte an dieser Quelle durch Prozesse und Prüfungen sichergestellt ist. Beispiele für geeignete Inhaltstypen sind:

  • Artikel-, Produkt- oder Serien­nummern von Produkten oder Bau- und Ersatzteilen aus ERP-Systemen
  • Maßzeichnungen aus PDM- oder PLM-Systemen
  • Technische Daten, wie Abmessungen oder Gewichte aus PIM-Systemen

Da sich diese Inhalte im Laufe des Prozesses ändern, muss die Schnittstelle die Möglichkeit bieten, die übernommenen Inhalte nachträglich zu aktualisieren. Technisch lässt sich dies in einem modernen CCMS (Component-Content-Management-System) sicherstellen, beispielsweise über die Verwendung von Variablen und Platzhaltern.

Keine Korrektheit ohne Prüfung

Wenden wir uns der Prüfung und Freigabe von Informationen zu. Dieser Teilprozess hat zur Erfüllung des Grundsatzes der Korrektheit maßgebliche Bedeutung. Wie müssen Reviewprozesse in der Praxis gestaltet sein und wie kann die Redaktion die Prüfenden bei ihrer Aufgabe unterstützen und damit zur Korrektheit von Informationen aktiv beitragen? Sechs Aspekte möchten wir ansprechen:

  1. Prüfung im Prozess verankern und einplanen
  2. Qualitätsziele und -anforderungen definieren
  3. Verantwortung für die Prüfung im Prozess definieren
  4. Umfang der Prüfung definieren und Prüfung vorbereiten
  5. Aufmerksamkeit der Prüfer aktiv lenken
  6. Korrekturen effizient einarbeiten

Prüfung im Prozess verankern und einplanen: Im Abschnitt 6.3.3 fordert die 82079-1: „Projektzeitpläne sollten Zeit für Reviews und Behebungen signifikanter Mängel einplanen und dabei, falls erforderlich, wiederholte Reviews berücksichtigen“. Dies betrifft in der Praxis nicht nur den IMP der Redaktion. Auch im PEP muss die Prüfung als Prozessschritt verankert und der hierfür benötigte Bedarf von Zeit und Ressourcen in Entwicklung, Konstruktion und Produktmanagement kalkuliert und eingeplant werden.

Unzureichende Prüfungen aufgrund von Zeit- und Ressourcenengpässen bei nahenden Abgabeterminen sind ansonsten an der Tagesordnung, wie viele Technische Redaktionen aus eigener Erfahrung bestätigen können.

Qualitätsziele und -anforderungen definieren: Zur Verankerung des Reviews in den Prozessen gehört auch die Definition von klaren und nachvollziehbaren Qualitätszielen und -anforderungen, wie sie die 82079-1 im Abschnitt 5.4 fordert. Diese bilden die Grundlage für die Beurteilung, ob eine erstellte Nutzungsinformation „korrekt“ im Sinne der definierten Kriterien ist oder nicht.

Die Dokumentation dieser Ziele und Anforderungen sollte zentral im Rahmen des Qualitätsmanagements erfolgen. Zusätzlich können sich kunden- oder projektspezifische Anforderungen aus Lastenheften, Spezifikationen oder Angebotsunterlagen ergeben, die im Prozess berücksichtigt werden müssen.

Verantwortung für die Prüfung im Prozess definieren: Im Absatz 6.3.3 führt die 82079-1 weiter aus: „Eine benannte Person muss die Review-Instanz darstellen, die bestimmt, ob die Nutzungsinformation den Review-Kriterien entspricht und mit der nächsten Phase fortgefahren werden kann“. Oftmals wird in Unternehmen diese Verantwortung von einer Person mit Leitungsfunktion (zum Beispiel aus Entwicklung und Konstruktion) übernommen, die sich auf das Urteil kompetenter Personen stützt.

Blicken wir auf das Review-Kriterium „Korrektheit“: Damit dieser Reviewprozess in der Praxis effizient funktioniert, sind die benannten Personen verantwortlich für bestimmte Produktkomponenten und -bereiche, etwa allgemeine Produktsicherheit, Elektronik, Hydraulik/Pneumatik, Steuerung und Software-Komponenten. Dadurch steigen zunächst Aufwand und Komplexität für die Planung. Der Prüfaufwand kann aber auf mehrere Schultern verteilt werden. Außerdem können sich die Verantwortlichen auf bestimmte Aspekte der Prüfung konzentrieren. Die klare und lückenlose Zuweisung von Verantwortung zu einzelnen Personen ist immer noch das beste Mittel gegen Verantwortungsdiffusion.

Wie bei allen Definitionen von Prozessverantwortlichkeiten sollten Stellvertretungen benannt sein, um Urlaub, Krankheit oder zeitliche Überlastung abzufangen.

Umfang der Prüfung definieren und Prüfung vorbereiten: Es gilt der Grundsatz, dass für Inhalte, für die die Technische Redaktion die alleinige Verantwortung übernehmen kann, keine explizite fachliche Prüfung notwendig ist. Tabelle 01 zeigt Beispiele für solche Inhalte aus der Praxis. Prozessseitig muss sichergestellt sein, dass alle Beteiligten über den geforderten Umfang der Prüfung informiert sind.

Tabelle mit Beispielen für eine Prüfung.
Tab. 01 Quelle Marco Hattemer und Roland Schmeling

Zusätzlich sollte ein Lektor oder Editor die Inhalte nach dem Vier-Augen-Prinzip prüfen. In kleineren Redaktionen kann dies auch eine Technische Redakteurin oder ein Redakteur sein – mit entsprechender Qualifikation, Rolle und Zeitkontingent. Diese Prüfung stellt die redaktionelle Qualität und Konformität aller Inhalte sicher, die in der Verantwortung der Redaktion liegen. Eine Checkliste erleichtert Dokumentation, Transparenz und Nachvollziehbarkeit und erhöht damit die Prozesssicherheit.

Status und Gültigkeit der zu prüfenden Inhalte sollten klar gekennzeichnet sein, damit die Prüfenden ihre Arbeit auf die wichtigsten Inhalte und Änderungen fokussieren können:

  • Welche Inhalte sind Standard­textbausteine, die in jeder Anleitung enthalten sind und aus diesem Grund nicht geprüft werden müssen?
  • Welche Inhalte wurden bereits geprüft und haben sich seit der letzten Freigabe nicht geändert?
  • Welche Inhalte gelten für bestimmte Produktvarianten, welche Inhalte sind für mehrere Varianten gültig und werden produktübergreifend verwendet?

Diese (Meta-)Informationen sind in modernen CCMS normalerweise auf Ebene der Textbausteine/Module vorhanden. Sie können über angepasste Publikationsstrecken (oder im CCMS integrierte Review-Clients) den Prüfenden bereitgestellt werden.

Aufmerksamkeit der Prüfer aktiv lenken: Wer die richtigen Fragen stellt, bekommt bessere Antworten. Je gezielter die Technische Redaktion die Aufmerksamkeit der Prüfenden auf offene Fragen oder Unklarheiten lenkt, desto besser. Meist hat die Technische Redaktion einen guten „Riecher“, wo in den erstellten Inhalten Unsicherheiten und Probleme schlummern, die gegen die fachliche Korrektheit verstoßen.

Checklisten als Handreichung für die Prüfenden führen in diesem Fall nicht zum Ziel. Sie sind zwar ein Schritt in die richtige Richtung eines differenzierteren Reviews. Checklisten greifen aber meist zu kurz und sind zu unspezifisch, weil sie nicht mit den konkreten Inhalten verknüpft sind. Im Extremfall sind sie kontraproduktiv, wenn sie von den Prüfenden als zusätzliche Arbeitslast wahrgenommen werden.

Besser ist, die erstellten Inhalte über Anmerkungen und Kommentare mit Fragen zu verknüpfen: „Ist diese technische Angabe korrekt?“ statt „Bitte diesen Abschnitt prüfen.“ Gezielte Fragen erleichtern den Prüfenden die Arbeit, erhöhen die Wirksamkeit der Prüfung und stellen sicher, dass die zur Prüfung eingeplante Zeit zur Klärung der wesentlichen Fragen verwendet werden kann. Art, Formulierung und Reihenfolge der gestellten Fragen wirken sich dabei ebenfalls auf die Prüfeffizienz aus.

Tabelle 02 zeigt zur Verdeutlichung Beispiele für die Verknüpfung von Inhalten mit konkreten Fragen aus einem Kundenprojekt.

Tabelle mit Beispielfragen.
Tab. 02 Quelle Marco Hattemer und Roland Schmeling

Korrekturen effizient einarbeiten: Die 82097-1 macht bewusst keine Angaben zur technischen Ausgestaltung der Prüfung. In der Praxis sind Workflows auf PDF-Basis immer noch weit verbreitet und bewährt. Hierüber lassen sich in der Regel zusammen mit einem modernen CCMS alle angesprochenen Prozessanforderungen leicht und zuverlässig umsetzen.

Einige CCMS bieten die Möglichkeit, Reviews über die direkte Kommentierung der Inhalte in der Datenbank durchzuführen. Die damit verbundenen Workflows und die nachvollziehbare Dokumentation der Kommunikation und Abstimmung von Kommentaren in der Datenbank erhöhen die Prozesssicherheit. Zudem entfallen für die Redaktion Medienbrüche bei der Übernahme und Einarbeitung von Korrekturen.

Unabhängig von der technischen Gestaltung gilt der Grundsatz: Die fachlich Prüfenden sind für die Identifikation von fachlichen Fehlern zuständig. Die Technische Redaktion trägt die Verantwortung für die redaktionelle Umsetzung zur Behebung erkannter Fehler. Auswahl, Darstellung, Formulierung und Struktur der Inhalte sind ohnehin die Kernkompetenz und Verantwortung der Redaktion.

Granularität als Prüfinstrument

Je früher eine Prüfung im Prozessverlauf ansetzt und je früher in den Inhalten Mängel und Fehler erkannt und behoben werden, desto besser. Nicht zuletzt haben wir Zeit- und Ressourcenmangel sowie Abgabetermine als Haupthindernisse für einen effizienten Reviewprozess identifiziert.

Ein wirksames Mittel, um diesen Problemen entgegenzuwirken, ist die Prüfung von granularen Inhalten auf Ebene der Textbausteine und Module als Ergänzung zum Review fertiger Informationsprodukte. Ein Review auf feingranularer Ebene stellt jedoch deutlich höhere Anforderungen an das Änderungsmanagement. Diese Anforderungen müssen im Prozess gewährleistet sein.

Daher kann in der Praxis ein solches Review zunächst für bestimmte Informationsarten etabliert werden, die im Erstellungsprozess frühzeitig fertiggestellt werden können und sich im weiteren Verlauf nicht mehr stark ändern. Beispiele sind allgemeine Sicherheitshinweise und Produktbeschreibungen.

Eine Frage der Kontinuität

Die angesprochenen Aspekte zur Prozessgestaltung bieten bereits einen guten Überblick, wie die Technische Redaktion den Grundsatz der Korrektheit von Nutzungsinformationen umsetzen und im Arbeitsalltag sicherstellen kann. Die 82079-1 listet im Abschnitt 6.3.3 noch eine ganze Reihe weiterer Maßnahmen und empirischer Methoden auf (Abb. 01). Ziel dieser Methoden ist, dass „Reviews und Tests der Nutzungsinformation […] im gesamten Informationsentwicklungsprozess durchgeführt werden“.

Mit einer einmaligen und isolierten Prüfung der Inhalte am Ende des redaktionellen Erstellungsprozesses ist es nicht getan. In der Kontinuität der Maßnahmen liegen für die Technische Redaktion die Chance – und die Verantwortung –, ein umfassendes Qualitätsmanagement für den gesamten IMP aufzubauen. Hier schließt sich der Kreis zu den weiteren Grundsätzen der 82079-1 für die Informationsqualität.

Übersicht über Prüfmethoden.
Abb. 01 Empirische Methoden zur weiteren Prüfung (Auszug). Quelle DIN EN IEEE/IEC 82079-1

Hand mit Stempel und Papier.