Neben den Interessen aller Beteiligten im Projekt gibt es noch weitere weiche Faktoren, die man leicht übersehen kann. Einige dieser Faktoren erleichtern eine erfolgreiche ITIL-Einführung, andere verhindern, dass bestimmte Problemlagen gar nicht erst eintreten.

In diesem Beitrag erfahren Sie:

• wie Sie mögliche Quick Wins kurzfristig erzeugen können,
• welchen Einfluss die Unternehmensphilosophie auf Ihr ITIL-Projekt haben kann,
• welche Widersprüchlichkeiten es im Projekt gibt und wie Sie damit umgehen.

Kaum beachtete aber bedeutsame Erfolgsfaktoren

Wurden weiter oben bereits die bekannten, typischen Erfolgsfaktoren der Prozessoptimierung nach ITIL behandelt, geht es im Folgenden um die eher »weichen« und nicht so häufig berücksichtigten Handlungsfelder von ITIL-Projekten.

Der verantwortliche Projektleiter für die ITIL-Einführung steht unter mehrfachem Erfolgsdruck. Er muss Quick Wins sowohl für den Sponsor, also seinen Auftraggeber, erzeugen, als auch für die betroffenen Mitarbeiter. Nur so kann er die Richtigkeit der ITIL-Einführung unter Beweis stellen. Dabei sind die schnellen Erfolge für die Geschäftsleitung sicherlich anders zu definieren als für die Mitarbeiter. Steht bei der Geschäftsleitung meist der Gedanke von Kostensenkung im Vordergrund, so sind für den Mitarbeiter die Kosten eher zweitrangig. Ihn interessiert vielmehr, inwieweit ihm ITIL seine Arbeit erleichtert.

In jedem Unternehmen beziehungsweise jeder Organisation, bei der ITIL eingeführt werden soll, sind stellenweise und in unterschiedlicher Ausprägung bereits ITIL-Elemente im Einsatz. Diese haben aber meist eine andere nicht ITIL-konforme Bezeichnung, sind anders verknüpft und werden anders gelebt. Von daher muss man immer von der spezifischen IST-Situation im Unternehmen ausgehen. Somit kann man mit keinem starren Implementierungsmodell arbeiten, sondern lediglich mit einer Vielzahl von Fragestellungen, aus deren Antworten sich dann ein jeweils maßgeschneidertes Vorgehen ableiten lässt. Um dieses Ziel zu erreichen, sind die nachfolgend erläuterten Aspekte zu beachten.

ITIL und das Pareto-Prinzip

Von de Gaulle stammt der Ausspruch: »Es ist besser, unvollkommene Entscheidungen durchzuführen, als beständig nach vollkommenen Entscheidungen zu suchen, die es niemals geben wird.« [1] Auch der chinesische Philosoph Lü Bu We hat sich einst mit der Frage der perfekten Lösung auseinandergesetzt und erkannt: »Was allzu vollkommen ist, hat sicher seine Lücken, was auf die Spitze getrieben wird, schlägt sicher in sein Gegenteil um, was voll ist, wird sicher abnehmen.« [2]

Beide Autoren haben die Problematik von Perfektionismus klar gesehen und erkannt, dass gute Ergebnisse auch mit deutlich weniger Aufwand erzielt werden können und zudem noch schneller.

Der italienische Ingenieur, Ökonom und Soziologe Vilfredo Pareto hat Ende des 19. Jahrhunderts die Verteilung des Volksvermögens in Italien untersucht. Dabei stellte er fest, dass etwa 80 Prozent der Bevölkerung nur 20 Prozent des Volksvermögens besaßen, während die übrigen 20 Prozent der Bevölkerung rund 80 Prozent des Volksvermögens innehatten. Wenn sich zum Beispiel Banken um diese 20 Prozent der Bevölkerung besonders kümmerten, müssten sie schon ihr Auskommen haben, schloss Pareto.

Als er 1896 seine Forschungsergebnisse veröffentlichte, wurde dieses nach ihm benannte Pareto-Prinzip auch 80-20-Regel genannt auf breiter Front aufgegriffen. Bald stellte man jedoch fest, dass es sich um eine universelle Regel handelt, die in fast allen Lebensbereichen anwendbar ist:

• 80 Prozent der Weltbevölkerung lebt in 20 Prozent der vorhan-denen Städte,

• mit 20 Prozent der Waren erwirtschaftet man 80 Prozent des Gewinns,

• 80 Prozent des Ausschusses in einem Fertigungsbetrieb lassen sich auf 20 Prozent der möglichen Fehler zurückführen,

• in 20 Prozent seiner Zeit kann man 80 Prozent seiner Aufgaben erledigen.

Die Anwendung des Pareto-Prinzips hilft also, Wichtiges von Unwichtigem zu trennen und gibt eine Entscheidungshilfe für die Optimierung der Arbeit. Mit ihrer Hilfe kann man die wesentlichsten Einflussgrößen von zu beobachtenden Phänomenen identifizieren und auf einfache Art bildlich darstellen. Dabei geht man in mehreren Schritten vor:

