Einführung des Prozesses Problem Management in der Business Unit Science & Technology der Bayer Business Services GmbH

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Vorgehensweise
1.3 Dank

2 Organisatorisches Umfeld

3 IT Service Management
3.1 Was ist IT Service Management?
3.2 Managementstandards für IT-Dienstleistungen
3.2.1 CObIT
3.2.2 MOF
3.2.3 IBM IT Process Model
3.2.4 HP IT Service Reference Model
3.2.5 Gegenüberstellung der Modelle
3.3 Qualitätsmanagement nach DIN EN ISO 9000ff
3.3.1 Kundenorientierung
3.3.2 Führung
3.3.3 Einbeziehung der Mitarbeiter
3.3.4 Prozessorientierter Ansatz
3.3.5 Systemorientierter Managementansatz
3.3.6 Ständige Verbesserung
3.3.7 Sachbezogener Ansatz zur Entscheidungsfindung
3.3.8 Lieferantenbeziehungen zum gegenseitigen Nutzen
3.4 Projektmanagement nach PRINCE
3.4.1 PRINCE 1
3.4.2 PRINCE 2
3.5 Auswahl eines Modells für die BBS-S&T-SST

4 ITIL
4.1 Geschichte
4.2 ITIL als Norm: BS 15000 und PD 0005
4.3 Vorteile und Nutzen von ITIL
4.3.1 Nutzen aus Unternehmenssicht
4.3.2 Nutzen aus Kundensicht
4.3.3 Reduzierung der IT-Kosten
4.4 Status und Trends von ITIL in Deutschland
4.4.1 Unterstützung der strategischen IT durch ITSM
4.4.2 Standardisierungsbedarf
4.4.3 Verbreitung von ITIL
4.4.4 Anwendung der ITIL-Prozesse
4.5 Struktur von ITIL
4.5.1 Service Delivery
4.5.1.1 Service Level Management (SLM)
4.5.1.2 Financial Management for IT Services
4.5.1.3 Capacity Management
4.5.1.4 IT Service Continuity Management
4.5.1.5 Availability Management
4.5.2 ICT Infrastructure Management
4.5.2.1 ICT Infrastructure Management Design and Plan
4.5.2.2 ICT Infrastructure Management Deployment
4.5.2.3 ICT Infrastructure Management Technical Support
4.5.2.4 ICT Infrastructure Management Operations
4.5.3 Service Support
4.5.3.1 Incident Management
4.5.3.2 Problem Management
4.5.3.3 Configuration Management
4.5.3.4 Change Management
4.5.3.5 Release Management
4.5.3.6 Service Desk
4.5.4 IT Security Management
4.5.5 Application Management
4.6 ITIL 1.x versus ITIL 2.x
4.6.1 Revisionsübersicht
4.6.2 Vergleich der Revisionen 1.x und 2.x

5 Problem Management-Implementierung
5.1 Projekt „Prozessverbesserung“
5.1.1 Organisatorische Neuausrichtung
5.1.2 Von Cost Centern zu Produkten
5.1.3 Zusammenspiel von ISO 9000 und ITIL
5.1.4 Re-Design vorhandener Prozesse
5.1.5 Akzeptanz schaffen
5.1.6 Ziele für Prozessbeschreibung und Arbeitsanweisungen
5.2 Organisatorische Eingliederung
5.2.1 Variante 1: Einfluss-Organisation
5.2.2 Variante 2: Matrix-Organisation
5.2.3 Variante 3: Linienorganisation
5.2.4 Verteilung der Zuständigkeiten bei der Organisation
5.2.5 Bewertung der Varianten im Hinblick auf den einzuführenden Prozess
5.3 Projektorganisation
5.4 Bayer-spezifische Anforderungen
5.4.1 Anforderungen des organisatorisches Umfelds
5.4.2 Besonderheiten im GxP-Umfeld
5.4.3 Vorgaben des Sarbanes-Oxley-Acts
5.5 Bayerspezifische Anpassungen
5.5.1 Rollenverständnis von Bayer Business Services
5.5.2 Aufbau der Rollenbeschreibungen
5.5.3 Anpassung der ITIL-Rollen an Unternehmenserfordernisse
5.5.4 Rollen im Prozess Problem Management
5.5.4.1 Problem Manager
5.5.4.2 Problem Koordinator
5.6 Begriffe und Inhalte
5.6.1 Begriffe
5.6.2 Ziel des Problem Managements
5.6.3 Aufgaben des Problem Managements
5.6.4 Metriken des Problem Managements
5.6.5 Schnittstellen des Problem Managements
5.7 Reaktives Problem Management
5.7.1 Ziele
5.7.2 Voraussetzungen
5.8 Proaktives Problem Management
5.8.1 Ziele
5.8.2 Voraussetzungen
5.9 Prozessvoraussetzungen
5.9.1 Kunden- bzw. Anwenderbezogene Daten
5.9.2 Personelle Anforderungen
5.9.3 Informationsbedarf
5.9.4 Unterstützende Tools
5.9.4.1 Perigrine Service Center
5.9.4.2 Service Desk Management System
5.9.4.3 Problem Management Tool
5.10 Eskalationsmanagement
5.10.1 Ziele und Voraussetzungen
5.10.2 Hierarchische und funktionale Eskalation
5.10.3 Vorgehensweisen
5.10.4 Schnittstellen zu anderen Prozessen
5.11 Wissensmanagement
5.11.1 Wissenstransfer
5.11.2 Ziel und Voraussetzungen
5.12 Reporting
5.12.1 Zielgruppen
5.12.2 Standard-Reports
5.13 Prozessbeschreibung
5.13.1 Begriffe, Definitionen
5.13.2 Rollen
5.13.3 Ziele
5.13.4 Workflow
5.13.5 Identifizieren und erfassen
5.13.6 Klassifizieren und zuweisen
5.13.7 Untersuchen und diagnostizieren
5.13.8 Lösungen suchen
5.13.9 Lösungsweg festlegen
5.13.10 Post Implementation Review (PIR)
5.13.11 Problem abschließen
5.14 Arbeitsanweisung
5.14.1 Begriffe, Definitionen
5.14.2 Vorgehensweise
5.14.2.1 Präambel
5.14.2.2 Quellen und Schnittstellen
5.14.2.3 Probleme identifizieren
5.14.2.4 Probleme klassifizieren
5.14.2.5 Problemursache erkennen
5.14.2.6 Problemursache untersuchen
5.14.2.7 Problemlösungen suchen und Umsetzen
5.14.2.8 Post Implementation Review
5.14.2.9 Problem abschließen
5.14.3 Vorgabe- und Nachweisdokumente
5.15 Schulung des Prozesses
5.15.1 Schulungsbedarf
5.15.2 Vorgehensweise
5.16 Einführungsaufwand
5.16.1 Aufwand
5.16.2 Methodik
5.16.3 Prozesse mit hohem Abstimmungsbedarf
5.16.4 Prozesse mit mittlerem Abstimmungsbedarf
5.16.5 Prozesse mit geringem Abstimmungsbedarf
5.16.6 Weitere Aufwendungen
5.16.7 Meetings des Kernteams
5.16.8 Projektkoordination
5.16.9 Gesamtaufwand
5.16.10 Kosten
5.16.11 Einführungskosten des Problem Managements
5.16.12 Betriebskosten
5.16.13 Return On Investment
5.16.13.1 Vergleich gelöster und nicht gelöster Service Desk-Anfragen
5.16.13.2 Verhinderung drohender Incidents
5.16.13.3 Reduzierung der Incidents pro Configuration Item
5.16.13.4 Kostenersparnis
5.17 Risiken
5.17.1 Mitarbeitermotivation
5.17.2 Projektplanung und -ablauf
5.17.3 Organisatorische Veränderungen
5.18 Make or Buy – Outsourcing?
5.18.1 Begriffe
5.18.2 Formen des Outsourcings
5.18.3 Chancen und Beweggründe des Outsourcings
5.18.4 Risiken des Outsourcings
5.18.5 Selektives Outsourcing
5.18.6 Rolle des ITIL-Modells in Outsourcing-Projekten
5.18.7 Outsourcing innerhalb der Bayer Business Services GmbH

6 Zusammenfassung und Ausblick
6.1 Zusammenfassung
6.2 Ausblick

7 Literaturverzeichnis

