IT Service Management - mitp · können. ITSM kann mehr, Geschäftsprozessmanagement auf vielen Ebenen wird möglich. Die anderen Prozesse sind mang els Vorgehensmodellen teilweise

3

Inhaltsverzeichnis

Geleitwort von Ruedi Noser, Präsident ICTswitzerland (zur ersten Auflage 978-3-658-00180-3) . . . . . . . . . . . . . . . . . . . . . . . 5

Geleitwort von Jürgen Dierlamm, Geschäftsführer itSMF Deutschland e.V. (zur zweiten Auflage) . . . . . . . . . . . . . . . . . . 7

Vorwort (zur ersten Auflage) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Vorwort (zur zweiten Auflage) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1 Was beinhaltet IT Service Management?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.1 Hauptdienstleistungselemente einer Informatik . . . . . . . . . . . . . . . . 131.2 Hauptelemente für ein erfolgreiches IT Service Management . . . . . 14

1.2.1 Wissen, was der Leistungsbezieher braucht und erwartet . . . 151.2.2 Standardisierung der IT-Dienstleistungen . . . . . . . . . . . . . . . 161.2.3 Etablieren der nötigen IT-Prozesse inklusive der Rollen . . . 241.2.4 Messen und Auswerten der erbrachten Dienstleistung . . . . 321.2.5 Optimieren der vereinbarten Dienstleistung . . . . . . . . . . . . . 34

2 Einführung eines IT Service Managements (ITSM) . . . . . . . . . . . . . . 412.1 Modell zur Einführung von ITSM-Prozessen . . . . . . . . . . . . . . . . . . . 412.2 Bereich: Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.3 Bereich: IT-Prozesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.3.1 Entwickeln der Prozess-Management-Struktur . . . . . . . . . . . 472.4 Bereich: Tools und Hilfsmittel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.5 Bereich: Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.6 Verankerung des IT Service Managements

in der Führungsebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.7 Führung und Leitung des Vorhabens . . . . . . . . . . . . . . . . . . . . . . . . . 51

3 IT Service Management Umsetzungsbeispiele . . . . . . . . . . . . . . . . . . 553.1 Aufbau einer Prozess-Management-Organisation . . . . . . . . . . . . . . . 56

3.1.1 Aufgaben des IT Process Owners . . . . . . . . . . . . . . . . . . . . . . 57

© des Titels »IT Service Management« (ISBN 9783958455047) 2016 by mitp Verlags GmbH & Co. KG, Frechen. Nähere Informationen unter: http://www.mitp.de/504

Inhaltsverzeichnis

4

3.1.2 Aufgaben des IT Process Managers . . . . . . . . . . . . . . . . . . . . 573.1.3 Aufgaben des Head of IT Process Managers . . . . . . . . . . . . . 59

3.2 Bildung von Business IT Services und IT Services . . . . . . . . . . . . . . . 603.2.1 Business IT Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.2.2 IT Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.3 Etablieren der Prozesse des IT Service Managements . . . . . . . . . . . . 693.3.1 Service Level Management (Design) . . . . . . . . . . . . . . . . . . . . 693.3.2 Change Management (Transition) . . . . . . . . . . . . . . . . . . . . . 953.3.3 Service Asset and Configuration

