Methodik zur Informations- und Datenmodellierung in IT-Service-Management-Prozessen: Die ITIL®-Prozesse 'service level management' und 'configuration management'

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung
1.1 Motivation
1.2 Aufgabenstellung und Zielsetzung
1.3 Vorgehensmodell

2 Einordnung der Arbeit
2.1 Terminologie
2.2 IT Service Management
2.3 IT Infrastructure Library (ITIL)
2.3.1 Ziele der ITIL
2.3.2 Bestandteile der ITIL
2.3.3 Nutzen der ITIL
2.3.4 Kritische Bewertung der ITIL
2.4 Enhanced Telecom Operations Map (eTOM)
2.4.1 Ziele der eTOM
2.4.2 Bestandteile der eTOM
2.4.3 Nutzen der eTOM
2.4.4 Kritische Bewertung der eTOM
2.4.5 Vergleich eTOM und ITIL
2.4.6 Konsequenzen
2.5 Bestehende Ansätze zur Modellierung
2.5.1 Vorhandene Informations- und Datenmodelle
2.5.2 Methoden zur Modellierung
2.6 Shared Information and Data Model (SID)
2.6.1 Ursprung und Aufbau des SID
2.6.2 Informationsmodellierung im SID
2.6.3 SID-Sichten
2.7 Operations Support Systems through Java (OSS/J)
2.8 Model Driven Architecture (MDA)
2.9 Abgrenzung der Arbeit

3 Methodik zur Informations- und Datenmodellierung im ITSM
3.1 Analyse von Artefakten
3.1.1 Identifikation von Artefakten
3.1.2 Identifikation von Beziehungen zwischen Artefakten
3.2 Modellierung von Artefakten
3.2.1 Artefakte und Beziehungen
3.2.2 Anleihe von SID-Konzepten
3.3 Fazit der Modellierung

4 Analyse der Artefakte aus der ITIL
4.1 Identifikation von ITIL-Artefakten
4.1.1 Plan-Artefakte
4.1.2 Dokumentations-Artefakte
4.1.3 Bericht-Artefakte
4.1.4 Datensatz-Artefakte
4.1.5 Datensammlungs-Artefakte
4.1.6 Abbildung von Dingen auf Artefakte
4.1.7 Abbildung von Analysen auf Artefakte
4.1.8 Abbildung von Projekten auf Artefakte
4.2 Beziehungen der Artefakte aus dem SLM
4.2.1 Das Dienst-Artefakt
4.2.2 Das Service Catalogue-Artefakt
4.2.3 Das Service Level Agreement-Artefakt
4.2.4 Das Support Arrangement-Artefakt
4.2.5 Das Operational Level Agreement-Artefakt
4.2.6 Das Underpinning Contract-Artefakt
4.2.7 Das Service Achievement-Artefakt
4.2.8 Das Service Achievement Report-Artefakt
4.2.9 Das Service Improvement Plan-Artefakt
4.2.10 Das Service Level Requirement-Artefakt
4.2.11 Das Specsheet-Artefakt
4.2.12 Das Service Quality Plan-Artefakt
4.3 Beziehungen der Artefakte aus dem CM
4.3.1 Das CMDB-Artefakt
4.3.2 Das Configuration Record-Artefakt
4.3.3 Das Configuration Baseline-Artefakt
4.3.4 Das Configuration Structure-Artefakt
4.3.5 Das Licence-Artefakt
4.3.6 Das Configuration Management Plan-Artefakt
4.3.7 Das Configuration Management Policy-Artefakt
4.3.8 Das Configuration Report-Artefakt
4.3.9 Das Configuration Documentation-Artefakt
4.3.10 Anmerkung zu Systemen
4.4 Zusammenfassung der Analysephase

5 Modellierung der Artefakte aus der ITIL
5.1 Modellierung der Artefakte aus dem SLM
5.2 Modellierung der Artefakte aus dem CM
5.3 Übertragung von Konzepten aus SID
5.3.1 Konzepte aus dem Bereich SLM
5.3.2 Vergleich der SID-Konzepte mit dem ITIL-Bereich SLM . .
5.3.3 Konzepte aus dem Bereich CM
5.3.4 Vergleich der SID-Konzepte mit dem ITIL-Bereich CM
5.4 Ansatz zur Umsetzung der Modelle
5.5 Zusammenfassung der Modellierungsphase

6 Zusammenfassung und Ausblick
6.1 Zusammenfassung
6.2 Ausblick

A Korrelationen ITIL, eTOM und SID

B Konsolidierung der ITIL- und SID-Modelle

Literaturverzeichnis

Zusammenfassung

Die hohe Abhängigkeit der Unternehmen von Diensten, die durch teilweise sehr komplexe IT- Systeme ermöglicht werden, trägt zunehmend dazu bei, dass das Management dieser Dienste von immer mehr Unternehmen als geschäftskritisch erkannt wird. Das Management der Prozesse, die diese Dienste ermöglichen, erfordert Tools, die nicht nur die klassischen infrastrukturellen Aspekte des IT-Managements abdecken, sondern vielmehr die Diensterbringung durch die Unterstützung ihrer Managementprozesse gewährleisten. Gerade in diesem Bereich mangelt es an Standardisie- rung.

Die IT Infrastructure Library (ITIL) als derzeitiger De-Facto-Standard im IT Service Management bietet Hilfestellung für die prozessseitige Unterstützung der Dienste. Jedoch fehlt ein Informationsmodell, an das sich Toolentwickler für eine ITIL-konforme Tool-Unterstützung orientieren können. Das im Telekommunikationssektor entstandene IT Service Management-Rahmenwerk enhanced Telecom Operations Map (eTOM) liefert mit dem Shared Information and Data Model (SID) ein eTOMspezifisches objektorientiertes Informationsmodell.

Für eine ITIL-konforme Toolentwicklung ist ein Informationsmodell erforderlich, das die Konzep- te der ITIL in einer standardisierten Form beschreibt. Im Rahmen dieser Diplomarbeit wird eine Methodik erarbeitet, die versucht diese Lücke zu schließen. Dabei werden alle ITIL-Artefakte zu- sammen mit den Beziehungen zu anderen Artefakten und Prozessen identifiziert und anschließend im Kontext der beiden Prozesse Service Level Management und Configuration Management auf ein objektorientiertes Informationsmodell abgebildet. Um praxisnahe Konzepte, für die es bereits Teilimplementierungen gibt, in das ITIL-Informationsmodell einfließen zu lassen, wird schließlich ein Vergleich der ITIL-Artefakte mit Konzepten aus dem SID durchgeführt. Das im Rahmen die- ser Arbeit entwickelte Informationsmodell bildet die Grundlage für eine Toolentwicklung nach den Prinzipien der Model Driven Architecture (MDA).

Abbildungsverzeichnis

1.1 Gliederung der Arbeit

2.1 Beispiele für Prozessartefakte aus der ITIL

2.2 Einordnung des Informationsmodells im morphologischen Kasten

2.3 Zusammenhang Informations- und Datenmodell

2.4 Prozessbegriff der ITIL [OGC 01, B.1.3]

2.5 ITIL und ISO 20000 (in Anlehnung an [Macf 06, S. 51] und [KBSt 06, S. 20])

2.6 Verwendete Rahmenwerke zur IT-Prozessoptimierung (in Anlehnung an [SZD 04]) .

2.7 Prozesse aus dem Bereich Service Support [OGC 00, Appendix F]

2.8 Prozesse aus dem Bereich Service Delivery [OGC 01, Appendix G]

2.9 Level 1 Prozesse des eTOM-Rahmenwerks (in Anlehnung an [TMF 07b, S. 22])