8 Glossar

Abbildungsverzeichnis

Abbildung 2-1: Organisation der Bayer Business Services GmbH (vgl. [BBS 2004])

Abbildung 2-2: Organisationsstruktur Science & Technology (Quelle: [BBS 2004])

Abbildung 3-1: Verbesserungspotentiale im ITSM (vgl. [DeDiCo 2004])

Abbildung 3-2: IuK-Einfluss auf Geschäftsprozesse (angelehnt an [KeDV1 2002, S.1])

Abbildung 3-3: Auswirkungen eines IT-Ausfalls (Quelle: [Synstar 2001])

Abbildung 3-4: Komponenten und Inhalte des CObIT-Frameworks (vgl. [ISACA 2004])

Abbildung 3-5: MOF-Modell (vgl. [MSMOF 2004, S. 22])

Abbildung 3-6: IBM IT Process Model (vgl. [IBMITSM 2001, S. 13])

Abbildung 3-7: HP IT Service Reference Model (Quelle: [HPITSM 2003, S. 15])

Abbildung 3-8: Prozessmodell der DIN EN ISO 9000:2000

Abbildung 3-9: Schritte des PRINCE 2-Projektmanagements (vgl. [KeySki 2004])

Abbildung 4-1: PDCA-Zyklus im Service Management (vgl. [CoSph 2003])

Abbildung 4-2: Standardisierungsbedarf im IT-Bereich (vgl. [DeDiCo 2004])

Abbildung 4-3: Geschätzter Standardisierungsbedarf (vgl. [DeDiCo 2004])

Abbildung 4-4: ITSM Map (Quelle: Gesamtprozessmodell der [BBS 2004])

Abbildung 4-5: Veröffentlichungsdaten von ITIL 1.x und 2.x

Abbildung 5-1: Workflow des Problem Managements

Abbildung 5-2: Von Cost-Centern zu Produktgruppen (vgl. [BBS 2004])

Abbildung 5-3: Anwendung der QM-Dokumentenpyramide auf ITIL (vgl. [BBS 2004])

Abbildung 5-4: Zusammenspiel von ISO 9001 und ITIL (vgl. [BBS 2004])

Abbildung 5-5: Von der Plattform- zur Prozessorientierung

Abbildung 5-6: Altes QM-System: Auffinden einer Checkliste (vgl. [BBS 2004])

Abbildung 5-7: Prototyp des neuen Systems: Checkliste auffinden (vgl. [BBS 2004])

Abbildung 5-8: Struktur der BBS-S&T-SST (vgl. [BBS 2004])

Abbildung 5-9: Eingliederungsoption „Einflussnahme"

Abbildung 5-10: Matrix-Eingliederungsoption

Abbildung 5-11: Eingliederungsoption „in Linie“

Abbildung 5-12: Gesamtübersicht des Projektplans (vgl. [BBS 2004])

Abbildung 5-13: Phasenstrukturplan als Gantt-Diagramm (vgl. [BBS 2004])

Abbildung 5-14: Aufteilung der Gesamtprojektzeit pro Mitarbeiter (vgl. [BBS 2004])

Abbildung 5-15: Einführungsplanung Problem Management (vgl. [BBS 2004])

Abbildung 5-16: Organisation des 1st/2nd-Level-Supports (vgl. [BBS 2004])

Abbildung 5-17: Umsetzung des SOAs bei der Bayer AG (vgl. [BBS 2004])

Abbildung 5-18: Perigrine Service Center - Ticketübersicht (vgl. [BBS 2004])

Abbildung 5-19: Verteilung der Incidents pro Team (vgl. [BBS 2004])

Abbildung 5-20: Verteilung der Incidents pro Produkttyp (vgl. [BBS 2004])

Abbildung 5-21: Verteilung der Incidents pro Server (vgl. [BBS 2004])

Abbildung 5-22: Verteilung der Incidents pro Wochentag (vgl. [BBS 2004])

Abbildung 5-23: Prototyp des Problem Management Tools – „Problem erfassen"

Abbildung 5-24: Prototyp des Problem Management Tools – „Probleme anzeigen"

Abbildung 5-25: Prototyp des Problem Management Tools – „Problem bearbeiten"

Abbildung 5-26: Workflow des Problem Managements

Abbildung 5-27: Entscheidungsbaum Dringlichkeit

Abbildung 5-28: Prioritätsmatrix

Abbildung 5-29: Aufwand für Projektkoordination und Rollen (vgl. [BBS 2004])

Abbildung 5-30: Gesamtaufwand (vgl. [BBS 2004])

Abbildung 5-31: Fiktive Kostenberechnung der ITIL-Einführung

Abbildung 5-32: Anteil des Problem Managements an den Gesamtkosten

Abbildung 5-33: Kostenberechnung der Prozess-Schulungen

Abbildung 5-34: Kostenberechnung für Prüfung und Freigabe

Abbildung 5-35: Lösungsrate im 1st-Level-Support (vgl. [BBS 2004])

Abbildung 5-36: Lösungszeiten im 1st-Level-Support (vgl. [BBS 2004])

Abbildung 5-37: Calls und Incidents von Januar bis Juli 2004

Abbildung 5-38: Reduzierte Zahl von Calls und Incidents

Abbildung 5-39: Eingesparte Bearbeitungszeit im 1st- und 2nd-Level-Support

Abbildung 5-40: Mögliche Kostensenkung durch Problem Management

Abbildung 5-41: Personal- und Einführungskosten des Problem Managements

Abbildung 5-42: Amortisationszeit des Problem Managements

Abbildung 5-43: Inhouse-Outsourcing (vgl. [Krcmar 2003])

Abbildung 5-44: Fallweiser Zukauf von Fremdleistungen (vgl. [Krcmar 2003])

Abbildung 5-45: Gründung einer Tochtergesellschaft (vgl. [Krcmar 2003])

Abbildung 5-46: Gründung einer strategischen Allianz (vgl. [Krcmar 2003])

Abbildung 5-47: Identifikation auszulagernder Prozesse (Quelle: [BoAlHa 2004])

Abbildung 5-48: Prozessmanagementstrategie-Potentiale (vgl. [MumCon 2003, S. 5])

Tabellenverzeichnis

Tabelle 3-1: Referenzmodelle serviceorientierten IT-Managements (vgl. [BrMeZ 2003])

Tabelle 3-2: Vergleich von ITSM-Modellen (vgl. [BrMeZ 2003, S. 48])

Tabelle 3-3: Projektphasen nach PRINCE 2

Tabelle 4-1: Unterstützung der strategischen IT durch das ITSM (vgl. [DeDiCo 2004])

Tabelle 4-2: Einsatz von ITIL nach Branchen (vgl. [DeDiCo 2004])

Tabelle 4-3: Beziehung zwischen ITIL-Einsatz und Mitarbeiterzahl (vgl. [DeDiCo 2004])

Tabelle 4-4: Aufbau und Zuordnung des „ITIL Back Catalogues"

Tabelle 5-1: Informationspflichten verschiedener Organisationsformen

Tabelle 5-2: Das Kernteam unterstützende Personen (vgl. [BBS 2004])

Tabelle 5-3: In ITIL 2.x definierte/erwähnte Rollen

Tabelle 5-4: Rollenbeschreibung „Problem Manager"

Tabelle 5-5: Rollenbeschreibung „Problem Koordinator"

Tabelle 5-6: CSFs und KPIs des Problem Managements (vgl. [ITSM3 2003])

Tabelle 5-7: Mögliche Inhalte des Reportings im Problem Management

Tabelle 5-8: Beispielmatrix zur Reporterstellung

Tabelle 5-9: Aufwand für Prozesse hohen Abstimmungsbedarfs (vgl. [BBS 2004])

Tabelle 5-10: Aufwand für Prozesse mittleren Abstimmungsbedarfs (vgl. [BBS 2004])

Tabelle 5-11: Aufwand für Prozesse geringen Abstimmungsbedarfs (vgl. [BBS 2004])

Tabelle 5-12: Widerstandsformen (vgl. [DopLau 1994])

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

„Das Problem zu erkennen ist wichtiger,

als die Lösung zu erkennen,

denn die genaue Darstellung

des Problems führt zur Lösung.“

Albert Einstein

1.1 Motivation

