API-Dokumentation – Was brauchen und wollen Entwickler?

Code ist undokumentiert schwer zugänglich
(c) Markus Vogelbacher via pixelio.de

Heute freuen wir uns, wieder einmal eine Gastautorin im doctima-Blog zu begrüßen. Stephanie Steinhardt ist Dipl. Technik-Redakteur (FH) und wissenschaftliche Mitarbeiterin an der Hochschule Merseburg. Als freiberufliche Technik-Redakteurin betreut sie außerdem verschiedene Kunden z. B. aus dem Automobilbereich. In ihrem Post zeigt Sie uns erste Ergebnisse aus einer gemeinsamen Forschungsarbeit mit Prof. Dr. Michael Meng und Andreas Schubert (MA) an der HS Merseburg. Doctima ist an diesem Projekt als Vernetzungspartner beteiligt.

Die Sicht von Entwicklern auf API- Dokumentation ist oftmals sehr verschieden. Während die einen davon überzeugt sind, dass guter Code keiner Dokumentation bedarf, schreiben die anderen selbst gern Dokumentation und konsultieren sie auch häufig. Die Meinungen darüber, wie sie denn aussehen soll, die perfekte API-Dokumentation, gehen ebenfalls auseinander. Es existieren unterschiedliche Ansätze zu Aussehen, Darreichung und Inhalt einer solchen.

An der Hochschule Merseburg widmet sich seit zwei Jahren ein kleines Team von Technik-Redakteuren in einem Forschungsprojekt der Optimierung von API-Dokumentation. Die Fragen nach Struktur und Inhalt der perfekten API-Dokumentation sowie nach dem Leseverhalten der Entwickler stehen dabei im Mittelpunkt der Untersuchungen. Auf Basis von 23 durchgeführten Interviews, der Erhebung von Daten aus rund 100 Fragebögen und einer Beobachtungsreihe, bei der genau verfolgt wurde, wie Entwickler Programmieraufgaben lösen, sowie unter Berücksichtigung der bereits existierenden Studien im Umfeld von Entwicklerdokumentation können wir Empfehlungen geben, die API-Dokumentationen deutlich besser und effizienter nutzbar machen.

Nicht jeder Entwickler ist wie der andere.

Entwickler unterscheiden sich nicht nur in ihrer Einstellung zur Dokumentation, in den Jahren ihrer Programmiererfahrung oder bezüglich der Systemwelt, in welcher sie zu Hause sind. Sie unterscheiden sich vor allem in ihrer Arbeitsweise. So konnten wir in unseren erhobenen Daten zwei verschiedene Ansätze identifizieren, welche vor allem bei der Einarbeitung in eine neue API deutlich hervortreten. So gibt es Entwickler, die einen eher codegetriebenen Ansatz verfolgen und nach eigener Aussage gern direkt mit einem Code-Beispiel einsteigen. Sie erarbeiten sich den Umfang einer API eher intuitiv von unten nach oben. Es gibt aber auch Entwickler, die konzeptorientiert arbeiten und sich vor der Nutzung einer neuen API zunächst einen Überblick verschaffen. Entwickler, die der Meinung sind, dass es nützlich ist, das Konzept der API in Gänze zu verstehen, auch wenn nur ein Teil der API tatsächlich zur Problemlösung genutzt wird.

Abb.: 1 – Absolute Zeitwerte: Recherchezeit (farbig) vs. Bearbeitungszeit (grau) der Probanden 01-11

Besonders deutlich traten diese Verhaltensmuster in der von uns durchgeführten Beobachtungsreihe hervor. So haben 6 der 11 beobachteten Probanden im Konzeptbereich der API-Dokumentation unserer Test-API gelesen, wohingegen die anderen 5 kaum einen Blick hinein warfen und vorrangig auf Beispielcode fixiert waren.

Lesen ist nicht gleich lesen.

Trotz der gegensätzlichen Sichtweisen der Entwickler auf API-Dokumentation hat die Beobachtung gezeigt, dass im Beobachtungszeitraum von jeweils einer Stunde alle Probanden nahezu die Hälfte der Zeit mit der Recherche in der API-Dokumentation zubrachten, während die andere Hälfte für die tatsächliche Programmierung zur Lösung der Aufgaben verwendet wurde.

