Bedeutung ITIL® V3 für Kunden und Dienstleister

Inhaltsverzeichnis

1. Vorwort

2. Einleitung
2.1. Motivation
2.2. Aufgabenstellung
2.3. Abgrenzung
2.4. Gliederung

3. Überblick über die relevanten Regelwerke
3.1. EN ISO 9001:2008
3.2. EN ISO 20001:2005
3.3. ÜberblickITIL Version 2
3.3.1. Service Support
3.3.2. Service Delivery
3.4. Überblick ITIL Version 3
3.5. Änderungenzur Version V2

4. IT Infrastructure Library V3
4.1. Konkrete Darstellung der relevanten Inhalte
4.1.1. Service Strategy
4.1.2. Service Design
4.1.3. Service Transition
4.1.4. Service Operation
4.1.5. Continual Service Improvement
4.2. Verankerung der Version 3 in der Organisation
4.3. Überlegungen über Vor- bzw. Nachteile in der Praxis
4.4. Annahme von ITILam Markt

5. Bedeutung ITIL V3 für die IT-Nutzer
5.1. Generelle Anforderungen
5.2. Chancen und Risiken
5.3. Schnittstellen zur IT

6. Bedeutung ITIL V3 für die IT-Dienstleister
6.1. Aufgaben der IT
6.2. Servicelebenszyklus im IT-Bereich
6.3. Grundvoraussetzungen definieren
6.4. ITIL-Elemente im täglichen Gebrauch
6.5. Kontinuierliche Bewertung und Verbesserung

7. Zusammenfassung

8. Ausblick

9. Abkürzungsverzeichnis

10. Glossar

11. Abbildungsverzeichnis

12. Literatur- und Quellenverzeichnis

Kurzzusammenfassung:

Die vorliegende Master Thesis gibt einen Überblick über den De-facto-Standard IT Infrastructure Library (ITIL) im IT-Bereich. Die Versionen 2 und 3 von ITIL werden insbesondere näher betrachtet. Die Version 3 wurde erst im zweiten Halbjahr 2007 publiziert und ist daher noch nicht sehr stark verbreitet. Großer Wert wird auf die Darstellung der Inhalte und die Verankerung in der Organisati­on gelegt. Weiters werden die wesentlichen Unterschiede zur bisherigen Version

2 aufgezeigt. Der Schwerpunkt der Arbeit bezieht sich auf die kritische Betrach­tung der Praxistauglichkeit und Relevanz im Alltag. Die Version 2 beschäftigte sich nur mit den Bereichen Service Support und Service Delivery. In der Version

3 wurden diese beiden Bereiche in insgesamt fünf Hauptbereiche eingegliedert und um die neuesten Best Practices erweitert. Die wesentlichste Neuerung war der durchgängige Service-Lebenszyklus. Die Master Thesis beschäftigt sich nicht nur mit den Aspekten des IT-Dienstleisters, wie vielleicht erwartet wird, sondern betrachtet auch den IT-Nutzer. Erst durch die duale Betrachtungsweise entsteht ein Gesamtbild für den Betrachter, der sich ein eigenes Urteil über die Einsatz­möglichkeiten bilden kann.

Schlagwörter: ITIL, Service Strategy, Service Design, ServiceTransition, Ser­vice Operation, Continual Service Improvement

Abstract:

This master thesis gives an overview about the de facto standard IT Infrastruc­ture Library (ITIL) in the IT domain. The versions 2 and 3 of ITIL specifically will be looked at closer. The version 3 was published only in the second half-year in 2007 and, hence, is not used as widely as version 2 yet. Major focus is placed on the representation of the contents and its anchorage in the organisation. Fur­thermore the essential differences between the current version 3 and its prede­cessor version 2 are presented. The main focus of the work refers to the critical consideration of the practice suitability and relevance in daily business. The ver­sion 2 dealt only with Service Support and Service Delivery. In the version 3 both these parts were integrated into a total of five main parts and were en­hanced with the newest Best Practices. The most essential innovation was the universal service-life cycle. This master thesis deals not only with the aspects of the IT service provider as is maybe expected, but also looks at the IT user. A general view originates only from the twofold approach for the viewer who can form his own opinion about the possible application.

Keywords: ITIL, Service Strategy, Service Design, Service Transition, Service Operation, Continual Service Improvement

1. Vorwort

Die vorliegende Arbeit bezieht sich zu einem Teil auf meine Diplomarbeit im Jahr 2007. Die Diplomarbeit beschäftigte sich mit ITIL V2, die Masterarbeit beinhaltet bereits die neue Version 3 von ITIL.

2. Einleitung

Die Menschheit stand vor vielen Millionen Jahren am Beginn der Evolution und verstand lange nicht, warum sich die Welt um die Sonne und auch um die eigene Achse drehte. Erst im Laufe der Zeit lernte der Mensch die Zusammenhänge der Naturwissenschaft zu begreifen und konnte diese nachvollziehen und für sich nutzbringend einsetzen. Heutzutage empfinden viele Menschen, dass der techni­sche Fortschritt zu langsam voranschreitet. Deshalb beginnen sie, Veränderun­gen in Gang zu setzen.

Erst mit der Spezialisierung kamen die Anforderungen und später auch die Quali­tätssysteme. Allgemeine Systeme deckten am Beginn großflächig die Branchen und Bereiche ab, erst mit der Zeit zeigten sich Schwächen, dass nicht alle Forde­rungen 1:1 umgesetzt werden konnten. Daher wurden eigene Standards und Normen gefordert.

