Dokumentation

Es kommt der Zeitpunkt, an dem etwas nicht mehr geht. Und dann sind sie froh, wenn es ein Stück Papier oder eine Textdatei gibt, in der die hoffentlich aktuellen Einstellungen hinterlegt sind. Wie kann man Exchange dokumentieren ?.

  • Mit dem Problem der Dokumentation stehen Sie nicht alleine. Nahezu jede Firma hat das "Problem" der Dokumentation und das ist oftmals hausgemacht:
  • Einer muss den Anfang finden
  • Jeder dokumentiert unterschiedlich mit anderen Programme
    Word, HTML, Notepad
  • Einige Programme "dokumentieren" selbst
    z.B. Inventarisierungssoftare, WSUS (Patchmanagement), Helpdesksysteme (Veränderungen )
  • Niemand fühlt sich wirklich verantwortlich
  • Dokumentation "veraltet" sehr schnell

Zu viele Personen glauben, dass eine Dokumentation immer den Charakter eines "Buchs" haben muss, was möglichst "perfekt" aussehen sollte. Dies ist ein hoffnungsloses unterfangen. Ich merke das schon, wenn ich als Autor meines Buchs (Exchange 2003 - Ein Buch zum Thema) hier "aktuell" bleiben will.

Was muss eine Dokumentation bieten ?

Eine Dokumentation in einer Firma zeichnet sich dadurch aus, dass idealerweise mehrere Personen ihren Teil eigenständig dokumentieren. Das stellt natürlich an die Organisation der Dokumentation einige Anforderungen:

  • Versionen und Vereinzelung
    Dokumente werden überarbeitet und geändert, weil sich auch ein Netzwerk weiterentwickelt. In der aktuellen Dokumentationen sollte auch der aktuelle Stand dokumentiert werden. Alte Systeme und Einstellungen sollten zur besseren Übersicht auch entfernt werden. Wenn aber doch jemand in die Vergangenheit schauen will, dann hilft eine möglichst automatische Versionsverwaltung, die frühere Versionen weiter vorhält.
    Das funktioniert natürlich sehr viel einfacher, wenn es nicht ein großes Gesamtdokument sondern viele kleine eigenständige Dokumente gibt, die aber miteinander verbunden sind.
    Damit ist natürlich auch verbunden, dass ein System Dokumente über Verfahren Einchecken und Auschecken kann
  • Struktur und Views
    Niemand kann effektiv mit hunderten von Dokumenten in einem Verzeichnis arbeiten. Daher sind Zusammenstellungen von Dokumenten für bestimmte Zielgruppen sinnvoll. So könnte ein Exchange Dokument sich aus den verschiedenen Bausteinen die erforderlichen Teile zusammenführen. Genau genommen kann so z.B. ein Active Directory Konzept in verschiedenen anderen Dokumenten als Filialdokument aufgenommen werden.
  • Besitzer
    Wenn viele Personen an der Dokumentation arbeiten, dann macht es absolut Sinn, wenn jedes Dokument einen "Owner" hat, d.h. eine für dieses Dokument verantwortliche Person, welche auch als Ansprechpartner bei Änderungen dienen soll. Dokumente die "vielen" oder "niemandem" zugeordnet sind, werden meist nicht mehr gepflegt, weil jeder auf die Anderen verweist oder sich niemand zuständig fühlt.
  • Editor und Reader
    Nicht jeder spricht fließend "HTML". Leistungsstarke Editoren wie Word, Sharepoint Designer u.a. Unterstützen aktiv bei der Erstellung von Dokumenten, egal ob diese am Ende als DOC/DOCX oder HTML/XML-Datei abgelegt werden. Mangelnde Unterstützung von "Rich-Clients" ist auch das, was den Einsatz von Wikis für Firmendokumentationen nicht gut geeignet erscheinen lässt
    Allerdings spricht für WIKIs die Verfügbarkeit auf nahezu jedem Client, auf dem ein Browser gestartet werden kann. Wobei auch Word und andere Programme auch HTML und Bilder speichern können.
  • "Offline" Funktion
    Die wenigsten Editoren bearbeiten die Dateien direkt auf dem Server. Meist werden die Dokumente "herunter" geladen, lokal bearbeitet und dann wieder hochgeladen (Einchecken). Oft ist damit eine "offline Kopie" verbunden, d.h. die Dokumente liegen auch lokal, was den Server entlastet aber viel mehr auch eine Dokumentation "offline" erlaubt, z.B.: wenn Sie mit dem Notebook unterwegs, im Außendienst oder an einem Ort ohne Verbindung sind. Dann sind "Online-Varianten" wie ein Wiki von Nachteil.
  • "Multiuser"-tauglich
    Eine parallele Bearbeitung zumindest unterschiedlicher Dokumente muss möglich sein. Entsprechend sollte es "Sperrvermerke" geben, d.h. wenn ein Dokument bereits bearbeitet wird. Zudem könnte es in Verbindung mit der Versionierung auch sinnvoll sein, dass es eine "Freigabefunktion" gibt, d.h. man die Bearbeitung eines Dokuments auch unterbrechen kann aber diese noch nicht "öffentlich" ist.
  • Einfach und jederzeit erreichbar'
    Es muss sehr einfach sein, schnell etwas in der Dokumentation zu addieren oder zu erweitern. Wer dazu erst an den Arbeitsplatz zurück oder eine proprietäre Software installieren bzw. Starten muss, wird weniger oft dokumentieren. Dazu gehört auch., dass so eine System Felder wie "Datum" oder "Autor" schon alleine anhand der Anmeldung füllt.
  • Mit Daten auch per Program "füllbar"
    Idel, wenn Skripte und andere Quellen die erforderlichen Daten automatisch beisteuern.
  • Durchsuchbar
    Was wäre der heutige EDV-Mitarbeiter ohne eine Volltextsuche. :-). Was natürlich auch bedeutet, dass eine Dokumentation eben nicht nur aus "Screen Captures" bestehen darf, sondern die essentiellen Dinge schon als Text erfasst werden müssen

