Technische Dokumentation Tools im Vergleich: Software für technische Dokumentation und Softwaredokumentation

Wer nach Tools für technische Dokumentation sucht, landet schnell bei Listen mit zwanzig oder vierzig Namen. Viele davon stammen von Herstellern, die ihr eigenes Produkt ganz oben einsortieren, und die neutralen Übersichten sind so lang, dass die eigentliche Frage untergeht: Welche Art von Werkzeug braucht dein Team gerade? Eine Betriebsanleitung für eine Maschinenbaureihe mit dreißig Varianten und acht Sprachen stellt andere Anforderungen als die Online-Hilfe einer Web-App oder die Entwicklerdoku eines Softwareteams. Dieser Artikel sortiert die technische Dokumentation Tools deshalb nach Kategorien statt nach Rangliste. Du erfährst, was Textverarbeitung, Redaktionssysteme mit XML-Editoren, Help-Authoring-Tools, Docs-as-Code und Wissensdatenbanken jeweils gut können, wo KI heute hilft und welche Pflichten aus der Maschinenverordnung und der ISO/IEC/IEEE 82079-1 auf die Tool-Wahl durchschlagen. Am Ende steht eine Bewertungsmatrix zum Kopieren, mit der du zu einer Entscheidung kommst, die du auch in zwei Jahren noch vertreten kannst.

Warum Textverarbeitungsprogramme für technische Dokumentation und Softwaredokumentation irgendwann nicht mehr reichen

Technische Dokumentation umfasst alle Informationen, die ein Produkt über seinen Lebenszyklus begleiten. Grob unterscheidet man zwei Teile. Die interne Dokumentation bleibt beim Hersteller: Konstruktionsunterlagen, Risikobeurteilung, Prüfberichte und alles, was für die Konformitätsbewertung zusammengetragen wird. Die externe Dokumentation geht an die Endbenutzer, also Betriebsanleitung, Montageanleitung, Wartungshandbuch, Ersatzteilkatalog oder Online-Hilfe. Bei einem Softwareprodukt spricht man von Softwaredokumentation, und auch die hat zwei Leserschaften. Entwickler brauchen Architektur, API-Referenz und Installationshinweise, Anwender brauchen Anleitungen und eine Hilfe, die ihre Frage in dem Moment beantwortet, in dem sie im Programm hängen. Gute Softwaredokumentation ist damit ein Teil der Benutzererfahrung und nicht nur ein Anhang zum Produkt.

Am Anfang entsteht fast jede Dokumentation in Word oder einem ähnlichen Textverarbeitungsprogramm, und das ist völlig in Ordnung. Für ein Produkt, eine Sprache und ein oder zwei Autoren ist Word schnell, jeder kann es bedienen, und das PDF ist mit zwei Klicks erzeugt. Die Grenzen zeigen sich erst, wenn das Produkt wächst. Derselbe Sicherheitshinweis steht dann in zwölf Dokumenten, und bei der nächsten Änderung erwischst du nur elf davon. Jede neue Variante bedeutet eine neue Kopie des Handbuchs, die ab diesem Tag eigenständig altert. Die Übersetzung geht als komplettes Dokument an den Dienstleister, obwohl sich nur drei Absätze geändert haben, und danach bessert jemand in acht Sprachen das Layout nach. Spätestens wenn mehrere Technische Redakteure gleichzeitig an denselben Inhalten arbeiten, fehlen ein Freigabe-Workflow, eine Versionierung auf Ebene einzelner Abschnitte und ein verlässlicher Weg, dieselben Inhalte für verschiedene Ausgabeformate aufzubereiten.

Aus genau diesen Schmerzpunkten sind die heutigen Kategorien von Software für technische Dokumentation entstanden. Jede Kategorie löst ein anderes Problem, und deshalb lässt sich die Frage nach dem besten Tool erst beantworten, wenn klar ist, welches dieser Probleme bei dir am meisten wehtut.

Führende Tools für technische Dokumentation nach Kategorien im Überblick