Management (Transition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1083.3.4 Incident Management (Operation) . . . . . . . . . . . . . . . . . . . . . 1223.3.5 Problem Management (Operation) . . . . . . . . . . . . . . . . . . . . . 1363.3.6 Request Fulfillment (Operation) . . . . . . . . . . . . . . . . . . . . . . . 1433.3.7 Requirement Management (Strategy) . . . . . . . . . . . . . . . . . . . 1553.3.8 Financial Management for Services (Strategy) . . . . . . . . . . . . 1633.3.9 Release Management (Transition). . . . . . . . . . . . . . . . . . . . . . 1773.3.10 Information Security Management (Design) . . . . . . . . . . . . . 1863.3.11 Service Continuity Management (Design) . . . . . . . . . . . . . . . 1953.3.12 Service Catalog Management (Design) . . . . . . . . . . . . . . . . . . 2103.3.13 Availability Management (Design) . . . . . . . . . . . . . . . . . . . . . 2173.3.14 Capacity and Performance Management (Design). . . . . . . . . 2233.3.15 Event Management (Operation) . . . . . . . . . . . . . . . . . . . . . . . 2293.3.16 Access Management (Operation). . . . . . . . . . . . . . . . . . . . . . . 2343.3.17 Risk Management (Supporting) . . . . . . . . . . . . . . . . . . . . . . . 2403.3.18 Business Relationship Management (Stragegy) . . . . . . . . . . . 2473.3.19 Service Portfolio Management (Strategy) . . . . . . . . . . . . . . . . 2503.3.20 Demand Management (Strategy). . . . . . . . . . . . . . . . . . . . . . . 2563.3.21 Supplier Management (Design). . . . . . . . . . . . . . . . . . . . . . . . 2583.3.22 Transition Planning and Support (Transition) . . . . . . . . . . . . 2643.3.23 Service Validation and Testing (Transition) . . . . . . . . . . . . . . 2713.3.24 Deployment Management (Transition). . . . . . . . . . . . . . . . . . 2833.3.25 Knowledge Management (Transition). . . . . . . . . . . . . . . . . . . 2863.3.26 Continual Improvement (Supporting) . . . . . . . . . . . . . . . . . . 290

A Abkürzungen und Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Stichwortverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299


5

Geleitwort von Ruedi Noser, Präsident ICTswitzerland (zur ersten Auflage 978-3-658-00180-3)

Die Informationstechnik (IT) ist aus unserer globalisierten und virtuellen Weltnicht mehr wegzudenken. Doch die immer komplexer werdende IT bringt Unter-nehmen auch an den Anschlag und stellt sie vor immense Herausforderungen.Hinzu kommt ein enormer Druck, die Betriebskosten für die IT zu senken, trotzimmer höherer Anforderungen an Verfügbarkeit und Qualität.

Weiter muss sichergestellt werden, dass Entscheidungen auf Kundennutzen,Geschäftsnutzen und Geschäftsprioritäten zugeschnitten sind. Die zentrale Auf-gabe der IT ist es im Allgemeinen, die Geschäftsprozesse bestmöglich zu unter-stützen. Gerade in dienstleistungsorientierten Unternehmen nimmt diese abernoch eine viel zentralere Rolle ein. Vielfach basiert das komplette Geschäftsmodellauf Informations- und Kommunikationstechnologien. Aber auch in der Industriefunktioniert heute kaum noch etwas ohne IT.

Ein Systemausfall oder Absturz in einer solchen Umgebung kann die Arbeit oderProduktion komplett zum Erliegen bringen und hohe Kosten für ein Unterneh-men zur Folge haben. Um dies zu verhindern, hat sich die IT auf das Arbeitsum-feld auszurichten, aber auch das Arbeitsumfeld auf die IT. Auf beiden Seiten sindProzesse im Detail zu definieren und aufeinander abzustimmen. Die IT wirdsomit nicht mehr nur verwaltet, sondern serviceorientiert angeboten. Denn nurmit einem etablierten IT Service Management können die immer höheren Anfor-derungen an Verfügbarkeit und Qualität bei gleichzeitig geringeren Betriebskos-ten erfüllt werden.

Beim Wandel von der Informationstechnik zur Kunden- und Serviceorientierungrichten sich viele Unternehmen an Prozessstandards aus sowie den dazugehöri-gen Best Practices.

Doch obwohl Industriestandards Rahmenempfehlungen für das in der Hauptsacheprozessfokussierte Service Management abgeben, benötigt eine erfolgreiche Im-plementierung die harmonische Annäherung dieser Prozesse an die Unterneh-mensziele wie auch an die drei zentralen Elemente – Mensch, Technologie undLieferant.


Geleitwort von Ruedi Noser, Präsident ICTswitzerland (zur ersten Auflage 978-3-658-00180-3)

6

In diesem Zusammenhang werden vermehrt konkrete Best Practices gewünscht.Doch was bzw. wo sind diese Best Practices?

Basierend auf seinem großen Erfahrungsschatz zeigt Fritz Kleiner im vorliegen-den Handbuch mit einer klaren und verständlichen Weise und vielen Praxisbei-spielen auf, wie IT Service Management ganzheitlich in einer Unternehmungeingeführt, optimiert und betrieben werden kann. Das Buch beinhaltet sehr vielBeratungswissen im Bereich des IT Service Managements, welches die Kundennormalerweise teuer einkaufen müssen.

Das Handbuch hat das Potenzial, zu einem Standardwerk zu werden.

Ruedi NoserPräsident ICTswitzerland1

1 ICTswitzerland ist die Dachorganisation der wichtigsten Verbände und Organisationen des schweizerischen Informatik- und Telekomsektors.


7

Geleitwort von Jürgen Dierlamm, Geschäftsführer itSMF Deutschland e.V. (zur zweiten Auflage)

IT Service Management ist nach wie vor ein Thema für die externen und internenIT-Provider bzw. -Abteilungen der Unternehmen und Behörden. Aus Sicht desitSMF Deutschland e.V. würde ich sagen: Es ist mehr denn je ein Thema! Durchdie Digitalisierung der Abläufe in den Unternehmen kommen mehr und mehrInformatik Services herein, teilweise auch von Cloud-Providern, die direkt von denFachabteilungen beauftragt werden. Wie baue ich Service für IT-Leistungen aufund leiste eine effektive Aufbau- und Ablauforganisation in den Unternehmen?Wir steuere ich mehrere Sourcing-Provider? Wie kann auch technischer Serviceaußerhalb der IT integriert werden? Gerade Letzteres ist durch das Aufkommender Industrie-4.0- und Internet-of-Things-Strategien wichtig geworden.

Ein IT Service Management taugt auch außerhalb der IT. Fast jeder digitale Ge-schäftsprozess kann durch ITSM abgedeckt werden, jedes technische Equipmentkann in eine CMDB aufgenommen werden. ITSM schlägt für Incident und RequestManagement ein Workflow-System vor. Tickets können erfasst, gelöst, weitergelei-tet und eskaliert werden. Es gibt für User, für Services und für technisches Equip-ment Stamm- und Bewegungsdaten sowie digitale Genehmigungen für Anfragen.Damit kann sich der IT-Provider für weit mehr Services als nur für IT in den Unter-nehmen positionieren. Technische Wartung z.B. von Gabelstaplern oder Aufzügen,Services für Firmenwagen, Bestellung von Büromaterial, Kreditanträge, Abläufe imPersonalmanagement: Das sind nur einige Beispiele für Services, die nicht mit ITim bisherigen Verständnis direkt zusammenhängen, aber ähnlich erbracht werdenkönnen. ITSM kann mehr, Geschäftsprozessmanagement auf vielen Ebenen wirdmöglich. Die anderen Prozesse sind mangels Vorgehensmodellen teilweise nicht soreif, wie es ITSM-Prozesse nach einem weitverbreiteten Framework für IT ServiceManagement sind.

Wir streichen das IT in IT Service Management. Helfen wir den Kernprozessendes Unternehmens bzw. der Behörde!

Fritz Kleiner hat das in seinem Buch verstanden und aufgenommen. Es ist mehrals ein gängiges Buch über IT-Prozesse. Dazu kommt, dass nur eine IT mit einerOrganisation nach ITSM in der Lage ist, jederzeit transparent, nachhaltig undprüfbar zu sein. Eine Compliance ist nur mit ITSM-Strukturen denkbar, nur dann


Geleitwort von Jürgen Dierlamm, Geschäftsführer itSMF Deutschland e.V. (zur zweiten Auflage)

8

sind Prozesse dokumentiert, die Tickets nicht mehr änderbar und Bewegungen anden Stammdaten archiviert.

Die Bedeutung der IT für die modernen Unternehmen ist höher denn je, aberwenn sie mit ITSM aufgebaut wird, wird sie diesen Anforderungen auch gerecht.Nur so kann der Wertbeitrag der IT gesteigert werden. Business IT Alignmentheißt das neudeutsche Zauberwort, Sie müssen die Geschäftsprozesse verstehenund abbilden, andernfalls schafft sich die IT durch Sourcing und Cloud Providingselber ab. Der Wertbeitrag muss transparent sein, gleichzeitig muss eine Prüfbar-keit der Services und Prozesse gewährleistet sein.

Wie das geht, ist in diesem Buch hervorragend beschrieben. Ich wünsche viel Spaßbei der Lektüre.

Jürgen Dierlamm Geschäftsführer des IT Service Management Forums (itSMF) Deutschland e.V. und der itSMS GmbH


9

Vorwort (zur ersten Auflage)

Mit diesem Buch fasse ich mein gesamtes Wissen zusammen, das ich über dieletzten 18 Jahre im Consulting-Bereich des IT Service Managements und derOrganisationsveränderung bei Beratungsaufgaben für zahlreiche Kunden imOutsourcing und im Versicherungs-, Banken-, Pharma- und Verwaltungsumfelderworben habe.

Einige Unternehmen lassen ihre Mitarbeiter in einem weitverbreiteten Frame-work für IT Service Management (auch als IT Service Management-Methode,Standardwerk oder Standard-Methode bezeichnet) ausbilden. In der Ausbildungklingt vielfach alles logisch und klar, dennoch haben viele Mitarbeiter Schwierig-keiten bei der Umsetzung und Einführung eines ganzheitlichen IT ServiceManagements und den dazugehörigen Prozessen.

Das hier vorliegende Buch zeigt Ansätze und Möglichkeiten auf, wie ein ganzheit-liches IT Service Management-Modell, das auf vielen Praxisbeispielen basiert, eta-bliert werden kann. Es soll dem Leser helfen, das IT Service Management-»BigPicture« zu verstehen und die benötigten Prozesse erfolgreich zu etablieren. Ineinigen Bereichen dieses Buches wird jedoch von dem oben genannten weitver-breiteten Framework abgewichen, da sich in der Praxis eine andere Umsetzung alsoptimal erwiesen hat oder die Informationen sehr viel Interpretationsspielraumlassen. Dies soll nicht als Kritik an diesem Framework verstanden werden. Ichbefürworte die Verwendung dieses Standardwerks sehr, erst mit diesem Standardwurden die Inhalte und der Umfang der Informatik-Prozesse definiert und imProzessbereich konnte ein gemeinsames Grundverständnis aufgebaut werden.

Falls Sie für sich die Zertifizierung in dieser weitverbreiteten Standard-Methodeanstreben, so empfehle ich Ihnen, die entsprechenden offiziellen Handbücher zuerwerben. Sind Sie jedoch daran interessiert, IT Service Management in IhremUnternehmen zu etablieren oder zu optimieren, so kann dieses Buch für Sie einegroße Hilfe sein.

Im Buch setzte ich eine meiner stärksten Fähigkeiten, nämlich klar zu strukturie-ren, ein, um das umfangreiche Thema »IT Service Management«, das man nicht


Vorwort (zur ersten Auflage)

10

nur auf die Umsetzung von IT-Prozessen reduzieren sollte, dem Leser und derLeserin1 näher zu bringen.

Obschon dieses Buch in deutscher Sprache verfasst ist, verwende ich an einigenStellen englische Begriffe, da diese eine große Verbreitung aufweisen, teilweiseder deutsche Begriff fehlt oder die deutsche Sprache weniger genau ist.

Abschließend bedanke ich mich herzlich bei meiner Partnerin Eva Risler für ihrestetige und liebevolle Unterstützung sowie bei meinen Proof-Readern RegulaWagner, Bert Rotmans, Guido Wenger, Peter Frick, Andreas Bauch, Lubos Mares,Marco Linsenmann und Andreas Gutzwiller sowie bei allen, die mich unterstützthaben.

Ein weiteres großes Dankeschön gilt Ruedi Noser (Version 1.0) für sein persönli-ches Geleitwort und dem gesamten Verlagsteam für die gute Zusammenarbeit beider Publikation.

1 Im Buch verwende ich in den meisten Fällen nur die männliche Form, dies nicht aus dem Grund, die weibliche Leserschaft zu diskriminieren, sondern um die Lesbarkeit des Buches zu vereinfachen.


11

Vorwort (zur zweiten Auflage)

In der zweiten Auflage habe ich einige Prozesse wie z.B. das Service Validationand Testing und das Release Management mit weiteren Beispielen und Informati-onen versehen. Zusätzlich sind die Prozesse des Requirement Managements unddes Deployment Managements als eigenständige Prozesse ergänzt worden. DesWeiteren habe ich aus rechtlichen Gründen die vier Buchstaben, mit denen aufein weitverbreitetes Prozess-Framework für IT Service Management verwiesenwurde, entfernt. Bei der Verwendung in der 1. Auflage war es mir ein Anliegen,auf mögliche Verbesserungsansätze hinzuweisen. Mittlerweile wurden die Rechtean diesen vier Buchstaben an eine Firma übertragen, wodurch leider bei jeder Ver-wendung umgehend eine Lizenzpflicht entsteht. Mit einem erforderlichen Lizenz-vertrag sind für die Autoren bzw. Verwender dieser vier Buchstaben massiveAuflagen verbunden, wie z.B. die Sicherstellung einer Vertretung durch einenenglischen Anwalt, der Abschluss einer zusätzlichen Haftpflichtversicherung(deren Höhe der Lizenzgeber bestimmt) und das unaufgeforderte, quartalsweiseRapportieren über die Verwendung der vier Buchstaben. Das Fehlen dieser vierBuchstaben bringt jedoch inhaltlich keine Nachteile mit sich. Wo erforderlich,bestehen allgemeine Hinweise, die eine Referenz herstellen.

Für die zweite Auflage möchte ich mich ganz herzlich bei meiner Partnerin EvaRisler für ihre Geduld und liebevolle Unterstützung bedanken.

Ein weiteres großes Dankeschön geht an Jürgen Dierlamm für sein persönlichesGeleitwort zur zweiten Auflage sowie an das gesamte Verlagsteam für die guteZusammenarbeit.


13

Kapitel 1

Was beinhaltet IT Service Management?

Um eine gute Übersicht der Informatikdienstleistung zu erlangen, werden im ers-ten Unterkapitel die Hauptdienstleistungselemente einer Informatik beschrieben.Diese Elemente bilden in diesem Buch die Basis, um anschließend das IT ServiceManagement (ITSM) zu beschreiben. Im zweiten Unterkapitel wird auf die Haupt-elemente für ein erfolgreiches IT Service Management eingegangen.

1.1 Hauptdienstleistungselemente einer Informatik

Grundsätzlich kann die Informatikdienstleistung gegenüber dem Informatik-Leis-tungsbezieher (später nur noch Leistungsbezieher genannt) in fünf Hauptdienst-leistungselemente unterteilt werden (siehe Abbildung 1.1).

Abb. 1.1: Hauptdienstleistungselemente der IT

� Managed-ArbeitsplatzUnter dieses Element fallen alle Informatikdienstleistungen, die im Bereichdes Arbeitsplatzes und den erweiterten Komponenten liegen, z.B. Arbeitsplatz,lokales Drucken, mobile Geräte. Diese werden benötigt, um die Geschäftspro-zesse des Unternehmens und die dazugehörigen Geschäftsanwendungen zunutzen und zu bedienen.

� Managed-AnwendungenUnter dieses Element fallen alle Geschäftsanwendungen, die der Erreichungder Unternehmensziele und deren Zweck dienen, wie z.B. Finanzportfolio-Management, Bankschalterabwicklung, Produktionsplanung, Versicherungs-


Kapitel 1Was beinhaltet IT Service Management?

14

berechnung, die dem Leistungsbezieher zur Verfügung gestellt werden. Damitdie Anwendungen genutzt werden können, braucht es darunterliegende Infor-matikkomponenten und die dazugehörigen Informatikdienstleistungen.

� AnwendungsentwicklungZentrale Aufgabe der Anwendungsentwicklung ist die Neu- und Weiterent-wicklung der Geschäftsanwendungen. In der heutigen Zeit werden in vielenBereichen Standardanwendungen eingesetzt, was den internen Aufwand inder Anwendungsentwicklung stark reduziert.

� InformatikberatungDieses Element beinhaltet verschiedene Beratungsleistungen, die durch dieInformatik erbracht werden. Dies können Strategien für die Nutzung vonneuen Medien wie z.B. Social Media oder Geschäftsoptimierungsmöglichkei-ten sein, die mittels der Informatik realisiert werden können.

� InformatikschulungUnter dieses Element fallen alle Schulungsaktivitäten, die vom Leistungser-bringer für die Leistungsbezieher angeboten werden. Dies können Schulungenim Bereich der Informatikgrundausbildung, Bürokommunikationskomponen-ten wie Textverarbeitung, Tabellenkalkulation oder auch Nutzung derGeschäftsanwendungen sein.

In diesem Buch stehen die beiden ersten Elemente, »Managed-Arbeitsplatz« und»Managed-Anwendungen« in der IT Service Management-Betrachtung im Vorder-grund.

1.2 Hauptelemente für ein erfolgreiches IT Service Management

Unternehmen, die erfolgreich IT Service Management umsetzen, haben die fol-genden fünf wichtigsten Elemente etabliert (siehe Abbildung 1.2).

Dieser Regelkreis stellt sicher, dass die Informatikdienstleistungen auf die Kun-denbedürfnisse abgestimmt sind. Mittels einer Standardisierung des IT-Dienst-leistungsangebots wird auf der einen Seite die Komplexität der IT reduziert undauf der anderen Seite die Basis für ein vereinfachtes Kosten-Management gelegt.

Der Einsatz von IT-Prozessen ermöglicht eine konstante Leistungserbringung.Das Messen von Service- und Prozess-Kennzahlen stellt eine frühzeitige Erken-nung von Abweichungen sicher. Falls nötig, wird das Angebot laufend angepasst,um die Qualität und die entsprechenden Kosten zu optimieren.


1.2Hauptelemente für ein erfolgreiches IT Service Management

15

Abb. 1.2: Regelkreis für ein erfolgreiches IT Service Management

In den nächsten Kapiteln wird auf die fünf Hauptelemente noch vertieft einge-gangen.

1.2.1 Wissen, was der Leistungsbezieher braucht und erwartet

Die Kundenanforderungen zu kennen, ist ein sehrwichtiger Schlüssel eines erfolgreichen IT ServiceManagements.

Die Erfahrung aus verschiedenen Mandaten lässt hier-bei Folgendes erkennen:

� Es fällt Informatikvertretern immer wieder schwer,mit dem Leistungsbezieher zu sprechen.

� Wenn ein Gespräch erfolgt, versteht der Leistungsbezieher häufig das »Fach-chinesisch« des Informatikmitarbeiters nicht.

� Der Informatikmitarbeiter, der die Schnittstelle zum Kunden wahrnimmt, hatzu wenig Kenntnisse vom Geschäft des Leistungsbeziehers.

Grundsätzlich können die Anforderungen des Leistungsbeziehers in zwei Berei-che aufgeteilt werden.

1. Funktionale Anforderungen (teilweise auch Utility genannt)Wie aus der Bezeichnung abzuleiten ist, definieren die funktionalen Anforde-rungen die Funktionen einer Anwendung oder einer ganzen Lösung. Diesewerden benötigt, um die Leistung gegenüber den Firmenkunden zu erbringen,wie z.B. Buchungsvorgang verarbeiten, Kundendaten eingeben und pflegen,



16

Versicherung berechnen, Kundenanliegen am Bankschalter abwickeln, Pro-duktionsplanung.

2. Nicht funktionale Anforderungen (teilweise auch Warranty genannt)Nicht funktionale Anforderungen sind Leistungsanforderungen oder Quali-tätsmerkmale. Diese definieren z.B. den Zeitraum, in dem die IT-Dienstleis-tungen zur Verfügung stehen, oder die Verfügbarkeit der Anwendungen oderBusiness IT Services.

Auf die nicht funktionalen Anforderungen wie z.B. Service Levels wird imAbschnitt 3.3.1, »Service Level Management (Design)« weiter eingegangen, dasie ein wichtiges Element einer Service-Vereinbarung bilden.

1.2.2 Standardisierung der IT-Dienstleistungen

Um die Komplexität der Services im Informati-kumfeld zu vereinfachen, wird empfohlen, zweiArten von Services zu unterscheiden:

1. Business IT Services (businessorientiert)

2. IT Services (IT-orientiert)

Business IT Services

Es ist sinnvoll, die IT-Dienstleistungen, die dem Leistungsbezieher (Business) ange-boten werden, basierend auf »Business IT Services« zu strukturieren, da so zusam-menhängende Geschäftsfunktionalitäten, die durch verschiedene Geschäftsanwen-dungen unterstützt werden, berücksichtigt werden können.

Ein Business IT Service ist eine IT-Dienstleistung, die beim Leistungsbezieher alsLieferelement ersichtlich ist und von ihm konsumiert wird. Dieses basiert aufeinem vereinbarten Preis pro Leistungselement, der Erbringung der nötigen funk-tionalen Anforderungen zu einer definierten Qualität und Quantität. Die BusinessIT Services werden grundsätzlich als Angebote im Service-Katalog für die Leis-tungsbezieher beschrieben. Für die Erbringung der Business IT Services sind ver-schiedene, untergeordnete IT Services wie z.B. Plattform IT Services, Netzwerk-ITServices, Anwendungs-IT Services nötig.

In den Handbüchern eines weitverbreiteten Frameworks für IT Service Manage-ment werden die Business IT Services meist nur als Business Services bezeichnet.Die Erfahrung aus der Beratungs-Praxis zeigt jedoch, dass dies nicht ganz optimalist, da ein Business-Service grundsätzlich mehr als nur IT-Aspekte enthalten kann.



17

Für ein besseres Verständnis ein Beispiel aus dem Versicherungsbereich.

Der Business Service »Versicherung-Schadensabwicklung« beinhaltet neben derInformatikleistung (Business IT Service »Schadensabwicklung«) auch Dienstleis-tungen, die nicht IT-orientiert sind wie z.B. die Zurverfügungstellung eines Fahr-zeugs (mit einer Funktionalität und qualitativen Merkmalen wie Wartung,Betankung des Fahrzeugs etc.) für den Versicherungsberater. Aus diesem Grundwird in diesem Buch der Begriff Business IT Service für IT-orientierte Dienstleis-tungen verwendet, die die Leistungsbezieher (Business) nutzen.

Um das Verständnis der Business IT Services zu vertiefen, wird Abbildung 1.1 ver-wendet und entsprechend weiter ergänzt (siehe Abbildung 1.3).

Abb. 1.3: Business IT Service »Managed-Arbeitsplatz«

Im Hauptelement »Managed-Arbeitsplatz« sind mögliche Business IT Serviceswie z.B. Arbeitsplatz-Service, E-Mail Service aufgeführt. Diese Gruppe von Ser-vices bildet einen Basisdienstleistungsumfang, der erlaubt, Business IT Servicesaus dem Hauptelement »Managed-Arbeitsplatz« zu nutzen.

Ein Arbeitsplatz-Service kann aus verschiedenen Optionen bestehen. Für jedeOption sind unterschiedliche Service Level-Aspekte definiert.

Optionen-Beispiel aus dem Bankenumfeld:

� Option: Desktop Standard

� Option: Desktop mit hoher Sicherheit

� Option: Desktop Trader

� Option: Desktop High End

� Option: Thin-Client

� Option: Laptop Standard

� Option: Laptop mit hoher Sicherheit

Die verschiedenen Optionen sind branchen- oder kundenabhängig. Es gibt Kun-den, die aus jeder Option einen eigenen Business IT Service im Bereich der Ar-



18

beitsplatz-Services entwickeln. In diesem Fall werden die Service Levels auf Stufedes entsprechenden Business IT Service und nicht auf der Stufe der Optionen de-finiert. Die Erstellung des SLA erfolgt auf der Stufe des Business IT Service.

Im Hauptelement »Managed-Anwendungen« sind mögliche Business IT Serviceswie z.B. E-Banking, Counter Service, Treasury etc. im Bankenumfeld möglich.Diese Business IT Service-Gruppe basiert auf den Geschäftsanwendungen. Fürjeden Business IT Service wird auch hier ein entsprechendes Service Level Agree-ment (SLA) mit dem Leistungsbezieher abgeschlossen (siehe Abbildung 1.4).

Abb. 1.4: Business IT Service »Managed-Anwendungen«

Viele Unternehmen haben keine Business IT Services etabliert. Die SLAs werdenvielfach je Geschäftsanwendung abgeschlossen. Dies ergibt bei mittleren und gro-ßen Unternehmen eine sehr große Anzahl von SLAs, was zu einer sehr aufwendi-gen Überwachung führt. Zusätzlich sind oft verschiedene Geschäftsanwendungenvoneinander abhängig, was in den einzelnen SLAs nur bedingt berücksichtigt wer-den kann.

Mit einer Gruppierung der Geschäftsanwendungen zu Business IT Services kanndie Komplexität besser beherrscht werden. Grundsätzlich bieten sich drei ver-schiedene Gruppierungsmöglichkeiten an:

� Basierend auf den Geschäftsprozessen oder -Subprozessen

� Basierend auf den Geschäftsfunktionen oder -Subfunktionen

� Basierend auf den Geschäftsprodukten; z.B. in der Produktion von Waschma-schinen, werden drei unterschiedliche Produktgruppen unterschieden:

� Waschmaschinen für Wohnungen/Einfamilienhäuser

� Waschmaschinen für Mehrfamilienhäuser

� Waschmaschinen für Textilreinigungen

In der Praxis kann es auch zu einem Mix von Business-Prozessen und -Funktionkommen. Natürlich wird die Bildung der Business IT Services auch von »nichtfunktionalen Anforderungen« und den darunterliegenden IT Services teilweisebeeinflusst.



19

IT Services

Verschiedene IT Services sind nötig, um die Business IT Services zu erbringen.Die IT Services sind so ausgelegt, dass die Anforderungen der Business IT Ser-vices unterstützt werden. Grundsätzlich sind diese IT Services im Gegensatz zuden Business IT Services für den Leistungsbezieher nicht direkt ersichtlich (sieheAbbildung 1.5).

Abb. 1.5: Gruppenübersicht IT Services

Um eine vereinfachte Darstellung dieser IT Services zu ermöglichen, wird emp-fohlen, auch sie in verschiedene Gruppen zu unterteilen. Die Grundidee der Glie-derung basiert auf einer Architektur der IBM, die »Global Infrastructure Refe-rence Architecture« genannt wird.

In Abbildung 1.5 werden fünf Gruppen von IT Services unterschieden:

� G1: Basis-IT ServicesIn dieser Gruppe befinden sich Datacenter IT Services, Network-IT Services,Storage IT Services und Plattform IT Services. Diese bilden, wie der Name kenn-zeichnet, die Grundvoraussetzung für die darüber liegenden IT Services.

� G2: Erweiterte IT ServicesDies ist die größte Gruppe der IT Services. Zu ihr gehören z.B. Mail IT Ser-vices, Database IT Services oder Print IT Services. Diese IT Services bauen aufden Basis-IT Services auf.

� G3: Anwendungsorientierte IT ServicesUnter diese Gruppe fallen zwei Arten von IT Services: Application-Maintenance& -Support (Geschäftsanwendungs-Wartung und -Unterstützung) sowie Applica-tion Development (Anwendungs-Entwicklung).

Leistungsbezieher

Business IT Service-Gruppen

Managed-Arbeitsplatz

Managed-Anwendungen

Anwendungs-entwicklung

Informatik-beratung

Informatik-schulung

E-Banking Counter Treasury …Arbeitsplatz-Service

E-Mail Service

Mobility Service

Arbeitsplatz-Druck-Service

Business IT Services

vice

s

End User IT Services

Application Maintenance & -Support IT Services

Application Development IT Services G3

Service Desk IT Services G4

& M

onito

ring

IT S

erv

File IT Services Print IT Services

Pl tf IT S i

Mail IT Services

Content Mgmt. IT Services Database IT ServicesDocument Mgmt. IT Services Citrix Infrastructure IT Services

Transaction IT ServicesIntegration IT Services Web Transaction IT ServicesDirectory IT Services

Web-Basis-IT Service

IT Services(Gruppen-übersicht) …Naming IT Service ……

G2

ecur

ity IT

Ser

vice

s

Even

t &

Network IT Services

Storage IT Services

Platform IT Services

Datacenter IT Services

G1

Se

G5G5



20

� G4: End-User-orientierte IT ServicesIn dieser Gruppe sind End-User-(Arbeitsplatz-)bezogene IT Services sowie Ser-vice Desk IT Services zu finden.

� G5: Unterstützende IT ServicesDiese Gruppe besteht aus Event-and-Monitoring-IT Services sowie aus SecurityIT Services.

Die Praxis aus verschiedenen Schulungen und Beratungsmandaten lässt erken-nen, dass das Verständnis von IT Services und ihre Zusammensetzung zu Busi-ness IT Services sehr schwer fällt. Darum möchte ich mich diesem Thema etwasvertieft widmen.

Jeder IT Service enthält zwei oder drei der folgenden Elemente:

� Hardwarekomponente A Darunter fallen z.B. Server-System, Netzwerkkompo-nenten, Speicherkomponenten oder Rechenzentrumsgebäude.

� Softwarekomponente A In der Gruppe G2 der IT Services ist dies in den meis-ten Fällen eine Middleware-Komponente wie z.B. eine Datenbank, eine Über-wachungs-Software, eine Firewall-Software. In der Gruppe G3 werden hier diedafür notwendigen Geschäftsanwendungen aufgeführt.

� IT-Dienstleistung A Um aus einer Hardware- und/oder Software-Komponenteeinen IT Service zu bilden, ist immer eine IT-Dienstleistung nötig, die internoder auch extern erbracht werden kann. Dies kann z.B. im Plattform-Bereichdie Installation und Wartung eines Windows-»High Available/High Perfor-mance«-Servers sein.

Damit ein Business IT Service einer globalen Versicherungsgesellschaft, wie z.B.die »Schadensabwicklung« mit den Service Levels (Service-Zeit 7×24 Stundenweltweit verfügbar, Verfügbarkeit 99,6%, Reaktionszeit <1 Sekunde bei der Scha-densabfrage-Funktion) gewährleistet werden kann, sind folgende darunterlie-gende IT Services nötig:

� Event and Monitoring IT Service 7×24 Stunden (aller Komponenten wie z.B.Geschäftsanwendungen, Mail-Schnittstellen, Sicherheitskomponenten, Server,Storage, WAN/LAN, USV)

� Wartungs- und Support IT Service für Schadensabwicklungs-Software-Module(dieser ist nötig, falls während des Betriebs Störungen in der Software auftre-ten und das Command Center, das den »Event and Monitoring IT« erbringt,den Event oder den resultierenden Incident nicht mit den zur Verfügung ste-henden Wiederanlaufprozeduren lösen kann)

� E-Mail Boudary IT Service inkl. 7x24 Stunden 2nd Level Support (für das Ver-senden von Bestätigungs-Mails im Schadenfall, falls der Versicherungsnehmereine E-Mail-Adresse im Kundenstamm hinterlegt hat)

� Unix IT Service High Available/High Performance inkl. 7x24 Stunden 2ndLevel Support



21

� Online Storage SAN IT Service High Performance inkl. 7x24 Stunden 2ndLevel Support

� WAN IT Service High Performance mit Backup-Leitung inkl. 7x24 Stunden2nd Level Support

� LAN IT Service High Performance inkl. 7x24 Stunden 2nd Level Support

� Sicherheitsrechenzentrum-IT Service mit USV und Backup-Anschluss inkl.7x24 Stunden 2nd Level Support

� weitere IT Services aus dem Bereich »Erweiterte IT Services« sind nötig, wer-den aber nicht aufgelistet, um die Darstellung zu vereinfachen.

Mittels einer Pyramidendarstellung kann sehr gut der Zusammenhang zwischenden Business IT Services, die gegenüber dem Leistungsbezieher ersichtlich sind,und den verschiedenen darunterliegenden IT Services aufgezeigt werden (sieheAbbildung 1.6).

Abb. 1.6: Dekomposition Business IT Service zu IT Services

Aus dieser Service-Dekomposition wird ersichtlich, wie die einzelnen Services inVerbindung stehen.



22

In einer Configuration Management-Datenbank werden die Verbindungen derBusiness IT Services zu den IT Services sowie zu der physischen Hardware oderauch Software dargestellt. In Abschnitt 3.3.3, »Service Asset and ConfigurationManagement (Transition)« wird vertieft auf die Verbindung zwischen den Busi-ness IT Services, IT Services und den IT-Komponenten eingegangen.

Für jeden IT Service oder seiner Option (falls diese vorhanden ist) werden klarmessbare Qualitätsmerkmale definiert. Analog zu den Service Levels auf Stufe derBusiness IT Services wird in diesem Buch auch auf Stufe der IT Services derBegriff Service Levels verwendet. Falls dieser Begriff auf der Stufe der IT Servicesnicht erwünscht ist, so kann eine andere Bezeichnung, wie z.B. Quality of Serviceoder Operational Level verwendet werden.

Um ein besseres Verständnis von möglichen Service Levels auf Stufe der IT Ser-vices zu bekommen, ist hier ein Beispiel eines IT Service aus dem BereichWindows Platform aufgeführt.

In diesem Beispiel (siehe Tabelle 1.1) werden die Service Levels auf der Option»High Available/High Performance« des IT Service definiert.

Service Level (SL) Zielwert (SL Target)

Service-Zeit (Service Time) des 2nd Level Supports 7 × 24 Stunden

Verfügbarkeit (Availability) pro Monat 99,9%

Leistung (Performance) Multi-Prozessor

Maximale nicht geplante Events pro Monat 1

Maximale nicht geplante Events pro Jahr 4

Reaktionszeit (Reaction Time) für den 2nd Level Support

A Entfernt (Remote)

A Vor Ort

15 Minuten

30 Minuten

Reparaturzeit (Lieferant stellt Ersatzkomponenten zur Verfü-gung.)

Max. 8 Stunden

Skalierbarkeit (Scalability) Zusätzliche 10 TB Platten-speicher stehen in 5 Ar-beitstagen zur Verfügung

IT-Notfallvorsorge (IT Disaster Recovery) Recovery Time Objective (RTO)a = 4 Stunden

Recovery Point Objective (RPO)b 30 Minuten

a. Bei Recovery Time Objective (RTO) handelt es sich um die Zeit, die vom Zeitpunkt des Ausfalls bis zur vollständigen Wiederherstellung des Business IT Service vergehen darf.

b. Bei Recovery Point Objective (RPO) handelt es sich um die Zeitdauer zwischen zwei Sicherun-gen. Dieser Zeitraum definiert somit den maximal hinnehmbaren Datenverlust. Ist kein Daten-verlust erwünscht, so beträgt der RPO null Stunden.

Tabelle 1.1: Service Levels eines IT Service



23

Die angegebenen Werte sind Beispiele und grundsätzlich von Unternehmen zuUnternehmen unterschiedlich. Es sind auch verschiedene andere Service Levelsvorstellbar wie z.B. sicherheitsrelevante Service Levels. Grundsätzlich empfiehlt essich, beim Aufbau von IT Services in einer ersten Phase nur die wichtigsten Ser-vice Levels zu definieren, da diese definierten Werte auch entsprechend überwachtwerden müssen. Es ist auch darauf zu achten, dass die Service Levels gemessenwerden können.

Sind für die entsprechenden IT Services alle wichtigen Service Level-Werte defi-niert, so können basierend auf den Anforderungen des Business IT Service (imSLA festgehalten, z.B. Service-Zeit 7×24 Stunden mit einer Verfügbarkeit von99,5% pro Monat) und der benötigten Architektur die entsprechenden IT Servicesmit ausreichend hohen Service Levels selektiert werden.

Wenn alle involvierten IT Services nur eine Verfügbarkeit von 99,5% pro Monataufweisen, so ergibt sich auf Stufe des Business IT Service eine massiv tiefere Ver-fügbarkeit von 97% bei einer End-to-End-Betrachtung1.

In unserem vereinfachten Beispiel sind sechs IT Services (ohne Redundanzen)mit je einer Verfügbarkeit von 99,5% pro Monat bei einer Service-Zeit von 7×24Stunden für die Erbringung der Business IT Services involviert:

1. Rechenzentrum (RZ)

2. Wide Area Network (WAN)

3. Local Area Network (LAN)

4. Online Storage (SAN)

5. Virtueller Unix-Server (Virt. Unix-Serv.)

6. Business-Anwendung xxx (Bus.-Anw.)

Bei einer Service-Zeit von 7×24 Stunden ergeben sich bei 31 Tagen für den MonatJanuar insgesamt 744 Betriebsstunden.

Basierend auf dieser Service-Zeit und einer Verfügbarkeit von 99,5% pro Monatergibt sich eine maximal mögliche Ausfallzeit von drei Stunden und 43 Minuten(dies entspricht 0,5% von 744 Stunden) pro IT Service, ohne die Vereinbarung zuverletzen. Fallen nun die einzelnen IT Services nicht gleichzeitig, sondern nachei-nander bis zur maximal möglichen Toleranz aus, so ergibt sich in einer End-to-End-Betrachtung eine Gesamtausfallzeit von 22 Stunden und 18 Minuten (6 mal 3Stunden 43 Minuten)

Grafisch stellt sich dies wie in Abbildung 1.7 dar.

1 Bei einer End-to-End-Betrachtung werden alle IT Services aufgeführt, die für die Erbringung des Business IT Service nötigt sind. Fällt einer dieser IT Services aus, so steht der Business IT Service für den Leistungsbezieher nicht zur Verfügung.



24

Abb. 1.7: Darstellung von Ausfällen basierend auf verschiedenen IT Services

Dies entspricht auf Stufe des Business IT Service bei einer Service-Zeit von 7×24Stunden einer Verfügbarkeit von 97% im Monat Januar.

Berechnung:

22,3 Std. / 744 Std. * 100% = 2,997% A gerundet 3% Nichtverfügbarkeit imMonat Januar. Daraus ergibt sich eine effektive Verfügbarkeit des Business IT Ser-vice von 97%.

Dieses Beispiel zeigt auf, dass die Verfügbarkeit der einzelnen IT Services immerhöher sein muss als die Verfügbarkeit auf Stufe des Business IT Service.

1.2.3 Etablieren der nötigen IT-Prozesse inklusive der Rollen

Für den Aufbau von Prozessen gibt es verschiedeneFrameworks/Standards. Grundsätzlich macht eskeinen großen Unterschied, für welches IT-Prozess-Framework oder welchen -Standard sich die Unter-nehmung entscheidet, wichtig ist, dass die IT-Prozesse mit einer Management-Unterstützungeingeführt werden und mittels eines IT-Prozess-Managements/einer -Governance etabliert werden.

Doch welche IT-Prozesse sind nötig? Für ein einfa-cheres Verständnis ist es sinnvoll, die Prozesse

nach ihrer Zugehörigkeit in die Stufen eines Service Life Cycles (Strategy, Design,Transition, Operation und Supporting) zu gruppieren (siehe Abbildung 1.8).

Abb. 1.8: Stufen eines Service Life Cycles

Wo immer möglich, sollte der entsprechende IT-Prozess durch Tools oder Hilfs-mittel unterstützt werden. Die Nutzung der IT-Prozesse durch die Anwender (Rol-lenträger der einzelnen IT-Prozesse) ist in Firmen, die Tools mit Workflow-



25

Unterstützung eingesetzt haben, erfahrungsgemäß am besten gewährleistet. Invielen Fällen können die benötigten Prozessmesskennzahlen aus den Tools erho-ben werden.

Gruppe: Strategy

� Business Relationship ManagementDer Business Relationship Management-Prozess kümmert sich um dasManagement der IT-Stakeholder sowie die Entgegennahme von Kundenrekla-mationen.

� Requirement ManagementIm Requirement Management werden die Bedürfnisse der Leistungsbezieherin Anforderungen (Requirements) umgewandelt und geprüft, ob sie realisiertwerden. Bei einer Realisierung erfolgt die Zuteilung des Requirements zueiner entsprechenden Umsetzungsart, z.B. ein Projekt, oder das Requirementwird einem Release zugeordnet.

� Service Portfolio ManagementDer Service Portfolio Management-Prozess stellt sicher, dass die Entwicklun-gen und Investitionen in neue oder bestehende Business IT Services und diedarunterliegenden IT Services entlang markwirtschaftlichen Kriterien erfol-gen. Basierend auf verschiedenen Portfolio-Darstellungen kann das Manage-ment strategische Entscheidungen treffen. Zusätzlich empfiehlt es sich, dassauch die lancierten IT-Projekte mittels des Service Portfolio Management-Pro-zesses überwacht werden.

� Financial Management for Services Der Financial Management for Services-Prozess bildet einen wichtigen Bau-stein im Bereich des IT Service Managements, da er alle Finanzinformationenfür die Planung, Realisierung und Verrechnung von Business IT Services undIT Services zur Verfügung stellt. Diese Finanzinformationen können beigezo-gen werden, um neue Anforderungen basierend auf einer Kosten-Nutzen-Überlegung zu prüfen. Als Beispiel kann es sich um Erweiterung der Service-Zeit eines Business IT Service von bisher 5x10 Stunden auf neu 7×24 Stundenhandeln. Mit dieser neuen Anforderung wird grundsätzlich der Business ITService teurer, da darunterliegende IT Services oder IT Service-Optionen ausge-tauscht werden müssen, um die neue Anforderung zu erfüllen. Somit sollten,falls es sich nicht um eine rein strategische Entscheidung des Unternehmenshandelt, die Mehreinnahmen des Unternehmens bei einem 7×24-Stunden-Betrieb die Zusatzkosten decken, die durch die Erweiterung des Business ITService entstanden sind.

In vielen Unternehmen basieren diese Überlegungen heute noch nicht auf die-sem Kosten-Nutzen-Vergleich. Bei einem stetigen IT-Kostendruck wird dies inZukunft vermehrt erforderlich werden.



26

� Demand ManagementDer Demand Management-Prozess hat zum Ziel, den Bedarf des Leistungsbe-ziehers zu verstehen, zu welchem Zeitpunkt die einzelnen Services genutzt wer-den. Basierend auf dieser Information wird eine entsprechende Verbrauchs-/Bedarfsplanung erarbeiten. Diese Angaben werden anderen Prozessen, im Spe-ziellen dem Capacity and Performance Management zur Verfügung gestellt.

Gruppe: Design

� Service Level Management und Operational Level ManagementDer Service Level Management-Prozess stellt sicher, dass die Informatikdienst-leistungen (Business IT Services) mit dem Leistungsbezieher entsprechendverhandelt werden und die Resultate in einem Service Level Agreement (SLA)festgehalten werden. Zusätzlich überwacht der Prozess die vereinbarten Ser-vice-Ziele (Service Levels) der einzelnen SLAs und rapportiert diese periodischgegenüber dem Leistungsbezieher. Bei Nichteinhaltung der Service Levels oderbeim Verdacht auf mögliche zukünftige Verletzungen leitet der Prozess inZusammenarbeit mit den Umprozessen nötige Maßnahmen zur Behebungein. Basierend auf einem weitverbreiteten Framework für IT Service Manage-ment gehören in diesen Prozess auch die Erstellung von Operational LevelAgreements (OLAs) bei einer internen Service-Erbringung oder UnderpinningContracts (UCs) bei einer externen Erbringung. Grundsätzlich werden dieOLAs und UCs mit der entsprechenden IT-Lieferorganisation, basierend aufden definierten IT Services, abgeschlossen.

Aus verschiedenen Mandaten zeigt sich, dass die Etablierung eines eigenstän-digen Prozesses »Operational Level Management« sinnvoll sein kann, da dieRollen für den Operational Level Management-Prozess anders zu besetzensind als für den Service Level Management-Prozess. In Abschnitt 3.3.1, »Ser-vice Level Management (Design)« wird näher auf dieses Thema eingegangen.

� Service Catalog ManagementDer Service Catalog Management-Prozess hat die Entwicklung und Wartungeines entsprechenden Service-Katalogs zum Ziel. Zusätzlich stellt der Prozesssicher, dass der Inhalt des Service-Katalogs immer auf einem aktuellen Standgehalten wird. Es ist sinnvoll, in diesem Katalog beide Arten von Services, dieBusiness IT Services (Sicht Leistungsbezieher) und die IT Services (IT-interneSicht) zu verwalten. Zusätzlich stellt sich auch die Frage, ob der Katalog ebensoim Rahmen des Request Fulfillment-Prozesses zum Abrufen von Standardauf-trägen genutzt werden kann. In Abschnitt 3.3.12, »Service Catalog Manage-ment (Design) wird vertieft auf dieses mögliche Zusammenspiel eingegangen.

� Capacity and Performance ManagementDer Capacity and Performance Management-Prozess stellt sicher, dass ausrei-chend Kapazität und Leistung für die gegenwärtigen und zukünftigen Anforde-rungen zur Verfügung stehen. Zusätzlich erstellt er alle nötigen Kapazitäts-



27

und Leistungs-Kennzahlen, die, basierend auf Service Level Agreement, rap-portiert werden müssen.

� Availability ManagementDer Availability Management-Prozess stellt sicher, dass die geforderte Verfüg-barkeit entsprechend den vereinbarten Verfügbarkeits-Service Levels eingehal-ten wird. Zusätzlich erstellt er die Verfügbarkeitskennzahlen, die, basierendauf Service Level Agreement, rapportiert werden müssen.

� Service Continuity ManagementDer Service Continuity Management-Prozess stellt sicher, dass die geschäftskri-tischen Business IT Services auch in einem Disaster-Fall (Katastrophe) zur Ver-fügung stehen. Mittels regelmäßigen Tests wird dies entsprechend überprüft,um die im SLA vereinbarten katastrophenrelevanten Service Levels bestmög-lich sicherzustellen.

� Information Security ManagementDer Information Security Management-Prozess stellt sicher, dass die IT-rele-vanten Sicherheitsrichtlinien und -Weisungen des Unternehmens umgesetztund eingehalten werden.

� Supplier ManagementDer Supplier Management-Prozess überwacht alle externen Lieferanten (Sup-plier) und steuert entsprechend die Verträge (auch als Underpinning Contracts»UC« bezeichnet).

Gruppe: Transition

� Transition Planning and SupportDer Transition Planning and Support-Prozess beinhaltet alle Prozesselemente,die für die Planung und Koordination der Veränderungen im IT-Umfeld nötigsind.

� Change ManagementDer Change Management-Prozess stellt sicher, dass Veränderungen auf kont-rollierte und zu diesem Zeitpunkt nachvollziehbare Art von der Entwicklung inden Betrieb übergehen. Dies wird i.d.R. mit einer Risikobewertung, Priorisie-rung, Planung, Roll Back/Back Out-Möglichkeit sowie mit Tests und einer ent-sprechenden Dokumentation gewährleistet.

� Service Asset and Configuration ManagementDer Service Asset and Configuration Management-Prozess verwaltet alle Confi-guration Items (CIs), vom Business IT Service bis zum Rechenzentrum. AlleInformationen werden in der Configuration Management Data Base (CMDB)oder auch in Federated CMDBs entsprechend aktuell aufgeführt.

� Release ManagementDer Release Management-Prozess ist verantwortlich für die Planung von ver-schiedenen Releases. Dies bedeutet die Bündelung von einzelnen Changes zu



28

Releases inklusive der Überprüfung der Testresultate sowie den Anstoß derVerteilung und Produktivsetzung.

� Deployment ManagementDer Deployment Management-Prozess stellt sicher, dass alle veränderten IT-Elemente, z.B. Programm-Codes, auf den entsprechenden Zielsystemen kor-rekt verteilt werden.

� Service Validation and TestingDer Service-Validation-and-Testing-Prozess stellt sicher, dass alle Veränderun-gen entsprechend ihrer Größe, Komplexität etc. getestet werden und den An-forderungen entsprechen.

� Knowledge ManagementDer Knowledge Management-Prozess stellt sicher, dass das Informatikwisseneffizient und aktuell verfügbar ist, um z.B. Störungen so schnell wie möglichzu beheben oder Events (Ereignisse) optimal zu beurteilen. Mittels eines effizi-enten Knowledge Managements können die Aufwände für Störungsbehebung,Störungsprävention oder Ereigniserkennung stark gesenkt werden. Zusätzlichkann das Knowledge Management auch dem Informatik-Management wich-tige Informationen für strategische Entscheidungen zur Verfügung stellen.

Gruppe: Operation

� Event ManagementDer Event Management-Prozess stellt sicher, dass alle wichtigen Events (Vor-fälle) erkannt, bewertet und entsprechend behandelt werden. Falls nötig, wirddie Schnittstelle zum Incident Management-Prozess sichergestellt.

� Incident ManagementDer Incident Management-Prozess hat zum Ziel, die Störung so schnell wiemöglich zu beheben, sodass die Auswirkung auf den betroffenen Business ITService minimiert wird.

� Problem Management Der Problem Management-Prozess bezweckt, das wiederholte Auftreten vonIncidents mittels proaktiven Maßnahmen zu vermeiden. Zusätzlich wird dieErmittlung der Root Causes (Hauptursache/Grundursache) eines Incidentsunterstützt.

� Request FulfillmentDer Request Fulfillment-Prozess bearbeitet standardisierte/vereinbarte Auf-träge größtenteils benutzer-/arbeitsplatzorientiert. Dies können auch automa-tisierte Aufträge wie z.B. Software-Verteilung auf eine Arbeitsstation sein.

� Access ManagementDer Access Management-Prozess regelt die Autorisierung basierend auf denVorgaben des Information Security Management-Prozesses und stellt den Leis-



29

tungsbeziehern die nötigen Zugriffsrechte auf die Business IT Services undderen Daten zur Verfügung. Auch IT-interne Zugriffsrechte werden über diesenProzess entsprechend geregelt.

Gruppe: Supporting

� Risk ManagementDer Risk Management-Prozess stellt sicher, dass in allen Life Cycle-Stufen dieRisiken innerhalb der IT identifiziert, bewertet, verringert/vermieden undüberwacht werden.

� Continual ImprovementDer Continual Improvement-Prozess beinhaltet verschiedene Prozessschrittefür die fortlaufende Verbesserung und/oder Optimierung der Service-Erbrin-gung. Er kann sowohl als separater Prozess als auch als Teilprozess in den ein-zelnen Prozessen erfolgen.

Rollen innerhalb der IT-Prozesse

Jeder IT-Prozess basiert auf verschiedenen Aktivitäten, die einzelnen Prozessrol-len, wie z.B. Change Manager oder Change Assignee im Change Managementoder Incident Analyst oder Incident Queue Manager im Incident Management,zugeordnet sind. Die entsprechenden Prozessrollen werden den IT-Mitarbeiternzugeteilt. Es ist sinnvoll, verschiedene Gruppen von Prozessrollen zu Funktionenzusammenzufassen (siehe Abbildung 1.9).

Abb. 1.9: Prozessrollen zu Funktion zusammengefasst

Ist die Funktion des Mitarbeiters in einer Human-Resources-(HR-)Anwendunghinterlegt, so kann über diese Funktion mit den dazugehörigen Prozessrollen ein



30

entsprechendes Qualifikations- und/oder Stellenprofil für die verschiedenen Mit-arbeiter erstellt werden. Dies kann im Speziellen für neue Mitarbeiter oder wennsich einzelne Prozessabläufe geändert haben, sehr dienlich sein.

Mit der Bildung von prozessrollenbasierten Funktionen kann die Komplexität derRollenzuteilung stark vereinfacht werden.

Zur Veranschaulichung dient Abbildung 1.10.

Abb. 1.10: Zuweisung der Funktion zu IT-Mitarbeitern

In vielen Unternehmen sind die IT-Prozesse, Prozessaktivitäten und die Prozess-rollen im Prozess-Management-Tool abgelegt. Die Funktionen können grundsätz-lich im Human-Resources-(HR-)Tool festgehalten werden. Was aber bisher in derPraxis meist fehlt, ist eine Verbindung von IT-Prozessrollen zu den entsprechen-den Funktionen. In diesem Buch werden in den Prozessen teilweise Funktionenund/oder Prozessrollen aufgeführt. Diese sind jeweils entsprechend markiert.

Rollen für das IT-Prozess-Management/die -Governance

Im vorherigen Abschnitt habe ich über die Rollen innerhalb der IT-Prozessegeschrieben. In diesem Abschnitt wird auf die Rollen eingegangen, die für das IT-Prozess-Management/die -Governance nötig sind.

Diese Rollen beschäftigen sich mit der Gestaltung, Dokumentation, Einführung,Etablierung, Verankerung und der Verbesserung der IT-Prozesse. Auch die Ausbil-dung für die verschiedenen IT-Prozesse kann durch diese Rollen wahrgenommenwerden.

Viele Unternehmen entscheiden sich, zwei unterschiedliche Rollen für das Pro-zess-Management zu etablieren:

1. IT Process Owner (IT-Prozess-Eigner)Diese Rolle umfasst die Gesamtverantwortung für den entsprechenden IT-Pro-zess von der Definition bis zur Nutzung und Verbesserung. Grundsätzlich wirddiese Rolle vom IT-Linienmanager (z.B. Betriebs- oder Entwicklungsleiter)wahrgenommen, in dessen Linie die Hauptnutzung oder Hauptaktivitäten des



31

Prozesses erfolgen. Das bedeutet, dass der Verantwortungsbereich dieser Rollemeistens mehrere IT-Prozesse beinhaltet.

Des Weiteren ist diese Rolle auch dafür verantwortlich, dass jeder IT-Prozesseinem IT Process Manager zugeordnet ist. Falls die Position des IT ProcessManagers nicht besetzt ist, so übernimmt der IT Process Owner automatischdiese Rolle.

2. IT Process Manager (IT-Prozess-Leiter)Diese Rolle ist für die Ausführung, d.h. für die Gestaltung, Dokumentation, Ein-führung, Etablierung, Steuerung und Verbesserung, der in ihrer Zuständigkeitliegenden IT-Prozesse verantwortlich. Das bedeutet, dass diese Rolle die Pro-zesse gestaltet und dokumentiert, eventuell auch Prozessschulungen durch-führt und die entsprechenden Prozessmesskennzahlen (KPIs) überwacht. Fallsnötig werden entsprechende Prozessverbesserungen eingeleitet. Sollten die Pro-zessaktivitäten von den entsprechenden Prozessrollenträgern nicht gelebt wer-den, setzt der IT Process Manager mit den Prozessrollenträgern oder demzuständigen Linienmanagement Verbesserungspläne auf und überwacht diese.In sehr hierarchisch geführten Unternehmen kann dies zu einem Problem füh-ren, da der IT Process Manager abteilungsübergreifend agieren muss. Solltendie eingeleiteten Maßnahmen nicht umgesetzt werden oder sollten sich die Rol-lenträger in anderen Bereichen der Umsetzung verweigern, schaltet der IT Pro-cess Manager den IT Process Owner ein und stellt somit über die Management-Ebene die Umsetzung der IT-Prozesse sicher. Bei der Einführung und Weiter-entwicklung von Tools, die den IT-Prozess unterstützen, hat der IT ProcessManager eine sehr wichtige Rolle. Er stellt sicher, dass die prozessrelevantenAnforderungen im Tool entsprechend reflektiert sind.

Für die Rolle als IT Process Manager eignen sich Personen, die ein breites IT-Verständnis (Architektur, Abläufe, Organisation) und sehr gute Kommunika-tions- und Verhandlungsfähigkeiten haben.

In mittleren und größeren Unternehmen, die eine große Anzahl von IT-Prozessenim Einsatz haben, empfiehlt es sich, eine zusätzliche Rolle aufzubauen. DieseRolle wird im vorliegenden Buch als »Head of IT Process Manager« bezeichnet.Sie beinhaltet die fachliche Führung aller IT Process Manager. Ich durfte in derIBM Schweiz AG über mehrere Jahre diese Rolle besetzen. In dieser Aufgabe hatteich zusammen mit 27 mir unterstellten IT Process Managern die IT-Prozesse imOutsourcing-Umfeld in einer ersten Phase in der Schweiz und später zusätzlich inden Ländern Österreich, Tschechien, Polen, Ungarn, Teilen von Afrika und Russ-land aufgebaut und die Audit Compliance sichergestellt. In dieser Rolle war ich alswichtiger Impulsgeber unter anderem bei der Entwicklung der IT-Prozess-Management-Strategie und den übergeordneten Grundsätzen (z.B. Dokumentati-onsgrundlagen, Prozessschulungen) verantwortlich.



32

1.2.4 Messen und Auswerten der erbrachten Dienstleistung

Es ist sinnvoll, dass die Messung und Auswertung dererbrachten Dienstleistung auf zwei Ebenen erfolgt:

1. Serviceebene

2. Prozessebene

Es empfiehlt sich, bei der Etablierung eines Manage-ment-Information-Systems (MIS) in der Informatikbeide Ebenen zu integrieren. Somit wird die bestmög-liche Aussagekraft über die Leistung der Informatik

ermöglicht. Wo entsprechende Tools eingesetzt werden, können diese (in den meis-ten Fällen) wichtige Kennzahlen für die IT-Prozessunterstützung liefern.

Serviceebene

Wie in Abschnitt 1.2.2, »Standardisierung der IT-Dienstleistungen« beschrieben,unterscheiden wir Business IT Services (Leistungsbezieher-Sicht) und IT Services(Leistungserbringer-Sicht). In einer Dekomposition sind verschiedene IT Servicesnötig, um einen Business IT Service zu bilden. Aus diesem Grund werden auf derServiceebene beide Arten von Services abgebildet und gemessen.

Bei den Business IT Services werden SLAs mit einzelnen Service Levels, wie z.B.die Service-Zeit (Service Time), Verfügbarkeit (Availability) und Leistung (Perfor-mance), vereinbart. Es liegt nahe, dass die Messung basierend auf den einzelnenService Levels und dann konsolidiert auf den entsprechenden Business IT Serviceserfolgt. Somit erhält das IT Management wie auch der Leistungsbezieher einensehr guten Überblick über die verschiedenen Business IT Services mit deren SLAsund die darin enthaltenen Service Levels. In der Messung sollten jedoch nicht nurdie qualitativen Größen einfließen, sondern auch die Ist-Kosten gegenüber denbudgetierten Kosten. Damit gelingt es, den finanziellen Bereich der Service-Erbringung auch im Beobachtungsbereich zu halten. In vielen Unternehmen wer-den die Kosten in drei Bereiche unterteilt: RtB (Run the Business), MtB (Maintainthe Business) und CtB (Change the Business). In Abschnitt 3.3.8, »FinancialManagement for Services (Strategy)« wird vertieft auf diese Begriffe eingegangen.

Viele Unternehmen begehen beim Etablieren von SLAs den Fehler, dass sie zuBeginn zu viele Service Levels definieren, die auch gemessen werden sollten. Diesmündet meistens in einem großen Messaufwand, ohne den die vereinbarten SLAskeinen Nutzen erbringen würden. Der Grundsatz »Weniger ist mehr« trifft in



33

einer ersten Phase der Etablierung von Service Levels sicher zu und bewährt sichbei der Umsetzung.

Prozessebene

Die Messungen auf der Prozessebene können als Frühindikatoren für möglicheService-Verletzungen dienen, da meistens vor einer Service Level-Verletzung ver-schiedene Prozesse nicht mehr richtig eingehalten werden.

Es empfiehlt sich, pro Prozess verschiedene Key Performance Indicators (KPIs)oder Prozessmesskennzahlen zu definieren.

Mögliche Prozessmesskennzahlen sind z.B.:

� Incident Management-Prozess

� Gesamtanzahl der Störungen (Incidents)

� Prozent der Störungen, aufgeteilt auf die verschiedenen Prioritäten

� Prozent der Störungen mit nicht erreichten Interventionszeiten, sortiertnach den Prioritäten

� Change Management-Prozess

� Anzahl durchgeführter Changes

� Nicht erfolgreiche Changes

� Nicht autorisierte Changes (nicht über den Change Management-Prozessabgewickelte Changes)

Weitere Beispiele von KPIs für die wichtigsten IT-Prozesse sind Abschnitt 3.3,»Etablieren der Prozesse des IT Service Managements« zu entnehmen.

Weitere Ebenen

Beide oben dargestellten Ebenen reflektieren die gemessenen Resultate. In eini-gen Unternehmen wird noch ein dritter Bereich ins Management-Information-System (MIS) eingebunden. Diese Ebene reflektiert dann die wahrgenommeneDienstleistungsqualität beim Leistungsbezieher und wird oft durch Umfragenerhoben und kann teilweise stark von den rapportierten Service- und Prozesskenn-zahlen abweichen. Gründe dafür können sein: Die Leistungsbezieher in einerBusiness Unit kennen die vereinbarten Service Levels nicht und erwarten eventu-ell eine höhere Verfügbarkeit als vereinbart oder der letzte Ausfall eines BusinessIT Service während einer wichtigen Geschäftsphase wurde bei der Befragung zustark gewichtet. In beiden Fällen ist es sinnvoll, die Kommunikation zu den Leis-tungsbeziehern zu verstärken, sodass diese über die vereinbarte Informatikdienst-leistung Kenntnis haben, oder zu überprüfen, ob die vereinbarten Service Levelsnoch auf das aktuelle Geschäft abgestimmt sind.



34

1.2.5 Optimieren der vereinbarten Dienstleistung

In der Optimierungsphase wird die Dienstleistungs-qualität sichergestellt, um so mögliche SLA Verlet-zungen zu vermeiden. Zusätzlich wird versucht, dieKosten-Nutzen-Effizienz laufend zu optimieren.

Reduktion von SLA-Verletzungen

Im externen Sourcing-Umfeld werden oft SLA-Ver-letzungen mit einer Malus-Regelung (Penalties)inklusive einer Kostenrückerstattung versehen, um

so den Leistungserbringer zu verpflichten, die geforderte Leistung zu liefern. Dader Malus den Profit der externen Source reduziert, hat er ein großes Interessedaran, langfristig die SLAs einzuhalten. Bei einer internen Leistungserbringungsind Malus-Regelungen mit Kostenrückerstattung eher unüblich, da es sich beiden Informatikkosten in vielen Unternehmen um eine rein interne Umbuchunghandelt und somit kein effektiver Geldfluss stattfindet. Die Einhaltung der SLAsist aber auch hier ein wichtiger Aspekt, um die gute Reputation der Informatiksicherzustellen.

Eine SLA-Verletzung findet dann statt, wenn einzelne Service Levels der Service-Vereinbarung (SLA) nicht eingehalten werden. Für einen entsprechenden Busi-ness IT Service wurde z.B. die Verfügbarkeit von 99,5% über einen Monat gemes-sen und vereinbart. Erreicht wurde aber wegen eines größeren Ausfalls nur 99,1%.Somit wurde das SLA im Bereich der Verfügbarkeit nicht eingehalten. Bei einerVerletzung ist in den meisten Fällen eine Root-Cause-Analyse nötig (der Teil desProblem Management-Prozesses ist). In dieser Analyse wird versucht, die Ursachefür die Nichteinhaltung der Verfügbarkeit zu finden. Eine Dekompositionsdarstel-lung des Business IT Service in verschiedene IT Services kann helfen, die Ursachefür die Störung zu finden.

Zur Ansicht ist in Abbildung 1.11 ein vereinfachtes Szenario dargestellt.

Wie die Darstellung zeigt, war die Ursache für den Ausfall eine Störung imBereich des IT Service »Wide Area Networks inkl. Backup-Leitung«.

Abb. 1.11: Einfache End-to-End Business IT Service-Darstellung



35

Die Backup-Leitung hat den Betrieb nicht aufgenommen, da die Einstellungen aufden Routern nicht auf die aktuellen Protokolle ausgelegt waren. Grund dafür war,wie schon öfter in diesem Umfeld passiert, die Durchführung von Veränderungenohne Einbezug des Change Managements.

Um spätere mögliche SLA Verletzungen zu vermeiden, wurden im folgenden Bei-spiel entsprechende Maßnahmen definiert:

1. Es erfolgte eine Zusatzausbildung für Personen, die den WAN IT Servicebetreuen, sodass die entsprechenden Veränderungen immer über den ChangeManagement-Prozess abgewickelt werden.

2. Es wurde ein Tool eingeführt, das alle Hardware-, Software- und Konfigurations-veränderungen im WAN-Umfeld sammelt und mit den entsprechendenChange-Tickets abgleicht. Falls weiterhin Veränderungen ohne die Einhaltungdes Change-Prozesses erfolgen, wird das entsprechende Linienmanagementinformiert.

3. Einmal pro Quartal wird die Funktion »Backup-Leitung« während einesChange-Fensters überprüft. Falls die Funktion nicht gewährleistet ist, werdenweitere Verbesserungsmaßnahmen eingeleitet.

Wie das Beispiel zeigt, können verschiedene Maßnahmen zur Reduktion der SLA-Verletzungen eingeleitet werden. Folgendes Analysevorgehen hat sich bei vielenUnternehmen etabliert:

1. SLA-Verletzung auf Stufe des Business IT Service erkennen

2. Lokalisieren des verursachenden IT Service

3. Identifizieren des Störungsgrunds

4. Technologieproblem

5. Prozessproblem (Rollenträger befolgen die Prozesse nicht)

6. Organisationsproblem

7. etc.

8. Falls nötig, Schritte zur Sicherstellung und Korrektur einleiten

9. Überprüfen, ob die eingeleiteten Schritte die gewünschte Verbesserung erbringen

Sicherstellung der Dienstleistungsqualität

Die Vermeidung von SLA-Verletzungen ist, wie im vorherigen Abschnitt beschrie-ben, ein wichtiger Aspekt. Bei einer Qualitätsbetrachtung sollte jedoch nicht nurdies im Vordergrund stehen. Basierend auf den verschiedenen IT-Prozessen wur-den für jeden davon Messkennzahlen (KPIs) definiert. Viele Unternehmen verse-hen die KPIs und die SLA-relevanten Kennzahlen mit einer Rot/Gelb/Grün-Bewertung. Für eine spätere Rapportierung der Werte an das Management ist diessehr sinnvoll.



36

Nachfolgend zwei Beispiele (siehe Tabelle 1.2), wie der Status des Business IT Ser-vice rapportiert werden kann:

Der grüne Wert reflektiert in der Regel das SLA Target.

Mittels einer Gewichtung der einzelnen Service Levels und einer Konsolidierungs-formel kann auch ein gesamter Service-Status mittels der Rot/Gelb/Grün-(Red/Amber/Green-)Bewertung angezeigt werden (siehe Abbildung 1.12).

Abb. 1.12: Übersicht MIS Business IT Service

Kosten-Nutzen-Effizienz steigern

Wie im vorgehenden Abschnitt beschrieben ist es wichtig, die geforderte Qualität(Effektivität) zu erbringen. Zu vermeiden ist jedoch, dass die Wirtschaftlichkeit dergelieferten Leistung (Effizienz) in der Betrachtung der Dienstleistungserbringungvernachlässigt wird. Viele Unternehmen können jedoch die Kosten der Business ITServices inklusive der darunter liegenden IT Services nicht ausweisen. Somit fehltdie Basis für einen Kosten-Nutzen-Vergleich. Ein möglicher Ansatz, wie die IT-Betriebsbuchhaltung und die Leistungsverrechnung aufgebaut werden können, istin Abschnitt 3.3.8, »Financial Management for Services (Strategy)« beschrieben.

In den nachfolgenden Bereichen besteht in vielen Unternehmen ein Potenzial, dieEffizienz in der Informatikdienstleistung zu steigern.

Service-Bereich:� Die Service Levels der Business IT Services sind nicht Kosten-Nutzen-orientiert

auf die Geschäftsanforderungen abgestimmt.

Service Level Definition(G) Grün

Definition(A) Gelb

Definition(R) Rot

Verfügbarkeit (End-to-End) >99,6% 99,5–99,6% <99,5%

Antwortzeit <1 Sek. 1–1,5 Sek. >1,5 Sek.

Tabelle 1.2: Beispiel-Service Levels mit Grün-, Gelb- und Rot Bewertung



37

Beispiel: Gemäß einer Analyse arbeiten in einem beispielhaften KMU-Betriebvon 20:00 bis 22:00 Uhr nur ein Prozent der Leistungsbezieher. Diese nutzenin dieser Zeitspanne keine geschäftskritischen Business IT Services. Somitkönnte eine Reduktion der Service-Zeit von aktuell 7:00 bis 22:00 auf 7:00 bis20:00 Uhr in Betracht gezogen werden. Was gemäß unserem Beispiel die Zeitdes Onsite-Supports oder den Bereitschaftsdienst von IT-Mitarbeitern reduziertund somit die IT-Kosten senken kann.

� Es bestehen zu viele unterschiedliche IT Service-Optionen.Beispiel: der »Windows Standalone Service« mit folgenden Optionen (Optionensind im folgenden Beispiel Ausprägungsarten eines IT Service mit unterschied-lichen Service Levels (Qualitätsmerkmalen) wie Service-Zeit, Verfügbarkeit,Leistung (Performance)):

Option 1. High Available / High Performance / Service-Zeit: Gold

Option 2. High Available / High Performance / Service-Zeit: Silber

Option 3. High Available / High Performance / Service-Zeit: Bronze

Option 4. High Available / Middle Performance / Service-Zeit: Gold

Option 5. High Available / Middle Performance / Service-Zeit: Silber

Option 6. High Available / Middle Performance / Service-Zeit: Bronze

Option 7. High Available / Low Performance / Service-Zeit: Gold

Option 8. High Available / Low Performance / Service-Zeit: Silber

Option 9. High Available / Low Performance / Service-Zeit: Bronze

Option x. Und die gleiche Anzahl für Middle-Available-Optionen

Hinzu kommen weitere IT Services in der Windows-Gruppe, wie z.B. »WindowsVirtual« oder »Windows Clustered«, auch mit einer großen Anzahl weitererOptionen.

Der Aufbau, die Verwaltung und Steuerung dieser IT Services mit den vielenOptionen ist entsprechend komplex und führt zu verschiedenen Herausforde-rungen bei der Handhabung, wie z.B. bei der Kostenzuteilung je Option. Ausdiesem Grund empfiehlt es sich, die Anzahl Optionen so klein wie möglich zuhalten.

� Die Unternehmung erreicht bei vielen IT-Dienstleistungen die kritische Massenicht, was sich in hohen IT-Kosten widerspiegelt. Durch ein gezieltes Sourcingkönnten so eventuell standardisierte IT-Dienstleistungen zu günstigen Kostenbei professionellen Sourcing-Partnern eingekauft werden.

Prozessbereich:� Viele Unternehmen machen bei der Prozesseinführung oft den gleichen Fehler

und versuchen, die IT-Prozesse so aufzubauen, dass diese 100% aller Anforde-rungen abdecken. Dies führt dazu, dass die Prozesse zu komplex werden. Bei



38

einer erstmaligen Etablierung gilt der Grundsatz »weniger ist mehr« (Pareto-prinzip). Wenn 80% aller Anforderungen im Prozess beschrieben sind, kannmit der Einführung begonnen werden. Ausnahmen werden dann nach Aufkom-men und Wichtigkeit als Ergänzung in den Prozess eingefügt. Falls in diesen Fäl-len keine Ergänzung im Prozess erfolgt, so kann ein Vermerk für den Prozess-rollenträger hilfreich sein, der ihm aufzeigt, bei wem er nachfragen kann, umzu klären, wie er mit der außerordentlichen Situation umgehen muss.

� Bei vielen Medienbrüchen und/oder fehlender Workflow-Unterstützung beistark genutzten Prozessen, wie z.B. Incident Management, Change Manage-ment und Service Asset and Configuration Management, kommt es zwangs-läufig zu einer schlechten Kosten-Nutzen-Effizienz.

Die Ursachen für die Einbußen in der Kosten-Nutzen-Effizienz sind von Unterneh-men zu Unternehmen unterschiedlich begründet. Es empfiehlt sich, eine detail-lierte Analyse basierend auf der Lean-Sigma®(Lean Management und Six Sigma)-Methode durchzuführen, um die Effizienz wie auch die Effektivität zu steigern.

Beispiel einer Lean Sigma®-Analyse:

Besteht eine Überproduktion? (Overproduction)

� Mehrleistung durch falsch abgestimmte Kundenbedürfnisse(Service Levels im SLA stimmen nicht mit den Kundenbedürfnissen überein)

� Regelmäßiges Überschreiten der Kundenanforderungen »Vergoldungs-Effekt«(Das Service Reporting weist eine massiv höhere Verfügbarkeit aus, als dies imSLA vereinbart wurde)

� Es werden Business IT Services zur Verfügung gestellt, die kaum genutzt wer-den und nicht »Business-vital« oder »Business-kritisch« sind.

Bestehen Wartezeiten in den IT-Prozessabläufen? (Waiting)

� Wartezeiten zwischen Zuweisungen von Arbeitstasks

� Leerlaufzeiten während automatisierter Workflows

� Wartezeiten, die durch Drittanbieter entstehen

Bestehen Ablaufprobleme? (Motion)

� Fehlende oder suboptimale IT-Prozesse und/oder IT-Aktivitäten

� Fehlende Workflow-Unterstützung in Tools. Die Mitarbeiter müssen sehr vielmanuell ausführen, was zeitaufwendig und fehleranfällig sein kann.

� Es bestehen viele manuelle Schnittstellen zwischen den Tools. Es kann sein, dassein Event manuell ins Incident Tool übertragen werden muss, wenn dieses eineStörung anzeigt. Oder Evidenzen (Nachweise) für Audits müssen manuell ausden Tools ausgelesen werden, um sie in einer eigenen Datenbank zu speichern,sodass bei einem Audit die benötigten Informationen zur Verfügung stehen.



39

� Wichtige Ansprechpartner oder Prozessrollen sind nicht definiert oder nichtbesetzt.

Besteht ein Transportproblem? (Transport)

� Es besteht ein nicht optimales Dispatching oder Weiterleiten von Aufgaben,sodass es zu Pingpong-Arbeiten kommt.

� Es muss sehr viel vor Ort abgeklärt werden, da Remote-Analyse- oder Support-Tools fehlen.

Ist das IT-Inventar nicht aktuell, zu komplex oder zu vielfältig? (Inventory)

� Jede Kundenanforderung basiert auf einer eigenen Lösung. Eine Standardisie-rung von IT-Dienstleistungen oder IT-Komponenten fehlt oder ist nur teilweiserealisiert.

� Es gibt eine sehr große Anzahl von Servern, die sehr schlecht ausgelastet sind.

� Kapazitäts- und Leistungsdaten auf Stufe der Business IT Services und IT Ser-vices fehlen oder sind nicht ausreichend.

Sind viele Nachbesserungen erforderlich? (Rework)

� Unzureichendes oder mangelhaftes Testen vor Inbetriebnahme der Veränderung

� Die Architekturgruppe entwickelt Systemspezifikationen/Anforderungen ohneeine Prüfung der Umsetzbarkeit.

� Anforderungen der Leistungsbezieher werden nur mangelhaft aufgenommen.

Wird unnötige Mehrarbeit geleistet? (Over Processing)

� Es werden Systeme oder Arbeitsstationen ersetzt, ohne dass diese den Lebens-zyklus erreicht haben oder einen massiven Defekt aufweisen.

� Sicherungen werden basierend auf einem zu kurzen Zyklus ausgeführt, wasviel Systemressourcen benötigt.

� Reports werden erstellt, die niemand liest oder weiterverarbeitet.

� Übertriebene Dokumentationen (dies ist jedoch eher selten der Fall).

Gibt es Probleme basierend auf fehlendem Wissen oder einer falschen Stellenbe-setzung? (Intellect)

� Den Mitarbeitern fehlt wichtiges Wissen, um ihre Arbeit optimal auszuführen.

� Die Fähigkeiten der Mitarbeiter entsprechen nicht dem Anforderungsprofil derStelle.

� Die Ausbildung im Prozessbereich fehlt oder wird nicht laufend bei Anpassun-gen durchgeführt, z.B. fehlende Prozess-Refresher-Kurse.


299

Stichwortverzeichnis

5-Why-Methode 138

AABB 63Access Analyst 238Access Management 28, 234Access Manager 239Access Verifier 238AM siehe auch Access ManagementAnforderung

funktionale 15nicht funktionale 16

AnsichtService-Katalog 215

Anwendungsentwicklung 14Anwendungsorientierter IT Service 19Arbeitsinstruktion siehe auch Working Inst-

ructionArbeitsplatz-Service 17Architecture Building Block 63Asset 109Aufnahmezeit 148Auftrags-Anliegen 143, 146

Eskalationsverfahren 149Genehmigungsfluss 147Zeitspanne 147

Ausfallsicherheit 81Availability Analyst 221Availability Management 27, 217Availability Manager 222Availability Plan siehe auch Verfügbarkeits-

planAVM siehe auch Availability Management

BBasis-IT Service 19Bedarfsmuster 256Bedürfnisformular 157Bedürfnissteller siehe auch Requirement

OriginatorBefund 272

Bereichs-IT-Sicherheitsbeauftragter siehe auch Security Analyst

Betriebszeiten 79Bewilligungszeit 148Budgetierung 169Budgeting siehe auch BudgetierungBusiness and IT Steering Group 254Business Impact-Analyse 198Business IT Service 16, 60, 74

definieren 61Business IT Service Manager 91Business IT Service Owner 90, 174Business IT Service Review Meeting 89Business IT Service-Kritikalität 78Business IT Service-Verrechnung 169Business Management 173Business Relationship Management 25, 247Business Relationship Manager 249Business Service 16

CCAB siehe auch Change Advisory BoardCapacity and Performance Management 26,

223Capacity Plan siehe auch KapazitätsplanCapacity/Performance Analyst 227Capacity/Performance Manager 227Change Advisory Board 95, 103Change Analyst 106Change Approver 106Change Closing-Code 105Change Management 27, 95

Rollen 106Change Manager 107Change Owner 106Change-Durchführungszeit 102Change-Risiko

Kategorisierung 100Change-Typ 99Charging siehe auch VerrechnungCHM siehe auch Change Management



300

CI 27, 97, 125, 182warten 110

CI-Typ 110Definition 114

CM siehe auch Service Continuity Manage-ment

CMDB 108pflegen 119

COI Analyst 293COI Manager 293COI siehe auch Continual ImprovementComplaint Management 247Complaint Owner 248Configuration Analyst 120Configuration Auditor 121Configuration Librarian 120Configuration Management-Datenbank 108Configuration Manager 121Configuration-Datenbank 114, 115Continual Improvement 29, 290Continuity-Test und -Übung 203Continuous Availability 221Continuous Operation 221Costing siehe auch KostenrechnungCPM siehe auch Capacity and Performance

ManagementCtB 32, 166, 170, 252

DDatenschutz 82Defect 272, 279Defect-Priorität 279Dekomposition 21Delta Release 180Demand Management 26, 256Demand Manager 257Deployment Management 28, 283Deployment Manager 285Deployment Owner 285Deployment-Plan 284Design 26Dispatcher-Kreise 131DM siehe auch Demand ManagementDPM siehe auch Deployment ManagementDrittanbieter

Incident-Abwicklung 132

EEinführungsmodell von ITSM-Prozessen 42EM siehe auch Event ManagementEmergency Release 180

End User-orientierter IT Service 20Erbringungszeit 146, 149Ereignis siehe auch EventErweiterter IT Service 19Eskalation 123

funktionale 123Eskalationsverfahren 129

Auftrags-Anliegen 149Event 229Event Analyst 233Event Management 28, 229Event Manager 233Event-Kategorisierung 231

FFault Tolerance 220Financial Management for Services 163FMS siehe auch Financial Management for

ServicesFührungsebene 50Full Release 180Funktion 29Funktionale Anforderung 15Funktionale Eskalation 123

GGeschäftsanwendung

gruppieren 18Grundstrategie

Risikobewältigung 243GtB 252

HHead of IT Process Manager

Aufgaben 59High Availability 220

IID

persönliche 236unpersönliche 236

Identifikation 236IM siehe auch Incident ManagementImprovement-Strategie 290, 292Incident Analyst 133Incident Assignee 133Incident Management 28, 122Incident Manager 134Incident-Abwicklung

Drittanbieter 132



301

Incident-BearbeitungZeitspanne 127

Incident-Priorität/Severity 124Informatikberatung 14Informatikschulung 14Information Security Management 27, 186Information Security Policy 186Informations- und Kommunikationsplan

248Informationsanliegen 144, 150Informationssicherheit 82Installation Test 274Integration Test 275Interventionszeit 128ISM siehe auch Information Security Manage-

mentISP siehe auch Security PolicyIT Financial Manager 173, 174IT Management 173IT Process Manager 31

Aufgaben 57IT Process Owner 30

Aufgaben 57IT Service 19, 63

anwendungsorientiert 19Basis 19End-User-orientiert 20erweitert 19unterstützend 20

IT Service Management 41Hauptelemente 14in Führungsebene 50

IT Service Provider 92, 174IT Service-Option 64IT Steering Group 255IT-Dienstleistung

Standardisierung 16IT-Finanz-Analyst 174, 175IT-Finanz-Auditor 175IT-interne Betriebsbuchhaltung siehe auch

KostenrechnungIT-Prozess 44IT-Prozess-Eigner siehe auch IT Process

OwnerIT-Prozess-Governance siehe auch IT-

Prozess-ManagementIT-Prozess-Leiter siehe auch IT Process

ManagerIT-Prozess-Management 30IT-Sicherheitsbeauftragter siehe auch Security

Manager

KKapazitätsplan 225Katalog

Status des Service 214Katastrophenaufbau- und -ablauforganisa-

tion 202Katastrophen-Management »K-Manage-

ment« 208Katastrophenstab »K-Stab« 208Katastrophenvorsorge 82Kategorisierung

Probleme 139Key Performance Indicator siehe KPIKM siehe auch Knowledge ManagementKnowledge Management 28, 286Known Error 123, 136Known Error-Datenbank 137Komponententest 275Kosten-Nutzen-Effizienz 36Kostenrechnung 166KPI 33, 93, 94, 142, 217Kritische Erfolgsfaktoren für eine Verände-

rung 54

LLead Times siehe auch Change-Durchfüh-

rungszeitLean Sigma 38Leistungsanforderung 80Leistungsbezieher 13, 15, 164, 166

Funktion 70Leistungserbringer

Funktion 70Lieferantenevaluations-Checkliste 260Lösungszeit 81

MMajor Incident 127Major Release 180Malus-Regelung 34Managed-Anwendung 13, 18Managed-Arbeitsplatz 13Management-Commitment 50Management-Information-System 32Meeting 88Minor Release 180MIS siehe auch anagement-Information-

SystemMixed Release 180MtB 32, 166, 170, 252



302

NNicht funktionale Anforderung 16

OOLA 69

Inhalt 84Review-Meeting 90Vereinbarungsgespräch 89

OLA Service Level Analyst 92OLM Controller 92OLM siehe Operational Level ManagementOperation 28Operational Level Agreement siehe OLAOperational Level Management 26, 75Operational Level Management Meetings 89Operational Level Manager 92Organisation 49

PPattern of Business Activity 256PBA siehe auch Pattern of Business ActivityPersönliche ID 236Pingpong-Situation 134PIR siehe auch Post Implementation ReviewPortfolioansicht 253Portfoliokategorie 252Post Implementation Review 104Problem

Kategorisierung 139Problem Analyst 141Problem Management 28, 136Problem Manager 142Problem-Priorität 137Process Governance siehe auch Prozess-

Management-OrganisationProjektklassifizierung 266Prozessinhaltsbeschreibung 109Prozess-Management-Organisation 56Prozess-Management-Struktur 47Prozessrolle 29

Zuteilung 90

RRCA siehe auch Root Cause AnalysisReaktionszeit 81, 128, 160Recovery Point Objective 22, 199Recovery Time Objective 22, 199Relationship Management siehe auch Busi-

ness Relationship ManagementRelease Closing-Code 183Release Level 180

Release Management 27, 177Release Manager 184Release Owner 184Release Plan 181

strategischer 181Release-Bezeichnung 180Release-Bündel siehe Mixed ReleaseRelease-Dokumentation 182Release-Packet siehe auch Mixed ReleaseRelease-Typ 180Request for Change 96, 98Request Fulfillment 28, 143Requirement Analyst 161Requirement Engineer 160Requirement Management 25, 155Requirement Manager 162Requirement Originator 160Revalidierung 237RF siehe Request FulfillmentRfC 96RIM 240Risikoanalyse 199Risikobewältigung

Grundstrategie 243Risikoklassifikation 200Risikoreduktion 243Risikostrategie 200Risikotransfer 243Risikoübernahme 243Risikovermeidung 243Risk Identifier 244Risk Management 29, 240Risk Management-Strategie 240, 244Risk Manager 245Risk Owner 245RM siehe auch Release ManagementRolle

in IT-Prozessen 29Zuteilung 90

Root Cause Analysis 138RPO siehe auch Recovery Point ObjectiveRQM siehe auch Requirement ManagementRQM-Zeitspanne 160RtB 32, 166, 170, 252RTO siehe auch Recovery Time Objective

SSACM

Rollen 120SACM siehe auch Service Asset and Configu-

ration Management



303

SACM-Strategie/Konzept 117Schadensauswirkung 200Schwellenwert siehe auch ThresholdSCM siehe auch Service Catalog ManagementSDP siehe auch Service Design PackageSecurity Analyst 193Security Manager 194Security Policy 187Security Procedure 188, 192Security Statement 188Security-Spezialist 194Security-Standard 188Service

Status im Katalog 214Service Asset and Configuration Manage-

ment 27, 108Service Catalog Content Manager 216Service Catalog Management 26, 210Service Catalog Manager 216Service Continuity Analyst 207Service Continuity Management 27, 195Service Continuity Manager 207Service Continuity Plan 205Service Continuity-Strategie 196, 197Service Design Package 269Service Knowledge Manager 288Service Level 22, 36Service Level Management 26, 74

Design 69Service Level Manager siehe auch Business IT

Service ManagerService Level-Meeting 88Service Life Cycle 24Service Portfolio Management 25, 250Service Portfolio Manager 254Service Reporting 83Service Request 143, 144, 145, 147Service Request Analyst 152Service Request Approver 152Service Request Manager 153Service Request Originator 151Service Transition Leader 269Service Transition Manager 269Service Validation and Testing 28, 271Service-Dekomposition 21, 115Service-Katalog 211

Ansichten 215Service-Zeit 79Skalierbarkeit 81SL siehe Service LevelSLA 69, 77

Vereinbarungsgespräch 88Verletzung 88

SLA Service Level Analyst 91SLA-Verletzung 34SLM Controller 92SLM siehe auch Service Level ManagementSL-Target 22Solicited Event 231SPM siehe auch Service Portfolio Manage-

mentStakeholder Management 247Status

Service im Katalog 214Störungsbehebungszeit 128Strategischer Release-Plan 181Strategy 25SUM siehe Supplier ManagementSupplier Management 27, 258Supplier Manager 263Supporting 29Support-Zeit

1st Level Support 80Suspend-Zeit 129SVT Manager 281SVT siehe auch Service Validation and TestingSVT-Strategie/Konzept 271, 273System Test 275Systemumgebung

Teststufen 275

TTeilauftragszeit 148Test Designer 280Test Engineer 280Test Manager 281Testart/-typ 276Tester 280Testfallbeschreibung 278Teststufe 274

Systemumgebung 275Threshold 229Ticketlaufzeit 128Tools und Hilfsmittel 48TPS siehe Transition Planning and SupportTransition Planning and Support 27, 264Transition-Strategie 265, 266TtB 252

UUC 73, 87Underpinning Contract siehe UC



304

Unit/Modul Test 275Unpersönliche ID 236Unsolicited Events 232Unterstützender IT Service 20Uplift siehe auch ZuschlagUser Acceptance Test 275Utility 271Utility siehe auch Anforderung, funktionale

VValidierungs- und Testplan 271, 274Verfügbarkeit 23, 80Verfügbarkeitsplan 219Verrechnung 83, 168

WWahrscheinlichkeit 200Warranty 271Warranty siehe auch Anforderung, nicht

funktionaleWIN 46WIN siehe auch Working InstructionWorking Instruction 43

ZZeitspanne

Bearbeitung von Auftrags-Anliegen 147Zuschlag 166


Documents

IT Service Management - mitp · können. ITSM kann mehr, Geschäftsprozessmanagement auf vielen Ebenen wird möglich. Die anderen Prozesse sind mang els Vorgehensmodellen teilweise