Eine Lösung muss daher eine ganz anderen Ansatz wählen als ein Consultant, der ein Word-Dokument mit Deckblatt, Inhaltsverzeichnis etc. erstellt und am Ende "abgibt".

Wie kann ich beginnen ?

Dabei hat Dokumentation erst mal nichts mit "Prozess Management" zu tun und bedeutet auch nicht den Einsatz einer bestimmten Software. für die Dokumentation sehe ich vier Schritte:

  1. Geeignete Plattform
    Eine Doc-Datei ist vielleicht nicht geeignet. Aber vielleicht ist ein "WIKI" (Wiki) als Ansatz. Denkbar ist aber auch Sharepoint oder eine Sammlung von OneNote-Dateien
  2. Kleine verlinkte Artikel
    Jedes Thema sollte dabei eine eigene Seite sein, die autark editiert und versioniert werden kann und sehr einfach mit anderen Seiten verknüpfbar ist. Bei einem WIKI gibt es z.B. keine feste "Struktur" sondern nur Schlüsselworte und Links. Wenn wirs genau überlegen, dann suchen wir schneller in Google als in einem Inhaltsverzeichnis eines großen Buchs.
  3. Ein Anfang machen
    Dann muss natürlich überhaupt erst mal ein Start gemacht werden. Da interne Mitarbeiter hier fast immer zu wenig Zeit dazu haben, bietet sich hier an, dass z.B. externe Mitarbeiter einzelne Themen einfach dokumentieren, wie Sie es sehen. Dann starten die eigenen Administratoren nicht mit einem leeren Blatt und nebenbei bekommen Sie auch eine dritte Meinung
  4. Mitarbeiter müssen wollen
    Eine Dokumentation lebt, d.h. die eigenen Mitarbeiter müssen die Dokumentation nicht als Pflicht, sondern als unentbehrliches Hilfsmittel akzeptieren und selbst ihren Bereich weiter pflegen.
  5. Integration schaffen
    Wenn es wünschenswert ist, kann man natürlich eine Kopplung schaffen, z.B. dass ein Script die Konfiguration eines Servers ausliest und im Serverdokument mit ablegt.

Sicher wird nicht alles in diesem System landen. Strukturierte Daten einer Softwareverteilung haben dort nichts verloren, sondern bleiben im jeweiligen System. Auch Eventlogs und andere Datenquellen sind viel zu kurzlebig. Aber wenn jemand Arbeit für etwas aufwendet, dann sollte das auch protokolliert werden. Wobei hier zu prüfen ist, ob das wirklich auch mit in die "Doku" muss, oder ein einfaches Tätigkeitsprotokoll nicht ausreichend ist.