Die folgende Tabelle ordnet die gängigen Dokumentationswerkzeuge nach ihrem Grundprinzip. Die Beispiele sind bekannte Vertreter der jeweiligen Kategorie und keine Rangfolge. Viele Teams kombinieren zwei Kategorien, etwa ein Redaktionssystem für die Betriebsanleitung und ein Wiki für das interne Wissen dahinter.

Textverarbeitung und Desktop-Publishing, kurz DTP, haben eines gemeinsam: Inhalt und Layout stecken in derselben Datei. Adobe FrameMaker ist seit Jahrzehnten ein Klassiker für lange technische Handbücher und kann auch strukturiert mit XML arbeiten, InDesign spielt seine Stärken bei aufwendig gestalteten Print-Dokumenten aus. Genau das ist der Unterschied zu einem Redaktionssystem. Im DTP-Programm baust du ein Dokument, im CCMS pflegst du Bausteine, und das Layout entsteht beim Publizieren automatisch über Stylesheets. Solange du wenige Dokumente hast, ist der DTP-Weg der kürzere. Sobald dieselben Inhalte in vielen Dokumenten auftauchen, kippt die Rechnung.

Wann sich Autorensysteme wie Redaktionssysteme, CCMS und XML-Editoren lohnen

Ein CCMS (Component Content Management System) speichert Inhalte nicht als ganze Dokumente, sondern als kleine, in sich geschlossene Module. Ein Modul kann eine Handlungsanweisung sein, ein Warnhinweis, eine technische Datentabelle oder eine Beschreibung. Jedes Modul trägt Metadaten, zum Beispiel für Produkt, Variante, Zielgruppe und Sprache, und aus diesen Bausteinen stellt das System die Publikationen zusammen. Modulare Inhalte sind damit der Kern jedes Redaktionssystems. Dieselbe Montageanleitung entsteht so für zwanzig Varianten, ohne dass jemand zwanzig Dokumente pflegt. Dieses Prinzip heißt Single-Source-Publishing: Aus einer Quelle erzeugst du PDF, HTML, ein Content-Delivery-Portal oder die Hilfe in der Maschinensteuerung, und eine Korrektur am Modul landet beim nächsten Publizieren überall.

Bei Übersetzungen spielt ein Redaktionssystem seine Stärke am deutlichsten aus. Weil das System weiß, welche Module sich seit der letzten Freigabe geändert haben, gehen nur diese in die Übersetzung, und unveränderte Bausteine werden aus den vorhandenen Sprachfassungen übernommen. Zusammen mit einem Translation Memory beim Dienstleister und einer gepflegten Terminologie senkt das den Aufwand pro Sprache spürbar. Viele Systeme binden zusätzlich Terminologieverwaltung und Sprachprüfung ein, damit "Not-Halt" nicht in einem Kapitel "Notstopp" heißt.

Technisch arbeiten die meisten Redaktionssysteme mit XML. Ein verbreiteter Standard ist DITA (Darwin Information Typing Architecture), ein offener OASIS-Standard, der Inhalte in Topic-Typen wie Konzept, Aufgabe und Referenz gliedert. Paligo setzt auf DocBook, Heretto auf DITA, und viele Systeme aus dem deutschsprachigen Raum wie SCHEMA ST4 oder COSIMA von DOCUFY arbeiten mit einem eigenen XML-Informationsmodell. Einen eigenständigen XML-Editor wie Oxygen brauchst du vor allem dann, wenn du DITA ohne komplettes CCMS nutzen willst oder Entwickler und Redakteure direkt im XML arbeiten sollen. In einem vollständigen Redaktionssystem ist der Editor in der Regel schon eingebaut und blendet das XML für die Autoren weitgehend aus.

Der große Schritt lohnt sich, wenn mehrere Dinge zusammenkommen: viele Varianten, mehrere Sprachen, regulatorische Anforderungen und ein Team aus mehreren Technischen Redakteuren. Für einen Hersteller mit einem Produkt und einer Sprache ist ein CCMS dagegen meist überdimensioniert. Bei den Kosten solltest du nicht nur die Lizenz betrachten. Ins Gewicht fallen auch das Informationsmodell, das jemand entwerfen muss, die Migration der Bestandsdaten, Schulungen und die Zeit, in der das Team parallel im alten und im neuen System arbeitet. Die Einführung dauert deshalb eher Monate als Wochen, und der größte Block ist fast immer die Migration. Ob am Ende ST4, COSIMA oder ein Cloud-System wie Paligo besser passt, entscheidet sich weniger an Funktionslisten als an einem Test mit deinen eigenen Inhalten, dazu weiter unten mehr.

