Wie Schnittstellen in Unternehmen Wissen fragmentieren und TR die Arbeit erschweren
Unternehmensschnittstellen sind Folgen von Effizienzanstrengungen und Spezialisierung. Viele Schnittstellen und viel Spezialisierung führt zu Wissensfragmentierung, organisationaler Demenz und viel Rekonstruktionsarbeit für Technische Redakteure.
Dr. Harald Schenda
9/2/202610 min read
Warum die Krise der Technischen Redaktion auch eine Schnittstellenkrise ist
Neben der klassischen praktischen Fachkommunikation und der Fachkommunikationswissenschaft war und ist Wissensmanagement eines meiner zentralen Interessengebiete. Ich bin ein Konzernkind und habe über die vergangenen Jahrzehnte hinweg in solchen Unternehmen gearbeitet. Gerade in der Automobil- und Luftfahrtindustrie gibt es sehr konkrete Vorstellungen davon, wie Unternehmensprozesse gestaltet sein sollen und wie sie im Arbeitsalltag umzusetzen sind. Meine Perspektive darauf wurde dabei stark von den Berufen geprägt, die ich selbst ausgeübt habe. Entsprechend habe ich Prozesse in Konzernen vor allem aus der Sicht von Kommunikations- und Marketingfunktionen beobachtet.
Dieser Artikel bezieht sich vor allem auf die Lebensrealität Technischer Redakteure in großen Unternehmen. Die beschriebenen Effekte können unter Umständen auch in kleineren Organisationen auftreten. Es geht darum, wie Technische Dokumentation als Prozess organisiert ist, wie sie in übergeordnete Produktentwicklungsprozesse eingebunden wird und welche systematischen Probleme daraus entstehen.
Viele Unternehmen organisieren Produktentwicklung und Technische Dokumentation entlang funktionaler Zuständigkeiten. Vereinfacht sieht dies in großen Unternehmen häufig so aus:
Product Management (PM) / Product Development (PD) → Risikobeurteilung / Compliance → UX → Technische Redaktion
Jede dieser Disziplinen hat eigene Methoden, Fachleute, Prozesse und Qualitätskriterien. Damit bringt sie eine spezifische Perspektive auf das Produkt mit. Diese Aufteilung erscheint zunächst logisch: Entwicklung benötigt andere Kompetenzen als Konformitätsarbeit, UX-Design andere als Technische Redaktion. Zugleich sind UX, Technische Redaktion, Training und Service verwandte Kompetenz- und Wissensgebiete mit teilweise erheblichen fachlichen Überlappungen.
Die Aufteilung des Produktentwicklungsprozesses in unterschiedliche Schwimmbahnen schafft Abteilungen, daraus Berufe mit unterschiedlichen Schwerpunkten und schließlich eigene Hochschul- und Zertifikatsausbildungen. Problematisch wird Spezialisierung aber dort, wo fachliche Arbeitsteilung in zeitliche, organisatorische und informationelle Trennung umschlägt.
Die beteiligten Disziplinen bearbeiten nämlich keine voneinander unabhängigen Gegenstände. Sie betrachten ein gemeinsames technisches Produkt – und insbesondere dessen Nutzungssituation – aus unterschiedlichen Perspektiven.
Ein Produkt – vier Perspektiven
PM/PD
Produktentwicklung ist in großen Unternehmen bereits stark arbeitsteilig organisiert. Product Management übersetzt Markt-, Kunden- und Unternehmensanforderungen in Produktziele und priorisierte Entwicklungsbedarfe. Product Engineering beziehungsweise Product Development entwickelt daraus technische Lösungen. Bei etablierten Produkten entstehen Anforderungen etwa aus Roadmaps, Änderungsanforderungen, Rückmeldungen aus Markt und Service oder – besonders in softwaregeprägten Bereichen – aus Backlogs. Bei Neuprodukten geht dem Engineering häufig eine Phase voraus, in der Marktbedarf, strategischer Fit und wirtschaftliche Tragfähigkeit untersucht und gegenüber anderen Produktinitiativen verteidigt werden müssen. Produktentwicklung ist daher immer auch eine Portfolio- und Ressourcenentscheidung.
Danach setzt sich die Zerlegung fort. Im Maschinen- und Anlagenbau arbeiten beispielsweise Produktmanagement, Planung, Konstruktion, Simulation, Elektrik, Hydraulik und Softwareentwicklung am selben Produkt. Innerhalb der Software kommen Automatisierung beziehungsweise SPS, Maschinen-/Anlagen-IT, Data Science und weitere Spezialgebiete hinzu. Solche fachlichen Differenzierungen sind bei modernen mechatronischen und cyber-physischen Systemen unvermeidbar. Problematisch ist nicht die Spezialisierung selbst, sondern die Frage, wie Wissen und Kontext zwischen den Bereichen erhalten und integriert werden.
Auch Entwicklerinnen und Entwickler haben selbstverständlich Vorstellungen davon, wer ein Produkt später benutzt und wie dies geschieht. Diese Vorstellungen liegen aber nicht zwingend als explizites, gemeinsam verfügbares Modell der Benutzer und ihrer Nutzungssituation vor. Sie können implizit bleiben, über Requirements vermittelt sein oder sich primär aus der technischen Funktion ableiten. Erfahrene Entwickler verfügen häufig über reichhaltige mentale Modelle, die intuitive und implizite Anteile enthalten.
Human-Centered Design verlangt dagegen eine explizite Auseinandersetzung mit Benutzern, ihren Aufgaben und ihrem Nutzungskontext. Die Integrationslast liegt in vielen Organisationen zu einem erheblichen Teil beim Product Management: Markt, Kundenbedürfnisse, Business-Ziele, technische Machbarkeit und die Interessen zahlreicher Entwicklungsdisziplinen müssen austariert werden. Product Manager sind damit häufig zentrale Knotenpunkte eines hochgradig verteilten Entwicklungsprozesses.
Risikobeurteilung und Compliance
Compliance fragt, welche produkt- und marktspezifischen Gesetze, Richtlinien und Normen gelten. In der Risikobeurteilung wird die Frage gestellt, welche Gefährdungen mit dem Produkt, seiner bestimmungsgemäßen Verwendung und seiner vernünftigerweise vorhersehbaren Fehlanwendung verbunden sind.
In diesem Bereich entsteht ein besonders formalisiertes, nachweispflichtiges Modell der Nutzungssituation. Die Risikobeurteilung nach ISO 12100 verlangt die Festlegung der Grenzen einer Maschine einschließlich Verwendungs-, Raum- und Zeitgrenzen. Sie verlangt außerdem, Gefährdungssituationen über alle Lebensphasen hinweg zu identifizieren und die beteiligten Personengruppen zu berücksichtigen. ISO 14971 fordert für Medizinprodukte Entsprechendes über die Bestimmung von Merkmalen mit Sicherheitsbezug. Während Product Management und Engineering ihre Benutzermodelle teilweise implizit lassen können, müssen sie hier explizit beschrieben werden.
Diese Modelle entstehen jedoch in einer Form, die vorrangig auf Nachweisführung ausgerichtet ist. Sie sind nicht automatisch Gestaltungsartefakte.
Kritisch wird die organisatorische Sequenzialisierung genau an diesem Punkt. Die Risikobeurteilung ist ihrem Wesen nach kein einmalig zu erledigender Prozessbaustein. ISO 12100 beschreibt vielmehr einen iterativen Prozess aus Risikobeurteilung und Risikominderung: Nach jeder Maßnahme muss erneut beurteilt werden, ob Risiken verbleiben oder neue Gefährdungen entstanden sind. Die Rangfolge ist domänenübergreifend vergleichbar: zunächst inhärent sichere Konstruktion, danach technische und ergänzende Schutzmaßnahmen, erst zuletzt Benutzerinformation über Restrisiken. Dies entspricht den Grundsätzen der Sicherheitsintegration in Anhang III der Maschinenverordnung (EU) 2023/1230, der Risikobeherrschungshierarchie der ISO 14971 sowie den grundlegenden Sicherheits- und Leistungsanforderungen der MDR.
Dieser Konsens beschreibt eine Rangfolge von Gestaltungsmaßnahmen, keine Reihenfolge von Abteilungen.
Wird die Rückkopplung dennoch in eine Swimlane oder einen festen Meilenstein übersetzt – „Jetzt machen wir die Risikobeurteilung“ –, verändert sich implizit die Haltung. Ein erkanntes Risiko erscheint dann nicht als Anlass, erneut in Konstruktion oder Interaktionsdesign einzugreifen, sondern als Versuchung, das Problem in den nächsten Prozessschritt – die Technische Redaktion – weiterzureichen. Was am Produkt nicht mehr verändert werden kann oder soll, wird in die Anleitung geschrieben.
ISO 14971 verlangt, die Wirksamkeit umgesetzter Risikobeherrschungsmaßnahmen zu verifizieren, einschließlich der Information für die Sicherheit. IEC/IEEE 82079-1 setzt voraus, dass Nutzungsinformation Teil des Produkts ist, ihre Entwicklung parallel zur Produktentwicklung beginnt und Ergebnisse der Risikobeurteilung in sie einfließen. Beide Normen beschreiben Rückkopplung. In der Praxis werden sie jedoch häufig als Prüflisten gelesen.
Das eigentliche Schnittstellenproblem liegt damit nicht allein zwischen Risikobeurteilung und Technischer Redaktion. Es liegt darin, dass ein normativ geforderter Regelkreis organisatorisch in eine Prozesskette überführt wird. Diese Überführung kann in der Praxis verdeckt bleiben, wenn Restrisiken formal mit Benutzerinformation adressiert werden, obwohl frühere Maßnahmen nicht konsequent ausgeschöpft wurden.
UX
UX soll die Perspektive der Benutzer in die Produktentwicklung einbringen. Das klingt selbstverständlich, ist organisatorisch jedoch alles andere als einfach – insbesondere in etablierten Strukturen.
Normativ ist der Auftrag präzise gefasst. ISO 9241-210 verlangt einen Gestaltungsprozess, der auf einem expliziten Verständnis von Benutzern, Arbeitsaufgaben und Nutzungsumgebung beruht, Benutzer während Gestaltung und Entwicklung einbezieht, durch benutzerzentrierte Evaluierung gesteuert und verfeinert wird, iterativ verläuft und auf die gesamte Benutzererfahrung zielt. Zwei Anforderungen sind organisatorisch unbequem: Der Prozess soll früh beginnen und mehrere Iterationen durchlaufen. ISO 9241-11 verdeutlicht zusätzlich, dass jede Usability-Aussage sich auf Effektivität, Effizienz und Zufriedenheit in einem bestimmten Nutzungskontext bezieht. Für Medizinprodukte formalisiert IEC 62366-1 diese Perspektive mit der Use Specification: einem expliziten Artefakt über vorgesehene Benutzer, Nutzungsumgebung und Anwendungsprinzip, das in die Risikobeurteilung nach ISO 14971 zurückwirkt.
UX kann damit ein explizites und gestaltungsfähiges Modell der Nutzungssituation erzeugen. Entscheidend ist allerdings, wann dieses Modell entsteht und ob es in Entscheidungen zurückwirken darf. Wenn UX untersucht, wie Menschen ein Produkt verstehen, welche Aufgaben sie damit lösen und wo Interaktionen scheitern, berührt diese Arbeit zwangsläufig Bereiche, die Product Management und Entwicklung bereits bearbeitet haben. Product Management hat Funktionen priorisiert, Märkte definiert und Anforderungen formuliert. Engineering hat daraus technische Lösungen entwickelt. Stellt UX danach fest, dass Benutzer das Produkt anders verstehen als angenommen, liefert sie nicht bloß einen Gestaltungshinweis. Sie stellt bereits getroffene Entscheidungen infrage.
IEC 62366-1 unterscheidet formative und summative Evaluierung: Die formative Evaluierung begleitet die Gestaltung und verändert sie; die summative Evaluierung validiert am Ende das Ergebnis. Diese Unterscheidung ist methodisch, nicht organisatorisch. Wird UX jedoch zur Swimlane hinter dem Engineering, kollabiert sie faktisch: Was UX dann noch tut, ist überwiegend summativ. Eine summative Evaluierung kann ein Bedienkonzept bestätigen oder scheitern lassen – ändern kann sie es nicht mehr.
Die typische Reaktion ist vorhersehbar. Nach gemeinsamen Usability-Tests darf UX dort optimieren, wo Änderungen wenig kosten: Benennungen, Dialoge, Bildschirmaufteilungen oder Icons. Das Grundkonzept bleibt häufig unangetastet. Aus nutzerzentrierter Produktentwicklung wird kosmetisches Interface-Finishing.
Was dabei liegen bleibt, benennt ISO 9241-110 mit Interaktionsprinzipien wie Aufgabenangemessenheit, Selbstbeschreibungsfähigkeit, Erwartungskonformität und Robustheit gegen Benutzungsfehler. Diese Eigenschaften entstehen im Konzept, nicht im Finishing. Wo sie fehlen, muss sie eine weitere Reparaturinstanz in der Prozesskette herstellen – nur eine Station vor der Technischen Redaktion.
Technische Redaktion
Technische Redaktionen arbeiten in großen Unternehmen häufig stark prozess- und effizienzorientiert. Das hängt auch mit ihrer Position am Ende des Produktentwicklungsprozesses zusammen, an der Zeit und Budget besonders knapp sind.
Technische Redakteurinnen und Redakteure erhalten ein weitgehend fertiges Produkt und sollen erklären, wie dieses Produkt sicher und erfolgreich benutzt wird. Dafür müssen sie Fragen beantworten, deren Antworten oft in früheren Entwicklungsphasen entstanden sind:
Was ist im Vergleich zu Vorprodukten anders?
Welche Handlungen sind an der Benutzeroberfläche für das gewünschte Handlungsergebnis erforderlich?
Welche Benutzerkenntnisse wurden vorausgesetzt?
Welche Fehlbedienungen wurden in der Risikobeurteilung betrachtet?
Welche Gefährdungen sind allgemein, welche an bestimmte Handlungen oder Situationen gebunden?
Welche unterschiedlichen Bedienungstraditionen bestehen in verschiedenen Märkten?
Wenn die Technische Redaktion an diesen Entscheidungen nicht beteiligt war, muss sie deren Logik nachträglich rekonstruieren. Sie wird damit zur institutionalisierten Reverse-Engineering-Abteilung für Nutzungssituationen. Das erklärt ein bekanntes Phänomen: die Reparatur-Dokumentation.
Ist eine Bedienhandlung unnötig kompliziert, wird sie ausführlicher erklärt.
Ist die Terminologie der Benutzeroberfläche inkonsistent, versucht die Anleitung, diese Inkonsistenz aufzulösen
Ist eine Funktion nicht selbsterklärend, entsteht ein zusätzliches Absatz oder gar Kapitel.
Ist eine Fehlbedienung technisch möglich, wird ein Warnhinweis ergänzt.
Die Technische Redaktion kompensiert damit teilweise Probleme, deren Ursachen im Produkt, in der Benutzeroberfläche oder in früheren Designentscheidungen liegen. Statt Informationsbedarfe frühzeitig in die Produktgestaltung zurückzukoppeln, muss die Redaktion die Nutzungssituation aus verfügbaren Informationen rekonstruieren. Sie steht am Ende einer Kaskade von Wissensübersetzungen und soll daraus ein konsistentes Bild erzeugen. Verbleibende Brüche muss sie mit Information auffangen.
An Schnittstellen wird Wissen nicht einfach übergeben
Eine umfassende Definition von Wissen würde einen eigenen Artikel erfordern. Für den vorliegenden Zusammenhang genügt eine einfache Unterscheidung: Wissen ist an Menschen gebunden. Was im Einzelfall als Wissen gilt, hängt von der interpretierenden Instanz ab. Fachlich präziser ist es daher oft, von Informationen zu sprechen. Erst durch Rezeption sowie die Anbindung an Vorerfahrung und mentale Modelle entsteht beim Rezipienten Wissen.
Wenn in diesem Artikel von Wissen die Rede ist, sind damit deshalb meist Informationen, Repräsentationen und rekonstruierte Zusammenhänge gemeint.
Entlang des Produktentwicklungsprozesses entstehen neue Informationen, die an nachfolgende Prozesse übergeben werden müssen. Die Vorstellung eines sauberen „Handovers“ ist jedoch irreführend.
Ein Entwickler übergibt sein Wissen nicht vollständig an UX oder Technical Writing. Er übergibt Anforderungen, Tickets, Spezifikationen, CAD-Daten, Screenshots, technische Daten, Software, Prototypen und andere Artefakte. Aus einem komplexen mentalen Modell wird dabei zwangsläufig eine reduzierte Repräsentation.
Ein Entwickler weiß möglicherweise sehr genau,
warum eine Funktion auf bestimmte Weise umgesetzt wurde,
welche Alternativen verworfen wurden,
welche Randbedingungen gelten,
welche Fehlbedienungen bereits aufgetreten sind,
welche Annahmen über Benutzer gemacht wurden,
welche technischen Grenzen bestehen.
Im nächsten Prozessschritt ist davon häufig nur ein Teil sichtbar. Informationen wurden nicht explizit übertragen, konnten nicht vollständig übertragen werden oder werden von den Beteiligten in vorhandene mentale Modelle und Erklärungsmuster eingeordnet.
Mit jeder organisatorischen Schnittstelle steigt damit nicht nur der Kommunikationsaufwand. Die beteiligten Einheiten können zudem deutlich unterschiedliche modellhafte Repräsentationen desselben Produkts ausbilden.
Engineering, Risikobeurteilung, UX und Technische Redaktion arbeiten nicht auf vier voneinander unabhängigen Aktionsfeldern. Sie betrachten ein gemeinsames System aus unterschiedlichen Blickwinkeln. Der Erkenntnisgewinn, der aus dieser Perspektivenvielfalt entstehen könnte, wird in der Praxis zu selten systematisch zusammengeführt.
Wer den Produktentwicklungsprozess organisatorisch zuerst zerlegt und anschließend versucht, ihn über Schnittstellen wieder zusammenzusetzen, muss Informationsverluste, Doppelarbeit und Rekonstruktionsprobleme in Kauf nehmen. Die vermeintliche Krise der Technischen Redaktion ist deshalb zu einem erheblichen Teil eine Schnittstellenkrise.
Fazit
Die praktische Fachkommunikation aka Technische Redaktion leidet nicht nur an mangelnder Anerkennung ihrer Leistung. Sie leidet auch darunter, an welcher Stelle des Prozesses sie diese Leistung erbringen muss. Wer am Ende einer Kette steht, kann häufig nur noch kompensieren, was vorher entschieden wurde. Kompensation bleibt jedoch oft Reparaturarbeit – gleich, wie professionell sie ausgeführt wird.
Produktentwicklung verläuft naturgemäß in Schleifen und zahlreichen Iterationen. Unternehmen organisieren sie aber häufig in Bahnen. Entwicklung, Risikobeurteilung, Interaktionsgestaltung und Benutzerinformation bearbeiten dieselbe Nutzungssituation und müssten sich wechselseitig korrigieren. Stattdessen reichen sie überwiegend Artefakte weiter. Der Preis dieser Entkopplung sind Informationsverluste an Übergaben, Rekonstruktionsaufwand am Ende und – im ungünstigsten Fall – Restrisiken, die dokumentiert werden, weil sie an einen nachgelagerten Prozess delegierbar erscheinen.
Arbeitsteilung ist bei mechatronischen und cyber-physischen Systemen unvermeidbar. Auch sequenzielle Freigabelogiken haben gute Gründe: Sie machen Verantwortung zurechenbar und Termine planbar. Der Fehler liegt nicht in der Zerlegung selbst, sondern in der Annahme, das Zerlegte lasse sich allein durch Schnittstellen wieder zusammenfügen. Ein Regelkreis, der in eine Prozesskette überführt wird, ist kein Regelkreis mehr.
Wo diese Zerlegung zum Normalfall wird, bleibt der Technischen Redaktion genau eine Variable: ihr eigenes Ergebnis. Auf Designentscheidungen, Risikobeurteilung und Bedienkonzept hat sie oft keinen ausreichenden Einfluss. Sie kann das Dokument optimieren – und tut dies seit Jahrzehnten durch Modularisierung, Wiederverwendung, Standardisierung und Automatisierung. Diese Dokumentenfokussierung ist nicht die Ursache der Marginalisierung, sondern ihre Folge.
Die Ursache liegt in einer Prozessarchitektur, die an Schnittstellen Informationen und Kontext verliert und deren Rekonstruktion an die letzte Station delegiert – dorthin, wo Zeit und Budget aufgebraucht sind.
Die Organisation zerlegt eine dynamische, gekoppelte Nutzungssituation in fachliche Repräsentationen und erwartet am Ende von der Technischen Redaktion, daraus wieder ein kohärentes Handlungsmodell für den Benutzer herzustellen. Gute Nutzungsinformation braucht nicht nur bessere Übergaben. Sie braucht Zugriff auf die Entscheidungen, die sie erklären soll, und institutionalisierte Rückkopplung in die Produktgestaltung.
Die Krise der Technischen Redaktion ist deshalb nicht nur eine Krise des Berufsbilds. Sie ist auch eine Schnittstellenkrise.
Quellen:
IEC/IEEE 82079-1:2019. Preparation of information for use (instructions for use) of products – Part 1: Principles and general requirements. Genf: International Electrotechnical Commission / Institute of Electrical and Electronics Engineers. Deutsche Übernahme: DIN EN IEC/IEEE 82079-1:2021-09, Erstellung von Nutzungsinformationen (Gebrauchsanleitungen) für Produkte – Teil 1: Grundsätze und allgemeine Anforderungen.
IEC 62366-1:2015 + AMD1:2020. Medical devices – Part 1: Application of usability engineering to medical devices. Genf: International Electrotechnical Commission. Konsolidierte Ausgabe: IEC 62366-1:2015+AMD1:2020 CSV.
ISO 12100:2010. Safety of machinery – General principles for design – Risk assessment and risk reduction. Genf: International Organization for Standardization. Deutsche Übernahme: DIN EN ISO 12100:2011-03, Sicherheit von Maschinen – Allgemeine Gestaltungsleitsätze – Risikobeurteilung und Risikominderung.
ISO 14971:2019. Medical devices – Application of risk management to medical devices. Genf: International Organization for Standardization. Deutsche Übernahme: DIN EN ISO 14971:2022-04, Medizinprodukte – Anwendung des Risikomanagements auf Medizinprodukte.
ISO 9241-11:2018. Ergonomics of human-system interaction – Part 11: Usability: Definitions and concepts. Genf: International Organization for Standardization. Deutsche Übernahme: DIN EN ISO 9241-11:2018-11, Ergonomie der Mensch-System-Interaktion – Teil 11: Gebrauchstauglichkeit: Begriffe und Konzepte.
ISO 9241-110:2020. Ergonomics of human-system interaction – Part 110: Interaction principles. Genf: International Organization for Standardization. Deutsche Übernahme:
DIN EN ISO 9241-110:2020-10, Ergonomie der Mensch-System-Interaktion – Teil 110: Grundsätze der Dialoggestaltung.
ISO 9241-210:2019. Ergonomics of human-system interaction – Part 210: Human-centred design for interactive systems. Genf: International Organization for Standardization. Deutsche Übernahme: DIN EN ISO 9241-210:2019-03, Ergonomie der Mensch-System-Interaktion – Teil 210: Menschzentrierte Gestaltung interaktiver Systeme.
Rechtsquellen
Verordnung (EU) 2017/745 des Europäischen Parlaments und des Rates vom 5. April 2017 über Medizinprodukte, zur Änderung der Richtlinie 2001/83/EG, der Verordnung (EG) Nr. 178/2002 und der Verordnung (EG) Nr. 1223/2009 und zur Aufhebung der Richtlinien 90/385/EWG und 93/42/EWG des Rates. Amtsblatt der Europäischen Union L 117 vom 5. Mai 2017, S. 1–175. Konsolidierte Fassung verwenden.
Verordnung (EU) 2023/1230 des Europäischen Parlaments und des Rates vom 14. Juni 2023 über Maschinen und zur Aufhebung der Richtlinie 2006/42/EG des Europäischen Parlaments und des Rates und der Richtlinie 73/361/EWG des Rates. Amtsblatt der Europäischen Union L 165 vom 29. Juni 2023, S. 1–102.
Theoretische Bezugsliteratur
Bühler, Karl (1934). Sprachtheorie: Die Darstellungsfunktion der Sprache. Jena: Gustav Fischer.
Schenda, Harald (2024). Mikroprozesse der Bediensituation. Berlin. Frank & Timme.