Die Technische Dokumentation steht an einem entscheidenden Wendepunkt. Lange Zeit wurde sie primär als nachgelagerter Prozess betrachtet, dessen Hauptziel die Erstellung rechtskonformer Handbücher war. Doch in einer zunehmend digitalisierten Welt, in der Nutzer Informationen in Echtzeit, kontextbezogen und auf unterschiedlichsten Endgeräten erwarten, reicht der klassische Redaktionsansatz nicht mehr aus. Hier tritt Content Engineering auf den Plan. Es ist die Disziplin, die Inhalte nicht mehr als statischen Text, sondern als strukturierte Daten begreift. Für Informations- und Digitalverantwortliche ist dieser Shift essenziell: Ohne sauberes Content Engineering gibt es keine funktionierende Automatisierung, keine effiziente KI-Integration und keine skalierbaren Informationsprozesse.
Was Content Engineering für Unternehmen typischerweise bedeutet
Der Übergang zum Content Engineering erfordert ein Umdenken in der Art und Weise, wie Informationen im Unternehmen fließen und verwaltet werden. Es geht nicht mehr nur um das Schreiben, sondern um das Konstruieren von Inhalten.
- Wandel vom Dokument zum Informationsmodul: Unternehmen müssen sich von der Vorstellung des „fertigen Dokuments“ (z. B. PDF) als primäres Speicherformat lösen. Stattdessen werden Inhalte in granulare, medienneutrale Module zerlegt, die sich flexibel zu neuen Publikationen zusammensetzen lassen.
- Vorbereitung auf KI und RAG (Retrieval Augmented Generation): Große Sprachmodelle (LLMs) und Chatbots benötigen strukturierte, semantisch angereicherte Daten, um präzise Antworten zu liefern. Content Engineering schafft die notwendige Metadaten-Struktur, damit KI-Systeme den Kontext von Informationen verstehen und Halluzinationen minimiert werden.
- Effizienzsteigerung durch Wiederverwendung: Durch intelligente Modularisierung wird Redundanz vermieden. Ein Warnhinweis oder eine technische Spezifikation wird nur einmal erstellt und referenziert, statt hundertfach kopiert zu werden. Dies senkt Übersetzungskosten und Pflegeaufwände massiv.
- Interdisziplinäre Zusammenarbeit: Die Grenzen zwischen Technischer Redaktion, IT und Produktentwicklung verschwimmen. Content Engineers arbeiten an der Schnittstelle und sorgen dafür, dass Informationsmodelle (z. B. iiRDS) mit den Systemarchitekturen des Unternehmens kompatibel sind.
Typische Fehlerbilder, die ich in der Praxis sehe
Trotz der offensichtlichen Vorteile scheitern Initiativen oft an der Umsetzung. Häufig werden technologische Lösungen eingeführt, ohne die methodischen Hausaufgaben gemacht zu haben.
- Tool-First statt Strategy-First: Oft wird ein mächtiges Component Content Management System (CCMS) angeschafft, in der Hoffnung, dass die Software allein Ordnung schafft. Ohne ein definiertes Informationsmodell und klare Redaktionsleitfäden führt dies lediglich dazu, dass das Chaos schneller und digitaler verwaltet wird.
- Mangelnde Granularität oder „Over-Engineering“: Ein klassischer Fehler ist die falsche Schnittgröße der Module. Sind sie zu groß, sinkt die Wiederverwendungsrate. Sind sie zu klein (z. B. einzelne Sätze), wird das Management der Varianten unüberschaubar und der Kontext geht für den Redakteur verloren.
- Vernachlässigung der Metadaten: Inhalte werden zwar modularisiert, aber nicht ausreichend klassifiziert. Ohne eine saubere Taxonomie (Wer braucht die Info? Wann? Für welches Produkt?) sind die Module in Datenbanken unauffindbar und für automatisierte Ausspielungen wertlos.
Die Content-Engineering-Checkliste
Struktur kommt vor Geschwindigkeit. Arbeiten Sie die Punkte der Reihe nach ab; jeder Haken ist die Voraussetzung für den nächsten Schritt. Zum Mitnehmen und Abhaken:
1 · Content-Audit
- ☐ Bestand vollständig erfasst (Formate, Mengen, Ablageorte)
- ☐ Redundanzen und Dubletten markiert
- ☐ Veraltete und „tote“ Inhalte aussortiert
2 · Informationsmodell
- ☐ Informationsklassen definiert (Konzept, Aufgabe, Referenz)
- ☐ Hierarchie- und Schachtelungsebenen festgelegt
- ☐ Orientierung an einem Standard geprüft (DITA, iiRDS)
3 · Taxonomie und Metadaten
- ☐ Facetten bestimmt (Produktgruppe, Zielgruppe, Lebenszyklus, Markt)
- ☐ Pflichtfelder je Modul festgelegt
- ☐ Benennungs- und Pflegeregeln dokumentiert
4 · Pilot
- ☐ Ein repräsentatives Produkt oder eine Doku-Art ausgewählt
- ☐ Modell am Piloten getestet, nicht am Gesamtportfolio
- ☐ Wiederverwendungsrate und Aufwand gemessen
5 · Toolchain
- ☐ Systeme erst jetzt final konfiguriert (CCMS, Translation Memory, Delivery-Portal)
- ☐ Offene Schnittstellen (APIs) sichergestellt
- ☐ Content-Fluss bis zur Endanwender-App oder zum Service-Portal getestet
Welche Fähigkeiten Content Engineers brauchen
Content Engineering ist ein Hybrid-Profil. Es sitzt zwischen Technischer Redaktion, Informationsarchitektur und IT, und es ist weder das eine noch das andere allein. Ein reiner Redakteur denkt in fertigen Texten, ein reiner Entwickler kennt die Inhalte nicht. Gebraucht wird die Brücke dazwischen. Konkret sind das diese Kompetenzen:
- Informationsmodellierung: in Strukturen statt in Dokumenten denken. Topic-orientiertes Schreiben, Informationsklassen sauber trennen, ein tragfähiges Modell entwerfen, bevor eine Zeile migriert wird.
- Strukturierte Formate: sicherer Umgang mit XML und Schemata, Verständnis für die Trennung von Inhalt und Auszeichnung, Grundkenntnisse in JSON und Markdown. Kein Software-Engineering, aber Datenkompetenz.
- Metadaten und Terminologie: facettierte Klassifikation, kontrollierte Vokabulare und konsequentes Terminologiemanagement. Das ist die unsichtbare Arbeit, die später jede Automatisierung trägt.
- Werkzeug-Souveränität: CCMS, Translation-Memory-Systeme und Publishing-Pipelines sicher bedienen und ihre Grenzen einschätzen können.
- Technisches Grundverständnis: wissen, was eine API leistet, wie Daten fließen, und genug Skript-Wissen (etwa XSLT, reguläre Ausdrücke, etwas Python), um wiederkehrende Aufgaben zu automatisieren.
- Redaktionelle Substanz bleibt Pflicht: verständliches Schreiben, Normenkenntnis (IEC 82079, Maschinenverordnung) und ein Gespür für die Zielgruppe. Erst auf einer guten Struktur wird Verständlichkeit planbar.
Die gute Nachricht: In den meisten Häusern sitzt das Potenzial bereits in der Redaktion. Erfahrene Technische Redakteure mit gezieltem Reskilling sind oft die bessere Investition als eine Neueinstellung, die das Produkt erst kennenlernen muss.
Was Sie als Unternehmen konkret einplanen müssen
Content Engineering ist eine Investition in Fähigkeiten und Prozesse, nicht nur in Software. Wer ausschließlich das Werkzeug bezahlt, hat das Budget zur Hälfte verschenkt. Diese Posten gehören realistisch in die Planung:
- Übergangszeit: Rechnen Sie mit einem Transformationsvorhaben über mehrere Quartale und beginnen Sie mit einem Piloten statt mit dem Gesamtportfolio.
- Kapazität für die Doppelbelastung: Das Tagesgeschäft läuft weiter, während umgestellt wird. Diese Migration passiert nicht „nebenbei“; sie braucht freigeräumte Zeit, sonst bleibt sie liegen.
- Weiterbildung: festes Budget und feste Zeit für die Qualifizierung der Redaktion. Reskilling ist kein einmaliger Kurs, sondern eine begleitete Entwicklung.
- Klare Rollen und Verantwortung: Wer hütet das Informationsmodell, wer pflegt die Taxonomie, wer administriert das System? Ohne benannte Eigentümerschaft zerfällt die Struktur wieder.
- Pflege als Daueraufgabe: Taxonomie und Terminologie sind kein Projekt mit Enddatum. Wird die Pflege nicht eingeplant, verwässert das Modell innerhalb eines Jahres.
- IT-Schnittstellen: frühzeitige Abstimmung mit der Systemarchitektur und ein realistischer Blick auf Lizenzen, Einführung und Wartung der Toolchain, deren Auswahl bewusst ans Ende gehört.
Die Rolle der Führung: ermächtigen statt verwalten
Die meisten Content-Engineering-Initiativen scheitern am fehlenden Mandat, lange bevor die Technik zum Problem wird. Die entscheidende Variable ist die Haltung der Führungskraft; sie lässt sich an drei Punkten festmachen:
- Mandat geben: Content Engineers setzen Standards durch, die Bequemlichkeit kosten. Ohne Rückendeckung wird jede Regel von dem überstimmt, der „nur schnell“ ein PDF braucht. Geben Sie Ihren Leuten die Autorität, beim Strukturmodell auch Nein zu sagen.
- Die Investitionsdelle aushalten: Modularisierung kostet erst, bevor sie spart. Wer nach drei Monaten ohne sichtbare Einsparung den Stecker zieht, verbrennt die gesamte Vorleistung. Führung bedeutet hier, die Durststrecke zu verteidigen, statt sie zu bestrafen.
- Konzeptarbeit als Wert anerkennen: Ein Informationsmodell und eine Taxonomie zu entwerfen, liefert wochenlang keinen sichtbaren Output. Wer das als „unproduktiv“ abwertet, erstickt genau die Arbeit, die intelligente Anwendungsfälle wie KI-Chatbots, situative Ausleitung und effiziente Wiederverwendung erst ermöglicht.
Ermächtigung bedeutet, mit klaren Zielen zu vertrauen und die Kontrolle über das Ergebnis zu behalten, statt über jeden Schritt. Die Führungskraft entscheidet, ob ihre Content Engineers gestalten dürfen oder nur verwalten. Diese Entscheidung bestimmt den Ertrag der gesamten Investition.
Für wen ist das relevant?
Für jeden, der Wissen besitzt, das andere finden, nutzen oder weiterverarbeiten sollen. Und das ist praktisch jedes Unternehmen.
Strukturierte, maschinenlesbare Inhalte sind kein Privileg von Maschinenbau oder Medizintechnik. Der Maschinenbauer braucht sie für variantenreiche Anleitungen, der Software-Anbieter für seine Produktdoku, der Energieversorger für Sicherheitsunterweisungen. Genauso der Dienstleister, der sein Beratungswissen schnell auffindbar machen will, der Handwerksbetrieb mit wiederkehrenden Prüf- und Wartungsabläufen, die Kanzlei mit ihren Vorlagen und Prüfschemata, die Klinik mit ihren Verfahrensanweisungen. Sobald Wissen mehrfach gebraucht, aktuell gehalten oder einer KI zugänglich gemacht werden soll, ist strukturierter Content dem unstrukturierten in jedem Fall überlegen.
Die Frage ist also nicht, ob Content Engineering für Sie zählt, sondern in welcher Tiefe. Ein Zwei-Personen-Betrieb braucht kein vollständiges CCMS. Aber er profitiert von klaren Modulen, sauberen Metadaten und der Disziplin, Wissen einmal richtig zu erfassen statt zehnmal halb. Der Umfang skaliert mit Ihrer Komplexität. Die Grundhaltung gilt für alle.
Quelle (Anlass)
Themenimpuls: Interne Redaktionsplanung zu Content-Strategie und Modularisierung.
Weiterführende Standards und Branchen-Information bei der tekom — Gesellschaft für Technische Kommunikation.
Bevor das nächste Tool gekauft wird — sprechen wir vorher
In Technischen Redaktionen entscheidet selten das Werkzeug, sondern die Datenbasis und die Prozessreife. Schübeler Consulting prüft Ihre konkrete Situation: Modularitätsgrad, Terminologie, Schnittstellen, Personal-Setup. Daraus kommt eine Empfehlung, mit der Sie Ihre nächste Investition belastbar begründen können.
Erstgespräch direkt online buchen →
Lieber schreiben? info@schuebeler-consulting.de
— Johann Jörgen Schübeler, Schübeler Consulting