Help-Authoring-Tools, Docs-as-Code und Wissensdatenbanken als Softwarelösungen für Online-Hilfen und Handbücher

Zwischen Word und CCMS liegen die Help Authoring Tools. Auch diese Werkzeuge arbeiten themenbasiert und nach dem Single-Source-Prinzip, sind aber leichter einzuführen und stärker auf Online-Hilfen und Handbücher ausgerichtet. In der Branche spricht man dabei oft von User Assistance, also allem, was Nutzer direkt im Produkt unterstützt. MadCap Flare ist hier ein bekannter Vertreter, HelpNDoc eine schlanke Alternative für kleinere Projekte, und ClickHelp läuft als SaaS komplett im Browser. Mit bedingtem Text und Variablen deckst du einfache Varianten ab, ohne gleich ein Informationsmodell aufzubauen. Für Softwarehersteller und Gerätehersteller mit einer kleinen Redaktion ist das oft der passende Zwischenschritt.

Ganz anders denkt Docs-as-Code. Hier liegt die Dokumentation als Markdown oder reStructuredText im selben Git-Repository wie der Code, und Generatoren wie Sphinx, MkDocs oder Docusaurus bauen daraus eine Website. Änderungen laufen über Pull Requests mit Review, genau wie beim Code, und Werkzeuge wie Doxygen erzeugen Referenzseiten direkt aus Kommentaren im Quelltext, ein Stück Automatisierung, das Redaktionen sonst selten bekommen. Für Entwicklerdoku und API-Referenzen ist das ein starker Ansatz, weil die Doku dort entsteht, wo die Änderung passiert. Die Kehrseite zeigt sich, sobald Produktmanagement, Support oder Fachbereiche mitschreiben sollen. Für sie ist Git eine echte Hürde, und dann bleibt die Doku wieder an den Entwicklern hängen.

Wikis und Wissensdatenbanken wie Confluence, MediaWiki oder Document360 senken die Einstiegshürde am weitesten. Jeder kann schreiben, die Suche funktioniert, und für interne Dokumentation, Prozesswissen und Support-Antworten reicht das oft völlig. Document360 richtet sich zusätzlich an Firmen, die ihren Kunden eine Self-Service-Wissensdatenbank anbieten wollen. Confluence wird in vielen Vergleichen genannt, weil es vielseitig ist und in vielen Firmen ohnehin schon läuft. Für strukturiertes Variantenmanagement, Übersetzungsprozesse und normkonforme Freigaben ist ein Wiki aber nicht gebaut. Wer eine CE-relevante Betriebsanleitung im Wiki pflegt, baut sich diese Prozesse früher oder später mühsam selbst nach.

Neben den Hauptwerkzeugen braucht fast jede Redaktion ein paar Helfer. Screenshot-Tools wie Snagit sparen bei Softwaredokumentation viel Zeit, Grafikprogramme bereiten Zeichnungen und Explosionsdarstellungen auf, die oft aus CAD-Daten stammen, und für Screencasting und Erklärvideos sind Programme wie Camtasia verbreitet. Diese Werkzeuge ersetzen kein Redaktionssystem, aber sie entscheiden mit darüber, wie schnell eine Seite fertig wird.

Maschinenverordnung, ISO/IEC/IEEE 82079-1 und Produkthaftung: was das Tool leisten muss