Durch die größer werdende Nutzung der Informationstechnologie entstanden und entstehen immer noch eigene Standards und Normen. Die Verdrängung von ISO 9001:2000 durch ISO 20001:2005 im IT-Bereich zeigt bereits das Umdenken. Ebenfalls setzte sich ITIL durch die Best Practice Methode mit der Zeit durch und erhält dank der weitgreifenden Überarbeitung in Form der Version 3 wieder Schwung. Es zeigte sich, dass der große Werkzeugkoffer und der Denkansatz von ITIL nicht nur dem IT-Dienstleister Vorteile bringen, sondern auch dem IT- Nutzer. Das Verständnis auf beiden Seiten führt zu einer Kommunikation und einer gemeinsamen Sprache. Die Normierung der Sprachelemente von ITIL lässt keine Interpretationsspielräume offen und legt die Begriffe mit der jeweiligen De­finition fest.

Vor ITIL gab es viele einzelne Ansätze und Methoden, die der IT-Dienstleister nach eigenem Ermessen nutzen konnte. Die Schwierigkeit der separaten Themen zeigte sich in der Überführung in Schnittstellen, wofür meistens zusätzlicher Auf- wand erforderlich war. Mit ITIL werden der Best Practice Weg und die Zusam­menhänge zwischen den einzelnen Bereichen vorgegeben. Jeder nimmt sich die für ihn erforderlichen Inhalte heraus und setzt diese im Unternehmen um. Begrif­fe wie ChangeBoard, Configuration Management Database und Problemmanage­ment werden bereits auch von IT-Nutzern verwendet und verstanden. Dadurch erhöht sich ebenfalls das Interesse beim Kunden und die gemeinsame Sprache erleichtert die Zusammenarbeit. Die vorliegende Arbeit gibt einen Einblick über die unterschiedlichen Sichtweisen und Zugänge von ITIL V3.

2.1. Motivation

Diese Arbeit beschäftigt sich mit den Inhalten der neuen Version 3 des De-facto- Standards IT Infrastructure Library. Im Focus steht die praktische und einfache Umsetzung im IT-Bereich, die im Speziellen die Umsetzbarkeit des De-facto- Standards in der Realität untersucht.

Erst Mitte 2007 wurde die Version 3 von ITIL publiziert. Grundsätzliche Neuerung der Version 3 ist das Servicelebenszyklusmodell¹. Zentral steht jene Strategie, die wesentlich besser die Prozesse im Unternehmen als bisher darstellt und auf das komplette Modell Einfluß nimmt.

Die Motivation lag in der praktikablen Ausrichtung von ITIL V3 im IT-Bereich. Heutzutage werden Normen und Standards kritischer als früher betrachtet, da in erster Linie eine Zertifizierung lediglich Aufwand darstellt und möglicherweise keine Verbesserungen bringt.

IT-Unternehmen sind heute noch stärker an Verbesserungen und an Einspa­rungspotentiale interessiert, damit die erforderlichen Aufgaben und Tätigkeiten umfassend erledigt werden können. Die angekündigten Verbesserungen von ITIL V3 werden hier auf eine praktikable Umsetzung untersucht.

Wesentliche Punkte im Zusammenhang mit ITIL sind wie folgt:

- Aufrechterhaltung bzw. Verbesserung des IT Service Management
- Einbeziehung des Best Practices Ansatzes in der Praxis unter Berücksichtigung der Kosten-Nutzen-Analyse
- Stärkere Einbeziehung der strategischen Sichtweise in die unternehmerischen Entscheidungen
- Nachvollziehbarkeit (Dokumentation, Abstimmungen, Termine, In- bzw. Außerbetriebnahmen)
- Zuverlässigkeit (Tests, Standardansatz)
- Problembeschreibungen (Service Desk, 2nd Level, Service Level Management, Wartungsverträge, Notfallpläne)
- Zentrale Infodrehscheibe (neue Projekte, Produkte, Planung von Termin­einsätzen)
- Systemspezialisten und Vereinbarungen mit OLA (Vereinbarungen mit 3rd Level)

Die neue Version 3 beinhaltet neue Definitionen von Begriffen, die in der vorigen Version anders beschrieben waren. Zum Beispiel wird der Begriff „Service" erwei­tert gesehen und der Terminus „continuous" findet in der ITIL-Literatur Einzug. Deshalb muss besonderes Augenmerk auf den Formalismus gelegt werden.

Die Kernaussage der neuen Version beschränkt sich auf die Anforderungen der Kunden, damit diese ihre gewünschten Services ohne Einschränkungen nützen können. Die Prozesse der Kunden stehen im Vordergrund.

Das Risikomanagement erhält größere Bedeutung und ist ein wesentlicher Punkt in der Betrachtung, welche Risiken mit welcher Wahrscheinlichkeit und mit wel­chem Impact auf das Unternehmen einwirken können.

In diesem Zusammenhang müssen Prozess- bzw. Systemfähigkeitsmessung und Prozessregelung genannt werden, da diese Methoden einen wesentlichen Beitrag

zur Reduzierung von Ausfällen und standardisierten Vorgehensweisen in Fehler­fällen leisten. Diese Daten werden für den allumfassenden Lebenszyklus, egal ob Hard- oder Software, genutzt, der nun in Version 3 von ITIL eine wesentliche Rolle spielt. Und zu guter letzt liefern die Lösungs- und Verbesserungsmethoden, wie Werkzeuge KVP, 7-Step-Lösungsmethode zusätzliches Potential, das nicht zu unterschätzen ist. Normierte Abläufe zeigen den Anwendern, wie einfach Werk­zeuge umsetzbare und teilweise kostengünstige Ergebnisse liefern.