Wie die Analyse der entstandenen Eyetracking-Aufnahmen zeigte, scannten und überflogen die Entwickler die einzelnen Inhalte mehr, als dass sie tatsächlich Zeile für Zeile lasen. Dabei fokussierten Sie vorrangig auf die visuell hervorgehobenen Elemente, wie Hyperlinks, die Navigation und Beispielcode. Der erklärende Fließtext wurde meist nur dann gelesen, wenn aus dem Beispielcode allein keine Lösung abzuleiten war.

Das Leseverhalten schien darüber hinaus nicht nur beeinflusst von der individuellen Arbeitsweise, sondern war auch geprägt von der Einschätzung zum Schwierigkeitsgrad der gestellten Aufgabe. Bei Aufgaben, die schwieriger zu lösen schienen, waren die Probanden eher geneigt zu lesen, als bei Aufgaben, die einfacher wirkten.

Wer die Prozesse kennt, ist klar im Vorteil.

Bereits in den Interviews und in existierenden Studien kam zum Vorschein, dass mitunter alleinige Programmiererfahrung kein Garant ist für die schnelle Einarbeitung in eine neue API. Vielmehr entscheidend ist das vorhandene Domainwissen. Wer mit den zugrunde liegenden Prozessen vertraut ist, welche die API abbildet und dazu das Fachvokabular kennt, ist deutlich schneller bei der Einarbeitung und Lösung von Programmieraufgaben. Das zeigte auch unsere Beobachtungsreihe sehr eindrücklich (vgl. Abbildung 1 – Probanden 03, 04, 05,06 und 10 besaßen Domainwissen).

Demnach kommt der Vermittlung von Domainwissen in einer API-Dokumentation eine wichtige Rolle zu. Die Platzierung dieser Informationen ist mit Hinblick auf Leseverhalten und Arbeitsweise der Entwickler elementar.