Wir bei Net at Work dokumentieren sehr intensiv z.B. mit Supportanrufen oder über Arbeitsberichte. Wir müssen das nicht nur zwecks Rechnungsstellung tun, sondern dies hilft uns auch, wenn später Supportanrufe kommen. Keiner von uns kann die Konfiguration aller Kunden aus dem Kopf wissen.

Zur Plattform

Historisch bedingt bin ich ein "Word"-Freund. Ich habe ein Buch (Exchange 2003 - Ein Buch zum Thema) geschrieben und meine Kunden erwarten zurecht eine "Dokumentation", die man auch Drucken kann. Schon daher ist Word oder ein anderes Textverarbeitungsprogramm natürlich erste Wahl.

Persönlich begrüße ich es immer, wenn ein Kunde schon eine Dokumentationsplattform hat, in der ich mich einbinden kann. Denn durch die Arbeit an der MSXFAQ habe ich die Vorteile vieler kleiner Seiten mit Verlinkungen erkannt.

Ein paar Stichworte zu verschiedenen Systemen. Betrachten Sie diese bitte selbst bezüglich:

  • Installation und Betriebskosten
    d.h. Hardware, Server, Software, Wartung, Pflege, Lizenzen kommen hier in die Kostenrechnung.
  • Versionierung
    Aus meiner Sicht ganz wichtig ist, dass auch vorherige Versionen erreichbar sind. Es gibt immer Überarbeitungen und der Zugriff auf eine alte Version schützt nicht nur vor "Verlusten", wenn beim Editieren unbemerkt was entfernt wurde, sondern nimmt auch Hemmschwellen etwas zu korrigieren. Auch wenn es nur Kleinigkeiten sind.
  • Benachrichtigung
    Vielleicht möchte jemand über Änderungen an Seiten informiert werden, z.B.: per Mail oder per RSS-Feed. Insbesondere wenn zu jedem Abschnitt oder jeder Seite eine "Verantwortliche Person" (Owner, Besitzer) hinterlegt wurde.
  • Berechtigung und Authentifizierung
    Ich würde fordern, dass die Plattform eine integrierte Anmeldung unterstützt. Also Programm oder Browser starten und los. Vielleicht ist es sinnvoll auch Berechtigungen zum Anzeigen bestimmter Artikel einzuführen. Beim Editieren würde ich keine Beschränkung einsetzen, wenn der "Besitzer" informiert wird und dank Authentifizierung auch der Editor dingfest gemacht werden kann.
  • Verfügbarkeit, Offline, Synchronisation.
    Können die Daten an mehrere Standorte oder auf Notebooks repliziert werden ?. Geht sogar paralleles Arbeiten und offline-Arbeit ?. Das ist auch wichtig, um z.B.: bei einem Server oder RZ-Ausfall weiterhin die "Desaster"-Dokumentation lesen zu können und Änderungen zu pflegen.
  • Editor und Bearbeitung
    Nicht zuletzt natürlich die Frage, wie der Content gepflegt wird. Reicht ein einfacher Browser (Mit/ohne Java, JavaScript, CSS, Flash, andere Addins) aus oder gibt es ein vollwertiges "Rich-"Programm. Wir einfach können z.B. Bilder eingebunden werden. Muss man die erst als GIF/JPG/PNG speichern und "hochladen" oder funktioniert die Zwischenablage ?

Eventuell sind für Sie ja noch andere Kriterien wichtig. Überlegen Sie einfach, was Sie von einer Dokumentationsplattform in ihrem Betrieb erwarten. Ausgestattet mit den Kriterien können Sie dann einige Plattformen vergleichen, z.B.

Plattform Bewertung

Dateiserver mit Textverarbeitung (z.B. Word)
Klassische Plattform, die wohl jeder kennt und meist vorhanden ist

 

OneNote
Unstrukturierte Ablage in Büchern, Karteikarten und Reitern. Aber einfache Suche, Offline, Replikation. Sogar Rechter (je Buch).

 

Sharepoint Designer
Damit bearbeite ich meine MSXFAQ. Wer html-Dateien liebt und die Doku wirklich als "Web" betreiben will, kann damit arbeiten

 

