© Gennadiy Poznyakov / 123RF.com

Viel Wissen im Unternehmen ist versteckt, lauert bestenfalls unter der Oberfläche. Um wertlose Silos zu vermeiden, müssen Firmen im Alltag Wissen sichern, erzeugen, teilen, managen und vermehren, ohne sich zu verzetteln.

Eine Stärke des Dokumentationsteams bei Suse lag darin, dass es immer wieder innovative, einfallsreiche Lösungen finden musste. 2014 hatte das Team sechs Mitarbeiter; der Firma war aber schon klar, dass die Verbreiterung des Produktportfolios (man ging in die Cloud und zu Containern) eine Vergrößerung des Doku-Teams bedeuten musste. Ein paar Jahre später waren es bereits 16 Schreiber und Schreiberinnen.

Wer jetzt denkt, die Writer fanden die Idee des Wachstums super, der täuscht sich. Anfangs war das Team absolut sicher, derlei Aufstocken sei schlicht unmöglich, weil die Ressourcen für das Anlernen fehlten: “Wir können keine neuen Mitarbeiter aufnehmen, wir sind doch schon mit der neuen Produktdoku ausgelastet. Wer soll das denn machen?”, sagten die Technical Writer. Zwar gab es eine exzellente Dokumentation für Neueinsteiger, sogar einen “Hitchhiker’s Guide to the SUSE Documentation” (HHGSD [1]), doch das Anlernen neuer Mitarbeiter war trotzdem zeitaufwendig, das Onboarding dauerte Wochen.

Nun ist Ressourcenmangel beim Onboarding ein allzu bekanntes Problem. Einer alten Weisheit aus dem Projektmanagement zufolge ergibt es ab einer bestimmten Phase keinen Sinn mehr, neue Mitarbeiter hinzuzufügen, um Abläufe zu beschleunigen, im Gegenteil: Es hemmt die Produktivität nur. Doch Alltagswissen dauerhaft abzuspeichern und implizites (also verstecktes) Wissen in explizites (offen bekanntes) umzuwandeln, war gerade die Domäne von Suses Doku-Team.

Aus der Not geboren entstand die Idee für eine Lösung – die Anforderungen waren ohnehin klar: Neue Mitarbeiter müssen so schnell wie möglich produktiv beitragen und Wissen erwerben, während die aktuellen Schreiber gleichzeitig die Neuen betreuen, ihre Dokumentation schreiben und darüber hinaus den internen Wissensbestand in Form des HHGSD aktuell halten und Fehler beseitigen. Ohne Mitwirkung der Neuen war das unmöglich, aber es brauchte Methode.

Die Neuen in den Workflow integrieren

Schnell kristallisierte sich heraus, dass agiles, rekursives Arbeiten nötig wäre, mit Mentoring, Kanban-Boards, Review-Meetings und dem iterativen Infragestellen von vermeintlich sicherem Wissen. Die Neuen lernten schnell, wo der Wissensbestand seine Fehler, Schwächen und Tücken hatte, und dokumentierten sie. In regelmäßigen Meetings mit den persönlichen Mentoren besprach man, ob tatsächlich ein Fehler der Dokumentation vorlag, der dann flugs korrigiert (und die Verbesserung getestet) wurde.

So entstand das sogenannte Agile Recursive Onboarding, wo die Neuen von Anfang an in den Prozess integriert waren. Ein Doku-Mitarbeiter übernahm die Pflege der Onboarding-Dokumentation, die schnell in einem Kanban-Board landete (Abbildung 1) – zunächst in Trello, später in freien Tools.

Abbildung 1: Ein einfaches Kanban-Board (hier in Nextcloud Decks) hilft beim Onboarding und erlaubt es, Prozesswissen zu sammeln.

Das Team definierte nach Zeitpunkten geordnete Tasks wie “vor dem ersten Tag” (vom Mentor zu erledigende Vorbereitungen für den oder die Neue), “erster Tag”, “erste Woche” oder “nach vier Wochen”. Unterschiedlichen Personen zugewiesen, wuchsen sie zum Master und zur Single Source of Truth für alle Prozesse des Teams. Das reicherte die Aufgaben mit Links und Hinweisen zu anderen Datenquelle und Ressourcen an. Die Newbies schoben erledigte Tasks in die Done-Spalte, Review Meetings mit dem Mentor konzentrierten sich schnell auf unerledigte Aufgaben.