2.2. Aufgabenstellung

Die vorliegende Arbeit beschäftigt sich mit den Inhalten des De-facto-Standards ITIL Version 3, die im Jahr 2007 veröffentlicht wurde. Konkret werden die Inhalte von ITIL Version 2 und 3 im Detail, sowie ISO 9001 und ISO 20001 überblicks­mäßig dargelegt. Weiters wird besonderes Augenmerk auf ITIL Version 3 gelegt, da die Version 2 sukzessive durch die neue Version ersetzt werden soll. Ob dies funktionieren kann, wird die vorliegende Arbeit beantworten können. Die Gegen­überstellung der Betrachtungsweise von IT-Nutzer und IT-Dienstleister liefert Informationen, in wieweit ITIL Praxisbezug und Umsetzungsmöglichkeit besitzt.

Folgende Fragen werden durch die vorliegende Master Thesis beantwortet wer­den:

- Welche Bedeutung hat ITIL V3 für den IT-Nutzer?
- Welche Bedeutung hat ITIL V3 für den IT-Dienstleister?
- Welchen Einfluss hat das Servicelebenszyklusmodell aufden IT-Bereich?
- Wie sehr hat ITIL bereits in den Unternehmen Einzug gefunden?
- Welche Herausforderungen gibt es für die neue Version 3?

2.3. Abgrenzung

Die Abgrenzung dieser vorliegenden Ausarbeitung beschränkt sich auf den IT- Bereich und dessen Normen, die in diesem Bereich Anwendung finden. Diese Ar­beit beschäftigt sich mit den Inhalten und dem Servicelebenszyklusmodell der IT Infrastructure Library Version 3 im Bezug zur Version 2. IT-Standards wie ISO 9001 und 20001:2005 werden theoretisch erläutert, finden jedoch keinen Einzug in der praktischen Betrachtung. Aufgrund der Aktualität von ITIL V3 werden kei­ne tiefgreifenden Vergleiche mit der bisherigen Version 2 bzw. anderen Normen, die erwähnt werden, erstellt.

2.4. Gliederung

Der erste Teil dieser Arbeit zeigt die theoretische Abhandlung des Themas Nor­men im IT-Bereich, wobei die aktuelle Version 3 näher betrachtet wird. Am Ende des ersten Teils wird das Thema „Annahme von ITIL am Markt" behandelt. In welchem Ausmaß wurde ITIL bereits vom Markt angenommen und welche Um­setzungsmöglichkeiten sind in Zukunft geplant.

Anhand eines eigenentwickelten Fragebogens wurden im August und September 2008 IT-Dienstleister in Österreich (Raum Wien) zu IT-Standards in der Praxis befragt. Die statistische Aufarbeitung des Themas liefert zusätzlichen Input, wie sehr ITIL wirklich verbreitet ist und ob sich der De-facto-Standard bald noch grö­ßerer Beliebtheit freuen darf.

Im zweiten Teil der Arbeit wird auf die Bedeutung für IT-Nutzer und IT- Dienstleister eingegangen. Dies soll die unterschiedlichen Sichtweisen und Zu­gänge zeigen und dem Betrachter ein Bild erstellen, ob eine Übereinstimmung der Forderungen und der Leistungen gegeben ist.

Abschließend wird auf den Lebenszyklus eines Services eingegangen, womit die zentrale Stellung des Services gezeigt wird. Abgerundet werden die Ausführun­gen mit einem Ausblick in die Zukunftsperspektive.

3. Überblick über die relevanten Regelwerke

Um einen groben Überblick über die Normen im IT-Bereich zu erhalten, werden diese hier kurz aufgelistet:

o EN ISO 9001:2008 o EN ISO 20001:2005 o ITIL V2 o ITIL V3

Da die vorliegende Arbeit sich nur mit ITIL Version 2 und 3 beschäftigt, werden die Normen ISO 9001:2008 und 20001:2005 nur rudimentär in beiden nachfol­genden Kapiteln beschrieben. Nähere Details können in Fachbüchern und im In­ternet nachgelesen werden.

3.1. EN ISO 9001:2008

Die EN ISO 9001:2008 ist eine Qualitätsmanagementnorm, die ein Regelwerk beschreibt, welche die Anforderungen an QM-Systeme beschreibt und für Weiter­entwicklung und Kontinuität steht. Der prozessorientierte Ansatz steht im Vor­dergrund und ermöglicht dadurch eine Erleichterung bei der Umsetzung in der Praxis. Zu Beginn müssen die sieben Prinzipien der Norm verstanden werden, damit das Prozessmodell erstellt werden kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Prozessmodell IS09001²

Eine Aufstellung allgemeiner Qualitätsprinzipien findet sich bei Scheiber wie folgt: „Prinzip 1 - Kundenorientierte Organisation

Organisationen hängen von ihren Kunden ab und sollten daher die aktuellen und künftigen Erfordernisse der Kunden verstehen, die Kundenanforderungen erfüllen und danach streben, die Kundenerwartungen zu übertreffen.

Prinzip 2 - Führung

Das Management gibt ein einheitliches Ziel und die Richtung der Organisation vor. Es sollte ein internes Umfeld schaffen und erhalten, in dem Mitarbeiter sich voll für das Erreichen der Ziele der Organisation einsetzen können

Prinzip 3 - Beteiligung der Mitarbeiter