CMS, Wiki o.ä.
Ob Sie ihr Wiki oder CMS nun auf Windows mit Sharepoint oder mySQL und einer Wiki-Software betreiben, bleibt ihnen überlassen. Entsprechend unterscheiden Sich aber die Funktionen bezüglich Authentifizierung, Editierbarkeit etc.

 

Blog
Ein Blog ist keine Dokumentation aber ein Anfang, Änderungen zu protokollieren. Ein Blog bietet sehr viel wie Authentifizierung, Zeitangabe, Schlagworte (Tag-Cloud) und Suche und kann ihr Dokumentationssystem begleiten. Viele Administratoren haben intern mit "Blogs" angefangen.

 

Webseite + Generator
Warum "aufschreiben", wenn das System alles weiß ? Es gibt schon Programme, die eine automatische Dokumentation ihrer Systeme versprechen. Sie können sicherlich ergänzend eingesetzt werden aber ersetzen keine Beschreibung von Konzepten und Arbeitsabläufen.

 

Welche Plattform oder Kombination von Plattformen bei ihnen passt, kann ich ihnen natürlich nicht sagen.

Welche "Dokumentarten" gibt es ?

Wenn Sie selbst noch nicht dokumentieren oder die aktuelle Form nicht mehr verwalten können, dann sollten Sie mit uns über die Umsetzung einer internen Dokumentation sprechen. Wir könnten z.B. mit ihnen die Anforderungen und Wünsche aufnehmen, ein geeignetes System auswählen und installieren und zuletzt je nach ihren Wünschen die aktuelle Umgebung dokumentieren und die Administratoren in die Benutzung einführen. Nicht immer muss alles in einer Dokumentation stecken. Gerade Betreiber trennen gerne Inhalte für verschiedene Zielgruppen ab. Dann könnten eine ganze Menge Dokumentationen:

Titel Zielgruppe Umfang Beschreibung

Produktbeschreibung

Kunde

1-2 Seiten

Als Betreiber einer SystemUmgebung "verkaufen" sie ihren Kunden ein Produkt. Viele Firmen werden nur genau ein Produkt verkaufen, aber wenn Standard und Enterprise CALs ein Kostenfaktor werden. dann werden wohl auch intern unterscheidungen stattfinden. für die verschiedenen Leistungsumfänge sollten Sie dann eigene Beschreibungen bereitstellen, die aber nicht tief technisch sind, sondern eher für Anwender verständlich sind. Vergleichen Sie dies einfach mit den Informationen, die Sie bei den Anbietern von Webpräsenzen (1&1, Strato, HostEurope, etc.) auf der ersten bzw. zweiten Ebene zur den verschiedenen Paketen erhalten.

Leistungsbeschreibung

Kunde

10-20 Seiten

Dies entspricht dann etwa dem "Kleingedruckten" nur bezogen auf die Produktleistungen. Hier sollten Sie alle Leistungen aufführen , die das System erbringen kann, d.h. die Sie theoretisch installieren können. Diese Beschreibung kann durchaus auch etwas detaillierter bezüglich der Funktion sein, aber den Leser interessiert hier natürlich nicht, wie das technisch umgesetzt ist. Das sollte auch verborgen bleiben, denn ihre technische Umgebung kann sich ja ändern.

Diese Beschreibung kann durchaus Appetit auf mehr machen, d.h. Funktionen beschreiben, die von ihnen bereit gestellt werden, aber der Kunde vielleicht noch nicht gekauft hat.

Technische Beschreibung

Intern und interessierter Kunde (Backstage)

10-20 Seiten

Diese Dokumentation sollte eine ersten Überblick über die SystemUmgebung, die Komponenten und Zusammenhänge geben. Sie sollte nicht allzu tief in die Server und Protokolle gehen, sondern die Funktionsblöcke beschreiben.

Diese Dokument ist quasi das Einstiegsdokument für Personen, die sich in die Materie einarbeiten wollen (z.B.: neue Mitarbeiter) oder Services daran anbauen müssen (z.B. Dienstleister bei der Installation von Zusatzprodukten) oder natürlich den Nachbarteams z.B. aus Bereichen wie Telefonanlagen, Netzwerkverkabelung, Firewall etc. einen Einblick zu geben.

Denkbar ist auch, dass diese Information für interessierte Kunden, quasi als "Backstage"-Information zugänglich gemacht wird. Das kann durchaus auch Imagefördernd sein.

