Service Desk, das richtige Maß an Dokumentation

Das richtige Maß an Dokumentation in der IT zu finden, ist anscheinend ein Dilemma. Der Programmierkurs and der Universität kann den Markstein setzen. Dokumentation ist wichtig und wird bei der Lösung mit-bewertet. Das muss an Erklärung reichen, die Vorgabe ist jede Codezeile muss einen Kommentar haben. In der Masse der Korrekturen wird

a := b + 1 // Hier wird der Variablen a der Wert der Variablen b erhöht um eins zugewiesen

zu einem korrekten Kommentar und dem Beginn eines Missverständnisses.

Bei einem Service Desk geht es nicht um kommentierte Codezeilen, sondern um Policies, Prozesse, Prozeduren und Work Instructions. Zumindest wenn man der ITIL®-Nomenklatur folgen mag. Egal wie das Zeug heißt: Richtlinien, Betriebsvereinbarungen, Abläufe, Verfahrensanweisungen, Arbeitsanweisungen, How-To, ganz egal. Es geht zuerst mal um verschiedenen (Abstraktions-)Ebenen der Dokumentation.

• Prozessdokumentation: Beschreibt eine übergreifende Struktur, im Service Desk ist dies zum Beispiel der Incident Prozess. Es könnte davon auch mehrere geben zum Beispiel Incident Prozess für IT und Produktion.
• Prozedur: Eine Schritt-für-Schritt-Übersicht, dies könnten zum Beispiel Bestell-Prozeduren aus dem Bereich Request-Fulfillment sein. Eine Bestell-Prozedur für einen neuen Standard-Server im Rechenzentrum sieht da meist anders aus als eine Bestell-Prozedur für ein Standard-Notebook.
• Workinstruction: Eine sehr-detaillierte schriftliche Anleitung, dies kann eine Verfeinerung einer Prozedur sein die einen Ausnahmefall regelt aber auch einen Standard Change in dem das Service Desk team eine Administrative Tätigkeit korrekt und richtig durchführen soll.

Bei der Übernahme eines Service Desk Betriebs im Outtasking kommt es selten vor, dass die Dokumentation große Bereiche des Arbeitsumfeld sicher abdeckt und auf aktuellem Stand ist. Dabei sind die Defekte durchaus verschiedenartig ausgeprägt:

• Gar nichts: Typisch bei gewachsenen In-House-Service-Desks kommt es in Extremfällen vor, das wirklich gar nichts dokumentiert ist. Ein Wenig an Dokumentation findet sich nur bei neuen Mitarbeitern auf dem Papierblock, der zur Einarbeitung diente. Es ist kaum vorstellbar, dass dieses Team so wie es ist fehlerfrei arbeiten kann. Spricht man die Verantwortlichen darauf an, werden diese mit Stolz die Fehlerfreiheit attestieren. Ein Blick in das ITSM-Tool wird jedoch einiges an Beschwerden bzw. Nachbesserungen zu Tage fördern a la „Ich komme in das XYZ-System immer noch nicht rein, brauche mehr Rechte“. Ein solches Umfeld war geprägt durch einen freundlichen Umgang und kann sich als Minenfeld für den neuen Provider herausstellen. Denn selbst wenn die Fehleranzahl gleich hoch ist, nun fallen diese auf. Solche Fehler aufzuarbeiten bedeutet „haben wir immer so gemacht“ in Struktur zu bringen. Das kann spannend werden.
• Oben Topp unten Flop: Gerade nach nicht ganz gelungenen „ITIL-Einführungen“ liegen die Prozesse als Schaubilder vor und hie und da finden sich Prozeduren wie „Neuer Mitarbeiter“ oder „Passwort Reset“. Immerhin weiß der Service Desk was er so grob abzudecken hat, es gibt aber auch Kardinalfälle in denen die Prozessdokumentation derart grob oder gar unpassend ist, dass selbst das Aufgabengebiet nicht erkennbar ist.
• Einmal und nie wieder: Oft gesehen bei IT-Organisationen, die viel über Berater oder Dritte einführen. Fast alles ist dokumentiert, jedoch ist die Dokumentation veraltet und an einigen Stellen stehen Hinweise, das dieses und jenes Kapitel nach Einführung vervollständigt werden muss, was selbstverständlich nicht geschehen ist. Eine solche Dokumentation kann meist sehr gut wieder auf Stand gebracht werden. Probleme entstehen meist durch Mangel an Wissen über die Organisation, Kooperationen über verschiedene Abteilungen oder ähnlich. Auch wird hie und da mal ein allgemeines Handbuch eines Herstellers durch die Abnahme gemogelt worden sein.
• Schubweise: Bei von Governance oder externen Audits getriebenen Organisationen kommt es vor, dass die Dokumentation alle zwei Jahre aufgearbeitet wird. Hört sich erst Mal gar nicht so schlecht an, jedoch Menge und Abstraktionsniveau passen da meist nicht. Die Auditoren bemängeln Dokumentation aus Sicht von Richtlinien oder Controls, das heißt es wurde nur ein bestimmter Teil der Arbeit überhaupt erfasst. Auch sind diese Dokumente oft sehr sperrig, um nicht zu sagen bürokratisch, zu lesen. Sie werden in der Praxis oft ignoriert, sind jedoch ein guter Ausgangspunkt um daraus Kurzanleitungen zu produzieren. Bei der Aufarbeitung ist wichtig, dass nicht ausgehend von der bestehenden Dokumentation gearbeitet wird. Es ist häufig sehr erstaunlich welche elementaren Bereiche des tagtäglichen Betriebs in solchen Organisationen vergessen werden.
• Skizzenhaft: Entweder durch den Leidensdruck zu vieler Prozeduren und Verfahren oder durch ein gutes Bewusstsein von professionellen Service Desk Agenten getrieben, findet sich manche Dokumentation als große Sammlung von Stichpunktlisten. Das heißt, Mitarbeiter die sich tagtäglich mit diesen Punkten beschäftigen haben sich eine Gedankenstütze geschaffen. Diese Aufzeichnungen werden als Leitfaden sozusagen als „Request Modell“ und zu Trainingszwecken genutzt. Allerdings fällt auf, dass oft Anfang und Ende fehlen bzw. für Profis offensichtliche Schritte weggelassen wurden. Eine solche Dokumentation – falls einigermaßen umfangreich – ist ein guter Ausgangspunkt. Denn die dort enthaltenen Prozeduren können mit der IT Leitung abgeglichen werden, während das Team die bestehenden Skizzen dokumentiert. Das ist sehr schön parallelisierbar.

Obige Grundhaltungen bedeuten unterschiedliche Aufwände bei der Nachdokumentation. Auch der nachhaltige Erfolg einer gemeinsamen Dokumentation, die von allen Parteien vorangetrieben wird, hängt von diesen Grundhaltungen ab.
Das Management wird dieses gerne per Handstreich aus der Welt schaffen wollen: „Dokumentation ist einfach, es muss getan werden, los anfangen!“.

Dokumentation muss getan werden, ganz klar, kein Widerspruch. Einfach ist das ändern einer (Un-)Kultur jedoch nicht. Wenn ein Team 20 Jahre gelernt hat „Dokumentation ist Bürokratie und lästige Pflicht“ bedarf es eines knackigen und guten Ansatzes um die Jungs und Mädels langsam aufzutauen. Darum soll es in den nächsten Artikeln gehen. Ich hoffe ihr bleibt dabei 🙂

• 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/