Diese Diplomarbeit wurde an der Fakultät für Informatik und Ingenieurwissenschaften der Fachhochschule Köln, Campus Gummersbach, in Zusammenarbeit mit der Business Unit^[1] Science & Technology (S&T) der Bayer Business Services (BBS) erstellt.

Um die IT-Organisation von S&T zukünftig prozessorientiert und kostenoptimiert auszurichten, entschloss man sich dazu, das IT Service Management-Modell ITIL einzuführen, um diese Ziele realisieren zu können.

Ziel dieser Diplomarbeit ist es, die praktische Entwicklung, Implementierung und Schulung des Prozesses^[2] Problem Management entlang des ITIL-Frameworks zu beschreiben und zu dokumentieren. So werden im Folgenden Verfahrensweisen, Methoden und Instrumente erläutert, die während der Einführung des Problem Managements eine wesentliche Rolle gespielt haben, welche Rahmenbedingungen dabei zu beachten waren und welche Probleme aufgetreten sind oder auftreten können.

Die Motivation, eine Diplomarbeit über das ITIL-Framework zu verfassen, ergab sich in erster Linie aus einer Vorlesung an der zu diesem Thema im Rahmen des Faches „Betriebliche Anwendungssysteme III“.

1.2 Vorgehensweise

Im zweiten Kapitel „Organisatorisches Umfeld“ wird eine kurze Einführung in das organisatorische Umfeld gegeben, in dem diese Diplomarbeit geschrieben worden ist. Darüber hinaus folgt ein erster Einblick in die Arbeitsgebiete und den Struktur dieser Business Unit.

Das dritte Kapitel „IT Service Management“ vermittelt einen Einblick in den Bereich des IT Service Managements, indem die Ziele von IT Service Management erläutert werden und die Motivation für IT Abteilungen und IT-Unternehmen vorgestellt wird, bisherige Strukturen zu überdenken und sich verstärkt dienstleistungsorientiert zu organisieren. Darüber hinaus werden einige Modelle vorgestellt, die sich mit dem Management von IT-Dienstleistungen und dem Projektmanagement von IT Projekten beschäftigen.

Nachdem die Bedeutung des Managements von IT Services herausgearbeitet worden ist, wird im vierten Kapitel „ITIL“ ein Ansatz zum IT Service Management weitergehend im Detail beschrieben. Es beschreibt die Information Technology Infrastructure Library, den am weitest akzeptiertesten und verbreiteten Standard, der IT Dienstleistern durch Best-practices dabei helfen soll, ihre Servicequalität sowie deren effiziente Erbringung zu verbessern.

Kapitel fünf, „Problem Management“, beschäftigt sich mit der Einführung des ITIL-Prozesses Problem Management in einer Business Unit der Bayer Business Services GmbH. In diesem Kapitel werden die Inhalte des Prozesses näher beschrieben und darauf aufbauend unternehmensspezifische Anpassungen sowie Maßnahmen zur Einführung des Prozesses vorgestellt. In diesem Rahmen werden ebenfalls Kosten und Risiken der Einführung sowie die Möglichkeit des Outsourcings diskutiert.

Im sechsten Kapitel „Zusammenfassung und Ausblick“ werden wesentliche Aspekte der Diplomarbeit zusammengefasst sowie ein Ausblick auf den weiteren Projektverlauf und die Zukunft des ITIL-Frameworks gegeben wird.

Im siebten Kapitel werden die Quellen dieser Diplomarbeit aufgelistet, auf die in den vorangegangenen Kapiteln in der Form [Quelle, Jahr] (zum Beispiel [OGC1 2000]) verwiesen worden ist.

Das achte und neunte Kapitel beschließen die Arbeit mit dem obligatorischem Glossar und der Erklärung, diese Arbeit selbständig verfasst zu haben.

1.3 Dank

An erster Stelle bedanke ich mich bei allen Personen, insbesondere meiner Mutter, die mich auf vielfältige Weise während des Studiums und der Erstellung der Diplomarbeit unterstützt haben.

Besonders dankbar bin ich dem Mitarbeitern von BBS-S&T-SST^[3] für die direkte und indirekte Unterstützung während dieser Phase sowie Herrn Helmut Schiefer und Herrn Erik Schitterer für Korrekturen und Anregungen.

Darüber hinaus gilt mein Dank Herrn Prof. Dr. Dipl.-Inform. Victor und Herrn Prof. Dr. Günther für die Unterstützung während der Erstellung der Diplomarbeit.

2 Organisatorisches Umfeld

Die Bayer Business Services GmbH ist eine Tochter der Bayer AG, die die fachliche Kompetenz des Bayer-Konzerns auf den Gebieten der informationstechnischen Infrastruktur, der angewandten Software und den administrativen kaufmännischen Funktionen bündelt, um Kunden^[4] innerhalb des Bayer-Konzerns effizient und professionell zu unterstützen.

Zu den kaufmännischen Prozessen zählt das Rechnungswesen ebenso wie personalwirtschaftliche, rechtliche und wissenschaftliche Dienste. Um für den Konzern und seine Teile ein höheres Maß an Professionalität bzw. Qualität und eine wirtschaftlich günstigere Versorgung zu gewährleisten, werden diese Dienste nicht aufgeteilt sondern in einem konzernweiten Dienstleistungsbereich BBS organisiert. Insofern handelt es sich um eine an der fachlichen Funktion orientierte Arbeitsteilung. Ziel der BBS ist es, als integraler wertschöpfender Bestandteil der Bayer AG ihren Teil zum Unternehmenserfolg beizutragen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-1: Organisation der Bayer Business Services GmbH^[5] (vgl. [BBS 2004])

Sie beschäftigt zurzeit etwa 5100 Mitarbeiter in 13 Bereichen und fünf Unterbereichen, für die 2004 ein Umsatz von 1,1 Mrd. € erwartet wird^[6].

Science & Technology ist eine Business Unit der BBS und unterstützt Geschäftsprozesse in den Bereichen Wissenschaft, Technik und Umweltschutz durch wissenschaftliche Recherchen, Bibliothek-Services, Informationssysteme für Endanwender^[7] sowie Entwicklung und Betrieb von Applikationen einschließlich des Betriebs der dafür eingesetzten Server. Es umfasst derzeit acht Bereiche (vgl. Abbildung 2-2: Organisationsstruktur Science & Technology (Quelle: [BBS 2004])). Mit diesen Aufgaben betreut Science & Technology zurzeit etwa 10.000 Anwender, 450 Systeme und 560 Oracle-Installationen^[8].

Der Bereich „Systems Management for Science & Technology“ der Science & Technology führt derzeit die ITIL-Prozesse des Service Delivery, des Service Supports, des ICT^[9] Infrastructure Managements sowie das Security Management ein. Begonnen wurde mit der Planung Mitte 2003 und der Einführung Ende 2003 mit den Prozessen Incident und Change Management sowie der Einführung eines Service Desks. Der Abschluss der Einführung wird zwischen Ende 2004 und Anfang 2005 erwartet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2-2: Organisationsstruktur Science & Technology^[10] (Quelle: [BBS 2004])

Während der ITIL-Prozess Configuration Management derzeit für etwa 400 Anwender der Infrastrukturbereiche (auch für BBS-S&T-SST) beschrieben wird, werden bei BBS-S&T-SST entschieden, dass folgende ITIL-Prozesse eingeführt werden sollen:

- die des Service Supports (außer dem Configuration Management),
- die des Bereichs Service Delivery (außer dem Capacity Management, das in einem späteren Projekt folgen soll),
- die des ICT Infrastructure Managements (außer dem Prozess Design & Plan)
- und das Security Management.

Der ITIL-Prozess Application Management wird aufgrund der Tatsache, dass bei BBS-S&T-SST nur in sehr geringem Umfang Software entwickelt wird, nicht eingeführt.

Das bestehende Qualitätsmanagementsystem nach DIN EN ISO^[11] 9000 soll nach der Einführung beibehalten werden.

3 IT Service Management

3.1 Was ist IT Service Management?

In zunehmendem Maße werden die Geschäftsprozesse von Unternehmen durch die Informationstechnologie (IT) gestützt. Die Bereitstellung der IT ist eine Dienstleistung, die von spezialisierten Abteilungen oder Drittanbietern erbracht wird und deshalb als IT Service bezeichnet wird. Aufgabe dieses Services ist die Unterstützung der Geschäftsprozesse der in- oder externen Kunden zur Erreichung des Unternehmensziels.