Abb.: 2 – Beispiellayout für Codekommentare im Beispielcode (adaptierter Inhalt, basierend auf https://developers.shipcloud.io/reference/)

Der beste Ort für wichtige Informationen in einer API-Dokumentation ist einer, den alle Entwickler tatsächlich anschauen. Auf Basis der Interviews, den Fragebögen und der Beobachtung können nur Codebeispiele dieser Anforderung genügen. Sie werden von allen Entwicklern angesehen und als Basis der eigenen Programmierung verwendet. „Verkleidet“ man wichtige Informationen als Codekommentar und setzt diese deutlich vom restlichen Codebeispiel ab, kann man sicher sein, dass sie gesehen und, wenn kurz, auch gelesen werden. Auf ausführlichere Beschreibungen sollte zugunsten der eher konzeptorientierten Entwickler aber dennoch nicht verzichtet werden.

Dieser konkrete Optimierungsvorschlag und die zuvor genannten Erkenntnisse sind natürlich nur ein kleiner Teil der bisher gewonnenen Forschungsergebnisse. Unsere Untersuchungen dauern im Moment noch an. Daher sind wir auch sehr interessiert an Unternehmen, die bereit sind, sich an ähnlichen Studien zu beteiligen und damit die Zahl der möglichen Probanden vergrößern.

Kontakt: stephanie.steinhardt@hs-merseburg.de

Eine App für Arbeitssicherheit und Umweltschutz

dka_screenshot

Die Startseite der Handbuch-App

Heute möchte ich ein Projekt aus dem Bereich Mobile Dokumentation vorstellen, das wir mit unserem Kunden Dresdner Kühlanlagenbau GmbH, kurz: DKA, umgesetzt haben. Einen kurzen Vortrag dazu habe ich bereits im „Showcase Mobile Doku“ auf der letzten tekom-Jahrestagung gehalten. Nach einem Jahr im Produktivbetrieb liegt uns nun eine ganze Reihe von positiven Rückmeldungen vor, die unser Credo bestätigen, dass mobile Dokumentation im richtigen Kontext einen deutlichen Mehrwert gegenüber herkömmlichen (Papier-)Dokumenten schafft.

Die DKA installiert und wartet Kühlanlagen und Klimatechnik für Handel, Gewerbe und Industrie. Die mehreren hundert Monteure im Außeneinsatz sind verpflichtet, ein Handbuch mit Betriebsanweisungen dabei zu haben, die den Umgang mit Gefahrstoffen und gefährlichen Situationen regeln. Das Unternehmen ist vielfach zertifiziert, u. a. nach ISO9001 und §6 ChemKlimaschutzV, und wird auch von seinen Kunden regelmäßig evaluiert. Mit dem Handbuch als Loseblattsammlung war es schwierig sicherzustellen oder nachzuweisen, dass alle Monteure immer mit dem aktuellsten Stand von Informationen versorgt sind. Daraus entstand die Idee, das Handbuch in eine Smartphone-App umzusetzen und um einige hilfreiche Funktionen zu ergänzen.

Was die App leistet

Die App soll im Kern zwei Dinge erreichen: Sicherstellen, dass die Mitarbeiter Änderungen in den Betriebsanweisungen zeitnah und nachweisbar erhalten.Und sie motivieren, das Handbuch tatsächlich zu verwenden.

Um auch in Kellern und Tunneln verfügbar zu sein, bringt die App alle wesentlichen Inhalte – das sind v.a. Betriebsanweisungen und ein Gefahrstoffverzeichnis mit Sicherheitsdatenblättern der Hersteller – offline mit. Verteilt und aktualisiert wird sie via Mobile Device Management.

Um unsere eher handwerklich fokussierte Zielgruppe zum Lesen zu motivieren haben wir uns einige Dinge einfallen lassen. Begonnen mit einer ansprechenden Aufmachung, weiter mit schnellen und alternativen Zugangswegen zur Information, deren Formulierungen wir gestrafft und auf Verständlichkeit optimiert haben bis hin zu einer Kommentarfunktion, um den Kollegen die Möglichkeit zu geben, sich aktiv in den Gestaltungsprozess des Handbuchs mit einzubringen.

Geänderte Anweisungen werden direkt auf der Startseite angezeigt. Im Dokument selbst sind die geänderten Abschnitte farbig hervorgehoben. Zudem erscheint in geänderten Dokumenten ein Button um zu bestätigen, dass man die Änderungen wahrgenommen hat. Nach dem Bestätigen verschwinden Button und Markierungen. Die Bestätigungen aller Mitarbeiter werden auf einem Server gesammelt, wo sie sich für Audits auswerten lassen.

Um einen weiteren Anreiz zu schaffen, regelmäßig in das Handbuch hineinzusehen, haben wir eine Rubrik mit aktuellen Meldungen eingerichtet. Das sind die einzigen Inhalte die direkt vom Server bezogen werden. Sie werden prominent auf der Startseite angezeigt.

Welche Technologien wir verwenden

Das Handbuch ist eine hybride Android-App, d.h. HTML-Seiten verpackt mit Adobe PhoneGap. Das HTML für die Inhalte basiert auf dem responsiven Framework Bootstrap von Twitter, das wir um einige eigene Funktionen erweitert haben. Von den PhoneGap-Features nutzen wir v. a. den lokalen Dateizugriff, um die zugelieferten Sicherheitsdatenblätter-PDFs anzuzeigen, und die lokale Datenbank und die Abfrage des Verbindungsstatus zu Pufferungszwecken. Die Interaktionen mit dem Server erfolgt über Javascript und HTTP.

Ein TYPO3-Server, den wir entsprechend erweitert haben, dient als zentrale Gegenstelle für die Nutzerverwaltung, die aktuellen Meldungen, das Feedback und die Lesebestätigungen.

Für die Redaktion der Inhalte verwenden wir SCHEMA ST4. Dessen Datenmodell mit klassifizierten Knoten, Links und Metadaten nutzen wir, um die Inhalte mit Intelligenz auszustatten.

Intelligenter Content

Neben der Wiederverwendung (in den Betriebsanweisungen werden sehr viele Textbausteine mehrfach eingesetzt) und dem Single Source Publishing (neben einer Desktop-Ausgabe fürs Intranet gibt es von der App auch eine PDF-Druckversion) nutzen wir die Features unseres Redaktionssystems v. a. dazu, um ein möglichst smartes Endprodukt zu erzeugen. Im Folgenden will ich ein paar Beispiele zeigen:

Aufklappbereiche strukturieren die einzelnen Betriebsanweisungen. Zu diesem Zweck haben wir die Betriebsanweisungen in einzelne Objekte (in ST4: „Fragmente“) zerlegt, die über ein Metadatum als Aufklappbereiche markiert sind. Im HTML werden diese Bausteine zu Bootstrap-Panels mit klickbarer Kopfzeile und versteckbarem Body. Der Aufwand für dieses Feature besteht hauptsächlich darin, redaktionell ein Metadatum zu setzen und in der Generierung dafür zu sorgen, dass das Fragment mit Metadatum in ein DIV der Klasse „panel“ umgesetzt wird.

Ein anderes Metadatum steuert, welche Sicherheitssymbole zu Beginn eines Seitenbereichs ausgegeben werden. Das Erfassen über eine Mehrfachauswahl ist leichter und flexibler als das direkte Zuordnen von Bildreferenzen.

Die Einteilung des Inhalts in Bausteine ist auch Voraussetzung dafür, dass einzelne Abschnitte ihr Überarbeitungsdatum kennen und in der App als geändert markiert werden können. Auch hier wird ein Metadatum aus dem Redaktionssystem, diesmal als HTML-Attribut „data-lastchanged“,ins Endprodukt übertragen.

Eine wesentliche Verbesserung der Bedienbarkeit am Smartphone erreichen wir durch die einfache Maßnahme, dass Links als Buttons dargestellt werden. Insbesondere die Notrufnummer, die im Bereich Erste Hilfe immer wieder im Text erscheint, wird als roter Button mit Telefonsymbol umgesetzt – der natürlich bei Betätigung sofort den Notruf auslöst.

Gefahrstoffverzeichnis

Type Ahead: Das Gefahrstoffverzeichnis verkürzt sich während des Tippens

dkagefstoff

Alles zum Gefahrstoff auf einen Blick

Die umfassendste Veränderung haben wir der Gefahrstofftabelle angedeihen lassen. Die ist im Original eine Tabelle mit einem Dutzend Spalten und einigen hundert Zeilen, die sich im Querformat über mehrere DIN-A4-Seiten verteilt. Gefolgt wird sie im Original von einer Reihe von Legenden, da in der Gefahrstofftabelle nur Platz ist für die ISO-Kürzel der verwendeten Gefahrensymbole und Hazard- bzw. Precautionary Statements. Diese Tabelle und ihre Legenden haben wir in einzelne Objekte und Querbeziehungen zwischen ihnen aufgelöst. Das erlaubt uns, mit einer Type Ahead-Auswahlliste in der App einen schnellen Zugang zu den Gefahrstoffen zu legen und jeden Gefahrstoff als eigene übersichtlich gelayoutete HTL-Seite zu erzeugen. Im PDF generieren wir wieder die Tabelle im Querformat.

Mit diesen Beispielen möchte ich zeigen, dass intelligente Information schon mit kleinen Eingriffen in den Redaktionsprozess erreicht werden kann. Die Liste ist nicht vollständig, aber sie soll auch nur ein Gefühl dafür geben, dass es mit überschaubarem Aufwand und ohne das Budget eines Großkonzerns möglich ist, dem Medium mobile Dokumentation einen spürbaren Mehrwert zu verleihen.

Projektergebnisse

Nach einem Jahr Produktivbetrieb sehen wir alle Projektziele erreicht. Die Aktualität nach Rechts- und Sachstand ist deutlich verbessert. Reaktionszeiten sind verkürzt, Lesbarkeit und Zugänglichkeit erhöht, und nebenbei wurden die Verteilkosten gesenkt. Die Nachweisbarkeit ist erreicht, was bereits beeindruckte Rückmeldungen von Auditoren und Großkunden zur Folge hatte. Die App kommt bei der Zielgruppe ebenso gut an wie bei führenden Mitarbeitern und hat im Unternehmen einen hohen Stellenwert, sodass Erweiterungen und weitere ähnliche Anwendungen diskutiert werden.

Wir als doctima (das „wir“ bisher in diesem Beitrag bezog sich immer auf das Projektteam bei uns und bei DKA) haben aus diesem Projekt viel gelernt, insbesondere, was das Zusammenspiel von Redaktionssystem und intelligentem mobilem Informationsprodukt angeht. Im Augenblick entsteht eine Masterarbeit auf der Grundlage unserer Erkenntnisse.

Auf der kommenden tekom-Tagung haben wir außerdem eine Demo-App im Gepäck, mit der Sie sehen können, wie die hier erarbeiteten Konzepte in der Praxis aussehen. Falls Sie noch keine Karten zur tekom Messe haben – kein Problem: Hier anmelden und Sie erhalten gratis von doctima Ihren persönlichen Aktions-Code für eine Freikarte. Und übrigens: Besucher unseres Messestands erhalten einen kostenlosen 3D-gedruckten „Textbaustein“.

Content Connected

Content Connected

Content Connected

Kürzlich gestand mir eine Technische Redakteurin: „…Und dann kopiere ich die einzelnen Technischen Daten in die Eingabemaske für die App und das Online-Portal. Das ist schon recht mühselig.“

Ein anderer Redakteur zeigte mir vor einiger Zeit seine Lösung: Er erzeugt aus seiner Redaktionslösung einige tausend statische HTML-Produktbeschreibungen, mit eigenem Navigationsbereich und allem, um das Ganze dann in einem iFrame in die Webseite einzukleben, die selbstverständlich dynamisch von einem Web-CMS (WCMS) erzeugt wird. Weder die Suchmaschine noch die Sprachumschaltung der Site sind angebunden. Optik und Bedienbarkeit sind damit -nun ja- diskutabel.

Solche und ähnliche Szenarien begegnen mir immer wieder. Was mich dabei fuchst: In beiden Fällen arbeiten Technische Redaktion und Marketing mit hochprofessionellen Werkzeugen und Methoden. Auf dem Weg zum Anwender verpufft aber die ganze schöne Effizienz an fehlenden Schnittstellen.

Schatzkiste Technische Dokumentation

Was leider oft übersehen wird: In der Technischen Redaktion entstehen mit professionellen Methoden und Werkzeugen hochwertige Inhalte:

  • Konsistente, qualitätsgesicherte und umfassende Produktinformationen,
  • Strukturierte Informationen, die personalisierte Darstellung bzw. Filterung erlauben – so entstehen aus demselben Ausgangsmaterial Sichten für Kunden, Partner, Mitarbeiter,
  • Hochwertige und durch Standardisierung kostengünstige Übersetzungen,
  • Professionell erstellte Grafiken und Bilder,
  • Metadaten, die z. B. über Facettensuche oder Kriterienfilter einen gezielten Zugang zum Produktportfolio ermöglichen.

Diese Inhalte werden häufig ausschließlich für die mit dem Produkt ausgelieferte Technische Dokumentation verwendet. Bestenfalls erstellt die Technische Redaktion auch Schulungsunterlagen und Produktblätter.

Profit für mehr Abteilungen

Wir haben uns diese Schnittstellen einmal systematisch angesehen und waren selbst überrascht, wie viele Unternehmensbereiche von diesem Datenschatz profitieren könnten. Insbesondere für Vertrieb und Marketing bieten sich vielfältige Optionen, die Informationen im Unternehmen weiter zu verwerten:

  • Produktbroschüren, Kataloge
  • Website, Shop
  • Produktpräsentations-Unterlagen
  • Reparatur- und Wartungsanleitungen
  • Support-Datenbank, Knowledge Base
  • Anforderungs-Management
  • ERP, PLM
  • … u. v. m.

Diese Informationsangebote entstehen zum überwiegenden Teil nicht in der Technischen Redaktion. Es gibt aber an zahlreichen Stellen Schnittmengen zu den Daten, die in der Technischen Redaktion erarbeitet werden. Nicht immer, und da sind wir wieder bei den Beispielen vom Anfang dieses Beitrags, findet allerdings an diesen Schnittstellen ein effizienter Abgleich statt.

Ein typisches Szenario sieht meist so aus:

  • Mehrfacherfassung und/oder Copy-Paste,
  • inkonsistente, teils widersprüchliche Stände zwischen den Medien,
  • fehlende Sprachversionen in einigen der Medien,
  • Verzögerungen und Koordinationsprobleme zwischen den Medien,
  • detaillierte Produktinformationen sind im Web nur als PDF verfügbar (Lokale Suchmaschine, Google, User Experience, etc.).

 

Aus diesen Erfahrungen heraus haben wir unser neues Produkt ContentConnect entwickelt. Mit ihm schaffen wir eine konfigurierbare Schnittstelle, um die Informationen aus der Technischen Redaktion an fast beliebiger Stelle automatisiert einbinden zu können. Zu den Details des ContentConnect und konkreten Einsatzbeispielen lassen wir demnächst einen eigenen Beitrag folgen.

Information 4.0: Gut aufgestellt und kräftig herausgefordert

680996_web_R_by_Martin Büdenbender_pixelio.de

Die Herausforderung wartet…
(c) Martin Büdenbender / pixelio.de

„Information 4.0“ war ja das Leitthema der tekom-Frühjahrstagung in Darmstadt, von der ich vor Kurzem hier schon einmal berichtet habe. Was steckt aber hinter diesem Begriff? Und was bedeutet er für die Dokumentations-Branche, in der wir von doctima ja auch zuhause sind?
Auf der Rückfahrt von Darmstadt habe ich mit meinem Kollegen Edgar Hellfritsch angeregt und auch kontrovers darüber diskutiert. Hier unser Fazit.

Kurze Begriffsklärung
Information 4.0 – was bedeutet das? Kurz gesagt: Unter diesem Schlagwort subsummieren sich all die Anforderungen und Anpassungen im Bereich der Produktdokumentation, die sich aus dem Konzept (Vorsicht: schon wieder Schlagwort) „Industrie 4.0“ ergeben. Also jener erwarteten vierten industriellen Revolution, die sich aus der „Informatisierung der Fertigungstechnik“ergibt.
Wie kann man sich die „Information 4.0“ konkret vorstellen? Dazu ein einfaches Beispiel: Das Bordhandbuch eines Autos wird heute komplett von einem Technischen Redakteur zusammengestellt; er sorgt vor Auslieferung dafür, dass das Handbuch nur die modellspezifischen Informationen enthält. Diese Aufgabe der modellspezifischen Zusammenstellung übernimmt unter Bedingungen der „Industrie/Information 4.0“ das Auto selbst. Dafür werden jedem Bauteil (oder jeder Baugruppe) alle benötigten Anwenderinformationen direkt mitgegeben; es gibt also gar kein fixes Bordhandbuch mehr. Will man im Auto zum Beispiel etwas zur Klimaanlage wissen, holt sich das Informationssystem des Autos zum Zeitpunkt der Anfrage alles Notwendige direkt von der entsprechenden Baugruppe. Und wird die Baugruppe ausgetauscht, steht automatisch auch die korrekte neue Dokumentation zur Verfügung.

Was bedeutet das für die Technische Redaktion?

Application_field_automotive.

Vernetzte Produktion.
(c) KUKA Systems GmbH – CC-BY-SA-3.0

Das klingt für den ein oder anderen vielleicht noch sehr nach Zukunftsmusik. Aber der Wandel zur „Industrie 4.0“, der die „Information 4.0“ nach sich zieht, ist bereits im Gange. Das hat nicht zuletzt die Keynote von Prof. August-Wilhelm Scheer auf der tekom-Frühjahrstagung gezeigt. Es ist also der richtige Zeitpunkt, das Thema (frühzeitig) in jener Zunft anzugehen, die im Produktionsprozess gerne vergessen wird: der Technischen Redaktion.

Von der tekom-Tagung sind wir mit dem Eindruck zurückgekehrt, dass aber besonders die Technische Redaktion an einigen wichtigen Punkten schon gut aufgestellt ist. Zumindest, wenn sie auf Höhe der Zeit betrieben wird:

  • Der Tatbestand eine fast kompletten Modularisierung, die den Produktionsprozessen noch bevorsteht (Stichwort „Losgröße 1“), ist für uns in der Technischen Redaktion nichts Neues. Damit beschäftigen wir uns im Grunde schon seit gut 15 Jahren. Hier ordnen sich Erfassungsstrategien und -technologien wie Regelbasiertes Schreiben und Content-Management-Systeme nahtlos ein.
  • Die Produktionsprozesse 4.0 leben von der Selbstbeschreibung der verarbeiteten Produkte und Komponenten. Selbstbeschreibung bedeutet für die Technische Kommunikation den systematischen Einsatz von Metadaten bzw. semantischen Ontologien. In professionellen Redaktionsprozessen sind diese Technologien heute geübte Praxis.
  • Unter dem Schlagwort „Content Delivery“ etablieren sich in der Technischen Redaktion in jüngster Zeit Lösungen für die intelligente Verteilung von technischen Informationen. Auch dieses Wissen kann direkt produktiv werden.

So weit ein paar – zugegeben sehr konzentrierte – Stichpunkte zur Habenseite. Natürlich sind diese Themen alles andere als trivial. Wer als Unternehmen hier Nachholbedarf hat, sollte sich jetzt auf den Weg machen. Nicht nur, um „irgendwann später“ einmal für die Industrie 4.0 gewappnet zu sein. Vielmehr geht es darum, die organisatorischen und wirtschaftlichen Potenziale zu nutzen, die in modernen und sauber konzipierten Redaktionsprozessen liegen.

Drei große Herausforderungen

650291_web_R_K_B_by_Markus Vogelbacher_pixelio.de


(c) Markus Vogelbacher / pixelio.de

Daran muss aus unserer Sicht die Technische Redaktion noch arbeiten, soll das mit der Information 4.0 wirklich klappen:

  • In Vorträgen auf der tekom-Tagung ist es eher lapidar angesprochen worden: Für das Modell Information 4.0 muss „halt noch“ ein einheitliches und natürlich verbindliches Informationsmodell verabschiedet werden. Also ein Standard wie DITA oder AutomationML. Nur so lässt sich sicherstellen, dass die verteilt erstellten Informationen grundsätzlich kompatibel sind. Was allen Beteiligten aber klar sein muss: Einfach wird dieser Prozess der Abstimmung und Vereinheitlichung ganz sicher nicht.
  • Information 4.0 verstärkt den Trend zur produktzentrierten und bis zur Sinnlosigkeit standardisierten Dokumentation. Wir bei doctima betrachten diese Entwicklung schon länger mit Sorge. Wo bleibt in dieser Denke der Anwender mit seinen Informationsbedürfnissen, die sich ganz sicher nicht an der Produktstruktur ausrichten und vielmehr individuell und experimentell geprägt sind?
  • Stichwort „Sicherheit“: Wo Produktions- und Informationsprozesse webbasiert laufen sollen, darf es in Sachen Sicherheit keine Lücken geben. Auch hier gibt es ganz viel zu tun.

Wir wünschen uns, dass die Technische Kommunikation den Weg zur Industrie 4.0 selbstbewusst und aktiv mitgestaltet. Unsere Branche hat zum einen schon viel Erfahrung gesammelt – und zum anderen müssen wir als TR-Verantwortliche selbst dafür sorgen, dass unsere Belange auch wirklich berücksichtigt werden.

Was stehen Sie zur „Information 4.0“?
So weit eine Zusammenfassung unserer Beobachtungen und Gedanken. Wie stehen Sie zu diesem Thema? Ist es für Sie nur ein Buzzword? Oder haben Sie schon Erfahrungen mit so gestalteten Informationsprozessen? In diesem Sinne „Kommentar frei“ für eine angeregte Diskussion.