• Zunächst muss man das Thema mit dem Untersuchungsgegenstand festlegen. Man muss sich darüber klar werden, welches Ziel man erreichen will.

• In einem zweiten Schritt sind dem Untersuchungsgegenstand Kategorien zuzuordnen, mit denen das zu untersuchende Phänomen beschrieben werden kann. Um einige Beispiele zu nennen: Fehlerarten, Kunden, Produkte, Ursachen für beobachtete Phänomene, etc.

• Im dritten Schritt werden die Größenangaben festgelegt, mit denen man das Ausmaß des Eintretens der kategorisierten Phänomene beschreibt. Am meisten wird hier die Häufigkeit genommen, mit der zum Beispiel ein Fehler auftritt oder ein Phänomen eintritt. Denkbar ist hier auch eine zusammengesetzte Größe, in der man die Häufigkeit mit den auftretenden Kosten multipliziert, um so die finanziellen Auswirkungen des Phänomens zu erfassen.

Es wird aber nicht nur der absolute Anteil bestimmt, sondern auch der relative Anteil an der Gesamtmenge ausgerechnet. Das geschieht unter Anwendung folgender Formel: Prozent-Häufigkeit = Teilmenge / Gesamtmenge x 100.

Die erhaltenen Werte trägt man in ein Koordinatensystem von links nach rechts ein. Dabei beginnt man mit dem höchsten Wert und fügt rechts davon den jeweils nächst kleineren an. Für jeden Wert trägt man eine Säule ein. Stapelt man nunmehr die einzelnen Säulen jeweils versetzt übereinander, so ergibt sich eine kurvenförmige Anordnung, die so genannte Pareto-Kurve. Aus ihr kann man leicht den 80-zu-20-Zusammenhang ablesen siehe Abb. 1.

Es stellt sich die Frage, ob man das Pareto-Prinzip auch auf ITIL anwenden kann. Wenn ja, so muss es möglich sein, mit einem relativ kleinen Aufwand ITIL so einzurichten, dass aus den schon implementierten Elementen Ist-Situation ein Höchstmaß an Gewinn gezogen werden kann. Es gilt also, von allen Einführungsaktivitäten die 20 Prozent herauszukristallisieren, die 80 Prozent des Gewinns einer ITIL-Einführung hervorrufen.

Aber welcher Gewinn soll gemeint sein? Es gibt auf diese Frage mehrere mögliche Perspektiven, die im Projekt vorab zu klären sind:

• Managementsicht,

• Mitarbeitersicht,

• Kundensicht,

• Aufwand/Kosten,

• Zeitbedarf im Sinne von Fertigstellung,

• Kombinationen aus einigen oder allen Sichtweisen.

Steht beispielsweise die Managementsicht oder das Thema Aufwand/Kosten im Vordergrund, so wird viel mehr Gewicht auf die Schaffung von Transparenz durch die Einrichtung eines funktionierenden Financial Managements gelegt, als wenn die Kundensicht im Fokus steht. Der Kunde wiederum sieht viel stärker, wie er durch den Service Desk unterstützt wird und wie schnell seine Incidents und Problems abgearbeitet werden.

Im Anschluss müssen die Kategorien festgelegt werden. Sie könnten mit den einzuführenden Prozessen gleichgesetzt werden, allerdings wäre dieses Raster zu grob. Jeder einzuführende Prozess hat nämlich ein ganzes Konglomerat von Einzelelementen, die separat zu betrachten sind. Zum Beispiel zeigen sich beim Incident-Prozess unter anderem folgende Elemente:

• Service Desk als Single Point of Contact SPOC,

• Automatic Call Distribution ACD,

• Computer Telephonie Integration CTI,

• Annahme und Abarbeitung von Standard Service Requests SSR,

• Berichtswesen,

• horizontale und vertikale Eskalation,

• Kategorisierung von Fehlern,

• Benachrichtigung von Anwendern,

• Training der Mitarbeiter,

• Festlegung von Key Performance Indicators KPI etc.

Es ist daher sinnvoll, die einzelnen Elemente des jeweiligen Prozesses darauf abzuklopfen, wie schnell sie realisiert werden können. Es gibt Elemente, die sich schnell umsetzen lassen, wie zum Beispiel die Einrichtung eines SPOC. Andere Elemente, wie die Einrichtung eines ACD oder CTI, sind erheblich aufwändiger.

Da nahezu jede Firma und jede Organisation bereits in irgendeiner Form ITIL betreibt ohne es zu wissen und ohne die ITIL-konforme Begrifflichkeit zu verwenden kann man kein für alle Fälle gültiges Modell entwickeln. Vielmehr muss man von dem ausgehen, was man vorfindet, und daraus ermitteln, welche Einzelkomponenten für die komplette Einführung der beauftragten Prozesse noch fehlen.