Durch die Einführung transparent dokumentierter Serviceprozesse und die fortlaufende Dokumentation der IT-Infrastruktur kann der IT Service qualitativ und quantitativ zielgerichtet, prozessorientiert, kundenorientiert und kostenoptimiert überwacht und gesteuert werden.

Wesentliche Ziele des IT Service Managements sind:

- den geforderten Output liefern: in- und externe IT Services an den bisherigen und zukünftigen Anforderungen des Unternehmens und der Kunden orientieren,
- die Qualität des Outputs (also der IT Services) sicherstellen und, falls möglich und erforderlich, verbessern,
- die Kosten der IT Services senken, indem diese dokumentiert, gesteuert und überwacht werden.

Befragt nach den Verbesserungspotentialen, die im ITSM^[12] Ihres Unternehmens stecken, antworteten 188 Geschäftsführer und IT-Leiter, dass die Effizienz, Transparenz und Kosten der IT-Prozesse optimiert werden könnten. Darüber hinaus wurden aber noch einige andere Aspekte ausgezählt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-1: Verbesserungspotentiale im ITSM (vgl. [DeDiCo 2004])

Die Bedeutung von IT Service Management wird dann besonders deutlich, wenn man sich vor Augen führt, welche Auswirkungen ein Teil- oder Totalausfall auf das operative Geschäft des Unternehmens hat. Ein Ausfall eines geschäftsprozessunterstützenden Rechnersystems hat mitunter schwerwiegende Folgen für das Unternehmen, da unter Umständen der gesamte Geschäftsbetrieb gestört oder unterbrochen ist und zu Produktionsausfällen, Regressforderungen, Imageschäden und Ähnlichem führen kann (vgl. Abbildung 3-1: Verbesserungspotentiale im ITSM (vgl. [DeDiCo 2004])).

So führt zum Beispiel der Ausfall einer Adressdatenbank bei einer Direktmarketingfirma oder eines zentralen Servers bei einem Dienstleister für Internet-Shops zu Konventionalstrafen und möglicherweise zu Schadensersatzforderungen. Je schneller der Service wieder hergestellt ist, desto geringer sind in der Regel die damit verbundenen Kosten, wobei effiziente und erprobte Notfallplanung eine wesentliche Rolle spielen. Vor diesem Hintergrund ist verständlich, warum Basel II^[13] fordert, dass Kreditinstitute das individuelle Risikoportfolio des Kreditnehmers untersuchen und hierbei auch IT-Risiken einen entscheidenden Anteil haben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-2: IuK-Einfluss auf Geschäftsprozesse (angelehnt an [KeDV1 2002, S.1])

Aber nicht nur der Wiederherstellung von IT-Services im Notfall kommt deshalb besondere Bedeutung zu, sondern auch der kostengünstigen, kundenorientierten und schnellen Erbringung von IT-Services, da auch verzögerte, unvollständige oder unzutreffende Dienstleistungen schwerwiegende Folgen auf die Geschäftsprozesse haben können. Eine Befragung von 500 IT-Leitern aus Deutschland, Großbritannien, Irland, Benelux und Spanien zeigt, ab welchem kurzen Zeitraum bereits der Ausfall der IT als geschäftsprozesskritisch eingestuft wird (vgl. Qualitätsmanagement nach DIN EN ISO 9000ff).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-3: Auswirkungen eines IT-Ausfalls (Quelle: [Synstar 2001])

3.2 Managementstandards für IT-Dienstleistungen

Im Laufe der Zeit wurde von verschiedenen Organisationen versucht, organisatorisch begründete Probleme durch Standardisierung zu mindern. Innerhalb der IT sollten Dienstleistungen prozessorientiert organisiert werden, um durch Standardisierung, Dokumentation und die Nutzung von Best-practices IT-Dienstleistungen gezielter, kostengünstiger und planmäßiger erbringen zu können. Die bekanntesten Vertreter dieses Ansatzes sind ITIL, CObIT^[14] und MOF^[15].

Diese Ansätze lassen sich zunächst danach unterscheiden, ob sie Public Domain^[16] -Ansätze sind oder nicht. Die folgende Tabelle gibt einen Überblick über diese Modelle und deren Entwickler:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3-1: Referenzmodelle serviceorientierten IT-Managements (vgl. [BrMeZ 2003])

Die bekanntesten Vertreter dieser Modelle – CobIT, MOF, IBM ITPM und HP ITSM – werden im Folgenden kurz vorgestellt, während auf drei (ITIL, BS 15000, PD0005) andere prozessorientierte Standards aufgrund ihres direkten Zusammenhangs mit ITIL erst im Kapitel 4.2 „ITIL als Norm“ eingegangen werden wird.

Zusätzlich wird die Norm DIN EN ISO 9000 als prozessorientiertes Qualitätsmanagementmodell vorgestellt, da auch nach der Einführung des ITIL - Frameworks bei BBS-S&T-SST die Zertifizierung entlang dieser Norm beibehalten werden soll.

Im Anschluss daran wird das Projektmanagementmodell PRINCE^[27] der OGC vorgestellt, an dem sich während der Einführung des ITIL-Frameworks orientiert wurde.

3.2.1 CObIT

CObIT ist ein international akzeptiertes Modell von Prozesskennzahlen für den IT-Betrieb zur Optimierung von IT-Dienstleistungen. Wesentlicher Gedanke, der hinter CObIT steht, ist, dass nur mit einer verlässlichen Organisation von Infrastruktur, Prozessen, Daten und Mitarbeitern die Anforderungen der Geschäftsprozesse erfüllt werden können.

CObIT wurde seit 1993 von der ISACA entwickelt und 1995 in seiner ersten und 1998 in einer vollständig überarbeiteten zweiten Version veröffentlicht. Zunächst wurde CObIT vorwiegend zu IT-Revision eingesetzt, da es eine nahezu vollständige Sammlung von Kennzahlen rund um den IT-Service bietet. Im Juli 2000 wurde CObIT um die Anforderungen aus dem IT Government-Bereich erweitert, indem so genannte „Management Guidelines“ hinzugefügt wurden und CObIT auf insgesamt 34 Bereiche angewachsen ist (vgl. Abbildung 3-4: Komponenten und Inhalte des CObIT-Frameworks (vgl. [ISACA 2004])).

Diese Management Guidelines definieren vor allem gängige betriebswirtschaftliche Managementindikatoren wie KPIs^[28], CSFs^[29], Zielerreichungsfaktoren und Reifegradmodelle und sollen so eine kontinuierliche Weiterentwicklung der IT-Leistungsfähigkeit bewirken.

Im Zuge der Weiterentwicklung von CObIT achtet die ISACA eigenen Aussagen zu Folge darauf, dass die Kompatibilität des Modells zu ITIL gewahrt bleibt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-4: Komponenten und Inhalte des CObIT-Frameworks (vgl. [ISACA 2004])

CObIT ist in erster Linie auf Großunternehmen ausgelegt, da es mit seinen inzwischen in 34 Bereiche aufgeteilten 314 einzelnen Kontrollzielen nicht als in KMU^[30] umsetzbar gilt. Um diesem Manko entgegenzutreten, wurde Ende 2002 das Projekt „CObIT Quickstart“ ins Leben gerufen, das speziell den Anforderungen von KMU gerecht werden soll.

Für jeden der 34 Bereiche von CObIT werden sowohl zu unterstützende Geschäftsziele als auch Kontrollziele definiert. Die Kontrollziele untergliedern sich in sieben Arten von Geschäftsanforderungen:

- klassische Sicherheitsanforderungen: Vertraulichkeit, Integrität und Verfügbarkeit,
- Effektivität (Wirksamkeit) und Effizienz (Wirtschaftlichkeit),
- Compliance (Einhaltung rechtlicher Erfordernisse) und Zuverlässigkeit (Ordnungsmäßigkeit der Berichterstattung).

Im Laufe der Zeit wurde CObIT als internes Kontrollsystem von Großunternehmen adaptiert (DaimlerChrysler, Philips International BV etc.), von Behörden eingeführt (wie dem Pentagon) sowie von anderen Institutionen (Wirtschaftsprüfer und Beratungsgesellschaften, zum Beispiel der META-Group) als Standard empfohlen.