Benutzerhandbuch

Endanwender

4-8 Seiten

Diese Dokumentation sollte dem Anwender eine Einführung in die Nutzung der angebotenen Dienste geben. Wesentlich sind hier die verschiedenen Zugangsdaten und Einstellungen, so diese nicht per Autodiscover ermittelt werden können und etwaige Besonderheiten der Umgebung. Es kann natürlich kein "Handbuch" für Outlook o.ä., sein.
In Firmen hat sich es aber als gute Praxis heraus gestellt, einfache "Aufsteller" zu verteilen, die z.B.: die Hotkeys für den Office Communicator oder wichtige Hyperlinks enthalten.

Kundenhandbuch

Kundenadmin
OU-Admin

?

Sofern die Verwaltung nicht durch Sie selbst erfolgt, sondern anderen Personen "delegiert" wird, sollten diese auch eine entsprechende Dokumentation erhalten, die diese Schritte beschreibt. Das kann die Dokumentation der verschiedenen Arbeitsschritte oder Zugänge sein und weiterführende Informationen zur Dateneingabe enthalten, sofern diese nicht über eine Provisioning-Lösung schon vorgegeben werden.
Ebenfalls ratsam sind hier ein paar Hintergründe zur Funktionsweise, speziell wenn Änderungen nicht sofort aktiv werden oder manuelle Nacharbeiten erforderlich sind.

Technische Dokumentation

Intern

?

Diese Dokumente beschreiben Server, Systeme und Zusammenhänge sehr detailliert und werden vorlaufend gepflegt. Überlegen Sie mal, ob hierfür nicht ein WIKI oder etwas ähnliches eine geeignete Plattform zur Dokumentation wäre.
Hier stehen sowohl Installationsbeschreibungen und Checklisten aber auch der aktuelle IST-Stand

Operatorhandbuch

Intern

?

Hier könnten die Tätigkeiten für Operatoren der ServerUmgebung niedergelegt sein. Eine Trennung zum "Kundenhandbuch" ist dadurch gegeben, dass Operatoren in der Regel direkt Einfluss auf die Systeme über entsprechende Management Konsolen und PowerShell Befehle nehmen können, die bei einem Admin eines Kunden, der nur für "seine Mitarbeiter" zuständig ist, nicht zur Verfügung stehen.

Diese Aufteilung ist nur ein Vorschlag, den Sie natürlich auf ihre individuellen Bedürfnisse anpassen sollten.

Wie könnte eine Struktur aussehen ?

Auch wenn dieser Abschnitt die Verwendung von Word mit DOC-Dateien nahelegt, so sollten Sie sich nicht daran binden. Eine Struktur gibt es in fast jedem normalen Dokumentationssystem (von einem chaotischen Wiki als Wörterbuchersatz abgesehen)

Die Struktur hängt natürlich davon ab, mit welchen Hilfsmitteln Sie ihre Dokumentation verfassen. Nutzen Sie einfach nur einen Satz Textdateien oder doch eher ein Textverarbeitungsprogramm wie Word. Oder ist es mehr in der Form eines Tagebuchs wie ein Blog oder doch webbasiert in einem Content Management System (CMS a la Mambo, Joomla etc.) ?. Wer eine Webseite, eine Word-Dokumentsammlung oder ein CMS einsetzt, braucht eine gewisse Strukturvorgabe

Wie sie auf Backstage vielleicht schon gelesen habe, pflege und verwalte ich die MSXFAQ komplett offline mit dem Sharepoint Designer (SPD) verwalte und dann hoch lade. So könnten Sie natürlich auch eine Dokumentation schreiben, wenn Sie lieber HTML/XML verwenden. Da aber der SPD extra zu lizenzieren ist und die meisten Personen mit Word umgehen können, ist für den internen Einsatz auch das DOC-Format geeignet.

Nun wissen die meisten Administratoren erst mal, dass man Word starten und Texte eingeben kann. Aber die wenigsten Administratoren arbeiten schon aktiv mit Filialdokumenten und Dokumentvorlagen. Aber die Filialdokumente sind der Schlüssel für eine effektive Dokumentation. Wenn Sie es schaffen, jeden Teil in einem eigenen Dokument zu pflegen und über Filialdokumente die Struktur zu bauen, dann kann die komplette Dokumentation sich wie folgt darstellen:

Da jedes Filialdokument eigenständig und ohne weitere Formatierung ist, können Sie jederzeit ein weiteres Masterdokument anlegen und ausgewählte Filialdokumente dort einbinden. Wer also z.B. eine Dokumentation für den Bereich der der Buchhaltung möchte, kann aus dem Filialdokument der Beschreibung und den Dokumenten der Server sich eine individuelle Dokumentation zusammen stellen.

Und wenn jemand z.B. das Dokument "Server3" aktualisiert, weil ein Update oder Servicepack installiert wurde, dann ist die in allen Masterdokumenten die dieses Filialdokument einbinden, auch aktuell.

Die Masterdokumente haben keine Kopie sondern binden nur die Filialdokumente ein. Somit bleiben die Dokumente an sich überschaubar und klein: Office sperrt Dokumente per Menü oder wenn das Filialdokument eigenständig geöffnet wird beim Einsatz über einen Dateiserver. Mehrere Personen können parallel in ihren Dokumenten arbeiten. Allerdings bietet ein Dateiserver keine einfache Möglichkeit einer Versionierung.

Insofern ist allein mit Word, Filialdokumente und einem Dateiserver schon eine sehr effektive Dokumentation mit mehreren Personen möglich, wenn man sich eine passende Struktur von Dokumenten aufbaut, die üblicherweise aber alle im gleichen Verzeichnis abgelegt werden. Da Word die Überschrift als Dateinamen heranzieht und die umbenennung mühsam ist, sollten sie jedes Filialdokument mit einer eindeutigen aussagekräftigen Überschrift beginnen lassen. Alternativ kann man eine Vorlagendatei kopieren und als neues Dokument einhängen.

Die Aufteilung in einzelne Dokumente ohne weitere Struktur und Formatierung erlaubt sogar die automatische Erstellung. Wer mag könnte also pro Server eine "servername.doc" Datei z.B. per VBScript erstellen lassen und in der Dokumentation einfach einbinden. Sogar Querverweise funktionieren über Dokumente hinweg.

So eine Struktur ist natürlich erforderlich, wenn Sie eben ein statisches System aus Dateien oder eine Webseite mit einem CMS betreiben.

Hilfsmittel Notepad

Das einfachste Hilfsmittel zur Dokumentation ist ein einfacher Texteditor. Zugegeben kann man hier meist keine Bilder einfügen oder Formatieren, aber solche ein Editor findet sich auf wirklich jedem System und ist daher immer "zu Hand". Sie müssen sich natürlich ein Schema zur Benennung und Ablage der Dateien überlegen und die Volltextsuche im Windows Explorer kann bei dem Wiederauffinden schon helfen. Allerdings krankt so ein System, dass es eben "Freitext" ist, d.h. der Admin wird nicht gezwungen, bestimmte Daten auszufüllen (z.B. Datum, Version, Produkt, Server etc)

Dennoch ist gerade "Notepad" ein einfaches und effektives Hilfsmittel verschiedene Änderungen erst mal zu protokollieren. In eine "große Dokumentation" kann man die Infos ja dann am Arbeitsplatz mit einem anderen Produkt immer noch einfließen lassen. Zwei Funktionen von Notepad können die wenigsten Administratoren.

  • "F5" addiert einen Zeitstempel
    Wenn Sie in Notepad beim Schreiben einfach die "F5"-Taste drücken, dann wird an der aktuellen Position ein Zeitstempel eingefügt. Wussten Sie das ?
  • ".LOG" am Anfang aktiviert Protokollmode
    Schreiben Sie an eine Textdatei in die erste Zeile einfach ".LOG" und speichern diese Datei wieder. jedes Mal, wenn Sie diese Datei nun mit Notepad öffnen, springt Notepad selbst an das Ende der Datei, startet eine neue Zeile mit einem Zeitstempel und erwartet dahinter nun ihre eingaben.

Ich weiß nicht, seit wann es die Funktion schon gibt, aber anscheinend hat da früher jemand schon damit gearbeitet. Selbst in einem Notepad von Windows 98 konnte ich die Funktion finden.

Ein Plädoyer für ein Server-Blog

Ich komme als Consultant mit vielen Firmen in Kontakt und sehe deren "Dokumentation". für mich ist "dokumentieren" normal und gehört immer zu einem Projekt und sogar zu einem Vorgespräch, auch wenn mit kein Gesetz dazu anhält, wie dies bei Bankberatungen z.B. der Fall ist.

