Service Desk – Wer ist zu motivieren?

In einem gewöhnlichen IT Betrieb, der sich nie sonderlich auf Dokumentation konzentriert hat, sind die Dinge genau so entstanden wie sie nützlich waren. Es wird in allen Teams unterschiedlich dokumentiert. Meist zu wenig, selten komisch, aber nie gar nichts.

Der Junior-Administrator hat auf jeden Fall auf die Finger bekommen, nachdem er einen Server gepatched hat und keinen Eintrag im changelog.txt gemacht hat. Sein älterer Kollege hat bei der Fehlersuche den Patch gar nicht im Blick gehabt und erst woanders gesucht. Nun bekommt der Junior Admin einen Anschiss und das Administratoren-Handbuch auf den Tisch geknallt. Das Administratoren-Handbuch ist eine E-Mail aus dem Jahr 2003. Entschuldigung nicht 2003, es wurde 2012 ergänzt und mit größerem Verteiler versehen.

Was ich sagen will, egal wie schlecht es um Dokumentation steht, es gibt einen Anfang, gefühlte Verantwortlichkeiten sowie hie und da Mitarbeiter die sich schon gekümmert haben. Aber lasst uns mit den Verantwortlichen beginnen.

Control heißt Steuern

Im ersten Teil dieser Serie bin ich kurz auf die Dokumenthierarchie eingegangen, wie sie im Service Delivery Management benannt bzw. aus der Governance heraus definiert wird. Hieraus ergeben sich die Verantwortlichkeiten für einzelne Dokumentklassen. Das funktioniert auch ganz prima, eine entsprechende RACI-Matrix ist schnell gebaut.

In der Praxis finden sich hier zwei Extreme: Die Verantwortung wird entweder so hoch wie möglich geschoben oder fällt flach auf die unterste Ebene. Das heißt das rechenschaftspflichtige „Accountable“ bekommen Personen, deren alltägliche Praxis weit weg von dem eigentlichen Geschehen ist. Selbst wenn das richtige Team durchführungsverantwortlich „Responsible“ ist, findet keine wertsteigernde Überwachung statt. Oder eben im anderen extrem bekommen Mitarbeiter ein „Accountable“ zugewiesen, die eine solche Verantwortung gar nicht übernehmen (können).

Ein sinnvolles Steuerungssystem muss alle Akteure einbinden und die Steuerung auf zwei unterschiedliche direkt involvierte Parteien aufteilen. Am Besten wechselseitig, damit kooperativ gearbeitet und nicht nur einseitig Kritik geübt wird. Beispiel:

• Das Fachteam prüft und lektoriert bestimmte Workinstructions des Service Desks
• Der Service Desk prüft und lektoriert die Workinstructions eines Fachteams

Es mag eingewandt werden, dass in obigem Beispiel der Service Desk eventuell gar nicht die Fachlichkeit hat, die Arbeitsanweisung des Fachteams bis in die letzte Schraube zu prüfen. Bei einem Lektorat geht es gar nicht darum dem Fachmann auf gleicher Höhe zu begegnen. Vermutlich kann ein langjähriger Service Desk Mitarbeiter sehr gut fachlich prüfen. Wichtig sind Vollständigkeit, Richtigkeit, einheitliche Ebene und andere Dokumenteigenschaften, aber vor allem auch die Gesamtheit der Dokumente zu einem Bereich.

Für die Leitung des Service Managements ist übrigens die qualitative Steuerung dieser Kooperation und die quantitative Steuerung der Resultate ein „A/R“ in der RACI-Matrix sinnvoll. Das gilt übrigens insbesondere in einer Organisation auf niedrigem Reifegrad. Wenn Teams dazu neigen sich zu beschimpfen, sind hierarchische Kontrollsysteme kontraproduktiv.

Shift to the Left

Oft auftretende Fälle sollen im Support möglichst von der Einheit gelöst werden die dem Endanwender am Nächsten ist, wenn nicht gar via Portal und Automatismus von dem Endanwender selbst. Ein sehr gesundes Verhältnis ist, wenn jede Support-Einheit 70% der Vorfälle, von all dem was rein kommt, lösen kann.