2.10 Die vier Sichten des NGOSS-Rahmenwerks (vgl. [TMF 04a, S. 14]

2.11 Abbildung der eTOM-Geschäftsbereiche auf Domänen des SID [TMF 05e, S. 9]

2.12 Zusammenhang OSS/J und SID [TMF 07c, S. 9]

3.1 Methodik zur Identifikation von Artefakten

3.2 Methodik zur Identifikation von Beziehungen zwischen Artefakten

3.3 Service und Service Spezifikation

3.4 Kompositum eines CustomerFacingService

3.5 Partei und Parteirolle (in Anlehnung an [Fowl 97])

3.6 Zeitbezogener Zustand [TMF 04b]

3.7 Eigenbeziehung von Projektaktivitäten [TMF 04b]

3.8 Methodik zur Modellierung von Artefakten

5.1 Das Dienst-Artefakt

5.2 Das Service Level Agreement-Artefakt

5.3 Die Artefakte OLA und UC

5.4 Das Artefakt Service Achievement

5.5 Informationsobjekte zu Service Achievement Report

5.6 Das Artefakt Service Improvement Plan

5.7 Das Artefakt Service Catalogue

5.8 Das Artefakt Service Level Requirement

5.9 Die Artefakte Service Quality Plan und Specsheet

5.10 Das CMDB-Artefakt

5.11 Das Configuration Record-Artefakt

5.12 Das Configuration Baseline-Artefakt

5.13 Das Configuration Structure-Artefakt

5.14 Das Configuration Documentation-Artefakt

5.15 Der Service-Begriff im SID [TMF 04c, S. 13]

5.16 Vereinfachtes SID-Produktmodell [TMF 04c, S. 12]

5.17 Produkt-Spezifikation und weitere Entitäten [TMF 04d, S. 13]

5.18 ServiceSpecification und Beziehung zu anderen Entitäten [TMF 04c, S. 27]

5.19 Dienst-Hierarchien des SID [TMF 04c, S.29]

5.20 ServiceRole und Beziehungen [TMF 04c, S. 41]

5.21 Service-Paket-Spezifikationen [TMF 04c, S. 53]

5.22 Beziehungen von ServiceLevelSpecification zu anderen Entitäten [TMF 04c, S. 66]

5.23 ServiceLevelObjectives [TMF 04c, S. 64]

5.24 Beziehungen von BusinessInteractionItems [TMF 05c, S. 12]

5.25 Geschäftsvereinbarungen mit Beziehungen [TMF 05b, S. 10]

5.26 Geschäftsvereinbarungen und SLAs

5.27 Konsolidierung SID / ITIL: Service

5.28 Konsolidierung SID / ITIL: SLA

5.29 Zusammenhang zwischen Diensten, Ressourcen und Produkten [TMF 06, S. 19]

5.30 Verschiedene Rollen von Ressourcen im SID [TMF 06, S. 103]

5.31 Ressourcen- und Produktspezifikationen im SID [TMF 06, S. 118]

5.32 ResourceUsage im SID [TMF 05d, S. 22]

5.33 Zusammenhang ITIL, SID und OSS/J

5.34 OSS/J-Entwicklung mit MDA durch XMF-Mosaic [GAC+ 04, S. 5]

B.1 Konsolidierung SID / ITIL: Dienst

B.2 Konsolidierung SID / ITIL: SLA

B.3 Konsolidierung SID / ITIL: OLA und UC

B.4 Konsolidierung SID / ITIL: Service Achievement

B.5 Konsolidierung SID / ITIL: Service Achievement Report

B.6 Konsolidierung SID / ITIL: Service Improvement Programme

B.7 Konsolidierung SID / ITIL: Service Catalogue

B.8 Konsolidierung SID / ITIL: Specsheet und Service Quality Plan

Tabellenverzeichnis

2.1 Vergleich eTOM und ITIL in Anlehnung an [Graw 03] und [Huan 05]

2.2 Perspektiven auf Informationsartefakte im SID

3.1 Beispieltabelle zur Identifikation von Artefakten

3.2 Vorlage eines Steckbriefs zur Identifikation von Beziehungen zwischen Artefakten

4.1 Artefakte vom Typ Plan

4.2 Artefakte vom Typ Dokumentation

4.3 Artefakte vom Typ Bericht

4.4 Artefakte vom Typ Datensatz

4.5 Artefakte vom Typ Datensammlung

4.6 Artefakte aus dem Bereich Service Level Management . .

4.7 Steckbrief Dienst

4.8 Steckbrief System

4.9 Steckbrief Service Catalogue

4.10 Steckbrief Service Catalogue Record

4.11 Steckbrief SLA

4.12 Steckbrief SLA Target

4.13 Steckbrief Support Arrangement

4.14 Steckbrief Operational Level Agreement

4.15 Steckbrief Underpinning Contract

4.16 Steckbrief Service Achievement

4.17 Steckbrief Internal Report

4.18 Steckbrief External Report

4.19 Steckbrief Service Improvement Plan

4.20 Steckbrief Action

4.21 Steckbrief Customer Feedback

4.22 Steckbrief Service Review Result

4.23 Steckbrief Service Level Requirement

4.24 Steckbrief Specsheet

4.25 Steckbrief Service Quality Plan

4.26 Artefakte aus dem Bereich Configuration Management

4.27 Steckbrief CMDB

4.28 Steckbrief Configuration Record

4.29 Steckbrief Configuration Baseline

4.30 Steckbrief Configuration Structure

4.31 Steckbrief Licence

4.32 Steckbrief Configuration Management Plan

4.33 Steckbrief Configuration Management Policy

4.34 Steckbrief Configuration Report

4.35 Steckbrief Configuration Documentation

5.1 Korrelationen aus den Bereichen Configuration und Service Level Management.

A.1 Primäre eTOM-Prozesse und ABEs die mit dem ITIL-Prozess SLM korrelieren

A.2 Sekundäre eTOM-Prozesse und ABEs die mit dem ITIL-Prozess SLM korrelieren

A.3 Primäre eTOM-Prozesse und ABEs die mit dem ITIL-Prozess CM korrelieren

A.4 Sekundäre eTOM-Prozesse und ABEs die mit dem ITIL-Prozess CM korrelieren

1 Einleitung

Dieses Kapitel gibt eine Einführung in die Thematik der Arbeit. Abschnitt 1.1 enthält die Motivation und das thematische Umfeld. Anschließend wird in Abschnitt 1.2 die Aufgabenstellung dargelegt. Schließlich wird in Abschnitt 1.3 das Vorgehen, das dieser Arbeit zugrunde liegt, beschrieben.

1.1 Motivation

Die meisten Unternehmen sind im hohen Maß von Informationstechnologie (IT) abhängig. Viele Kernprozesse von Unternehmen sind ohne den Einsatz von IT nicht mehr durchführbar. Zudem gibt es Produkte, die erst durch IT-Systeme ermöglicht werden. Dadurch steigt die Abhängigkeit des Geschäfts von der IT. Der Ausfall eines IT-Systems kann kritische Konsequenzen nach sich zie- hen und im schlimmsten Fall zum Verlust der Wettbewerbsfähigkeit des Unternehmens führen. Daher findet derzeit ein Wandel von technologieorientierten IT-Abteilungen zu kundenorientierten IT-Dienstleistern statt. Das Unternehmen tritt als Kunde der IT-Abteilung bzw. des IT-Dienstleisters auf, der einen Dienst in Anspruch nimmt.

Die Anforderungen an die IT sind durch verschiedene Betrachtungswinkel geprägt. Aus der Ge- schäftssicht werden abstrakte Dienste benötigt, welche die Durchführung der Geschäftsprozesse ermöglichen. Dabei stehen vor allem funktionale Aspekte im Vordergrund, die technische Realisie- rung ist in dieser Sicht nicht von Belang. Aus Sicht des IT-Dienstleisters stehen die Komponenten im Fokus, aus denen ein Dienst besteht, der die Geschäftsprozesse ermöglicht. Somit muss ein Dienst aus verschiedenen Blickwinkeln beschrieben werden. Informationen über diesen Dienst müssen so- wohl technische Details für den Betreiber als auch nichttechnische Informationen für den Nutzer enthalten.

Das IT Service Management beschäftigt sich mit der Aufrechterhaltung sowie der stetigen Verbes- serung der Dienste, um somit die Kundenzufriedenheit zu erhöhen. Dies schließt Maßnahmen und Methoden für die Vereinbarungen über die Dienstgüte in Zusammenarbeit mit Kunden, die Erfas- sung sowie Behebung von Störungen und die kontrollierte Änderung an der Infrastruktur mit ein. In Rahmenwerken zum IT Service Management, wie beispielsweise die IT Infrastructure Library (ITIL), werden Prozesse und Best Practices beschrieben, die sich zur effektiven und effizienten Aus- richtung der IT-Organisation im Hinblick auf die Serviceorientierung bewährt haben.

Der Umbruch hin zum IT Service Management hat sich auf organisatorischer Ebene bereits größten- teils vollzogen. Die Einführung von IT Service Management-Prozessen benötigt in vielen Bereichen eine Unterstützung durch geeignete Werkzeuge. Nachdem beispielsweise Service Level Agreements (SLAs) mit Kunden geschlossen wurden, muss deren Einhaltung überprüft werden und entspre- chende Berichte über die Diensterbringung verschickt werden. Des Weiteren beschreibt die ITIL die Configuration Management Database (CMDB) als zentrale Datenbank, die Informationen für alle IT Service Management-Prozesse vorhält. Bei einer Vielzahl von Diensten ist oftmals eine effiziente und effektive Unterstützung des Geschäfts ohne ein entsprechendes Managementtool nicht möglich.

Im Bereich des klassischen IT-Managements sind bereits zahlreiche Ansätze etabliert, jedoch mangelt es diesen an der Ausrichtung an IT Service Management-Prozessen. Darüber hinaus betrachten die Konzepte hauptsächlich technische und infrastrukturelle Aspekte, sie gewährleisten jedoch keine direkte Unterstützung der zugrunde liegenden Prozesse.

Im Bereich des IT Service Managements fehlt es an standardisierten Tools, welche alle Bereiche des Managements abdecken. Zwar gibt es proprietäre Lösungen, die sich selbst als ITIL konform bezeichnen, jedoch existiert kein Tool, das nachweislich alle Konzepte der ITIL im Sinne eines Stan- dards betrachtet. Ein Grund dafür ist sicherlich das Fehlen eines umfassenden und formalisierten Informationsmodells anhand dessen Datenmodelle abgeleitet werden können. Durch ein Informati- onsmodell wäre eine konforme Entwicklung eines Tools sowie dessen Standardisierung bzw. Zerti- fizierung möglich.

1.2 Aufgabenstellung und Zielsetzung

Der vorherige Abschnitt 1.1 hat bereits auf das Fehlen adäquater Tools für das IT Service Manage- ment hingewiesen. Bisherige Ansätze betrachten meist nur einzelne Konzepte oder Prozesse in Iso- lation und bieten dafür Hilfestellungen. Darüber hinaus werden die zugrundliegenden Konzepte unzureichend dokumentiert bzw. der Öffentlichkeit zur Verfügung gestellt, wodurch eine Wieder- verwendung auch in anderen Bereichen oder für andere Prozesse erheblich erschwert wird. Um von den Insellösungen hin zu einem kooperativen Ansatz zu gelangen, bei dem Informationen über Sy- stemgrenzen hinaus zur Verfügung stehen, ist ein gemeinsames Informationsmodell unabdingbar.

Ziel dieser Arbeit ist es eine Methodik zu entwickeln, mit deren Hilfe auf der Basis von Prozessbe- schreibungen aus einem Rahmenwerk (wie beispielsweise die ITIL) und der darin enthaltenen Best Practices, ein gemeinsames Informationsmodell abgeleitet werden kann. Die Methodik konzentriert sich dabei auf die Abbildung von Informationen über Artefakte sowie deren Beziehungen.

Im Rahmen der Aufgabenstellung ist darzulegen, wie Prozess-Artefakte sowie ihre Beziehungen zu- einander identifiziert werden können. Dazu ist zunächst der Artefakt-Begriff näher einzugrenzen. Des Weiteren soll erläutert werden, welche Mittel zur Modellierung verwendet werden können und, ob bestehende Ansätze hilfreich zur Zielerreichung sind. Insbesondere soll in diesem Zusammen- hang das Shared Information and Data Model (SID) näher betrachtet werden, das im Bereich des IT Service Managements ein umfangreiches Informations- und Datenmodell zur Verfügung stellt.

Im Fokus der Arbeit steht das ITIL-Rahmenwerk sowie die darin beschriebenen Prozesse Configura- tion Management und Service Level Management, für die Artefakte und deren Beziehungen identifiziert werden.

1.3 Vorgehensmodell

Im ersten Kapitel wurde das Thema motiviert sowie die Aufgabenstellung näher eingegrenzt, um in diesem Abschnitt das Vorgehen, das dieser Arbeit zugrunde liegt, aufzuzeigen.

Im Kapitel 2 wird zunächst das Thema thematisch eingeordnet, die wichtigsten Begriffe werden erläutert und es wird auf die Rahmenwerke IT Infrastructure Library (ITIL) und enhanced Tele- com Operations Map (eTOM) näher eingegangen. Anschließend werden Modellierungsmethoden aufgeführt und auf die Anwendbarkeit innerhalb dieser Arbeit geprüft. Überdies wird das SID, das Informations- und Datenmodell für eTOM, genauer betrachtet, da es derzeit das einzige Modell die- ser Art im Kontext des IT Service Managements darstellt. Daraufhin wird eine Initiative vorgestellt, die eine auf Java-Technologie basierende Implementierung des SID vorantreibt. Zudem wird dar- auf eingegangen, wie objektorientierte Modelle automatisiert auf Tools abgebildet werden können. Schließlich wird auf Forschungsarbeiten, die sich ähnlichen Themengebieten widmen eingegangen und die vorliegende Arbeit davon abgegrenzt.

Der Hauptteil der Arbeit beschäftigt sich mit der entwickelten Methodik sowie deren Anwendung auf Artefakte aus der ITIL. Im Kapitel 3 wird ein Vorgehen beschrieben, mit Hilfe dessen Artefakte und deren Beziehungen identifiziert werden können. Die Methodik ist in zwei Phasen aufgeteilt: Die erste Phase beschäftigt sich mit der Analyse der Artefakte sowie deren Beziehungen (Abschnitte 3.1 bzw. 3.1.2). In der zweiten Phase wird beschrieben, mit welchen Hilfsmitteln die Ergebnisse aus der Analysephase in einem Informationsmodell abgebildet werden können. Nachdem eine erste Mo- dellierung der Artefakte aus einem konkreten IT Service Management-Rahmenwerk durchgeführt wurde, werden im Abschnitt 5.3 die Modelle der Artefakte mit Konzepten aus dem SID verglichen.

Nach Einführung der Methodik, wird sie auf die Bereiche Configuration Management und Service Level Management der ITIL angewandt. Die erste Phase der Methodik ist in Kapitel 4 aufgeführt, die zweite Phase in Kapitel 5. Im Anschluss wird ein Ansatz skizziert, der beschreibt, wie die erstellten Modelle in ein Tool überführt werden können.

Abschließend werden die Ergebnisse der Arbeit in Kapitel 6 zusammengefasst und es wird ein Ausblick hinsichtlich der Anwendung der Ergebnisse gegeben. Abbildung 1.1 fasst die Gliederung der Arbeit grafisch zusammen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.1: Gliederung der Arbeit

2 Einordnung der Arbeit

Im Folgenden wird das Thema der vorliegenden Arbeit in den Kontext verwandter Themen gestellt. Zuerst werden wichtige Grundbegriffe erläutert. Dabei wird insbesondere auf prozessorientiertes IT Service Management eingegangen, es werden die beiden Rahmenwerke ITIL und eTOM vorgestellt, der Artefakt-Begriff näher eingegrenzt und Informations- und Datenmodelle charakterisiert. An- schließend werden gängige Modellierungsmethoden aufgeführt und bewertet, um danach auf das SID näher einzugehen, das derzeit als einziges objektorientiertes Informations- und Datenmodell im Bereich des IT Service Managements vorhanden ist. Schließlich wird auf die OSS/J-Initiative einge- gangen, die Implementierungen des SID-Standards veröffentlicht. Zudem werden die Konzepte der MDA vorgestellt mit deren Hilfe aus Modellen Tools erstellt werden können. Abschließend wird die zu bearbeitende Themenstellung von verwandten Forschungsarbeiten abgegrenzt.

2.1 Terminologie

Im folgenden Abschnitt werden wichtige Begriffe eingeführt, auf die im Laufe der Arbeit Bezug genommen wird. Zuerst wird der Artefakt-Begriff erläutert und er wird vom Begriff des Managementobjekts abgegrenzt. Anschließend wird der Begriff des Informationsmodells eingeführt und das zu erstellende Informationsmodell näher eingegrenzt. Schließlich wird eine Abgrenzung zwischen den Begriffen Informationsmodell und Datenmodell vorgenommen.

Artefakt

Artefakte sind „Enabler“ eines Prozesses. Sie umfassen Daten, die von IT Service ManagementProzessen erzeugt werden [BGSS 06, S. 6]. Das heißt, sie unterstützen einen Geschäftsprozess direkt, einen Dienst jedoch nur indirekt. Artefakte werden in der ITIL in Form von Informationscontainern beschrieben. Darunter zählen Dokumente, Pläne und allgemeine Datensammlungen (für Beispiele vgl. Abbildung 2.1). Diese Informationscontainer sind Eingaben bzw. Ergebnisse von Prozessaktivitäten. Im Bereich des Service Level Management s unterstützt beispielsweise ein SLA als Artefakt die Erbringung eines Dienstes nicht unmittelbar. Jedoch ermöglicht das Artefakt den ManagementProzess. Folgendes Beispiel soll diesen Zusammenhang verdeutlichen:

Ein SLA beinhalte Vereinbarungen bezüglich des Dienstes E-Mail. Zur Erbringung der Dienstlei- stung werden lediglich Infrastrukturkomponenten wie Server, Router, Netzwerkkarte oder Netz- werkkabel benötigt, jedoch keine vertraglichen Vereinbarungen mit dem Kunden über die Güte des Dienstes, wie sie in einem SLA beschrieben werden. Das Artefakt SLA unterstützt den Mana- gementprozess Service Level Management, indem es beispielsweise Zielvorgaben definiert, anhand derer überprüft werden kann, ob der Dienst im Rahmen der Vereinbarungen über die Dienstgüte erbracht wurde.

Managementobjekt

Der Begriff des Managementobjekts wurde vom Open System of Intercommunication (OSI) geprägt und umfasst Ressourcen, die durch das Netzmanagement überwacht und kontrolliert werden (vgl. [Blac 92, S. 11]). Somit wird der Begriff des Managementobjekts im klassischen Umfeld mit Netz- und Systemkomponenten verbunden. HEGERING, ABECK und NEUMAIR [HAN 99, S. 101] beschrei- ben Managementobjekte als eine Abstraktion realer Ressourcen des Managements zusammen mit

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Beispiele für Prozessartefakte aus der ITIL

ihren Eigenschaften. Dabei umfasst der Begriff des Managements „alle Maßnahmen für einen unter- nehmenszielorientierten effektiven und effizienten Betrieb eines verteilten Systems mit seinen Res- sourcen“ [HAN 99, S. 6]. Durch die Abbildung einer Ressource auf ein oder mehrere Management- objekte wird sie dem Management unterstellt. Die Menge aller Managementobjekte im Einflussbe- reich eines Managementsystems wird als Management Information Base (MIB) bezeichnet. Diese dient als Basis für Management-Werkzeuge zur Überwachung und Steuerung der Ressourcen. Wäh- rend Artefakte sich auf Prozessebene befinden und IT Service Management-Prozesse unterstützen, beschreiben Managementobjekte im klassischen Sinne Managementinformationen, die sich direkt einer Ressource zuordnen lassen, welche einen Dienst auf technischer Seite ermöglicht. Somit kön- nen Artefakte als Managementobjekte auf Prozessebene gesehen werden, die im Gegensatz zur ur- sprünglichen Definition von Managementobjekte den Managementprozess unterstützen und dabei nicht auf die technische Diensterbringung fokussiert sind. Im Rahmen dieser Arbeit wird einheit- lich der Artefakt-Begriff verwendet, wenn prozessbezogene Managementinformationen betrachtet werden.

Informationsmodell

Ein Informationsmodell stellt einen Rahmen für die Beschreibung von Managementobjekten be- reit. Dabei definiert es den Modellierungsansatz (objektorientiert oder datentyporientiert) und eine eindeutige Syntax für die Beschreibung und Spezifikation von Managementobjekten [HAN 99, S. 102]. Die Aufgabe des Informationsmodells ist die Definition der Identifikation, der Zusammen- setzung, des Verhaltens und der Manipulationsmethoden von Managementobjekten sowie deren Beziehung zu anderen Managementobjekten. Zudem definiert das Informationsmodell, wie das Managementobjekt über das Managementprotokoll angesprochen werden kann. Das Management benötigt keine detaillierte Übersicht über den gesamten Aufbau oder über interne Abläufe von Res- sourcen. Vielmehr müssen managementrelevante Parameter modelliert werden. Die Modellierung dieser Parameter geschieht über Managementobjekte [HAN 99, S. 101]. Entsprechend des Request for Comments 3444 [PrSc 03, S. 2] der Network Working Group beschreibt ein Informationsmodell Managementobjekte und deren Beziehungen untereinander auf konzeptioneller Ebene, das heißt unabhängig von der Implementierung, der Art der Datenhaltung oder dem verwendeten Protokoll. STRASSNER [Stra 04, S. 60] verfeinert die Definition dahingehend, dass ein Informationsmodell die Definition der Attribute, der Operationen, der Einschränkungen sowie der objektorientierten Bezie- hungen, wie Assoziationen, Aggregationen oder Kompositionen enthält.

Im Rahmen dieser Arbeit wird der Begriff Informationsmodell entsprechend der Definition von STRASSNER verwendet. Es umfasst also Managementobjekte und deren objektorientierten Bezie- hungen auf konzeptioneller Ebene. Anstelle der ursprünglichen Definition von Managementobjek- ten (siehe Abschnitt 2.1) werden in der vorliegenden Arbeit Artefakte und deren Beziehungen be- trachtet. Als Beschreibungsmittel für Informationsmodelle können sowohl formale Modellierungs- ansätze (wie beispielsweise UML-Klassendiagramme) als auch informale Methoden (beispielsweise die natürliche Sprache) dienen. Jedoch wird die Verwendung eines formalen objektorientierten An- satzes empfohlen [PrSc 03, S. 3]. Informationsmodelle können auf verschiedene Datenmodelle ab-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Einordnung des Informationsmodells im morphologischen Kasten

gebildet werden, welche die Informationsmodelle implementieren (vgl. Abschnitt 2.1). Beispiele für objektorientierte Informationsmodelle sind das Common Information Model der Distributed Ma- nagement Task Force sowie das Shared Information and Data Model des TeleManagement Forums (siehe Abschnitt 2.5.1).

Im Folgenden wird das in dieser Arbeit zu erstellende Informationsmodell in dem morphologischen Kasten zur Einordnung von Informationsmodellen eingebettet (vgl. [Prob 03, S. 43 ff.], [Rose 95, S. 22] und [Schü 98, S. 63 ff.]). Abbildung 2.2 bildet anhand der grauen Schattierung das Modell dieser Arbeit auf Merkmalsausprägungen im morphologischen Kasten ab. Die einzelnen Merkmale werden im Folgenden näher erläutert.

Abstraktionsgrad Innerhalb dieser Dimension wird zwischen Ausprägungsebene, Typebene, Me- taebene und Meta-Metaebene differenziert. Informationsmodelle auf Ausprägungsebene bil- den konkrete Sachverhalte ab. Auf nächster Abstraktionsstufe stehen Modelle der Typebene, die einen konkreten Sachverhalt abstrahieren und die Typen innerhalb eines Sachverhalts be- schreiben. Auf Metamodellebene wird zwischen sprachorientierten Metamodellen, welche die Syntax beschreiben, und Metavorgehensmodellen unterschieden, die den Konstruktionspro- zess bzw. den Vorgehensprozess bei Erstellung eines Datenmodells beschreiben. Auf höchster Abstraktionsebene befindet sich das Meta-Metamodell, das Gemeinsamkeiten verschiedener Modellierungstechniken abbildet. Das in dieser Arbeit zu erstellende Informationsmodell ab- strahiert von konkreten Sachverhalten und bildet diese in einem Modell auf Typebene ab. Bei- spielsweise werden keine konkreten SLAs zwischen dem Leibnitz Rechenzentrum und der Technischen Universität München betrachtet. Vielmehr wird das Artefakt SLA, wie es inner- halb der ITIL beschrieben wird, abgebildet. Ein weiterer Teil der Aufgabenstellung dieser Ar- beit ist es, eine Methodik zur Modellierung zu entwickeln, weshalb bei der Entwicklung der Methodik die Metamodellebene betrachtet wird. Dabei werden sowohl sprachorientierte als auch vorgehenstechnische Aspekte Berücksichtigung finden.

Adressat/Inhaltliche Individualität Adressaten können Organisationsgestalter und Anwendungs- systemgestalter sein. Inhaltlich kann das Modell in unternehmensspezifisches Modell, Refe- renzmodell oder Mastermodell unterteilt werden. Referenzmodelle sind branchenspezifische Mastermodelle, die unternehmensspezifische Eigenheiten abstrahieren. Ein Ziel dieser Arbeit ist es, Informations- und Datenmodelle in IT Service Management-Prozessen zu erstellen, wes- halb der Fokus auf dem Bereich des Referenzmodells liegt.

Geltungsanspruch Im morphologischen Kasten wird zwischen Ist-, Soll- und Idealmodell unter- schieden. Dabei bildet ein Istmodell reale Zustände, ein Sollmodell Zielzustände und ein Idealmodell optimale Zustände ab. Bei dem zu erarbeitenden Modell handelt es sich um ein Sollmodell, da es sich um eine angestrebte Entwicklungsstufe handelt.

Beschreibungsebene SCHEER [Sche 97, S. 14 ff.] unterscheidet in der Architektur integrierter In- formationssysteme (ARIS) zwischen Fach-, Datenverarbeitungs- und Implementierungskon- zept. Das Fachkonzept (auch semantisches Modell genannt) beschreibt ein sprachorientiertes Modell, das notwendige Aspekte zur Unterstützung durch Informationstechnologie model- liert. Die Ebene des Datenverarbeitungs-Konzepts (DV-Konzept) stellt Inhalte des Fachkon- zepts durch die Spezifizierungssprache dar. Im Rahmen der vorliegenden Arbeit bilden Ele- mente des Informationsmodells das Fachkonzept und Elemente des Datenmodells das DV- Konzept ab. Im morphologischen Kasten bildet die Implementierungsebene die Elemente des DV-Konzepts auf konkrete Informationstechnologie ab.

Beschreibungssicht Die Beschreibungssicht unterscheidet in Anlehnung an ARIS zwischen Daten, Funktionen, Organisationen und Prozessen. Daten sind Informationselemente zur Beschrei- bung der Struktur des Problembereichs. Diese Sicht bezieht Relationen, Zustände und Zu- standswechsel (in Form von Datenobjekten) mit ein. Die Funktionssicht dient zur Modellie- rung relevanter Aufgaben und ihrer Beziehungen während die Organisationssicht die Struktur der Aufbauorganisation eines Unternehmens darstellt. Die Prozess- oder Steuerungssicht ver- einigt schließlich die zuvor genannten Beschreibungssichten. Innerhalb dieser Arbeit werden aus den Prozessbeschreibungen der ITIL Artefakte abgeleitet und die Beziehungen zwischen den Artefakten dargestellt. Dabei wird nicht im Detail auf Funktionen, auf die Organisation oder auf Prozesse eingegangen.

Neben der eben vorgestellten Einordnung von Informationsmodellen bezüglich des Typs kann eine Bewertung hinsichtlich der Qualität durchgeführt werden. Die Einhaltung der Grundsätze ordnungsgemäßer Modellierung (GoM) [BRS 95] trägt zur Sicherstellung der Qualität von Informationsmodellen bei. Im Folgenden werden die einzelnen Grundsätze kurz vorgestellt.

Grundsatz der Richtigkeit Der Grundsatz der Richtigkeit betrachtet sowohl die semantische als auch die syntaktische Richtigkeit des Modells. Semantische Richtigkeit ist gegeben, wenn ein Modell Sachverhalte und Konzepte aus dem Betrachtungsbereich realitätsgetreu wiedergibt. Durch die Einhaltung und Definition von Notationsregeln kann eine syntaktische Richtigkeit gewährleistet werden.

Grundsatz der Relevanz Die Modellierung aller wichtigen Aspekte wird vom Grundsatz der Re- levanz gefordert. Dabei ist darauf zu achten, dass ein Modell für den jeweiligen Adressaten nur die für ihn bedeutsamen Informationen enthält.

Grundsatz der Wirtschaftlichkeit Der Grundsatz der Wirtschaftlichkeit verlangt eine Gegenüber- stellung von Kosten der Informationsmodellierung und deren Nutzen, um einen optimalen Detaillierungsgrad der Modelle zu finden.

Grundsatz der Klarheit Aspekte der Strukturiertheit, der Lesbarkeit und der Anschaulichkeit wer- den vom Grundsatz der Klarheit gefordert. Somit soll das Verhältnis zwischen Einfachheit und Komplexität der Modelle in einem ausgeglichenen und zweckdienlichen Maße stehen.

Grundsatz der Vergleichbarkeit Der Grundsatz der Vergleichbarkeit zielt auf syntaktische und se- mantische Vergleichbarkeit der Modelle ab. Syntaktische Vergleichbarkeit ist gewährleistet, wenn zur Modellierung verschiedener Modelle dieselbe Technik verwendet worden ist. Se- mantische Vergleichbarkeit zweier Modelle ist erreicht, wenn die Inhalte zweier Modelle hin- sichtlich Überschneidungen untersucht werden können.

Grundsatz des systematischen Aufbaus Die Modellierung von unterschiedlichen Sichten auf das Informationsmodell bedingt eine Integration dieser Sichten. Der Grundsatz des systemati- schen Aufbaus fordert wohldefinierte Schnittstellen zwischen den einzelnen Sichten.

Datenmodelle sind Instanzen von Informationsmodellen. Sie beschreiben Managementobjekte auf einer geringeren Abstraktionsebene und bilden diese auf einen Data Store oder ein Repository ab [PrSc 03, S. 4]. STRASSNER [Stra 04, S. 60] ergänzt diese Definition und nimmt das Zugriffsprotokoll und die Datenverarbeitungssprache in die Definition mit auf.

Beispiele für Datenmodelle sind
- MIB „Structure of Management Information“
- PIB „Structure of Policy Provisioning Information“
- CIM „Managed Object Format“
- OSI-MIB „Guidelines for the Definition of Managed Objects“

In Abbildung 2.3 ist der Zusammenhang zwischen Informations- und Datenmodell bildlich dargestellt. Hier wird deutlich, dass auf Basis eines abstrakten Informationsmodells mehrere unterschiedliche Datenmodelle implementiert werden können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Zusammenhang Informations- und Datenmodell

2.2 IT Service Management

Im Rahmen der vorliegenden Arbeit wird eine Methodik entwickelt, mit deren Hilfe Informationsund Datenmodelle aus IT Service Management-Prozessen abgeleitet werden können. Daher wird im Folgenden der Begriff des IT Service Managements im Kontext des Prozess-Begriffs näher erläutert. Da sich das Wort IT Service Management aus den drei Begriffen IT, Service und Management zusammensetzt, werden diese zunächst näher eingegrenzt, um anschließend auf prozessorientiertes IT Service Management einzugehen.

IT ist ein Akronym für Informationstechnologie und umfasst sowohl Hard- als auch Software für den Betrieb von IT-Diensten [Somm 04, S. 37]. Somit ist Informationstechnologie, wie beispiels- weise ein Router oder ein Server, der Grundstein, auf dem Dienste aufbauen. Ein Dienst ist nach SCHMIDT [Schm 01, S. 9] der Grund der Zusammenarbeit zwischen Dienstnehmer (oder Kunden) und Diensterbringer (oder Service Provider). Der Service Provider stellt dem Dienstnehmer eine bestimmte Funktionalität in Form eines Dienstes zur Verfügung. Im Falle eines IT-Dienstes ist In- formationstechnik die Grundlage des Dienstes. Der E-Mail Dienst beispielsweise kann ohne IT- Komponenten wie einen Server nicht erbracht werden. Der Dienst-Begriff in der Netztechnik bezeichnet hingegen die Funktionalität, die ein Netzelement anderen Elementen des Netzes zur Verfügung stellt [ShWr 97]. Der dieser Arbeit zugrunde liegende Dienst-Begriff umfasst komplexe Dienste, die Kunden, und nicht Computersysteme adressieren.

Innerhalb der ITIL, auf die in Abschnitt 2.3 näher eingegangen wird, ist ein Dienst wie folgt definiert: „One or more IT systems which enable a business process“ [OGC 01, 4.4.1]. LEWIS [Lewi 99, S. 36] grenzt den Dienst-Begriff weiter ein: „A service is a function that the enterprise network provides for the business. (...) [It] is an abstraction over and above the enterprise network.“ Somit setzt sich ein Dienst aus mehreren IT-Komponenten bzw. IT-Systemen zusammen und stellt Funktionen für die Durchführung eines Geschäftsprozesses bereit. Als Abstraktion muss dem Abnehmer die genaue Zusammensetzung eines Dienstes aus einzelnen Komponenten nicht bekannt sein. Aufbauend auf diesem Dienst-Begriff müssten die Management-Aufgaben vom klassischen IT-Management abge- grenzt werden. Während der Begriff des IT-Managements im klassischen Umfeld die Bereiche Netz-, System- und Anwendungsmanagement zum Inhalt hat, vollzieht sich seit einigen Jahren ein Wan- del hin zum Service-Management. Das klassische Management befasst sich mit der Verwaltung von Standarddiensten, wohingegen das Service-Management kundenspezifische Individual-Dienste er- möglicht [HAN 99, S. 558]. Die Anbieter der Dienste sind IT-Organisationen, die dem Kunden qua- litativ hochwertige Individual-Dienste ausliefern, deren Umfang und Dienstgüte im Rahmen von Vereinbarungen (sogenannte SLAs) definiert werden. Dabei wird der operationale Betrieb der IT- Systeme, auf denen die Dienste aufbauen, vom Service Provider sichergestellt. Um die Dienste an den Zielen der Unternehmung auszurichten, müssen sie auf effiziente und effektive Weise in einer kontrollierten Umgebung gesteuert werden.

Diese Aufgabe übernimmt das IT Service Management, indem es Prozesse beschreibt, die praxi- serprobte Methoden und Maßnahmen enthalten (sogenannte Best Practices). Ein Prozess ist nach [ISO 9000] ein „Satz von in Wechselbeziehung oder Wechselwirkung stehenden Tätigkeiten, der Ein- gaben in Ergebnisse umwandelt.“ Diese Mittel schließen Personal, Finanzen, Anlagegüter, Einrich- tungen, Techniken und Methoden mit ein. ALLWEYER [Allw 05] erweitert diese Definition um „eine zeitlich-logische Abfolge von Aktivitäten zur Erfüllung einer betrieblichen Aufgabe, wobei eine Lei- stung in Form von Material- und/oder Informationstransformation erbracht wird“. Im Kontext des IT Service Managements der ITIL findet sich folgende Definition des Geschäftsprozess-Begriffs: „[A Business Process is a] Process that is owned and carried out by the Business. A Business Process contributes to the delivery of a product or Service to a Business Customer.“ [OGC 06] Abbildung 2.4 stellt die Prozess-Definition der ITIL bildlich dar. Darin ist zu erkennen, dass ein Prozess, jeweils ei- ne Eingabe in ein Ergebnis umgestaltet. Ressourcen und Rollen ermöglichen den Prozess, das heißt zur Ausführung und Steuerung von Prozessen werden Ressourcen benötigt. Darüber hinaus gibt es für jeden Prozess einen Verantwortlichen. Zur Steuerung von Prozessen können Ziele und Parame- ter verwendet werden. Somit liegt der Fokus des IT Service Managements nicht auf die Technologie, die einen Dienst ermöglicht, sondern auf Best Practices zur Steuerung der IT-Organisation. Die ITIL definiert den Begriff IT Service Management als die Verwaltung der Dienste, um Kundenbedürf- nisse zu befriedigen [OGC 01, A.2]. SOMMER [Somm 04, S. 37] definiert den Begriff als die Prozesse und Verfahren, Funktionen und Informationen, die zur Auslieferung eines Dienstes notwendig sind. ZARNEKOW, HOCHSTEIN und BRENNER [ZHB 05, S. 8] nennen als primäres Ziel die stetige Anpas- sung, Ausrichtung, Steuerung und Überwachung der IT-Dienste an Kundenanforderungen. Der Fo- kus liegt dabei auf der Perspektive des Service Providers, der einem Dienstnehmer bzw. Kunden einen Dienst zur Verfügung stellt. In Vereinbarungen zur Verfügbarkeit dieser Dienste, die in SLAs getroffen werden, definieren Service Provider und Kunde Zusagen bzw. Ziele im Hinblick auf die zu erreichende Dienstgüte. Diese müssen seitens Service Provider kundenspezifisch verwaltet werden, wobei es sich beim Kunden oftmals um Organisationseinheiten innerhalb der Unternehmung des Dienstanbieters handelt.

Nachdem der Begriff des IT Service Managements umfassend eingeführt wurde, und dabei bereits insbesondere auf die ITIL eingegangen wurde, werden nun einige Rahmenwerke im Bereich IT Service Management aufgeführt und gegenübergestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Prozessbegriff der ITIL [OGC 01, B.1.3]

ISO 20000

Am 15. Dezember 2005 wurde unter der Norm ISO 20000, basierend auf dem Britischen Standard BS15000 vom 06.11.2000, von der International Organization for Standardization (ISO) ein Stan- dard für IT Service Management veröffentlicht. Dieser Qualitätsstandard bezieht sich auf IT Service Management-Prozesse und spezifiziert Mindestanforderungen für die Zertifizierung der Prozesse eines Unternehmens.

ISO 20000 besteht aus zwei Teilen [ISO 05] [Macf 06, S. 46]:

- Teil 1 - Spezifikation der Anforderung zur Erreichung der Zertifizierung nach ISO 20000.
- Teil 2 - Praxisleitfaden mit Erläuterungen und Ausführungen der in Teil 1 aufgeführten Anfor- derungen.

Durch den Ursprung des Standards im BS15000, der von den ITIL-Autoren verfasst wurde, ähnelt das Prozessmodell dem der ITIL sehr stark [KBSt 06, S. 20] [Macf 06, S. 51]. Die Beziehungen zwischen ISO 20000 und der ITIL werden in Abbildung 2.5 dargestellt. Wie der Abbildung zu entnehmen ist, definiert auf oberster Ebene der Pyramide die Norm ISO 20000 Anforderungen für eine Zertifizierung der Prozesse. Das Rahmenwerk ITIL liefert Prozessbeschreibungen und Best Practices, die für den Einsatz in einem Unternehmen entsprechend angepasst werden. Darüber hinaus gibt es weitere Rahmenwerke, die in diesem Bereich angesiedelt sind. Im Folgenden werden einige Rahmenwerke aus dem Bereich kurz aufgeführt.

IT Infrastructure Library (ITIL)

Die ITIL wurde Ende der 80er-Jahre als Richtlinie der britischen Regierung entwickelt [OGC 00, S. 1]. Nachdem die Richtline einigen Unternehmen als Basis für das IT Service Management diente,

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: ITIL und ISO 20000 (in Anlehnung an [Macf 06, S. 51] und [KBSt 06, S. 20])

wurde sie ab 1999 überarbeitet und vom Office of Government Commerce (OGC) veröffentlicht. Mitte 2007 wurde der „worldwide de facto standard“ [Rudd 06, S. 149] für das IT Service Manage- ment in der Version 3 veröffentlicht. Die Inhalte dieser Arbeit beziehen sich auf die Version 2, da zu Beginn dieser Arbeit die Verfügbarkeit der ITIL in der Version 3 nicht sichergestellt werden konnte. Die ITIL bietet in Form von Büchern Best Practice-Anleitungen für das IT Service Management. Best Practice bedeutet in diesem Zusammenhang praxiserprobte IT Service Management-Praktiken, wel- che vom OGC durch den Vergleich der Ansätze verschiedener Organisationen und deren Lösungen im Bereich IT Service Management gesammelt wurden und in Form von Büchern als ITIL veröffent- licht werden. Im IT Service Management Forum (itSMF) können Mitglieder aus der Industrie ihre Erfahrungen und Best Practices einbringen, welche dann vom OGC evaluiert werden und in die ITIL einfließen können. Wie bereits angesprochen bildet die ITIL die Grundlage für ISO 20000 und ist daher von zentraler Bedeutung für den IT Service Management-Bereich. Die Relevanz der ITIL für das Management von IT-Diensten belegen Studien, wie beispielsweise die Umfrage der Fach- hochschule Aalen [SZD 04]. Dabei wurden 217 Teilnehmer zu 37 Fragen zum Thema „Verbreitung und Nutzen des prozessorientierten IT-Managements - Wo steht ITIL?“ befragt. In Abbildung 2.6 sind die Ergebnisse auf die Frage, welche Rahmenwerke als Grundlage einer IT-Prozessoptimierung geplant sind, aufgeführt.

Hauptbestandteil der ITIL bilden die beiden Bücher Service Support [OGC 00] und Service Delivery [OGC 01], welche die zentralen Prozesse und Best Practices für das IT Service Management beschreiben. Darüber hinaus veröffentlicht die OGC weitere Bücher im Rahmen der ITIL die sich mit Themen wie Einführung der ITIL, IT-Sicherheit, Infrastruktur-, Anwendungs- und Assetmanagement beschäftigen (vgl. [OGC 07]). Aufgrund der hohen Relevanz der ITIL in diesem Bereich wird in Abschnitt 2.3 näher auf die Inhalte eingegangen. Mit der ISO 20000 ist eine Zertifizierung der Prozesse möglich. Zudem können sich Personen durch das OGC einer Zertifizierung unterziehen. Jedoch fehlt eine öffentlich anerkannte Stelle zur Zertifizierung von ITIL-Tools. Auf diese Problematik wird ebenfalls in Abschnitt 2.3 näher eingegangen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: Verwendete Rahmenwerke zur IT-Prozessoptimierung (in Anlehnung an [SZD 04])

Microsoft Operations Framework

Ein weiteres Rahmenwerk im Bereich IT Service Management ist das Microsoft Operations Fra- mework oder MOF. Dabei handelt es sich um eine Anpassung der ITIL an eigene Produkte durch Microsoft [PQA 03, S. 11]. Das Unternehmen unterteilt die Bereiche des IT Service Managements in vier Segmente:

- Changing beschäftigt sich mit der Verwaltung von Änderungen in der IT-Landschaft. Dies bezieht die aus der ITIL bekannten Prozesse Change Management, Configuration Management und Release Management mit ein.
- Operating befasst sich mit den IT-Diensten und der Einhaltung vereinbarter Service Levels. Die Prozesse in diesem Bereich sind System-Administration, Security-Administration, Service- Monitoring & Kontrolle, Job Scheduling, Netzwerk-Administration, Directory Service Administration (Verzeichnisdienst-Administration), Print & Output Management (Druck- und Ausgabe-Management) sowie Storage Management (Speicher-Management).
- Supporting umfasst die Erkennung, Bearbeitung, Priorisierung und Nachverfolgung von Incidents. Analog zur ITIL befinden sich in diesem Bereich der Service Desk sowie das Incident Management und Problem Management.
- Optimizing beinhaltet sowohl die Verwaltung der Kosten als auch die Einhaltung und Verbes- serung vereinbarter Service Levels. In diesem Quadranten fallen die Prozesse Service-Level- Management, Finance-Management, Service-Continuity-Management, Availability-Management, Capacity-Management sowie Workforce-Management.

Da MOF stark an die ITIL angelehnt und zudem ein proprietäres Produkt ist, das Microsoft veröffentlicht, wird es im Rahmen dieser Arbeit nicht näher betrachtet. Wie BRENNER [Bren 07, S. 81] andeutet, ist der Beitrag von MOF vor allem im Hinblick auf die Verbreitung der ITIL im amerikanischen Raum zu sehen.

IBM Tivoli Unified Process (ITUP)

Eine weitere proprietäre Lösung im IT Service Management-Bereich ist der Tivoli Unified Process der Firma IBM (kurz ITUP). IBM veröffentlicht ein Prozess Referenzmodell (IBM Process Reference Model for IT) für IT Service Management in Form eines webbasierten Tools, das „ITIL experience of decades of IBM consulting experience“ [EMA 06, S. 2] vereint. Jedoch handelt es sich hierbei um die Erfahrungen von einer Firma, die das Ziel hat, proprietäre Lösungen zu vertreiben. Dies bedeutet, dass die firmeneigenen Lösungen und deren Integration in das IT Service Management- Rahmenwerk im Zentrum der Entwicklung stehen. Unter der Reihe Tivoli veröffentlicht IBM eine Vielzahl von Softwarelösungen, welche die Themen Sicherheit, Speichermanagement, Softwareentwicklung sowie Verfügbarkeitsmanagement abdecken (vgl. [IBM 07]), wodurch eine Toolunterstützung des IT Service Management-Rahmenwerks ermöglicht werden soll.

Die Prozessbibliothek in ITUP umfasst folgende vier Aspekte:

- Products (Tools) beschreiben den Einsatz von IBM Tools zur Unterstützung der Aktivitäten eines IT Service Management-Prozesses.
- People (Roles) umfassen Verantwortlichkeiten innerhalb eines Aufgabengebietes, die mit einer bestimmen Aufgabe verknüpft sind. Dabei wird auf die Products Bezug genommen, die bei der Aufgabenbewältigung behilflich sind.
- Information (Work Products) sind Eingaben oder Erzeugnisse eines Prozesses und werden im ITUP detailliert beschrieben.
- Problem Scenarios beschreiben Probleme und Best Practice-Lösungen und beziehen den Einsatz von Tools bei der Lösungssuche mit ein.

Aus der Beschreibung der Prozessbibliothek ist ein deutlicher Schwerpunkt auf die Unterstützung durch IBM Tools zu erkennen. Im Hinblick auf die Identifikation von Artefakten innerhalb der ITIL erscheint vor allem der Aspekt der Work Products als hilfreiche Quelle, wenn auch eine gewisse Subjektivität in Kauf genommen werden muss.

Enhanced Telecom Operations Map (eTOM)

Ein weiterer Vertreter unter den IT Service Management-Rahmenwerken ist die eTOM, die vom TeleManagement Forum (TMF) verwaltet wird [TMF 07a]. Dem TMF gehören vor allem Firmen aus der Telekommunikationsbranche wie die Deutsche Telekom, France Telecom oder die Vodafo- ne Group an. Da die Telekommunikationsbranche in sehr hohem Maße von IT abhängig ist, wurde der Nutzen von IT Service Management bereits früh erkannt [Hend 06, S. 166]. Ursprünglich als branchenspezifische Lösung unter dem Namen TOM entwickelt, wird mit der 2001 veröffentlich- ten und erweiterten Version eTOM eine breitere Zielgruppe angesprochen. eTOM ist in das New Generation Operations Systems and Software (NGOSS) Projekt des TeleManagement Forums einge- bettet, das Lösungen für Business und Operations Support Systeme (BSS bzw. OSS), also Systeme, die Geschäftsprozesse bzw. automatisierte Service-Management-Prozesse unterstützen, bereitstellt. Als herstellerunabhängige Architektur verfolgt NGOSS das Ziel, eine Lösung mit standardisierten Schnittstellen zu schaffen. Das NGOSS-Rahmenwerk umfasst Geschäftsprozesse für das IT Service Management in der eTOM, ein auf der eTOM basierendes Informationsmodell (das SID) sowie tech- nologieunabhängige Schnittstellen und Architekturprinzipien. Des Weiteren werden Kriterien zur Zertifizierung aufgestellt, wodurch eine Zertifizierung von Tools ermöglicht wird. Die weite Ver- breitung und Akzeptanz des Rahmenwerks in der Telekommunikationsbranche, die Erweiterung des Fokus auch außerhalb der Telekommunikationsbranche und die Einbettung in das NGOSS- Programm begründet eine genauere Betrachtung der eTOM in Abschnitt 2.4.

2.3 IT Infrastructure Library (ITIL)

Wie in Abschnitt 2.2 bereits angedeutet, ist die ITIL das meist verbreitetste IT Service ManagementRahmenwerk, wodurch eine genauere Betrachtung motiviert ist.

2.3.1 Ziele der ITIL

Durch die Zusammenstellung von Best Practices in der ITIL soll ein Rahmenwerk für das IT Ser- vice Management geschaffen werden, das sich nicht auf alltägliche Vorgänge konzentriert, die sich von Organisation zu Organisation unterscheiden. Vielmehr ist das erklärte Ziel der ITIL die Bereit- stellung praxiserprobter Methoden zur Planung einheitlicher Prozesse zusammen mit Rollen und Aktivitäten [OGC 00, 1.1.2]. Durch die Einführung der ITIL-Prozesse soll die Bereitstellung qualita- tiv hochwertiger Dienste bei gleichzeitiger kostengerechter IT-Service-Qualität ermöglicht werden und Mängel der Kommunikation und Koordination durch eine einheitliche Terminologie minimiert werden [OGC 00, 1.1.4]. Die Beziehungen mit Kunden stehen dabei im Vordergrund, wobei die IT- Abteilung innerhalb einer Organisation als Service Provider Dienste an unternehmensinterne Par- teien, die als Kunden auftreten, bereitstellt. Dadurch soll eine Ausrichtung des IT Service Manage- ments an den Geschäftsprozessen des Unternehmens sichergestellt werden.

2.3.2 Bestandteile der ITIL

Die Bücher Service Support [OGC 00] und Service Delivery [OGC 01], deren Inhalt sich auf zehn Prozesse und die Funktion Service Desk bezieht, bilden die Hauptbestandteile der ITIL. Im Folgenden werden diese kurz vorgestellt. Dabei wird insbesondere auf die Prozesse Configuration Manage ment und Service Level Management eingegangen, da sie im Rahmen der Aufgabenstellung der vorliegenden Arbeit näher betrachtet werden.

Service Support

Dieser Bereich der ITIL umfasst Prozesse für die Unterstützung des operativen Betriebs. Dabei bil- det die Funktion des Service Desk s als „Single Point Of Contact“ die zentrale Anlaufstelle für Kunden von IT-Diensten. Dort werden alle Anfragen, Incidents und sonstiges Feedback entgegengenommen. Innerhalb des Service Support-Buches werden fünf Prozesse unterschieden, die nun kurz skizziert werden. Abbildung 2.7 bietet einen Überblick der Prozesse sowie wichtiger Artefakte aus dem Be- reich Service Support.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.7: Prozesse aus dem Bereich Service Support [OGC 00, Appendix F]

Incident Management [OGC 00, Kapitel 5]

Dieser Prozess stellt einen reibungslosen Betrieb der IT-Dienste durch die schnellstmögliche Beseiti- gung von Störungen (Incidents) sicher. Es werden Incidents klassifiziert sowie priorisiert, innerhalb ihres Lebenszyklus dokumentiert und, sofern möglich, behoben. Die Dokumentation der Incidents geschieht in der Incident Management Datenbank. Ist eine Behebung nicht möglich, wird der Inci- dent an das Problem Management weitergeleitet. Dadurch soll die Verfügbarkeit sowie die Qualität der Dienste gemäß der mit den Kunden getroffenen Vereinbarungen in Form von SLAs sicherge- stellt werden. Darüber hinaus werden Service Requests von Benutzern, die durch den Service Desk entgegengenommen wurden, bearbeitet. Durch das Incident Management soll eine hohe Anwender- zufriedenheit bezüglich der Dienste und eine hohe Erreichbarkeit dieser ermöglicht werden.

Problem Management [OGC 00, Kapitel 6]

Das Problem Management beschäftigt sich mit dem Auffinden, der Dokumentation und der Verfol- gung von Störungen der Infrastruktur, um so die Auswirkung von Incidents zu minimieren und deren Wiederkehr zu verhindern. Es werden Ursachen von Incidents identifiziert, Work-arounds für die vorübergehende Wiederherstellung des betroffenen Dienstes erstellt und dokumentiert. So- bald eine Ursache gefunden wurde und ein Work-around zu dem Problem erstellt wurde, wird das Problem als Known Error bezeichnet und in der Known Error-Datenbank abgelegt. Die Fehlerbe- handlung beschäftigt sich mit der Beseitigung der Ursachen von Störungen durch das Verfassen von Requests for Change, so dass die Maßnahmen zu deren Beseitigung durch das Change Management eingeleitet werden können. Neben reaktiver Problem-Behandlung wird mit Hilfe von Trendanaly- sen versucht, proaktiv zukünftige Beeinträchtigungen des Betriebes zu verhindern, bevor sie als In- cidents beim Kunden auftreten. Somit gewährleistet der Problem Management -Prozess eine effiziente und effektive Identifikation und Behebung der Ursachen von Incidents.

Configuration Management [OGC 00, Kapitel 7]

Durch die Identifikation, Kontrolle, Wartung und Verifizierung von Komponenten der Infrastruktur (in der ITIL als Configuration Items, CIs, bezeichnet) wird mit Hilfe des Configuration Management s eine logische Sicht auf die Infrastruktur und Dienste ermöglicht. Diese logische Sicht steht als Da- tenbank (die CMDB) anderen IT Service Management-Prozessen zur Verfügung. Darin sind neben den Informationen über Anlagegüter auch Beziehungen zwischen den Anlagegütern sowie damit verbundene Changes, Incidents, Problems oder Releases abgebildet. Die Informationen der CMDB dienen sämtlichen ITIL-Prozessen zur Unterstützung ihrer Tätigkeit. Der Configuration Management - Prozess beschäftigt sich mit den Aspekten der Planung, der Identifikation, der Kontrolle, des Status- nachweises und der Verifizierung und dem Audit von CIs. Aufgrund des hohen Stellenwerts des Configuration Management -Prozesses innerhalb der ITIL und hinsichtlich der Aufgabenstellung, wird im Folgenden auf die Artefakte des Configuration Management -Prozesses näher eingegangen. Inner- halb der Planung werden die Artefakte Configuration Management Plan und Policy definiert und erstellt. Diese Artefakte beschreiben den Zweck und Umfang sowie Maßnahmen und Prozeduren auf technischer und organisatorischer Ebene. In der Phase der Identifikation werden Configuration Structures erstellt und die Zusammensetzung von CIs identifiziert. Dies schließt die Identifikation von Beziehungen zwischen CIs sowie die Rolle, die ein CI innerhalb einer Configuration Structure einnimmt (Kind oder Elternteil) mit ein. Innerhalb dieser Phase werden die Informationen über CIs in Form von Configuration Records (CRs) sowie die Beziehungen zwischen den CIs in der CMDB abgelegt. Die Phase Kontrolle stellt mit Hilfe der Artefakte aus der Planung sicher, dass nur autori- sierte CIs in der CMDB abgelegt werden, dass Änderungen nur in Form von Changes durchgeführt werden und dass die Informationen innerhalb der CMDB aktuell sind. Dabei werden Schnappschüs- se von CIs in Form einer Configuration Baseline festgelegt sowie Managementinformationen durch den Configuration Report aufbereitet. Durch den Statusnachweis werden Informationen über CIs so- wie deren Lebenszyklus zur Verfügung gestellt. Dadurch wird beispielswiese die Verfolgung von Changes anhand des Status eines CIs ermöglicht. Darüber hinaus wird durch diesen Aspekt des Configuration Management s sichergestellt, dass Releases nur mitsamt der Configuration Documenta- tion in die Live-Umgebung eingespielt werden. Die Verifizierung und das Audit stellen schließlich sicher, dass die Informationen innerhalb der CMDB konsistent sind und die tatsächliche Situation widerspiegeln.

Change Management [OGC 00, Kapitel 8]

Änderungen der Infrastruktur werden durch den Change Management -Prozess koordiniert und gesteuert. Diese werden in Form von Requests for Change eingereicht und müssen autorisiert, klassifiziert, terminiert und evaluiert werden. Durch die Klassifikation werden Requests for Change im Hinblick auf Bedeutung, Kosten und Dringlichkeit priorisiert. Bei wichtigen und bedeutsamen Änderungen wird das Change Advisory Board einberufen, ein Gremium, das diese Changes autorisiert. Darüber hinaus kann in SLAs definiert werden, welche Changes von Kunden eingereicht werden können und wie schnell diese zu bearbeiten sind. Das Change Management stellt sicher, dass Änderungen durchgeführt werden, ohne die Dienstgüte zu beeinträchtigen.

Release Management [OGC 00, Kapitel 9]

Das Release Management stellt den Einsatz von getesteter und freigegebener Hard- und Software innerhalb der Produktivumgebung sicher. Es werden Pläne und Richtlinien aufgestellt, die eine si- chere und reibungslose Auslieferung von Releases an den Kunden ermöglichen. Releases werden entsprechend der Richtlinien getestet, ausgeliefert, dokumentiert und kommuniziert. Des Weite- ren stellt das Release Management sicher, dass Änderungen nachvollziehbar und entsprechend der Richtlinien ausgeführt werden. Inhalte der Releases werden in der Definitive Software Library ge- speichert. Alle umgesetzten Änderungen eines neuen Releases werden in der CMDB dokumentiert.

Service Delivery

Das Service Delivery Buch umfasst fünf Prozesse aus den Bereichen Planung und Steuerung, die ein kundenorientiertes IT Service Management sicherstellen. Dabei werden vor allem strategische Aufgaben des IT Service Managements behandelt. Abbildung 2.8 bietet einen Überblick der Prozesse sowie wichtiger Artefakte aus dem Bereich Service Delivery.

Service Level Management [OGC 01, Kapitel 4]

Als zentraler Prozess innerhalb der ITIL werden im Service Level Management Details über Dienste zusammen mit Kunden und Zulieferern vereinbart. Die Überwachung der Auslieferung der Dienste und Sicherstellung der vereinbarten Dienstgüte sowie die stetige Berichterstattung über die Errei- chung des Service Achievements bindet den Kunden als Dienstnehmer in den Prozess mit ein. Da im Rahmen dieser Arbeit mehrfach auf SLAs und andere Artefakte aus dem Service Level Manage- ment -Prozess Bezug genommen wird, und es sich darüber hinaus um den zentralen Prozess aus dem Bereich Service Delivery handelt, wird im Folgenden näher auf die Artefakte dieses Prozes- ses eingegangen. Im Zentrum dieses Prozesses steht das Steuern der Service Levels der Dienste, die an den Kunden ausgeliefert werden. Als Service Level wird der Grad der Dienstgüte bezeich- net. Ein SLA regelt dabei schriftlich zwischen Kunden und Service Provider die Art, den Umfang und die Dienstgüte der zu erbringenden Dienste. Innerhalb des Dokuments werden mit dem Kun- den Ziele (SLA Targets) vereinbart anhand derer die Güte des Dienstes gemessen wird. Mit Hilfe von Service Achievements wird die Dienstgüte innerhalb eines Zeitraums ermittelt. Berichte geben durch aggregierte Service Achievements Aufschluss über die Zielerreichung der Dienste gegenüber vereinbarter SLA Targets. Um in SLAs vereinbarte Ziele erfüllen zu können, müssen SLAs durch Vereinbarungen innerhalb der Organisation des Service Providers sowie durch Verträge mit Zuliefe- rern abgesichert werden. Ist es dem Service Provider nicht möglich alle Komponenten eines Dienstes selbst zu erbringen, so werden Teile ausgelagert. Damit sichergestellt wird, dass die Vereinbarun- gen, die zwischen dem Kunden und dem Service Provider in Form von SLAs getroffen wurden, erfüllt werden können, müssen die ausgelagerten Teile des Dienstes vertraglich abgesichert wer- den. Diese vertragliche Absicherung wird in der ITIL als Underpinning Contract (UC) bezeichnet, der einen SLA zwischen Service Provider und einem Zulieferer darstellt. Vereinbarungen innerhalb der Organisation zur Absicherung der in den SLAs vereinbarten SLA Targets werden in der ITIL als

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.8: Prozesse aus dem Bereich Service Delivery [OGC 01, Appendix G]

Operational Level Agreement (OLA) bezeichnet. Alle Dienste, für die ein SLA abgeschlossen wur- de, werden im Service Catalogue zusammen mit Details über den jeweiligen Kunden aufgeführt. Neben einer Beschreibung der Charakteristika der Dienste, der angebotenen Dienst-Optionen so- wie der verfügbaren Service Levels, wird ein Verantwortlicher für den Dienst geführt. Zusätzlich wird empfohlen, jeden Dienst als CI in der CMDB aufzunehmen, wodurch ein Überblick über mit dem Dienst verbundene Incidents oder Requests for Change möglich ist. Die ITIL fordert, dass für jeden Dienst, der einem Kunden zur Verfügung gestellt wird, ein SLA geschlossen wird. Bei der Entwicklung neuer Dienste werden zunächst Service Level Requirements (SLRs), also Kundenan- forderungen bezüglich des zu entwickelnden Dienstes, auf die technische Machbarkeit sowie Ein- haltung gewünschter Service Levels analysiert und zugleich ein SLA erarbeitet. Nach Aufnahme des Dienstes in den Service Catalogue wird der entwickelte SLA vom Service Provider und dem Kunden unterschrieben. Zur Evaluation der Service Achievements werden zusammen mit Kunden Service Review Meetings abgehalten, bei denen Service Achievements einer vergangen Periode be- sprochen werden. Zur Verbesserung der Dienstgüte werden gegebenenfalls Aktionen vereinbart, die dazu beitragen Schwachstellen der Diensterbringung zu beseitigen. Als ein weiteres Mittel zur Ver- besserung der Dienstgüte kann ein formales Projekt, das Service Improvement Programme (SIP), initialisiert werden, das Verbesserungsmaßnahmen innerhalb eines Problembereichs identifiziert. Innerhalb des Service Improvement Programmes werden die Ursachen für Beeinträchtigungen der Dienstgüte bestimmt. Anschließend werden zusammen mit dem Availability Management und dem Problem Management Maßnahmen eingeleitet, die diese Beeinträchtigungen unterbinden.

Financial Management [OGC 01, Kapitel 5]

Das Financial Management umfasst die Bereiche Budgetierung, Controlling und Rechnungserstel- lung. Die Budgetierung ermöglicht die Zuteilung von finanziellen Ressourcen auf IT-Bereiche, um eine Überwachung der Ausgaben sicherzustellen. Der Bereich des Controllings stellt sicher, dass Kosten der Diensterbringung verursachungsgerecht erhoben werden. Die Rechnungsstellung verrechnet die ausgelieferten Dienste entsprechend der Vereinbarungen in der Charging Policy. Somit stellt das Financial Management die Transparenz der Kosten sicher, wodurch ein effizientes Management der Dienste ermöglicht wird.

Capacity Management [OGC 01, Kapitel 6]

Der Capacity Management -Prozess gewährleistet eine optimale Nutzung und Verfügbarkeit der Kapazitäten von Ressourcen entsprechend aktueller und zukünftiger Anforderungen aus SLAs. Über die Capacity Management Database (CDB) werden Kapazitätsinformationen anderen IT Service Management-Prozessen zur Verfügung gestellt. Bei der Definition neuer Dienste wird geprüft, ob zukünftige Kapazitätsanforderungen aus SLRs organisationsintern erfüllt werden können. Darüber hinaus wird versucht, eine optimale Kapazitätsauslastung zu erreichen, so dass eine effiziente Ressourcen-Nutzung zur Erreichung der SLA Targets gewährleistet wird.

IT Service Continuity Management [OGC 01, Kapitel 7]

Das IT Service Continuity Management identifiziert Bedrohungen und Risiken sowie deren Auswir- kungen auf kritische Geschäftsprozesse. Durch die Erstellung von Notfallplänen sowie das Vor- halten von Ersatzkomponenten zur Diensterbringung nach einer Katastrophe (z.B. einem Brand) versucht das IT Service Continuity Management die Auswirkungen von Dienst-Ausfällen einzudäm- men und Geschäftsprozesse innerhalb einer bestimmten Zeit wiederherzustellen. Im Rahmen des Prozesses werden Risiken identifiziert und deren Auswirkung auf die Geschäftsprozesse analysiert, um daraus schließlich Maßnahmen abzuleiten, die in Notfallpläne einfließen können.

Availability Management [OGC 01, Kapitel 8]

Das Availability Management stellt die Verfügbarkeit von IT-Diensten auf in SLAs vereinbartem Ver- fügbarkeitsniveau durch eine kontinuierliche Überwachung und Verbesserung der IT-Infrastruktur sicher. Dabei werden Verfügbarkeitsanforderungen aus SLAs ermittelt und auf die Kapazitäten der IT-Infrastruktur sowie der Support-Organisation auf kosteneffiziente Weise abgebildet. Die Mes- sung und Überwachung aktueller Verfügbarkeitszahlen sowie die Bereitstellung von Verfügbar- keitsdaten in der Availability Management Database (AMDB) sind weitere Aufgabengebiete des Availability Management s.

2.3.3 Nutzen der ITIL

Die Best Practices der ITIL bilden die Grundlage für eine einheitliche Terminologie, die Kommu- nikationsprobleme minimiert, und ermöglichen ein effektives und effizientes IT Service Manage- ment. Durch die Standardisierung nach ISO 20000 (siehe Abschnitt 2.2) können die IT-Prozesse des Unternehmens zertifiziert werden, womit die Konformität mit den Vorgaben der ITIL sichergestellt werden kann. Die Prozesse ermöglichen zudem eine geschäftsorientierte und kundenzentrierte Aus- richtung der IT-Organisation eines Unternehmens. Die Überwachung der Kundenzufriedenheit, so- wie die Vereinbarungen über Dienstumfang und Supportleistungen schafft Transparenz und erhöht die Kundenzufriedenheit. Durch SLAs ist der Umfang von Diensten klar definiert und deren Lei- stung kann auf Grundlage von Zielen gemessen werden. Die Ausrichtung der Managementpro- zesse an die ITIL führt zur Steigerung der Dienst-Qualität, da Änderungen an der Infrastruktur koordiniert durchgeführt werden und Auswirkungen von Änderungen aufgrund vielseitiger Infor- mationen genau abgeschätzt werden können. Zudem herrscht ein einheitliches Verständnis über Umfang und Inhalt von Diensten, da Kunden bereits in der Planungsphase von Diensten miteinbe- zogen werden. Durch die Planung von Katastrophenszenarios, können Risiken von Totalausfällen der IT eingegrenzt und minimiert werden. Die in der ITIL propagierte proaktive Steuerung der IT- Landschaft hilft Probleme und Störungen zu beseitigen, bevor sie in Erscheinung treten und die Qualität der Dienstleistungen mindern. Somit können durch die ITIL Risiken minimiert werden, die erhebliche Kosten verursachen könnten. Die Auslastung der vorhandenen Kapazitäten schafft einen effizienten Einsatz der Ressourcen. Durch eine stetige Verbesserung werden die Dienste ständig im Hinblick auf Effektivität und Effizienz getrimmt, um ein optimales Leistungsniveau zu etablieren. Somit liefert die ITIL ein Rahmenwerk, das bessere Managementkontrolle durch eine Transparenz der Prozesse sowie der in den Prozessen verarbeiteten Informationen ermöglicht. Daraus ergibt sich eine zuverlässige Steuerung der IT-Landschaft. Die zunehmende Verbreitung der ITIL liefert überdies ein einheitliches Verständnis der Prozesse über Unternehmensgrenzen hinweg.

2.3.4 Kritische Bewertung der ITIL

Häufig wird kritisiert, dass die ITIL in vielen Bereichen keine konkreten Vorgaben gibt und dass die Informationsflüsse mangelhaft beschrieben sind. PROBST [Prob 03] bemängelt, dass nur verein- zelt auf Informationsobjekte und deren Beziehungen eingegangen wird, wodurch keine klare und nachvollziehbare Sicht auf die Daten möglich ist. Zudem kritisiert er, dass das informelle Referenz- modell der ITIL nicht den Grundsätzen ordnungsgemäßer Modellierung (GoM) (siehe Abschnitt 2.1) gerecht wird [Prob 03, S. 88 f.]. Die widerspruchsbehaftete Modellierung, verstößt gegen den Grundsatz der Richtigkeit. Defizite in der Datensicht, die sich durch eine fehlende Informations- modellierung relevanter Aspekte auszeichnen, sowie die unterschiedliche Strukturierung und Be- handlung einzelner Themen verstoßen gegen die Grundsätze der Relevanz und der Klarheit. Die informale Darstellung sowie die nicht verfügbare Umsetzung über ein Modellierungstool verstößt gegen den Grundsatz der Wirtschaftlichkeit. Inkonsistenzen innerhalb der Beschreibungen sowie das Fehlen eines Metamodells verletzen die Grundsätze der Vergleichbarkeit sowie des systemati- schen Aufbaus. Zwar sind beispielsweise in [OGC 00, Kapitel 9] und [OGC 01, Kapitel 10] Hinweise zu Anforderungen an Softwaretools für das IT Service Management nach den Vorgaben der ITIL zu finden, diese sind jedoch sehr allgemein gehalten und, wie BRENNER [Bren 07, S. 47 f.] feststellt, wenig belastbar. PRÄNGER und SCHMIDT [PrSc 06] bemängeln, dass der Informationsgehalt nicht ausreicht, um eine umfassende Implementierung im Sinne eines Leitfadens zu ermöglichen, wes- halb viele Prozesstools von Unternehmensberatungen anbieterspezifische Referenzmodelle erstel- len und somit „ITIL-Dialekte“ schaffen, die zueinander inkompatibel sind. Die unterschiedlichen Implementierungen sind wohl damit zu begründen, dass die Autoren dieser Tools ihre Methodik zur Informationsmodellierung nicht für die Öffentlichkeit zugänglich machen. Das Fehlen eines Informations- und Datenmodells ist als Grund zu sehen, warum es bisher keine Toolzertifizierung für die ITIL gibt. Durch die ISO 20000 ist es zwar möglich, organisatorische Prozesse zu zertifizie- ren, jedoch ist es für den operativen Einsatz dieser Prozesse nötig, die entsprechenden Tools zur Hand zu haben. Aus diesen Gründen ist ein Informationsmodell wünschenswert, das als Basis für die Entwicklung von ITIL-Tools dient.

2.4 Enhanced Telecom Operations Map (eTOM)

In Abschnitt 2.2 wurde eTOM bereits als IT Service Management-Rahmenwerk vorgestellt. Aufgrund der wachsenden Relevanz auch außerhalb des Telekommunikationssektors sowie der Einbettung in das NGOSS-Programm werden im Folgenden die Konzepte der eTOM betrachtet, um anschließend einen Vergleich mit der ITIL durchzuführen.

2.4.1 Ziele der eTOM

Hauptziel des TMFs bei der Entwicklung der eTOM ist ein Referenzmodell für Service Provider und eine Einheitssprache für Anbieter, Händler und Großhändler von Dienstleistungen in der Te- lekommunikationsindustrie zu erarbeiten. Der Fokus wurde auf die Geschäftsprozesse des Service Providers zusammen mit Schnittstellen und Verbindungen zwischen den einzelnen Prozessen ge- legt [TMF 07a, S. 12 f.]. Dabei wurde zusammen mit Vertretern aus der Telekommunikationsbranche versucht, die verschiedenen Aktivitäten für die Innen- und Außenbeziehungen eines Unternehmens durch automatisierte und effiziente Prozesse vollständig darzustellen und ein Basisinformationsmo- dell für einzelne Prozesselemente innerhalb einer Geschäftsaktivität zu entwickeln. Aus dieser Motivation entstand das NGOSS-Programm [TMF 05a]. Weitere Ziele waren eine einheitliche Definition von Prozesselementen aus der Sicht des Dienstleisters, die Einsatzfähigkeit der eTOM außerhalb der Telekommunikationsbranche sowie die Unterstützung von Unternehmen bei der Analyse und Modellierung ihrer eigenen Prozesse [TMF 07a, S. 12 f.].

Die letzten beiden Punkte machen zusammen mit NGOSS das Rahmenwerk der TMF als Alternative zu ITIL als IT Service Management Lösung äußerst attraktiv. Daher findet es auch zunehmend außerhalb der Telekommunikationsindustrie Verwendung [Hend 06, S. 163].

Das NGOSS-Programm besteht aus vier Hauptbestandteilen, die zur Entwicklung, Integration und den Betrieb von Operations Support Systemen (OSS) sowie von Business Support Systemen (BSS) beitragen sollen [TMF 07f]:

- Business Process Map (eTOM): Das Prozessrahmenwerk liefert Hilfestellungen bei der Prozes- saufnahme und bei der Verbesserung der Kommunikation in der Organisation. Zudem dient es durch die Beschreibung der Kernprozesse des IT Service Managements als Bezugssystem für Softwarelösungen in diesem Bereich.
- Shared Information and Data Model (SID): „Einheitssprache“ für die Beschreibung von Mana- gementinformationen zur Unterstützung der Integration in OSS/BSS-Softwareanwendungen. Das SID umfasst dabei ein allgemeines Informationsmodell und dessen Elemente und Entitäten, geschäftsspezifische UML-Klassenmodelle sowie systemspezifische UML-Klassen- und Sequenzdiagramme.
- Contract Interface & Technology Neutral Architecture: NGOSS verwendet zur Integration verschiedener Anwendungen ein technologieneutrales Architekturkonzept sowie ein Vertragsmodell für eine verteilte Umgebung.
- NGOSS Compliance: Zur Sicherstellung des Zusammenspiels verschiedener OSS-Komponen- ten bietet NGOSS eine Testsuite, welche die Konformität zur eTOM und zum SID sowie zum Vertragsmodell und zum Architekturkonzept prüft.

Durch die Integration des Prozessrahmenwerks in das NGOSS-Programm sind die Weichen für einen standardisierten Toolsupport durch Softwarehersteller gestellt.

2.4.2 Bestandteile der eTOM

Das Prozessrahmenwerk verwendet bei der Abbildung von Prozessen verschiedene Beschreibungs- ebenen (sogenannte Levels) zur hierarchischen Gliederung [TMF 07b, S. 21 - 23]. Die oberste Be- schreibungsebene, Level 0, stellt Geschäftsbereiche dar. Jede niedrigere Ebene verfeinert die darüber liegende Beschreibungsebene mit zusätzlichen Details. Level 1 befasst sich mit Prozessgruppen, die in den darunter liegenden Ebenen näher detailliert werden. Die nächste Ebene, Level 2, beschreibt Kernprozesse. Die Aktivitäten der Kernprozesse sind als Aktivitätsflüsse auf den untersten Ebenen, Level 3 bis 5, dargestellt. Während die oberen Levels umfangreich dokumentiert sind, werden auf der Ebene der Aktivitätsflüsse lediglich Teilbereiche abgebildet (vgl. [TMF 04g]). Auf den untersten Ebenen Level 4 und 5 existieren in der aktuellen Version 7 der eTOM bisher keine Beschreibungen. Daher beschränkt sich die Darstellung im Folgenden auf die darüber liegenden Levels.

Auf oberster Ebene, Level 0, befinden sich folgende Elemente [TMF 07a, S. 23 - 25]:

- Kunden,
- Geschäftsprozesse,
- Geschäftszweckneutrale Unternehmensfunktionen,
- Anteilseigner, Mitarbeiter und andere Interessensgruppen als interne und externe Partner des Unternehmens,
- Lieferanten und Leistungspartner.

Dabei werden Kunden, Lieferanten und Leistungspartner sowie Anteilseigner, Mitarbeiter und an- dere Interessensgruppen als Parteien beschrieben, mit denen der Service Provider interagiert. Die eigentlichen Prozesse können in drei Gruppen aufgeteilt werden. Die linke Gruppe in Abbildung 2.9 enthält Prozesse aus den Bereichen Strategy, Infrastructure and Product (SIP), die sich mit strategischen und somit längerfristigen Aufgaben sowie Lebenszyklusaspekten von Diensten befassen. Die rechte Gruppe stellt den Prozessbereich Operations (OPS) dar, der durch eine starke KundenAusrichtung charakterisiert ist und die operative Bereitstellung von Diensten sicherstellt. Die untere Gruppe des Enterprise Managements enthält Prozesse, die in allen Unternehmen vorhanden sind, wie beispielsweise Personalwesen oder Controlling.

Die Prozessgruppen werden auf jedem Level vertikal und horizontal gegliedert. Die vertikale Anord- nung stellt End-To-End-Geschäftsprozesse dar, die Wert für Kunden bzw. Service Provider schöpfen. Die horizontale Gliederung bildet Funktionsbereiche ab und entspricht den Fachabteilungen eines Unternehmens. Während die Bereiche SIP, OPS und Enterprise Management vertikal angeordnet sind, werden auf oberster Ebene folgende horizontale Prozessgruppen unterschieden: Market, Pro- duct and Customer, Service, Resource und Supplier/Partner. Aus Gründen der Übersichtlichkeit wurden die horizontalen Prozessgruppen aus Level 0 nicht in Abbildung 2.9 dargestellt. Wie im An- schluss gezeigt wird, fassen sie jeweils zwei horizontale Level 1 Prozesse zusammen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.9: Level 1 Prozesse des eTOM-Rahmenwerks (in Anlehnung an [TMF 07b, S. 22]) Auf der nächsten Ebene (Level 1 [TMF 07a, S. 25 - 39]) werden die Prozesse aus den einzelnen Grup- pen ebenfalls sowohl vertikal als auch horizontal gegliedert. Die vertikale Gliederung enthält sie- ben End-To-End-Prozesse, die in Abbildung 2.9 als Säulen dargestellt sind. Die Prozesse der Säulen Fulfillment, Assurance und Billing (FAB) aus dem Level 0 Bereich OPS bilden als Echtzeitprozesse den Kernbereich der eTOM. Sie beinhalten Schnittstellen zum Kunden und ermöglichen die operative Leistungserstellung. Die Säule Operations Support & Readiness (OSR) besitzt ebenfalls eine Schnittstelle zum Kunden, der Fokus liegt jedoch auf der Sicherstellung der Leistungsfähigkeit der FAB -Prozesse. Dies schließt beispielsweise Kundensupport über Onlineportale mit ein.

Die funktionale Level 0 Prozessgruppierung wird im OPS -Bereich über Level 1 Prozesse weiter detailliert. Im Folgenden wird beschrieben, durch welche horizontalen Level 1 Prozesse die funktionale Level 0 Prozessgruppen im OPS -Bereich verfeinert werden.

- Market, Product and Customer: Customer Relationship Management umfasst alle Kundenbeziehungen. Dies schließt die Identifikation von Kundenbedürfnissen, Kundenakquise sowie den Ausbau von Kundenbeziehungen mit ein.
- Service: Der Prozess Service Management & Operations hält alle Informationen vor, die ein Kunde bezüglich eines Dienstes benötigt. Darüber hinaus werden Funktionalitäten für die Verwaltung und den Betrieb der Dienste von diesem Prozess verwaltet.
- Resource: Resource Management & Operations beschäftigt sich analog zum zuvor genannten Prozess mit der Verwaltung von Ressourcen sowie Informationen über diese.
- Supplier/Partner: Supplier/Partner Relationship Management kümmert sich um Beziehungen mit Zulieferern und Partnern.

Der Bereich SIP enthält vertikale Prozesse, die keine direkten Kundenschnittstellen besitzen und nicht direkt zur Leistungserstellung beitragen, jedoch die Prozesse aus dem OPS -Bereich langfristig unterstützen. Darunter zählen die Prozesse Strategy & Commit, sowie Infrastructure bzw. Product Lifecycle Management (siehe Abbildung 2.9). Prozesse der ersten vertikalen Säule unterstützt das Produkt- und Lebenszyklusmanagement durch die Erstellung und Umsetzung von Strategien. Die Prozesse der beiden anderen Säulen ermöglichen und steuern Kernabläufe und Kundenprozesse zur Befriedigung von Kundenerwartungen und Marktnachfragen, indem neue Infrastrukturkom- ponenten oder Produkte eingeführt werden.

Die Prozesse aus dem Bereich SIP können folgendermaßen den horizontalen Level 1 Bereichen zugeordnet werden:

- Market, Product and Customer: Das Marketing & Offer Management beschäftigt sich mit der Definition von Strategien, der Entwicklung und Verwaltung von Produkten sowie der Umsetzung von Marketing- und Angebotsstrategien.
- Service: Service Development & Management umfasst das Entwickeln, Planen und Ausliefern von Diensten an OPS -Prozesse.
- Resource: Resource Development & Management stellt durch das Entwickeln, Planen und Ausliefern von Ressourcen den OPS -Prozessen nötige Ressourcen zur Verfügung, um Dienste und Produkte zu ermöglichen.
- Supplier/Partner: Das Supply Chain Development & Management konzentriert sich auf Inter- aktionen mit Zulieferern und Partnern, damit Dienste und Produkte bestmöglich unterstützt werden.

Die nächste Betrachtungsebene (Level 2) umfasst die Kernprozesse, welche in [TMF 07e] beschrieben werden und eine Verfeinerung der Prozessgruppen des vorangehenden Abschnittes darstellen.

2.4.3 Nutzen der eTOM

Die eTOM stellt eine Einheitssprache für Service Provider zur Verfügung und bietet ein gut struk- turiertes Prozessrahmenwerk, das als Ausgangspunkt für eine Neuausrichtung der Organisation eines Service Providers dienen kann. Da das Rahmenwerk seinen Ursprung in der Telekommunika- tionsbranche hat, wo die Service Provider typischerweise als eigenständige Unternehmen auftreten, behandelt es nicht nur Prozesse zur Diensterbringung und -unterstützung, sondern bindet auch andere Unternehmensbereiche wie beispielsweise Controlling und Vertrieb in die Betrachtung mitein. Die Einbettung in das NGOSS-Programm, worin die eTOM-Prozesse innerhalb des SID auf ein Informations- und Datenmodell abgebildet werden, ermöglicht es Softwareherstellern eine Toolunterstützung für die Prozesse aufbauend auf Standards zu schaffen.

2.4.4 Kritische Bewertung der eTOM

Aufgrund des Ursprungs in der Telekommunikationsindustrie ist in vielen Bereichen eine klare Aus- richtung auf Massendienste zu erkennen. Dies lässt sich beispielsweise an der Trennung zwischen OPS - und SIP -Bereiche sowie die Einteilung der FAB -Kernprozesse erkennen. Eine Einteilung in Standarddienste und Individualdienste ist nicht immer sinnvoll bzw. möglich, insbesondere wenn im Leistungsportfolio des Service Providers auch technische Dienste enthalten sind [Prob 03, S. 92]. Zwar bietet die eTOM ein gut strukturiertes Referenzmodell für die Prozesse, jedoch ist es in man- chen Bereichen nicht sehr detailliert. HENDRIKS [Hend 06] kritisiert, dass die eTOM die einzelnen Geschäftsaktivitäten in Isolation betrachtet und daher der Prozess als eine Folge von Aktivitäten nur skizziert wird. Die Einbettung in das NGOSS-Programm bietet zwar interessante Möglichkeiten zur Automatisierung der Prozesse, jedoch ist zum einen das SID noch nicht auf alle Bereiche des Rahmenwerks abgestimmt und zum anderen existiert noch keine Implementierung der Architektur im Sinne einer vollständigen OSS- und BSS-Unterstützung.

2.4.5 Vergleich eTOM und ITIL

Das TMF veröffentlicht zusammen mit der eTOM eine Abbildung bzw. Integration der ITIL-Prozes- se in die eTOM (vgl. [TMF 04h]). Seitens OGC wird aktuell keine Abbildung oder Integration der eTOM-Prozesse in das ITIL-Rahmenwerk angestrebt. Das vom TMF beschriebene Vorgehen bildet zunächst die oberen Beschreibungsebenen (Level 0 und Level 1) der eTOM auf Bereiche der ITIL ab. Anschließend werden beispielhaft die Prozesse Incident Management und Change Management auf detaillierteren Ebenen betrachtet. Dabei ist anzumerken, dass es in vielen Bereichen Überschnei- dungspunkte gibt, allerdings die eTOM auch Prozesse außerhalb des IT Service Managements nach den ITIL-Vorgaben betrachtet. Darunter zählt insbesondere der Komplex des Enterprise Manage- ments, der beispielsweise das Human Resources Management enthält, das in der ITIL nicht adres- siert wird. Eine Integration der ITIL und der eTOM ist seitens der Telekommunikationsanbieter vor allem hinsichtlich der unterschiedlichen Ausrichtung beider Rahmenwerke lohnenswert. Für Tele- kommunikationsunternehmen bietet die eTOM Hilfestellungen zum Betrieb und zur Auslieferung von Massendiensten an Direktkunden. Zur Kommunikation mit Zulieferern sowie zur Strukturie- rung der organisationsinternen IT-Prozesse bietet die ITIL anerkannte Best Practices. Aufgrund des unterschiedlichen Ursprungs beider Rahmenwerke, legt die ITIL den Fokus auf organisationsinter- ne Service Provider und deren Prozesse. Die eTOM hingegen hat seine Wurzeln in der Telekommu- nikationsbranche, in der die Service Provider als eigenständige Unternehmen auftreten, wodurch alle Prozesse eines Unternehmens im Rahmenwerk enthalten sind. Während in der ITIL eine ein- heitliche, jedoch recht unspezifische bzw. abstrakte Beschreibungstiefe der Prozesse Verwendung findet, bemüht sich die eTOM um eine Strukturierung der Prozesse auf unterschiedlichen Beschrei- bungsebenen. Auf oberster Ebene werden die Prozesse recht detailliert beschrieben. Ab der Ebene der Aktivitätsflüsse mangelt es der eTOM an einer einheitlich detaillierten Beschreibung. Im Hin- blick auf die Zertifizierung besteht im Rahmen der ISO 20000 (siehe Abschnitt 2.2) die Möglichkeit die Unternehmensprozesse auf ITIL-Konformität zu zertifizieren. Mit der Einbettung in das NGOSS- Programm, das mit dem SID ein Informations- und Datenmodell bereitstellt und darüber hinaus die Tool-Zertifizierung übernimmt, ist ein solider Standard zur Tool-Unterstützung für das eTOM be- reits vorhanden. Seitens der ITIL fehlen sowohl ein Informations- und Datenmodell als auch die Möglichkeit der Tool-Zertifizierung. Derzeit existierende Tools bezeichnen sich selbst als ITIL kon- form, eine Verifizierung durch die Herausgeber der ITIL ist jedoch nicht vorgesehen. Somit setzt die eTOM mit NGOSS und dem SID Grundlagen für die Zertifizierung sowie zur Automatisierung der Prozesse, die bisweilen nicht für ITIL verfügbar sind. Tabelle 2.1 enthält eine Übersicht über Gemeinsamkeiten und Unterschiede zwischen der eTOM und der ITIL.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Vergleich eTOM und ITIL in Anlehnung an [Graw 03] und [Huan 05]

2.4.6 Konsequenzen

Dadurch, dass die OGC gerade im Hinblick auf die Tool-Unterstützung noch keine vergleichbaren Ansätze wie das TMF mit NGOSS liefert, ist eine nähere Betrachtung dieser Konzepte lohnenswert. Wie GRAWE [Graw 03] feststellt, ist ein effektives und effizientes IT Service Management nur mit dem Einsatz von Management-Werkzeugen möglich. Da ITIL weder eine Zertifizierung von Werk- zeugen anbietet noch ein Informations- oder Datenmodell veröffentlicht, auf deren Basis Werkzeuge zur Automatisierung der Prozesse abgeleitet werden könnten, sind derzeit viele proprietäre Lösun- gen am Markt, die einen „Best-of-breed“ Einsatz in Unternehmen fördern. „Best-of-breed“ heißt, dass ein Unternehmen für verschiedene Teilbereiche die jeweils beste Softwarelösung einsetzen soll, die über Schnittstellen und Adaptoren zu verbinden sind. Dadurch entstehen für einzelne Teilberei- che Insellösungen, die sich nur schwer integrieren lassen, da sie nicht auf einer einheitlichen Infor- mationsbasis aufbauen. Im Rahmen dieser Arbeit werden Konzepte aus NGOSS aufgegriffen, um ein Informations- und Datenmodell für die ITIL in analoger Weise wie es das SID für die eTOM darstellt, abzuleiten.

2.5 Bestehende Ansätze zur Modellierung

Im Folgenden werden bestehende Informations- und Datenmodelle vorgestellt, und deren Verwend- barkeit im Kontext des IT Service Managements evaluiert. Anschließend werden im Abschnitt 2.5.2 Methoden zur Modellierung aufgeführt, die im Bereich der Prozessmodellierung Verwendung fin- den.

2.5.1 Vorhandene Informations- und Datenmodelle

Für das IT-Management gibt es bereits Architekturen, die einen Beschreibungsrahmen für Mana- gementobjekte in Form eines Informationsmodells bieten. Dies motiviert eine nähere Betrachtung der Informationsmodelle hinsichtlich der Anwendbarkeit und Übertragbarkeit der Informations- modelle auf den Bereich des IT Service Managements. LANGER hat allgemeine Anforderungen an Informationsmodelle formuliert, während BRENNER ET AL. sich auf Anforderungen an die Model- lierung einer CMDB konzentriert haben (vgl. [Lang 01, S. 90 ff.] bzw. [BGSS 06]). Essenziell für die Übertragbarkeit des Informationsmodells auf andere Anwendungsbereiche ist die Verwendung eines objektorientierten Ansatzes. Das Informationsmodell muss überdies auf verschiedene Datenmodelle abbildbar sein und zudem Oberklassen zur Verfügung stellen, von denen Managementobjekte für das IT Service Management abgeleitet werden können. Im Folgenden werden verschiedene Informationsmodelle vorgestellt und diesbezüglich bewertet.

Informationsmodell der Internet-Managementarchitektur

Die heute im Bereich von lokalen Rechnernetzen am weitesten verbreitete Managementarchitek- tur (vgl. [HAN 99, S. 563]) ist die von Internet Activity Board (IAB) und der Internet Enginee- ring Task Force (IETF) entwickelte Internet-Managementarchitektur [RoMc 90] [CFSD 90]. Das zu- grunde liegende Informationsmodell verwendet keine objektorientierten Ansätze. Management- objekte basieren auf einem datentyporientierten Ansatz. Sie beschreiben Tabellen oder Variablen und werden in Form eines Baumes, dem Internet-Registrierungsbaum, inhaltlich strukturiert. Eine Template-Sprache dient zur Spezifikation von Managementobjekten, die ein SNMP-Agent zur Ver- fügung stellt und in einer Management Information Base (MIB) verwaltet werden. Hauptnachteil des Informationsmodells ist die fehlende Objektorientierung, weshalb keine Mechanismen zur Wie- derverwendung, Verfeinerung und Generalisierung zur Verfügung stehen. Daher ist die Internet- Managementarchitektur für die Betrachtung innerhalb dieser Arbeit ungeeignet.

Informationsmodell der OSI-Managementarchitektur

Das OSI-Management Rahmenwerk der ISO und International Telecommunication Union (ITU) beschreibt eine Architektur, die konform zum OSI-Schichtenmodell ist [ISO 7498]. Das Informationsmodell [ISO 10165] ist vollständig objektorientiert und Managementobjekte werden durch eine Template-Sprache, die in den „Guidelines for the definition of managed objects“ (GDMO) beschrieben ist [ISO 10165-4], definiert. Durch den Fokus auf das Netz- und Systemmanagement und den Mangel an IT Service Management-Konzepten ist es als Grundlage für die vorliegende Arbeit ungeeignet [Lang 01, S. 55]. Ein weiterer Nachteil der OSI Managementarchitektur ist die mangelnde Verbreitung aufgrund der hohen Komplexität der Architektur.

Reference Model of Open Distributed Processing

Das Reference Model Of Open Distributed Processing (RM-ODP) ist ein Standard für den Entwurf verteilter Systeme, der von der ISO zusammen mit der ITU-T festgelegt wird [ISO 10746]. Das RM- ODP Meta-Modell spezifiziert Konzepte, Regeln und Infrastrukturobjekte für verteilte Anwendun- gen. Die Dienste der einzelnen Komponenten einer verteilten Anwendung können über definierte Schnittstellen angesprochen werden. Zur Reduktion der Komplexität wird das Gesamtsystem aus unterschiedlichen Sichten (sogenannte Viewpoints) untersucht, die jeweils verschiedene Abstrak- tionen des Betrachtungsbereichs mit einem bestimmten Fokus darstellen. Das Informationsmodell wird innerhalb des Information Viewpoint definiert. In dieser Sicht wird die Struktur und die Se- mantik der auszutauschenden Informationen festgelegt. Im Enterprise Viewpoint wird die Gesam- tumgebung, der Nutzungsbereich und der Zweck der Anwendung beschrieben. Dabei werden Be- dingungen und Zielvorgaben sowie Anforderungen an das System aus Sicht des Unternehmens fest- gelegt. Der Computational Viewpoint teilt das Gesamtsystem in funktionale logische Komponenten auf, die als Objekte modelliert werden. Interaktionen finden über Dienste, die jedes Objekt durch Schnittstellen anbietet und nutzen kann, statt. Diese Interaktionen werden im Engineering View- point auf konkrete Technologien und Protokolle abgebildet. Der Technology Viewpoint beschreibt schließlich die Hard- und Softwarekomponenten, auf denen die verteilte Anwendung ausgeführt wird. Da es sich beim RM-ODP um ein Meta-Modell handelt, werden Konzepte beschrieben und keine konkreten Technologien [Lang 01, S. 59 f.]. Im Telekommunikationssektor fördert das Rah- menwerk Telecommunications Information Networking Architecture (TINA) die Wiederverwend- barkeit, Interoperabilität und Transparenz von Software-Komponenten auf einer abstrakten Trans- portinfrastruktur [TINA 95]. TINA basiert auf RM-ODP und versucht existierende Architekturen aus dem Telekommunikationssektor zu integrieren. Die Informationsmodellierung geschieht mittels einer Erweiterung von GDMO, das dem OSI-Managementmodell zugrunde liegt. Die Beschreibung der Managementobjekte geschieht auf Basis der Object Modeling Technique (OMT), ein Vorläufer der UML, der von RUMBAUGH entwickelt wurde. Dadurch wurde eine Abbildbarkeit der Objekte auf eine große Bandbreite von Sprachen anderer Informationsmodelle ermöglicht. Jedoch fehlen insbesondere im Bereich des IT Service Managements detaillierte Spezifikationen, weshalb TINA als Grundlage für diese Arbeit keine Verwendung finden wird.

Common Information Model

Im Gegensatz zur Internet-Managementarchitektur basiert das Informationsmodell des Common Information Models auf einem objektorientierten Ansatz. Der Standard wird von der Distributed Management Task Force (DMTF) entwickelt und hat zum Ziel, eine hersteller- und plattformun- abhängige Managementschnittstelle zur Verfügung zu stellen, die eine möglichst verlustfreie Inte- gration bestehender Modelle ermöglicht. Dadurch können Managementinformationen plattform- übergreifend ausgetauscht und einheitlich zugegriffen werden [DMTF 03]. Das Common Informa- tion Model ist in das Web-Based Enterprise Management (WBEM) Programm der DMTF eingebet- tet, das Standards für Managementinformationen veröffentlicht, um einen herstellerunabhängigen Austausch von Managementinformationen zu ermöglichen. Das Informationsmodell besteht aus einem UML-basierenden Metamodell und einer Spezifikationssprache zur Beschreibung von Ma- nagementobjekten, die eine Abbildung von Managementobjekten auf verschiedene Technologien ermöglicht. Überdies sind im Informationsmodell Oberklassen enthalten, die als Grundlage für eine technologiespezifische Abbildung dienen. Das Metaschema dient als Grundlage für die Integration von Managementmodellen und stellt eine Sprache sowie eine Methodologie zur Beschreibung von Managementinformationen zur Verfügung. Auf Grundlage des Metaschemas können Oberklassen gebildet werden, die Managementinformationen in UML beschreiben. Die Managementinformatio- nen können schließlich für einen automatisierten Austausch und zur Verarbeitung durch das Mana- ged Object Format spezifiziert werden.

Das Common Information Model ist in drei Ebenen aufgeteilt:

- Das Core Model modelliert Klassen, Assoziationen und Eigenschaften, die von allen Manage- mentbereichen benötigt werden und als Basis für die Vererbung dienen. Darunter fällt unter anderem das CIM_ManagedElement, das die Ausgangsklasse aller Managementobjekte bildet.

- In den Informationsmodellen des Common Model s werden die Klassen um technologieunab- hängige Klassen verfeinert, die als Basis von Managementanwendungen verwendet werden. In diesen Bereich fallen Modelle für Systeme, Anwendungen, Netzwerke und Geräte. Die Klassen, Eigenschaften, Assoziationen und Methoden aus diesem Bereich sollen als Grundlage für den Softwareentwurf dienen.
- Das Erweiterungsschema (Extension Schema) erweitert die Informationsmodelle um technologiespezifische Klassen. Es bildet das Datenmodell, das die Implementierung der Klassen aus dem Core bzw. Common Model auf spezifische Plattformen ermöglicht.

Für einen offenen und standardisierten Austausch der Managementinformationen können die Com- mon Information Model-Klassen beispielsweise als XML-Elemente in Form von Document Type Definitions (DTDs) definiert werden. Als nachteilig für die weitere Betrachtung innerhalb dieser Ar- beit wird vor allem die fehlende Integration von IT Service Management-Aspekten gesehen (vgl. [BGSS 06, S. 8]). Das Hauptaugenmerk Common Information Model richtet sich auf das Manage- ment der operativen Infrastruktur. Konzepte aus der Geschäftsperspektive werden nicht näher be- rücksichtigt. Des Weiteren ist eine Anpassung des Modells nicht ohne weiteres möglich, denn dazu müssten die Zusammenhänge der knapp eintausend Objektklassen nachvollzogen und berücksich- tigt werden [KKS 01]. Ein weiterer Nachteil ist die zugrunde liegende Modellierung, die aufgrund der Anpassungen und Erweiterungen der UML eine Verwendung von Standard-Modellierungstools erheblich erschwert [KKS 01].

Shared Information and Data Model

Das vom TMF veröffentlichte SID ist im NGOSS-Programm eingebettet und bildet das Informati- onsmodell der eTOM (siehe Abschnitt 2.4) [TMF 04b]. Durch diese Einbettung wird der Zusammen- hang mit Konzepten des IT Service Managements hergestellt. Dadurch werden im Gegensatz zum Common Information Model, das hauptsächlich Managementinformationen der Infrastruktur ab- bildet, Informationen modelliert, die von allgemeinem Geschäftsinteresse sind. Im Gegensatz zum Common Information Model basiert SID auf einen objektorientierten Ansatz, der sich streng an die Konzepte der UML hält. Zur Gliederung des Betrachtungsbereichs verwendet das SID verschiede- ne Sichten (sogenannte Views). Das Informationsmodell wird in der Business View beschrieben und die System View enthält zusammen mit der Implementation View das Datenmodell. Innerhalb der Geschäftssicht werden Entitäten aus der Realwelt modelliert, welche von besonderem Geschäfts- interesse sind. Die Systemsicht verfeinert schließlich die in der Geschäftssicht identifizierten Enti- täten um weitere Eigenschaften und Zusammenhänge sowie um zusätzliche Klassen, so dass sich die Realwelt auf Softwarekonzepte abbilden lässt. Die Implementierungssicht bildet schließlich die Konzepte der beiden darüber gelegenen Sichten auf konkrete Technologien ab. Durch die starke Ausrichtung auf Geschäftsprozesse aus der eTOM, sowie der objektorientierten UML-konformen Modellierung erscheint eine nähere Betrachtung der Modellierungsmethoden der SID für die der Arbeit zugrunde liegenden Aufgabenstellung als äußerst interessant. Deshalb wird in Abschnitt 2.6 näher auf das SID eingegangen.

2.5.2 Methoden zur Modellierung

Im Bereich der Prozessmodellierung gibt es verschiedene anerkannte Ansätze zur Modellierung. Im Folgenden wird auf die wichtigsten kurz eingegangen und deren Methodik zur Informations- und Datenmodellierung vorgestellt.

Architektur integrierter Informationssysteme (ARIS)

Die von SCHEER [Sche 97] entwickelte Architektur integrierter Informationssysteme (ARIS) defi- niert einen Ordnungsrahmen für betriebliche Informationssysteme aus den vier Perspektiven Or- ganisationssicht, Datensicht, Funktionssicht und Steuerungssicht. Die Organisationssicht beschreibt die Aufbauorganisation und ihre Beziehungen in Form von Organigrammen, die Datensicht bil- det unternehmensrelevante Informationen und deren Beziehungen als Entity Relationship-Modell ab. Die Funktionssicht modelliert alle funktionalen Elemente in Form eines Funktionsbaums. Die Steuerungssicht verknüpft schließlich die Sichten und erstellt einen logischen Ablaufplan durch er- eignisgesteuerte Prozessketten [Sche 97].

Für die Aufgabenstellung, die dieser Arbeit zugrunde liegt, ist vor allem die Datensicht relevant. Innerhalb dieser Perspektive werden das Fachkonzept, das Datenverarbeitungskonzept und die Implementierungssicht beschrieben. Das Fachkonzept enthält Entitäten, Beziehungen der Entitäten untereinander sowie Attribute. Das Datenverarbeitungskonzept überführt die Entitäten und deren Zusammenhänge in ein Relationsmodell. Die Implementierungssicht beschreibt, wie das zuvor ent- wickelte Schema mit Hilfe einer Datenbankbeschreibungssprache umgesetzt werden kann.

Die Entity Relationship-Modelle auf Fachkonzeptebene gehen auf CHEN [Chen 76] zurück. Dabei wird zwischen Entitäten und Beziehungen unterschieden. Entitäten sind wohlunterscheidbare Ge- genstände (gedanklicher oder physischer Natur) der zu modellierenden Welt, während Beziehun- gen den semantischen Zusammenhang mehrerer Entitäten abbilden. Entitäten und Beziehungen werden zu Typen abstrahiert, wobei Entitäten grafisch als Rechteck und Beziehungen als Rauten repräsentiert werden und über Kanten mit den Entitäten verbunden sind [KeEi 04, S. 35]. Da Entity Relationship-Modelle primär zur Modellierung von Datenbanken Verwendung finden und zudem als Vorläufer der UML zu sehen sind, die nicht alle objektorientierten Konzepte unterstützen (vgl. [EnGr 00]), erscheinen sie für die Modellierung der Artefakte in dieser Arbeit als weniger geeignet.

Business Process Modeling Notation (BPMN)

Die Business Process Modeling Notation (BPMN) ist eine Modellierungssprache im Bereich der Ge- schäftsprozessmodellierung. Sie wird seit 2005 durch die Object Management Group (OMG) ver- öffentlicht [OMG 06a]. BPMN spezifiziert grafische Elemente, mit deren Hilfe die Abbildung von Geschäftsprozessen und die Abfolge von Prozessschritten in einer für den Menschen nachvollzieh- baren und verständlichen Weise vorgenommen werden kann. Durch die Business Process Execu- tion Language (BPEL), die von der Organization for the Advancement of Structured Information Standards (Oasis) standardisiert wird, können diese Abflogen der Prozessschritte in XML überführt werden [AAA+ 07]. Dadurch ist BPEL die Grundlage für eine technische Implementierung der in BPMN modellierten Prozesse und deren Abläufe durch ein Tool. Im Sinne des Ordnungsrahmens der zuvor vorgestellten ARIS beschäftigt sich BPMN mit der Steuerungssicht, wohingegen sich die Informations- und Datenmodelle innerhalb der Datensicht befinden, die nicht im Fokus von BPMN steht. Im Zentrum der Modellierung mit BPMN stehen die Prozessflüsse und nicht die Artefakte, die es im Rahmen dieser Arbeit zu betrachten gilt. Zwar können Artefakte durch Data Objects abgebil- det werden, jedoch ist eine detaillierte Modellierung der Beziehungen zwischen den Informationen und Daten innerhalb eines Prozess nicht im Fokus der BPMN. Vielmehr werden Artefakte im Kon- text des Prozessflusses abgebildet.

Unified Modeling Language (UML)

Die Unified Modeling Language (UML) [OMG 07] wird ebenfalls von der OMG entwickelt und veröffentlicht. Sie ist eine Modellierungssprache, die aufgrund der zugrunde liegenden objektorien- tierten Konzepte vor allem im Bereich der Software Entwicklung große Verbreitung findet. Damit ist sie von großer Relevanz für die Modellierung von betrieblichen Anwendungssystemen. Die UML stellt für die Modellierung verschiedene Diagramme auf verschiedenen Abstraktionsebenen zu Ver- fügung. Auf oberster Ebene befindet sich das Use Case Diagramm, das die Anwendungsfälle des beschreibenden Systems abbildet. Für das Zusammenspiel zwischen Objekten, die in Anwendungs- fällen identifiziert wurden, können Sequenzdiagramme verwendet werden, welche die Operationen auf den Objekten als dynamisches Modell abbilden. Die Objekte werden im statischen Modell mit- tels Klassendiagrammen näher verfeinert, in Klassen eingeteilt und mit Attributen und Beziehun- gen zwischen den Klassen versehen. Darüber hinaus stehen Aktivitäts- und Zustandsdiagramme zur Verfügung, um Zustände eines Objekts und deren Übergänge in Form von Aktivitäten zu be- schreiben. Im Gegensatz zum Entity Relationship-Modell, das für die Datenmodellierung in ARIS verwendet wird, kann neben Attributen und Beziehungen auch das Verhalten (durch Angabe von Methoden) und die Sichtbarkeit von Entitäten bzw. Objekten abgebildet werden.

Durch die weite Verbreitung der UML stehen zahlreiche Werkzeuge zur Modellierung zu Verfü- gung. Darüber hinaus wird durch die Verwendung von UML im Rahmen dieser Arbeit keine spe- zielle Managementarchitektur impliziert. Wie in Abschnitt 2.8 gezeigt wird, kann aus den UML- Modellen automatisiert Code generiert werden. Das erstellte Informationsmodell kann somit auf verschiedene Datenmodelle abgebildet werden. Der Einbezug von objektorientierten Konzepten er- möglicht unter anderem eine einfache Wiederverwendung und Anpassung der Modelle. Aus Grün- den der Vergleichbarkeit der im Rahmen dieser Arbeit zu erstellenden Modelle mit Konzepten aus dem SID ist zudem die Verwendung von UML als Grundlage für die Modellierung von Artefakten motiviert.

2.6 Shared Information and Data Model (SID)

Bei der Betrachtung bestehender Informationsmodelle in Abschnitt 2.5.1 wurde bereits auf die Re- levanz des SID im Rahmen dieser Arbeit eingegangen. Insbesondere aufgrund der Ausrichtung an die eTOM-Prozesse und wegen der objektorientierten Modellierungsmethoden ist eine nähere Be- trachtung des SID äußerst lohnenswert. Zudem wurde beim Vergleich der eTOM und der ITIL in Abschnitt 2.4.5 festgestellt, dass ein vergleichbares Informations- und Datenmodell für die ITIL fehlt, was die nähere Betrachtung des SID motiviert.

2.6.1 Ursprung und Aufbau des SID

Wie die eTOM ist das SID ein Teil des NGOSS-Projekts. Die eTOM bildet innerhalb von NGOSS die Sicht auf Geschäftsprozessebene, während das SID die Daten und Informationen innerhalb der Geschäftsprozesse modelliert. Das SID wird vom TeleManagement Forum in Form von Dokumen- ten herausgeben. Die Dokumente lassen sich in einführende Dokumente („Getting Started“) und Anhänge („SID-Domain Addenda“) untergliedern. Die Anhänge sind einheitlich aufgebaut und be- schreiben textuell, grafisch (in Form von UML-Diagrammen) und detailliert (in Form eines Data Dictionaries) die Artefakte des betrachteten Bereichs. Dabei liegt der Fokus auf „things that are involved in business processes“[TMF 04b, S. 1] also Geschäftskonzepten. Darunter fallen beispiels- weise Personen, Anlagegüter, Produkte oder Dienstleistungen. Das SID verfolgt das Ziel, alle Infor- mationen bereit zu stellen, die für die Umsetzung der Anwendungsfälle der eTOM benötigt werden [TMF 04b, S. 4].

2.6.2 Informationsmodellierung im SID

Innerhalb der Einführungsdokumente wird der Begriff Informationsmodell folgendermaßen definiert: „An information model is a representation of business concepts, their characteristics and relationships, described in an implementation independent manner“ [TMF 04b, S. 4]. Diese Definition des Begriffs Informationsmodell deckt sich mit der Definition des Begriffs im Rahmen dieser Arbeit (vgl. Abschnitt 2.1). Das Informationsmodell enthält Identitäten von Objekten, Werte, Kontext und Rollen, Zustände und Lebenszyklen sowie Beziehungen der Objekte untereinander. Werte sind Objekte ohne Identität. Eine Rolle ist das Verhalten eines Objekts in einem bestimmten Kontext. Der Lebenszyklus ist der Zustand eines Objekts im Kontext all seiner Zustände.

Für die Erstellung des semantischen Modells und insbesondere für die Kategorisierung der Ele- mente verwendet das SID das Zachman-Rahmenwerk [Zach 87]. In dem von ZACHMAN [Zach 87] entwickelten Konzept wird mithilfe von Fragestellungen ein Ordnungsrahmen für Informationsar- tefakte geschaffen. Artefakte bzw. Bezugsobjekte werden auf unterschiedlichen Detaillierungsebe- nen aus verschiedenen Blickwinkeln betrachtet (vgl. [Zach 07]). Die Blickwinkel beleuchten das zu erstellende Modell aus verschiedenen Perspektiven, die eine hierarchische Gliederung des Betrach- tungsbereichs bewirken. Die oberste Ebene beschreibt Konzepte des zu erstellenden Modells im Kontext des gesamten Unternehmens aus Sicht des Planers. In der darunter liegende Ebene werden diese Konzepte verfeinert und aus der Sicht des Owners beschrieben. Dabei werden Informations- objekte und deren Beziehungen untereinander beschrieben. Während diese beiden Ebene konzep- tionelle Sachverhalte abbilden, werden eine Ebene darunter in der Perspektive des Designers Soft- warekonzepte beschrieben. Diese werden schließlich durch jede weitere Perspektive detailliert. Die zweite Dimension der Detaillierungsebenen gibt Antwort auf die folgenden Fragen:

- Was wird betrachtet? (Datensicht)
- Wie wird interagiert? (Funktionssicht)
- Wo wird agiert? (Netzwerksicht)
- Wer agiert? (Organisationssicht)
- Wann wird agiert? (Ablaufsicht)
- Warum wird agiert? (Strategische Sicht)

Tabelle 2.2 gibt eine Übersicht der Detaillierungsebenen auf Informationsartefakte des SID, wobei die Abbildung der Ebenen unter Verwendung der Business Grammar von MORIARTY [Mori 02] durchgeführt wurde.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2: Perspektiven auf Informationsartefakte im SID

Bei der Modellierung unterscheidet das SID zwischen dem „Analysis Model“, das sich mit der stati- schen Geschäftsmodellierung befasst und dem „Design Model“, welches das dynamisch Verhalten abbildet [TMF 04b, S. 25]. Im Kontext der Softwareentwicklung wird in der Modellierung ebenfalls zwischen Analyse und Design unterschieden. LARMAN [Larm 02] grenzt die beiden Begriffe folgen- dermaßen ab:

Objektorientierte Analyse beschäftigt sich mit der Ermittlung und Beschreibung der Objekte bzw. der Konzepte des Betrachtungsbereichs.

Objektorientiertes Design befasst sich mit der Definition von Klassen und deren Zusammenwir- ken. Dies schließt die Definition von Attributen und Methoden mit ein. Im Mittelpunkt steht die Umsetzung der Konzepte des Betrachtungsbereichs auf Softwarekonzepte.

Darüber hinaus gliedert er das Vorgehen der Analyse- und Design-Modellierung in folgende Schrit- te:

1. Definition von Anwendungsfällen (Schriftliche und informelle Beschreibungen des Betrach- tungsbereichs).
2. Definition des Domänenmodells (Identifikation und Klassifikation von realen Konzepten, At- tributen und Assoziationen aus dem Betrachtungsbereich).
3. Definition von Interaktionsdiagrammen (mit Hilfe von UML-Interaktionsdiagrammen wird der Nachrichtenfluss zwischen den Objekten unter der Berücksichtigung einwirkender Me- thoden modelliert. Die realen Konzepte dienen als Grundlage für das dynamische Design Mo- dell der Softwarekonzepte).
4. Definition von Klassendiagrammen aus dem Design (Modellierung der Klassen als Softwa- rekonzepte zusammen mit Attributen und Methoden als abstrahierte Konzepte des Betrach- tungsbereichs).

Bei der Betrachtung der Methoden zur Informationsmodellierung im SID ist anzumerken, dass die zugrunde liegende Methodik nicht oder nur unzureichend dokumentiert wurde. Der Bezug zum Zachman-Rahmenwerk wird nur in einem Satz erwähnt. An vielen Stellen wird auf Zusatzliteratur verwiesen, jedoch wird oftmals kein direkter Bezug zu dieser hergestellt, sondern sie ist nur im Lite- raturverzeichnis aufgeführt. Daher kann zwar aufgrund des Verweises auf LARMAN angenommen werden, dass die Designer des SID analog zum Vorgehen LARMAN [Larm 02] vorgegangen sind, es wird jedoch nicht dokumentiert, welche Schritte bei der Modellierung durchlaufen wurden. Ur- sache hierfür ist wohl der Ursprung des SID, der nicht in der Wissenschaft, sondern in der Praxis liegt.

[...]