Mitarbeiter aller Ebenen sind der Kern einer Organisation, und ihre volle Beteili­gung ermöglicht, dass ihre Fähigkeiten zum Vorteil der Organisation genützt werden können.

Prinzip 4 - Vorgehen mittels Prozessen

Ein erwünschtes Ergebnis wird dann wirksam erreicht, wenn die betroffenen Res­sourcen und Aktivitäten als Prozess gesteuert werden.

Prinzip 5 - Vorgehen mittels Systemen

Um die Effizienz einer Organisation zu verbessern, wird als bestimmtes Ziel das Identifizieren, das Verstehen und das „Managen" eines Systems in zusammen­hängenden Prozessen verstanden. (vgl. dazu Konrad Scheiber, ISO 9000 - Die große Revision, S. 74)

Prinzip 6 - Ständige Verbesserungen

Ständige Verbesserungen sollten stets die Zielsetzung einer Organisation sein.

Prinzip 7 - Sachliches Vorgehen bei Beschlussfassung

Wirksame Entscheidungen basieren auf der Analyse von Daten und Informatio­nen.

Prinzip 8 - Für beide Seiten vorteilhafte Lieferantenbeziehungen

Eine Organisation und ihre Lieferanten sind voneinander abhängig, für beide Sei­ten vorteilhafte Beziehungen steigern die Fähigkeiten beider, Werte zu schaf­fen."³

Anhand der vorliegenden Prinzipien werden die einzelnen Prozesse des Quali­tätsmanagementsystems definiert und beschrieben. Jedes Unternehmen gibt die Form und die Struktur des Systems vor, welche und wie viele Prozesse aufgebaut werden. Natürlich bedeutet jeder Prozess Arbeit, Zeit und Verantwortung, die nicht vernachlässigt werden dürfen. Außerdem müssen diese Prozesse gelebt und weiterentwickelt werden. Jeder Prozess besitzt einen Prozessmanager, der sich um die inhaltlichen Belange kümmert und im Unternehmen verankert. Mittels Kommunikation und aktiver Mitarbeit werden die Prozesse transportiert, damit auch diese gelebt werden. Meistens erhalten Führungskräfte oder angesehene Mitarbeiter in einem Unternehmen die Rolle des Prozessmanagers, damit eine erfolgreiche Umsetzung möglich ist.

3.2. EN ISO 20001:2005

Die ISO 20001 ist ein international anerkannter Standard zum IT Service Mana­gement, in dem die Anforderungen für ein IT Service Management beschrieben sind. Diese Norm entstand ursprünglich aus dem British Standard 15000 und dient zur standardisierten Prozessdarstellung von IT-Services, die bei erfolgrei­cher Umsetzung zertifiziert werden kann. Die notwendigen Mindestanforderungen an die Prozesse sind in der ISO 20001 detailliert beschrieben. Die Unternehmen müssen diese Anforderungen umsetzen, um die IT-Services in definierter Qualität bereitstellen und managen zu können. Diese Norm ist sehr stark an ITIL Version 2 mit dem Best Practices Ansatz angelehnt. Dieser Standard ist derzeit der einzi­ge, in dem die Anforderungen für ein professionelles IT Service Management do­kumentiert sind.

Die BS 15000 wurde mittels eines „fast tracking" Verfahrens in die ISO 20001 übergeleitet, damit ein internationaler Standard für IT Service Management­Prozesse zur Verfügung stand. Dies wurde durchgeführt, damit eine international anerkannte Zertifizierung von IT-Organisationen möglich ist. Von geringen Ände­rungen abgesehen, Ende 2006 wurde die ISO 20001 offiziell veröffentlicht und ersetzte damit die BS 15000, der erste Meilenstein im IT-Bereich wurde gelegt.

Die IT Service Management Prozesse können lediglich auf Basis der ISO 20001 zertifiziert werden. Wie bei der ISO 9001 gibt es operative und unterstützende Prozesse, sowie Managementprozesse. Die ISO 20001 „IT Service Management" dient als messbarer Qualitätsstandard im IT Service Management. Die Norm be­schreibt die notwendigen Prozesse, die ein Unternehmen einführen muss, um IT- Services in definierter Qualität zur Verfügung zu stellen und managen zu können.

Wenn die Vorarbeiten für die Einführung einer ISO 20001 Norm geleistet wurden, kann eine Zertifizierung durchgeführt werden. Dadurch besteht endlich eine Mög­lichkeit, den internationalen Standard zu zertifizieren, wobei die Inhalte des Standards vorausgesetzt werden.

Die ISO 20001 ist derzeit der einzige offizielle Standard für das IT Service Mana­gement. Daher kann lediglich eine Unternehmenszertzifierung auf Basis dieses Standards erfolgen. Eine Zertifizierung auf Basis von ITIL ist nicht möglich und findet daher auch keine Anerkennung. Die Etablierung der von der ISO 20001 geforderten Prozesse erfordert ein Prozessdesign, welches von ITIL - Best Practi­ce als Prozess-Empfehlung idealerweise herangezogen werden kann.

Im IT-Bereich werden sich die IT-Dienstleister in nächster Zeit auf eine ISO 20001 Zertifizierung vorbereiten. Dadurch wird die ISO 9001 sicherlich in diesen Bereich in Hintergrund gedrängt. Langfristig wird erwartet, dass die ISO 20001 für IT-Dienstleister wichtiger als die ISO 9001 sein wird.