In den meisten Tool-Vergleichen kommen Normen und Gesetze nur als Stichwort vor. Für die Auswahl sind sie aber ein harter Filter, und gerade jetzt ändert sich etwas. Ab dem 20. Januar 2027 gilt die Maschinenverordnung (EU) 2023/1230 und löst die Maschinenrichtlinie 2006/42/EG ab, ohne Übergangszeit. Die Betriebsanleitung darf dann digital bereitgestellt werden. Das klingt nach Entlastung, bringt aber konkrete Pflichten mit: Auf der Maschine, der Verpackung oder einem Begleitdokument muss stehen, wie man an die Anleitung kommt. Die digitale Fassung muss sich herunterladen, speichern und ausdrucken lassen und während der voraussichtlichen Lebensdauer der Maschine verfügbar bleiben, mindestens aber zehn Jahre nach dem Inverkehrbringen. Verlangt der Kunde beim Kauf eine Papierfassung, musst du sie innerhalb eines Monats kostenlos liefern, und bei Maschinen für nichtprofessionelle Nutzer gehören die wesentlichen Sicherheitsinformationen weiterhin auf Papier. In Deutschland legt das Durchführungsgesetz fest, dass Betriebsanleitung und Sicherheitsinformationen auf Deutsch vorliegen müssen.

Für die Tool-Wahl heißt das für deine technische Dokumentation: Dein System muss für jede ausgelieferte Maschine eine stabile, versionierte Fassung erzeugen, die du über Jahre wiederfindest, und es muss Print und digitale Ausgabe aus derselben Quelle bedienen. Content-Delivery-Plattformen können helfen, ersetzen aber nicht die Archivierung der Version, die zu einer bestimmten Seriennummer gehört.

Die ISO/IEC/IEEE 82079-1 beschreibt Anforderungen an Nutzungsinformationen, also an Inhalt und Gestaltung von Anleitungen und an den Prozess, in dem sie entstehen. Kein Tool macht deine Doku von sich aus normkonform. Ein gutes System unterstützt aber genau die Prozesse, die die Norm erwartet: nachvollziehbare Freigaben, konsistente Terminologie, Zielgruppenbezug und eine Qualitätssicherung, die belegt, wer was wann geprüft hat. In der Medizintechnik kommen die MDR und eigene Regeln für elektronische Gebrauchsanweisungen dazu.

Dahinter steht die Produkthaftung. Eine Anleitung ist Teil des Produkts, und fehlende oder unverständliche Warnhinweise können als Instruktionsfehler gelten. Im Ernstfall willst du zeigen können, welche Fassung mit welchem Produkt ausgeliefert wurde und wer sie freigegeben hat. Ein Tool ohne verlässliche Versionierung und Freigabehistorie ist für regulierte Produkte deshalb keine gute Wahl, egal wie angenehm sich der Editor bedienen lässt.

Was KI in Dokumentationswerkzeuge bringt und wo der Engpass vor dem Tool liegt

Fast jedes Dokumentationswerkzeug hat inzwischen KI-Funktionen. Typisch sind Formulierungsvorschläge, das Kürzen und Umschreiben von Abschnitten, Vorschläge für Übersetzungen, Prüfungen gegen die Terminologie und eine Suche, die Fragen direkt aus der Wissensdatenbank beantwortet. Das spart Zeit, solange ein Mensch das Ergebnis prüft. Bei sicherheitsrelevanten Inhalten ist diese Prüfung ohnehin Pflicht, und du solltest für jeden Vorschlag nachvollziehen können, worauf er sich stützt. Frag bei jedem Anbieter außerdem, wo Daten gespeichert und von welchen Sprachmodellen sie verarbeitet werden, bevor du Konstruktionswissen hineingibst.

Viele Vergleichslisten gehen stillschweigend davon aus, dass die Inhalte schon da sind und nur verwaltet werden müssen. In der Praxis liegt der Engpass oft eine Stufe früher. Das Wissen steckt in den Köpfen von Entwicklern, in Tickets, Prüfprotokollen, Produktdaten aus dem PLM-System, der Produktspezifikation und den Notizen, die sich ein Servicetechniker beim Kunden gemacht hat. Technische Redakteure verbringen einen großen Teil ihrer Zeit damit, diesen Informationen hinterherzulaufen, und kein CCMS dieser Welt holt sie von allein aus dem Notizbuch. Wer hier ansetzt, verbessert die Dokumentation oft stärker als mit dem nächsten Systemwechsel, denn auch die beste technische Dokumentation ist nur so aktuell wie die Informationen, die bei der Redaktion ankommen.