Nehmen wir 4.000 aufgenommene Tickets im Monat, so sollte der Service Desk davon 2.800 davon lösen und somit 1.200 an 2^nd-Line-Einheiten weitergeben, 2^nd-Line sollte 360 Tickets an 3^rd-Linie weitergeben. Dieser Daumenwert passt eigentlich sehr gut. Wenn dem nicht so ist, liegt es meist an fehlendem „Shift to the Left“ und nur sehr selten an speziellen Konstellationen, wie z.B. hohem Automatisierungsgrad oder vielen Business Transaktionen am IT Service Desk.

Eine funktionierende Abgabe von Wissen an eine niedrigere Support Einheit ist ein Geben und Nehmen. Diese Zusammenarbeit muss etabliert werden und ist gerade am Anfang von Projektleitung und Management zu hegen und zu pflegen. Fangen wir mal mit dem Nehmen an. Ein guter Service Desk fordert regelmäßig Wissen an.

• Nur häufige Fälle lohnen sich weit vorne abgearbeitet zu werden. Komplexität ist hierbei nicht relevant
• Störungen mit schweren Auswirkungen werden oftmals nicht rechtzeitig erkannt, hier fehlen ggf. Analyseregeln oder -mittel
• Tickets mit häufigen Nachfragen der Endanwender sind Kandidaten die weit vorne gelöst werden sollten
• Tickets, die zwischen den Support Einheiten hin- und hergeschoben werden, sollen bessere Templates und Vorgaben bekommen

Werden diese Fälle von den Fachteams oder beim Service Management gefordert

• Muss das Fachteam eine grobe aber vollständige Anleitung entwerfen ggf. komplexe Abläufe verschlanken oder automatisieren. Zusammen mit dem Service Desk wird diese dann vervollständigt, getestet und beidseitig genehmigt.
• Falls möglich kann das Fachteam dem Service Desk Analysemittel oder Skripte zur Verfügung stellen. So ein Skript muss nicht vollständig sein, sondern kann auch geregelte Kommunikation sein „Prüfe A, B, C und dann ruf uns an“.
• Häufige Nachfragen von Anwendern kosten der IT und dem Unternehmen bares Geld. Oft müssen problematische Konstellationen wie langatmige Workflows oder sinnlos hoch angesiedelte Genehmiger angegangen werden.
• Ping-Pong-Tickets fehlt es oft an Information, zusammen mit allen Fachteams sollte ein Konzept von Incident-Templates erarbeitet werden. So können dem Endanwender zu der Störung (einer Kategorie) 2-5 Fragen gestellt werden, die den Fall systematisch eingrenzen. Fehlt eine zusätzliche Information muss sich ein Fachteam verantwortlich kümmern und nicht einfach so weiterleiten.

Selbstverständlich können auch Fachteams Wissen aktiv nach Links schieben. Wichtig ist immer gegenseitig die Rolle und Leistungsfähigkeit zu verstehen. Service Desk Agenten sind keine Administratoren und Administratoren sind keine Ausputzer für einen überlasteten Service Desk. Genauso wie der Service Desk die Operations vor Banalitäten schützt und die Operations diesen Schutzschirm ausbauen hilft.

Abholen, Bitten, Charisma, Druck

Nun kommen wir zu einem Teil, der nur schwer in einem Blog-Artikel erklärt werden kann: Wie sind Individuen zu fördern, zu nutzen oder simpel in den Hintern zu treten? Wichtige Erkenntnis: die Motivation der Mannschaft ist aktive Arbeit.  Ein aufklärendes PowerPoint, eine strenge Mail und Delegation an Teamleiter haben noch nie geholfen.

Haben alle verstanden worum es geht? Was ist an dem jetzigen Zustand nicht optimal? War die Zusammenarbeit in der Vergangenheit falsch? Warum reicht das was die Teams heute liefern nicht aus? Ist das neue System eine Art Bürokratie für die ISO 9001?

