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 ?.

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 Lösung muss daher eine ganz anderen Ansatz wählen. eine Dokumentation einer Firma muss vom Prinzip her viele Faktoren erfüllen, die eine normale "Textverarbeitung" nicht leisten kann:

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
    Dine DOC-Datei ist sicher nicht geeignet. Aber vielleicht ist ein "WIKI" (Wiki) als Ansatz. Denkbar ist aber auch Sharepoint
    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 aber keine feste "Struktur" sondern nur Schlüsselworte und Links. Wenn wir alle ehrlich sind, dann suchen wir schneller in Google als in einem Inhaltsverzeichnis eines großen Buchs
  2. 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
  3. 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.
  4. 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.

Wie geht es weiter ?

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.

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.

Weitere Links

Keywords: Dokumentation