An dieser Stelle hilft eine andere Art von KI-Werkzeug, das aus kurzen Notizen Entwürfe und Änderungen macht. Cortee ist ein solcher KI-Dokumentations-Workspace: Du schreibst in ein paar Stichpunkten auf, was sich geändert hat, Cortee setzt die passende Änderung direkt auf der Seite um, und falls etwas nicht stimmt, machst du sie mit einem Schritt rückgängig. Die Quellen bleiben dabei nachvollziehbar, und die Daten liegen in der EU. Ein Redaktionssystem für dreißig Varianten in acht Sprachen ersetzt das nicht. Es passt dort, wo Softwaredokumentation, Prozessbeschreibungen oder Produktwissen aus den Notizen von Fachleuten entstehen und Leute mitschreiben sollen, die kein Git und kein XML lernen wollen. Wie das konkret aussieht, zeigt die Seite zur automatisierten Softwaredokumentation für nicht-technische Teams. Ob du die Doku dann selbst schreibst, an einen Dienstleister gibst oder teilweise automatisierst, ist eine eigene Entscheidung, die der Beitrag Technische Dokumentation erstellen lassen oder selbst schreiben durchgeht.

Auswahlkriterien und Bewertungsmatrix für deine Tool-Entscheidung

Bevor du Anbieter anschreibst, lohnt sich ein ehrlicher Blick auf deinen Reifegrad. Wenn du als Dokumentationsverantwortliche oder Dokumentationsverantwortlicher die Auswahl leitest, hol Entwicklung, Service und Produktmanagement früh dazu. Der Tool-Bedarf entwickelt sich bei den meisten Firmen in ähnlichen Stufen. Am Anfang reicht Word. Mit der ersten Online-Hilfe oder dem ersten zweisprachigen Handbuch kommt ein Help-Authoring-Tool oder ein Wiki dazu. Mit vielen Varianten, mehreren Sprachen und Audits wird ein Redaktionssystem sinnvoll, und parallel dazu lebt die Entwicklerdoku oft im Docs-as-Code-Workflow. Eine Stufe zu überspringen kann sich lohnen, wenn du weißt, dass das Portfolio bald wächst. Zwei Stufen zu überspringen endet oft in einem System, das niemand richtig nutzt.

Die wichtigsten Auswahlkriterien ergeben sich aus den Abschnitten oben. Welche Ausgabeformate brauchst du heute und in drei Jahren? Wie viele Varianten und Sprachen musst du bedienen, und wie kommen Übersetzungen ins System und wieder heraus? Wer schreibt, also eine Redaktion, Entwickler oder Fachbereiche? Welche Nachweise verlangen deine Regelwerke, und wie archiviert das System alte Fassungen? Dazu kommen Schnittstellen zu PLM, ERP, Git oder Ticketsystem, der Betrieb in der Cloud oder im eigenen Rechenzentrum mit Blick auf den Datenschutz und eine Frage, die in fast keinem Vergleich auftaucht: Wie kommst du wieder heraus? Ein Export in offene Formate wie DITA, DocBook, Markdown oder sauberes HTML schützt dich davor, dass ein Systemwechsel in fünf Jahren zur nächsten Großmigration wird.

Mit der folgenden Matrix machst du aus diesen Fragen eine nachvollziehbare Entscheidung. Gewichte die Kriterien zuerst im Team, bevor du Demos siehst, sonst passt sich die Gewichtung unbewusst an das Tool an, das in der Präsentation am besten aussah.

BEWERTUNGSMATRIX: TOOLS FÜR TECHNISCHE DOKUMENTATION

Schritt 1: Gewichtung je Kriterium festlegen (1 = wünschenswert, 2 = wichtig, 3 = entscheidend)
Schritt 2: Jedes Tool bewerten (0 = fehlt, 1 = mit Aufwand, 2 = gut, 3 = sehr gut)
Schritt 3: Punkte = Gewichtung x Bewertung, Summe je Tool bilden