Das Regelwerk der ISO 20001 beschreibt nicht, wie die Leistungserbringung der IT-Services erbrachtet werden muss, sondern welche Bereiche erfasst werden müssen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Prozessmodell ISO 20001 [4]

Um die ISO 20001-Zertifizierung zu erhalten, muss das Unternehmen den Nach­weis bringen, dass einerseits alle Prozesse der ISO 20001 umgesetzt sind und andererseits diese Prozesse einem Management Control des IT-Bereichs unterlie­gen. Erst wenn diese Nachweise vorliegen und das erstmalige Zertifizierungsau­dit durch das akkreditierte Unternehmen ohne Abweichungen verlaufen ist, kann das Zertifikat überreicht werden.

Die erwähnte Management Control wird in Kriterien festgelegt, die wie folgt aus­sehen:

- Input muss bekannt und steuerbar sein
- Output muss bekannt, anwendbar und auswertbar sein
- Messungen von Services und Prozessen müssen festgelegt und durchgeführt werden[2]
- Zuständigkeit und Funktionalität der internen Prozesse müssen objektiv nach­gewiesen werden
- Prozessverbesserungen müssen festlegbar, meßbar und überprüfbar sein

3.3. Überblick ITIL Version 2

Die Information Technology Infrastructure Library (ITIL) stellt einen De-facto- Standard im Qualitätsmanagement dar, der im IT-Bereich Einzug gefunden hat. Ursprünglich basiert ITIL auf den Erfahrungen von aus dem anglikanischen Raum stammenden IT-Spezialisten, die in einer Sammlung von Best Practices Nieder­schlag gefunden haben. In den 1980er Jahren begann die Thatcher-Regierung in England mit dem Sammeln dieser Werke. Diese Sammlung dient nun IT- Unternehmen, um deren oder fremden Dienstleistungen hinsichtlich Planung, Un­terstützung und Umsetzung qualitativ höherwertiger, kostengünstiger und kun­denorientierter abwickeln zu können. Die Computer and Telecommunications Agency (CCTA) der britischen Regierung präsentierte im Jahr 1989 die Inhalte bzgl. ITIL zur Qualitätssicherung der IT.

Für jeden Prozess sind Key Performance Indikatoren und Erfolgsfaktoren vorhan­den, die in der Diplomarbeit von Schroll[5]ersichtlich sind.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Rahmenstruktur des ITIL-Modells V[6]

In der Abbildung 3 ist das ITIL-Modell V2 mit allen beteiligten Prozessen und an­grenzenden Bereichen ersichtlich. Das Service-Management mit den beiden Pro­zessen Service Support und Service Delivery steht im Zentrum. Im Focus der Betrachtung befinden sich weiters auch noch folgende Themen: Geschäftsprozes­se, Kunden, Lieferanten und IT-Management. Die Korrelationen zwischen dem IT-Service Management und den angrenzenden Bereichen werden mit den Inhal­ten der ITIL Version 2 gefüllt und erhalten durch den Best Practice Ansatz die praxisorientierte Erfahrung, die für Standards normalerweise nicht vorliegen. ITIL V2 zeigt eine große Anzahl von vordefinierten Prozessen auf, die im IT-Umfeld genutzt werden können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Prozessübersicht ITIL V2[7]

Der Service Desk und das Security Management befinden sich in der Tabelle, obwohl beide keine Prozesse sind, sondern Funktionen. ITIL V2 sieht hier keine expliziten Prozesse vor, da sich die Inhalte ursprünglich in bestehenden Prozes­sen befanden und aufgrund ihrer Relevanz, und der Weiterentwicklung von ITIL eine besondere Bedeutung zugesprochen wurde.

In den weiteren Ausführungen werden die inhaltlichen Gründe für die Implemen­tierung von Funktionen klarer dargestellt.

3.3.1. Service Support

Die Prozesse des Service Supports umfassen die operativen Themen eines IT- Dienstleisters und verstehen sich als Pflichtübung, um im täglichen Gebrauch auf etablierte und funktionierende Abläufe und Vorgehensweisen zurückgreifen zu

können. Umso besser die Prozesse des Dienstleisters umgesetzt werden, umso einfacher gestaltet sich die Zusammenarbeit mit dem Kunden, dadurch stehen die Dienste des Kundens immer im Vordergrund, der Dienstleister ist nicht mit sich selbst beschäftigt.

З.З.1.1. Service Desk

Der Service Desk als Single Point of Contact (SPoC) dient dem IT-Dienstleister als erste Anlaufstelle für Kunden, um Probleme, aber auch Fragen zentral zu erfassen und wenn möglich, auch im SpoC zu lösen. Probleme und Fragen, zu­sammengefasst unter dem Namen Anforderungen, werden in einem zentralen und Workflow basierten EDV-System gespeichert. Dieses Tool benötigt zusätz­lich eine Schnittstelle zum Change Management (siehe Change Management).

Die oberste Aufgabe des Service Desks besteht darin, rasche und effektive Lö­sungen zu erbringen. Wenn dies nicht möglich ist, aus welchen Gründen auch immer, sind die Spezialisten des 2nd-Level-Supports gefordert. Diese Mitarbei­ter besitzen Spezial Know how, das zur Lösung von Problemen bzw. Anforde­rungen dient. Die Mitarbeiter des Service Desks kümmern sich weiterhin um die Probleme des Anwenders, da die Spezialisten nach der Lösungsbehebung eine Rückmeldung an den Service Desk machen. Erst wenn der Endkunde mit der Lösung zufrieden ist, wird das erfasste Ticket abgeschlossen (siehe Inci­dent M.). Diese Tickets bilden den ersten Input für das IT Service Manage­ment. Informationen sind sehr essentiell für notwendige Änderungen, Einflüsse und Adaptierungen in anderen Bereichen wie zB Change Management, Availa­bility Management, aberauch Continuity Management.