Hin zum agilen, rekursiven Onboarding

Das Team wuchs, und mit ihm die Onboarding-Doku, getragen von den neuen Mitarbeitern und ihren Mentoren. Aus dem initialen Trello-Board entstand ein Template, das ein dafür zuständiger Writer eigenverantwortlich pflegte. Die Mentoren lieferten dazu Input, wenn Fehler oder Unstimmigkeiten auftauchten. Bei Neuzugängen kopierte der Template-Verantwortliche das Board in eine neue Version, die seinen Namen trug. Nur so konnte das Team gleichzeitig wachsen, die eigenen Prozesse dokumentieren und Qualitätsmanagement am Wissensbestand betreiben.

Suse war auch deshalb etwas Besonderes, weil die Open-Source-Company über eine moderne Fehlerkultur verfügte und kaum Mitarbeiter mit Domänenwissen hatte, deren Existenzberechtigung im Nichtteilen von Wissen bestand. Grace Hopper hätte sich gefreut, denn die Bereitschaft, Neues auszuprobieren und Altes infrage zu stellen, war vergleichsweise hoch. Das erklären auch Bettina Baum und Sandra Gerhards in ihrem Buch “Wissen verlernen” (siehe Buchtipps in dieser Ausgabe) zu einem der “7 Bausteine guten Wissensmanagements”.

Der geschilderte Prozess wendet genau diese sieben Schritte praxisgerecht an: Die Spalten im Kanban-Board definieren Ziele. Die Tasks enthalten Links und Informationen zu Wissen, das die neuen Mitarbeiter konsumieren und gegebenenfalls selbst erzeugen und gemeinsam mit ihrem Mentor über das Template speichern und teilen. Anwenden müssen sie es ohnehin, in Review Meetings mit den Mentoren gehen sie die Einträge durch.

Da das Vorgehen einige agile Methoden nutzt und dabei rekursiv jederzeit alles hinterfragt, inklusive der Methoden selbst, erhielt es die Bezeichnung Agile Recursive Onboarding (ARO). Später wurde es zur Agile Recursive Documentation (ARD) ausgebaut, die darauf abzielt, auf der Metaebene der OSI-Layer 8, 9 und 10 implizites, internes Prozesswissen in Firmen in Schriftform zu übertragen.

Zunehmend bedeutsam: Wissen manifestieren

In Zeiten, in denen graubärtige Unix-Admins und Nerds der ersten Computergeneration in den Ruhestand gehen und dabei oft ihr Wissen mitnehmen, wird Dokumentation immer wichtiger.

Wer kennt nicht die Geschichten wie die, in der Admins einer bayerischen Kommune mehrere Generationen ehemaliger Mitarbeiter abklappern mussten, nur um festzustellen, dass der Autor eines zwar wichtigen, aber unverständlich geschriebenen Perl-Skripts bereits vor Jahren verstorben war. Admins einer US-Firma hatten mehr Glück, aber erst, als sie dank eines Bart-Simpson-Posters herausfanden, dass das Prozessmodell des Firmen-Tools eines ehemaligen Entwicklers sich sehr strikt an die Beziehungen der Simpsons-Charaktere untereinander hielt und deren Namen dafür verwendete – ein forkender Prozess hieß beispielsweise »Apu«.

Die Methode der agilen rekursiven Dokumentation kann überall helfen, wo es gilt, aus der Praxis heraus Wissensdatenbanken, Knowledge Bases oder Produktdokumentationen zu befüllen, zu erstellen, zu überarbeiten oder neu zu strukturieren. Die Frage nach der richtigen Software (Confluence, Jira, Mediawiki, Trello, Exchange, Sharepoint, Owncloud oder Nextcloud) stellt sich dabei erst ganz am Schluss, wenn alles andere geklärt ist. Wer mit unformatiertem Plaintext anfängt, kann sich auf den Inhalt konzentrieren und hält sich bezüglich der Tools alle Optionen offen. Formatierungen spielen meist ohnehin erst eine Rolle, wenn es um ein Ausgabeformat oder eine Veröffentlichung geht.

