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. „Service Desk – Wer ist zu motivieren?“ weiterlesen

Priorität ohne CMDB

Priorität errechnet sich aus Impact und Urgency, so steht es in jedem ITIL®-Buch und ist auch absolut prima. Dumm ist, wenn die IT losgelöst vom Geschäft arbeitet und den geschäftlichen Wert eines Ausfalls gar nicht einschätzen kann.

Ist der Ausfall eines Logistikstandortes mit 300 Mitarbeitern schneller zu lösen, als der gleichzeitige Ausfall eines Produktionsstandortes mit ähnlich vielen Beschäftigten?

Genauso können viele interne IT Organisationen die Auswirkung nicht sicher bestimmen. Wie viele Anwendungen nutzen die ausgefallene Datenbank und was bedeutet das in Summe für die Anwender? Ohne eine CMDB (bzw. CMS) ist da nichts zu holen.

Die Behelfslösung ist meist eine – wie auch immer geartete – inhaltliche Umschreibung der einzelnen Prioritätstufen. Unten-stehende Tabelle ist dazu gedacht diesen Wahnsinn etwas plakativer darzustellen. In der Praxis finden sich manchmal wahre Zeilen-Monster, die wie wir sehen werden Niemandem helfen, auch nicht bei Erhöhung von Detailtiefe .

Prio 1 Sehr kritische Störung von erheblichem Umfang, ohne Umgehungslösung, Produktionsgefährdend
Prio 2 Kritische Störung von großem Umfang, es existiert eine Umgehungslösung mit deutlichem Mehraufwand
Prio 3 Deutliche Störung, mindestens ein Mitarbeiter kann nicht mehr arbeiten.
Prio 4 Geringere Störung, Lösung kann einen Tag warten.
Prio 5 Unbegründete Störung oder Benutzer versucht etwas zu nutzen, was er gar nicht braucht.

Ihr kennt diese Systematik sicher aus der Praxis in unterschiedlichsten Ausbaustufen. Diese gibt es von knackig-kurzer Tabelle bis hin zu zwei DIN-A4-Seiten Prosa.

Wenn ich solch ein System sehe drängt sich sofort die Frage auf: Wie genau kann der Service Desk Agent die Priorität einschätzen? Immerhin ist am anderen Ende der Leitung ein aufgebrachter Endanwender, der nahezu nie sagen wird „hat einen Tag Zeit“ sondern eher auch mal bei Kleinkram „Ahrg, hier kann keiner mehr arbeiten, ihr müsst sofort was tun!“. Vom dem betroffenen IT Service haben Endanwender keine Ahnung: „Ich muss hier Rechnungen archivieren, gestern ging es noch! Macht was!“.

Die Antwort eines Service Desk Teamleiters auf meine Frage lautet fast nie: „Dann klickt der Agent in das Impact-Analyse-Modul der CMDB…“, wie man das immer so schön auf ITSM Messen sehen kann. Sondern meist: „Meine Leute haben eine Menge Erfahrung“. Das Vertrauen des Teamleiters in die Kompetenz seiner Leute in allen Ehren, eine Analyse des Ticket-Abzuges eines Monats ergibt fast immer, das dem nicht so ist. Gleiche Vorfälle werden unterschiedlich eingeschätzt, die statistische Analyse sagt dann eher etwas über die IT Organisation aus, also über Wiederholbarkeit.

Die anzustrebende Normalverteilung „Ticketanzahl nach Priorität“ findet sich bei diesen „Priorität via Umschreibung“-Systemen so gut wie nie.
normalverteilung

Eine nach Links verschobene Verteilung, die sich auf Prio 1 und 2 konzentriert ist die häufigste Krankheit.

links

Ein nach rechts verschobener Berg kommt fast nie vor. Einige IT Organisationen halten sich für besonders clever und haben die Eigenheit „bei uns gibt es keine Major Incidents“. Ja toller Trick, dann nennen wir es eben „Prio 2“.

rechts

Auch ein Gebirge mit ausgeprägtem Tal kommt vor. Hier bedeutet der Prio 2 Gipfel zum Beispiel ERP, MES und Co. der Prio 4 Gipfel sind dann die Endanwender.

mitte

Noch einmal zurück auf Anfang: Wozu wird eine Priorisierungs-Systematik eigentlich benötigt? Im Kern stehen sicherlich nicht statistische Analysen wie gut die IT ist, im Kern geht es darum die Support-Teams in heißen Phasen zu lenken. Wenn alle Mitarbeiter engagiert Störungen beseitigen, welche Störungen sind dann zuerst dran?

Mit obigem System kann der Service Desk dies nicht sinnvoll entscheiden. Je nach Störung kann dies eventuelle ein 2nd-Line-Team, die nämlich feststellen, dass eine Zentralkomponente ausgefallen, demnach 300 Anwender betroffen sein müssten. Der Service Desk hat keine Chance, anhand von munter definierten Schachtelsätzen dies abzuschätzen.