Grund für diese Empfehlung als Kontrollsystem liegt nicht zuletzt in der großen Anzahl an Gesetzen, Normen und Richtlinien, die in CObIT eingeflossen sind:

- Gesetze und Richtlinien der EU^[31], OECD^[32], ISACA etc.,
- Qualifizierungsstandards wie ITSEC^[33], TCSEC^[34], ISO 9000, SPICE^[35], Common Criteria etc.,
- Normen für in- und externe Revision: COSO-Report^[36], IFAC^[37], ISACA, GAO^[38] etc.
- Anforderungen von Industrieforen und Behörden.

Darüber hinaus gilt die Einführung von CObIT als ein wesentlicher Schritt, die Vorgaben des Sarbanes-Oxley Act (Abkürzungen: SOA, Sarbox, SOX), einem US-amerikanischem Gesetz aus 2002, zu erfüllen. Dieses Gesetz sieht vor, dass alle Unternehmen, die bei der amerikanischen Börsenaufsicht SEC^[39] gelistet sind, regelmäßige unabhängige Audits durchzuführen haben, die die deutlich erhöhten Anforderungen an interne Kontrollsysteme überprüfen sollen. Um dieser Forderung Nachdruck zu verleihen, sieht das Gesetz zivilrechtliche Strafen (nach US-amerikanischem Recht) für das Management in Form von bis zu fünf Millionen US$ Schadensersatz und bis zu 20 Jahren Haft vor. Grund dieser verschärften Gesetzeslage sind negative Erfahrungen aus US-amerikanischen Börsenskandalen (Enron^[40], WorldCom etc.), bei denen die bisherigen Maßnahmen der Wirtschaftsprüfung offenbar nicht ausreichend waren.

Die Forderungen sehen im Bezug auf die IT eines Unternehmens vor, dass strengere Informations- und Offenlegungspflichten zur internen Informationsverarbeitung und -steuerung umgesetzt werden, indem stetige Risikoanalysen durchgeführt und Finanzkennzahlen laufend überwacht werden sowie eine interne IT-Revision vorhanden sein muss, um Planabweichungen sofort berichten zu können. Diese Forderungen werden durch das Kontrollsysteme CObIT weitgehend unterstützt.

3.2.2 MOF

MOF ist eine ITIL-basierte Vorgehensweise, die von Microsoft entwickelt wurde, um unter Verwendung von Microsoft-Produkten den Betrieb einer IT-Infrastruktur unter den Gesichtspunkten Hochverfügbarkeit, Sicherheit und Zuverlässigkeit sicherzustellen. Ziel ist es vor allem, den Betrieb von IT-Umgebungen zu beschreiben, da nach Ansicht von Microsoft dies nicht ausreichend in ITIL beschrieben sei. Da Microsoft in der Beschreibung nur einige ITIL-Bücher (Service Support, Service Delivery, Application Management, Planning to Implement Service Management) erwähnt, nicht aber das Buch „ICT Infrastructure Management“ – dass sich gerade mit diesen operativen Aspekten der IT-Organisation beschäftigt – erscheint diese Bewertung etwas unverständlich.

Grundsätzlich lässt Microsoft folgende Komponenten in sein Modell einfließen:

- Best-practices nach ITIL,
- Microsoftinterne Konzepte und Best-practices,
- Unterstützung von Personen und Prozessen bei der Anwendung von Microsoftprodukten,
- Dienstleistungs- statt Technologiekomponenten-Gedanke,
- Integration des gesamten IT-Lebenszyklus.^[41]

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-5: MOF-Modell (vgl. [MSMOF 2004, S. 22])

Im Wesentlichen besteht das Modell aus vier Bereichen, die nacheinander ablaufen (vgl. Abbildung 3-5: MOF-Modell (vgl. [MSMOF 2004, S. 22])). Die Tätigkeiten innerhalb dieser Bereiche teilen sich wie folgt auf:

- Wechsel: dieser Punkt befasst sich mit den Punkten der Bereitschaft des Produkts und des Personals auf den Wechsel eines IT-Systems sowie mit möglichen Auswirkungen auf andere Systeme. Wenn die Überprüfung dieser Aspekte positiv ausfällt, so wird der entsprechende Hardware- oder Software- Releasewechsel durchgeführt.
- Betrieb: ist die neu eingeführte Version betriebsbereit übergeben worden, so übernimmt der Betrieb die Wartung des Systems.
- Support: dieser Bereich identifiziert und bearbeitet Störungen und beantwortet Benutzeranfragen. Darüber hinaus werden die SLAs^[42] auf ihre Einhaltung hin überprüft.
- Optimierung: dieser Quadrant ist langfristig orientiert, indem er aktuelle Leistungsdaten der anderen drei Quadranten überprüft und diese für die nächsten sechs Monate prognostiziert. Aus diesen Daten heraus werden Verbesserungen abgeleitet und vorgeschlagen.

3.2.3 IBM IT Process Model

Das ITPM ist eine Weiterentwicklung des 1979 veröffentlichten ISMA^[43], die seit 1997 von IBM angewendet wird, um die Effizienz des IT-Managements zu steigern, indem traditionelle, hierarchische Strukturen aufgegeben werden. Hierzu wurden acht Komponenten mit 41 Prozessen und 176 Subprozessen definiert:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-6: IBM IT Process Model (vgl. [IBMITSM 2001, S. 13])

Das ITPM ist im Vergleich zu anderen Prozessmodellen ein sehr detailliertes Modell, da es für jeden Prozess In- und Outputs, Rollen, Verantwortlichkeiten, Ziele und notwendige Tools vorgibt. Jedoch werden weder CSFs noch Kennzahlen für die Prozesse beschrieben.

Das ITPM wurde von IBM entwickelt, wird kontinuierlich weiterentwickelt und ist zu ITIL kompatibel. Diese Kompatibilität rührt vor allem daher, dass IBM auch an der Weiterentwicklung von ITIL beteiligt ist.

Im Folgenden werden kurz die acht Eckpfeiler des ITPM erläutert:

1. Satisfy customer relationship: stellt die Kommunikation mit den Kunden sicher, um dessen Bedürfnisse und Anforderungen zu erfahren und zu erfüllen,
2. Provide enterprise IT management systems: plant und erstellt IT-Systeme, die zu Management der IT-Organisation dienen,
3. Manage IT business value: stellt sicher, dass das Unternehmen für seine Investition einen ausreichenden ROI^[44] erhält,
4. Realise solutions: erstellt, erweitert und wartet IT-Systemlösungen, die mit dem Kunden auf dessen Bedürfnisse abgestimmt worden sind,
5. Deploy solutions: führt Änderungen an der IT-Infrastruktur ein und stellt sicher, dass diese mit möglichst geringen Folgen für operative Systeme erfolgt,
6. Deliver operational services: stellt vereinbarte Services zur Verfügung und spiegelt alle bislang aufgetretenen Aktivitäten wider,
7. Support IT services and solutions: stellt Support zur Sicherung der Kontinuität des Operations sicher,
8. Manage IT assets and infrastructure: erstellt und kontrolliert die Infrastruktur zur Steuerung von IT Assets (Hardware, Software und Mitarbeiter).

3.2.4 HP IT Service Reference Model

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-7: HP IT Service Reference Model (Quelle: [HPITSM 2003, S. 15])

HP entwickelte 1996 dieses Referenzmodell zur Darstellung von IT-Prozessbeziehungen, um Kunden einen Leitfaden zur Identifikation und Organisation der Anforderungen an das IT Service Management zu geben. Das Modell, dass als wesentliche Punkte Kunden- und Serviceorientierung zum Ziel hat, gliedert sich in fünf Bereiche auf (vgl. Abbildung 3-7: HP IT Service Reference Model):