Im Alltagsbetrieb Wissen generieren

Selbst in kleinen Formaten wie Meeting Minutes, Agenden oder wöchentlichen Reports schlummert wertvolles Unternehmenswissen. Teams, die diese Aufgaben strukturiert angehen und die Inhalte gezielt ablegen, erzeugen wichtiges Prozess- und Unternehmenswissen, das sich oft nicht nur für neue Mitarbeiter als hilfreich erweist.

Die Ausgestaltung hängt individuell vom Team ab, aber ein paar Beispielregeln helfen beim Start. Wichtig ist, dass die Arbeitsweise dem Team entspricht und von ihm getragen wird. Daher sind die folgenden Eckpunkte nicht in Stein gemeißelt:

• Zu jedem Meeting gibt es eine Agenda und Gesprächsnotizen.
• Die Agenda entsteht aus einem Template in einem kollaborativen Editor wie Etherpad [2] (gegebenenfalls mit integriertem Videochat [3]). Die Teilnehmer befüllen sie vor dem Meeting.
• Ein Protokollführer schließt die Agenda am Tag vor dem Meeting.
• Er überführt die Inhalte in Besprechungsnotizen, finalisiert den Text und überführt ihn in ein CMS, Wiki oder Git.

Bei größeren Gruppen empfiehlt es sich, einen Protokollführer zu definieren, der das Editieren koordiniert und es anderen Teilnehmern im Meeting explizit erlaubt zu editieren. In den meisten Teams hat es sich bewährt, den Posten per Round Robin zu vergeben und den Beteiligten so einen Blick über den Tellerrand auf die Arbeit der anderen zu ermöglichen.

Templates und Vorlagen helfen dabei, Meetings schneller vorzubereiten. Solche Agenden erleichtern auch die Übergabe etwa bei Krankheit. Hier offenbart sich der Übergang von ARO und ARD zu Prozessdokumentation und Projektmanagement.

Wie sich mit Farbe Wissen erzeugen lässt

Die passende Struktur für die Notizen ist gleichermaßen elementar wichtig und individuell: Sie sollte sowohl das Weiterverarbeiten erlauben als auch zur Aufgabenverteilung und Arbeitsweise des Teams passen.

Einerseits ließe sich eine Agenda nach den zu besprechenden Produkten oder den Teilnehmern organisieren, andererseits nach der Priorität der Themen. Für Jours Fixes und wöchentliche Reports hat sich dabei das Rot-Gelb-Grün-Modell bewährt. Rot bedeutet eine Eskalation im Sinne von “Das verlangt eine Aktion”, “Hier liegt ein Problem, ich brauche Hilfe”. Gelb bedeutet “Dieses Thema könnte noch explodieren”. “Grüne” Themen schildern schlicht, was alles geklappt hat oder problemlos läuft. Der Kasten “Wochenreport an den Teamleiter” zeigt ein einfaches Beispiel für solchen Bericht.

Derlei strukturiere Notizen im Rot-Gelb-Grün-Format taugen wunderbar als schnelle, wöchentliche Reports für den Chef. Die Mitarbeiter fassen kurz zusammen, woran sie gearbeitet haben. Der Chef liest nur die roten Absätze, weil sie eine Aktion von ihm verlangen. Gelbe Absätze liest er, falls er Zeit hat, grüne nur, wenn er stolz auf sein Team sein möchte. Dieser Rot-Gelb-Grün-Ansatz ist flexibel und werkzeugneutral, er lässt sich für jedes Unternehmen anpassen.

Im Kasten “Besprechungsnotiz” findet sich eine Adaption für Meeting Minutes eines Teams. Nach einleitenden Metainformationen, dem Review der Themen der Vorwoche und den aktuellen Themen führt es unter “What’s next” die Arbeitsaufgaben auf.

Beim Vorbereiten der Agenda können Teilnehmer vor dem Meeting Einträge anlegen. Deren Nummerierung kann Ticketnummern, Git Issues oder dergleichen widerspiegeln. Wer hier gleich auf Git setzt, gewinnt viele Vorteile – allerdings überfordert das Tool nichttechnische Mitarbeiter häufig. Der Protokollführer kopiert die Aufgaben der Vorwoche in den Review-Bereich, wo sie verbleiben, bis sie entweder gelöst oder verworfen werden.