Selbstläufer sind diese Projekte nie. Es geht darum Teamgrenzen zu überbrücken, Menschen eine bestimmte Art von Kommunikation beizubringen und auch bisheriges Handeln in Frage zu stellen. Ein solches Projekt benötigt hochrangige Aufmerksamkeit und Projektarbeiter die etwas davon verstehen.

• Es wird Mitarbeiter geben, die nicht gern ihr Wissen teilen, z.B. weil sie um Verlust von Anerkennung bzw. Job fürchten. Aber auch hier finden sich Beispiele aus der Vergangenheit in denen lästige Aufgaben abgegeben wurden. Vielleicht ist das ein Anküpfungspunkt für einen positiven Aspekt.
• Es wird Mitarbeiter geben, die in der Vergangenheit länglich und ausführlich zu Störungen Stellung genommen haben, sei es in der Kaffeeküche oder im Ticket-Tool. Hier könnte sich ein Tandem anbieten, ein Service Desk Mitarbeiter versucht im Dialog daraus mehrere Wissensartikel zu produzieren, der technische Mitarbeiter Anleitungen für sein Team oder gar Automatisierungsskripte.
• Es gibt Mitarbeiter, die tun genau das was man ihnen sagt und das gar nicht mal schlecht. Damit das Thema Dokumentation nicht von Teammitgliedern verdrängt wird, vereinbart man z.B. eine bestimmte Zeit oder eine bestimmte Quote an (überarbeiteten) Artikeln pro Woche.
• Nörgler und „Früher war alles Besser“ kann man eventuell mit einem Bewertungssystem begegnen, dass frühzeitig Entstörungen mit Fakten belegt oder gar die Qualität der Wissensartikel bewertet.

Auf jeden Fall braucht so ein Projekt eine Ist-Analyse, wie die Teams, ihre Mitarbeiter und ihre Führungskräfte ticken. Intelligente Führungskräfte, die nichts von dem Projekt halten, werden das Projekt um Monate aufhalten. Hier hilft Überzeugungsarbeit, Messen und Vergleichen. Wenn all dies nicht hilft, muss ein Projektleiter mindestens dieses Team anleiten.

Vergiftende Ideen

Gerade um schnell vorzeigbare Verbesserungen zu erzielen hilft es erfahrene Berater mit ins Boot zu holen, die wie eine technische Redaktion nach 80:20-Methode technische Artikel aus den Teams abluchsen und diese schnell auf professionellen Stand bringen. Die Idee einer Fachredaktion führt jedoch dazu, dass die technischen Fachteams sich in der Rolle als Zuträger von Information wohlfühlen und alle Aktivitäten rund um die Erstellung von Wissensartikeln gar nicht im Detail kennenlernen möchten.

Die hohe Geschwindigkeit der externen Fachredaktion wird ihr übriges dazu beitragen, dass die Fachteams allerlei Gründe finden für schnödes Wissensmanagment keine Zeit zu haben.

Gegenmaßnahme ist, dass die Berater ihr Wissen frühzeitig weitergeben und die Fachteams ausbilden. Es muss sichergestellt sein:

1. Das die Fachteams die Arbeitsweise lernen
2. Selbstständig üben
3. Durch Korrektur der Fachredaktion im Prozess und Ergebnis vollständig und in der gewünschten Qualität liefern
4. Den Prozess und die Anforderungen selber an weitere Kollegen weitergeben

Insbesondere der letzte Schritt ist wichtig, um die Qualität langfristig zu erhalten. Die Berater können hierzu gegebenenfalls nach 3-4 Monaten wiederkommen.

Eine weitere Art von Gift ist Bereiche die Kooperation benötigen, hierarchisch lenken zu wollen. Erfahrene neu eingestellte Mitarbeiter im Service Desk, kennen sich bei der Wissenserstellung prima aus. Dies und ähnliche Gründe verleiten dazu, die Verantwortung zur Wissenerstellung dort einem Kernteam zu übertragen.

