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.

Wichtig, Wichtiger am Wichtigsten

Manchmal – ganz kurz – sehne ich mich zurück und möchte meinen Monitor gegen ein 90-iger Jahre 21″-Paperwhite Exemplar tauschen. Aus dem einzigen Grund: Von Mitmenschen verbrochene Rich-Text-E-Mails oder Dokumente in ihrer Wirkung etwas abmildern zu können.

Da wird munter mit Farben und Auszeichnungen rumgeklotzt, dass es einem in den Augen vor lauter Hervorhebung wehtut. Der erste Fehler ist natürlich, dass Textverarbeitungen und E-Mail-Clients so einen Müll auf einen Mausklick bereitstellen.

Wichtig wichtiger

Der zweite Fehler ist jedoch schlimmer: Man tut Unbildung und Verwirrung kundtun.

Zerlegt man ein Dokument mit duzendfacher Auszeichnung in dessen unterschiedliche Bestandteile, stellt man fast immer fest, das trotz mannigfaltiger Unterstrechung und Hervorhebung es dem Autor entglitten ist: Wichtiges wird nicht von Unwichtigem unterschieden. Ganz so wie Studierende Bücher und Skript mit dem Textmarker durcharbeiten. Dinge sind so lange wichtig, wie der Arm noch nicht weh tut.

Also noch mal zurück auf Los. Die Dinge sind erst gut, wenn sie nicht mehr vereinfacht werden können.

  1. Text sortieren und gliedern. Auch wenn es nur eine E-Mail ist. Was soll der Leser verstanden haben? Mit einem Element beginnen: Wenn der Leser fast nichts versteht, welcher Inhalt muss verstanden sein? Jetzt auf zwei Elemente erhöhen.
  2. Überschriftsebenen gliedern den Text, so wenig wie möglich, so viel wie nötig.
  3. Kursiv für Dinge die während des Lesens auffallen sollen. Kursiv verlangsamt das Lesen. Bitte keine ganzen Passagen kursiv.
  4. Fett zieht wie ein Schlagwort im Lexikon die Aufmerksamkeit an sich. Was soll der Leser beim ersten Anblick des Dokuments erfassen?

Fertig, mehr braucht es nicht. Wer mehr über Typografie wissen mag: Typografie mit dem OpenOffice.org Writer

P.S.: Wenn sich 12-jährge zum ersten Mal schminken, kommt doch auch die Mama mit dem feuchten Tuch und macht der Sache ein Ende. Warum gibt es solche Zuwendung nicht auch in der Geschäftswelt? Ich gäbe etwas darum.

Processes without people – Hope springs eternal

Ages ago I started my career in the Unix company with the nice logo. In transition projects when Windows infrastructure was changed to Unix, there was a golden rule: Find new jobs for the old administrators – a good inter company choice was the client environment. The reason is simple, it takes a lot of training and time to become familiar with a different architecture and learn about new approaches. In other words: If you try to re-educate existing staff, there is a high chance that the “everything used to be better” minded will win the game by time.

[Link to German version]

Dear reader, feel free to flip the place-holders “Windows” and “Unix” or substitute them by any other things that are different in concept and you’ve a general rule.

Let us use the place-holders “historical IT operational sequences” and “operations guided by ITIL® practices” in this article. The astonishing fact about this flavour of the general rule is: There are people out in IT industry who believe that something like this can work satisfyingly.

We use the example of a certain IT department, which is according to industry benchmark too rich staffed. The results of this department are not good, but tolerable in quality, using a lot of overtime work. This example is not completely unfounded, such set-ups can be easily found. Take a look at established internal IT organizations who did the usual mistake negotiating special terms with a lot of internal customers. All these special agreements weaved to a thick complex network, that is operated manually and eats a lot of resources. From a corporate perspective, usually without any deeper reason or benefit.

In fact such a situation is perfect to structure everything towards ITIL. A project could implement and standardize internal agreements (OLAs) which ensure that extra-services are only carried out against extra-money. A change management could take care to focus and prioritize changes. The formerly too rich department would be enabled to separate important from unimportant things using a business perspective. After standardization, change requests will be professionally evaluated, communicated and implemented. Something like this can work and will save a lot of money in the end.

In such situations I often notice that the old team is almost not supported. A consultant explained them ITIL upfront in a three sessions course, even sometimes including the necessary changes in correctly amended detail. Taken the short time into account – means no time to think – the team understands: “They want to bother us, the consultant understands not a single bit of our business needs; and oh, god, we will get an extra burden of bureaucracy!” Depending on the behaviour of the management team, usual after initial defensive battles of the team in which management just gets the “everything used to be better” attitude, management switches to high pressure mode and cuts headcount.

The reaction of the old team, that still does not gets the meaning and benefits of industrialization and good practices, will start to play a role, e.g. masquerades a process flow that makes no sense. In reality, they do their old job. But now much worse, with fewer resources and supporting this extra “process” bureaucracy. Such “ITIL implementation” becomes ludicrous when there is a high 6-digit budget for the design, but almost no money left for implementation and management decides to assign this task to the old teams and who apparently get nothing more than some material to read.

I always wonder, what is the mindset of people who want develop service management using this approach. Essentially this is as worse as sending initially mentioned Windows administrators to a short Unix training. With the next problem popping up this short trained guys are clueless. To build a bridge from problem to solution was a no brainer for those guys in their familiar environment, because the solved similar cases in the past. Now with the new technology everything seems to be difficult and unmanageable. No one understands why managements goes for this stupid Unix. (Again feel free to interchange “Windows” by “Unix” administrators).

The missing knowledge to bridge a gap applies as is also for operating processes: the well known evolved processes are familiar, in an ITIL world a way walking along the accepted practices is unknown and hard to find.

The reason is familiarisation and can be observed by the example of a new employee in the old department structures: In the first working days the new employees will realize the existing procedures as complex, confusing and he finds the need of improvement obvious. After half a year he gets along quite well in the chaos and the impression of complicated will start to dissolve. After a year he will already be absorbed in the processes and all his initial suggestions to improve the mess are refused as too simple, because by his current knowledge all suggestions do not reflect all the different special rules of each internal customer.

My finding is: In existing structures only a few people are able switch to an abstraction level that enables them to map the existing to a new system. One key to success is to find and utilize those employees to communicate with ITIL experienced staff or consultants. You will need them to leverage solutions until the major part (e.g. 80%) of the problems were solved by alternatives. Beware those alternatives, are developed by experts of the new system. A Windows administrator is not able to develop a Unix-style solution. When the architects of the old system develop the new solution, you will get the worst of both worlds. Basically a concept of the ancient world, with a lot of whopping and tinker to be amended to the new world.

My letter to the protectors of the budget, if there is no budget for implementation available, please wait for the next fiscal year. Delay is a far better idea, than the abuse of the old team plus some prayers for a miracle.

Last note: Initial general rule is in general not commutative. People who are used to higher maturity, can easily manage lower maturity structures. This is a usual smack in corporate acquisitions. Nevertheless there is a direct link to higher attrition if such simple structured operations become the main task of senior employees.

Issue: Incident and Problem

ITIL® provides a set of good practices which is a kind of general direction. In ITIL there are processes and roles that need to be provided. How exactly is a matter of the individual organization. In the ITIL books you will also find remarks, anecdotes or even sometimes (inappropriate) generalizations that give a good indication of how processes and functions are implemented in reality. A very common question of ITIL beginners is, how an incident becomes a problem. The short answer is: “Never”. The full answer is as follows …

[Link to German version]

Weiterlesen

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]

Weiterlesen