Kapitel 2:
Einführung eines IT Service Managements (ITSM)

?In den vielen Unternehmen, in denen IT-Prozesse etabliert sind, wurden die IT-Prozesse wie z.B. Incident Management, Problem Management und Change Management eingeführt. Was jedoch oft fehlt, sind Prozesse wie Service Level Management, Service Catalog Management, Portfolio Management, Requirement Management oder auch Configuration Management.

In einigen Unternehmen war das Management sogar der Meinung, dass, wenn die Mitarbeiter die Handbücher eines weitverbreiteten Prozess-Frameworks für IT Service Management gelesen oder eine entsprechende Zertifizierung erreicht haben, diese Prozesse automatisch leben und sie somit als eingeführt gelten.

Spätestens nach einem Audit oder einem Assessment hat sich jedoch deutlich gezeigt, dass diese Meinung nicht der Realität entsprach und die IT Service Management-Prozesseinführungen basierend auf einem strukturierten Modell anzugehen sind. In diesem Abschnitt wird dieses Einführungsmodell etwas eingehender betrachtet.

2.1  Modell zur Einführung von ITSM-Prozessen

Falls neue Prozesse etabliert werden sollen, empfiehlt sich folgendes Vorgehen, das an die Größe des jeweiligen Unternehmens angepasst werden kann.

Das hier vorgestellte Modell (siehe Abbildung 2.1) unterscheidet vier verschiedene Einführungsbereiche:

1. Dokumentation

   Auf dieser Ebene erfolgen die Definition und das Erstellen der entsprechenden Prozess- und Tool-Beschreibungen. Die Dokumentation dient als Nachschlagewerk bei Fragen betreffend der Prozessnutzung oder auch als Schulungsgrundlage für neue Mitarbeiter, die Rollen innerhalb der Prozesse wahrnehmen.

2. Prozess

   Hier werden die nötigen Prozessschritte, die Prozessrollen inklusive der KPIs definiert, getestet und später in Verbindung mit dem entsprechenden Tool/Hilfsmittel eingeführt.

   Abb. 2.1: Einführungsmodell von ITSM-Prozessen?

3. Tools/Hilfsmittel

   Auf der Ebene der Tools/Hilfsmittel werden entsprechende Anwendungen und Software-Programme evaluiert oder auch entwickelt, um den Prozess zu unterstützen. Immer häufiger werden in diesem Bereich auch Workflow-Tools eingesetzt, was die Prozessdokumentation auf Stufe der Arbeitsanweisungen, auch Working Instruction ?(WINs)? genannt, stark vereinfacht. Die Prozessschritte, die in einem Workflow-Tool abgebildet werden, müssen nicht in einer WIN separat beschrieben werden.

4. Organisation

   Auf der Organisationsebene werden die Prozessrollen den verschiedenen Mitarbeitern im Unternehmen zugeteilt und, falls nötig, wird der Ausbildungsbedarf ermittelt.

Jedes Unternehmen kann dieses Einführungsmodell mit weiteren Ebenen wie z.B. Verrechnungslösung, Drittanbieter (bei einem Sourcing) erweitern. Die Basis des Modells bleibt jedoch in den meisten Fällen bestehen (siehe Abbildung 2.1).

2.2  Bereich: Dokumentation

Die Dokumentation der Informatikprozesse muss für jeden Rollenträger zur Verfügung stehen. Im Speziellen sind es die Arbeitsanweisungen (Working Instructions? »WINs?«), die dem einzelnen Rollenträger aufzeigen, in welchem Arbeitsschritt er sich befindet und wie er ihn ausführen muss. Aus diesem Grund sollte die Lösung, die zur Prozessdokumentation verwendet wird, verschiedene Ansichten (Views) zur Verfügung stellen, z.B. Ansicht nach IT-Prozessen, Ansicht nach IT-Prozessrollen oder im Idealfall auch nach Funktionen (wie in Abschnitt 1.2.3, »Etablieren der nötigen IT-Prozesse inklusive der Rollen« beschrieben). Weitere zusätzliche Ansichten für Experten sind empfehlenswert, in denen z.B. jeder IT Process Manager oder IT Process Owner seine eigenen Prozesse sieht und diese pflegen oder Änderungen freigeben kann.

Das verwendete Tool sollte auch eine Versionierung bei Änderungen für einen späteren Audit-Trail zur Verfügung stellen. Mittels einer Workflow-Unterstützung bei Prozessveränderungen, wie beispielsweise das Akzeptieren eines neuen Prozess-Inputs durch den verantwortlichen IT Process Manager oder die finale Abnahme/Freigabe von Prozessänderungen durch den IT Process Owner, können die Pflege und Wartung der Prozessdokumentation vereinfacht werden.