Typischerweise versiegt die Zulieferung von technisch höherrangigen Fachteams sehr schnell. Beziehungsweise diese liefern zu abstrakte, unmotivierte Informationen wie Hinweise auf Wissensdatenbanken von Herstellern. In Summe sind sie sind nicht verantwortlich für das erarbeiten von Wissen und haben ihre Pflicht getan.

Das Kernteam ist nun mit einer unlösbaren Aufgabe betraut. Während sich ein Fachmann auf das Niveau eines Agenten einstellen kann, da er selbst mal Anfänger war, ist es andersherum nahezu unmöglich. Ein Agent muss sich erst einiges an Fachwissen aneignen um dann einen relativ simplen Fall zu dokumentieren. Das ist verschwendete Zeit und Dilettantismus.

So ein Konzept funktioniert nur, wenn beide Teams für die Kooperation verantwortlich sind . Beide müssen die selben Auf- und Abbauziele für Wissensartikel haben, beide müssen gemeinsam zu Readaktionssitzungen erscheinen. Je nach sozialer Ausgangslage empfehlen sich Management-Paten die Fachwissen mitbringen. In der IT Operations findet sich der ein oder andere kürzlich beförderte Abteilungsleiter mit einem soliden Fachwissen, der in Streitfragen vermitteln kann, insbesondere wenn darum gestritten wird welches Wissensniveau von jeder Partei verlangt wird.

Falls sich kein interner Vermittler findet, sollte auch hier ein externer Berater hinzugezogen werden. Dokumentation ist ein pragmatischer Prozess, der nicht mal eben so zum laufen kommt.

Knowledge Management ist kein Prozess

Recht häufig finde sich in dem Konvolut der IT Service Management Dokumentation auch ein Knowledge Management Prozess Diagramm. Wenn es gut gemacht ist, sogar gefolgt von Prozedur-Diagrammen, das sich um Detailabläufe kümmert. Der Knowledge Management Prozess ist dann meist so eine Art Anforderung-Lektorat-Freigabe-Ablauf. So etwas hat aber gar nichts mit Wissensmanagement zu tun. Knowledge Management ist kein Prozess.

Während das auslösende Ereignis bei Incident Management in 95% der Fälle eine Störung ist, fällt es bei Knowledge Management schon schwieriger was denn das Hauptereignis ist, das den Prozess startet. Es muss irgendwas mit fehlendem Wissen zu tun haben.

Gehen wir mal von der Annahme aus, dass eine IT Organisation funktioniert, egal wie viel Verbesserungspotential Knowledge Management heben kann. Dann gab es in der Vergangenheit keine (oder viel zu wenige) Anlässe sich um Wissensverbesserung zu kümmern.

Der erste Ansatz bei Knowledge Management ist diese Anlässe zu schaffen. Ohne diese Anlässe wird auch die beste Dokumentation nicht weiterentwickelt.

Bei einem sehr gut etablierten Knowledge Management werden, die wenigsten Anlässe zur Nachpflege reaktiv erfolgen. Diese gibt es: Wie etwa eine Überprüfung eines Artikels nach Ablauf seiner Gültigkeit oder ein Mitarbeiter stellt fest, dass ein Artikel nicht mehr korrekt den Ablauf beschreibt. Viel wichtiger ist es jedoch nach und nach eine Organisation zu schaffen, die Freude am lernen und kontinuierlicher Verbesserung hat.

Bei dem finden und festlegen von auslösenden Ereignissen für das Knowledge Management, sollte eher experimentiert als festgeschrieben werden. Ganz simpel: Auch die deutlichste Vermutungen in einem Bereich massiv Wissen steigern zu können, sollte eine Zeitlang ausprobiert und analysiert werden. Unterschätzte Gebiete durchaus auch mal in das System eingebunden werden. Nur bei Erfolg werden diese Auslöser nachhaltig verfolgt. Bei Interesse widme ich diesem Aspekt gerne mal einen eigenen Artikel.

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