In einer zentralen Wissensdatenbank (Known Error Database) werden die Lö­sungen festgehalten, die für mögliche Lösungsbehebungen von neuerlichen Fehlern gebraucht werden. In der Known Error Datenbank werden Störungen mit bekannten Ursachen gespeichert, diese Fehler sind noch nicht gelöst. Für diese Fehler gibt es in manchen Fällen eine Umgehungslösung oder sogar nur

eine Beschreibung. Diese Errors werden im Problem Management abgehandelt (siehe Problem M.), um nachhaltig gelöst zu werden.

Die Organisation von Service Desks kann sich von Unternehmen zu Unterneh­men unterscheiden, in der ITIL-Literatur wird von lokalen, zentralen und virtu­ellen Service Desks gesprochen.

3.3.1.2. Incident Management

Wie bereits im Kapitel Service Desk beschrieben, dient der Prozess Incident Management zur raschen und unmittelbaren Behebung von Problemen und Störungen. Zusätzlich werden Anforderungen (Service Request) des Anwen­ders abgehandelt. Oberste Prämisse ist die rasche Wiederherstellung von Diensten, wobei als erste Annäherung auch zielführende Umgehungslösungen für die Aufrechterhaltung des Betriebs reichen.

In diesem Zusammenhang muss der Begriff Service Level Management ge­nannt werden, da in diesem Prozess Vereinbarungen (Service Level Agree­ment) in Richtung Leistung, Verfügbarkeit und Erreichbarkeit u. a. zwischen IT-Dienstleister und Kunden getroffen werden. Diese Vereinbarungen beziehen sich auch auf die Erstlösungsrate des Helpdesks und dies hat explizit Einfluss auf die Verfügbarkeitsrate von Hard- und Software. Deshalb ist die genaue zeitliche Erfassung vom Auftritt eines Fehlers bis hin zur Lösung wichtig, da dies die Basisdaten für die Erfüllung eines Service Level Agreements sind.

3.3.1.3. Problem Management

Das Problem Management behandelt Probleme und Störungen, die nicht im Incident Management ursprünglich gelöst wurden. Nachhaltige Lösungen sind hier gefragt, wobei auf endgültige Lösungen, aber auch auf Umgehungslösun­gen gesetzt wird. Dieser Prozess dient zur kontinuierlichen Verbesserung be­stehender Abläufe und Systeme, wobei vorausschauend auf ähnliche oder bei-nahe gleiche Fehler großes Augenmerk gelegt wird. Die Fehleranalyse wird in diesem Bereich proaktiv durchgeführt, um eine stabilere Servicestruktur dem Kunden anbieten zu können.

Der IT-Dienstleister trägt Sorge, einmalig oder mehrmalig aufgetretene Errors oder Anomalien mit diesem Prozess zu beseitigen. Auf Basis dieser Erkenntnis­se werden gleiche und ähnliche Konstellationen auf diese Fehler untersucht. Die Problembehebung samt Beschreibung finden sich in der Known Error Da­tenbank und werden mit den aufgetretenen Fällen, sprich Problem Requests verlinkt. Die erarbeiteten Lösungen dürfen lt. der Norm nicht einfach einge­setzt werden, sondern werden mittels Request for Change (RfC) dokumentiert. Dieser Antrag beinhaltet einerseits die Begründung einer produktiven Änderung und andererseits den Verweis zur Known Error Datenbank. Eigent­lich gehören RfC zum Change Management, wobei das Problem Management eine enge Schnittstelle darstellt.

З.З.1.4. Change Management

Dieser Prozess kümmert sich um einen standardisierten Ablauf, um Änderun­gen von produktiven Komponenten durchzuführen und zu dokumentieren. Re­quest for Change ist die Grundlage, worauf dieser Prozess aufbaut. Alle Ände­rungen, In- aber auch Außerbetriebnahmen von Hard- und Software müssen zentral in einem Tool erfasst und dokumentiert werden. Diese Requests sollten Informationen über Thema und Grund der Änderung, Einsatzdatum, vermeint­licher Auftraggeber, Verantwortlicher der Umsetzung, Risikoabschätzung und Rückstiegsszenario bei Misserfolg, Auswirkung auf Produktion und Resumé der Änderung beinhalten.

Bevor die herkömmlichen Requests durchgeführt werden, müssen diese das Change Advisory Board (CAB) passieren und erhalten dort die endgültige Au- torisierung zur Umsetzung. Das CAB ist ein Gremium, das sich aus allen Betei­ligten, die mittelbar und unmittelbar von Änderungen betroffen sind, dem Change Manager und auch Kunden zusammensetzt und das periodisch tagt. Bei diesen periodischen Sitzungen werden alle anstehenden Änderungen be­sprochen und im Kontext mit den Beteiligten autorisiert.

Wenn dringende Änderungen erforderlich sind, die einen Incident bzw. ein Problem darstellen, können diese als Urgent Change abgehandelt werden. Diese Urgent Changes werden unter Berücksichtigung der anstehenden Änderungen vom CAB-Leiter direkt freigegeben.