- Business IT Alignment entwickelt IT-Strategien und vereinbart Service Portfolios, mit dem Ziel, den Nutzen der IT für das Unternehmen zu steigern. Zu diesem Prozess gehören die Subprozesse Business Alignment, Customer Management und IT Strategy Development.
- Service Design & Management wägt Servicequalität gegen dessen Kosten ab, indem es detaillierte Anforderungsanalysen erstellt. Zu diesem Prozess gehören die Subprozesse „Service Planning“ sowie Service Level-, Security-, Availability-, Capacity- und Cost Management.
- Service Operations führt tägliche operative Tätigkeiten wie Instandhaltung von Systemen und serviceorientiertes Bearbeiten von Kundenanfragen durch. Hierzu bedient es sich der Subprozesse Incident-, Problem- und Operations Management.
- Service Development and Deployment^[45] entwickelt neue Hard- und Software-Releasewechsel und führt das Projektmanagement während der Einführung dieser Releases durch, nachdem diese getestet und auf Kosten und Nutzen hin verifiziert worden sind. Unterstützende Prozesse sind dazu „Build & Test“ sowie „Release to Production“.
- Service Delivery Assurance erarbeitet und verhandelt Serviceverträge, stellt anderen Prozessen Informationen zu diesen Verträgen zur Verfügung und stellt deren Einhaltung sicher. Dazu bedient es sich der Prozesse Change- und Configuration Management.

Ebenso wie das IBM ITPM ist das HP ITSM sehr detailliert beschrieben, allerdings fehlen auch hier Kennzahlen und Management-Guidelines. Darüber hinaus ist dieses Modell – wie die Namen vieler Subprozesse bestätigen – sehr stark an ITIL orientiert. Ursprünglich versuchte HP sein Modell durch folgendes Statement von ITIL abzugrenzen:

„…the team also designed the model to reflect the need to run IT ‘as a business’ rather than merely running IT ‘within a business’“ (vgl. [HPITSM 2003]).

Zum Zeitpunkt der Entwicklung dieses Modells war die Aussage zwar noch gerechtfertigt, da ITIL für die IT-Servicemanagementprozesse der britischen Regierung entwickelt wurde, allerdings ist ITIL inzwischen in diesem Bereich umfassend weiterentwickelt worden, so dass es auch diesen Bereich abdeckt.

Die Weiterentwicklung des HP ITSM stellen HP-eigene Mitarbeiter sicher.

3.2.5 Gegenüberstellung der Modelle

Im Folgenden werden die vier Alternativmodelle zu ITIL miteinander verglichen. Dabei wird deutlich, dass insbesondere die von IT-Firmen entwickelten Modelle im Bereich der formalen Kriterien besonders gut beschrieben werden. Dagegen fehlen diese oft pragmatischen Faktoren wie die Messbarkeit der Erfolge.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3-2: Vergleich von ITSM-Modellen (vgl. [BrMeZ 2003, S. 48])

Im Hinblick auf den Detaillierungsgrad fällt auf, dass dieser bei allen Modellen als hoch eingeschätzt wird, während in Bezug auf Schnittstellen bei manchen Modellen Lücken auftauchen. Instrumente sind vorwiegend bei den herstellerabhängigen Modellen zu finden, was vorwiegend darin begründet ist, dass diese an diesem Punkt eigene Produkte platzieren können. ITIL bleibt in dieser Hinsicht bei einem allgemeinen Anforderungsprofil, dass zum Beispiel den Funktionsumfang und die Aufgaben der Datenbanken zur Unterstützung bestimmter Prozesse festschreibt.

In Bezug auf Effektivität, also der Wirksamkeit eingeführter Prozesse, sowie Effizienz, der Wirtschaftlichkeit dieser Prozesse, lässt sich feststellen, dass vor allem bei den proprietären Modellen diese Merkmale durchgängig fehlen. CObIT bietet als Prozessmodell, das vor allem Revision und Controlling avisiert, an dieser Stelle die meisten Vorgaben.

In Bezug auf Verständlichkeit und Klarheit wird deutlich, dass ITIL im Gegensatz zu anderen Modellen im Nachteil ist. Grund dafür sind mitunter schwer verständliche Texte als auch mitunter vagen Beschreibungen. Jedoch sind es auch gerade diese vagen Aussagen, die ITIL flexibel machen, da es nicht zuletzt darum geht, eigene Ideen und Vorgehensweisen einzubinden und diese nicht wahllos zu übernehmen.

Die rasante Entwicklung von ITIL in den letzten Jahren – vor allem in Europa – hat dazu geführt, dass ITIL inzwischen sehr weit verbreitet ist. CObIT ist zurzeit vorwiegend in den USA bekannt, während es in Europa erst in den letzten Monaten durch SOA und andere Richtlinien bekannt geworden ist.

Da alle Modelle außer CObIT auf ITIL aufsetzen, ist die Anwendbarkeit dieser Modelle auf kleine und mittelständische Unternehmen zumindest grundsätzlich gegeben. Jedoch haben vor allem die proprietären Modelle sehr viele Prozesse und Subprozesse, die eine Umsetzung zumindest erschweren. ITIL bietet im Bezug hierauf weniger Subprozesse und somit letztlich eine skalierbarere Einführungsbasis.

3.3 Qualitätsmanagement nach DIN EN ISO 9000ff

Die Norm DIN EN ISO 9000 ff, umgangssprachlich ISO 9000 genannt, ist ein umfangreiches Werk bestehend aus Leitfäden, Normen, Begriffen und QM^[48] -Modellen. Die bekannteste Norm dieser Reihe ist die DIN EN ISO 9001, eine Darlegungsnorm für ein Qualitätsmanagementsystem, nachdem sich Unternehmen durch Dritte zertifizieren lassen können. Da diese Norm im Dezember 2000 novelliert worden ist, trägt die derzeit gültige Version der Norm den Namen DIN EN ISO 9001:2000.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-8: Prozessmodell der DIN EN ISO 9000:2000

Diese neue Revision der ISO 9000 besteht im Wesentlichen aus drei Teilen:

- ISO 9000: Konzepte und Vokabular,
- ISO 9001: Anforderungen an Qualitätsmanagementsysteme,
- ISO 9004: Richtlinien für Qualitätsmanagementsysteme.

Die beiden Normabschnitte ISO 9002 und ISO 9003 sind mit der Umstellung der Norm von der Revision DIN EN ISO 9000:1994 auf die Revision DIN EN ISO 9000:2000 entfallen. Grund für diese Umstellung war, dass man Nachteile der Norm gegenüber anderen QM-Modellen ausgleichen und an Anforderungen kleinerer Unternehmen sowie von Dienstleistern (die 1994er Norm war auf die Fertigungsindustrie fokussiert) anpassen wollte.

Vor diesem Hintergrund wurde vor allem die Kundenorientierung in der 2000er Revision herausgestellt, während das grundlegende Ziel der Norm das Gleiche blieb:

„Schaffen von Vertrauen als Ergebnis einer Demonstration der Übereinstimmung von Produkten und/oder Service mit den aufgestellten Anforderungen". (Vgl. [ Deming 2004 ])

Um dieses Ziel zu erreichen, werden von der Norm folgende acht Grundsätze vorgegeben, die vom Management eines Unternehmens verwendet werden sollten.

3.3.1 Kundenorientierung

Organisationen sind von ihren Kunden abhängig und sollten deshalb aus ihrem eigenen Interesse gegenwärtige und zukünftige Erfordernisse der Kunden verstehen, deren Anforderungen erfüllen und versuchen, deren Erwartungen zu übertreffen.

3.3.2 Führung

Führungskräfte sollten versuchen, eine Übereinstimmung von der organisatorischen Ausrichtung mit dem Unternehmensziel zu erreichen. Dazu sollten Sie das interne Umfeld schaffen und erhalten, in dem sich Mitarbeiter voll und ganz für die Erreichung der Ziele der Organisation einsetzen können.

3.3.3 Einbeziehung der Mitarbeiter

Jede Organisation ist im Wesentlichen durch ihre Mitarbeiter geprägt. Aus diesem Grund sollte versucht werden, diese möglichst weitgehend in die Organisation einzubinden und diese durch die Organisation zu unterstützen, um deren Fähigkeiten zur Unterstützung des Unternehmenserfolgs nutzen zu können.

3.3.4 Prozessorientierter Ansatz

Unternehmensziele lassen sich besonders effizient erreichen, wenn das Unternehmen prozessorientiert ausgerichtet ist. Dies wird insbesondere dadurch erreicht, dass Ressourcen, Mitarbeiter und Tätigkeiten nach Prozessen ausgerichtet eingesetzt werden.

3.3.5 Systemorientierter Managementansatz

Erkennen, Verstehen, Leiten und Lenken von miteinander in Wechselbeziehung stehenden Prozessen als System tragen zur Wirksamkeit und Effizienz der Organisation beim Erreichen ihrer Ziele bei.