Seit einigen Jahren "bloggt" die Welt über alles mögliche. Ein gutes Beispiel für eine technische Nutzung ist das Exchange Team Blog mit dem Titel "You Had Me At EHLO.. Unter der Adresse http://msexchangeteam.com/. Das Exchange Team war eine der ersten Produktgruppen, die dieses Medium schon früh genutzt haben, um die Kommunikation zu fördern. Ein Blog hat nämlich für die Autoren als auch die Nutzer viele nette Vorteile:

  • Einfach und schnell
    Wer etwas dokumentieren möchte und das bisher mit Word macht, kennt die Situation der "leeren Seite" und dass man erst mal anfangen muss und am Ende eine DOC-Datei irgendwo hinschreibt. Auch stören die Funktionen zur Formatierung, Inhaltverzeichnis, Seitennummern, Kopfzeilen etc. bei einer Betriebsdokumentation eher als sie nützen.
  • Automatismus
    Wenn das Blog gut eingerichtet ist, dann werden der Autor anhand des angemeldeten Benutzers und auch das Datum alleine korrekt gepflegt und können daher nicht mehr "falsch" gemacht werden.
  • Zugriff von überall
    Da Blogs ja per Browser gelesen und sogar Einträge erstellt und gepflegt werden können, ist sogar eine direkte Bearbeitung auf dem Ort Aktion möglich. Fast so flexibel wie Notepad. per Browser ist es dann zwar schwer ein "Bild" (z.B. Screencapture) einzubetten, aber dies ist bei einer Serverdokumentation weniger der Fall. Die Zielgruppe sind ja Administratoren mit entsprechenden Kenntnissen. Zudem sind Einstellungen in Textform auch per "Suche" einfacher zu finden, als wenn jemand einfach nur ein Bildschirmfoto als "Doku" abgibt.
  • Gruppieren und Schlagworte
    Verschiedene Teams können sich eigene Blogs einrichten und selbst innerhalb eines Blogs kann man Bereiche einrichten oder besonders über die "Tags" verschiedene Artikel zusammen fassen. Wer z.B. die Servername (Server1..n) , Produktnamen (Windows, Exchange, SQL...) und Komponenten (z.B. DNS, WINS, NTP, Routing, Intranet, Mail, AD,..) als Schlagworte verwendet, kann sehr schnell die passenden Artikel finden.
  • Suchen und Finden
    Und was man nicht per Tag findet, sucht man eben als Volltextsuche.
  • Recycling und Feeds
    Und das wichtigste zum Schluss: Jede Blog-Software erlaubt den Zugriff auf Artikel und Änderungen über einen RSS-Feed. Über den Weg können "interessierte" Mitarbeiter sich quasi ohne ihr Zutun informieren. Wenn z.B. das Windows-Team einfach das Blog der "Netzwerker" anzapft, dann weiß man schnell, was die anderen machen und kann Feedback geben oder sogar verbundene Probleme besser erkennen.
    Und natürlich kann man solche "neuen Artikel" auch im Intranet und anderen Portalen einfach integrieren-

Sie sehen also, es gibt ganz viele Argumente für ein Blog, selbst wenn Sie schon ein anderes Dokumentationssystem haben. Natürlich macht das ganze nur Sinn, wenn es auch "Consumer" gibt, also Personen die die erstellten Artikel lesen. für sich alleine können Sie auch mit einer Sammlung von Notepad-Dateien weiter machen, wenn sie denn überhaupt dokumentieren.

Ich kann Sie aber nur auffordern, zu dokumentieren. Es muss kein Buch sein, aber wir vergessen alle sehr schnell.

Welches "Blog" sie einsetzen, ist ihre Entscheidung. Ich kenne Firmen, die sogar "extern" (also bei Wordpress oder Windows Live) mit dem Blog gestartet sind und die Daten dann später erst nach intern gezogen haben, um sich am Anfang den Server und die Installation zu sparen. Mittelfristig werden Sie aber ein Blog lieber intern laufen lassen. Das kann Wortpress sein (Auch Microsoft stellt Windows Live Spaces wird auf Wordpress um). Aber auch die Windows Sharepoint Services haben entsprechende Funktionen. Interessant ist z.B., wenn der Anwender sich nicht getrennt anmelden muss, d.h. das Blog auf die Daten des Active Directory zurückgreift.