Damit die Prozesse auf die Praxis und die Bedürfnisse der Rollenträger ausgelegt sind, hat sich ein Feedback-Knopf sehr bewährt, der in der Prozessansicht gedrückt werden kann, um Verbesserungen oder Anregungen zu platzieren. Das funktioniert selbstverständlich nur dann, wenn das Feedback seriös bearbeitet wird und nicht in einem großen schwarzen Loch verschwindet.

2.3  Bereich: IT-Prozesse

?Die Kernfrage in diesem Bereich ist: Welche Prozesse möchte oder muss man etablieren? Da viele Firmen bereits verschiedene IT-Prozesse eingeführt haben, kann es sein, dass in einem zweiten Schritt zusätzliche Prozesse wie z.B. Requirement Management oder IT Financial Management einzuführen sind.

Bei Kunden, die noch keine IT-Prozesse etabliert haben, stellt sich immer wieder die Frage, welche IT-Prozesse in einer ersten Phase eingeführt werden sollten und welche eher in einer zweiten oder dritten Phase.

Die unten stehende Auflistung basiert auf Erfahrungen bei unterschiedlichen Kunden und kann als Orientierungshilfe dienen. Da jedoch jeder Kunde eigene Anforderungen und Problemstellungen hat, können sich die Prozesse je Phase ändern.

Welcher IT-Prozess eingeführt werden muss, kann in jedem Unternehmen unterschiedlich sein. Die drei unten aufgeführten Fragestellungen können bei der Bestimmung jedoch helfen:

1. Welcher neu einzuführende IT-Prozess bringt den größten Nutzen?

2. Wo liegen heute in der IT die größten Risiken und welcher IT-Prozess kann sie reduzieren oder gar vermeiden?

3. Welcher IT-Prozess kann wichtig für die Erreichung der Unternehmens-/IT-Zielsetzungen sein?

Die aufgeführten Prozesse und/oder Fähigkeiten sind nicht in einer bewerteten Reihenfolge innerhalb der Phase dargestellt, sondern entsprechen der Anordnung der Life-Cycle-Stufen.

2.3.1  IT-Prozesse in der Phase 1 (aus meiner Sicht sehr wichtig):

• Service Level Management (Design) Der Service-Level-Management-Prozess sollte mindestens rudimentär eingeführt sein, sodass die Informatik weiß, was der Leistungsbezieher fordert.

• Change Management (Transition)

• IT Asset Management (Transition) Falls das eingesetzte ITSM-Tool eine eigene IT-Asset-Datenbank zur Verfügung stellt

• Configuration Management (Transition)

• Incident Management (Operation)

• Problem Management (Operation)

• Service Request Management (Operation)

• Project Management (Transition)

2.3.2  IT-Prozesse in der Phase 2 (aus meiner Sicht wichtig):

• Requirement Management (Strategy)

• IT Financial Management (Strategy)

• Release Management (Transition)

• Deployment Management (Transition)

• Information Security Management (Design)

• Service Continuity Management (Design)

• Service Catalog Management (Design)

• Availability Management (Design)

• Capacity and Performance Management (Design)

• Operational Level Management (Design)

• Monitoring and Event Management (Operation)

• Access Management (Operation)

• Risk Management (Supporting)

2.3.3  IT-Prozesse in der Phase 3 (aus meiner Sicht empfehlenswert):

• Business Relationship Management (Strategy)

• Portfolio Management (Strategy)

• Strategy Management (Strategy)

• Supplier Management (Design)

• Service Validation and Testing (Transition)

• Knowledge Management (Transition)

• Architecture Management for IT (Strategy)

• Continual Improvement (Supporting)[1]

Die in Abschnitt 3.3, »Etablieren der Prozesse des IT Service Managements« aufgeführten IT-Prozesse sind nach den aufgeführten Phasen gegliedert. Eine Ausnahme bildet der Operational-Level-Management-Prozess. Dieser wird im Abschnitt 3.3.1, »Service Level Management (Design)« beschrieben.

Wie im Bereich »Prozesse« in Abbildung 2.1 dargestellt, erfolgt die Definition der IT-Prozesse in verschiedenen Schritten. Das Modell mit drei Levels in der Definitionsphase hat sich sehr bewährt:

2.3.4  Level 1: Entwickeln einer Prozessbeschreibung

Dieser Schritt umfasst folgende Dokumentationstiefe:

• Prozessbeschreibung

• Prozessziele

• Prozessumfang (was ist enthalten, was ist nicht aufgeführt)

• Prinzipien/Guidelines zum Prozess

• Prozessschritte (Prozessboxen) und Teilschritte mit einer Beschreibung inklusive der Eingänge (Inputs) und Ausgänge (Outputs)

• Prozessrollen

• Beschreibung der zu erhebenden Prozessmesskennzahlen

• Definieren der Prozess-Management-Zuständigkeit

• Es erfolgt die Zuteilung, wer die IT-Process-Owner- und wer die IT-Process-Manager-Rolle für den entsprechenden Prozess übernimmt.

2.3.5  Level 2:...