Kriterium                                         Gewicht  Tool A  Tool B  Tool C
01 Ausgabeformate (PDF, HTML, Portal, App, Print)    __      __      __      __
02 Varianten und Wiederverwendung von Modulen        __      __      __      __
03 Übersetzung (Export/Import, nur Änderungen)       __      __      __      __
04 Terminologie und Sprachprüfung                    __      __      __      __
05 Freigabe-Workflow und Rollen                      __      __      __      __
06 Versionierung und Archiv je Auslieferung          __      __      __      __
07 Bedienbarkeit für alle, die schreiben sollen      __      __      __      __
08 Schnittstellen (PLM, ERP, Git, Tickets)           __      __      __      __
09 Hosting, Datenschutz, Speicherort der Daten       __      __      __      __
10 KI-Funktionen mit nachvollziehbaren Quellen       __      __      __      __
11 Export in offene Formate (Exit-Strategie)         __      __      __      __
12 Aufwand für Einführung, Migration, Schulung       __      __      __      __
SUMME                                                        __      __      __

K.-o.-Kriterien (ein Nein scheidet das Tool aus):
[ ] Erzeugt die Formate, die Gesetz und Kunden verlangen
[ ] Liefert jede ausgelieferte Fassung auch nach 10 Jahren wieder aus
[ ] Erfüllt unsere Vorgaben zu Datenschutz und Speicherort
[ ] Lässt sich mit unseren eigenen Inhalten testen, bevor wir unterschreiben

Die Demo eines Anbieters zeigt dir, was das Tool kann. Ob es zu dir passt, siehst du erst mit deinen eigenen Inhalten. Nimm deshalb für zwei oder drei Kandidaten einen echten Ausschnitt aus deiner Dokumentation, idealerweise ein Kapitel mit Varianten, Warnhinweisen und Tabellen, und spiel einen kompletten Zyklus durch: importieren, ändern, freigeben, übersetzen lassen, publizieren. Dabei merkst du schnell, wie gut die Migration deiner Bestandsdaten klappen wird, und die Leute, die später täglich damit arbeiten, haben mitentschieden.

PILOT-TESTPLAN: TOOL MIT EIGENEN INHALTEN PRÜFEN (4 WOCHEN)

Woche 1: Vorbereitung
[ ] Testkapitel auswählen (Varianten, Warnhinweise, Tabellen, Bilder)
[ ] Testteam benennen: Redaktion, Entwicklung, Service, ggf. Übersetzung
[ ] Erfolgskriterien aus der Bewertungsmatrix übernehmen

Woche 2: Import und Erstellung
[ ] Bestandsinhalte importieren, Aufwand für Nacharbeit notieren
[ ] Ein neues Kapitel von Grund auf schreiben
[ ] Eine Variante ableiten, ohne Inhalte zu kopieren

Woche 3: Änderung, Freigabe, Übersetzung
[ ] Eine echte Produktänderung einpflegen und alle betroffenen Stellen finden
[ ] Freigabe durchlaufen lassen, Historie prüfen
[ ] Geänderte Inhalte in eine Sprache übersetzen lassen und zurückspielen

Woche 4: Ausgabe und Auswertung
[ ] PDF und Online-Fassung erzeugen, Ergebnis mit dem Ist-Stand vergleichen
[ ] Export in ein offenes Format testen
[ ] Bewertungsmatrix mit dem Testteam ausfüllen und Entscheidung festhalten

Fazit: Das passende Tool richtet sich nach Varianten, Sprachen und Team

Die Frage nach den besten Tools für technische Dokumentation hat keine allgemeine Antwort, aber eine sehr konkrete für dein Unternehmen. Wenn du wenige Produkte in einer Sprache dokumentierst, kommst du mit Word oder einem Help-Authoring-Tool lange gut aus. Viele Varianten, mehrere Sprachen und regulatorische Pflichten wie die Maschinenverordnung sprechen für ein Redaktionssystem mit XML, und Entwicklerdoku fühlt sich in Docs-as-Code am wohlsten. Wikis tragen das interne Wissen, und KI-Werkzeuge helfen vor allem dort, wo das Wissen bisher in Notizen und Köpfen feststeckt. Gewichte deine Kriterien, bevor du Demos siehst, teste mit deinen eigenen Inhalten und achte darauf, wie du wieder herauskommst. Dann wird aus dem Tool-Vergleich eine Entscheidung, die zu deinem Reifegrad passt und mitwächst.