Wider die ledigen Grundsatzdiskussionen

Eine (wärmstens zu empfehlende) Besonderheit im Kasten “Besprechungsnotiz” stellt der Bereich “Exkurse” dar. Hier landen alle Themen, die die Anwesenden als vielleicht interessant, aber wenig hilfreich einstufen. Die Anwesenheit in dieser Diskussionsrunde am Ende des Meetings ist fakultativ.

Ein derartiges Vorgehen wirkt sich vor allem in solchen Teams entspannend aus, die häufig Grundsatzdiskussionen führen. Nach dem Meeting übertragen die Protokollführer die Informationen beispielsweise in ein Wiki oder in Confluence, und schon entsteht eine erste Wissenssammlung darüber, wer woran arbeitet. Exkurse werden nicht in die nächsten Wochen weitergetragen.

Manche Teams werden gleich in Wikis oder in Git arbeiten wollen, das Modell lässt sich einfach übertragen. Nicht zu verachten ist dabei der Effekt, dass Medienbrüche und das manuelle Übertragen durch den Perspektivwechsel oft kreativen Input erzeugen. Im Git, Confluence oder einem Wiki entsteht so eine Wissenssammlung, ergänzt durch eine intelligente Suchfunktion zum schnellen Finden von Inhalten. Aufschluss über die Bedürfnisse und offenen Fragen geben die Zugriffszahlen oder die Auswertung der Suchanfragen.

Herausfinden, was es noch zu dokumentieren gilt

Für einen mittelständischen IT-Betrieb, der in über 40 Jahren im Zuge von diversen Akquisitionen und Mergern eine Vielzahl von Tools, Servern, Datenspeichern und verteiltes Wissen angehäuft hat, erstellten Experten einen Workflow für einen Dokumentationsprozess in 14 Schritten.

Die Tabelle “In 14 Schritten zur Prozessdokumentation” zeigt einen Auszug als Text. Häufig bietet es sich jedoch an, grafische Darstellungen zu verwenden. Nicht immer muss dazu gleich ein vollständiges Business Process Model and Notation (BPMN [4]) herhalten: Abbildung 2 zeigt, dass selbst simple Grafiken funktionieren. Diese Visualisierung half einer Firma, den neuen Open-Source-Weg zu verstehen.

Abbildung 2: Schon einfachste Flowcharts veranschaulichen komplizierte Prozesse.

Der Mittelständler mit seinen Datensilos hatte bemerkt, dass die meisten Mitarbeiter sich regelmäßig über ineffizientes Suchen nach Arbeitsanweisungen beschwerten. Meist war unklar, wo die Prozessdokumentation zu finden sei. Die Experten schlugen vor, alles in einem Kanban-Board zu dokumentieren, was mehr als 10 Minuten Suche erforderte. Dieses Board sollte dann als Materialsammlung für die Verantwortlichen dienen sowie der Geschäftsführung einen Überblick verschaffen.

Auch die Industrie hat solche Silo-Probleme längst erkannt, IBM und andere nennen die Lösungen Data Fabric. Hersteller wie Owncloud adressieren die Thematik mit Produkten wie Infinite Scale (OCIS) und versprechen beispielsweise Silo-übergreifende Suchfunktionen im Web-Frontend.

Was den Anwendern wirklich weh tut

Anhand von To-do-Listen entschied das Management im vorliegenden Fall, was zu dokumentieren sei, und benannte Verantwortliche, die in Dokumentationssprints zusammenkamen und loslegten. Nicht immer muss das so formal und kompliziert ausgestaltet sein wie im Beispiel, wo erst über Inhalte, Verantwortlichkeiten und andere Rahmenbedingungen entschieden werden musste, bevor die Doku-Experten ans Werk gehen konnten.

Das im letzten Schritt der Tabelle “In 14 Schritten zur Prozessdokumentation” aufgeführte Kriterium der “Triage by User Pain” [5] ist ein (Scoring-)Ansatz aus der agilen Softwareentwicklung. Er zielt darauf ab, einen etwas ganzheitlicheren Ansatz für die Schwere eines Bugs zu finden und so die wirklich wichtigen Fehler effizienter zu identifizieren.