3.3.6 Ständige Verbesserung

Die ständige Verbesserung (Synonyme sind: kontinuierlicher Verbesserungsprozess, continuous improvement oder Kaizen) der Gesamtleistung ist ein permanentes Unternehmensziel. Dies wird umgesetzt, indem alle Mitarbeiter und Abteilungen die jeweiligen Produkte, Dienstleistungen und Arbeitsschritte weiter verbessern mit den Zielen:

- die entstehenden Kosten in der Produktion, Verwaltung und anderen Bereichen weiter zu reduzieren,
- die Qualität weiter zu steigern.

3.3.7 Sachbezogener Ansatz zur Entscheidungsfindung

Damit das Management eines Unternehmens Entscheidungen vor ausreichendem fachlichen, faktischen und realistischem Hintergrund treffen kann, müssen Daten, Zahlen und Fakten, die der Entscheidungsfindung dienlich sein können, effizient, korrekt und zutreffend analysiert und aufbereitet werden.

3.3.8 Lieferantenbeziehungen zum gegenseitigen Nutzen

Da Beziehungen zwischen Unternehmen in der Regel von beiderseitigem Nutzen sind, sollten diese sich zur Erhöhung der beiderseitigen Wertschöpfung aufeinander abstimmen.

3.4 Projektmanagement nach PRINCE

PRINCE wurde in den 1980er Jahren von der CCTA als Antwort der britischen Regierung auf das Scheitern verschiedener IT-Projekte entwickelt, um dies durch den Einsatz einer strukturierten und effizienten Projektmanagementmethode zukünftig zu verhindern und Projekte schneller, wirksamer und kostengünstiger abschließen zu können.

Seitdem wird diese Methode intensiv von britischen Regierungsorganisationen genutzt und gilt mit Erscheinen der zweiten Version 1996 auch im nicht-staatlichen Sektor als international anerkannter und weit verbreiteter de-facto-Projektmanagementstandard.

Ähnlich wie ITIL ist auch PRINCE eine nicht proprietäre Sammlung von Best-practices, die als Anleitung für das Projektmanagement zwar ein registriertes Handelskennzeichen der CCTA ist, aber aufgrund seiner Freigabe als Public Domain frei verwendet werden darf.

3.4.1 PRINCE 1

Die erste Version von PRINCE wurde ursprünglich speziell für Anforderungen an das Projektmanagement von IT-Projekten entwickelt. Da diese Methode aber auch für verschiedene andere Projekte benutzt wurde, entschloss man sich, mit PRINCE 2 ein generischeres Modell zu entwickeln, um die Methode auch außerhalb von IT-Projekten besser einsetzen zu können. Aus diesem Grund wurden die Anforderungen bestehender PRINCE 1-Nutzer und notwendige Erweiterungen der Methode zu PRINCE 2 zusammengefasst, wobei gleichzeitig versucht wurde, den Fokus weg vom IT-Projektmanagement hin zu Best-practices für das Projektmanagement zu lenken.

3.4.2 PRINCE 2

Das PRINCE 2-Prozessmodell unterteilt das Projektmanagement in acht Hauptprozesse, denen bestimmte Aufgaben zugeordnet werden, um eine grundsätzliches Framework zur Vorgehensweise in Projekten zu geben. Dies umfasst die organisatorische Struktur, den Beginn, die einzelnen Phasen sowie deren Übergänge.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3-9: Schritte des PRINCE 2-Projektmanagements (vgl. [KeySki 2004])

Vertikal (hier: von unten nach oben) beschreibt Abbildung 3-9: Schritte des PRINCE 2-Projektmanagements (vgl. [KeySki 2004]) die Befugnisse und die Berichterstattung innerhalb von Projekten, horizontal (hier: von links nach rechts) die Abfolge der einzelnen Projektschritte.

Im Folgenden werden kurz die einzelnen Schritte innerhalb des Projektmanagements beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3-3: Projektphasen nach PRINCE 2

3.5 Auswahl eines Modells für die BBS-S&T-SST

Die Zertifizierung entlang der ISO 9000-Norm besteht für Teile der Business Unit bereits seit ungefähr 1990 und soll auch in Zukunft aus verschiedenen Gründen (Marktanforderung, Organisationsoptimierung etc.) beibehalten werden.

Da die ISO 9000 allerdings in Bezug auf Prozesse nur vorschreibt, dass diese bestimmte Kriterien erfüllen und dokumentiert sein müssen, nicht aber, welche Inhalte diese haben, steht einer gleichzeitigen Nutzung eines IT Service Management Modells zur weiteren Prozessverbesserung nichts im Wege.

Aus diesem Grund entschloss man sich, ein derartiges Modell zu nutzen. Da die meisten vorgestellten IT Service Management-Modelle auf ITIL basieren und ITIL das weitest verbreitete Modell ist, entschloss man sich, dieses zu nutzen. Darüber hinaus waren auch Aspekte wie Proprietät, Flexibilität und der best-practice-Ansatz Gründe, sich für dieses Modell zu entschließen.

4 ITIL

4.1 Geschichte

Mitte der 1980er Jahre zweifelte die britische Regierung die Effizienz der IT innerhalb der staatlichen Behörden stark an, weshalb die Behörden angewiesen wurden, Infrastruktur und Prozesse zu dokumentieren und anschließend zu vereinfachen. Da als Mittel zur Effizienzsteigerung der IT-Prozesse auch Outsourcing in Frage kam, prüfte man zunächst, ob diese Möglichkeit umsetzbar wäre. Nachdem aufgrund verschiedener Probleme – hauptsächlich wegen des Fehlens einer zentralisierten und einheitlichen Struktur sowie ungleicher Prozessabläufe – zu dem Ergebnis kam, dass ein Outsourcing-Projekt nicht im vertretbaren finanziellen Rahmen umzusetzen sei, wurde ein Projekt zu Prozessverbesserung ins Leben gerufen.

Die Abteilung GITIMF^[51] der CCTA wurde damit beauftragt, die Aufgabe des Dokumentierens und Vereinfachens zu übernehmen und ebenfalls eine „best of breed“-Strategie zur Erbringung von IT Services entlang der Geschäftsprozesse zu erarbeiten.

Die erste Dokumentation, die im Rahmen dieses Projekts entstanden ist, war 1989 das Buch über Service Level Management (SLM). Nach einiger Zeit wurden auf die Dokumentationen über andere Bereiche – insgesamt 30 – fertig gestellt, die nach einiger Zeit weiter verbreitet wurden und als Grundlage von ITIL angesehen werden können.

Im Jahr 2000 wurden diese 30 Werke auf die heute bekannten sieben Werke (Service Delivery, Service Support, Application Management, ICT Infrastructure Management, The Business Perspective, Security Management, Planning To Implement Service Management) zusammengefasst.

Die ITIL herausgebende CCTA wurde am 2. April 2001 in das OGC organisatorisch eingegliedert, was dazu führte, das nunmehr das OGC ITIL weiterentwickelt.

Ab der Mitte der 1990er Jahre wurde ITIL immer populärer und setzte sich schließlich als de-facto-Standard für IT Service Management durch, nicht zuletzt, weil ITIL die einzige umfassende, herstellerunabhängige und frei verfügbare Sammlung von Best-practices in diesem Bereich darstellt und aus diesem Grund weitreichende Akzeptanz genießt. Sicherlich trägt auch die unternehmensübergreifend einheitliche Terminologie in einer weit verbreiteten Sprache ihren Teil hierzu bei.

Seither wurde ITIL kontinuierlich weiterentwickelt und Aspekte des zunehmenden Einzugs von PCs^[52] in Unternehmen und der Einführung von Client/Server-Architekturen integriert.

4.2 ITIL als Norm: BS 15000 und PD 0005

In 2002 und 2003 folgte die schrittweise Einführung als britische Norm (BS 15000), die eine Zertifizierung von Unternehmen entlang der ITIL-Richtlinien vorsieht. Zunächst wurden mit BS 15000-1:2002 („Specification For Service Management”) grundlegende Anforderungen definiert, der mit BS 15000-2:2003 („Code Of Practise For IT Service Management“) eine Anleitung zur Umsetzung angefügt wurde. Weitere Elemente der Norm sind PD 0005:2003 („A Manager’s Guide To Service Management”) und PD 0015:2002 („IT Service Management – Self Assessment Workbook”).