Plädoyer für Wiki

Nun sind sie vielleicht alle von einem Blog infiziert. Aber ehe Sie nun los eilen, sollten Sie noch eine Alternative oder Ergänzung betrachten.

  • Keine Versionierung
    Artikel einer Dokumentation werden überarbeitet. für einen "Tagebucheintrag" oder eine Protokoll ist das seltener der Fall aber wenn Sie ein Blog auch als Bestandsdokumentation führen wollen, dann werden Sie bald an die Grenzen stoßen. ein Wiki enthält quasi per Definition eine Versionierung
  • Verlinkungen
    Eine Dokumentation lebt von Verknüpfungen. Ein System sollte diese einfach bereitstellen. In einem Wiki gibt es quasi nur "Keywords", die direkt zu einer bestehenden Seite führt. Gibt es die nicht, dann kann sie gleich erstellt werden. Bei anderen Systemen muss sich der Anwender mühsam URLs eingeben
  • Kaum Struktur
    Selbst wenn man möchte, kann eine Struktur nur schwer aufgebaut werden. Sicher gibt es die "Tag-Cloud" und einen zeitlichen Ablauf aber würden Sie einen eigenen "Index"-Blogeintrag immer wieder aktualisieren ?

Viele Dinge kann ein Wiki hier sehr viel besser. Denken Sie mal drüber nach. Es muss ja kein "öffentliches Wiki" sein. für einen Firmeneinsatz können Sie durchaus einige Einschränkungen vornehmen (z.B. bestimmte Browser unterstützen). Mit Sharepoint könnte sogar ein "Rich-Client wie der Sharepoint Designer zum Einsatz kommen

Auf der anderen Seite sollte ein unternehmens-Wiki auf jeden Fall die Identitätsverwaltung aus dem vorhandenen Verzeichnis und Anmeldedienst (z.B. Active Directory) beziehen und ein Single-SignOn unterstützen. Wenn eh schon alles "intern" ist, dann könnte jeder Abschnitt auch einen "Owner" haben, der bei Änderungen anderer Benutzer eine Nachricht erhält.

Es ist so viel denkbar, was ein Wiki auf jeden Fall zur besseren Plattform als statische Dateien einer Textverarbeitung macht. Allerdings bleibt es eine Webseite die auf einem Server an einem Ort abgelegt ist. Die wenigsten Wiki-Systeme erlauben eine Replikation oder einen Offline-Betrieb, was für eine IT-Dokumentation mit Desasterhandbuch nicht hilfreich ist. Ein Export als PDF oder ein statische Kopie (z.B. mit HTTrack) kann eine Option darstellen.

Tools zur automatischen Dokumentation

Es gibt zwar keine Tools, die Konzepte und Zusammenhänge automatisch erfassen aber reine System und Konfigurationsdaten können über verschiedene Hilfsprogramme sehr wohl erfasst und damit dokumentiert werden. Hier ein paar Links zu Tools.

Auch kommerzielle Werkzeuge helfen bei der Analyse und Dokumentation von Netzwerken Da ist in erste Reihe natürlich das GSTOOL vom BSI zu nennen. Zudem gibt es noch einige weitere kommerzielle Werkzeuge verschiedener Anbieter:

Es ist ja klar dass so eine Aufnahme nicht immer nur manuell erfolgen kann, so dass sich Systemhäuser natürlich selbst ihre Werkzeuge erstellen.

Es gibt als eine ganze Menge Werkzeuge, die auch Daten automatisch in eine solche Dokumentation einbauen können. Bedenken Sie aber, dass bestimmte Informationen auch besser in einem klassischen Inventarsystem (Softwareverteilung etc.) aufgehoben sind.

Viele Programme bringen "Assistenten" mit, die am Ende sogar eine "Zusammenfassung" ihrer Aktionen auf dem Bildschirm ausgeben. Leider gibt es innerhallb der Windows Plattform zwar APIs für alles mögliche aber eben keinen "Dokumentstore". Wäre es nicht genial, wenn diese Assistenten ihre Arbeit quasi "Auto-Doumentieren" könnten ?. So bleibt ihnen nur die manuelle Übertragung der Ausgaben in eine Dokumentation

Weitere Links