Professionelles Schätzen

Die Aufgabenstellung ist: Wie schätzt der Service Desk professionell eine Priorität, wenn es keine technische Unterstützung sondern nur den Endanwender am Telefon gibt?

Impact: Gut unterscheiden lässt sich, ob ein oder mehrere Anwender betroffen sind.
„Wie viele Anwender sind betroffen?“
„Alle hier!“
„Auch ihr Schreibtischnachbar?“
„Ich sagte doch alle!“
„Darf ich ihren Schreibtischnachbar mit in das Ticket eintragen? Wie heißt er denn?“
Anwender rufend „Sach mal Karl, funktioniert Dein ERP auch nicht?“

Ja nach Firmenstruktur kann solch ein System auch auf Gebäude bzw. Ebenen ausgedehnt werden. Damit es Sinn ergibt, muss eine Übersicht der Anwender pro Gebäude vorliegen und eine Überprüfungsmöglichkeit wie ein Anruf durch einem Key User geben.

Organisatorische Strukturen wie Abteilung, Hauptabteilung können auch herangezogen werden, wenn deren Daten geordnet als Übersicht mit Ansprechpartner vorliegen. Firmen ohne CMDB, haben meist auch hier Lücken.

Urgency: Zur Einschätzung der Dringlichkeit kann sozusagen eine Minimalversion einer CMDB genutzt werden. Die wichtigsten 10 Services bekommen eine Dringlichkeitsstufe zugeordnet. Häufen sich Tickets zu einem System, prüft Service Desk mit dem 2nd-Line-Team, ob der Service betroffen ist. Dies geht zum Beispiel wunderbar per Chat.

Diese Mini-CMDB kann prima als Tabelle auf einem Share abgelegt werden. In großen Service Desk Teams ergibt es auch Sinn diese Tabelle als Strichliste zu nutzen. Übrigens, wer nun auf die Idee kommt 20 oder 50 Services in die Tabelle einzutragen, der hat diesen Artikel nicht verstanden, darf mich gerne um Rat fragen, oder zu eśeinem alten System zurückgehen.

Das ist nicht Professionell!

Wie gesagt, es gibt Zeitgenossen, deren Antwort auf Herausforderungen wie diese Stereotyp lautet, muss man alles bis auf die letzte Schraube definieren, CMS, SMKS, etc. muss da sein.

Meine Antwort ist: Mache aus den verfügbaren Mitteln das Beste und richtet sich an Teamleiter die konkret und ohne Budget Verbesserungen schaffen müssen. Veraltete oder ohne Sachverstand einführte ITSM Tools, liefern oft keine sinnvolle Unterstützung vom simplen festhalten der Vorfälle mal abgesehen.

Was mir auch Wichtig ist: Eine kompakte kleine von Services ausgehende CMDB (CMS) ist kein Hexenwerk, leicht zu pflegen und liefert auch auf dem Niveau von Services eine tolle Unterstützung für den Service Desk. Leider konzentrieren sich manche IT Organisationen auf andere Schlachtfelder. Eine ordentliches Top-Down eingerichtetes CMS ist wie eine sauber Strukturierte Produktionshalle. Die hat nicht jeder.

P.S.: Warum funktionieren Service Desks mit solchen Prosa-Prioritäten eigentlich? Die Antwort lautet: Sie tun es nicht. So lange genug Kapazität vorhanden ist, können die Vorfälle einigermaßen Zeitgerecht verarbeitet werden. Erst wenn die Hütte brennt, bekommt das Priorisieren seinen eigentlichen Sinn. Dann unterscheiden sich Profis, von guten Teams, von Hühnerhaufen.

What is the defined scope of different support levels or lines?

If a job post asks for a 1st-line supporter or an RfP is requesting a first- and second-level support, the exact scope is more a question than a direct answer. Different lines-of-support is more a differentiation of team divisions, than an industry defined share of vertical integration. But let us discuss it bit by bit:

[Link to German version]

„What is the defined scope of different support levels or lines?“ weiterlesen

Service Desk – Was ist zu dokumentieren?

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“. „Service Desk – Was ist zu dokumentieren?“ weiterlesen

Service Desk – Dokumentation mit Tools

In der ITIL®-Dokumentation findet sich ein ganz schönes Bild: Die SKMS (Service Knowledge Management System). Ich hoffe es ist konzeptionell und nicht technisch gemeint. In erstaunlich vielen Projekten werden nämlich diverse Tools für viel Geld miteinander verknüpft, teilweise mit unidirektionalen Schnittstellen oder ähnlichen faulen Kompromissen und danach kommt es nicht zum erhofften Wunder der Wissensvermehrung. „Service Desk – Dokumentation mit Tools“ weiterlesen