Die neueste Ausgabe der Norm (2002/03) wurde durch den Plan-Do-Check-Act-Prozesszyklus der Qualitätsmanagementnorm ISO 9000:2000 ergänzt (vgl. Abbildung 4-1: PDCA-Zyklus im Service Management (vgl. [CoSph 2003]), deren Erfüllung häufig von IT-Dienstleitern erwartet wird. Durch diese Anpassung der BS 15000 wurde versucht, diese Norm stärker an die ISO 9000:2000 heranzuführen, so dass eine Zertifizierung nach BS 15000 zumindest einen weiteren Schritt zur Erfüllung der Anforderungen von ISO 9000:2000 darstellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4-1: PDCA^[53] -Zyklus im Service Management (vgl. [CoSph 2003])

Schätzungen der Gartner Group (vgl. [GaGr1 2002, S. 4f]) zufolge wird die BS 15000-Norm auf lange Sicht ein ISO-Standard werden, entweder als Teil der ISO 9000er Reihe oder aber als eigenständige Norm. Jedoch liege die Wahrscheinlichkeit, dass es bis 2006 zu einem internationalen ISO-Standard kommen werde, lediglich bei 20%.

Dagegen berichtet ZDNet India am 09.07.2004 (vgl. [TSO 2004]), dass aufgrund des Drängens des IT Service Management Forums (ITSMF), BS 15000 international als Norm einzuführen, mit der Veröffentlichung einer BS 15000-basierten Norm bereits 2005 zu rechnen sei, die im Wesentlichen folgende Punkte behandeln werde:

- Anforderungen an ein Managementsystem,
- Planung und Implementierung von Service Management,
- Planung und Implementierung neuer oder veränderter Services,
- die Service Delivery-Prozesse,
- die Beziehungen zwischen Prozessen,
- Lösungsprozesse,
- Prüf- und Releaseprozesse.

Die Gartner Group bewertete die Einführung der Norm BS 15000 im März 2002 als „a major step toward IT service delivery becoming mature and stable with a level of cross enterprise consistency” (vgl. [GaGr1 2002, S. 4f]), die großen Nutzen für Industrie, Firmen und externe Dienstleister haben kann.

Voraussetzung dafür sei, dass:

- Unternehmen ITIL-basiertes Service Management als Methode erkennen,
- alle Verbesserungen im Unternehmen sowohl auf ITIL als auch auf BS 15000 basieren sollen, um sich die Fähigkeit für eine zukünftige Zertifizierung offen zu halten.

Gartner schätzt, dass in 2008 die Zahl größerer Unternehmen, die eine Zertifizierung nach BS 15000 (oder einer darauf aufbauenden Norm) anstreben, wie folgt verteilt sein wird:

- weniger als 10%: Wahrscheinlichkeit von 0,2 (jeweils von 1,0),
- 10 bis unter 20%: Wahrscheinlichkeit von 0,3,
- 20 bis unter 33%: Wahrscheinlichkeit von 0,4,
- mehr als 33%: Wahrscheinlichkeit von 0,1.

4.3 Vorteile und Nutzen von ITIL

Die Bedeutung von ITIL hat seit 1997 kontinuierlich zugenommen, nachdem unter anderem Procter & Gamble ITIL erfolgreich eingeführt hatten. Inzwischen hat die Zahl der Unternehmen, die ITIL eingeführt haben oder gerade einführen, drastisch zugenommen, wozu auch die Gründung der ersten ITSMF ab November 2000 ihren Beitrag leisteten. Aus diesem Grund beschäftigen sich nach und nach auch immer mehr kommerzielle Dienstleister wie Gartner Group, META Group oder das Helpdesk Institute mit ITIL und den Verkauf von Dienstleistungen rund um diese Methode. Microsoft, IBM, Hewlett-Packard und andere versuchen seitdem verstärkt, ihre auf ITIL aufsetzenden Produkte am Markt zu platzieren.

[...]

---

^[1] Business Unit = Geschäftsbereich

^[2] Definition „Prozess” siehe Glossar

^[3] BBS-S&T-SST = Abk. für „Bayer Business Services – Science & Technology – Systems Management for Science & Technology”

^[4] Definition „Kunde“ siehe Glossar

^[5] Stand: 22.07.2004

^[6] Stand: 31.05.2004

^[7] Definition „Anwender“ siehe Glossar

^[8] Stand: 31.03.2004

^[9] ICT = Abk. für „Information and Communication Technology“

^[10] Stand: 25.09.2003

^[11] DIN EN ISO = Abk. für „Deutsche Industrienorm Europäische Norm International Organization for Standardization“

^[12] ITSM = Abk. für „IT Service Management”

^[13] Definition „Basel II” siehe Glossar

^[14] CObIT = Abk. für „Control Objectives for Information and Related Technology”

^[15] MOF = Abk. für „Microsoft Operations Framework“

^[16] Definition „Public Domain” siehe Glossar

^[17] ISACA = Abk. für „Information Systems Audit and Control Association”

^[18] MNM = Abk. für „Munich Network Management“

^[19] CMM = Abk. für „Capability Maturity Model”

^[20] IS= Abk. für „Information System“

^[21] ASL = Abk. für „Application Service Library“

^[22] BIOOlogic = Aus „Biologic“ und OO für „Object-oriented“ zusammengesetzter Neologismus

^[23] BS = Abk. für „British Standard“

^[24] ITIL ist entgegen weitläufiger Meinung kein Public Domain: es muss käuflich erworben werden, ist Copyright-geschützt und darf nicht ohne Erlaubnis des OGC nachgeahmt oder weitergegeben werden

^[25] OGC = Abk. für „Office Of Government Commerce“, britische Regierungsorganisation

^[26] DISC PD = Abkürzung für „Delivering Information Solutions to Customers - Published Document”

^[27] PRINCE = Abk. für „Projects In Controlled Environment“

^[28] KPI = Abk. für „Key Performance Indicator“ , Definition siehe Glossar

^[29] CSF = Abk. Für „Critical Success Factor“, Definition siehe Glossar

^[30] KMU = Abk. für „Klein- und mittelständische Unternehmen“

^[31] EU = Abk. für „Europäische Union“

^[32] OECD = Abk. für „Organisation for Economic Co-operation and Development“

^[33] ITSEC = Abk. für „Information Technology Security Evaluation Criteria“

^[34] TCSEC = Abk. für „Trusted Computer System Evaluation Criteria“

^[35] SPICE = Abk. für „Software Process Improvement and Capability Determination (Software Process Improvement and Capability Evaluation)“

^[36] COSO = Abk. für „Committee of Sponsoring Organisations of the Treadway Commission Internal Control-Integrated Framework“

^[37] IFAC = Abk. für „International Federation of Accountants“

^[38] GAO = Abk. für „(United States) General Accounting Office“

^[39] SEC = Abk. für „Securities and Exchange Commission“

^[40] Beispiel Enron: die Firma war die dritterfolgreichste Firma der USA, bis am 12.10.2001 eine interne E-Mail der Wirtschaftsprüfer bekannt wurde, in der empfohlen wurde, alle relevanten Geschäftsaufzeichnungen zu zerstören, um massive Schadensersatzansprüche wegen falscher Bilanzen zu vermeiden. Daraufhin brach der Aktienkurs um über 90% ein.

^[41] Definition „Lebenszyklus“ siehe Glossar

^[42] SLA = Abk. für „Service Level Agreement“, Definition siehe Glossar

^[43] ISMA = Abk. für „Information Systems Management Architecture“

^[44] ROI = Abk. für „Return On Investment“

^[45]: Definition „Deployment“ siehe Glossar

^[46] Als Mindestgröße einer nach dem ITIL-Framework auszurichtenden IT-Abteilung wird im Allgemeinen von 80 Mitarbeitern ausgegangen

^[47] „CObIT Quickstart“ adressiert kleine und mittelständische Unternehmen

^[48] QM = Abk. für „Qualitätsmanagement“

^[49] Definition „Business Case“ siehe Glossar

^[50] SWOT = Abk. für „Strength, Weakness, Opportunity, Threat”

^[51] GITIMF = Abk. für „Government Information Technology Infrastructure Management Forum“

^[52] PC = Abk. für „Personal Computer“

^[53] PDCA = Abk. für „Plan-Do-Check-Act“