Beim angesprochenen Mittelständler integrierten die Experten darüber hinaus eine einfache Art des Qualitätsmanagements über ein Punktesystem von 0 (keine Doku vorhanden) bis 100 (perfekte Doku liegt vor). Eine 0 muss nicht schlimm sein: Es gibt auch Prozesse, die keine Dokumentation benötigen – ein weiteres Datum, das als “keine Doku notwendig” in die Metadaten Einzug hielt.

Zum Prozess passende Zwischenstufen (etwa in Zehnerschritten) erwiesen sich ebenfalls als hilfreich, vor allem, weil sie sich farbkodiert in Wiki-Tabellen abbilden lassen. Diesen Ansatz können Wissensmanager individuell maßschneidern: Wem es beliebt, der kann auf das ganze Portfolio der agilen Tools und Tricks zurückgreifen, von Epics über User Stories zu Scrum, Story Telling und vielem mehr.

Dokumentationsformate und Style Guide

Fast immer entscheidet sich früh, welche Formate die zu erstellenden Dokumentationen haben sollen. Der Kasten “Wochenreport an den Teamleiter” veranschaulicht eines der gebräuchlichsten, sehr einfachen Dokumentationsformate, eine Checkliste. Die eingangs erwähnte Kanban-Board-Lösung fürs Onboarding folgt ebenfalls diesem Format. Die Zusammenstellung aus dem Kasten “Besprechungsnotiz” dagegen ist als eine noch vergleichsweise generische Vorlage für Gesprächsnotizen oder wöchentliche Reports eher den Best Practices zuzuordnen.

In der praktischen Arbeit haben sich ferner Cheat Sheets (“Spickzettel”), Quick Start Guides, Topical Guides zu einzelnen Themen (siehe IBMs berühmte Redbooks) sowie Referenzdokumentationen (für APIs idealerweise automatisiert erzeugt [6]) bewährt. Hinzu kommen oft How-tos, FAQs, Marktübersichten, UI/UX-Dokumentationen und ähnliche längere Dokumente (siehe nächster Abschnitt).

Ganz egal, was im Einzelfall zum Einsatz kommt: Es sollte klar definiert sein, beispielsweise in einem Style Guide. Der ist so kurz wie möglich gehalten und enthält die maximal erlaubte Anzahl an Formatierungen für Texte im Unternehmen, die etwa in einem Wiki landen.

Wer die Aufgabe übernimmt, einen Style Guide zu erstellen, muss sich immer wieder die gleichen Fragen stellen: “Brauchen wir das? Und geht das nicht einfacher?” Die Reduktion auf den kleinsten gemeinsamen Nenner bei Formatierungen, Inhalten und Auszeichnungen hilft, Texte lesbarer zu machen, und erhöht den Wiedererkennungswert. In Tabellen und Listen dienen farblich kodierte Zellenhintergründe und Emojis dazu, den Leser schon optisch auf die relevanten Daten hinzuweisen. Abbildung 3 zeigt das exemplarisch an einem Template für einen Redaktionsplan des News-Blogs einer Firma (in Confluence).

Abbildung 3: Ein Redaktionsplan für ein Blog mit Farbkodierung und Emojis.

Die interne Knowledge Base strukturieren

Als Knowledge Base bezeichnen Experten Software, mit der sich Wissen zentral hinterlegen lässt. Unternehmen und Organisationen benötigen so etwas zum Beispiel für das Beschreiben von Produkten und Dienstleistungen, Kundenprojekte, Partnernetze, Schulungsmaterialien, aber auch zum Planen von Projekten und Kampagnen, für Protokolle und Berichte und nicht zuletzt für die interne Prozessdokumentation. Im Idealfall lagert in der Knowledge Base jedes Wissen, das Mitarbeiter brauchen, um die tägliche Arbeit schnell und fehlerfrei zu erledigen.

Für diese Aufgabe haben sich Wikis in Unternehmen als Standard etabliert, beispielsweise Bluespice Mediawiki [7], die Enterprise-Distribution der Software Mediawiki, die Wikipedia antreibt. Wikis stellen Wissen zentral und bequem zur Verfügung, Mitarbeiter greifen per Webbrowser darauf zu, finden Inhalte unkompliziert über Suchfunktionen und können mit modernen Editoren gemeinsam Wissen erzeugen, ergänzen oder aktualisieren. Sie können (und müssen) mit sehr heterogenen Inhalten umgehen, wobei nicht jeder Inhalt für jeden Nutzer relevant ist.