Geringfügige Änderungen und die eben genannten Urgent Changes werden vom CAB-Leiter behandelt und beim nächsten Change Advisory Board nachbe­sprochen. So wird verhindert, dass irgendwelche Changes ohne Information und Zustimmung in der Produktion übernommen werden. Der kontinuierliche Verbesserungsprozess steckt hier ebenfalls dahinter und soll neu gesammelte Erfahrungen in den tatsächlichen Ablauf bringen.

З.З.1.5. Configuration Management

Im Configuration Management werden alle Informationen und Daten über Hard- und Software gesammelt, die zur Übersicht der gesamten IT-Landschaft dienen. Unter Informationen und Daten werden in erster Linie die Konfigurati- ons- und Leistungsparameter von IT-Komponenten verstanden, die zentral in einer Configuration Management Database (CMDB) gespeichert werden. Jeder Systembetreuer muss alle betreuten Systeme, sowie alle Zusammenhänge (Relationen) mit anderen Komponenten eintragen und pflegen. Dadurch ergibt sich ein Netzplan von verwendeter Hard- und Software, sowie Dienste, die für den Betrieb erforderlich sind. Der Sinn hinter dieser Übung liegt auf der Hand - Inventarisierung und Wissensmanagement. Der IT-Dienstleister muss in ers­ter Näherung wissen, welche und wie viele Maschinen im Feld sind und welche Software darauf läuft. Diese Informationen sind in allen Prozessen sehr wichtig und werden überall benötigt. Das Change Management bezieht sich auf diese erwähnten Hard- und Software-Komponenten und der Service Desk weiß da-durch, welche Änderungen stattgefunden haben, damit im Fehlerfall Rück­schlüsse gezogen werden können.

Die Inhalte der CMDB sind sogenannten Configuration Items (CI), welche die IT-Landschaft im Unternehmen widerspiegelt.

Die fünf grundlegenden Aktivitäten des Configuration Managements sind wie folgt[3]:

- Planung der Strategien, Grundsätze, Umfänge, Ziele, Rollen und Verant­wortungen
- Identifizierung und Spezifizierung des Datenmodells, Kategorisierung, Er­fassung und Namensgebung der CI
- Kontrolle auf Aktualität, Gültigkeit und Korrektheit der Inhalte; Aufdeckung von nicht genehmigter, realisierter oder nicht dokumentierter Changes
- Dokumentation jeder Änderung durch Statusnachweis und Führung histori­scher Daten
- Verifizierung und Audit der vorhandenen CMDB mit Realität

З.З.1.6. Release Management

Die oberste Aufgabe des Release Managements ist der geordnete und geplante Einsatz von Gesamtpaketen in Form von Hard- oder Software. Diese Aufgabe ist aber auch in Kombination mit dem Produktionsbereich zu sehen. Als Re­lease wird eine abgeschlossene, getestete und freigegebene Version von Pro­grammen bzw. Hardwarekomponenten verstanden. Der Vorteil eines Releases besteht in der klar definierten und abgehandelten Thematik, die in sich abge­schlossen ist. Diese Pakete werden in Abhängigkeit und Zusammenspiel der bereits vorhandenen Programme und Hardware-Komponenten überprüft, ob weitere Systeme dadurch betroffen sind oder welche Auswirkungen auf

Schnittstellen gegeben sind. Im Release Management werden die Release Poli­cies festgelegt und verwaltet.

Folgende unterschiedliche Typen von Releases verstehen sich unter Version 2:

- Vollrelease
- Deltarelease
- Package-Release
- Emergency-Fixes

Alleine durch die unterschiedlichen Typen von Releases ergeben sich Anknüpfungspunkte zum Change, aber auch Configuration Management. Ei­nerseits muss jedes Release im Change Management als ein oder mehrere Change Requests Niederschlag finden, den CAB passieren und andererseits müssen die geänderten bzw. neuen Configuration Items in der CMDB gewartet werden. Zusätzliche Dokumente wie zB Ablaufpläne, Beschreibungen, Testpro­tokolle und Fehlerbehebungen müssen dem RfC beigelegt werden, da diese für das Release Management und das CAB relevant sind.

In diesem Zusammenhang werden Definitive Software Library (DSL) und Defi­nitive Hardware Store (DHS) erwähnt, wo zentral die originalen Softwarestän­de und Hardwarekomponenten gespeichert werden. Diese sind mit der CMDB verbunden.

3.3.2. Service Delivery

Service Delivery ist der zweite große Bereich der ITIL V2, der sich mit der Unter­stützung und dem Management der operativen Aufgaben der Services beschäf­tigt. Mit diesem Set an Prozessen soll dem IT-Dienstleister eine Optimierung der Planungs- und Steuerungsaufgaben gelingen. Optimierung in diesem Zusam­menhang versteht sich als vorausschauende, begleitende und unterstützende Aktion, die in den weiteren Ausführungen noch detaillierter beschrieben werden.

Meistens werden die Service Delivery Prozesse im Anschluss der Service Support Prozesse erstellt, da die Pflichtübung im Service Support und die Kür im Service Delivery liegen. Zumindest die Schnittstellen der Service Delivery Prozesse müs­sen bei der Etablierung der Service Support Prozesse in die Gesamtbetrachtung fließen, um von Beginn an das Verständnis und den Focus zu erhalten.

З.З.2.1. Availability Management

Availability Management steht für optimale Verfügbarkeit von IT-Services und gegen Null gehende Ausfallsraten für die Kunden. Die geschäftskritischen Ein­heiten, auch Vital Business Functions (VBF) genannt, sind jene IT-Dienste, die besondere Betreuung und Behandlung vom Dienstleister benötigen. Überle­gungen von erforderlichen Investitionen in Richtung Hardware, Software und auch menschlichen Ressourcen werden getroffen, um die jeweilig geforderte Zuverlässigkeitsstufe einhalten zu können. Methoden, Abläufe und Vorge­hensweisen, die diese Voraussetzungen schaffen, befinden sich im vorliegen­den Availability Management.

