Fritz Kleiner ist CEO der Firma Futureways GmbH und hat sich auf die Beratung und Lehre im Bereich des IT Service Managements spezialisiert. Er hat über 28 Jahre Erfahrung im Bereich der Informatik, welche er in zahlreichen nationalen und internatialen Kundenmandaten im Outsourcing, Versicherungs-, Banken-, Pharma- und Verwaltungsumfeld als Managing Senior Consultant und Pricipal erwarb.
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, Service Portfolio Management, Requirement Management oder auch Service Asset and 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, sie diese Prozesse automatisch leben und somit die Prozesse 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:
-
Dokumentation
Auf dieser Ebene erfolgt 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.
-
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-Proz?essen
-
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.
-
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 den einzelnen Rollenträgern 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, kann 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-Pro?zesse
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 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:
-
Welcher neu einzuführende IT-Prozess bringt den größten Nutzen?
-
Wo liegen heute in der IT die größten Risiken und welcher IT-Prozess kann sie reduzieren oder gar vermeiden?
-
Welcher IT-Prozess kann wichtig für die Erreichung der Unternehmens-/IT-Zielsetzungen sein?
Die aufgeführten Prozesse sind nicht in einer bewerteten Reihenfolge innerhalb der Phase dargestellt, sondern entsprechen der Anordnung der Life-Cylce-Stufen.
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)
-
Service Asset and Configuration Management (Transition)
-
Incident Management (Operation)
-
Problem Management (Operation)
-
Request Fulfillment (Operation)
IT-Prozesse in der Phase 2 (aus meiner Sicht wichtig):
-
Requirement Management (Strategy)
-
Financial Management for Services (Strategy)
-
Release 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)
-
Event Management (Operation)
-
Access Management (Operation)
-
Risk Management (Supporting)
IT-Prozesse in der Phase 3 (aus meiner Sicht empfehlenswert):
-
Business Relationship Management (Strategy)
-
Service Portfolio Management (Strategy)
-
Demand Management (Strategy)
-
Supplier Management (Design)
-
Transition Planning and Support (Transition)
-
Service Validation and Testing (Transition)
-
Deployment Management (Transition)
-
Knowledge Management (Transition)
-
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. Er ist bereits in 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:
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 Unterschritte 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...