Es ist schon ein erstaunliches Prinzip: Auf die Frage, was alles dokumentiert sein muss antworten IT Leiter oder Service Desk Chefs mit einheitlicher Stimme „Alles“. Wenn ein bestehender Service übernommen werden soll wird selten eine Quote von über 50% brauchbarer Dokumentation angetroffen. Vermutlich liegt genau hier der Hund begraben, ohne vernünftiges Konzept „Alles“ zu fordern ergibt „Wenig“.
Auf der anderen Seite ist es schon erstaunlich mit wie wenig so ein Service Desk in der Vergangenheit auskommen konnte. Bei näherer Betrachtung fällt jedoch schnell auf, dem ist gar nicht so. Undokumentierte Service Desks sind schlecht in außergewöhnlichen Situationen. Zum Beispiel ein Produktionserver, der 3 Jahre prima lief, fällt eines Nachts aus. Dessen Dienstleister wurde drei Jahre lang nicht gerufen, um eine Störung zu beheben. Falls der Server überhaupt irgendwo aufgelistet ist, spätestens die Telefonnummer des Dienstleisters stimmt nicht mehr.
Das Märchen vom effizienten unaufgeräumten Schreibtisch
Der undokumentierte Service Desk telefoniert sich nun durch die Organisation und hat nach etlichen Minuten bis Stunden den Dienstleister in Marsch gesetzt. Der gut dokumentierte Desk hat, a) den Server gelistet, b) die Kontaktregeln vorliegen und c) jedes Quartal die Telefonnummern gepflegt. Der Dienstleister ist nach wenigen Minuten korrekt in Marsch gesetzt und der Service Desk wird nach 2 Stunden beim Dienstleister nachhaken, da bekannt ist das es sich um einen 4 Stunden Vertrag handelt. Der undokumentierte Desk macht schon nach einer Stunde Druck, da überhaupt nichts über den Wartungsvertrag bekannt ist, machen die Jungs immer Druck.
Die Ergebnisse dieses Einsatzes werden dicht beieinander liegen: Der dokumentierte Desk wird einige Minuten besser als der undokumentierte sein, das fällt in keiner Statistik auf. Der undokumentierte Desk hat mehr Mitarbeiter unnötig geweckt und sich mal wieder mit einem Dienstleister angelegt. Da liegt im Tagesgeschäft der Hauptunterschied.
Es ist jedoch nicht immer so, dass der Undokumentierte Desk gar nicht so schlimm dasteht. Im Fall von Major Incidents, bei denen verschiedene betroffene Systeme koordiniert in Stand gesetzt werden müssen, kann das auch mal sehr unterschiedlich im Ergebnis sein und ein undokumentierter Desk wirklich blöd ausschauen.
Raus aus der Falle
In einer Umgebung, die mit Dokumentation bis dato nicht umgehen konnte, benötigt man eine Strategie. Ich beantworte die Frage was dokumentiert werden muss, mit Minimal-Notwendig-Schichten: Welche Dokumentation benötigt der Service Desk um (Nachts) zu überleben ohne jemanden zwecks Auskunft anzurufen? Welche Dokumentation benötigt der Desk um große Störungen fachgerecht abzuwickeln? Welche Dokumentation, um die wichtigsten Geschäftsprozesse zu unterstützen? Und so weiter… Es ist zwingend darauf zu achten, dass diese Diskussionen auf das Minimum ausgerichtet sind. Sobald jemand ein Dokument einbringt, das der Service Desk Nachts eventuell noch gebrauchen könnte, ist das ganze Prinzip auf dem falschen Weg.
Abbildung: Ein etwas stark vereinfachtes Schichtenmodell
Deshalb sollte das Schichtenmodell mit Bedacht, eng an den geschäftlichen Gegebenheiten in kleiner Runde vorbereitet werden. Ein Dokument, was man im Notfall gebrauchen könnte, aber nicht zum Minimal notwendigen gehört, kann vom Moderator einer solchen Runde dann leicht in eine höhere Schicht aufgenommen werden. Eben genau die Schicht in der es dann zum Notwendigen gehört. Übrigens müssen die Schichten nicht unbedingt trennscharf sein, ein Notfall kann auch in der Nacht auftreten. Ist „Notfall“ und „Nachtüberlauf“ eine Schicht oder zwei Schichten? Kein Problem, denn eine Rolle wird für diese beiden kritischen Schichten zuständig sein. Im Zweifel trennen und zwei Schichten daraus definieren, das dient dem Verständnis.
Nachdem ein Schichten- oder Zwiebeldiagramm erstellt wurde und mit Dokumenten(klassen) gefüllt wurde, kann dies zum aufräumen, aktualisieren und auch zur Steuerung (Audits) genutzt werden. Auch lassen sich so gut Rollen aus dem Service Desk zuordnen, je zentraler in der Zwiebel, desto zentraler der Mitarbeiter. Auch sollten die inneren Kreise nur einen verantwortlichen Rolle (einer Person) unterliegen. Im Außenbereich der Zwiebel sind mehrere Teams angesiedelt, wenn hier ein Team noch nicht ganz so gut arbeitet ist das nicht schön, aber erzeugt keinen großen Schaden.
Bei der Zuordnung von Personen bzw. Rollen sollte das aus RACI bekannte Prinzip genutzt werden. In jeder Schicht sind R, A, C und I zu vergeben – verantwortlich (responsible), rechenschaftspflichtig (accountable), fachverantwortlich (consulted) und zu informieren (informed). Der Kreis der aufgeführten Personen sollte klein gehalten werden und nicht weit über den SErvice Desk ausgedehnt werden. Beispiel: Wenn ein Service Desk Mitarbeiter ein gefordertes Update trotz mehrerer Nachfragen aus der Fachabteilung nicht erhält, dann ist das ein gutes Thema für das nächste Service Manager Meeting. In den meisten Organisationen ist so ein Prinzip besser, als alle Einzelfälle in die Breite zu eskalieren.
Push und Pull
Nachdem nun eine Rangfolge von wichtig und unwichtig gefunden wurde, muss noch zwischen leicht und schwer zu pflegen unterscheiden werden. Informationen die reaktiv bzw. aktiv an den Service Desk herangetragen werden sind entscheidend, um erstere braucht man sich nicht kümmern. Die neue Telefonnummer eines Field Supporters, der täglich in Koordination mit dem Service Desk arbeitet, ist nach wenigen Stunden im System hinterlegt, da in dieser Zeit schon x-Kollegen gefragt haben (reaktiv).
Generell tendieren Störungsintensive operative Services oder Prozeduren dazu aktuell dokumentiert zu sein, Störungsarme Systeme oder höhere Managementebenen sind schlechter dokumentiert. Reaktives Dokumentmanagement kann demnach aus großen Störungen Katastrophen erzeugen. Also bitte etwas Budget in aktive Dokumentkontrolle stecken.
Für schwer zu pflegende Dokumente muss eine Prozedur eingeführt werden. Zum Beispiel eignen sich in Produktionsbetreiben regelmäßige Begehungen, um zu sehen was sich verändert hat. Begehungen können in anderen Umgebungen auch virtuell sein, zum Beispiel einmal im Quartal mit der Operations alle virtuellen Server durchsehen oder mit dem Supplier/Provider Manager Verträge und Kontaktlisten durchsprechen. Das dient der Kommunikation und ist meist gut investierte Zeit.
Integration in die tägliche Arbeit
Die Dokumentation muss die Arbeit unterstützen, das heißt zum einen muss diese von dem Personenkreis geschrieben sein, der diese Arbeiten auch durchführt. Ein Arbeitsanweisung sollte vom Fachteam skizziert, vom Service Desk vervollständigt und final vom Fachteam abgenommen werden.
Leider klappt das selten auf Anhieb. Oftmals finde ich pseudo-bürokatischen Unsinn vor: 10-seitige Anweisungen deren eigentlicher Inhalt auch auf eine halbe Seite passen würde. Diese Fehljustierung über den Sinn von Dokumentation aufzulösen bedeutet eine Menge Überzeugungsarbeit. Der Schlüssel dazu ist die aktive Einbindung der Dokumentation in Training, Ausbildung und Übung. Ganz ähnlich wie bei Blended-Learning-Konzepten, der Agent liest die Dokumentation, versucht das Wissen anzuwenden und wird von einem Supervisor dabei unterstützt. Bleibt es bei dem „Schau mir über die Schulter“ Trainings-Konzept in dem eingearbeitete Kollegen jüngere Kollegen on-the-job ausbilden, bleibt es auch bei unnützer Dokumentation.
Die beiden Enden einsammeln
Ist das erstmals geschafft und wird die Kritik der jüngeren Kollegen in die Dokumentation eingepflegt, so wird eine gute arbeitsunterstützende Dokumentation dabei herauskommen. Aber es bleibt noch eine Lücke zu schließen. Dokumentation zu Störungen oder Änderungsanträgen die wenige Male pro Woche anfallen werden die optimal dokumentierten Anweisungen sein, je häufiger ein Vorfall zu lösen ist, desto dünner fällt die Dokumentation aus. Auf der anderen Seite der Skala sind Vorfälle, die zu Lösung an Spezialteams gegeben werden, auch diese werden nur Stichpunktartig ausgearbeitet sein.
Bei fehlender Dokumentation zu tagtäglicher Arbeit sollte nachgearbeitet werden, ein Anfänger muss ausschließlich mit der Dokumentation arbeiten können. Dies gilt vor allem auch für bebilderte Anleitungen wie Verwaltungstools die ständig in Benutzung sind (anmelden, umsetzten, abmelden). Hier komme auch ich nicht umhin zu sagen: Das muss gemacht werden. Punkt! Immerhin müssen Anfängerfehler nicht auf mangelnder Dokumentation beruhen. Zu Auditierung bzw. Nachpüfung dieser Ebene sollten Teammitglieder herangezogen werden. Einem hauptberuflichen Auditor geht hier zu viel durch die Lappen.
Bei fehlender Dokumentation auf Spezialteam bzw. Expertenebene rate ich zur Gelassenheit. Ein gut ausgebildeter Mitarbeiter im 2nd-line-Team benötigt keine langweilige Dokumentation mit Screen-Shots, dort kann eine Stichwortliste ausreichend sein. Allerdings sollte diese Kurzdarstellung vollständig sein und alle Schritte bzw. Ausnahmen enthalten. Die Korrektheit und Vollständigkeit auf dieser Ebene kann zum Beispiel durch ein Peer-Review sichergestellt werden.
Ich hoffe so oder ähnlich klappt es auch bei Euren Projekten, fehlt noch die Motivation der Leute nach dem Start auch dabei zu bleiben. Tipps dazu beim nächsten Mal.
- Einleitung „Das richtige Maß an Dokumentation“
- Was müssen Tools können?
- Was muss wie dokumentiert werden?
- Wer ist zu motivieren?
- Ein Satz von Vorlagen jenseits von Firmenlogos…
Blog abonnieren: https://wernerroth.de/index.php/feed/