Folgende fünf Punkte sind in dieser Betrachtung von äußerster Relevanz:

1. Verfügbarkeit
2. Zuverlässigkeit
3. Wartbarkeit (einfache Bedienung der Services, um den normalen Zustand wieder zu erreichen, Reduzierung der Komplexität)
4. Servicefähigkeit (Vorkehrungen zu treffen, um die Betreuung respektive Wartung durchzuführen; Verpflichtungen mit externen Partnern eingehen)
5. Sicherheit (Sicherstellung der Schutzmaßnahmen für Services)

Die Herausforderung des IT-Dienstleisters liegt in der Erfüllung von Kundenan­forderungen, die sich in Form von Zuverlässigkeit und Verfügbarkeit in defi­nierten Zeiteinheiten darstellen. Die Kunst liegt nun in der Umsetzung, damit der geforderte Erfüllungsgrad unabhängig von der Komplexität erfüllt wird.

Vereinbarungen zwischen Kunden und IT-Dienstleister werden im sogenannten Service Level Agreement (SLA) zusammengefasst (siehe Service Level Mana­gement). Der SLA stellt die Basis für die Planung und das fachliche Verständ­nis des Auftragnehmers dar und gibt Aufschluss über notwendige Redundan­zen, zusätzliche Hardware und bei Notwendigkeit über den Aufbau neuer Mit­arbeiter. Hiermit wird die IT-Infrastruktur und das Know how entsprechend festgelegt, um die bekannten Kundenwünsche zu befriedigen. Daraus ergeben sich unter Umständen Synergieeffekte oder neue Betätigungsfelder, die durch Unterkapazitäten gefüllt werden müssen.

Der Grundgedanke der proaktiven und ständigen Verbesserungen unterstützt das Availability Management, um die anfallenden Kosten und das permanenten Dauerschuldverhältnis vor Augen zu führen. Der Kostenfaktor beeinflusst we­sentlich die Zusammenarbeit von Kunde und Auftragnehmer. Überzogene An­forderungen seitens des Kundens gehen Hand in Hand mit anfallenden erhöh­ten Kosten. Der Dienstleister muss hier Fingerspitzengefühl zeigen, dass Zu­verlässigkeit und Verfügbarkeit in Relation mit Preis und Zufriedenheit des Kundens stehen.

Das Availability Management beinhaltet ebenfalls Methoden und Arbeitsweisen zur Risikoanalyse. Risikoanalysen sind wichtige Aufgaben, um bestehende Ri­siken zu erkennen und in der Planung bzw. Umsetzung hinsichtlich Verfügbar­keit zu berücksichtigen. Daher werden im Availability Management Risikoana­lysen erstellt, die zur Einhaltung der notwendigen Verfügbarkeit beitragen. Diese zielorientierten Maßnahmen müssen im Anschluss umgesetzt werden.

Zur Ermittlung der Verfügbarkeit stehen im Availability Management folgende Methoden zur Verfügung, die wie folgt beschrieben sind:

Component Failure Impact Assessment (CFIA)

Das CFIA ist eine Methode, die CI identifiziert, welche zu Ausfällen führen können. Weiters stellt diese Methode fest, welche CI kein Backup besitzen. Die

Ausfallsrisiken für jedes einzelne CI werden mit diesem System evaluiert und geben Auskunft über das erforderliche Budget bzw. über künftige Investitio­nen. Diese Methode unterstützt u. a. Pflege und Wartung der Configuration Management Database.

Fault Tree Analysis (FTA)

Die FTA ermittelt in Form eines Wasserfallmodells die Ereignisse bei Unterbre­chungen von Services und stellt die dadurch betroffenen Schnittstellen und Systeme dar. Es wird zwischen Basic, Result, Conditional und Trigger Events unterschieden, die unterschiedliche Bedeutungen in der Analyse haben. Mit diesem Analysewerkzeug werden Gegenmaßnahmen zur Bekämpfung von Un­terbrechung erarbeitet.

Computer Risk Analysis & Management Methodology (CRAMM)

Die Analysemethode CRAMM beschäftigt sich mit den Vermögenswerten eines Unternehmens, die zuerst beurteilt werden. Anschließend werden diese Werte auf mögliche Bedrohungen analysiert. Daraus leiten sich Schwachstellen ab und eine Risikoabschätzung kann erstellt werden.

Service Outage Analysis (SOA)

Die Methode SOA hat die Verbesserung der Verfügbarkeit von Services als Ziel. Unter Beteiligung des Kundens wird diese Analyse durchgeführt. Jedes Service wird auf den Unterbrechungsgrad untersucht und mögliches Verbesse­rungspotential erarbeitet.

Das Security Management war früher im Availability Management inkludiert. Erfahrungen zeigten jedoch, dass die Etablierung von Schutzmaßnahmen für Services separat behandelt werden müssen. Datenschutz und Datensicherheit gehören eng zusammen und haben hohe Relevanz für Kunden. Deshalb erhielt das Security Management eine Funktion, die im weiteren Verlauf der Arbeit beschrieben ist.

[...]

---

¹ vgl. Schroll J. (2006)

² Information technology - Service Management, Part 1 (2005)

³ vgl. Schroll (2006)