Damit Teams, Abteilungen oder Projekte zielgenau mit den für sie wichtigen Inhalten arbeiten können, gilt es, Informationen in Themengruppen wie Vertrieb, Fertigung oder Personal zu organisieren und Inhalte in unterschiedlichen Formaten (Dokumenttypen) abzulegen. Es gibt Beschreibungsartikel, Protokolle, Checklisten, Planungsdokumente und vieles mehr. Inhalte können strukturiert sein, müssen es aber nicht. Je nach der Phase eines Arbeitsprozesses sind sie unterschiedlich vorstrukturiert.

Erweiterungen wie die Draw.io-Flowcharts in Bluespice greifen Nutzern bei der Visualisierung unter die Arme. Zugriffsberechtigungen regeln, wer was lesen, löschen oder bearbeiten darf. Assistenzsysteme helfen beispielsweise dabei, Dokumente vorab zu sichten und freizugeben. Manche Inhalte benötigen unterstützende Workflow-Funktionen und Erinnerungssysteme.

Das Standard-Mediawiki bringt vier Strukturierungsfunktionen mit, die dazu dienen, die Themengruppen, Dokumententypen, Zugriffsberechtigungen, Assistenzsysteme und Sprachvarianten in den Griff zu bekommen. Dazu zählen Unterseiten, Namensräume, Kategorien und die Kombination mehrerer separater Wikis. Komplexe Inhalte lassen sich so verteilen und miteinander verknüpfen. Das Cloud-Produkt Bluespice pro hat außerdem mit Semantic Mediawiki zusätzliche semantische Funktionen eingebaut, die es erlauben, Wiki-Seiten mit Metadaten anzureichern und automatisiert auszuwerten.

Die Buchfunktion erlaubt es, Seiten in eine starke hierarchische Struktur zu bringen. Bücher, Kategorien, Unterkategorien oder völlig separate Wikis helfen Firmen, das vorhandene Wissen mit ihrer spezifischen internen Organisation zu mappen. Namensräume helfen dabei, das Wissen zu ordnen. Die unterschiedlichen Dokumententypen wie Artikel, Planungsdokumente, Protokolle oder Entscheidungsverzeichnisse und Aufgabenlisten packt man am besten in jeweils eigene Namensräume wie Artikel (der Hauptnamensraum), Planung, Protokoll, Aufgabe, Report, Richtlinie oder Dokumentation.

Die Dokumententypen lassen sich fast beliebig komplex ausgestalten, etwa mit Unterseiten wie Richtlinie:Produkt/ oder Richtlinie:Vertrieb/. Die Dokumententypen kann man dann mithilfe von Kategorien verschlagworten und so verschiedenen Themengruppen wie Kundenbetreuung, interne IT oder Produktion zuordnen. Auch hier gibt es die Möglichkeit, über Unterkategorien wie Produktion/Fertigung, Produktion/Montage oder Produktion/Logistik komplexe Unternehmensstrukturen nachzuzeichnen. Dieses Verfahren erzeugt eine Matrix, über die sich schnell alle Protokolle der internen IT auflisten oder über die Suchmaschine finden lassen.

Ausblick: Neues Jobprofil Informationsmanager

Wer sich jetzt von der Vielfalt und dem Umfang der praxisrelevanten Informationen in diesem Artikel erschlagen fühlt, den tröstet vielleicht die Tatsache, dass die Job Description “Informationsmanager” (IM) immer häufiger in Unternehmen auftaucht, selbst in kleineren. Der oder die IM hat alle Fäden in der Hand und muss Kompetenzen aus Dokumentation, Qualitätssicherung und Projektmanagement vereinen. Im Optimalfall verfügen IMs über eine passende akademische Ausbildung, eine empathische und praxisorientierte Persönlichkeit ist jedoch ebenfalls zwingend. Nur wer das Thema nicht verkopft-akademisch angeht, sondern sich sowohl technisch als auch am Geschäftserfolg orientiert, wird da erfolgreich sein. (csi/jlu)