Betriebsinformatik-Projekt — ITIL und die IT-Wirklichkeit

Transcription

Betriebsinformatik-Projekt
—
ITIL und die IT-Wirklichkeit
Prof. Dr. Thorsten Spitta – Dipl.-Inform. Meik Teßmer
Universität Bielefeld
Fakultät für Wirtschaftswissenschaften
Angewandte Informatik
Wintersemester 2007/2008
Vorwort
ITIL (IT Infrastructure Library) ist ein de facto-Standard für das IT Service
Management. Er wurde gegen Ende der 1980er Jahre in England entwickelt
und hat sich seitdem ständig weiterentwickelt. ITIL definiert verschiedene Rollen und Funktionen, die helfen sollen, die IT-Infrastruktur effizient einzusetzen,
Dienstleistungen anzubieten und zu verbessern sowie eine hohe Service-Qualität
zu gewährleisten.
Im Rahmen dieses BI-Projekts sollen die verschiedenen ITIL Service ManagementFunktionen betrachtet werden sowie eine mögliche Anwendung des Standards
in der lokalen IT. Auch Gründe, die gegen einen Einsatz von ITIL sprechen,
sollen untersucht werden.
Die Teilnehmer waren: Carolin Ahlert, Michael Bochenek, Björn Borgmeier,
Sonja Bozionek, Linda Gerstenberger, Tim Kattner, Andre Kröger, Julius Kuhljürgen, Kathrin Stegmann, Julia-Vanessa Stork, Christian Teicher, Christopher
Uhrig.
Bielefeld, im März 2008
Prof. Dr. Thorsten Spitta
Dipl.-Inform. Meik Teßmer
3
4
Inhaltsverzeichnis
1 ITIL-Wirklichkeit an der Universität Bielefeld
1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Service Support . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Service Desk . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Incident Management . . . . . . . . . . . . . . . . . . .
1.2.3 Problem Management . . . . . . . . . . . . . . . . . . .
1.2.4 Change Management . . . . . . . . . . . . . . . . . . . .
1.2.5 Release Management . . . . . . . . . . . . . . . . . . . .
1.2.6 Configuration Management . . . . . . . . . . . . . . . .
1.3 Untersuchung des IT-Managements in der Universität Bielefeld
1.3.1 Fakultät für Wirtschaftswissenschaften . . . . . . . . . .
1.3.2 Fakultät für Rechtswissenschaft . . . . . . . . . . . . . .
1.3.3 Kritik und Empfehlung . . . . . . . . . . . . . . . . . .
1.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Fragebogen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
10
12
16
22
27
30
32
37
37
40
42
46
48
2 ITIL-Zertifizierung nach ISO/IEC 20000
2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Der Standard ISO/IEC 20000 . . . . . . . . . . . . . . . . . . .
2.2.1 Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Beziehung zu ITIL . . . . . . . . . . . . . . . . . . . . .
2.2.3 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4 Anforderungen an ein Management-System . . . . . . .
2.2.5 Planung und Implementierung des Service Managements
2.2.6 Anforderungen an Service-Management-Prozesse . . . .
2.3 Die Zertifizierung . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Entscheidungsfindung . . . . . . . . . . . . . . . . . . .
2.3.2 Prozessumsetzung . . . . . . . . . . . . . . . . . . . . .
2.3.3 Fragenkatalog zur Prozessumsetzung . . . . . . . . . . .
2.3.4 Zertifizierungsprozess . . . . . . . . . . . . . . . . . . .
2.4 Beurteilung der Zertifizierung . . . . . . . . . . . . . . . . . . .
2.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
53
54
54
54
55
56
57
58
63
63
64
67
73
74
76
3 ITIL und IT-Sicherheit
3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Grundlagen des IT-Security Management . . . . . . . . . .
3.2.1 Informationssicherheit . . . . . . . . . . . . . . . . .
3.2.2 Gesetzesanforderungen, Vorschriften und Standards
.
.
.
.
81
81
82
82
84
5
.
.
.
.
.
.
.
.
6
INHALTSVERZEICHNIS
3.2.3
3.2.4
3.3
3.4
Ziele und Aufgaben des IT-Security Management . . . . . 85
Einordnung von Informationssicherheit und Security Management in ITIL . . . . . . . . . . . . . . . . . . . . . . . 88
Security Management mit ITIL auf operativer Ebene . . . . . . . 90
3.3.1 Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.3.2 Incident Management . . . . . . . . . . . . . . . . . . . . 91
3.3.3 Problem Management . . . . . . . . . . . . . . . . . . . . 94
3.3.4 Change Management . . . . . . . . . . . . . . . . . . . . . 96
3.3.5 Release Management . . . . . . . . . . . . . . . . . . . . . 99
3.3.6 Configuration Management . . . . . . . . . . . . . . . . . 101
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4 ITIL-unterstützende Werkzeuge
4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Begriffsabgrenzungen . . . . . . . . . . . . . . . . . . .
4.2.1 ITIL . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Werkzeuge . . . . . . . . . . . . . . . . . . . .
4.3 Service Support und Anforderungen an die Werkzeuge
4.3.1 Vorgehensweise . . . . . . . . . . . . . . . . . .
4.3.2 Incident Management mit Service Desk . . . .
4.3.3 Problem Management . . . . . . . . . . . . . .
4.3.4 Change Management . . . . . . . . . . . . . . .
4.3.5 Release Management . . . . . . . . . . . . . . .
4.3.6 Configuration Management . . . . . . . . . . .
4.4 Betrachtung ausgewählter ITIL-Werkzeuge . . . . . .
4.4.1 Vorgehensweise . . . . . . . . . . . . . . . . . .
4.4.2 Das Open Source-Werkzeug OTRS . . . . . . .
4.4.3 Das kommerzielle Werkzeug Remedy . . . . . .
4.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
109
109
110
110
111
112
112
112
116
120
123
125
127
127
127
132
136
Gruppen
Thema
Gruppe 1: Service SupportUmsetzung an zwei ausgewählten Fakultäten
Gruppe 2: ITIL-Zertifizierung
nach ISO 20000
Gruppe 3: Security-Management
mit ITIL
Gruppe 4: Werkzeuge für ITIL
Teilnehmer
Carolin Ahlert, Julius Kuhljürgen, Christian Teicher
Julia-Vanessa Stork, André Kröger, Christopher Uhrig
Björn Borgmeier, Michael Bochenek, Tim Kattner
Linda Gerstenberger, Sonja Bozionek, Kathrin Stegmann
7
8
INHALTSVERZEICHNIS
Kapitel 1
ITIL-Wirklichkeit an der
Service Support-Umsetzung an zwei ausgewählten Fakultäten
Carolin Ahlert, Julius Kuhljürgen, Christian Teicher
1.1
Einleitung
Nahezu jedes Unternehmen, sei es in der Dienstleistungsbranche oder in der
Produktion tätig, sei es ein Krankenhaus oder eine Universität, ist mit dem
täglichen Gebrauch der IT konfrontiert. Es ist nicht weiter verwunderlich, dass
Sätze wie „Mein Computer stürzt dauernd ab.“, „Ich habe keinen Zugriff auf
die Datenbank.“ oder „Mein alter Computer kann mit seiner noch älteren Software dieses Problem nicht lösen.“ in diesen Unternehmen zum Alltag gehören.
Doch wie können diese Probleme bewältigt werden? Wie kann ein möglichst
reibungsloser Betriebsablauf gewährleistet werden? Dafür liefert ITIL eine mögliche Lösung. Mit Hilfe von Funktionen und Prozessen, die sich in der Praxis
bereits bewährt haben, soll nun die Vielzahl der verschiedenen Probleme angegangen werden. Allerdings stellt sich die Frage: Wo fängt die Problemlösung
an und wo hört sie auf? Oder allgemeiner: Wie kann der Kunde resp. der User
am besten unterstützt werden? Laut der ITIL-Philosophie ist dafür der Service
Support zuständig. Wie dieser Service Support den User auf operativer Ebene
unterstützen kann, soll in dieser Arbeit detailliert dargestellt werden. Auf Grund
der Behauptung, dass die Anwendung von ITIL für jedes Unternehmen von Vorteil sei, kann daraus gefolgert werden, dass dieser de facto-Standard auch für
eine Universität vorteilhaft sein muss. Um dieser These nachzugehen, wird in
der vorliegenden Arbeit die Universität Bielefeld resp. zwei ihrer größten Fakultäten als Untersuchungsgegenstand im Bezug auf ITIL gewählt. Es drängt sich
allerdings die Frage auf, ob der von ITIL vorgeschlagene Service Support wirklich so sinnvoll und als „Allheilmittel“ für sämtliche User-Probleme zu verstehen
9
10
ITIL-Wirklichkeit an der Universität Bielefeld
ist. Kann mit ITIL bzw. mit einem ITIL-konformen Service Support den Professoren, den Sekretärinnen und allen, die mit der Organisation der Universität
beschäftigt sind, wirklich geholfen werden? Werden die IT-Probleme der studentischen Hilfskräfte besser gelöst und die Anfragen der Professoren für neue
Computer schneller bearbeitet? Wenn diese Fragen mit „ ja“ beantwortet werden
können, dann sollte der Service Support sofort in der Universität implementiert
werden. Zudem sollten sich in der Universität Bielefeld bereits Grundzüge der
ITIL vorfinden lassen, da diese auf dem Best Practice-Konzept beruhen und jedes Unternehmen, auch die Universität Bielefeld, an einer möglichst effizienten
IT-Lösung schon lange vor der Einführung von ITIL interessiert sein sollte.
Ziel dieser Arbeit ist es, diesen Fragen bzw. Behauptungen nachzugehen und
das Konzept der ITIL im serviceorientierten IT-Management in der Realität
kritisch zu hinterfragen. Aus diesem Grund sollen zunächst die Anforderungen
von ITIL im Bereich des Service Supports in Kapitel 1.2 vorgestellt werden. Die
ausführliche Darstellung dieses Kapitels hat mehrere Gründe. Zum einen soll dadurch gewährleistet werden, dass der Leser einen umfangreichen Überblick über
die einzelnen Anforderungen an einen ITIL-konformen Service Support erhält,
zum anderen soll die Komplexität und die damit verbundene Schwierigkeit der
Implementierung von ITIL verdeutlicht werden. Anschließend wird die mögliche
Anwendung des von ITIL vorgeschlagenen Standards anhand zweier ausgewählten Fakultäten der Universität Bielefeld kritisch evaluiert. Dabei wird zunächst
auf die jetzige Situation des Service Supports der jeweiligen Fakultät verwiesen.
Dieser IST-Zustand wurde anhand von Interviews mit den zuständigen EDVMitarbeitern der Fakultäten festgestellt und wird in Kapitel 1.3 behandelt. Eine
daran anschließende Kritik im Bezug auf den IST-Zustand des IT-Services der
jeweiligen Fakultäten soll ebenfalls in diesem Kapitel ausgeübt werden. Des
Weiteren werden diverse Empfehlungen, die auf den von ITIL vorgeschlagenen
Service Support basieren, Gegenstand dieses Abschnitts sein. Das Fazit dieser
Arbeit wird anschließend Thema des Abschnitts 1.4 sein. Hier sollen die letzten noch offen gebliebenen Fragen im Bezug auf die ITIL-Wirklichkeit an der
Universität Bielefeld bzw. die Service Support-Umsetzung an zwei ausgewählten
Fakultäten geklärt werden. Um ein besseres Verständnis für den Service Support
von ITIL zu bekommen, sollen nun in dem folgenden Kapitel die theoretischen
Grundlagen des Service Supports im Hinblick auf seine Funktionen und Prozesse
vorgestellt werden.
1.2
Service Support
Für die bereits oben beschriebenen Störungsfällen soll nun der Service Support
nach ITIL als Unterstützung im Bereich des operativen IT-Services fungieren
und dem Kunden1 bei der Lösung seiner Probleme behilflich sein. Allerdings
gestaltet sich der Aufgabenbereich des Service Supports wesentlich komplexer,
da der Service Support nicht nur die Probleme der Endanwender lösen soll, sondern auch einen reibungslosen Betriebsablauf im Bereich der IT gewährleisten
soll.
Nach der ITIL-Philosophie lässt sich der Service Support im wesentlichen in
fünf Geschäftsprozesse und eine unterstützende Funktion untergliedern:
1 Es ist hier sowohl der unternehmensexterne als auch der unternehmensinterne Kunde
(Endanwender bzw. User) gemeint.
11
• Service Desk, als unterstützende Funktion,
• Incident Management,
• Problem Management,
• Change Management,
• Release Management,
• Configuration Management.
Treten Störungen oder Fehler beim Gebrauch der IT auf, so muss der User sich
mit diesem Vorfall, auch Incident 2 genannt, an eine zentrale Kontaktstelle, den
sogenannten Service Desk, wenden. Dieser soll also dem Kunden als zentrale Anlaufstelle für Probleme und Wünsche bzw. Anregungen, die laut ITIL auch als
Request for Change (RfC) 3 bezeichnet werden, dienen. Es werden sowohl Störungen im Bereich der IT als auch Wünsche der Kunden entgegengenommen,
dokumentiert und versucht, diese zu beheben bzw. zu erfüllen. Dadurch wird
auch die enge Verknüpfung des Service Desks mit dem Incident Management
deutlich. Denn sollte die primäre Hilfe des Service Desks nichts bewirken, so wird
der Prozess des Incident Managements in Gang gebracht. Das Incident Management hat zur Aufgabe, möglichst schnell auf etwaige Incidents zu reagieren
und diese zu beheben, um einen reibungslosen Betriebsablauf zu gewährleisten. Beim sogenannten Problem Management wiederum geht es vielmehr um
die Ursachenforschung. Wenn die Ursache einer Störung noch nicht bekannt ist,
dann liegt laut ITIL ein Problem vor, welches vom Problem Management zu dokumentieren, je nach Schweregrad zu klassifizieren und zu untersuchen ist. Ist
die Ursache bzw. der Grund für eine Störung gefunden, geht von dem Problem
Management ein Request for Change an das Change Management, um solche
Störungen zu vermeiden. Das Change Management klassifiziert die erhaltenden
RfCs und ordnet sie nach ihrer Wichtigkeit. Anschließend wird hier entschieden,
welche Änderungen zu welchem Zeitpunkt durchgeführt werden sollen. Hier erfolgt ebenfalls eine Dokumentation der Entscheidungen. Die Kontrolle über alle
Änderungen und die Entwicklung bzw. Einführung von standardisierten Änderungsverfahren zählen zu den wichtigsten Aufgaben des Change Managements.
Im Release Management werden dann sämtliche bewilligte Änderungen bezüglich der Hardware- und Softwarekomponenten der IT gebündelt und zu neuen Releases zusammengefasst. Dabei wird die Durchführung der Änderungen
geplant, getestet, kontrolliert und selbstverständlich auch dokumentiert. Das
Release Management hat somit nach der ITIL-Philosophie die Systemordnung
des Betriebs sicherzustellen. Das Configuration Management ist für die Pflege der zentralen Informationsquelle sämtlicher Prozesse des Service Supports
zuständig. Alle Informationen, wie zum Beispiel die bereits erwähnte Dokumentation in den Prozessen, die vorhandene Hardware im Betrieb, die Verbindungen zwischen Datenbanken oder die Lizenzen der Betriebssoftware, werden in
einer sogenannten Konfigurationsdatenbank gespeichert, für die das Configuration Management zuständig ist.
Abbildung 1.1 stellt den Aufbau des Service Supports dar.
2 engl.
Incident = Vorfall, Störung
an eine Systemkomponente
3 Änderungsanforderung
12
Incident
S
e
r
v
I
c
e
D
e
s
k
Incident Management
Incident
Problem Management
RfC
IT Operations
Configuration
Management
RfC
Change Management
Release Management
Incident / Request for Change
Informationsfluss
Abbildung 1.1: Service Support.
Aus Abbildung 1.1 wird ersichtlich, stellt jeder Prozess eine in sich geschlossene Einheit dar, allerdings existieren Schnittstellen, die eine Kommunikation
zwischen den verschiedenen Prozesse ermöglichen.
Des Weiteren ist noch anzumerken, dass ITIL oft den Begriff Rolle innerhalb
der Prozesse verwendet. So sind zum Beispiel die Aufgaben des Incident Managements in der Rolle des Incident Managers zu beschreiben. Grund dafür ist,
dass die ITIL-Prozesse unabhängig von der Organisationsstruktur des Betriebs
sein sollten, da somit eine höhere Flexibilität bei der Einführung bzw. der Umsetzung von ITIL gewährleistet werden kann. So kann beispielsweise in kleineren
Betrieben eine Person sowohl Incident Manager als auch Configuration Manager sein, ohne die von ITIL vorgeschlagene Aufteilung des Service Supports zu
verletzen.
Nachdem die Zusammenhänge bzw. der Aufbau der operativen Ebene des serviceorientierten IT-Managements, d.h. des Service Supports, kurz dargestellt
wurden, sollen nun in den folgenden Abschnitten die einzelnen Prozesse, also Incident Management, Problem Management, Configuration Management,
Change Management und Release Management, und die Funktion Service Desk
detailliert beschrieben werden.
1.2.1
Service Desk
Wie bereits in dem vorangegangenen Abschnitt gesagt, existieren eine Reihe
von verschiedenster Vorfälle, die in einem laufenden Betrieb im Bereich der IT
zum Alltag gehören. Fragen, Beschwerden, Probleme aller Art, sie werden von
ITIL als Incident bezeichnet, müssen möglichst schnell erfasst, bearbeitet und
gelöst werden, um eine Störung des laufenden Betriebs zu vermeiden. In diesem
13
Zusammenhang kommt der sogenannte Service Desk 4 ins Spiel.
Der Service Desk soll laut ITIL als zentraler Anlaufpunkt für sämtliche Incidents dienen und das Kommunikationsinstrument zwischen Service Support
und Endanwender sein. Aus diesem Grund wird der Service Desk als eine Funktion und nicht als Prozess des Service Supports verstanden, da er mehr oder
weniger die Schaltstelle für die übrigen Prozesse darstellt. Probleme, Belange,
Fragen, Wünsche, etc. sollen hier gesammelt, klassifiziert und, wenn möglich,
beantwortet werden. Hier wird auch die enge Verbindung zum Incident Management deutlich. Der Service Desk übernimmt teilweise die Aufgaben des Incident Managements, da versucht werden soll, die Fragen oder Störungen bereits
hier zu klären und zu beseitigen, bevor sich das Incident Management mit ihnen
beschäftigt. Es besteht daher durchaus die Möglichkeit, dass ein Incident Manager auch Mitarbeiter des Service Desk ist et vice versa. Das Ziel des Service
Desks sollte somit eine hohe Erstlösungsrate sein. „Ziel des Service Desks ist es,
möglichst viele Anfragen bereits bei Erstkontaktaufnahme durch den Anwender
vollständig zu beantworten und abzuschließen.“ [Vic05, S. 34]
Auf Grund der Tatsache, dass der Service Desk die einzige Kommunikationsstelle zwischen Support und Kunden ist, wird er auch als Single Point of Contact,
kurz SPOC, bezeichnet. Warum der Service Desk der einzige Kommunikationskanal zwischen Support und Kunden ist, lässt sich am einfachsten anhand eines
Beispiels verdeutlichen.
Angenommen, ein Mitarbeiter hat Probleme mit seiner Netzwerkkarte. Da er
jemanden vom Service Support kennt, umgeht er den Service Desk und bittet
seinen Bekannten direkt um Hilfe. Dieser kümmert sich sofort um die Netzwerkkarte. Die Problematik ist allerdings dabei, dass, da mehrere Netzwerkkarten
streiken, der Vorfall und der passende Lösungsweg bereits im Service Desk bekannt sind. Dadurch entsteht ein unnötiger Mehraufwand, der hätte vermieden
werden können. Ebenso hätten weitaus schlimmerere Konsequenzen eintreten
können, wenn das gesamte Netzwerk ausgefallen wäre und der Mitarbeiter des
Service Supports sich lediglich um diese eine Netzwerkkarte kümmern würde.
Somit zeigt sich, dass der Service Desk als einziger Kommunikationsweg wesentliche Vorteile besitzt. „Schwerwiegende Störungen oder sogenannte Massenstörungen könnten nicht mit der ihnen zustehenden notwendigen Priorität behandelt und die Ausweitung auf weitere Anwender könnte nicht verhindert werden.
Die gleichmäßige Arbeitsbelastung der unterstützenden Spezialisten wäre nicht
mehr steuerbar und eine zügige Abarbeitung von Incidents oder Problemen mit
hoher Priorität wäre gefährdet.“ [Vic05, S. 33] Die wichtigsten Aufgaben des
Service Desk sind demnach:
• einheitliche zentrale Kommunikationsschnittstelle (SPOC) zwischen Usern
und Support in Verbindung mit Ausgabe von Informationen, zum Beispiel
des aktuellen Status von Vorgängen, geplanten Änderungen, usw.,
• Aufnahme, Dokumentation und Auswertung von Vorfällen,
• Bearbeitung von Problemen mit „Erste Hilfe“ -Charakter, auch First Level
Support genannt,
4 Service Desk wird oft auch mit den Begriffen Help Desk oder User Desk beschrieben.
Grundsätzlich ist aber ihre Bedeutung gleich. ITIL benutzt den Ausdruck Service Desk, um die
Dienstleistung, die aktive Unterstützung des Mitarbeiters, die hinter dieser Funktion steckt,
zu betonen.
14
• Einschätzung von Vorfällen und damit verbundene Weiterleitung der Incidents zu den Supportstellen Incident Management und Problem Management (Second und Third Level Support).
Aus den Aufgaben des Service Desks wird ersichtlich, dass die Anforderungen an
den Mitarbeiter des Service Desks sehr umfangreich sind. Dieser muss bei einem
hohen Kommunikationsaufkommen, begründet durch die SPOC-Eigenschaft des
Service Desks, nicht nur eine gewisse Kenntnis von der Materie, sondern vielmehr auch eine gute fachliche Kompetenz vorweisen können. Des Weiteren empfiehlt es sich, dass der Mitarbeiter rhetorische und soziale Fähigkeiten besitzt,
um einen geeigneten Umgang mit ungeduldigen bzw. unzufriedenen Kunden zu
finden.5
Nachdem wir uns mit den Aufgaben, Eigenschaften und Zielen des Service Desks
beschäftigt haben, wollen wir uns nun dem Service Desk hinsichtlich seiner
Struktur bzw. seiner Organisation widmen. Im nun folgenden Abschnitt sollen
nun kurz drei verschiedene Architekturmodelle zur Implementierung des Service
Desks vorgestellt werden.
Lokaler Service Desk. Zum einen besteht die Möglichkeit eines lokalen Service Desk. Hierbei handelt es sich um eine dezentrale Struktur. Beispielsweise
könnte so eine Universität für jede Fakultät einen eigenen Service Desk, der
über optimale Kenntnisse bezüglich aller Vorgänge innerhalb der jeweiligen Fakultät verfügt, haben. Die Vorteile wären eine hohe Intensität im Bereich der
Kundenbetreuung und eine verkürzte Reaktionszeit auf sämtliche Incidents der
Fakultät. Die Voraussetzung für die Einführung eines lokalen Service Desks ist
allerdings die Bereitstellung eine großen Menge an Ressourcen6 . Dies findet seine Begründung darin, dass jeder lokale Service Desk auch für die Bereitstellung
eines lokalen Service Supports sorgen muss. Außerdem kann sich eine Einführung eines lokalen Service Supports in Bezug auf die Zusammenarbeit von Unternehmensbereichen, in unserem Beispiel bezüglich der Zusammenarbeit von
Fakultäten, als problematisch erweisen. Es besteht die Möglichkeit, dass jeder
Unternehmensbereich oder jede Fakultät anders mit Incidents verfährt und daher andere Systeme oder Prozesse zur Behandlung von Incidents benutzt. Eine
mögliche Zusammenarbeit von Fakultäten wäre somit gefährdet.
Abbildung 1.2 soll den Grundgedanken des lokalen Service Desks nochmals verdeutlichen. Sie zeigt auch eine weitere Möglichkeit, den Service Desk zu strukturieren.
Zentraler Service Desk. Der zentrale Service Desk ist die einzige Anlaufstelle für alle Unternehmensbereiche. Die Problematik der Zusammenarbeit der
Unternehmensbereiche, wie sie beim lokalen Service Desk auftrat, ist hier nicht
gegeben, da nicht nur ein System zur Bewältigung von Incidents existiert, sondern auch sämtliche Prozesse vereinheitlicht werden. Bei einem zentralen Service
Desk ist zwar der Kommunikations- bzw. Informationsfluss wesentlich größer als
der bei einem lokalen Service Desk, der Informationsgewinn steigt aber ebenfalls. Mit steigendem Informationsgewinn kann die Verteilung der Ressourcen
optimiert werden und somit können Kosten gesenkt werden.
5 Auch
6 In
in diesem Dienstleistungssegment gilt: Der Kunde ist König.
besondere Weise monetäre Ressourcen
„Funktion“
A
„User“
S
e
r
v
I
c
e
D
e
s
k
„User“
„User“
Service Support
„Funktion“
B
A
S
u
p
p
o
r
t
D
e
s
k
„Funktion“
„Prozesse“
1
st
L
e
v
e
l
S
e
r
v
I
c
e
„Prozesse“
1
st
L
e
v
e
l
S
u
p
p
o
r
t
Service Support
Lokaler Service Desk
15
B
„User“
Z
e
n
t
r
a
l
e
r
S
e
r
v
I
c
e
D
e
s
k
„Prozesse“
1
st
L
e
v
e
l
S
u
p
p
o
r
t
Service Support
Zentraler Service Desk
Abbildung 1.2: Lokaler und zentraler Service Desk.
Durch ein Beispiel soll dieser Vorteil verdeutlicht werden. Angenommen, es liegt
ein Request for Change vor. Ein Mitarbeiter benötigt einen neuen Computer.
Die verschiedenen lokalen Service Desks haben folglich die Aufgabe, sich um diesen RfC zu kümmern und an die passende lokale Supportstelle weiterzuleiten.
Diese wird das ihrer Meinung nach beste Angebot einholen und den Computer bestellen. Durch einen zentralen Service Desk bzw. einen zentralen Service
Support besteht nun aber die Wahrscheinlichkeit, ein noch besseres Angebot
einzuholen, da die Mitarbeiter des Service Supports sich über Angebote und
Preise austauschen können. Man kann demnach einen Nutzen aus dem somit
gewonnenen Informationsgewinn ziehen.
Ein anderes Beispiel wäre die Behandlung von Incidents. Während sich bei dem
lokalen Service Desk jeweils ein Mitarbeiter mit ein und demselben Incident
beschäftigen würden, könnte man bei einem zentralen Service Desk einen Mitarbeiter mit der Behandlung des Incidents beauftragen, während der andere Mitarbeiter bereits einen neuen Incident entgegennimmt, auch hier könnten Kosten
gespart werden.
Allerdings können bei einer Einführung eines zentralen Service Desks auch Probleme entstehen. Je größer ein Kundenstamm wird, desto schwieriger wird sich
die kundennahe Betreuung erweisen. Somit nimmt selbstverständlich auch der
Organsisationsbedarf bzw. -aufwand erheblich zu.
Virtueller Service Desk. Die dritte Service Desk-Struktur versucht die Vorteile der bereits vorgestellten Strukturen zu kombinieren. Abbildung 1.3 zeigt
den sogenannten virtuellen Service Desk. Der virtuelle Service Desk sieht zwar
16
„Funktion“
A
S
e
r
v
I
c
e
D
e
s
k
1st
L
e
v
e
l
S
u
p
p
o
r
t
„User“
„Prozesse“
„Funktion“
B
S
e
r
v
I
c
e
D
e
s
k
1st
L
e
v
e
l
S
u
p
p
o
r
t
„User“
Service Support
Abbildung 1.3: Virtueller Service Desk.
lokale Annahmestellen und lokale Support Teams7 vor, aber auch eine zentrale
Datenbank. Somit sind die Vorteile des lokalen Service Supports, nämlich eine
kundennahe Betreuung und eine verkürzte Reaktionszeit auf Incidents, ebenfalls
bei dem virtuellen Service Desk vorzufinden, wie auch der erhöhte Informationsgewinn des zentralen Service Desks. Demgegenüber steht aber ein entscheidender Nachteil. Der Aufwand, den virtuellen Service Desk zu organisieren, ist
erheblich und dementsprechend teuer.
Wir haben nun gesehen, wie der Service Desk als eine Funktionseinheit auf der
operativen Ebene des serviceorientierten IT-Managements wirkt. Des Weiteren
wurden Aufgaben, Ziele und Organisationsstrukturen des Service Desks vorgestellt. Warum aber der Service Desk und das Incident Management so eng
miteinander verknüpft sind und wie die Incidents im einzelnen behandelt werden, soll nun im folgendem Kapitel betrachtet werden.
1.2.2
Incident Management
Bevor man sich mit den Aufgaben, den Zielen und dem Prozess des Incident
Managements beschäftigt, müssen vorab zwei Sachverhalte erklärt werden. Zum
einen muss definiert werden, was genau ein Incident ist, und zum anderen muss
7 Diese
sollen vom virtuellen Service Support gesteuert und verwaltet werden
17
gekläre werden, wie der Zusammenhang zwischen Incident Management und
Service Desk aussieht.
Laut dem Office of Government Commerce [OGC07, S. 46] ist ein Incident
definiert als:
An unplanned interruption to an IT service or reduction in the
quality of an IT Service. Failure of a configuration item that has not
yet impacted service is also an incident, for example failure of one
disk from a mirror set.
Ein Incident kann also als ein Ereignis verstanden werden, das zu einer Unterbrechung oder zu einer Abnahme der Qualität des IT-Services8 führt. Es existiert
eine Vielzahl von Incidents, diese lassen sich zum Beispiel in Abhängigkeit ihres
Ursprungs kategorisieren:
• Störung im Bereich der Hardware, beispielsweise:
– bestimmte Netzwerkkarten funktionieren nicht,
– Prozessoren haben einen technischen Defekt,
– Bildschirme einer gewissen Marke empfangen nicht das gewünschte
Signal.
• Störung im Bereich der Software, beispielsweise:
– die Software des Users zur Berechnung des Gewinn- und VerlustWertes einer Firma errechnet den falschen Wert,
– der Zugriff auf eine Software wird verweigert, obwohl man selbst Administrator ist,
– ein benötigter Treiber wurde falsch oder gar nicht installiert.
• Anfragen, beispielsweise:
– „Ich habe mein Passwort vergessen. Können Sie mir weiterhelfen?“
– „Ich brauche einen neuen Laserdrucker. Mein alter Drucker macht es
nicht mehr lange. Können Sie mir einen Bestellen?“
Die Incidents werden im Service Desk9 , der die zentrale Funktion des Incident Managements darstellt, entgegengenommen und bearbeitet. „Der Service
Desk übernimmt als Funktion innerhalb des Incident Managements weitgehend die operative Steuerung und Dokumentation der Aktivitäten der IncidentBearbeitung.“ [Olb06, S. 28] Gegenstand dieses Kapitels ist aber vorrangig, die
Ziele, die Aufgaben und insbesondere den Prozess des Incident Managements
darzustellen.
Die wichtigsten Ziele des Incident Managements sind, bei Eintritt eines Störungsfalles die schnellstmögliche Wiederherstellung des normalen Betriebs zu
gewährleisten, mögliche Einflüsse durch Störungen auf den Betrieb zu minimieren und das vertraglich vereinbarte Service Level Agreements (SLA) 10 halten zu
8 Unter dem Begriff „Abnahme der Qualität des IT Services“ wird hier die Unterschreitung
der voher vereinbarten Service-Grenzen verstanden.
9 Wie bereits im vorherigen Kapitel ausführlich beschrieben.
10 Vereinbarungen, die mit dem User oder Kunden über die Höhe der Service-Dienstleistung
getroffen wurden.
18
können. Laut ITIL gilt, dass jeder Incident, der im Service Desk aufgenommen
wird, einen entsprechenden Prozess im Incident Management auslöst. Dabei ist
anzumerken, dass die einzelnen Schritte des Prozesses zugleich die Aufgaben
des Incident Managements bei Eintritt eines Incidents darstellen. Wie genau
dieser Prozess nach der ITIL-Empfehlung aussehen sollte, wird nun anhand der
Abbildung 1.4 dargestellt und erläutert.
Incident aufnehmen
und dokumentieren
Klassifizierung und
erste Unterstützung
Monitoring, Control & Communication
ja
Service
Request?
Service Request
Verfahren
nein
Untersuchung und
Diagnose
Problem?
ja
Weiterleitung
an den Support
nein
Lösung,
Wiederherstellung
Service
Incident Closure
Abbildung 1.4: Flussdiagramm Incident.
Incident aufnehmen und dokumentieren. Im ersten Schritt wird der Incident aufgenommen, das heißt alle wichtigen Informationen bezüglich des Incidents, wie:
• wann der Incident festgestellt wurde,
• welcher Kategorie der Incident angehört,
• wie der User heißt, der den Incident festgestellt hat, und in welcher Abteilung er arbeitet, usw.
werden hier erfasst und unter einer gemeinsamen Referenznummer in einer Datenbank, der sogenannten Configuration Management Data Base (CMBD) 11
abgespeichert bzw. dokumentiert.
11 Diese
Datenbank wird noch ausführlich in dem Abschnitt 1.2.6. beschrieben.
19
Da diese Aufgabe vom Service Desk ausgeführt wird, wird an dieser Stelle nochmal die enge Verknüpfung des Incident Managements als Prozess mit dem Service Desk als operative Funktion des Incident Managements deutlich. Die Erfassung des Incidents ist äußerst wichtig, da die nachfolgenden Support-Gruppen
ebenfalls auf die entscheidenden Daten bezüglich des Incidents angewiesen sind.
„and so that if the incident has to be referred to other support group(s), they
will have all relevant information to hand to assist them.“ [OGC07, S. 49]
Klassifizierung und erste Unterstützung. Nachdem nun der Incident aufgenommen und dokumentiert wurde, gilt es nun zwei Fragen zu beantworten.
Es muss geklärt werden, welcher sogenannten „Klasse“ der Incident angehört
und ob die Möglichkeit besteht, den Incident bereits im Service Desk, von daher
im Incident Management-Prozess, zu lösen.
Wie bereit zu Anfang dieses Kapitels beschrieben, lassen sich Incidents ihrer
Quelle nach kategorisieren. Es wurde zwischen Störungen im Software- und
Hardwarebereich und Anfragen unterschieden. Die Klassifizierung von Incidents
beinhaltet aber nicht nur die Kategorisierung, sondern auch die sogenannte Priorisierung, die einem Incident zugesprochen wird. Es gilt:
Klassifizierung = Kategorie + Priorität
Die Priorisierung bzw. die Priorität setzt sich wiederum aus der Dringlichkeit,
wie schnell der Incident behandelt werden muss, und der Auswirkung, zum
Beispiel wie viele User von diesem Incident betroffen sind, zusammen12 . Daraus
folgt:
Priorität = Dringlichkeit + Auswirkung
Wie sich die Priorität im einzelnen dann bestimmen lässt, kann laut ITIL über
sogenannte Bewertungsmatrizen erfolgen, in denen zum Beispiel die Anzahl der
betroffenen User und die Auswirkung des Incidents gegeneinander abgetragen
werden. Eine Klassifizierung von Incidents könnte, wie folgt, aussehen:
• einfache Anfragen,
• Anfragen bezüglich einer Änderung im IT-Bereich,
• Störungen, deren Ursache bekannt ist,
• Störungen, deren Ursache unbekannt ist.
Handelt es sich um eine einfache Anfrage seitens des Users, so sollte diese bereits
im Service Desk und somit am Anfang des Incident Managements zu beantworten sein13 . Bezieht sich die Anfrage auf eine Änderung im IT-Bereich, so spricht
man von einem Request for Change (RfC), dieser Änderungsantrag wird gesondert in einem Service Request-Verfahren behandelt, das aber in Abschnitt 1.2.4.
12 Es existieren aber auch andere Definitionen von Dringlichkeit und Auswirkungen. So sieht
die Dringlichkeit, wenn der „Chef“ einen neuen Computer will, anders aus, als wenn der
Praktikant einen neuen benötigt
13 Ein guter Service Desk zeichnet sich unter anderem dadurch aus, dass er die meisten
einfachen Fragen der IT-User bereits im Vorfeld klären kann.
20
separat behandelt wird. Liegt allerdings eine Störung vor, so wird erstmal unabhängig davon, ob die Ursache bekannt oder unbekannt ist, der Prozess des
Incident Managements fortgesetzt.
Wichtig sei hier noch zu erwähnen, dass sowohl die Klassifizierung als auch die
erste Unterstützung durch den Service Support dokumentiert und in der CMBD
abgespeichert wird.
Untersuchung und Diagnose. Da die Anfragen als Incident bereits in den
vorangegangenen Schritten des Incident Management-Prozesses bearbeitet wurden, werden ab hier nur noch Störungen des laufenden Betriebs behandelt. Dabei
wird zwischen zwei Arten von Störungen unterschieden.
Die Störungen, die als Ursache einen bereits bekannten Fehler haben, werden
als Known Error bezeichnet, die Störungen, deren Ursache unbekannt ist14 , als
Unknown Error bzw. Problem. Nun gilt es den Incident hinsichtlich seiner Art zu
untersuchen, um anschließend eine Diagnose erstellen zu können, ob der Incident
durch das Incident Management selbst oder durch die anderen Support-Stellen
behoben werden kann.
Stellt sich heraus, dass es sich um einen Known Error handelt, so existiert
bereits eine Lösung für diesen Fehler. Dies kann eine einfache Handlungsanweisung, mit der der Fehler endgültig gelöst wird, oder eine Umgehungslösung,
ein sogenannter Workaround, mit der der Fehler lediglich umgangen wird, sein.
Die bekannten Lösungen werden durch die CMDB bereitgestellt, in der sich
sämtliche durch das Problem Management erarbeitete Lösungen für die verschiedensten Incidents befindet15 . Das Incident Management hat zu jeder Zeit
Zugriff auf diese Datenbank und die sich darauf befindlichen Lösungen. Hier
kann das Incident Management durch seinen First Level Support bereits helfen
und aktive Unterstützung durch Bereitstellung der Lösung leisten.
Wird der First Level Support an seine Grenzen gebracht, ein Incident wird daher
als Problem diagnostiziert, wird dieses Problem dann an das Problem Management weitergeleitet. Dieser Vorgang wird bei ITIL als funktionale Eskalation
bezeichnet. Der Incident wird somit an eine Gruppe von Spezialisten weitergegeben. Diese Spezialisten werden als Second Level Support bezeichnet und
verfügen im Gegensatz zum First Level Support über ein größeres Fachwissen
und eine bessere Ausstattung, um Incidents zu behandeln. Diese Weiterleitung
an eine Gruppe von Spezialisten kann theoretisch n-mal geschehen, also bis zu
einem n-ten Level Support fortgesetzt werden.
In Anlehnung an [Olb06] soll Abbildung 1.5 die funktionale Eskalation verdeutlichen.
Bei ITIL wird aber lediglich von einem Third Level Support gesprochen, der
bereits aus den Herstellern der fehlerhaften Software bzw. Hardware besteht.
Das Problem Management stellt hier somit in diesem Prozess den Second Level
Support dar.
An dieser Stelle wird auch nochmals das Ziel des Incident Managements und
damit der Unterschied zum Problem Management mehr als deutlich. Während
das Incident Management versucht, Fehler und die damit verbundenen Störungen zu vermeiden, geht das Problem Management den Fehler auf den Grund.
Falls ein Incident „unbekannter Natur“ ist, es sich von daher um ein Problem
14 Es
kann auch mehrere Ursachen für ein Problem geben
soll aber erst im folgenden Abschnitt genauer erläutert werden.
15 Dies
21
1st Level Support
Untersuchung und
Diagnose
Problem?
ja
2nd Level Support
3rd Level Support
Untersuchung und
Diagnose
Untersuchung und
Diagnose
n-ter Level Support
Untersuchung und
Diagnose
nein
Lösung?
nein
Lösung?
ja
nein
ja
Lösung?
ja
Lösung,
Wiederherstellung
Service
Abbildung 1.5: Ablauf der funktionalen Eskalation.
handelt, oder ein Incident immer wiederkehrt, so ist das Problem Management
davon in Kenntnis zu setzen und der Incident zu übergeben.
Lösung, Wiederherstellung des Services. Nachdem alle Informationen
bezüglich des Incidents zusammengetragen und untersucht wurden, kann nun
ein möglicher Lösungsweg ausgewählt und getestet werden. Für die Wiederherstellung des standardisierten Betriebs kommen hier folgende Möglichkeiten in
Frage:
• Der Workaround, der lediglich eine Umgehungslösung darstellt. Die Ursache des Incidents wurde nicht untersucht. An dieser Wiederherstellung
des Betriebs wird daher nochmal die Aufgabe des Incident Managements,
nicht die Ursachen des Incidents zu untersuchen, sondern lediglich den
laufenden Betrieb zu gewährleisten, mehr als deutlich.
• Die Lösung, die bereits im Incident Management bekannt ist, bereitstellen.
Das heißt zum Beispiel ein neues Passwort an einen User liefern, der sein
altes Passwort vergessen hat.
• Die Lösung, die vom nachfolgenden Problem Management bzw. Service
Support erarbeitet wurde, bereitstellen. Das heißt, ein Unknown Error
wird zum Known Error und es kann durch das Incident Management darauf zugegriffen werden.
• Auf einen Request for Change, der zuvor an das Change Management weitergeleitet und von diesem bearbeitet wurde, antworten. In dieser Antwort
kann dann enthalten sein, dass der Auftrag ausgeführt, aber auch, dass er
abgelehnt wurde.
22
Es sei hier noch erwähnt, dass für die Ausführung der gerade dargestellten Möglichkeiten sowohl der Service Desk selbst als auch extra dafür eingerichtete Service Support Teams, sozusagen die IT Operater, in Frage kommen.
Incident Closure. Nachdem die Anfrage beantwortet oder die Störung beseitigt und somit der User zufrieden gestellt wurde, kann der Incident im Incident
Closure „formell“ abgeschlossen werden. Doch damit ist der Prozess noch nicht
ganz beendet. Wichtig ist nämlich hierbei das sämtliche Informationen bezüglich des Verlaufs der Incident-Behandlung im Incident Record abgespeichert
werden. Dies betrifft im besonderem Maße die Lösung des Incidents, da somit
gewährleistet werden kann, dass bereits der Service Desk bei Eintritt desselben
Incidents auf die passenden Incident-Details zurückgreifen und entsprechende
Maßnahmen ergreifen kann, ohne das aufwendige Analysen durchgeführt werden müssen.
Monitoring, Control & Communication. Wichtige und dauerhafte Begleiter aller Subprozesse des Incident Managements sind Monitoring, Kontrolle
und Kommunikation. Unter dem Begriff Monitoring wird hier die Erfassung,
Beobachtung und Überwachung des Incident Managements verstanden. So besteht zum Beispiel zu keiner Zeit die Möglichkeit zur Stagnation der Behandlung
eines Incidents, was natürlich ganz klar von Vorteil ist. Ein weiterer wichtiger
Begleiter des Incident Managements ist die Kontrolle des Incidents. Dies lässt
sich am einfachsten anhand eines Beispiels verdeutlichen.
Angenommen, ein Incident würde sich zu lange im Subprozess „Klassifikation
und erste Unterstützung“ befinden, da er als zu unwichtig eingestuft wird. Nach
einer Weile würde er in Vergessenheit geraten. Um solche Fälle zu vermeiden,
könnte man zum Beispiel eine Art „Zeitkontrolle“ einführen, die kontrolliert,
wie lange sich ein Incident in einer Instanz des Incident Managements befindet
und überhaupt befinden darf.
Der letzte wichtige Aspekt ist die Kommunikation. Hier ist sowohl die Kommunikation zwischen Incident Management und User als auch die Kommunikation
des Incident Managements und dem Service Support gemeint. So kann zum Beispiel ein User immer über den Prozess informiert werden und ist somit immer
„auf dem Laufenden“. Dies kann sich positiv auf die Resonanz auf den Service
Desk bzw. auf das Incident Management auswirken.
Es wurde nun gezeigt, dass sämtliche Incidents den hier vorgestellten Prozess
durchlaufen. Des Weiteren wurden das Ziel, die Gewährleistung eines laufenden
Betriebs, die Aufgaben und somit der Prozess mit allen einzelnen Instanzen des
Incident Managements vorgestellt. Doch was passiert mit den Problemen, also
den Incidents, dessen Ursache nicht klar ist, diese Frage soll nun im nächsten
Abschnitt geklärt werden.
1.2.3
Problem Management
Im vorangegangenen Abschnitt wurde das Ziel des Incident Managements dargestellt, nämlich eine schnelle Wiederherstellung des laufenden Betriebs. Ein
mögliches Mittel ist hierzu zum Beispiel die Bereitstellung einer bereits bekannten Lösung in Form von einer Handlungsanweisung oder die Anwendung eines
Workarounds. Doch woher kommen die bekannten Lösungen von Fehlern bzw.
23
Problemen und woher kommen die Workarounds, die im Incident Management
ihre Anwendung finden? Die Antworten dafür sind im Problem Management zu
finden.
Sobald ein Incident eine unbekannte Ursache hat, wird dieser Incident zum Problem. Dieses wird vom Incident Management, das nicht in der Lage ist, dieses
Problem zu behandeln, weitergeleitet zum Problem Management. Hierbei ist zu
erwähnen, dass ein Problem durchaus ein Resultat von mehreren Incidents sein
kann. „ITIL defines a problem as the cause of one or more Incidents“. [OGC07,
S. 58] Dass man es mit einem Problem zu tun hat, merkt man an zwei Sachverhalten. Zum einen kann das Incident Management nicht mehr weiterhelfen,
zum anderen kann das Incident Management zwar einen Workaround bzw. eine
Lösung liefern, aber ein und derselbe Incident tritt immer wieder von neuem
auf.
Als Beispiel könnte hier ein Computer genannt werden, dessen Programme nicht
ordnungsgemäß ausgeführt werden, und deshalb nicht einwandfrei läuft. Als
Workaround würde das Incident Management einen Neustart des Computers
empfehlen. Hilft dieser Neustart nicht, nach gewisser Zeit wird also derselbe
Incident, also die nicht ordnungsgemäße Ausführung der Programme, erneut
auftreten, so spricht man hier eher von einem Problem als von einem Incident.
Dieses muss dann von dem Problem Management behandelt werden.
Um die Vielfältigkeit von Problemen und die damit betroffenen Personengruppen darstellen zu können, sollen kurz weitere Beispiele folgen. Als Probleme
kommen in Frage:
Virenprobleme: Hiervon können einzelne Mitarbeiter, aber auch ganze Unternehmen betroffen sein. Die Auswirkungen beziehen sich auf den Ausfall
eines Computers bis hin zu ganzen Servern.
Hardwareprobleme: Man kann nicht mehr auf eine bestimmte Festplatte zugreifen, da sie defekt ist. Bei einzelnen Computerfestplatten wäre dieser
Vorfall nicht so schlimm, hingegen hat der Ausfall eines Server auf Grund
eines Defektes aber einen ganz anderen Stellenwert. Bei einer Bank zum
Beispiel könnte dies katastrophale Auswirkungen haben.
Softwareprobleme: Einmal angenommen, eine Universität würde eine bestimmte Software zur Verwaltung von Noten benutzen. Diese arbeitet
allerdings immer wieder fehlerhaft und ordnet die Noten nicht den gewünschten Personen zu. Auch hier wären die Auswirkungen definitiv zu
merken.
Diese Reihe an Beispielen für Probleme könnte beliebig lang fortgesetzt werden und verdeutlicht ganz klar, welches Ziel das Problem Management haben
sollte und welche Anforderungen an das Problem Management gestellt werden.
Laut ITIL lässt sich das Ziel des Problem Managements, wie folgt, definieren:
„The primary objectives of Problem Management are to prevent problems and
resulting incidents from happening, to eliminate recurring incidents and to minimize the impact of incidents that cannot be prevented.“ [OGC07, S. 58 f.] Das
Ziel ist daher, Probleme bzw. Incidents zu vermeiden, wiederkehrende Incidents
zu eliminieren und die Auswirkungen der Incidents, die nicht vermieden werden
konnten, zu minimieren. Es lässt sich der ITIL-Philosophie nach dann erreichen,
wenn die drei Aufgabenbereiche des Problem Managements, Problem Control,
24
Error Control und Proactive Problem Management, erfolgreich ausgeführt werden. Während die Prozesse der ersten beiden Aufgabenbereiche, genauso wie die
des Service Desks bzw. Incident Managements, dann ausgelöst werden, sobald
ein Incident bzw. Problem eintrifft, wird dem Proactive Problem Management
eine besondere Bedeutung zugesprochen und separat behandelt. Doch sollen
zunächst die Bereiche Problem Control und Error Control dargestellt werden.
Abbildung 1.6 verdeutlicht die Zusammenhänge der beiden Aufgabenbereiche,
aber auch die Schnittstelle des Incidents Managements mit dem Problem Management.
„Problem“Control
„Incident“
Problem?
ja
„Error“Control
„Change“
Unknown Error
Identifizieren
& aufzeichnen
nein
Problem
Klassifizierung
Untersuchung &
Diagnose
Known
Error ?
ja
Known Error
Identifizieren
& aufzeichnen
nein
Eskalation
Untersuchung &
Diagnose
Fehler
Beschluss
RfC?
ja
Change
Management
nein
PIR
Problem Closure
Abbildung 1.6: Flussdiagramm-Problem.
Problem Control. Wie bereits schon erwähnt, werden Incidents mit unbekannter Ursache als Problems bezeichnet. Ob es sich tatsächlich um ein Problem handelt, wird, wie aus den Abbildungen 1.4 und 1.6 ersichtlich, bereits im
Incident Management entschieden. Ist dies der Fall, so wird das Problem weitergeleitet. Der Auslöser für den Prozess des Problem Managements ist somit ein
Unknown Error, ein Fehler ohne bekannte Lösung. Ein Ziel des Problem Controls ist es also, aus dem Unknown Error einen Known Error, einen bekannten
Fehler mit Lösung, zu machen und ihn damit, wie das Wort „Control“ bereits
sagt, kontrollieren zu können. Dies geschieht in den nun folgenden Schritten.
25
Unknown Error identifizieren & aufzeichnen: Im ersten Schritt wird der
Unkown Error identifiziert. Es soll herausgefunden werden, um welche Art
von Unknown Error es sich hier handelt, ebenso ob mehrere Incidents an
diesem Unkown Error beteiligt sind, welche Software davon betroffen ist
usw.. Des Weiteren wird der Unknown Error oder auch das Problem in
einem sogenannten Problem Record aufgezeichnet und in einer Datenbank
abgespeichert. Alle Schritte, von dem Zeitpunkt der Feststellung des Problems bis hin zur Beendigung des Problems, werden in diesem Problem
Record und somit in der Datenbank festgehalten.
Problem Klassifizierung: Nachdem das Problem aufgenommen ist, muss es
nun klassifiziert werden. Es wird hier sowohl die Kategorie des Problems
als auch die Priorität des Problems festgelegt. Da diese Klassifizierung
ähnlich zu der Klassifizierung eines Incidents verläuft, soll hier näher darauf eingegangen werden.16
Untersuchung & Diagnose: In den nun folgenden Subprozessen Untersuchung & Diagnose und Eskalation wird nun versucht, aus dem Unknown
Error ein Known Error zu machen und eine Lösung für eventuelle Fehler
zu finden. Die Aufgabe hier ist es „den Problemursachen auf den Grund
zu gehen [...] und dem Service Desk so weit wie möglich Informationen,
Lösungsmöglichkeiten und Workarounds an die Hand zu geben.“ [Olb06,
S. 43] Handelt es sich so dann um einen Known Error, wird dieser dem
Error Control übergeben.
Eskalation: Zur Ermittlung der gerade vorgestellten Lösungen werden Experten herangezogen. Sollte das Wissen dieser Experten nicht ausreichen, es
handelt sich deshalb immer noch um ein ungelöstes Problem, kurz um
einen Unknown Error, so werden weitere Fachkräfte zu Rate gezogen. Es
kommt zu der bereits vorgestellten funktionalen Eskalation.17
Error Control. Nachdem sich das Problem Control mit der Ursache des Problems beschäftigt hat und der Unknown Error zu einem Known Error umgewandelt wurde, befasst sich das Error Control mit der konkreten Beseitigung
des Fehlers. Dies erfolgt in den Schritten:
Known Error identifizieren & aufzeichnen: Zuerst müssen auch die umgewandelten Known Errors identifiziert und aufgezeichnet werden. Natürlich könnte man in diesem Fall mit unnötigen Mehraufwand argumentieren, da bereits sowohl der Incident als auch das Problem identifiziert und
aufgezeichnet wurden, es geht hier allerdings vielmehr um die Verknüpfung
zwischen Known und Unknown Error.
Untersuchung & Diagnose: Nachdem der Fehler bekannt gemacht und dokumentiert wurde, sollen hier die verschiedenen Lösungsmöglichkeiten erarbeitet werden. Die Lösungen können Workarounds oder Requests for
Change sein. Welche der Lösungen genau gewählt wird, erfolgt im nächsten Schritt. Es ist noch anzumerken, dass auch vor der „Untersuchung
16 Vgl.
Abschnitt 1.2.2.
die funktionale Eskalation in dem Abschnitt 1.2.2 behandelt wurde, soll hier nicht
weiter darauf eingegangen werden.
17 Da
26
& Diagnose“ des Known Errors wiederum eine Klassifizierung des Errors
stattfinden kann, da diese aber sehr ähnlich zu der des Unknown Errors
ist, wird sie hier nicht weiter erwähnt.
Fehler Beschluss: In diesem Schritt wird nun eine der erarbeiteten Lösungsmöglickeiten zur Beseitigung des bekannten Fehlers ausgewählt. Handelt
es sich um Workarounds, müssen diese unverzüglich umgesetzt werden.
Im Gegensatz dazu stehen die Requests for Change. Wird nämlich zur
Behebung des bekannten Fehlers eine Änderung einer Komponente des
IT-Bereiches benötigt, so darf das Problem Management diese Änderung
nicht einfach durchführen, sondern muss ein RfC, einen Antrag auf Änderung, an das sogenannte Change Management weiterleiten. Das Change
Management überprüft diesen Antrag auf seine Notwendigkeit und auf
die Auswirkungen, die es im Unternehmen verursacht. Nicht unerwähnt
sollte hier bleiben, dass das Change Management sowohl einem Request
for Change zustimmen als auch ihn ablehnen kann. Bei Anlehnung des
Request for Change muss das Problem Management eine andere Lösung
auswählen und gegebenenfalls einen neuen Request for Change formulieren. Aus diesem Zusammenhang wird deutlich, dass Probleme bzw. Fehler
nicht nur einmal diese Prozesse durchlaufen. Auf Grund ihrer Entwicklung
im Bezug auf Auswirkung im Betrieb und Priorität müssen sie dauerhaft
beobachtet und, wenn nötig, neu bewertet werden.
Post Implementation Review (PIR): Wurden alle notwendigen Änderungen umgesetzt, erfolgt durch das Change Management im Error Control
ein sogenannter Post Implementation Review. Dabei wird geprüft, ob die
vorgegebenen Ziele, wie zum Beispiel die Beseitigung des Fehlers, durch
die Änderung erreicht wurden.
Problem Closure: Nach Abschluss der Prozesse soll in diesem letzten Schritt
überprüft werden, ob die gesamte Historie des Problems tatsächlich erfasst und dokumentiert wurde. Ist dies nicht der Fall, so muss der Record
ergänzt werden.
Proactive Problem Management. Die beiden gerade vorgestellten Aufgabenbereich bzw. Prozesse „Problem Control“ und „Error Control“ sind eher
reaktiver18 Natur. Daher sollte ein Problem resp. Fehler eintreten, so wird auf
diesen reagiert und die Prozesse werden in Gang gesetzt. Ganz anders ist es bei
dem Proactive Problem Management. Hier wird eine Art Voruntersuchung auf
zukünftige Problems und Incidents betrieben, um diese bereits im Voraus zu
vermeiden und gar nicht erst entstehen zu lassen. Dazu werden:
• Problemfelder und Fehlerquellen analysiert. Deshalb werden hier Fragen
untersucht, wie zum Beispiel:
– Kommen dieselben Incidents immer aus derselben Abteilung,
– entsprechen die Fehler immer einem bestimmten Typ von Fehler,
– kann man schon sagen, wo das nächste Problem entstehen wird und
wie es aussieht.
18 reaktiv
(lat.)=rückwirkend; auf Reize reagierend
27
Sind diese Fragen beantwortet, werden:
• Präventivmassnahmen zur Vermeidung von Incidents und Problems vorbereitet. Daher werden hier Möglichkeiten erörtert und ausgearbeitet, die
die Problemfelder und Fehlerquellen beseitigen sollen.19
Ein Beispiel für die beiden Aktivitäten könnte folgendermaßen sein. Angenommen, eine Firma würde die Daten ihrer Kunden auf einem einzigen Computer
speichern. Diese Datensätze würden neben der Anschrift auch den Briefwechsel mit besagtem Kunden enthalten. Durch einen wirtschaftlichen Boom würde
es nun zu einem rasanten Anstieg der Kundenzahl kommen. In diesem Augenblick ist das Problem Management gefragt. Es muss erkennen, dass es durch
eine höhere Anzahl an Kunden zu mehr Datensätzen auf dem Computer kommt
und dieser daher Gefahr läuft, immer wieder abzustürzen, da er mit der großen
Datenmenge nicht mehr einwandfrei arbeiten kann. Als zweiten Schritt muss
das Proaktive Problem Management eine Präventivmassnahme zur Vermeidung
dieses Problems durchführen. Eine Möglichkeit wäre der Kauf eines weiteren
Computers.
Auch wenn das vorangegangene Beispiel recht einfach war, so zeigt es aber die
hohe Anforderung, die an das Problem Management und seinen Mitarbeitern
gestellt wird. Es muss nicht nur ein hohes Fachwissen sondern auch eine Wissensdatenbank, ausführliche Dokumentationen vorangegangener Probleme, eine
ausreichende Anzahl an Programmen usw. vorhanden sein. Des Weiteren wurde
gezeigt, dass im Problem Management nicht nur auf Problems reagiert, sondern
auch diese vorhergesehen und im Voraus vermieden werden sollen. Wer die Änderungen, die vom Problem Management zur Beseitigung bzw. Vermeidung von
Problemen erarbeitet und vorgeschlagen werden, im Endeffekt kontrolliert und
steuert, wird nun im nächsten Kapitel behandelt.
1.2.4
Change Management
Das Change Management befasst sich mit der Kontrolle und Steuerung aller
Änderungen (Changes) innerhalb der IT-Infrastruktur. Da die IT-Komponenten
häufig Änderungen unterworfen sind, besteht die Aufgabe des Change Managements darin, standardisierte Methoden und Verfahren zur Abwicklung und
Überwachung von Änderungen zu entwickeln. Darüber hinaus darf nur das
Change Management autorisierte Änderungen durchführen. Es soll somit eine
ordnungsmäßige Implementierung der Änderung in die IT-Infrastruktur sichergestellt werden und mögliche Störungsrisiken minimiert werden.
Bevor eine Änderung durchgeführt werden kann, muss ein Änderungsantrag, ein
sogenannter Request for Change (RfC), an das Change Management übermittelt
werden. Die Änderung kann sich auf die Bereiche der Hardware-Komponenten,
Kommunikationsgeräte, Anwendungs- und Systemsoftware, Dokumente sowie
Prozeduren beziehen. Im Grunde wird jede beabsichtigte Änderung an Komponenten der IT-Infrastruktur, den sogennanten Configuration Items (CIs)20 ,
19 Allerdings ist hier anzumerken, dass das Problem Management die Präventivmassnahmen nicht einfach durchführen darf. Es müssen zuvor Kosten-Nutzen Rechnungen durchgeführt werden, um zu sehen, ob sich der eingesetzte Aufwand zur Vermeidung von Problemen
überhaupt lohnt.
20 Eine genauere Erklärung eines CIs ist im Abschnitt 1.2.6 zu finden.
28
mit einem RfC an das Change Management übermittelt. Ist zum Beispiel eine Hardware-Komponente defekt, wie die Festplatte, der Monitor oder sogar
der Server, muss dies dem Change Management übermittelt werden, damit eine
Änderung durchgeführt werden kann. Darüber hinaus muss das Change Management entscheiden, welche Änderungen zuerst durchgeführt werden sollen.
So hat die Reparatur eines Servers eine höhere Priorität als ein defekter Monitor. Zu den weiteren Aufgaben, die das Change Management bzw. der Change
Manager erfüllen muss, gehören folgende Punkte:
• Erfassung und Filterung von RfCs,
• Planung und Organisation der Durchführung eines RfC,
• kontinuierliche Überwachung und Kontrolle bei der Durchführung eines
RfC,
• abschließende Revision (PIR)21 .
Ein RfC kann von allen Benutzern der IT versendet werden. Vorteilhaft ist
die elektronische Übermittelung mit Hilfe von standardisierten Anträgen.22 Der
Change Manager entscheidet in einer Vorauswahl, ob ein RfC akzeptiert oder
abgelehnt wird. Ähnlichen RfCs können auch zusammengefasst werden. Jeder
RfC bekommt eine eindeutige Identifikationsnummer zugewiesen und wird dokumentiert. Während der gesamten Durchführungsphase wird jeder einzelne
Schritt eines RfC protokolliert und an die Configuration Management Database (CMDB) 23 übermittelt. Am Ende der Durchführung sollen nach den ITILEmpfehlungen die nachfolgenden Fragen ([TRA07, S. 53]) beantwortet werden
können. Dadurch lässt sich jede Änderung leicht nachvollziehen.
• Wer hat den Änderungsantrag gestellt?
• Was sind die Gründe für die Änderung?
• Welchen Vorteil hat die Änderung?
• Welche Risiken sind mit der Änderung verbunden?
• Welche Ressourcen müssen für die Änderung bereitgestellt werden?
• Wer ist verantwortlich für die Durchführung, Test und Implementierung
der Veränderung?
Ist eine grobe Vorauswahl für die Ausführung einer Änderung getroffen, wird
die Priorität und Kategorie des RfC eingestuft. Die Einstufung erfolgt nach der
Dringlichkeit oder dem Ausmaß bzw. dem Risiko einer Änderung. Hierzu gehört
auch eine Kosten/Nutzen-Rechnung, die mit darüber entscheidet, ob eine Änderungen wirklich durchgeführt werden soll. Des Weiteren müssen Ressourcen für
Änderungen bereitgestellt werden. Zu den Ressourcen gehören unter anderem
Personal, Hardware, Software und finanzielle Mittel.
Handelt es sich um einen RfC mit geringer Priorität, wie zum Beispiel eine Änderung der Zugriffsrechte eines Users oder andere routinemäßigen Aufgaben, so
21 PIR
steht für Post Implementation Review.
können Service Tools eingesetzt werden.
23 Eine genauere Erklärung einer CMDB ist im Abschnitt 1.2.6 zu finden.
22 Hierbei
29
obliegt die Entscheidung der Durchführung allein bei dem Configuration Manager. Bei dieser Art von RfC sind meistens nur ein oder wenige User betroffen
und es ist kein großer Ressourcenaufwand nötig.
Ist es hingegen eine Priorität und Kategorie höherer Stufe, wird das sogenannte
Change Advisory Board (CAB) oder in einigen Fälle sogar das Emergency CAB
(ECAB) einberufen. Das CAB ist zuständig für Änderungen mit mittlerer und
hoher Priorität und Kategorie, wie zum Beispiel die Umstellung des Betriebssystems bei sämtlichen Computern von Windows XP auf Windows Vista. Meist
sind hier mehrere User von den Änderungen betroffen und ein höherer Aufwand
an Ressourcen ist nötig. Das CAB setzt sich aus mehreren Mitgliedern zusammen. Diese können sowohl aus dem Bereich des Incident Managements, Problem
Managements, Service Desks, usw. kommen als auch IT-Experten, etc. sein und
sollten regelmäßig in Kontakt zueinander stehen. Bei größeren Änderungen sollte
auch der jeweilige betroffene Personenkreis mit in die Entscheidung einbezogen
werden. Wird das ECAB einberufen, liegt ein dringendes Problem vor, dass nur
mit hohen Aufwand an Ressourcen zu lösen ist. Dieses Problem betrifft meist alle User und muss sehr schnell behoben werden. Hierzu gehört beispielsweise der
Ausfall des gesamten Netzwerkes. Das ECAB besteht aus wenigen Mitgliedern
des CABs, die stellvertretend für die restlichen Mitglieder schnelle Entscheidungen treffen können. Die Abbildung 1.7 zeigt die einzelnen Schritte, die ein RfC
durchläuft.
Wurde der RfC genehmigt, beginnt die zeitliche Planung der Änderung. Je nach
Dringlichkeit werden die RfC geordnet und die benötigten Ressourcen bereitgestellt. Die Informationen werden an die CMDB übermittelt, so dass sichergestellt ist, dass sich der User über den genauen Bearbeitungsstand des RfC
informieren kann. Im nächsten Schritt werden die für die Umsetzung bzw. für
die Durchführung der Änderungen zuständigen Bereiche kontaktiert. Die Hauptaufgabe des Change Managements besteht nun aus der formalen Koordination
und Überwachung der Änderungen. Es muss darauf geachtet werden, dass die
bereitgestellten Ressourcen ausreichend sind, um den Change planmäßig durchzuführen. Dies geschieht in enger Zusammenarbeit mit dem Release Management, das für die tatsächliche technische Umsetzung der Änderung zuständig
ist. Nach einer Testphase, in der sichergestellt werden soll, dass die Änderungen ordnungsgemäß funktionieren, erfolgt die abschließende Implementierung
der Änderungen. Dies sollte zu einem Zeitpunkt geschehen, bei dem möglichst
wenige andere Prozesse beeinträchtigt werden. Nach der Implementierung sollte nach einiger Zeit eine abschließende Revision (PIR) zur Qualitätssicherung
erfolgen. Es wird dabei festgestellt, ob die Ziele der Änderung erreicht wurden
oder ob unerwünschte Nebeneffekte aufgetreten sind. Aber es wird auch überprüft, inwieweit die eingeplanten Ressourcen ausreichend waren. Mit Hilfe dieser
abschließenden Revision lassen sich mögliche Schwachstellen aufdecken, die bei
zukünftigen ähnlichen Änderungen korrigiert werden können.
Anhand des vorgestellten Schemas sollten sämtliche RfC abgewickelt werden.
Denn nur durch diesen standardisierten Ablauf können Änderungen effizient
durchgeführt und Fehlerquellen minimiert werden. Auf den ersten Blick erscheint es, dass es ein großer Aufwand für den Anwender ist, jede Änderung
eines CI erst durch das Change Management genehmigen zulassen. Denn oftmals lassen sich die Änderungen schnell von dem Anwender selbst durchführen.
Doch es kann dann passieren, dass das IT-System nicht mehr konsistent ist und
das System dadurch nicht mehr fehlerfrei arbeitet. Um dies zu vermeiden, ist es
30
RFC
Change Manager
• RFC filtern
• Priorität festlegen
ablehnen
gering
mittel
Change
Manager
hoch
dringend
CAB/
ECAB
Configuration
Management
(CMDB)
nein
genehmigt ?
ja
Change
planen & durchführen
Release
Management
abschließende
Revision
nein
Erfolg ?
ja
Ende
Abbildung 1.7: RfC-Ablauf.
wichtig, einen RfC an das Change Management zu übermitteln. Um die Systemintegrität der genehmigten Änderungen sicherzustellen, arbeitet das Change
Management eng mit dem Release Management zusammen, das im folgenden
Abschnitt näher erläutert wird.
1.2.5
Release Management
Das Release Management ist für die Bereitstellung, Einführung und Verwaltung von autorisierter Software und Hardware zuständig. Während das Change
Management für die Entwicklung von standardisierten Methoden und Verfahren zur Durchführung und Überwachung von Änderungen verantwortlich ist,
befasst sich das Release Management unter anderem mit der Sicherstellung der
Systemintegrität der Änderungen. Des Weiteren entwickelt das Release Management qualitätssichernde Richtlinien und Grundkonfigurationen zur Installation
von IT-Systemen. Es lässt sich somit festhalten, dass das Release Management
maßgeblich die Verantwortung dafür trägt, dass neue oder veränderte CIs voll
funktionsfähig in die IT-Umgebung implementiert werden. Zu den Hauptaufgaben des Release Managements gehören:
31
• Festlegung der Release Policy,
• enge Zusammenarbeit und inhaltliche Abstimmung mit dem Change Management,
• Planung, Überwachung und Durchführung von Änderungen bzw. Einführungen von Software und Hardware,
• Dokumentation, Verwaltung, Versionierung und Speicherung von genehmigten Releases.
Im Kontext der ITIL wird jedes neue oder veränderte CI, dass von dem Release
Management veröffentlicht wird, als Release bezeichnet. Hierbei können ähnliche Releases auch gebündelt und als Paket veröffentlicht werden. In diesem
Zusammenhang lassen sich drei verschiedene Release-Arten nach ihrem Umfang
unterscheiden:
Full Release: Alle Software- und Hardwarekomponenten werden zusammen
entwickelt, getestet und verteilt.
Delta Release: Es sind nur Komponenten enthalten, die seit dem letzten Release geändert worden sind.
Package Release: Full Releases und Delta Releases werden zu einem Paket
gebündelt und veröffentlicht.
Hilfreich hierbei ist eine zentrale Softwareverteilung, die die Releases auf die relevanten Computer verteilt. Die Implementierung von Releases werden als Rollout bezeichnet. Soll ein bereits implementierter Release wieder entfernt werden,
wird dies als Rollin beschrieben.
Um sicherzustellen, dass bei einem fehlerhaften Release immer auf eine lauffähige Version einer Software zurückgegriffen werden kann, verwaltet das Release
Management die Definitive Software Library (DSL). Es handelt sich dabei um
eine Datenbank auf der sich sämtliche autorisierte Software befindet. Mit Hilfe
des Backup-Systems bzw. Repository kann auf eine lauffähige Sofwareversion
zurückgegriffen werden. Darüber hinaus werden in der DSL auch die Softwarelizenzen verwaltet. Die DSL ist in die CMDB des Configuration Managements
implementiert, untersteht aber der Kontrolle des Release Managements. Dieses
verwaltet auch den Definitive Hardware Store (DHS). Es handelt sich dabei um
ein Lager mit wichtigen Hardwarekomponenten. Auf Grund der hohen Kosten
einer Vorratshaltung sollten nur kritische Komponenten als Ersatz gelagert werden. Die Informationen, an welcher Stelle die Ersatzteile gelagert sind, werden
in der CMDB gespeichert.
Mit Hilfe von Abbildung 1.8 soll auf die wichtigsten Aufgaben des Release Managements eingegangen werden. Wie aus ihr ersichtlich wird, sind die Aufgabenbereiche des Release Managements in die Entwicklungs-, Test- und Produktionsumgebung integriert. Dadurch wird sichergestellt, dass die Releases fehlerfrei
in das IT-System implementiert werden. Wie der allgemeine Vorgang eines Releases durchgeführt wird, hängt von der Release Policy ab. Die Release Policy
bestimmt die Richtlinien für die Bearbeitung und Dokumentation eines Release
und ist als Leitfaden für die weitere Bearbeitung zu verstehen. Wird ein autorisierter RfC an das Release Management übermittelt, beginnen die Planungen
32
Entwicklungsumgebung
Testumgebung
Produktionsumgebung
Release Management
Release
Politik
Planung
Entwicklung/
Bestellung
Erstellung/
Konfiguration
Testphase/
Akzeptanz
Rolloutplanung
Information/
Training
Installation
Configuration Management
CMDB
DSL
Informationen über den DHS
Abbildung 1.8: Release Management.
für die Änderungen. Dies geschieht in enger Zusammenarbeit mit dem Change
Management.
So müssen Releaseinhalte, Prioritäten, benötigten Ressourcen, Notfallpläne usw.
festgelegt werden, um eine schnelle Umsetzung zu gewährleisten. Im nächsten
Schritt wird der Release entwickelt. Handelt es sich bei dem Release um eine Softwareänderung, muss sichergestellt sein, dass sich eine lauffähige Version der Software auf der DSL befindet. Anschließend sollte der Release in eine
realitätsnahe Testumgebung implementiert werden, um die Systemintegrität zu
überprüfen. Wenn der Release die Anforderungen erfüllt, beginnen die Planungen für den Rollout. Dieser Schritt umfasst die Terminplanung und Koordination der Implemetierung des Release in die Produktionsumgebung. Bevor der
Release veröffentlicht wird, sollten die betroffenen User über die Änderungen
unterrichtet werden. Im letzten Schritt erfolgt die endgültige Verteilung und
Implementation des Release. Sämtliche Schritte werden dokumentiert und dem
Configuration Management übermittelt. Dadurch lassen sich die Änderungen
und deren Auswirkungen nachvollziehen und gegebenenfalls korrigieren. Die weiteren Aufgaben des Configuration Managements werden im folgenden Abschnitt
erläutert.
1.2.6
Das Configuration Management stellt eine wichtige Komponente im Bereich der
Service Support-Prozesse dar. Aufgabe des Configuration Managements ist es,
den anderen ITIL-Prozessen Informationen über die IT-Infrastruktur bereitzustellen. Somit fungiert das Configuration Management unter anderem als Datenbank. Wichtig hierbei ist, dass sich die Informationen auf dem aktuellsten Stand
befinden. Um dies zu gewährleisten, muss jede Veränderung der IT-Infrastruktur
33
durch das Change Management bzw. das Release Management an das Configuration Management übermittelt werden. Zu den Veränderungen zählen neben
Modifikationen an Komponenten der Hardware und Software auch Änderungen
an Dokumenten.24
Anhand der Abbildung 1.9 wird die zentrale Bedeutung des Configuration Managements und die wechselseitige Beziehung zu den anderen ITIL Support Prozessen verdeutlicht.
Change
Management
Incident
Management
Configuration
Management
Problem
Management
Release
Management
Informationsfluss
Abbildung 1.9: Informationsfluss Configuration Management und Service Support Prozesse.
Alle Komponenten, die in der IT-Infrastruktur von dem Configuration Management erfasst werden, bezeichnet man als Configuration Item (CI). Die CIs
werden in einer zentralen Datenbank, der sogenannten Configuration Management Database (CMDB), gespeichert und verwaltet. Die Besonderheit bei der
CMDB ist, dass sie nicht bloß die einzelnen CIs speichert, wie es bei einer Bestandsdatenbank der Fall ist, sondern ebenfalls deren Verflechtungen zueinander
widerspiegelt. Ein CI setzt sich oft aus mehreren CIs zusammen. So besteht ein
Computer, der auch ein CI ist, aus einer Festplatte, CD-Rom, Netzwerkkarte,
Software usw., die ebenfalls einzelne CIs sind. Der Computer ist natürlich auch
nur ein Bestandteil eines höher geordneten CIs.
Auf Grund dieser vielfältigen Verflechtungen ist es wichtig, jedem CI eine eindeutige Identifikationsnummer zuzuteilen, um einen Überblick über alle CIs sicherzustellen. Des Weiteren müssen zu jedem CI die wichtigsten Eigenschaften
resp. Attribute gespeichert werden. Ein Vorteil dieses Aufbaus der CMDB ist,
dass bei einer Störung oder bei einem Ausfall eines CIs genau nachvollzogen
werden kann, welche Komponenten mitbetroffen sind. Da auch Änderungen, In24 Zu den Dokumenten zählen zum Beispiel Problem- und Fehlerbehebungs-Beschreibungen,
Installationsanleitungen, usw..
34
cidents, Problems, Known Errors und Releases und deren Beziehungen als CIs
gespeichert sind, ist eine effiziente Fehlerbehebung möglich.
Abbildung 3.6 zeigt eine vereinfachte Darstellung der Struktur der CIs und deren
Eigenschaften.
CMDB
Hardware
Software
Dokumentation
ComputerID:1234
Prozessor : Intel Core
2 GH
HD
: 60 GB
Software : MS Vista
MS Office
Monitor
: LCD
usw.
CI
Abbildung 1.10: CI-Verflechtung in der CMDB.
Zusätzlich ist innerhalb der CMDB die Definitive Software Library (DSL) 25 implementiert. Darüber hinaus sind die Informationen über den Definitive Hardware Store (DHS), die von dem Release Management verwaltet werden, auf
der CMDB gespeichert. Aus diesem Zusammenhang wird ersichtlich, dass die
CMDB ein zentraler Punkt hoher Komplexität ist. Um diese Arbeit zu bewältigen, müssen folgende Aufgaben von dem Configuration Management bzw. von
der Rolle des Configuration Managers erfüllt werden:
Aufbau und Planung des Configuration Managements: Pläne und Prozeduren für sämtliche Aktivitäten des Configuration Managements müssen
festgelegt werden. Dieser Punkt umfasst unter anderem auch die Definition der CIs und eine einheitliche Namenskonvention der CIs, dadurch soll
ein konsistenter Zustand der Datenbanken sichergestellt werden. Des Weiteren muss der Umfang und die Struktur der CMDB festgesetzt werden,
zum Beispiel die Festlegung der Speicherkapazitäten der CMDB und der
DSL. Um ein effizientes Arbeiten zu ermöglichen, müssen auch geeignete Configuration Management-Tools implementiert werden, die die Arbeit
mit den Datenbanken erleichtern sollen. Da im Zeitablauf der Arbeitsauf25 Zur
Erklärung vgl. Abschnitt 1.2.5.
35
wand wächst, sollte durch einen regelmäßigen Soll/Ist-Abgleich sichergestellt sein, dass die zur Verfügung gestellten Ressourcen ausreichend sind.
Identifikation der CIs: Eine wesentliche Komponente bei der Identifizierung
der CIs ist das Maß der Differenzierung der IT-Infrastruktur. So ist der
Aufwand abhängig von der Definition der CIs. Soll zum Beispiel ein PC inkl. Maus, Tastatur und Monitor ein einzelnes CI darstellen oder sollen die
Bestandteile auch als CIs definiert sein? Diesen Fragen werden zuvor bei
dem Aufbau und der Planung des Configuration Managements geklärt. Je
nach Maß der Differenzierung muss die IT-Infrastruktur in ihre Bestandteile zerlegt werden und sämtliche CIs erfasst werden. Zu den möglichen
CIs gehören beispielsweise die Hardware, Software, Dokumentationen der
Systemkonfiguration, RfC, Dokumentationen über Änderungen und Abweichungen, Fehlerbehebungs-Beschreibungen, usw..
Kontrolle der CIs: Das Configuraion Management sorgt dafür, dass sich nur
autorisierte und aktuelle Einträge über die CIs in der CMDB befinden.
Um dieses zu gewährleisten, gehört dazu die Registrierung neuer CIs, die
Aktualisierung bestehender CIs, Lizenz-Kontrollen, Kontrolle der DSL,
usw..
Statusinformationen über die CIs: Über den gesamten Einsatzzeitraum eines CIs werden Berichte mit allen relevanten Informationen und dem aktuellen Zustand angefertigt. Auf diese Weise können die anderen Service
Support-Prozesse immer auf aktuelle Informationen zurückgreifen.
Verifizierung und Audits: Damit die Aktualität der CMDB sichergestellt
ist, müssen die gespeicherten Daten in regelmäßigen Abständen überprüft
werden. Bei dieser Verifizierung bzw. Audit wird festgestellt, ob die gespeicherten Daten der CIs die aktuellen Daten der CIs widerspiegeln. Sollte
dies nicht mehr der Fall sein, wird ein RfC mit Hilfe des Change Managements und Release Managements durchgeführt.
Abbildung 1.2.6 zeigt die Aufgabenbereiche und die Schnittstellen des Configuration Managements mit den anderen Service Support-Prozessen anhand eines
Incidents.
Bei der Registrierung eines Incidents sendet das Incident Management die Daten zu der CMDB. Falls es sich um einen bekannten Fehler handelt und dazu
Lösungskonzepte oder andere Details existieren, stellt die CMDB diese bereit.
Wird nur eine temporäre oder keine Lösung erreicht, wird der Vorfall an das
Problem Management weitergereicht. Auch hier findet ein Austausch von Daten
statt. So stellt die CMDB dem Problem Management wichtige Informationen
über die Verflechtung der betroffenen CIs und weitere relevante Daten zur Verfügung, um eine schnelle Lösung zu gewährleisten. Wird das Problem erkannt und
zu einem Known Error, wird dies der CMDB übermittelt. Um das Problem zu
lösen, wird ein RfC an das Change Management weitergeleitet. In enger Zusammenarbeit mit dem Release Management werden die notwendigen Änderungen
durchgeführt und an die CMDB übermittelt.
Mit Hilfe des Configuration Managements und den dazugehörigen Komponenten sollte es möglich sein, die Effizienz und die Effektivität der IT-Organisation
zu steigern. Es eignen sich verschiedene Vorgehensweisen für die Einführung
36
Service Desk
Start
Incident
Management
Incident
Problem
Problem
Management
Known Error
Request
for Change
C
M
D
B
Configuration
Management
(inkl. DSL
und Info.
DHS)
Autorisierter
Change
Change
und
Release
Management
Change
ausgeführt
Ende
Abbildung 1.11: Schnittstelle zwischen CM und andere Service
Support Prozesse. Quelle: Eigene Darstellung in Anlehnung an
[Vic05, S. 56]
eines Configuration Managements. Von Vorteil ist es, wenn von Anfang an eine ITIL konforme Implementierung erfolgt, denn dadurch verringert sich der
Arbeitsaufwand. Natürlich ist eine schrittweise Einführung möglich, die Vorraussetzung dafür ist aber eine genaue IST-Analyse der IT-Infrastruktur. Ein
Hinderungsgrund für einen reibungslosen Ablauf des Prozesses ist oft die fehlende Akzeptanz der Mitarbeiter. Sie müssen jede Veränderung der IT an das
Configuration Management weitergeben, oftmals erscheint ihnen dies als zu bürokratisch. Es ist aber eine Notwendigkeit, um eine aktuelle CMDB und die
damit verbundenen Vorteile zu garantieren.
Im nächsten Kapitel erfolgt eine Untersuchung des aktuellen IT-Managements
bzw. Service Supports an der Universität Bielefeld anhand der Fakultät für
Wirtschaftswissenschaften und der Fakultät für Rechtswissenschaft. Das Ziel soll
es sein, mit Hilfe des in Kapitel 2 vorgestellten idealtypischen Verlaufes des ITIL
Service Supports die Möglichkeit der Implementierung eines ITIL konformen
Service Supports an der Universität Bielefeld darzustellen.
1.3
37
Untersuchung des IT-Managements in der
In diesem Kapitel soll der Service Support anhand von zwei ausgewählten Fakultäten untersucht werden. Es wird sowohl die Fakultät für Wirtschaftswissenschaften als auch die Fakultät für Rechtswissenschaft betrachtet. Zu diesem
Zweck haben wir mit den System-Administratoren der jeweiligen Fakultät Gespräche geführt. Der Fragenkatalog wurde in die einzelnen Prozesse bezüglich
des Service Supports gegliedert. Grundsätzlich kann man die IT der beiden Fakultäten nicht in die Funktion des Service Desks und die einzelnen Prozesse
einteilen, da die Aufgaben und Zuständigkeiten der einzelnen Mitarbeiter nicht
klar abgegrenzt sind, dennoch wird dies hier versucht. Dementsprechend kann
auch nicht von den unterschiedlichen „Rollen“ der einzelnen Prozesse gesprochen werden.
1.3.1
Fakultät für Wirtschaftswissenschaften
Zuerst wird der Aufbau der IT in der Fakultät für Wirtschaftswissenschaften
beschrieben. Die Fakultät für Wirtschaftswissenschaften betreibt ihre lokalen
Netzwerke mit minimalem Personalaufwand. Die wesentlichen Aufgaben sind
die Sicherstellung des reibungslosen Betriebs zentraler Komponenten (Server)
und die Pflege der Infrastruktur (Hardware).
Service Desk. Wie im Kapitel 1.2.1 beschrieben wird, soll der Service Desk
nach ITIL als ein „Single Point of Contact“ für die Kommunikation mit dem
Endanwender verantwortlich sein. Auch die Administratoren der Fakultät für
Wirtschaftswissenschaften sind die einzigen Ansprechpartner für sämtliche Incidents, Problems und Request for Changes bezüglich der Hardware und Software,
zumindest sollten sie dies sein. Die Kontaktaufnahme mit den Administratoren
erfolgt über verschiedene Weisen, zum einen kommen die User persönlich bei ihnen im Büro vorbei, zum anderen teilen sie ihnen telefonisch oder auch per eMail
den Vorfall mit. Dies kann auch in mehrfacher Form geschehen. Wenn möglich,
sollten die Probleme und Fehler mit möglichst genauer Beschreibung per eMail
an die Systembetreuer gesendet werden. Auf Grund der geringen Anzahl an
Mitarbeitern kann jedoch nicht zwischen First Level Support oder Second Level
Support unterschieden werden.
Incident Management. Bei Meldung eines Incidents sollte prinzipiell kein
Unterschied gemacht werden, wer den Vorfall meldet. Dennoch muss im Nachhinein differenziert werden, welchen Status der User innerhalb der Fakultät
innehat. Außerdem kann es von den persönlichen Vorlieben des Mitarbeiters
abhängen.
Dieses kann am Beispiel „Drucker“ betrachtet werden. Es sind in der Fakultät
zwei unterschiedliche Kategorien an Druckern vorhanden, es gibt sowohl Bürodrucker, die lokal an einem Computer angeschlossen sind, als auch Netzwerkdrucker, die von mehreren Personen genutzt werden. Auf Grund der Nutzung
von mehreren Personen genießen die Netzwerkdrucker einen wesentlich höheren
Support als die Bürodrucker, deshalb haben Netzwerkdrucker auch eine hohe
38
Priorität. Generell kann also gesagt werden, dass Vorfälle genau dann eine höhere Priorität haben, wenn mehrere User davon betroffen sind, als wenn nur ein
einzelner von dem Incident betroffen ist.
Die Priorität kann in drei unterschiedliche Kategorien eingeteilt werden, Incidents können hoch, mittel oder niedrig eingestuft werden. Grundsätzlich werden
die meisten Vorfälle bei Auftreten oder bei Meldung erstmal hoch eingestuft.
Nach einer kurzen Beschäftigung mit dem Incident wird der Vorfall eventuell
neu priorisiert, da bemerkt wird, dass dieser für den Moment nicht so wichtig ist. Wartet man zum Beispiel auf die Lieferung eines Ersatzteils, so stellt
man den Incident zurück und behaftet ihn mit einer Information, dass auf den
Lieferungeingang gewartet wird.
Zu den einzelnen Incidents werden unterschiedliche Informationen abgespeichert, nicht nur Informationen zu dem User und dessen Computer, sondern
auch zum Beispiel der letzte Bearbeiter.
Auf Nachfrage bekommen die User, die ein Incident vorliegen haben, eine Übersicht über den Stand der Dinge. Auch bei Bestellungen wird der User darüber
informiert, dass zum Beispiel die Bestellung aufgegeben wurde und wann mit
einer Lieferung zu rechnen ist. Jedoch reagieren oftmals die Kunden ganz unterschiedlich, die einen möchten auf dem Laufenden gehalten, den anderen reicht
die Meldung, dass sich darum gekümmert wird.
Problem Management. Nach ITIL wird zwischen „Incident“ und „Problem“ unterschieden, ein Problem ist schwerwiegender als ein Incident. Bei den
Administratoren der Fakultät für Wirtschaftswissenschaften gibt es eine solche Unterscheidung nicht. Auf den Computern in der Fakultät wird StandardSoftware installiert. Dennoch möchten manche User eine spezielle Software auf
ihren Computern haben, treten bei diesen dann Fehler auf, so ist der Supportlevel von den Administratoren sehr gering. Es wird bei Anschaffung darauf hingewiesen, dass bei eventuellen Problemen mit der Software keine Unterstützung
durch die Administratoren gewährleistet werden kann. Tritt ein Fehler oder ein
Problem bei einer Standard-Software, verfügen sie über eine selbst angeeigneten
Wissensbasis. Dennoch kann man auch Hilfe im Internet oder in verschiedenen
Administratoren-Foren finden, da die Standard-Software oftmals eine sehr verbreitete Software ist. Ist trotzdem zu einem gewissen Zeitpunkt der Support
nicht mehr möglich, so wird der Hersteller der Hardware oder Software kontaktiert. Dies kommt jedoch in den seltensten Fällen vor. Um Fehler oder Probleme
an der Software im Voraus zu verhindern, wird, sobald sich Software in einer
neuen Version auf dem Markt befindet, diese getestet und überprüft. Damit die
Schadensbegrenzung so gering wie möglich zu halten, wird eine Empfehlung zur
Nichtnutzung der bestimmten Software ausgesprochen.
Change Management. In Bezug auf finanzielle Mittel sind alle Lehrstühle
der Fakultät für Wirtschaftswissenschaften selbst verwaltet, also alle haben ein
eigenes Budget, das ihnen frei zur Verfügung steht. Dieses wird von der Fakultätsverwaltung verwaltet, jedoch hat die Fakultätsverwaltung kein technisches
Know-How bezüglich der Software oder Hardware. Aus diesem Grund können
die Administratoren nur leiten und beratend eingreifen, was die Beschaffungen
betrifft, haben aber keinen direkten Einfluss darauf. Sie haben nicht die Möglichkeit, zum Beispiel „unvernünftige “ Beschaffungen, die von den Lehrstühlen
39
gewünscht werden, zu verhindern. Auch bezüglich der Hardware besteht ein
Standard, der eingehalten werden soll. Da man sich bereits Kenntnisse über
die standardisierte Hardware angeeignet hat, kann so Zeit eingespart werden,
die man unnötig vergeuden würde, wenn man sich ständig mit unterschiedlicher
Hardware auseinandersetzen müsste.
An erster Stelle steht das HRZ, das Empfehlungen bezüglich der Hardware oder
Software herausgibt. Bevor die Software den Usern angeboten wird, wird die
Lauffähigkeit im universitären Umfeld getestet, wie sie im universitären Umfeld
läuft, vor allem mit dem Server.
Die PC-Nutzer verfügen in der Regel keine Administratoren-Rechte, sie haben
nur Hauptbenutzer-Rechte.
Release Management. Die Administratoren sind sowohl für Beschaffung,
Installation, Wartung und Entsorgung Hardware als auch für Beschaffung, Installation und Pflege von System- und Anwendungssoftware zuständig. Sie können Hardware oder Software kostengünstig beschaffen, außerdem können die
Beschaffungen dann auch gebündelt werden. die Administratoren können beratend eingreifen, da innerhalb der Fakultät bezüglich Hardware und Software
gewisse Standards eingehalten werden sollen.
Die Computer-Arbeitsplätze werden für die Benutzer funktionsfähig eingerichtet. Die Erstinstallation umfasst das HRZ-Basic-Bundle. Im Hochschulrechenzentrum (HRZ) wird ein Software-Bundle bereit gestellt, das es in zwei unterschiedlichen Ausführungen gibt. Dies ist zum einen das Basic-Bundle und zum
anderen das Classic-Bundle, das das Basic-Bundle beinhaltet. Die Konfiguration, die Implementierung und die Beratung der HRZ PC-Services in der Fakultät
sollte durch die Administratoren mit beratender Unterstützung durch das HRZ
geschehen. Die Software wird ausschließlich von den Administratoren beschafft
und installiert. Sonstige Software aus dem Classic-Bundle und weitere Installationen, die nicht aus dem Bundle stammen, werden per Antrag auf Kosten des
betreffenden Lehrstuhls beschafft. Bei gekaufter Software ist der Lizenznehmer
immer die Fakultät, die Kopien und die Originalen werden bei den Administratoren aufbewahrt. Sie sind also Ansprechpartner für Softwareangelegenheiten,
außer es wird spezielle Software genutzt, die zum Beispiel aus dem HRZ-ClassicBundle kommt.
Bei einem Backup-System oder einer Repository muss man zwischen ProgrammDateien und User-Dateien unterscheiden. Jeder Benutzer sollte aus Sicherheitsgründen seine eigenen User-Dateien auf der persönlichen Home Directory speichern, da sich dieses Laufwerk auf den Servern des HRZ befindet und täglich
gesichert wird. Außerdem befinden sich mehrere Versionen der User-Dateien auf
den Servern.
Bei Problemen in der Konfiguration, die durch fehlerhafte Programme ausgelöst
werden, werden diese gelöscht und anschließend neu installiert. Es gibt also kein
sogenanntes Lifecycle-Management.
In der ITIL gibt es den sogenannten Definitive Hardware Store (DHS). Hierbei
handelt es sich um ein Lager mit wichtigen Hardwarekomponenten. Aus Platzgründen wird Hardware nicht gelagert, sondern erst bei Bedarf beschafft, dann
für den Einsatz vorbereitet und kommt dann zu dem Endnutzer. Es sind nur
Standard-Sachen in geringer Anzahl vorhanden, wie zum Beispiel Tastaturen,
Computer-Mäuse, Laufwerke etc. Da die Administratoren für die Netzwerkdru-
40
cker zuständig sind, müssen sie sich auch um Toner für diese kümmern und ein
paar auf Lager haben.
Configuration Management. Die Computer, die für die Fakultät beschafft
werden, werden zentral von der Universität verwaltet, deshalb werden sie einer
sogenannten Inventarisierungsnummer zugeordnet. Dies wird mit jedem Rechner gehandhabt. Außerdem wird in der Universitätsverwaltung dokumentiert,
wer den Rechner nutzt, wo dieser steht, etc.. Auch die Administratoren haben
eine solche Datenbank, in der neben den bereits oben erwähnten alle sonstigen
Informationen bezüglich der Hardware und Software gespeichert werden.
1.3.2
Fakultät für Rechtswissenschaft
Die Fakultät für Rechtswissenschaft hat eine ähnliche IT wie die Fakultät für
die Wirtschaftswissenschaften. Jedoch ist sie nicht an die Active Directory des
HRZ angeschlossen, sondern sie betreibt ihre eigene Domäne26 .
Service Desk. Auch in der Fakultät für Rechtswissenschaften existiert teilweise ein Service Desk. Die EDV ist täglich von zwei Personen besetzt, eine
Vollzeitkraft und eine studentische Hilfskraft. Einer von beiden ist im Büro
anzutreffen und arbeitet organisatorisch, der andere erledigt die Problembehandlung an den Lehrstühlen. Auch hier werden Incidents oder Requests for
Change durch die übliche Art und Weise an die EDV-Betreuer herangetragen,
sprich persönlich, durch einen Anruf oder per eMail. Es soll aber vornehmlich
per eMail mit den EDV-Betreuern Kontakt aufgenommen werden. Eine Unterscheidung zwischen einem First Level Support und einem Second Level Support
kann man an dieser Stelle auch nicht entdecken. Der Third Level Support sind
Anfragen an den Hersteller der Software oder Hardware.
Incident Management. Generell wird bei der Meldung eines Incidents keine Unterschiede gemacht, wer den Incident meldet, jedoch hängt es auch hier
sehr von dem Status in der Fakultät ab. Ein Professor bzw. seine Sekretärin
genießen klar Vorrang. Trotzdessen wird aber auch festzustellen versucht, wie
sehr der Incident den Arbeitsfähigkeit der Person einschränkt, also wie hoch der
Arbeitsausfall ist.
Momentan läuft die Aufnahme eines Incidents größtenteils über eMail ab, sprich
man schreibt den Kollegen und somit auch sich selbst eine eMail, in der dann
nähere Details zu dem Incident stehen und was gemacht werden soll. Nach Abhandlung des Incidents wird die dazugehörige eMail in einen anderen Ordner
geschoben. Es werden weder irgendwelche Daten erfasst noch wird dokumentiert, wie hoch der Zeitaufwand war, es gibt also weder den sogenannten Incident Record noch den Problem Record. Es soll aber ein Open Ticket Request
System (OTRS) eingeführt werden, mit dem sich dann Probleme und Anfragen
bearbeiten lassen. Außerdem existiert ein internes Wiki27 . Es dient nicht nur als
26 Eine Domäne ist ein Server zur zentralen Authentifizierung und Autorisierung von Computern und Benutzern in einem Rechnernetz.
27 Unter einem Wiki versteht man eine Sammlung von Webseiten, die nicht nur gelesen,
sondern auch online verändert werden kann. Dabei kann auch auf frühere Versionen zurückgegriffen werden.
41
organisatorische sondern auch als technische Datenbank, in der jedoch nur Probleme, die häufiger auftreten, und ihre Problembehandlung eingetragen werden.
Alles kann nicht streng dokumentiert werden, da es oft zu zeitintensiv ist.
Einmal die Woche findet eine EDV-Besprechung statt, in der dann auch Probleme besprochen werden und Lösungsvorschläge gemacht werden. Bei der Behandlung von Problemen an der Software dienen zum Beispiel Mailinglisten der
Open Source Produkte als Hilfe, manchmal wird auch Rücksprache mit dem
HRZ getroffen. Bei Hardwareproblemen lässt man einen Techniker des passenden Herstellers kommen.
Problem Management. Auch für die Fakultät für Rechtswissenschaft gibt
es eine Standardsoftware-Installation. Bei speziellen Wünschen bezüglich der
Software wird die sich auf dem Markt befindliche Software gesichtet, so dass
dann eine als Standardsoftware definiert. Für eine Aufgabenstellung gibt es jeweils auch nur eine Standardsoftware. Wird eine andere Software für die gleiche
Aufgabe gewünscht, so muss man sich mit der Standardsoftware begnügen. So
lassen sich Probleme an der Software schneller beheben, da jeder Computer an
der Fakultät mit der gleichen Software ausgestattet ist.
Die Benutzer haben keine Administratoren-Rechte, sie können daher auch keine
Software installieren, die in die Registry eingreift.
Change Management. Das Geld, das den Lehrstühlen zur Verfügung steht,
wird auch hier zentral verwaltet. Hardware wird von der EDV beschafft, es gibt
eine Standard-PC-Ausstattung. Bis zu einem Betrag von 200 Euro kann alles
sofort beschafft werden, alles andere läuft über die Beschaffungsstelle der Fakultät. Diese leitet es dann an die Zentrale Beschaffungsstelle der Universität.
Extrawünsche werden mit einer Empfehlung der EDV an die Verwaltung weitergeleitet, jedoch werden diese oft abgeblockt. Es wird versucht, den PC-Pool
möglichst identisch zu halten.
Die Softwareeinführung, zum Beispiel die Einführung einer neuen WindowsVersion, wird durch die Lehrkörperkonferenz abgehandelt. Zuerst wird mit dem
DV-Beauftragten kommuniziert, dieser stellt dann das Vorhaben in der Lehrkörperkonferenz vor. Es muss von der ganzen Fakultät beschlossen, damit es
auch Akzeptanz findet. Auch in diesem Fall spielt das Geld eine große Rolle,
denn man wird angehalten, Geld zu sparen.
Release Management. Keiner der Fakultätsmitarbeiter darf Software kaufen, denn dafür ist die EDV-Abteilung zuständig. Es muss ein Beschaffungsauftrag gestellt werden, der dann an das Dispatching des HRZ weitergeleitet wird.
Es wird immer nur das bestellt, was momentan benötigt wird, es wird also nicht
auf Vorrat gekauft.
Für die Installation von Software gibt es ein System zum Rollout der Software.
Vorher kann festgelegt werden, ob alle Lehrstühle oder nur bestimmte Lehrstühle die neue Software oder -version bekommen. Meistens wird die Software
vor dem Rollout auf den Rechnern in der EDV getestet. Wird sie als lauffähig identifiziert, so wird sie zuerst auf die Computer eines Lehrstuhls ausgerollt.
Falls dann keinen Beschwerden kommen, bekommen auch die übrigen Lehrstühle die Software. So wird der Software-Pool auf dem aktuellsten Stand gehalten,
zumindest die gängige Software.
42
Da die Fakultät für Rechtswissenschaft, wie bereits schon erwähnt, ihre eigene
Domäne betreibt, werden die Daten des Benutzers auf den Rechnern gespeichert.
Jeder Benutzer hat sein eigenes Benutzerprofil, ein sogenanntes „Roaming-UserProfile“ , er kann damit an jedem Computer in der Fakultät auf seine persönliche
Benutzeroberfläche und seine Daten zurückgreifen. Bei Abmeldung des Benutzers vom System wird alles wieder zurück auf den Server geschrieben. Einmal
in der Nacht wird dann ein Backup gemacht.
Configuration Management. Das System zum Rollout der Software inventarisiert jeden Computer. Es kann also genau festgestellt werden, welche Software sich auf welchem Rechner befindet. Durch ein Suchfunktion in dem System wird manchmal geschaut, ob unerlaubte Software, wie zum Beispiel Instant
Messenger, auf den Rechnern vorhanden ist. Bei Eintreten dieses Falls wird der
Benutzer darüber aufgeklärt und die Software umgehend entfernt. Es gibt aber
dennoch Informationen, die nicht automatisch in dem Inventarisierungsclient
auftauchen, diese müssen nachträglich per Hand eingegeben werden. Zu diesen Informationen gehören zum Beispiel der Standort des Rechners, an welcher
Netzwerkdose der Rechner angeschlossen ist, außerdem wird die Inventarisierungsnummer, die die Universität verteilt, und das Anschaffungsdatum verwaltet. Man weiß also zum Beispiel auch, an welchem Rechner welcher Bildschirm
angeschlossen ist.
Neben dem Domäne-Server existieren noch zwei weitere Server, ein Web-Server
und ein Backup-Server. Wenn der Domäne-Server ausfällt, steht die Arbeit in
der gesamten Fakultät stillt. Alle drei Server werden durch ein MonitoringSystem bewacht. Die EDV-Betreuer werden per SMS und per eMail über den
Ausfall eines Servers oder womöglich aller Server informiert.
Im Allgemeinen gibt es keinen Überblick über alle Lizenzen, die in der Fakultät
vorhanden sind. In dem vorhandenen Wiki kann nachvollzogen werden, welcher
Lehrstuhl welche Software-Lizenz eingekauft hat bzw. einkaufen lassen hat.
1.3.3
Kritik und Empfehlung
Bevor auf Kritik und Empfehlungen eingegangen wird, soll noch einmal der
Grundgedanke von ITIL aufgezeigt werden. Denn daran wird die Problematik
für die Einführung eines ITIL-konformen Service Supports an einer Universität
verdeutlicht.
Im Vordergrund bei der Implementierung von ITIL steht, wie bereits erwähnt,
im Allgemeinen die Verbesserung des IT-Service Managements. Dies ist in erster Linie für Unternehmen besonders im Hinblick auf Wirtschaftlichkeit von
enormer Bedeutung. Insbesondere geht es dabei um die Verbesserung des Kundenservices und der effizienten Strukturierung der IT-Infrastruktur. In einer
Universität haben solche Faktoren in der Regel einen nicht so hohen Stellenwert.
Wie in Kapitel 1.2 dargelegt wurde, basiert der Service Support nach ITIL
auf festgelegten Strukturen und Arbeitsabläufen. Es ist somit ein hohes Maß
an Standardisierung und eine exakte Rollenverteilung resp. Arbeitsaufteilung
notwendig, um die Vorteile der ITIL-Prozesse zu nutzen. Entsprechend müssen dafür auch genügend Ressourcen in Form von Arbeitsplätzen, finanziellen
Mitteln etc. bereitgestellt werden.
43
Anhand des im vorangegangenen Abschnittes dargestellten IST-Zustandes des
IT-Managements der beiden Fakultäten ist es offensichtlich, dass die Implementierung eines ITIL-konformen Service Supports an der Universität Bielefeld sich
als äußerst schwierig erweisen würde und nur mit einem großem Arbeits- und
Kostenaufwand zu realisieren wäre.
Im einzelnen zeigt sich die Problematik für eine Einführung von ITIL-konformen
Prozessen bereits bei der allgemeinen Zusammenarbeit der EDV-Abteilungen
der einzelnen Fakultäten. Im Grunde ist jede EDV-Abteilung autark und für
die IT-Struktur der jeweiligen Fakultät verantwortlich. Die Probleme, die mit
diesem Sachverhalt zusammenhängen, werden im Verlauf dieses Abschnittes anhand der verschiedenen Prozessen des Service Supports näher erläutert. Ein
weiteres Umsetzungsproblem besteht darin, dass auf Grund der geringen personellen Größe der einzelnen EDV-Abteilungen die Mitarbeiter sich fast alle
Aufgaben teilen und es dadurch nicht möglich ist, die verschiedenen Rollen resp. Aufgabenbereiche klar voneinander abzugrenzen.
Im Folgendem werden aufbauend auf der Kritik mögliche Verbesserungsvorschläge nach ITIL-Empfehlungen dargestellt. Es wird hierbei auf die Service
Support-Funktion Service Desk bzw. -Prozesse Incident Management, Problem
Management, Change Management, Release Management und Configuration
Management im Einzelnen eingegangen. Es soll aber nicht das Ziel sein, sämtliche Punkte des Service Supports nach ITIL auf die Universität zu übertragen,
sondern nur solche, die sinnvoll erscheinen. Des Weiteren werden manche Punkte
zusammengefasst, da eine klare Abgrenzung auf Grund der geringen personellen
Größe der Abteilungen oftmals nicht möglich ist.
Service Desk, Incident und Problem Management. Nach ITIL dient
der Service Desk als zentrale Kommunikationsschnittstelle zwischen Usern und
Support. Die Architektur des Service Desks an der Universität Bielefeld entspricht dem eines lokalen Service Desk. Dies lässt sich damit begründen, dass
jede Fakultät eine eigene EDV-Abteilung beinhaltet und diese als Ansprechpartner für die jeweiligen Fakultätsmitarbeiter dient. Somit ist gewährleistet, dass
auf Probleme, Fragen, Anregungen etc. seitens der User schnell reagiert werden
kann. Aber diese Struktur verhindert auch eine Zusammenarbeit zwischen den
Fakultäten. Wünschenswert wäre ein virtueller Service Desk, um die Kooperation der Fakultäten zu verbessern. Insbesondere die Implementierung einer
gemeinsamen Configuration Management Database wäre wichtig, dies wird sich
noch im Verlauf dieses Abschnittes zeigen.
Ein weiterer wichtiger Punkt ist die Aufnahme eines Incidents und dessen Priorisierung bzw. Klassifizierung. An der Universität sind sachliche Gründe bei der
Bearbeitung eines Incidents oftmals nicht das Hauptkriterium. Vielmehr erfolgt
die Klassifizierung häufig anhand personenbezogenen Gründen. Wünschenswert
wäre eine ITIL-konforme Priorisierung, bei der Dringlichkeit und Auswirkung
des Problems maßgebende Kriterien sind.
Als ein weiterer kritischer Punkt ist in diesem Zusammenhang die Bearbeitung
von Incidents zu sehen. Wird zum Beispiel von einem User der Fakultät für
Wirtschaftswissenschaften ein bisher unbekanntes Problem bzw. Fehler einer
Software der entsprechenden EDV-Abteilung gemeldet, kann die Problembehebung unter Umständen sehr aufwendig sein, da man erst die Gründe des Fehlers
suchen muss, um die entsprechende Lösung zu erarbeiten. In diesem Zusammen-
44
hang besteht die Möglichkeit, dass eine andere Fakultät einen ähnlichen Vorfall
hatte und diesen bereits gelöst hat. Somit hat die EDV-Abteilung der Wirtschaftswissenschaften einen unnötigen Mehraufwand. Denn wäre der Abteilung
das Problem bekannt gewesen, hätten sie den Fehler schneller beheben können.
Im Kontext des Service Supports nach ITIL wäre einen Fakultäts übergreifende
Configuration Management Database (CMDB) von Vorteil, um einen solchen
Mehraufwand zu vermeiden. Dadurch hätte man eine Plattform, auf der die
EDV-Mitarbeiter ihre erarbeiteten Lösungen, auch im Rahmen des Proactive
Problem Managements, für bestimmte Probleme den anderen Fakultäten zur
Verfügung stellen können. Dies könnte zum Beispiel in Form eines Wikis geschehen. Um die Suche nach einer Lösung für den Benutzer zu erleichtern, wäre
es vorteilhaft, wenn das Wiki mit einer Volltextsuche ausgestattet wäre.
Mit Hilfe einer solchen Datenbasis könnte auch ein weiteres Problem gelöst
werden. Denn auf Grund der Tatsache, dass es sich bei den Mitarbeitern zum
Großteil um studentische Hilfskräfte handelt und diese meistens nur über einen
begrenzten Zeitraum in der EDV-Abteilung arbeiten, herrscht eine hohe Mitarbeiterfluktuation und damit geht häufig Wissen verloren. Um diesen Problem
entgegenzuwirken, wäre es von Vorteil, anstatt zwei oder drei studentischen
Hilfskräften eine Vollzeitkraft anzustellen und zusätzlich mit Hilfe einer Datenbasis das Wissen nachhaltig zu sichern. Die Voraussetzung dafür ist zum einen
die Bereitschaft der Mitarbeiter, ihr Wissen zu teilen, und zum anderen die
Dokumentation jeglicher Incidents. In einem Unternehmen kann dies beispielsweise durch Abmahnung gewährleisten werden, in der Universität gestaltet sich
dies oftmals als schwierig, da entsprechende Sanktionierungsmaßnahmen keine
Wirkung haben.
Abschließend lässt sich für die Bereiche Service Desk, Incident Management und
Problem Management festhalten, dass die Implementierung einer gemeinsamen
Datenbasis in der Universität ein wichtiger Fortschritt wäre. Sie sollte aber nicht
nur als reine Wissensdatenbank fungieren, sondern darüber hinaus als Mittel der
aktiven Kommunikation zwischen den verschiedenen Fakultäten.
Change Management und Release Management. Das Ziel eines ITILkonformen Change Managements und Release Managements ist die Implementierung von autorisierter Software und Hardware mit Hilfe standardisierter Verfahren. Dies gestaltet sich an der Universität Bielefeld auf Grund der autarken
Fakultäten als äußerst schwierig.
Im Bereich der Software lässt sich für die Universität festhalten, dass es keine
einheitliche Softwarestandards für die Fakultäten gibt. Das HRZ stellt zwar standardisierte Softwarepakete bereit, doch jede Fakultät erweitert das SoftwareBundle um fakultätsinterne Software. Dadurch besitzt jede Fakultät eigene
Softwarestandards, die auf den fakultätsinternen Computern installiert werden
und von den jeweiligen EDV-Abteilungen betreut werden. Infolgedessen ist es
schwierig, einen einheitlichen Standard zu realisieren. Eine Lösungsansatz für
die Problematik könnte eine Definitive Software Library (DSL) sein, die von
dem HRZ verwaltet werden könnte. Mit Hilfe dieses Konzeptes könnte dann
die Software von dem HRZ zentral verteilt werden. Die Wartung der Software
obliegt dann auch dem HRZ, welches dann auch die entsprechenden Rollouts
durchführt. Welche Programme auf der DSL installiert werden, müsste dann in
Absprache mit den einzelnen Fakultäten festgelegt werden. Dieses Lösungskon-
45
zept basiert auf der Bereitschaft zur Zusammenarbeit der einzelnen Fakultäten,
da Standards festgelegt werden müssen.
Ein weiteres Problem im Bereich der Software ist die Softwarelizenzierung. Die
Fakultäten haben, wie in Abschnitt 1.3.1 und 1.3.2 gezeigt wurde, unterschiedliche Verfahren für die Verwaltung von Softwarelizenzen. Dadurch besteht die
Gefahr, dass manche Fakultäten überlizenziert und andere unterlizenziert sind.
Eine mögliche Lösung wäre der Erwerb von Campuslizenzen für die gängigste
Software, wie Microsoft Windows oder Microsoft Office.
Im Bereich der Hardware empfiehlt das HRZ Standard-Computer für die Universität. Es ist aber keine zwingende Vorgabe, dementsprechend gibt es eine
Vielzahl von unterschiedlichen Systemen. Um diesen Umstand zu begegnen,
sollten zwingend geltende Richtlinien für die Beschaffung von Computern in
den Fakultäten der Universität eingeführt werden. Die Informationen, der ITInfrastruktur der jeweiligen Fakultäten, sollten dann in der Configuration Management Database (CMDB) gespeichert werden. Diese kann dann als Informationsdatenbank für die Hardware dienen.
Ein weiteres Problem bei der Beschaffung der Hardware ist die Frage der Notwendigkeit. Oftmals werden für Lehrstühle neue Computer beschafft, obwohl
deren „alte“ Geräte noch ausreichend sind. Aus diesem Grund sollte an jeder
Fakultät ein Change Advisory Board (CAB) eingeführt werden. Dieses sollte
dann über die Zweckmäßigkeit einer teureren Anschaffung bestimmen.
Es zeigt sich, dass besonders im Hinblick der Softwareverwaltung, Lizenzierung
und Hardwareverwaltung Handlungsbedarf an der Universität Bielefeld besteht.
Configuration Management. Die wesentliche Aufgabe des Configuration
Management ist die Bereitstellung von Informationen mit Hilfe einer Datenbank. Anhand der bereits genannten Kritikpunkte ist die Implementierung einer Configuration Management Database (CMDB) in die IT-Infrastruktur der
Universität Bielefeld die wichtigste Empfehlung. Sie soll als Wissensdatenbank,
Informationsdatenbank für Hardware, Mittel der Kommunikation und DSL der
einzelnen Fakultäten dienen. Es ist in diesem Zusammenhang empfehlenswert,
dass die Verwaltung der CMDB dem HRZ obliegt. Die Abbildung 1.12 stellt
ein mögliches Lösungskonzept28 der Funktionsweise der CMDB und der DSL
an der Universität Bielefeld dar.
CMDB+DSL
Fakultät
Wirtschaftswissenschaften
Rollout
Rollout
Informationen
Informationen
Fakultät
Rechtswissenschaften
HRZ
Abbildung 1.12: Funktionsweise der CMDB und der DSL.
Zusammenfassend lässt sich festhalten, dass eine vollständige Implementierung
eines ITIL-konformen Service Support-Prozesses an der Universität Bielefeld
28 Aus
Gründen der Übersicht wird das Konzept nur mit zwei Fakultäten dargestellt.
46
nicht realisierbar ist. Die Gründe dafür sind vielfältig, zum Beispiel spricht die
vorhandene IT-Infrastruktur dagegen, ein weiterer wichtiger Punkt ist die geringe Größe der einzelnen EDV-Abteilungen. Diese wären nur mit einem großen
Aufwand zu ändern, die damit zusammenhängenden Kosten würden aber den
Nutzen nicht rechtfertigen. Auch die Bereitschaft zur Veränderung und der Kooperation der einzelnen EDV-Abteilungen spielen bei der Einführung von ITIL
eine wichtige Rolle, diese sind jedoch nicht im ausreichenden Maße vorhanden.
Trotz dieser Gründen sollte aber versucht werden, einige Ideen von ITIL aufzugreifen und diese in der Universität umzusetzen. Hierzu gehört zum Beispiel
die Implementierung einer Configuration Management Database (CMDB) und
einer Definitive Software Library (DSL).
1.4
Fazit
„Mein Computer stürzt dauernd ab.“, „Ich habe keinen Zugriff auf die Datenbank.“, „Mein alter Computer kann mit seiner noch älteren Software dieses
Problem nicht lösen.“ Wir haben nun gesehen, dass ITIL für solche Incidents
resp. Problems immer einen Prozess auf Basis des Best Practice-Konzeptes zur
Lösung vorschlägt. Daher löst ITIL Probleme nicht, sondern zeigt Mittel und
Wege auf, Probleme zu bewältigen. Wie umfangreich die Incidents bzw. Problems und die damit verbundene Struktur des Service Supports ist, wurde in
Abschnitt 1.2 mehr als deutlich.
Das Ziel der ausführlichen Darstellung war es, die Schwierigkeit der Implementierung eines ITIL-konformen Service Supports und die Komplexität der Anforderungen an die jeweiligen Prozesse darstellen zu können. Allerdings gibt
Abschnitt 1.2 auch zu verstehen, dass ITIL mit dem Service Support ein Problemlösungskonzept zur Verfügung stellt, das den Kunden resp. den User in
jeglicher Hinsicht unterstützt. Von der Aufnahme des Incidents bis hin zur Lösung des Problems stehen nach ITIL Funktionen und Prozesse zur Verfügung,
die sich in der Praxis bereits bewährt haben und einen reibungslosen Betriebsablauf gewährleisten können. Somit sind die Vorteile von ITIL nicht von der
Hand zu weisen.
In den Abschnitten 1.3.1 bzw. 1.3.2 wurde dann zunächst auf den IST-Zustand
der Fakultät für Wirtschaftswissenschaften und der Fakultät für Rechtswissenschaft der Universität Bielefeld eingegangen. Hierbei wurden mit Hilfe eines
bereits vorab ausgearbeiteten Fragenkatalogs29 Interviews mit den zuständigen EDV-Mitarbeiter geführt. Anschließend wurden die Interviews zusammengefasst und separat abgehandelt. Hier war der Aufbau der einzelnen Abschnitte
identisch mit dem Abschnitt 1.2, in dem die theoretische Struktur des Service
Supports vorgestellt wurde.
In dem Abschnitt 1.3.3 kamen Kritik und Empfehlungen hinsichtlich des ISTZustandes der Fakultäten in Bezug auf einen ITIL-konformen Service Support zu
ihrer Geltung. Hier wurde zum Beispiel festgestellt, dass die jeweiligen Fakultäten autark voneinander arbeiten und dies zu einem unnötigen Mehraufwand bei
einer Problemlösung führen kann. Weitere Probleme sind die fehlende Kommunikationsbereitschaft der Fakultäten untereinander, die Unflexibilität gewisser
Mitarbeiter und die unökonomische Betrachtungsweise der Universität. Auch
hierzu wurden im Abschnitt 1.3.3 diverse Vorschläge gemacht, die die Probleme
29 Siehe
Anhang.
47
an der Universität Bielefeld nicht lösen, aber zumindest die Situation verbessern
würden.
Am Anfang dieser Arbeit stellte sich die Frage, ob der von ITIL vorgeschlagene
Service Support wirklich so sinnvoll ist. Grundsätzlich lässt sich diese Frage mit
einem „Ja“ beantworten. ITIL bietet tatsächlich mit dem Service Support eine
gute Möglichkeit, auf operativer Ebene des serviceorientierten IT-Managements
effizient zu arbeiten. Diese Tatsache ist allerdings nicht weiter verwunderlich,
da die vorgeschlagenen Funktionen und Prozesse sich bereits in der Praxis bewährt haben. Als „Allheilmittel“ sämtlicher User-Probleme kann ITIL nicht
verstanden werden. Es gibt lediglich die Richtung und die Organisation der
Problemlösung vor, die Incidents bzw. Problems des Users zu behandeln.
Die durchzuführenden Prozesse und die damit verbundene Qualität der Prozesse
liegen im Aufgabenbereich der zuständigen EDV-Mitarbeiter. Aber die in dieser
Arbeit wichtigste Frage, ob sich ITIL bzw. ein ITIL-konformer Service Support
wirklich für jeden lohnt, muss mit „Nein“ beantwortet werden. ITIL ist vor
allem für große Unternehmen von Interesse, da sich hier mit Hilfe von ITIL
eine bessere Übersicht in der Problembewältigung und somit ein reibungsloserer
Betriebsablauf im Unternehmen gewährleisten lassen. Auch Unternehmen, die in
der IT-Branche tätig sind, werden eine Umsetzung von ITIL im eigenen Betrieb
kaum hinterfragen. Doch der Versuch, ITIL zum Beispiel an einer Hochschule,
wie die Universität Bielefeld, umzusetzen, ist, wie bereits aus Abschnitt 1.3
ersichtlich, nur begrenzt sinnvoll.
Dies hat verschiedene Gründe. Zum einen sind da die unterschiedlichen Ausrichtungen der jeweiligen Unternehmungen zu nennen. Während ein Unternehmen eher monetäre Ziele verfolgt, sind Forschung und Entwicklung im Bereich
der Wissenschaft sowie Ausbildung von Wissenschaftlern die vorrangigen Ziele
einer Universität. Dies wurde auch im Verlauf dieser Arbeit deutlich. Zum anderen sind die doch teilweise undurchsichtigen Strukturen ein weiteres Problem,
welches eine Einführung von ITIL erschwert. Im Vergleich zu einem Unternehmen, in dem eine klare Organisation unabdingbar für das Bestehen in der freien
Marktwirtschaft ist, wird in der Universität zwar nicht darauf verzichtet, aber
auch nicht viel Wert gelegt. Zum Schluß ist noch die personelle Problematik, die
ebenfalls eine Barriere für ITIL darstellt, zu nennen. Somit ist von einer Umsetzung von ITIL an der Universität Bielefeld abzuraten, da die Kosten den Nutzen
übersteigen würden. Es lässt sich aber feststellen, dass ITIL mit dem Service
Support in seinen Grundzügen eine sehr gute Möglichkeit zur Gewährleistung
eines reibungslosen Betriebsablaufes und zur Bewältigung von IT-Problemen
darstellt. Aus diesem Grund sollte die Universität den Grundgedanken von ITIL
aufnehmen und auf seine spezielle Ausrichtung resp. Bedürfnisse auslegen.
48
1.5
Fragebogen
Prozess
Incident Management
Problem Management
Change Management
Release Management
Frage
Ist ein zentraler Service Desk vorhanden? Wie funktioniert die
Kontaktaufnahme?(eMail, Anruf, persönlich,...)
Ist der Service Desk als SPOC implementiert?
Gibt es einen First Level Support?
Gibt es einen Second Level Support?
Gibt es einen Third Level Support?
Wie werden Incidents klassifiziert, daher wie werden sie kategorisiert und priorisiert, vor allem wie wird Priorität definiert?
Wie werden Incidents aufgenommen, dokumentiert und ausgewertet? Welche Informationen werden aufgenommen?(Incident Records)
Deckt der Service Desk die Anforderungen der Kunden?
Werden die Kunden über den Stand der Dinge informiert?
Gibt es einen schnellen Zugriff auf verschiedene Dokumente und
Support Informationen in Form von speziellen Dokumentmanagementsystemen oder Wissensdatenbanken?
Gibt es eine Klassifizierung zwischen bekannten Fehlern und Problemen?
Werden die bekannten Fehler in einer eigenen Datenbank (Known
Error Database)?
Gibt es schnelle, kurzfristig verfügbare Lösungsmöglichkeiten zum
Umgang von Fehlern (Workarounds)?
Treten Eskalationsfälle auf?
Wird bei Problemen ein Problem-Record erstellt?
Versucht man die Ursachen von Störungen zu erforschen?
Werden die betroffenen CIs ermittelt? Wie werden die CIs ermittelt?
Werden dem Service Desk so weit wie möglich Informationen, Lösungsmöglichkeiten und Workarounds an die Hand gegeben?
Werden unbekannte Fehler zu bekannten Fehlern? Wie geschieht
das?
Werden alle Prozessschritte zur Behebung überwacht und nachverfolgt?
Werden definierte Methoden ein, um Anzahl und Schwere von
Störungsmeldungen nachhaltig zu senken? (Pro-Aktives Problem
Management)
Gibt es standardisierte Änderungsschritte? Werden alle Änderungsvorhaben geprüft, genehmigt und geordnet?
Gibt es ein Change Advisory Board, dem die Entscheidungsgewalt
obliegt?
Wird sichergestellt, dass durch eine Änderung an einer Stelle keine
Störungen oder andere Beeinträchtigungen an einer anderen Stelle
neu verursacht werden?
Gibt es qualitätsgesicherte Standards und Grundkonfigurationen
zur Installation von IT-Systemen?
Prozess
Release Management
Configuration
gement
Allgemein
Mana-
49
Frage
Ist das Change Management in das Release Management eingebunden?
Existiert ein BackUp-System bzw. Repository?
Wird die ordnungsgemäße Durchführung der Änderungen organisiert, überwacht und dokumentiert?
Werden bei Änderungen an Systemkomponenten alle wichtigen
Daten gesichert und alle Komponenten gründlich getestet?
Gibt es eine Datenbank für bekannte und gelöste Probleme?
Gibt es gesicherte Informationen bzgl. Lizenzen und Herstellersupport?
Gibt es Verfahren zur Beschaffung, Verwaltung, Verfolgung und
Bewertung von Hardware- und Softwareinventars?
Werden die Konfiguration aller IT-Komponenten (Kommunikation, Netzwerk, Hardware, Software) an zentraler Stelle dokumentiert?
Sind die Aufgaben und Zuständigkeiten klar abgegrenzt? Gibt es
einen Manager?
Werden Kennzahlen und Statistiken über Störungsverläufe geführt? Welche Kennzahlen gibt es?
Erfolgt die Softwareverteilung und der Aufbau von Rechnern automatisiert?
Wie sehen die Tools für die einzelnen Geschäftsprozesse aus?
50
Literaturverzeichnis
[Olb06]
Olbrich, A.: ITIL kompakt und verständlich, Vieweg Verlag,
3.Auflage 2006
[Vic05]
Victor, F. und Günther, H.: Optimiertes IT-Management mit ITIL,
Vieweg Verlag, 2.Auflage 2005
[OGC07] Office of Government Commerce: ITIL - Service Operation, TSO, 1.
Auflage 2007
[TRA07] Office of Government Commerce: ITIL - Service Transition, TSO, 1.
Auflage 2007
51
52
Kapitel 2
ITIL-Zertifizierung nach
ISO/IEC 20000
Eine Darstellung des Standards und des Zertifizierungsprozesses
Julia-Vanessa Stork, André Kröger, Christopher Uhrig
2.1
Einleitung
Mit ITIL steht IT-Dienstleistern eine detaillierte Sammlung von Best Practice Empfehlungen für die Gestaltung der Arbeitsabläufe im IT Service Management zur Verfügung. Anhand der in ITIL definierten Prozesse können die
IT-Infrastruktur und die IT-Dienstleistungen übersichtlich und nachvollziehbar
organisiert und kontinuierlich verbessert werden. Die damit einhergehende gesteigerte Servicequalität können Organisationen nach außen hin kommunizieren, indem sie sich als „ITIL-konform“ bezeichnen. Allerdings ist diese Aussage
nicht nachprüfbar, da ITIL kein offizieller Standard ist. Es ist nicht möglich,
eine Organisation ITIL-zertifizieren zu lassen. Nur Einzelpersonen können ein
Zertifikat erwerben (ITIL Foundation, ITIL Service Manager, ITIL Practitioner). Der Standard ISO/IEC 20000 schließt diese Lücke. Es handelt sich dabei
um einen international anerkannten Standard, in dem die Anforderungen an das
IT Service Management einer Organisation zur Erlangung einer Zertifizierung
formell dokumentiert sind. Da ITIL die Basis dieses Standards bildet, kann mit
einem Zertifikat die Konformität mit dem ITIL Rahmenwerk belegt werden.
Der Standard kann dazu verwendet werden, die Service-Qualität zu überwachen
und zu optimieren, als Referenzwert für IT Management Services, als Basis für
eine unabhängige Zertifizierung und damit als Beleg für die Fähigkeit, Services
zu erbringen, die den Kundenbedürfnissen entsprechen. Die Anforderungen des
Standards stellen einen Branchenkonsens für Qualitätsstandards bei IT Service Management-Prozessen dar. [Cod05, S. 1] In der Geschäftspraxis wird der
53
54
ITIL-Zertifizierung nach ISO/IEC 20000
Nachweis der Servicequalität zunehmend vorausgesetzt. So geht das Marktforschungsunternehmen Gartner davon aus, dass bis Ende 2008 mindestens 60% der
relevanten Beschaffungsvorhaben der öffentlichen Verwaltung und mindestens
30% des privaten Sektors eine ISO/IEC 20000 Zertifizierung verlangen werden.
[Gar06]
Ziel dieser Arbeit ist es, den Standard ISO/IEC 20000 mit seinen Anforderungen an das Service Management von IT-Organisationen darzustellen sowie
Möglichkeiten seiner praktischen Umsetzung und den Ablauf der Zertifizierung
aufzuzeigen. Es soll die Frage beantwortet werden, inwiefern sich für eine Organisation die Umsetzung des Standards oder die Zertifizierung lohnt. Dazu werden
zunächst im Kapitel 2.2 die Entwicklung des Standards und seine Beziehung zu
ITIL sowie die Anforderungen an die verschiedenen IT Service ManagementProzesse vorgestellt. Das Kapitel 2.3 behandelt die Zertifizierung. Von der Entscheidungsfindung und Planung über die Umsetzung der Vorgaben des Standards bis hin zum Ablauf der Zertifizierung wird hier Schritt für Schritt der
Weg zum Zertifikat dargestellt. Im Kapitel 2.4 erfolgt eine Gegenüberstellung
der Vor- und Nachteile der Zertifizierung nach ISO/IEC 20000. Abschließend
werden im Kapitel 2.5 die wichtigsten Ergebnisse zusammengefasst.
2.2
2.2.1
Der Standard ISO/IEC 20000
Entwicklung
Der Standard ISO/IEC 20000 geht auf den British Standard BS 15000 zurück.
Dieser wurde im November 2000 von der BSI, der British Standards Institution,
veröffentlicht. Darin wurden die Anforderungen an ein effektives IT Service Management festgelegt. Im Jahr 2002 wurde eine überarbeitete Version unter der
Bezeichnung BS 15000-1:2002 herausgegeben. Ergänzt wurde dieses Dokument
im Jahr 2003 durch den BS 15000-2:2003, den „Code of Practice for Service
Management“. Dieser zweite Teil des BS 15000 enthielt Empfehlungen und Anleitungen zu den Anforderungen des ersten Teils. Im Mai 2005 entschieden die
Mitglieder der ISO (International Organization for Standardization) und der
IEC (International Electrotechnical Commission), den BS 15000 in einen neuen internationalen Standard zu überführen. Am 15. Dezember 2005 wurde der
Standard ISO/IEC 20000 veröffentlicht. Dieser enthält nur geringfügige Änderungen gegenüber dem Originaltext des BS 15000. Seit der Einführung des
ISO/IEC 20000 findet nur noch eine Zertifizierung nach diesem Standard statt.
Die für den BS 15000 ausgegebenen Zertifikate verloren nach dem 15. Juni 2007
ihre Gültigkeit [SMF06, S. 11f.]. Aufgrund dessen ist in dieser Arbeit nicht vom
BS 15000 die Rede, auch wenn dieser in der einschlägigen Literatur häufig verwendet wird, sondern es wird ausschließlich auf den Standard ISO/IEC 20000
Bezug genommen.
2.2.2
Beziehung zu ITIL
Der Standard ISO/IEC 20000 und ITIL ergänzen sich gegenseitig. Der Standard spezifiziert die Anforderungen an das IT Service Management und ITIL
dokumentiert zu den Prozessen des IT Service Management Best Practice Empfehlungen. Während der Standard kurz gefasst die Kriterien für eine Zertifizie-
55
ISO/IEC
20.000
Specification
ISO/IEC
20.000
Best Practices
ITIL
IT Infrastructure Library
Betriebsinterne Abläufe / Arbeitsabläufe
Abbildung 2.1: Spezialisierungsgrad der ISO 20000 Richtlinien. Quelle: Eigene
Darstellung in Anlehnung an [SMF06].
rung festlegt, beschreiben die ITIL-Bücher die möglichen Wege, diese Kriterien
zu erfüllen. Der Standard ISO/IEC 20000 behandelt alle Service Management
Prozesse, die in den ITIL Publikationen „Service Support“ und „Service Delivery“ sowie „Security Management“ dokumentiert sind. Darüber hinaus werden noch einige zusätzliche Prozesse sowie übergeordnete Anforderungen an ein
Management-System definiert. Der Zusammenhang zwischen ISO/IEC 20000
und ITIL ist in Abbildung 2.1 dargestellt. ITIL stellt eine Sammlung von Best
Practice Empfehlungen für die betriebsinternen Arbeitsabläufe im IT-Bereich einer Organisation dar. Die formelle Spezifikation des Standards ISO/IEC 20000
wurde auf der Basis von ITIL entwickelt und enthält spezielle verbindliche Vorgaben für eine Zertifizierung. Ergänzt wird der Standard um den Code of Practice, der Leitlinien und Empfehlungen für die Umsetzung enthält. Dieser ist
vergleichbar mit den Best Practice Empfehlungen von ITIL, bezogen auf den
Rahmen des formellen Standards.
2.2.3
Struktur
Der Standard ISO/IEC 20000 besteht aus zwei Dokumenten. Der erste Teil
20000-1 „Specification“ definiert verbindliche Vorgaben („shall“) für das IT
Service Management, die für eine Zertifizierung vollständig umgesetzt werden
müssen. Der zweite Teil 20000-2 „Code of Practice“ enthält Leitlinien und Empfehlungen („should“) zur Umsetzung der Anforderungen des ersten Teils. Abweichungen von diesen Erläuterungen der Best Practices sind erlaubt, für eine
erfolgreiche Zertifizierung sind sie nicht zwingend erforderlich. Grundlage für
die Zertifizierung ist Teil 1 des Standards.
Beide Teile sind inhaltlich gleich strukturiert. Einem einführenden Kapitel zum
Anwendungsbereich des Standards folgt die Einführung und Definition von
56
Service Delivery Processes
Capacity Management
Service Level Management
Service Continuity and
Availibility Management
Service Reporting
Information Security
Management
Budgeting and Accounting
for IT services
Control Processes
Release
Processes
Change Management
Resolution
Processes
Relationship
Processes
Incident Management
Business Relationship
Management
Problem Management
Supplier Management
Release Management
Abbildung 2.2: Service Management Processes. Quelle: Eigene Darstellung in
Anlehnung an [Spe05].
Fachbegriffen. Die Kapitel 3 bis 5 behandeln das Management-System. Zunächst werden die Anforderungen in Bezug auf die Verantwortlichkeiten, die
Dokumentation und die Kompetenz der Mitarbeiter definiert. Dann erfolgt eine Beschreibung der „Plan-Do-Check-Act“-Methode, die zur Planung und Implementierung des Service Managements sowie neuer oder geänderter Services
eingesetzt werden kann. In den Kapiteln 6 bis 10 werden insgesamt 13 Service
Management Prozesse definiert, die in die 5 übergeordneten Gruppen Service
Delivery-Prozesse, Relationship-Prozesse, Lösungsprozesse, Steuerungsprozesse
und Release-Prozesse aufgeteilt sind (siehe Abbildung 2.2). Die Anforderungen
des Standards sind unterteilt in Ziele (Objectives) und definierte Anforderungen
zur Erfüllung dieser Ziele (Requirements).
2.2.4
Anforderungen an ein Management-System
Das vorgegebene Ziel ist ein Management-System mit Grundsätzen und Strukturen, die eine effektive Implementierung und Verwaltung aller IT Services ermöglichen [Spe05, S. 3].
Um dieses Ziel zu erreichen, müssen die Rollen und Verantwortlichkeiten des
Managements klar definiert sein. Dazu gehört die Festlegung von Grundsätzen, Plänen und Zielen des Service Managements sowie die Beschreibung, wie
diese Ziele erreicht werden sollen. Für die Koordination und die Verwaltung
sämtlicher Services ist eine verantwortliche Person zu ernennen und es ist ein
Risiko-Management zu implementieren. Die Anforderungen der Kunden müssen ermittelt und Maßnahmen, diesen auch gerecht zu werden, müssen getroffen
werden. In festgelegten Abständen sind Service Management Reviews durchzuführen, um eine kontinuierliche Angemessenheit und Effektivität sicherzustellen
[Spe05, S. 3f.]. Für jede Rolle im Service Management muss festgelegt werden,
Business
requirements
Manage services
Management responsibility
requirements
Customer
PLAN
Plan service
management
ACT
Continual
improvement
Other teams,
e.g. security,
IT operations
satisfaction
New / changed
services
Other processes
e.g. business,
supplier, customer
Service Desk
Business
results
Customer
Request for
new / changed
services
57
Other processes,
e.g. business,
supplier, customer
DO
Implement service
management
CHECK
Monitor, measure
and review
Team and people
satisfaction
Abbildung 2.3: Regelkreislauf. Quelle: Eigene Darstellung in Anlehnung an
[Spe05].
welche Kompetenzen zur effektiven Erfüllung der Aufgaben benötigt werden. Die
Mitarbeiter müssen wissen, wie sie zur Erreichung der festgelegten Ziele beitragen. Desweiteren müssen sie sich der Bedeutung ihrer Aktivitäten bewusst sein
[Spe05, S. 4]. Um dieses sicherzustellen, sollte ein Weiterbildungsplan erstellt
werden [Cod05, S. 3]. Eine weitere Anforderung ist die Bereitstellung von Dokumentationen und Aufzeichnungen zur Unterstützung der Management-Prozesse.
Dabei ist zu beachten, dass Abläufe und Verantwortlichkeiten für die Erstellung,
Pflege, Entsorgung und Kontrolle der Dokumente festgelegt werden, und dass die
Aktualität sichergestellt ist. Zu den Dokumentationen gehören die Grundsätze
und Pläne, die Abläufe und Prozesse sowie sonstige erforderliche Aufzeichnungen [Spe05, S.4].
2.2.5
Planung und Implementierung des Service Managements
Zur Umsetzung der Implementierung des Service Managements gibt der Standard die „Plan-Do-Check-Act“-Methode vor [Spe05, S. 4]. Dabei handelt es sich
um ein Modell, bei dem vier Schritte in einem Kreislauf immer wieder durchlaufen werden (siehe Abbildung 2.3). Die Festlegung der Ziele und notwendigen Prozesse (Plan), die Durchführung der Implementierung (Do), die Überprüfung der
Prozesse hinsichtlich der Grundsätze, Ziele und Anforderungen (Check) sowie
das Ergreifen von Maßnahmen zur kontinuierlichen Verbesserung der Prozesse
(Act). Durch diese Methode wird eine ständige Qualitätsverbesserung sichergestellt.
Bei der Planung des Service Managements müssen der Umfang des Service Managements, die zu erreichenden Ziele sowie die auszuführenden Prozesse definiert
werden. Es ist zu beschreiben, wie die Prozesse in Aktivitäten umgesetzt wer-
58
den und wie das Risikomanagement durchgeführt wird. Darüber hinaus sind die
Verantwortlichkeiten, Ressourcen, Hilfsmittel und das Budget anzugeben. Alle
Pläne müssen durch einen Review überprüft und kommuniziert werden [Spe05,
S. 5].
Die Implementierung des Service Management Plans hat durch die Zuweisung
von Verantwortlichkeiten, Budgets und Hilfsmitteln sowie durch die Koordination der Prozesse und die Auswahl und Schulung von Mitarbeitern zu erfolgen.
Dabei sind Pläne und Grundsätze, Abläufe und Definitionen für die Prozesse
zu dokumentieren und einzuhalten. Bezüglich des Fortschritts müssen Berichte
angefertigt werden [Spe05, S. 6].
Es müssen Methoden zur Überwachung der Prozesse eingeführt werden, die
belegen können, dass die Ziele durch die Prozesse erreicht werden können. In
regelmäßigen Abständen sind Reviews durchzuführen, um die Service-Qualität,
die Kundenzufriedenheit und die Auslastung der Ressourcen zu überprüfen. Es
muss ein Prüfprogramm erarbeitet werden, das den Status und die Bedeutung
des Prozesses, die Ergebnisse vorheriger Prüfungen und die Auswahl der Prüfer
berücksichtigt. Die Ergebnisse sind mit den beteiligten Personen zu kommunizieren [Spe05, S. 6].
Für die Verbesserung der Service-Aktivitäten muss alles, was nicht mit den Service Management Plänen übereinstimmt, entfernt werden. Dafür sind Rollen
und Verantwortlichkeiten klar zu definieren. Für die Bearbeitung von ServiceVerbesserungen muss ein Prozess definiert und ein Service-Verbesserungsplan
erstellt werden. Diese müssen die Informationen zu den Verbesserungen und die
festgelegten Ziele sowie die Methoden zur Identifizierung, Planung, Kommunikation und Implementierung der Verbesserungsmaßnahmen beinhalten. Daneben
sind die Methoden zur Messung, Berichterstattung und Sicherstellung der Ausführung und Zielerreichung der Aktionen anzuführen. Vor der Durchführung
einer Verbesserungsmaßnahme muss die Servicequalität als Vergleichsmaßstab
dokumentiert werden [Spe05, S. 7].
Die Planung und Implementierung neuer oder geänderter Services muss im Rahmen eines formellen Change-Management erfolgen. Dafür ist eine Analyse der
kostenbezogenen, organisatorischen, technischen und wirtschaftlichen Auswirkungen notwendig. Die zu erstellenden Pläne müssen die Rollen und Verantwortlichkeiten für die Implementierung, Ausführung und Betreuung und die
Änderungen an bestehenden Grundsätzen und Services beinhalten. Die Anforderungen an die Mitarbeiter sind zu dokumentieren und die Positionen zu besetzen. Es wird festgelegt, welche Prozesse, Maßnahmen, Methoden und Tools
eingesetzt werden und wie viel Zeit und Geld dafür zur Verfügung steht. Abschließend sind messbare Ergebnisse für die Ausführung vorzugeben [Spe05, S.
7f.].
2.2.6
Anforderungen an Service-Management-Prozesse
Für alle Prozesse müssen das Ziel und der Ablauf des Prozesses, die Rollen und
Verantwortlichkeiten, die Messung definierter Kennzahlen, die SchnittstellenSpezifikation sowie die kontinuierliche Verbesserung ersichtlich und beweisbar
sein [SMF06, S. 23].
Service Level Management Für das Service Level Management gibt der
Standard als Ziel vor, die Service-Level zu definieren, zu vereinbaren, aufzu-
59
zeichnen und zu verwalten.
Jeder Service, der angeboten wird, muss in einer Service-Level-Vereinbarung
(service level agreement) zusammen mit dem zugehörigen Ziel dokumentiert
werden. Der gesamte Serviceumfang sollte in einem Servicekatalog dargestellt
werden, der vom Change-Management zu verwalten ist und sowohl Kunden als
auch Mitarbeitern jederzeit zugänglich sein sollte [Cod05, S. 8]. Unterstützende Vereinbarungen und Lieferantenverträge sind ebenfalls aufzuzeichnen. Durch
regelmäßige Reviews ist sicherzustellen, dass die Vereinbarungen stets auf dem
neuesten Stand sind. Die Service-Level müssen überwacht werden und es hat eine
Berichterstattung zu den festgelegten Zielen zu erfolgen. Notwendige Maßnahmen zur Verbesserung sind in Service-Verbesserungsplänen zu dokumentieren
[Spe05, S. 8].
Service Reporting Ziel des Service Reporting ist es, rechtzeitig vereinbarte,
zuverlässige und genaue Berichte zu erstellen, um eine effektive Kommunikation
zu gewährleisten und damit informationsbezogene Entscheidungen möglich zu
machen.
Jeder Service Report muss eine Beschreibung seines Zweckes, der Zielgruppe
und Details über die Datenquelle enthalten. Es ist festzuhalten, inwiefern die
erbrachten Services die definierten Ziele erreicht haben und es müssen Leistungsmerkmale aller Prozesse aufgezeichnet werden. Es sind Zufriedenheitsund Trendanalysen durchzuführen und nach besonderen Ereignissen sind Leistungsberichte anzufertigen. Managemententscheidungen und Korrekturen müssen umgehend dokumentiert und kommuniziert werden [Spe05, S. 9].
Service Continuity und Availability-Management Zielvorgabe für das
Service Continuity und Availability-Management ist die Sicherstellung der Service-Kontinuität und Verfügbarkeit, so dass Vereinbarungen gegenüber dem
Kunden unter allen Umständen eingehalten werden können.
Um diese zu erreichen, müssen auf Basis der Service-Level-Vereinbarungen Verfügbarkeitspläne und Servickontinuitätspläne entwickelt und regelmäßig gepflegt
und getestet werden. Dabei sind Risiko-Bewertungen durchzuführen und zu dokumentieren. Anforderungen an Zugriffsrechte und Reaktionszeiten sowie an
die Verfügbarkeit der Systemkomponenten müssen definiert werden und es ist
sicherzustellen, dass diese erfüllt werden. Die Verfügbarkeit muss gemessen und
aufgezeichnet werden. Ist diese außerplanmäßig nicht gegeben, müssen die Ursachen analysiert und angemessene Gegenmaßnahmen eingeleitet werden [Spe05,
S. 9]. Es sollte eine enge Zusammenarbeit mit dem Change-Management erfolgen, um die Auswirkungen von Changes auf die Verfügbarkeit und ServiceKontinuität zu kontrollieren. Wo dies möglich ist, sollten potenzielle Probleme
prognostiziert werden, damit vorbeugende Maßnahmen getroffen werden können
[Cod05, S. 11f.].
Finanzplanung und Kostenrechnung für IT Services Ziel der Finanzplanung und Kostenrechnung für IT Services ist es, einen Plan für die finanziellen
Ressourcen zu erstellen und die Kosten für die Bereitstellung von Services zu
berechnen.
Für die Finanzplanung und Kostenrechnung, für die Kontrolle und Genehmigung des Budgets sowie für die Ermittlung und Zuordnung von indirekten Kos-
60
ten müssen klare Grundsätze und Prozesse definiert werden. Kostenrechnungsprozesse sollten die Nutzung der finanziellen Ressourcen aufzeigen und die Ermittlung der Stückkosten ermöglichen [Cod05, S. 14]. Die Kosten sind so detailliert zu planen, dass die Kontrolle des Budgets und die Entscheidungsfindung
effektiv gestaltet werden können. Die Kosten müssen hinsichtlich des Budgets
überwacht und dokumentiert werden, Finanzprognosen sind zu überprüfen und
dementsprechend müssen die Kosten verwaltet werden [Spe05, S. 10].
Capacity-Management Zielvorgabe für das Capacity-Management ist die
Sicherstellung der Verfügbarkeit ausreichender Kapazitäten, so dass die mit dem
Kunden vereinbarte Nachfrage jederzeit befriedigt werden kann.
Im Rahmen des Capacity-Managements muss ein Kapazitätsplan erstellt und
gepflegt werden, um die Service-Kapazität zu überwachen, anzupassen und eine
angemessene Kapazität bereitstellen zu können. Dafür sind Methoden, Abläufe
und Techniken zu identifizieren und anzuwenden. Der Kapazitätsplan muss Prognosen über zukünftige Anforderungen sowie Einflüsse durch neue technologische Entwicklungen und Auswirkungen externer Veränderungen berücksichtigen
[Spe05, S. 10].
Information-Security-Management Ziel des Information-Security-Managements ist eine effektive Verwaltung der Informations-Sicherheit innerhalb aller
Service-Aktivitäten.
Grundsätze zur Informations-Sicherheit müssen definiert und kommuniziert werden. Dazu sind Sicherheitskontrollen einzuführen, die die Anforderungen der
Grundsätze implementieren, und die die Risiken bezüglich des Zugriffs auf den
Service oder auf die Systeme verwalten. Eine Dokumentation der Kontrollen
muss die Durchführung und Wartung der Kontrollmaßnahmen beschreiben und
die Risiken nennen, auf die sie sich beziehen. Für sämtliche Informationsträger
sollte eine Bestandsaufnahme, eine Kategorisierung entsprechend der Bedeutung
für den Service und eine Bewertung der erforderlichen Sicherheitsstufe durchgeführt werden [Cod05, S. 16]. Der externe Zugriff auf Services und Systeme
ist durch geeignete formelle Vereinbarungen zu regeln. Treten sicherheitsrelevante Störungen auf, sind in Übereinstimmung mit dem Incident-Management
Berichte und Aufzeichnungen zu erstellen. Es müssen Abläufe definiert sein, die
dafür sorgen, dass jede sicherheitsrelevante Störung überprüft wird, und dass
entsprechende Maßnahmen getroffen werden [Spe05, S. 10f.].
Business-Relationship-Management Ziel des Business-Relationship-Managements ist es, den Kunden und seine geschäftsfördernde Abläufe zu verstehen
und auf dieser Basis eine gute Beziehung zu dem Kunden herzustellen und zu
pflegen.
Das Business-Relationship-Management muss alle Kunden und die an den Services beteiligten Personen identifizieren und dokumentieren. Zusammen mit den
Kunden müssen mindestens einmal pro Jahr Reviews durchgeführt werden, um
Geschäftsanforderungen, erbrachte Leistungen und Changes in Service-Umfang,
Service-Level-Vereinbarungen und Verträgen zu diskutieren. Es sind regelmäßige Meetings abzuhalten und zu protokollieren, um die Leistung, die erreichten
Ziele, die Schwierigkeiten und die Aktionspläne zu erörtern. Für den Umgang
61
mit Beschwerden muss ein formeller Ablauf festgelegt und mit den Kunden abgestimmt werden. Alle Beschwerden sind aufzuzeichnen und zu untersuchen.
Es müssen Maßnahmen ergriffen und dokumentiert werden und die Beschwerde muss formell abgeschlossen werden. Die Kundenzufriedenheit ist regelmäßig
zu messen und zu dokumentieren. Für die Erfassung des Feedbacks und die
Reaktion darauf muss ein Prozess erstellt werden [Spe05, S. 11f.]. Schwankungen im Zufriedenheitsgrad sollten auf ihre Ursachen hin untersucht werden. Die
Ergebnisse der Feedback- und der Beschwerdeanalyse fließen in den ServiceVerbesserungsplan ein. Verbesserungs-Empfehlungen sollten an das Service Delivery Team weitergereicht werden [Cod05, S. 18].
Lieferanten-Management Zielvorgabe für das Lieferanten-Management ist
die Sicherstellung einer nahtlosen Bereitstellung von qualitativ hochwertigen
Services.
Für die Verwaltung der Lieferanten müssen Prozesse implementiert und dokumentiert werden und jedem Lieferanten ist ein zuständiger Vertragsmanager zuzuordnen. Die Services müssen definiert werden und die Lieferantenverträge sind
mit den Service-Level-Vereinbarungen abzustimmen und durch Reviews regelmäßig zu überprüfen. Werden Lieferungen indirekt über einen Hauptlieferanten
bezogen, muss dieser nachweisen, dass die nachgeordneten Lieferanten die Vertragsanforderungen erfüllen. Die Rollen und Beziehungen zwischen den Hauptlieferanten und den Lieferanten mit Unterverträgen sind klar zu dokumentieren.
Es muss ein Prozess festgelegt werden, der Vertragsänderungen, Vertragsstreitigkeiten und die Beendigung des Service regelt. Die Leistungen sind zu überwachen, zu überprüfen und aufzuzeichnen. Sie müssen mit den Service-Level-Zielen
verglichen werden und es sind Verbesserungsmaßnahmen zu identifizieren und
aufzuzeichnen. Diese dienen als Input für den Service-Verbesserungsplan [Spe05,
S. 12].
Incident-Management Ziel des Incident-Managements ist die Reaktion auf
Service-Requests und die schnellstmögliche Wiederherstellung des vereinbarten
Service.
Sämtliche Incidents müssen aufgezeichnet werden und es sind Verfahren anzuwenden, um die Auswirkungen von Incidents zu verwalten. Diese Verfahren müssen die Aufzeichnung der Incidents und Prioritätsabfolgen, die Klassifizierung
und Aktualisierung, die Auswirkungen auf Geschäftsabläufe sowie die Lösung
und den formellen Abschluss definieren. Für bedeutende Incidents ist ein Prozess zu entwickeln, der die Klassifizierung und Behandlung vorgibt. Der Kunde
muss über den Fortschritt der gemeldeten Incidents oder Service-Requests informiert werden. Er ist vorab zu benachrichtigen, wenn sein Service-Level nicht
erreicht werden kann. Sämtliche Mitarbeiter des Incident-Managements müssen
auf die relevanten Informationen zugreifen können [Spe05, S. 13].
Problem-Management Ziel des Problem-Managements ist es, durch Identifizierung und Analyse der Ursache von Incidents und einer Verwaltung der
Probleme bis zum Abschluss die Unterbrechungen des Geschäftsprozesses auf
ein Minimum zu reduzieren.
Alle identifizierten Probleme müssen aufgezeichnet werden und es sind Verfahren anzuwenden, um die Auswirkungen von Incidents und Problemen zu
62
identifizieren, zu minimieren oder zu vermeiden. Diese Verfahren müssen die
Aufzeichnung aller Probleme, deren Klassifizierung und Aktualisierung sowie
deren Lösung und formellen Abschluss definieren. Die Problembehebung ist zu
überwachen und es sind Reviews und Berichte dazu anzufertigen. Potenzielle
Probleme sind durch vorbeugende Maßnahmen zu reduzieren. Aktuelle Informationen von bekannten Fehlern und behobenen Problemen müssen für das
Incident-Management verfügbar gemacht werden und notwendige Änderungen
sind an das Change-Management weiterzuleiten. Identifizierte Verbesserungsmaßnahmen müssen aufgezeichnet und dem Service-Verbesserungsplan hinzugefügt werden [Spe05, S. 13].
Configuration-Management Ziel des Configuration-Managements ist die
Definition und Steuerung der Service- und Infrastrukturkomponenten sowie die
Aufrechterhaltung korrekter Konfigurationsinformationen.
Für die Planung des Change- und Configuration-Managements muss ein integrativer Ansatz verfolgt werden. Es ist ein Konfigurationsplan erforderlich, in dem
die Konfigurations-Elemente und deren Grundbestandteile aufgeführt werden.
Darin sind die Eigenschaften der Elemente und deren Beziehung zueinander zu
definieren. Es müssen Methoden zur Identifizierung, Kontrolle und Überwachung
von Service- und Infrastrukturkomponenten entwickelt werden. Informationen
zu Auswirkungen von Veränderungen sind dem Change-Management zur Verfügung zu stellen. Änderungen an Konfigurations-Elementen müssen verfolgt und
überprüft werden können. Zur Aufrechterhaltung der Integrität von Systemen
und Services sind Prozesse zur Steuerung der Konfigurationen erforderlich. Alle
Konfigurations-Elemente sind in einer Configuration-Management-Datenbank
(CMDB) aufzuzeichnen. Diese muss aktiv gepflegt werden, um deren Zuverlässigkeit und Aktualität sicherzustellen. Der Zugriff auf die Datenbank ist strikt
zu kontrollieren. Informationen zum Status der Konfigurations-Elemente, deren
Versionen, Standorte und damit zusammenhängende Änderungen und Probleme müssen den Personen zur Verfügung stehen, die diese benötigen. Es sind
Prozesse zur Überprüfung der Konfigurationen zu implementieren, die Mängel
aufzeichnen, Korrekturen einleiten und Ergebnisberichte erstellen [Spe05, S. 14].
Change-Management Ziel des Change-Managements ist es sicherzustellen,
dass alle Changes bewertet, genehmigt, implementiert und überprüft werden.
Changes müssen einen klar definierten und dokumentierten Umfang haben. Alle Requests for Changes sind aufzuzeichnen und zu klassifizieren. Es müssen
Bewertungen bezüglich der Risiken, der Auswirkungen und des Geschäftsnutzens durchgeführt werden. Changes sind zu genehmigen, zu überprüfen und
kontrolliert zu implementieren. Es muss ein Zeitplan mit Details zu allen Changes erstellt werden, deren Implementierung genehmigt wurde. Die Implementierungszeiten sind allen beteiligten Parteien mitzuteilen. Es müssen Richtlinien und Abläufe für Notfall-Changes erstellt werden und es ist zu definieren,
wie nicht erfolgreiche Changes rückgängig gemacht oder entfernt werden. Nach
der Implementierung ist ein Review durchzuführen, dessen Ergebnisse in den
Service-Verbesserungsplan einfließen. Die Aufzeichnungen von Changes müssen regelmäßig analysiert werden, um sich häufende Changes, wiederkehrende
Change-Kategorien, Trends und andere relevanten Informationen zu ermitteln
[Spe05, S. 14f.].
63
Release-Management-Prozess Ziel des Release-Management-Prozesses ist
die Bereitstellung, Verteilung und Verfolgung eines oder mehrerer Changes in
einem Release in der Live-Umgebung.
Der Release-Management-Prozess sollte in die Configuration und Change Management Prozesse integriert werden. Grundsätze, die die Häufigkeit und den
Typ der Releases angeben, sind zu dokumentieren und zu vereinbaren. Es muss
ein Plan für das Release von Services, Systemen, Software und Hardware erstellt
werden. Die Einführung (Rollout) des Release ist zwischen allen beteiligten Parteien zu vereinbaren und von allen Parteien zu genehmigen. Das Release muss
so konzipiert und implementiert werden, dass die Integrität der Hardware und
Software während der Installation, Bearbeitung, Verpackung und Auslieferung
gewährleistet ist. Vor der Bereitstellung müssen alle Releases in einer kontrollierten Testumgebung erstellt und getestet werden. Es sind Richtlinien und Abläufe
für Notfall-Releases zu erstellen und es muss definiert werden, wie nicht erfolgreiche Releases rückgängig gemacht oder entfernt werden. Es sind Messungen
bezüglich des Erfolges von Releases durchzuführen [Spe05, S. 15].
2.3
2.3.1
Die Zertifizierung
Entscheidungsfindung
Grundlage für die Entscheidung für eine Zertifizierung nach ISO/IEC 20000
ist die Durchführung einer Standortbestimmung des IT-Bereiches und die Erarbeitung eines Maßnahmenplanes für die notwendigen Anpassungen. Darauf
aufbauend kann im Fall einer Entscheidung für die Einführung der Anforderungen des Standards ein Projektplan für die Umsetzung der Prozesse erstellt
werden.
Ein geeigneter Weg für die Standortbestimmung ist die Durchführung eines
Assessments. Dabei wird der konkrete Reifegrad aller IT-Service-ManagementProzesse ermittelt und es werden Empfehlungen abgeleitet, was für eine erfolgreiche Zertifizierung noch zu tun ist. Für die Durchführung des Assessments
sollte ein geeignetes Beratungsunternehmen beauftragt werden. Es ist ein Projektteam mit einem Projektleiter und den Prozessverantwortlichen zusammenzustellen. Die Vorgehensweise des Assessments sollte mit dem Beratungsunternehmen in einem Vorgespräch geklärt werden. Dabei werden die Prozesse bereits
grob durchgesprochen und die Prozessdokumentationen werden gesichtet. Die
entsprechenden Dokumente sollten rechtzeitig vorbereitet werden. Es muss ein
detaillierter Zeitplan für die Durchführung erstellt werden und die Mitarbeiter
des IT-Bereiches sind darüber zu informieren, so dass sie zu den vereinbarten Zeiten verfügbar sind und die erforderlichen Dokumente griffbereit haben.
Das eigentliche Assessment wird in Form von Interviews durchgeführt. Dabei
wird aufgezeichnet, was bei den Prozessen jeweils bereits vorhanden ist. Das
Beratungsunternehmen erstellt dazu einen Bericht, der für jeden Prozess einen
konkreten Reifegrad benennt und Empfehlungen ausspricht, welche nächsten
Schritte in welcher Reihenfolge unternommen werden sollten. Abschließend werden die Ergebnisse des Assessments allen IT-Mitarbeitern präsentiert [Boc06,
S. 38 f.].
Es ist sinnvoll, sich von dem Beratungsunternehmen einen Maßnahmenplan erstellen zu lassen. Auf der Grundlage der Ergebnisse des Assessments werden
64
darin alle für eine Zertifizierung notwendigen Maßnahmen und Umsetzungserfordernisse aufgelistet. Der Plan ist nach den Prozessen zu strukturieren und es
ist eine Prozesslandkarte als Übersicht zu erstellen [Boc06, S. 49f.].
2.3.2
Prozessumsetzung
Das folgende Kapitel thematisiert die praktische Umsetzung der Anforderungen
des ISO/IEC 20000. Es wird beschrieben, wie die vorgegebenen Prozesse im Betrieb realisiert werden können und was dabei zu beachten ist. Behandelt werden
nur die über ITIL hinausgehenden Teile, also das Management-System, die Planung und Implementierung des Service-Managements, das Service Reporting,
das Information-Security-Management, das Business-Relationship-Management
sowie das Lieferanten-Management. Auf die Umsetzung der auf ITIL basierenden Prozesse wird ausführlich in den Arbeiten der anderen Gruppen eingegangen.
Management-System Das Management-System ist ein Rahmenwerk, das
die Politik, die Organisation und die Strategie des IT-Bereichs festlegt. Voraussetzung für die Umsetzung ist, dass eine ausformulierte Unternehmensstrategie
existiert. Daraus abzuleiten ist eine IT-Strategie, deren wesentliche Bestandteile
in der Abbildung 2.4 dargestellt werden. Rahmenbedingungen dieses Strategiekonzepts sind die Unternehmensumgebung und die vorhandenen IT-Strukturen
sowie die Vorgaben zur Effektivität und Effizienz. Die Aufgaben, Ziele und Prioritäten sind in einem Leitbild zu definieren. Die Philosophie, wie diese umzusetzen sind, wird in einer Anwendungsstrategie formuliert. Darauf aufbauend
werden in einer Systemstrategie und einer Organisationsstrategie festgelegt, wie
die IT strukturiert und organisiert wird. Die Ressourcenstrategie beantwortet
die Frage, mit welchen Mitteln die vorgegebenen Ziele erreicht werden sollen.
Die IT-Strategie ist schriftlich auszuformulieren und an die Mitarbeiter zu verbreiten [Boc06, S. 81].
Die Ziele und Strategien heruntergebrochen auf die einzelnen Prozesse ergeben
zusammengefasst die Service-Management-Politik. Darin ist zu beschreiben, auf
welche Art und Weise die IT-Services erbracht werden sollen. Die konkreten
Ziele und Vorhaben für das kommende Geschäftsjahr sind in einem ServiceManagement-Plan zu definieren. Es muss formuliert werden, wie man sicherstellt, dass die Ziele auch erreicht werden und wie man gewährleistet, dass die
Dokumente stets aktuell sind [Boc06, S. 72].
In einem Dokument Management-System sind organisatorische Grundprinzipien sowie die Rollen und Verantwortlichkeiten für die Prozesse und Dokumente
festzulegen. Für die Umsetzung eines Risikomanagements ist ein Vorgehen zu
definieren, wie Risiken erkannt, erfasst und bewertet werden und wie Gegenmaßnahmen ergriffen werden. Aufzeichnungen über relevante Risiken können
beispielsweise in Form einer Risikomatrix, die Eintrittswahrscheinlichkeit und
Schadenshöhe einander gegenüberstellt, geführt werden [Boc06, S. 76f.]. Die
Umsetzung und die Wirksamkeit der Gegenmaßnahmen sind laufend zu überwachen. Bei der Formulierung sämtlicher Dokumente ist zu beachten, dass diese
nicht nur von Spezialisten verstanden werden müssen, und dass durch die Verwendung von konkreten Begriffen ein einheitliches Verständnis gewährleistet
sein muss [Boc06, S. 81].
65
Abbildung 2.4: Strategiekonzept. Quelle: Eigene Darstellung in Anlehnung an
[Boc06].
Eine weitere Aufgabe des Management-Systems ist die Bereitstellung von Dokumentationen. Es sind standardisierte Abläufe zu definieren, wie Dokumente
zu erstellen, zu ändern und zu archivieren sind. Von jeder Version eines Dokumentes sollte eine Archivdatei erstellt werden und die Versionsführung sollte
dokumentiert werden. Für alle Abläufe muss es klare Verantwortlichkeiten geben
[Boc06, S. 107f.].
Planung und Implementierung des Service-Managements Zur Umsetzung der Planung und Implementierung des Service-Managements ist die in
Kapitel 2.2.5 vorgestellte „Plan-Do-Check-Act“ -Methode zu verwenden. Die
Implementierung von Services anhand dieser Methode bewirkt einen kontinuierlichen Verbesserungsprozess (KVP) der Leistungen. Es muss ein Prozessmanager (KVP-Manager) bestimmt und eine Prozessbeschreibung erstellt werden.
Wenn bei der Überprüfung der implementierten Prozesse Nonkonformitäten mit
den festgelegten Zielen und Anforderungen auftreten, hat der Prozessmanager
die Aufgabe, eine Bewertung durchzuführen. Bei den Nonkonformitäten kann
es sich um einen Verstoß gegen die Anforderungen oder um Verbesserungspotential handeln. Die Ermittlung der Ursachen erfolgt durch einen Spezialisten,
meist durch den zuständigen Prozessmanager, der gleichzeitig Lösungsvorschläge ausarbeitet. Daraus hat der KVP-Manager den erforderlichen Handlungsbedarf abzuleiten und entsprechende Maßnahmen zu ermitteln. Diese werden
in einem Maßnahmenkatalog gesammelt, der mit einem Tool verwaltet werden
sollte. Darin sind die Zuständigkeiten und der Zeitrahmen für die Umsetzung
festzulegen. Der KVP-Manager hat die ergriffenen Maßnahmen zu überprüfen
und zu bewerten. Alle Mitarbeiter müssen über die Maßnahmen informiert werden [Boc06, S. 86f.].
66
Service Reporting Aufgabe des Prozesses Service Reporting ist es, eine
Plattform für eine effektive Kommunikation innerhalb des IT-Bereiches zur Verfügung zu stellen. Zur Umsetzung ist ein Prozessmanager zu bestimmen, der
festlegt, welche Berichte verfasst und verbreitet werden sollen. Sämtliche erforderlichen Reports können beispielsweise auf einer Intranetseite dargestellt und
verlinkt werden [Boc06, S. 103]. Auf diese Weise entsteht eine Sammlung von
Berichten, auf die jederzeit zugegriffen werden kann. Dabei muss deutlich werden, welche Person für den Report verantwortlich ist, an wen er sich richtet, auf
welcher Datenquelle er basiert und in welchem Rhythmus er erstellt wird. Diese
Informationen können zur übersichtlichen Strukturierung in die Darstellung der
Berichte übernommen werden. Darüber hinaus ist es sinnvoll, die Berichte nach
den Prozessen zu kategorisieren, durchgängig zu nummerieren und regelmäßig
auf ihre Aktualität zu überprüfen [Boc06, S. 103f.].
Die Mitarbeiter des IT-Bereichs haben in diesem Zusammenhang verschiedene
Aufgaben zu erfüllen. Grundsätzlich hat sich jeder über die für ihn relevanten
Berichte zu informieren. Die Prozessverantwortlichen müssen Prozessänderungen und die Archivierung von Dokumenten bekannt machen und für die Aktualisierung der Berichte ihrer Prozesse sorgen. Der Service-Manager ist für die
Änderung der Prozessdokumentation verantwortlich [Boc06, S. 279f.].
Information-Security Management Als Grundlage für den Prozess Information-Security Management ist eine Sicherheitspolitik zu definieren. Darin soll
für jeden verständlich die Grundhaltung zum Thema Sicherheit festgelegt werden, um ein einheitliches Verständnis davon im Unternehmen zu etablieren.
Es sollte formuliert werden welche Bedrohungen existieren, was grundsätzlich
wie schutzbedürftig ist, welches Maß an Schutz angemessen ist, inwiefern Vorkehrungen hinsichtlich der IT-Systeme und des Personals nötig sind und wie
die Kontrolle und Verbesserung der Schutzmechanismen sichergestellt werden
kann. Die Sicherheitspolitik ist mit der Geschäftsleitung abzustimmen und im
Unternehmen bekannt zu machen [Boc06, S. 127f.].
Ausgehend von der Sicherheitspolitik sind Sicherheitsrichtlinien zu definieren,
die sämtliche Regeln enthalten, die jeder Mitarbeiter zwingend einhalten muss.
Dabei sind die sicherheitsrelevanten Ereignisse (Security Incidents) zu benennen
und es ist zu beschreiben, wie damit umzugehen ist. Diesbezüglich müssen die
Mitarbeiter geschult und für das Thema Sicherheit im Allgemeinen sensibilisiert
werden. Alle Geschäftsprozesse des Unternehmens sind auf mögliche Sicherheitsrisiken zu untersuchen. Die Eintrittswahrscheinlichkeit eines Security Incidents
und die potentielle Schadenshöhe müssen bewertet werden, so dass man Prioritäten erkennen kann. Aus dieser Beurteilung sind Gegenmaßnahmen abzuleiten
[Boc06, S. 134f.].
Business-Relationship-Management Für den Umgang mit Kunden sind
klare Regeln zu definieren. Es ist sinnvoll, Anfragen nach einer standardisierten
Vorgehensweise zu bearbeiten und Vorlagen für die strukturierte Durchführung
von Kundenterminen zu erstellen. Die Kommunikation mit den Kunden ist zu
dokumentieren. Als zentrale Ansprechpartner für alle IT-Fragen können Geschäftsfeldbetreuer bestimmt werden, die die Kundenanforderungen verwalten.
In regelmäßigen Abständen sind Reviews mit den Kunden durchzuführen, um
die erbrachten Services und Änderungswünsche zu diskutieren. Für den Umgang
67
mit Beschwerden muss ein Prozess erstellt werden, der sicherstellt, dass alle
Beschwerden aufgezeichnet, bearbeitet und abgeschlossen werden. Die Kundenzufriedenheit ist regelmäßig durch eine Umfrage zu überprüfen. Die erhobenen
Informationen sollen helfen, die Leistungen zu verbessern [Boc06, S. 121f.].
Lieferanten-Management Es sind Grundsätze zu formulieren, wie die Zusammenarbeit mit den Lieferanten aussehen soll. Jedem Lieferanten wird ein verantwortlicher Manager zugeordnet, der als zentraler Ansprechpartner alle Vorgänge im Blick hat. Es sollte definiert werden, wer was bestellen darf und welche
Verträge durch Juristen geprüft werden müssen. Die Lieferantenverträge sind
an die Anforderungen der Service-Level-Vereinbarungen anzupassen. Es sollte
ein laufendes Monitoring von Leistungen und Preisen durchgeführt werden. In
regelmäßigen Gesprächen müssen mit den Lieferanten die erbrachten Leistungen und Maßnahmen zur Verbesserung der Zusammenarbeit diskutiert sowie
die zukünftigen Strategien abgestimmt werden. Für den Vertragsabschluss, Änderungen und die Auflösung von Verträgen, insbesondere bei Streitfällen, sind
Prozesse zu definieren. Es empfiehlt sich, alle Festlegungen dieses Prozesses in
einem zentralen Dokument festzuhalten [Boc06, S. 114f.].
2.3.3
Fragenkatalog zur Prozessumsetzung
Die in diesem Kapitel wiedergegebenen Fragen jedes einzelnen Prozesses stellen
eine Art Checkliste für eine Zertifizierung nach ISO/IEC 20000 dar. Sie zeigen
Anhaltspunkte für die jeweiligen Prozessmanager auf und dienen der Aufdeckung von Schwachstellen innerhalb des jeweiligen Prozesses.
Management-System
• Ist ein IT-Service-Management, eine Strategie, bzw. eine Zielsetzung vorhanden?
• Sind genügend Ressourcen zur Planung, Überwachung, Durchführung und
Verbesserung einzelner Handlungen vorhanden?
• Werden die Zuständigkeiten und die hinreichenden Kompetenzen für alle
Rollen bestimmt?
• Sind Verantwortliche und Zuständigkeiten zur Erstellung und Aktualisierung von Dokumenten vorhanden?
• Ist der Schulungsbedarf der Mitarbeiter so geregelt, dass diese ihre Aufgaben kompetent und effektiv erfüllen?
• Ist eine Identifikation von Kundenanforderungen vorhanden und wird diese von den Mitarbeitern erfüllt?
• Sind sich die Mitarbeiter des Unternehmens über die Orientierung an
Kundenanforderungen bewusst, d.h. sehen sie die Relevanz der ServiceErbringung?
• Sind die einzelnen Prozesse aufeinander abgestimmt?
68
Planung und Implementierung des Service-Managements
• Werden die Prozesse des IT-Service-Managements im Unternehmen identifiziert?
• Besteht eine klare Vision bzw. klare Leitlinien des Managements zur Überprüfung des Service-Managements-Plans?
• Ist die Zuständigkeit in Fragen zur Serviceverbesserung eindeutig festgelegt?
• Legt der Service-Management-Plan den Bereich des Service-Managements
in dem Unternehmen fest und zeigt dieser verschiedene Zielerreichungen
und Schnittstellen zwischen den Service-Management-Prozessen auf?
• Stimmen die Prozessziele mit denen des Service-Management-Plans überein?
• Sind alle Verbesserungsmöglichkeiten überprüft, dokumentiert und freigegeben?
• Besteht die Möglichkeit, Verbesserungsmaßnahmen überhaupt zu identifizieren, die mehr als einen einzelnen Prozess betreffen?
• Gibt es Management-Reviews, die überprüfen, ob Konformität der Anforderungen an das Service-Management mit den Vorgaben des ISO/IEC
20000 besteht.
• Wurden alle Non-Konformitäten behoben?
• Werden durch das Unternehmen Handlungen durchgeführt, die Verbesserungen identifizieren, ggf. Strategien und Ziele überarbeiten, sowie die
Umsetzung aller freigegebenen Maßnahmen sicherstellen?
• Wird die Objektivität bei einem internen Audit sichergestellt, d.h. das
Auditoren nicht ihre eigene Arbeit auditieren?
Service-Level-Management
• Werden die angebotenen Services in einem Service-Level-Agreement definiert und dokumentiert?
• Ist eine Berichterstattung und Überprüfung sowie aktuelle Informationen
und Entwicklungen über die erreichten Service-Levels vorhanden?
• Werden die Gründe, wenn ein Ziel nicht erreicht wird, korrigiert und überprüft?
• Werden verschiedene Reviews durchgeführt?
69
Service Reporting
• Steht eine detaillierte Beschreibung der einzelnen Berichte, die Informationen über verwendete Datenquellen, Zwecke und Identitäten enthalten,
zur Verfügung?
• Sind alle erforderlichen Berichte und Dokumente vorhanden und stets aktuell?
• Werden erlangte Ergebnisse und Optimierungspotentiale in den Entscheidungen des Managements berücksichtigt?
Service-Continuity-Management
• Sind Pläne vorhanden, die die Services nach einem Ausfall und den Normalzustand des Systems wieder herstellen?
• Wenn ein normaler Zugang zum Büro nicht möglich ist, sind dann die
CDMB, die Kontaktliste und der Notfallplan für die befugten Mitarbeiter
zugänglich?
• Ist ein proaktives Vorgehen, die Zusammensetzung der Teams im Notfall
und ein Vorgehen im Notfall definiert?
• Existiert eine jährliche Überprüfung der Notfallpläne?
• Werden die Ergebnisse einer Prüfung in Maßnahmeplänen festgehalten?
Availability-Management
• Ist ein Verfügbarkeitsplan vorhanden und wird dieser auf veränderte Geschäftsanforderungen aktualisiert?
• Wird die Verfügbarkeit des benötigten Services für den Geschäftsprozess
sichergestellt?
• Existieren präventive Maßnahmen für ungeplante Ausfallzeiten?
• Wird die Verfügbarkeit des Services gemessen und dokumentiert?
Finanzplanung mit Kostenrechnung für IT-Service
• Ist eine eindeutig definierte Finanzplanung und Kostenrechnung für alle
Komponenten vorhanden?
• Besteht eine effiziente Kontrolle und Genehmigung der Finanzen?
• Reichen die Finanzen aus, um eine zukünftige Kontrolle und Entscheidungsfindung durchzuführen?
• Erfolgt ein kontinuierlicher Vergleich der anfallenden Kosten mit dem vorhandenen Budget und werden Maßnahmen bei einer erheblichen Abweichung eingeleitet?
70
Capacity-Management
• Ist ein Kapazitätsplan vorhanden und wird dieser kontinuierlich aktualisiert?
• Werden Request for Changes erstellt?
• Werden vom Kapazitätsmanagement zukünftige Geschäftsanforderungen,
vorhersehbare Auswirkungen neuer Technologien und Techniken, Auswirkungen externer Veränderungen, aktuelle Leistungs- und Kapazitätsanforderungen sowie Daten und Prozesse zur Analysenbetrachtung aufgezeigt?
• Erfolgt die Identifizierung von Verfahren, Mechanismen und Techniken,
um die Serviceleistungen und -kapazität aufzuzeigen?
Information-Security-Management
• Ist die Sicherheitspolitik für Mitarbeiter und Kunden ausreichend festgelegt?
• Sind effiziente Sicherheitsmaßnahmen zur Implementierung dieser Vorgaben der Politik vorhanden?
• Existieren Maßnahmen zur Behandlung von Risiken?
• Existiert die Dokumentation der Sicherheitsmaßnahmen?
• Wird bei der Beschreibung dieser Maßnahmen Bezug auf verschiedene
Risiken und Wartung dieser genommen?
• Wird untersucht, ob Changes ein Sicherheitsrisiko darstellen?
• Werden alle Security-Incidents erkannt, überprüft, entsprechend dem Incident-Prozess abgearbeitet und werden entsprechende Maßnahmen ergriffen?
Business-Relationship-Management
• Werden die Stakeholder der einzelnen Services identifiziert und schriftlich
festgehalten?
• Sind Verantwortliche für die Bestimmung der Kundenzufriedenheit festgelegt?
• Ist das Unternehmen auf zukünftige Änderungen der Geschäftsanforderungen der Kunden vorbereitet?
• Werden regelmäßige Besprechungen mit den Kunden zur Standortbestimmung durchgeführt und dokumentiert?
• Sind für Reklamationen von Kunden entsprechende Prozesse eingeführt?
71
Lieferanten-Management
• Sind dokumentierte Lieferanten-Management-Prozesse vorhanden?
• Existiert für jeden Lieferanten ein Verantwortlicher?
• Sind alle Prozessschnittstellen vereinbart und beschrieben?
• Besteht eine Dokumentation von Rollen und Interaktionen von Hauptund Unterlieferanten?
• Werden, um die vertraglichen Verpflichtungen und die geschäftlichen Notwendigkeiten einzuhalten, größere Reviews mindestens einmal im Jahr
durchgeführt?
• Gibt es Verfahren für die Überwachung der Leistung interner und externer
Lieferanten?
Incident-Management
• Besteht eine Aufzeichnung aller Incidents und eine nachgelagerte Ticketerfassung?
• Enthält der Prozess die Aktivität der Aufzeichnung, Priorisierung, Beurteilung der Geschäftsauswirkungen, Klassifikation, Aktualisierung, Eskalation, Lösung und ein formaler Abschluss?
• Werden alle offenen Tickets ausgewertet und die Kunden über die Entwicklung ihrer gemeldeten Incidents informiert?
• Erfolgt eine eindeutige Zurechenbarkeit der Tickets zu einem Mitarbeiter
und zu einem Kunden?
• Wie wird mit der Eskalation umgegangen?
• Ist die Übergabe der Incidents ins Problem-Management eindeutig möglich?
Problem-Management
• Erfolgt eine Dokumentation der auftretenden Probleme durch die Verantwortlichen?
• Wird die Prävention von Fehlern als ein relevanter Teil des ProblemManagements angesehen?
• Werden die Probleme eindeutig klassifiziert?
• Erfolgt eine Weiterleitung aller Verbesserungen und Veränderungen, die
Incidents und Fehler verhindern können, über das Change-Managements?
• Unterliegt die Wirksamkeit des Prozesses einer Überwachung und Überprüfung?
72
Configuration-Management
• Sind Schnittstellen zur Anlagenbuchhaltung vorhanden?
• Existiert eine Begriffsabgrenzung eines Konfigurationselements (CI) und
deren zugehörigen Komponenten?
• Werden durch das Configuration-Management Mechanismen zur Identifikation, Steuerungsmöglichkeiten und Versionsverfolgung bereitgestellt?
• Informiert das Configuration-Management das Change-Management über
Veränderungen?
• Wird die Configuration Management Data Base (CMDB) überprüft und
verwaltet, um Zuverlässigkeit und Genauigkeit zu garantieren?
• Erfolgen Audits zur CMDB?
Change-Management
• Werden Veränderungen des Services und der Infrastruktur in einem angemessenen Umfang dokumentiert?
• Erfolgt eine Beurteilung sogenannter Veränderungsanträge hinsichtlich bestimmter Risiken, Auswirkungen, Sicherheitskontrollen und finanzieller
Gegebenheiten?
• Existieren formelle Verfahren, die alle Changes hinsichtlich ihrer Aussicht
auf Erfolg prüfen, kontrollierend einführen und genehmigen?
• Werden wiederkehrende Ergebnisse und relevante Informationen aufgedeckt?
• Gibt es bei der Einführung veränderter und neuer Services eine wirksame
Planung und Überprüfung durch das Change-Management?
• Befasst sich das Unternehmen bei einer Veränderung des Services mit Zeitplänen, bestimmten Zuständigkeiten der Mitarbeiter, Kommunikation mit
relevanten Abteilungen, erwarteten Ergebnissen sowie Handlung bzgl. des
Kompetenz- und Schulungsbedarfs?
• Erfolgt eine Weitergabe der veränderten Ergebnisse an alle Mitarbeiter
des IT-Bereichs?
Release-Management
• Existiert eine Politik, die verschiedene Arten von Releases enthält?
• Besteht eine Absprache der Planung der Releases bzw. der Software und
Hardware mit dem Kunden?
• Werden Vorgehensweisen beschrieben, wie z.B. die Revidierung von nicht
erfolgreichen Releases erfolgt?
• Werden die Changes nach Ausbringung eines Releases auf dem aktuellem
Stand gehalten?
73
Assessment
Maßnahmenplan
Entscheidung
Prozessumsetzung
Internes Audit
vor der Zertifizierung
Erforderliche Korrekturen
Korrekturmaßmahmen
Zertifizierungsaudit
Zertifikat
Abbildung 2.5: Der Weg zum Zertifikat. Quelle: Eigene Darstellung in Anlehnung an [Boc06].
• Werden Erfolge und Misserfolge von Releases bewertet, gemessen und regelmäßig analysiert, um deren Folgen auf bestimmte IT-Tätigkeiten und
Geschäftstätigkeiten zu überwachen?
• Erfolgt eine Zuordnung von Incidents zu den entsprechenden Releases?
• Wie funktioniert die Zusammenarbeit mit dem Change-Management?
([Boc06, S. 255ff.])
2.3.4
Zertifizierungsprozess
Sind die Anforderungen des Standards ISO/IEC 20000 umgesetzt, kann der
Zertifizierungsprozess eingeleitet werden. Dieser beinhaltet die interne Auditierung und entsprechende Korrekturmaßnahmen unmittelbar vor der Zertifizierung sowie den eigentlichen Zertifizierungsaudit und die weitere Vorgehensweise
im Anschluss daran. Der Prozess wird in Abbildung 2.5 dargestellt.
Das interne Audit stellt einen letzten Check vor der Zertifizierung dar, bei dem
erforderliche Korrekturen identifiziert werden sollen, um noch rechtzeitig entsprechende Maßnahmen einleiten zu können. Es wird überprüft, ob die Anforderungen des Standards ISO/IEC 20000 verstanden, umgesetzt und gelebt werden. Es ist zu empfehlen, dafür jenes Beratungsunternehmen zu beauftragen,
das bereits das Assessment durchgeführt hat. Das interne Audit dauert normalerweise zwei bis drei Tage [Boc06, S. 233]. Es sind Besprechungsräume zu reservieren und sämtliche Dokumente zur Verfügung zu stellen. In Gesprächen mit
dem IT-Management werden grundsätzliche Dinge geklärt, wie die Umsetzung
des Management-Systems. Die Prozessmanager müssen den jeweiligen Prozess
beschreiben und berichten, was bereits umgesetzt ist. Sämtliche erforderlichen
74
Prozessaufzeichnungen und Dokumente werden überprüft. Als Ergebnis erhält
man einen Maßnahmenplan, was bis zur Zertifizierung noch umgesetzt werden
muss. Es sollte genügend Zeit eingeplant werden, um die Korrekturmaßnahmen, die für eine erfolgreiche Zertifizierung zwingend erforderlich sind, bis zum
Zertifizierungsaudit durchführen zu können [Boc06, S. 239].
Der Zertifizierungsaudit wird durch eine offizielle Zertifizierungsstelle (Registered Certificated Body) durchgeführt. Die Mitgliedsländer der International
Organization for Standardization (ISO) verfügen über nationale Akkreditierungsstellen, die geprüften Zertifizierungsstellen das Recht übertragen, Organisationen nach ISO/IEC 20000 zu zertifizieren [SMF06, S. 17f.]. In Deutschland
zählt beispielsweise die TÜV SÜD Management Service GmbH zu den offiziellen
Zertifizierungsstellen. Dabei ist zu beachten, dass Prüfungsunternehmen keine
Beratungsleistungen anbieten dürfen, um die Unabhängigkeit zu gewährleisten.
Die Anmeldung zur Zertifizierung sollte mindestens vier Monate vor dem geplanten Termin erfolgen. Die Unterlagen dazu sind bei der Zertifizierungsstelle
anzufordern. Es müssen Angaben zum Unternehmen und dem zu zertifizierenden
Bereich gemacht werden und es ist ein Termin aus den Vorschlägen der Zertifizierungsstelle auszuwählen. Spätestens einen Monat vor der Zertifizierung sind
sämtliche erforderlichen Unterlagen bei der Zertifizierungsstelle einzureichen.
Sobald der zeitliche Ablauf mit der Zertifizierungsstelle abgestimmt ist, sind die
Räumlichkeiten vorzubereiten und die Anwesenheit aller erforderlichen Personen ist sicherzustellen. Es empfiehlt sich, die Mitarbeiter durch Schulungen und
Bewusstseinsbildung auf die Zertifizierung vorzubereiten, beispielsweise durch
die Teilnahme an einem ITIL-Foundation-Kurs [Boc06, S. 240f.].
Der Ablauf des Zertifizierungsaudits ähnelt dem des internen Audits bzw. des
Assessments. Bei einem einführenden Gespräch mit allen Teilnehmern verschafft
sich der Zertifizierer einen Überblick über die Aufgaben und Tätigkeiten und
erklärt den Ablauf der Zertifizierung. Es folgt ein Interview mit der IT-Führung
hinsichtlich der Anforderungen an das Management-System und den kontinuierlichen Verbesserungsprozess. Im Anschluss daran wird für jeden Prozess eine Befragung des zuständigen Prozessmanagers durchgeführt. Dabei wird zum einen
kontrolliert, ob der Prozessmanager den Prozess auch wirklich versteht, und
zum anderen wird die Umsetzung aller Anforderungen des Standards ISO/IEC
20000 überprüft. Zum Abschluss trägt der Zertifizierer seine Erkenntnisse vor
und gibt bekannt, ob er der Zertifizierungsstelle die Ausstellung des Zertifikats
vorschlägt. Die Zertifizierungsstelle trifft dann anhand dieses Vorschlags und der
Protokolle des Audits eine Entscheidung [Boc06, S. 252f.].
Bei erfolgreicher Zertifizierung erhält der IT-Service-Provider das Zertifikat, und
er ist ermächtigt, das offizielle Zertifizierungslogo zu verwenden. Desweiteren
wird er gesondert auf der Internetseite der Zertifizierungsstelle gelistet. Dieser
Projekterfolg sollte durch professionelles Marketing bekannt gemacht werden.
Das Zertifikat hat eine Gültigkeit von drei Jahren. Danach findet ein Wiederholungsaudit statt. Jährlich werden zudem Überwachungsaudits durchgeführt
[SMF06, S.19f.]. Insofern ist nach der Zertifizierung besonders wichtig, dass die
Prozesse im Unternehmen auch gelebt werden und eine kontinuierliche Weiterentwicklung und Verbesserung nach dem KVP-Ansatz erfolgt. Dies kann durch
eine regelmäßige Erfassung und Überprüfung der für die Prozesse etablierten
Kennzahlen sichergestellt werden [Boc06, S. 270f.].
2.4
75
Beurteilung der Zertifizierung
Der IT-Service spielt bei der Kundenbetreuung eine wichtige Rolle. Die Umsetzung der Anforderungen des Standards ISO/IEC 20000 führt dazu, dass die
IT-Dienstleistungen effizient gesteuert werden und den Kundenbedürfnissen angepasst sind. Mit der Zertifizierung nach ISO/IEC 20000 durch eine offizielle
unabhängige Zertifizierungsstelle kann somit eine hohe Servicequalität objektiv
nachgewiesen und den Kunden gegenüber belegt werden. Das ist insbesondere
für Unternehmen relevant, die das Outsourcing und die Verwaltung und von
IT-Services anbieten. Das Zertifikat kann als Marketing-Instrument verwendet
werden, um die Reputation am Markt zu erhöhen und damit die Wettbewerbsfähigkeit zu steigern. Gegenüber Kunden, Kreditgebern, Aktionären, Mitarbeitern
und öffentlichen Einrichtungen wird eine breite Vertrauensbasis geschaffen. Aufgrund der Aktualität der Thematik gilt ein zertifiziertes Unternehmen zudem
als besonders innovativ [Boc06, S. 269].
Firmenintern hat die Zertifizierung zur Folge, dass die IT-Mitarbeiter durch
die intensive Beschäftigung mit dem Thema ein besseres Verständnis von den
Prozessen, den Zielen und Strategien sowie von ihrer eigenen Rolle im Unternehmen entwickeln. Es bilden sich eine gemeinsame Sprache und ein einheitlicher
Kenntnisstand von den Prozessabläufen. Durch Effizienzsteigerungen können die
Kosten für die eingesetzten Systeme reduziert werden. Die unabhängige Beurteilung des Reifegrads der Prozesse und des Service Managements bildet eine
Orientierungshilfe und die Grundlage für den kontinuierlichen Verbesserungsprozess [Boc06, S. 268f.].
Allerdings ist bis zum Erhalt des Zertifikats ein langer Weg zurückzulegen, wie
sich in den vorangegangenen Kapiteln gezeigt hat. Der Standard ISO/IEC 20000
stellt hohe Anforderungen an Unternehmen und Prozesse. Dies gilt auch für Unternehmen, die ITIL-erfahren sind. Eine Vielzahl von Unternehmen beschränkt
sich bei der Einführung von ITIL auf nur wenige Prozesse, wie zum Beispiel
das Incident-Management, das Change-Management oder das ConfigurationManagement. Voraussetzung für die Zertifizierung ist allerdings, dass alle vorgegebenen Prozesse im Unternehmen umgesetzt sind. Es ist ein großer Aufwand
zu betreiben, um dieses Ziel zu erreichen. Und da das Zertifikat nur eine begrenzte Gültigkeit besitzt, fallen auch langfristig Aufwände an.
Auch für Unternehmen, die zunächst keine Zertifizierung anstreben, stellt der
Standard ISO/IEC 20000 eine wertvolle Informationsquelle und Leitlinie dar.
Dies gilt insbesondere für Unternehmen, die ihr Handeln und Vorgehen auf die
ITIL-Prinzipien abgestimmt haben und sich bei der Implementierung der Prozesse des IT Service Managements auf die ITIL-Richtlinien berufen. Wenn sich
ein Unternehmen an die Vorgaben des Standards ISO/IEC 20000 hält, kann es
sicher sein, dass seine IT-Dienstleistungen eine hohe Qualität besitzen. Der im
Standard beschriebene kontinuierliche Verbesserungsprozess bietet die Möglichkeit, die Servicequalität regelmäßig zu überprüfen und ständig weiterzuentwickeln.
Unternehmen müssen die Einhaltung einer Vielzahl behördlicher Vorschriften
und Regelungen nachweisen. Besonders auf das IT Service Management und die
IT-Services beziehen sich viele der Vorschriften. Zu nennen ist das SarbanesOxley-Gesetz und das HIPAA-Gesetz (Health Insurance Portability and Accountability Act) von 1996 aus den USA. Zum Nachweis der Einhaltung dieser
Vorschriften fordern Wirtschaftsprüfer bislang keine Zertifizierung für bestimm-
76
te Standards und Normen. Aufgrund seines Bezugs zur Qualität des IT Service
Managements bietet sich der Standard ISO/IEC 20000 als internationaler Standard zur Überprüfung der Einhaltung behördlicher Vorschriften im Rahmen von
Wirtschaftsprüfungen an [BMC06, S. 5].
Die Zertifizierung nach ISO/IEC 20000 wird sich für viele IT-Service-Anbieter
trotz des hohen Aufwands lohnen. Ein offizielles Prüfsiegel nach international
anerkannten Standards ist wohl der beste Qualitätsnachweis gegenüber den
Kunden. Bei der Auftragsvergabe im IT-Sektor wird eine Zertifizierung nach
ISO/IEC 20000 zunehmend zur zwingenden Voraussetzung. Unternehmen, die
sich aufgrund einer Kosten-Nutzen-Analyse gegen die Zertifizierung und den damit verbundenen Wettbewerbsvorteil entscheiden, können den Standard in Ergänzung zu ITIL als Leitlinie zur Verbesserung ihrer IT-Services nutzen [ISM06].
2.5
Fazit
Die Zertifizierung nach dem Standard ISO/IEC 20000 bietet IT-Dienstleistern
die Möglichkeit, die Konformität mit dem ITIL Rahmenwerk objektiv zu belegen. Der Standard definiert verbindliche Vorgaben für das IT Service Management, die für eine Zertifizierung vollständig umgesetzt werden müssen. Es sind
neben den auf ITIL basierenden Prozessen das Management-System, die Planung und Implementierung des Service-Managements, das Service Reporting,
das Information-Security-Management, das Business-Relationship-Management
sowie das Lieferanten-Management umzusetzen.
Die Entscheidung für eine Zertifizierung nach ISO/IEC 20000 sollte auf der
Grundlage einer Standortbestimmung des IT-Bereiches und eines dabei erarbeiteten Maßnahmenplanes mit notwendigen Korrekturen getroffen werden. Die
praktische Umsetzung der Anforderungen ist abhängig von den gegebenen Rahmenbedingungen sowie der Unternehmensstrategie und den Zielen. Der Code
of Practice des Standards stellt Leitlinien und Empfehlungen zur Umsetzung
der Anforderungen zur Verfügung. Abweichungen von diesen Erläuterungen der
Best Practices sind erlaubt, so dass das IT Service Management individuell ausgestaltet werden kann. Der in der Arbeit dargestellte Fragenkatalog dient als
Hilfestellung bei der Prozessumsetzung.
Vor der Zertifizierung wird ein interner Audit durchgeführt, um letzte erforderliche Anpassungen zu identifizieren. Sind die Korrekturmaßnahmen umgesetzt,
kann der Zertifizierungsaudit durchgeführt werden. Dies erfolgt durch eine offizielle Zertifizierungsstelle in Form von Interviews. Dabei wird überprüft, ob
die Anforderungen des Standards ISO/IEC 20000 verstanden, umgesetzt und
gelebt werden. Erfüllt der IT-Service-Anbieter sämtliche Voraussetzungen, wird
ein Zertifikat ausgestellt.
Durch eine erfolgreiche Zertifizierung wird nachgewiesen, dass effiziente ITServices angeboten werden, die den Kundenbedürfnissen entsprechen. Da in der
Geschäftspraxis dieser Nachweis der Servicequalität zunehmend vorausgesetzt
wird, wird dadurch die Wettbewerbsfähigkeit gesteigert. Daneben erhöht sich
die Reputation des Unternehmens am Markt. Trotz des hohen Aufwands wird
sich daher für viele IT-Service-Anbieter die Zertifizierung nach ISO/IEC 20000
lohnen. Und auch für Unternehmen, die keine Zertifizierung anstreben, bringt
die Umsetzung des Standards eine Reihe von Vorteilen mit sich.
Die vorliegende Arbeit bezieht sich primär auf das Buch „ITIL Zertifizierung
77
nach BS 15000/ISO 20000“ von den Autoren Wolfgang Bock, Günter Macek,
Thomas Oberndorfer und Robert Pumsenberger und auf den Standard ISO/IEC
20000 selbst. Dies liegt daran, dass zum Zeitpunkt der Erstellung der Arbeit
noch keine weitere einschlägige Literatur zur Verfügung stand. Für Interessierte an weiterer Literatur sind wir bei unserer Recherche auf folgende Bücher
gestoßen, deren Veröffentlichung noch aussteht:
• ISO 20000 - Eine Einführung für Manager und Projektleiter. Dohle, H. /
Schmidt, R., Dpunkt Verlag, 1. Auflage, 2008.
• ISO 20000 - Praxishandbuch für Servicemanagement und IT-Governance.
Andenmatten, M., Symposion Publishing, Düsseldorf 2008.
• ISO/IEC 20000 - An Introduction. itSMF, Van Haren Publishing, 1. Auflage, Zeewolde / Niederlande 2008.
• Implementing ISO/IEC 20000 Certification - The Roadmap. itSMF, Van
Haren Publishing, 1. Auflage, Zeewolde / Niederlande 2008.
78
[BMC06] BMC Software. http://documents.bmc.com/products/
documents/49/66/64966/64966.pdf [21.01.08].
[Boc06]
Bock, W. / Macek, G. / Oberndorfer, T. / Pumsenberger, R.: ITIL
Zertifizierung nach BS 15000 / ISO 20000, Galileo Computing,
1.Auflage, Bonn 2006.
[Cod05] International Organization for Standardization / International
Electrotechnical Commission: ISO/IEC 20000-2: Code of practice, 1.
Auflage, Geneva / Schweiz 2005.
[Gar06]
Marktforschungsunternehmen Gartner, URL: www.gartner.com
[15.01.08].
[ISM06] Competence Site, URL: http://www.competence-site.de/
itmanagement.nsf/5438155EE69CF678C125728B0042967B/$File/
it-service-management_iso_20000.pdf [21.01.08].
[SMF06] The IT Service Management Forum: ISO/IEC 20000 - Das
Taschenbuch, Van Haren Publishing, 1. Auflage, Zeewolde /
Niederlande 2006.
[Spe05]
International Organization for Standardization / International
Electrotechnical Commission: ISO/IEC 20000-1: Specification, 1.
Auflage, Geneva / Schweiz 2005.
79
80
Kapitel 3
ITIL und IT-Sicherheit
Synergien zwischen Security Management und Service Support nutzen
Björn Borgmeier, Michael Bochenek, Tim Kattner
3.1
Einleitung
Sicherheit und Schutz sind Grundbedürfnisse der Menschheit. Im gleichen Maße gilt dies für Prozesse der Informations- und Kommunikationstechnik (IT).
Während in Zeiten immer größere Vernetzung die Komplexität und Abhängigkeit von der IT stetig wächst, nehmen ebenso Gefahren und Risiken für Informationstechnologien zu. Die Bedrohungen sind vielfältiger Art und reichen
von Wirtschaftsspionen und Hackern über Viren bis hin zu eigenen Anwendern.
Bedingt durch die gestiegene Verwundbarkeit und Gefahr wirtschaftlicher Schäden haben sowohl Handlungsdruck als auch Anforderungen an ein effizientes
IT-Security Management zugenommen.
Trotz dieser Entwicklung herrscht in vielen Fällen eine weit verbreitete Fehleinschätzung über den eigenen Schutzbedarf bei den Unternehmen. Im Zuge
sinkender IT-Budgets werden Maßnahmen nur noch implementiert, sofern sie
die Produktivität der Geschäftsprozesse erhöhen oder einen Wettbewerbsvorteil
generieren. Die Tatsache alleine, dass in der Vergangenheit keine Sicherheitsvorfälle erkannt wurden, bedeutete nicht, dass keine Vorlagen oder die Sicherheitsmaßnahmen ausreichend sind. Security Management ist kein statischer Zustand,
sondern ein dynamischer Prozess.[Bsi07, S. 6]
Unternehmen suchen oftmals nach praxisbewährten Lösungen, die erfolgreich
implementiert worden sind und einen Großteil des Aufgabenspektrums abdecken. Eine solche Best Practice Lösung ist ITIL. Der momentane Trend geht
dazu, IT-Prozesse gemäß ITIL neu zu entwickeln bzw. zu restrukturieren. Dies
bietet einerseits die Möglichkeit Informationssicherheit vorteilhafter in die ITProzesse zu integrieren und andererseits eine bessere Arbeitsverteilung zwischen
IT-Bereich und Security Management zu ermöglichen. Zudem bietet es die Chance das Thema Sicherheit stärker in den Fokus zu rücken und diesbezüglich die
81
82
Akzeptanz seitens der Unternehmensleitung zu erhöhen.[Bsi05, S. 12].
Ziel dieser Arbeit soll es zum einen sein, einen kurzen Überblick über das Thema
IT-Sicherheit zu liefern, aber vor allem sollen die positiven Effekte des Zusammenwirkens von IT-Security und IT-Service Management aufgezeigt werden.
Hierbei stehen nicht die konkreten Maßnahmen des Security Managements im
Vordergrund, sondern ein prozessorientiertes Vorgehen, welches exemplarisch
am Beispiel des Service Supports, der operativen Ebene beschrieben wird.
Die vorliegende Arbeit gliedert sich dabei in vier Kapitel. Nach der Einleitung
folgt ein Grundlagenkapitel, indem die für den weiteren Verlauf notwendigen
Begrifflichkeiten des Security Managements erörtert werden. Das dritte Kapitel stellt den Hauptteil der Arbeit dar. Hier werden die einzelnen Prozesse des
Service Supports kurz vorgestellt und anschließend die sich bietenden Synergieeffekte mit dem Security Management aufgezeigt. Einen Abschluss findet die
Arbeit in einem kurzen Fazit und der Zusammenfassung der gewonnenen Erkenntnisse.
3.2
Grundlagen des IT-Security Management
Das nachfolgende Kapitel stellt eine Einführung in den Bereich des Security Managements dar. Um eine Diskussionsgrundlage für die weiteren Kapitel zu schaffen, wird zunächst der Begriff Informationssicherheit definiert und die einzelnen
Dimensionen der Informationssicherheit vorgestellt. Da die IT-Sicherheit unter
anderem bedingt durch das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (§ 91 Abs. 2 AktG) nicht mehr nur Aufgabe der IT-Abteilung ist,
sondern auch die Unternehmensleitung gesetzlich verpflichtet ist, dafür Sorge zu
tragen [Köh06, S. 204], werden zusätzlich gesetzliche Anforderungen und Vorschriften an die Informationssicherheit und den Datenschutz vorgestellt. Nachdem Ziele und Aufgaben des Security Managements präsentiert werden, findet
das Kapitel seinen Abschluss mit einer Einordnung des Security Managements
in ITIL.
3.2.1
Informationssicherheit
Oftmals sind es bestimmte Informationen oder fachspezifisches Know-how, das
den Unternehmen auf den hart umkämpften Märkten einen Wettbewerbsvorteil
gegenüber ihren Konkurrenten verschafft.[Bru06, Vorwort des Verfassers] Aus
diesem Grund kommt der Sicherung und dem Schutz dieser Informationen und
deren Systemen eine hohe Bedeutung zu.
Der Begriff IT-Informationssicherheit ist stark durch die Sicht der Verlässlichkeit [Die04, S. 346] geprägt, welche durch die drei Dimensionen Verfügbarkeit,
Vertraulichkeit und Integrität gekennzeichnet ist. Ein IT-System gilt als sicher,
sofern es den drei Grundbedrohungen jeder Informationsverarbeitung Stand
hält.[Die04, S. 347] Es handelt sich bei diesen Bedrohungen um unbefugten
Informationsgewinn, unbefugte Veränderung der Funktionalität und unbefugte
Modifikation.
Vertraulichkeit. Unbefugter Informationsgewinn geht einher mit dem Verlust der Vertraulichkeit. Geraten wichtige Informationen in die falschen Hände,
83
kann dieses schwerwiegende wirtschaftliche Schäden nach sich ziehen. Um diesem Datendiebstahl/ -missbrauch entgegen zu wirken, gibt es diverse Möglichkeiten, angefangen bei der Nutzung sicherer Informationskanäle über Verschlüsselungsalgorithmen bis hin zur Schaffung von Zugangsbarrieren (Passwörter,
PIN, etc.).
Obendrein sollte in diesem Zusammenhang nach dem sogenannten „Need-toknow-Prinzip“ verfahren werden, nach dem jeder Benutzer (auch der Administrator) lediglich die Berechtigungen (Zugriffe auf Datenbestände und Programme) erhält, die er für seine tägliche Arbeit benötigt.[Bsi07, S. 14]
Verfügbarkeit. Die Verfügbarkeit eines DV-Systems ist gefährdet bzw. geht
verloren, wenn die Funktionalität unbefugt oder durch technisches Versagen gestört wird. Mögliche Indikatoren für eine solche gestörte Verfügbarkeit sind der
Ausfall der Informationsverarbeitung, Sabotage der Verarbeitungsprozesse und
Zerstörung bzw. Löschen von Daten durch unbefugte Personen. Die Etablierung redundanter Einheiten (Backup Server, etc.) oder die Verschärfung der
Zugangsrestriktionen für Unbefugte sind zwei von mehreren Optionen, um diesem entgegen zu treten.
Integrität. Werden sensible Daten, Programme oder Geräte unerlaubt verändert bzw. modifiziert, so tritt eine Beeinträchtigung oder der Verlust der Integrität ein. Ein solcher Verlust der Integrität liegt bspw. vor, wenn Informationen
unbewusst falsch verarbeitet oder verfälscht werden.[Köh06, S., 208] Ebenso ist
denkbar, dass bewusste Veränderungen an Informationen vorgenommen wurden,
wie es bspw. MalWare1 tut. Auch in diesem Fall sind eine restriktive Vergabe
der Nutzungsrechte und Zugangskontrollen Alternativen, um die Vollständigkeit, Korrektheit und Unverfälschtheit der Informationen zu gewährleisten.
Neben der Verlässlichkeit schützenswerter Informationen hat in der jüngeren
Vergangenheit auch deren Beherrschbarkeit mehr und mehr an Bedeutung gewonnen. Dabei steht nicht die technische Sicht (Sicherheit der Systeme), sondern
die Sicherheit der Betroffenen (Schutz vor dem System) im Vordergrund. Im
Zeitalter des Internets und der damit verbundenen Nutzung für Rechtsgeschäfte
(Online-Banking, E-Commerce, etc.) sind die bereits vorgestellten Hauptmerkmale der Informationssicherheit (Integrität, Vertraulichkeit und Verfügbarkeit)
deshalb um zwei Dimensionen zu erweitern. Es handelt sich hierbei um Zurechenbarkeit und Rechtsverbindlichkeit/Revisionsfähigkeit, die zusammen die
Sicht der Beherrschbarkeit bilden.[Die04, S. 249] Ist es möglich Daten oder Vorgänge einem Verursacher oder eine auslösende Instanz eindeutig zu zuordnen
und sind diese darüber hinaus von unabhängigen Personen oder Instanzen nachvollziehbar bzw. beweisbar, so sind Zurechenbarkeit sowie Rechtsverbindlichkeit
gewährleistet.
Die fünf vorgestellten Dimensionen der Informationssicherheit (Vertraulichkeit,
Verfügbarkeit, Integrität, Zurechenbarkeit und Rechtsverbindlichkeit)2 können
auch als Qualitätsmerkmale eines IT-Systems verstanden werden. Das Security
1 Als Malware bezeichnet man Computerprogramme, welche vom Benutzer unerwünschte
und ggf. schädliche Funktionen ausführen.
2 Neben diesen fünf Dimensionen wurden in der letzen Zeit eine Reihe weiterer möglicher
Dimensionen diskutiert, wie etwa Robustheit, Stabilität, Wartbarkeit, Flexibilität oder Beobachtbarkeit.
84
Management sollte bestrebt sein, diese Qualitätsmerkmale entsprechend der jeweiligen Anforderungen zu gewichten und anhand definierter Kriterien auf allen
Unternehmensebenen umzusetzen. Dabei darf jedoch nicht außer Acht gelassen
werden, dass der Aufwand für die Implementierung im Verhältnis zum Nutzen
stehen muss.[Bru06, S. 9]
3.2.2
Gesetzesanforderungen, Vorschriften und Standards
Ein IT-Sicherheitsvorfall kann nicht nur wirtschaftliche Schäden nach sich ziehen, sondern es bestehen mittlerweile auch gesetzliche Regelungen, aus denen
sich Handlungs- und Haftungsverpflichtungen für die Unternehmung (vor allem für die Geschäftsleitung) ableiten lassen. Aus diesem Grund soll in diesem Abschnitt kurz auf die gesetzlichen Anforderungen und Vorschriften an die
IT-Sicherheit sowie Standards, welche das IT-Security Management betreffen,
eingegangen werden.
Es gibt eine Reihe von Rechtsvorschriften, welche die verantwortlichen Personen
einer Unternehmung zur Rechenschaft ziehen, wenn es aufgrund eines nicht angemessenen IT-Sicherheitsniveaus zu wirtschaftlichen Schäden kommt. In Verbindung mit anderen gilt dies insbesondere für das Gesetz zur Kontrolle und
Transparenz in Unternehmensbereichen (KonTraG). Dieses Gesetz ist ein sogenanntes Artikelgesetz, welches verschiedene Gesetze wie das HGB oder AktG
ändert bzw. ergänzt. Kern des KonTraG ist eine Vorschrift, die die Unternehmensleitungen von Kapitalgesellschaften dazu zwingt, ein unternehmensweites
Früherkennungssystem für Risiken (Risikomanagement) einzuführen und zu betreiben sowie Aussagen bzgl. Risiken und Risikostruktur des Unternehmens im
Lagebericht des Jahresabschlusses der Gesellschaft zu veröffentlichen. Dies umfasst ebenfalls IT-Risiken.
Gemäß § 91 Abs. 2 des Aktiengesetzes hat der Vorstand einer Aktiengesellschaft geeignete Maßnahmen zu ergreifen, insbesondere ein Überwachungssystem einzurichten, damit gefährdende Entwicklungen früh erkannt werden, um
den Fortbestand der Unternehmung zu gewährleisten. Kommt der Vorstand dieser Forderung nicht nach, so haftet er persönlich.(§ 93 Abs. 2 AktG) Der Geltungsbereich dieser Vorschriften erstreckt sich auch auf das HGB.(§ 317 Abs. 4
HGB) Des Weiteren verpflichtet § 317 Abs. 2 HGB Abschlussprüfer zu prüfen,
ob die Risiken auch zutreffend dargestellt werden. Eine weitere Regelung, welche betroffen sein kann, ist der Paragraph 43 Abs. 1 des GmbHG, wonach für
die Geschäftsführung die „Sorgfalt eines ordentlichen Geschäftsmannes“ gilt.
Der Umgang mit personenbezogenen Daten wird in den Datenschutzgesetzen
des Bundes und der Länder geregelt.
Während bei der Datensicherheit die Gewährleistung der Verfügbarkeit, Vertraulichkeit und Integrität von Daten im Vordergrund steht, ist das Ziel des
Datenschutzes die freie Entfaltung der Persönlichkeit.[Köh06, S. 210] Um dies zu
gewährleisten, muss ein Schutz des Einzelnen vor Erhebung, Speicherung, Verwendung und Weitergabe seiner persönlichen Daten sichergestellt sein. Damit
liegt der Wirkungskreis des Datenschutzes in der Sicherstellung der informellen
Selbstbestimmung des Einzelnen.
Für bestimmte Berufsgruppen, wie Ärzte, Anwälte oder Angehörige sozialer
Berufe, gibt es im Strafgesetzbuch Sonderregelungen, die sogar Freiheitsstrafen
vorsehen, wenn vertrauliche Daten ihrer Patienten oder Klienten ohne deren
85
Zustimmung an die Öffentlichkeit gelangen.3 Bereits einen fahrlässiger Umgang
mit der Informationstechnik (z. B. durch unsichere Passwörter oder ungeeignete
Verschlüsselungsalgorithmen) kann unter Umständen diesen Tatbestand erfüllen.
Neben den Gesetzesanforderungen und Vorschriften gibt es zugleich diverse
Standards (BS/ISO), welche das IT-Security Management thematisieren und es
unter anderem ermöglichen sollen, die oben angesprochenen gesetzlichen Vorgaben zu erfüllen.
Einer der ersten dieser Art war der britische Standard BS 7799, auf Basis dessen
im späteren Verlauf der ISO/IEC 17799:2005 entwickelt wurde. Genau wie die
Urfassung des britischen Standards beruht der ISO/IEC 17799 auf einem Best
Practice Ansatz, welcher die Aufstellung von Maßnahmen umfasst, deren Ziel es
ist, die Informationssicherheit zu gewährleisten.[Bru06, S. 213] Der große Vorteil
der ISO-Standards ist die internationale Akzeptanz und damit besonders für
global agierende Unternehmen von Bedeutung.
Der ISO/IEC 27001:2005 dagegen beschreibt den Aufbau eines Information Security Management Systems (ISMS) und referenziert im Anhang auf die Maßnahmen, die durch den ISO/IEC 17799 detailliert beschrieben werden. Dabei
werden Anforderungen an ein dokumentiertes Informationssicherheits-Managementsystem im Hinblick auf Implementierung, Erhaltung, Verbesserung, Wartung und Überwachung detailliert dargestellt.
Auch in Deutschland hat man sich dieser Thematik angenommen, woraufhin das
Bundesamt für Sicherheit in der Informationstechnik (BSI) das IT-Grundschutzhandbuch herausgab und später zu den IT-Grundschutzkatalogen weiter entwickelte. Diese enthalten Gefährdungs- und Maßnahmekataloge, die helfen sollen,
die Arbeit des Security Managements sinnvoll zu strukturieren.
Dabei beschreibt das IT-Grundschutzhandbuch die Vorgehensweise von der Erstellung eines Sicherheitsprozesses über die Implementierung bis hin zur Definition der konkreten Aufgaben. Weiterhin werden sogenannte Bausteine beschrieben, die übergeordnete Prozesse und Verfahren, wie z. B. die Notfallplanung, ITSecurity Management und Organisation darstellen. Jeder Baustein beschreibt
ein Szenario, weist ihm Gefährdungen zu und leitet daraus Maßnahmen ab.
Diese können dann mit den Security Baselines verglichen werden.
In der heutigen Zeit wird das Grundschutzhandbuch nicht nur in Behörden angewandt, auch die Wirtschaft fragt dieses immer stärker nach. In seiner aktuellsten
Version wurde es mit dem ISO/IEC 27001:2005 kompatibel gemacht.
Eine weniger detaillierte Darstellung liefert der Leitfaden zur IT-Sicherheit,
ebenfalls herausgegeben vom BSI. In kompakter Form werden eine Zusammenfassung der wichtigsten Sicherheitsmaßnahmen sowie Praxisbeispiele und
Checklisten geliefert.
3.2.3
Ziele und Aufgaben des IT-Security Management
Die Zeiten, in denen die IT-Infrastruktur hinter sicheren Mauern vor den Blicken
der Umwelt geschützt war und einige wenige Sicherheitsmaßnahmen genügten,
um die Datensicherheit zu gewährleisten, sind längst vorbei. „Sicherheit ist heute
mehr als das Abschlie[ß]en von Serverräumen und die peinlich genaue Beachtung von Passwortregeln.“[Vog02, S. 270] Die Anforderungen an das Security
3§
203 StGB, die so genannte Schweigepflicht
86
Management haben in unserer heutigen hochtechnisierten und auf den eigenen
Vorteil ausgerichteten Welt, erheblich zugenommen.[Köh06, S. 203] Aus diesem
Grund sollen im Folgenden Anforderungen, Ziele und Maßnahmen des Security
Managements vorgestellt werden.
Security Policy. Bevor Maßnahmen zum Schutz der IT-Infrastruktur vor
potenziellen Bedrohungen, wie etwa Hackerangriffen, Viren oder Datendiebstahl
ergriffen werden können, sind zunächst die Anforderungen an die jeweiligen
Prozesse zu ermitteln und in Form konkreter Sicherheitsziele zu definieren.
Elementarer Baustein innerhalb des Security Managements ist in diesem Zusammenhang die Security Policy 4 . Neben den langfristigen Sicherheitszielen beinhaltet sie die Personalverantwortlichkeiten und Sicherheitsstufen für die jeweiligen
Prozesse und Daten eines Unternehmens. Ferner werden auch Sicherheitsrichtlinien in der Policy definiert und festgehalten. Für die konkrete Ausgestaltung der
Sicherheitsrichtlinien liefert bspw. das IT-Grundschutzhandbuch des BSI geeignete Anhaltspunkte. In der Regel umfasst die Security Policy folgende Aspekte:
([Köh06, S. 210])
• Sicherheitsziele
• Zweck und Geltungsbereich
• Personalzuständigkeit und Rolle
• Aufgaben, Verantwortung und Rechte der einzelnen Rollen
• Beschreibung der Sicherheitsstufen für Daten und DV-Verfahren
• Verfahren bei Sicherheitsverstößen
• Berichtswesen und Abstimmungsverfahren
• Datenschutz und Fernmeldegeheimnis
Bei der Ausarbeitung der Security Policy ist große Sorgfalt geboten. Mit ihr wird
die Basis für ein effizientes und funktionierendes Security Management gelegt.
Dennoch sollte sie dabei nicht mit den Unternehmenszielen konfligieren.
Zudem ist bei der Erstellung mit dem Auftreten von Interessenskonflikten zwischen den jeweiligen Prozessverantwortlichen zu rechnen, bspw. zwischen Datenschutz- und Sicherheitsbeauftragten. Beide vertreten unterschiedliche Auffassungen im Hinblick auf die Protokollierung persönlicher Zugriffe von Mitarbeitern.
[Köh06, S. 210] Während der Datenschutzbeauftragte den Schutz personenbezogener Daten als Ziel verfolgt, liegt es im Interesse des Sicherheitsbeauftragten diese Informationen möglichst detailliert zu erfassen, um einem Missbrauch
vorzubeugen oder für den Fall eines Missbrauchs die Nachvollziehbarkeit zu ermöglichen.
4 Englischer
Begriff für IT-Sicherheitspolitik
87
Ziele. Für den reibungslosen Ablauf bzw. das Funktionieren eines Unternehmens sind aktuelle und fehlerfreie sowie konsistente Informationen unerlässlich.
[Vog02, S. 270] Daher verfolgt das IT-Security Management als primäres Ziel,
die Informationssicherheit5 von Daten und Prozessen gemäß ihrer Bedeutung
für die Unternehmung zu gewährleisten. Der Schutz der Vertraulichkeit, Verfügbarkeit und Integrität vor potenziellen Bedrohungen soll dabei auf effiziente
und ressourcenschonende Weise erfolgen (Wirtschaftlichkeit).
Neben der Datensicherheit stehen auch Aspekte des Datenschutzes im Fokus des
Security Managements. Maßgeblich ist in diesem Zusammenhang das gesetzliche
Rahmenwerk.6 Zielsetzung in diesem Kontext ist es, die gesetzlichen Auflagen
einzuhalten.
Geschäftsleitung
Security Policy
IT-SicherheitsManagement
Informations und Prozesssicherheitsstandards
Fachbereiche
Datensicherheit
Sicherheitsadministrator
System- und Netzwerksicherheit
Mitarbeiter im Produktionsprozess
Sicherheitsbewusstsein und Sicherheitskompetenz
Abbildung 3.1: Sicherheitsziele nach Hierarchieebenen. Quelle: [Köh06, S. 216].
Aufgaben und Aktivitäten des Security Management. Zu den Maßnahmen des Security Managements zählen alle Vorkehrungen, die geeignet sind,
den durch die definierten Ziele vorgegebenen Sicherheitsgrad zu erreichen bzw.
aufrecht zu halten. Neben der Behebung von Sicherheitsvorfällen reicht das Aufgabenspektrum dabei von der Auswahl adäquater Firewalls, Anti-Viren- und
Anti-Malware-Programmen über die Schulung des Sicherheitsbewusstseins der
Mitarbeiter bis hin zu Risikoanalysen. Bei Risikoanalysen werden Betriebsmittel
auf Schwachstellen und potentielle Bedrohung untersucht und diesbezüglich Bewertungen vorgenommen. Die Risikobewertung richtet sich einerseits nach dem
Schadenspotenzial und zum anderen nach der Bedeutung für das Unternehmen. Eine solche Einstufung in Risikoklassen (Klassifizierung) hat den Vorteil,
dass die Ressourcen des Security Management optimal verteilt werden können.
Letztlich bietet eine Risikoanalyse die Möglichkeit, Gefahren und Auswirkungen für Geschäftsprozesse frühzeitig zu identifizieren und rechzeitig präventive
5 siehe
6 siehe
dazu ausführlicher Kapitel 3.2.1 IT-Informationssicherheit
dazu ausführlicher Kapitel 3.2.2 Gesetzesanforderungen, Vorschriften und Standards
88
Maßnahmen einzuleiten.[Bru06, S. 28]
Weitere wichtige Aufgaben des Security Management sind:
• Durchführung von Security Audits7
• Erstellen von Management Reports zur IT-Sicherheit
• Überprüfen, ob die eingeführten Sicherheitsmaßnahmen eingehalten werden
Die nachfolgende Abbildung dient abschließend dazu, den Prozess des Security
Managements zu veranschaulichen und verdeutlicht, dass die IT-Sicherheit kein
statischer Zustand ist, sondern ein dynamischer Prozess.[Bsi07, S. 6]
Report
Report
Plan
ManagementReport zu
IT- Risiken und
IT- Sicherheit,
Dokumentation von
Sicherheitsvorfällen
Security Policy,
Service Level
Agreement,
Operational Level
Agreement
Act
Act
Plan
Notwendige
Änderungen
herbeiführen,
Verbesserung der
Prozesse
Check
Do
Check
Einhaltung der
Security Policy
überprüfen,
Security Audits,
Interne u. Externe
Überprüfung
Do
Bedrohungsanalysen,
Priorisierung,
Sicherheitsbewusstsein
schulen/fördern,
Auswahl geeigneter
Software/ Tools zum
Schutz vor Viren,
Würmern, MalWare,
etc.
Abbildung 3.2: Erweiterter PDCA-Zyklus des Security Management Prozesses.
3.2.4
Einordnung von Informationssicherheit und Security Management in ITIL
Heutzutage sind Unternehmen und Organisationen zunehmend dem Druck ausgesetzt, ihre IT-Prozesse zu überarbeiten und zu verbessern. Dynamische Geschäftsprozesse und der steigende Informationsbedarf sind Auslöser zur Neustrukturierung und stellen ein Unternehmen vor Probleme in Bezug auf deren
Umsetzung. Nicht zuletzt trägt der technologische Fortschritt in der Informationsübertragung und -verarbeitung zusätzlich dazu bei. Um solchen Anforderungen gerecht zu werden, führt kein Weg an Standardisierung vorbei, wodurch
7 Security Audits sind regelmäßige Prüfungen des Softwarebestands und gleichzeitiger Abgleich mit Securitylisten, wodurch Gefahren frühzeitig erkannt werden können.
89
nicht nur versucht wird Geschäftsprozesse und Verhaltensweisen, sondern auch
serviceorientiertes Management aneinander anzupassen.
Die ITIL hat sich dieser Thematik angenommen und dient als Orientierung für
eine solche Prozessstandardisierung. Als „IT-Infrastructure Library“ hat sich
dieses Rahmenwerk als Instrument zur Planung und Umsetzung etabliert.
Ein oft vernachlässigter Bereich ist in diesem Zusammenhang das Thema Informationssicherheit. Auch dieser Problematik hat sich ITIL angenommen und versucht ein Leitfaden für den sicheren Umgang mit Informationen im Service Management zu sein. ITIL beruht auf Best Practice Ansätzen und sieht Sicherheitsaspekte als unverzichtbaren Bestandteil eines ordnungsgemäßen IT-Betriebes
an. In der Version V2 umfasst das komplette ITIL-Paket sieben Bücher. Eines davon ist das Buch „Security Management“, welches sich dieser Thematik
widmet und versucht eine Verbindung zwischen Sicherheitsanforderungen und
Geschäftsprozessen zu schaffen. Im Gegensatz dazu wird dem Thema Sicherheit
in der aktuellen, dritten Version (V3) kein eigenes Buch gewidmet, sondern findet in Teilbereichen der fünf Buchbände Berücksichtigung. Wird diese Thematik
nach ITIL eingeführt und allumfassend umgesetzt, ergeben sich viele Chancen
für einen effizienten Umgang mit sicherheitsrelevanten Ereignissen.
Informationssicherheit betrifft alle Personen und Bereiche innerhalb einer Organisation, vom einfachen Mitarbeiter bis hin zur Chefetage. ITIL unterteilt
deswegen seine Prozesse in drei Ebenen.
Strategische Ebene. Das Top-Management stellt die oberste, die strategische Ebene dar. Auf ihr wird entschieden, ob ein Security Management aufgebaut wird und gegebenenfalls werden Verantwortlichkeiten festgelegt. Zudem
sollte die von dem Security Management erarbeitete Security Policy an die Geschäftsleitung herangetragen werden, um eine gesamtheitliche Akzeptanz und
Unterstützung zu gewährleisten. Strategische Ausrichtung, Finanzierung und
Kontrollfunktion sind weitere Aufgaben, die das Top-Management betreffen.
Taktische Ebene. Die zweite Ebene wird auch taktische Ebene genannt und
dient der Qualität der Services. Auf ihr werden alle Prozesse des Service Delivery
zusammengefasst. Das Service Level Management bestimmt die Anforderungen
an das Service Delivery, also die zu erbringenden IT-Dienstleistungen. Diese
Vereinbarungen, die die Erbringung von Serviceleistungen betreffen, bilden das
Service Level Agreement (SLA). Hier tritt der Kunde als Auftraggeber der Leistungen auf und kann über seinen Bedarf die Serviceangebote der IT-Abteilung
beeinflussen. Ebenfalls auf dieser Ebene anzusiedeln, ist das Security Management, dessen Aufgabe es ist die gesamte Netzwerkstruktur in puncto Sicherheit
zu betreuen und zu überwachen. Gegebenenfalls wird zusätzlich ein Security
Officer ernannt, der die Verantwortung diesbezüglich trägt und Ansprechpartner der Geschäftsleitung ist. Aus den, in den SLAs definierten, Anforderungen
leiten sich Sicherheitsziele ab, welche in der Security Policy zusammengefasst
werden. Wie im vorigen Kapitel bereits erläutert, zählen hierzu beispielsweise
Datenschutz, gesetzliche Bestimmungen oder Sicherheitsstufen.
Operative Ebene. Die operative Ebene ist für die konkrete Umsetzung dieser
Ziele verantwortlich und beinhaltet die Prozesse des Service Supports. Diese
Ebene steht in direktem Kontakt mit Anwendern und verwaltet alle Wünsche,
90
Anfragen und Änderungen. Der zentrale Anlaufpunkt ist der Service Desk. Hier
laufen Anfragen
zusammen und es wird die Funktion des Incident Managements mit Schnittstellen zu Problem-, Change- und Release Management etabliert.8
3.3
Security Management mit ITIL auf operativer Ebene
Nachdem im vorherigen Kapitel grundlegende Aspekte, wie IT-Security Management oder Informationssicherheit erläutert wurden, soll nun im Folgenden
aufgezeigt werden, wo sich Chancen und Möglichkeiten des Zusammenwirkens
von Security Management und Service Support im Zuge der Restrukturierung
bzw. Neustrukturierung der Geschäftsprozesse nach ITIL bieten. Ferner soll explizit dargestellt werden, wie sich diese Synergieeffekte nutzen lassen.
Dazu werden in den folgenden Abschnitten die einzelnen Prozesse des Service
Supports kurz erläutert und anschließend die Vorteile der wechselseitigen Beziehung aufgezeigt.
Ziel dieses Kapitels ist es nicht, konkrete Sicherheitsmaßnahmen vorzustellen,
wie es bspw. das BSI-Grundschutzhandbuch tut. Zwar sollen auch solche Aspekte angesprochen werden, der Fokus dieses Kapitels liegt jedoch eindeutig auf der
Darstellung der prozessorientierten Maßnahmenplanung.
3.3.1
Service Desk
Hat ein Anwender eine Anfrage oder treten Komplikationen in Bezug auf bestimmte Anwendungen oder Services auf, ist der Service Desk die erste Station,
an die er gelangt. Er ist der zentrale Anlaufpunkt einer IT-Organisation und soll
eine professionelle Anwenderunterstützung garantieren. Mittels Email, „Faceto-Face“-Kommunikation oder wie in den meisten Fällen per Telefon, werden
sogenannte Incidents 9 aufgenommen und bearbeitet. Das können unter anderem
triviale Fragen zu Soft- und Hardware sein oder auch Meldungen zu Produktfehlern oder Servicestörungen. Der Mitarbeiter am Service Desk ist nun gefragt
weitere Schritte zur Behebung dieser Incidents einzuleiten und Ereignisdaten in
einer Datenbank zu speichern. Gemäß ITIL ist dies die Configuration Management Database (CMDB), auf die in Kapitel 3.3.6 ausführlicher eingegangen
wird. Im Gegensatz zu den nachfolgenden Servicemanagement-Prozessen in ITIL
stellt der Service Desk keinen eigentlichen Prozess dar, sondern eine Funktion,
die eine Schnittstelle zwischen Anwendern und IT-Organisation bildet.[Bmi06,
S. 13] Über den gesamten Zeitraum der Bearbeitung kann der aktuelle Status
des Incidents abgerufen und kontrolliert werden, so dass Geschäftsleitung oder
Kunden schnell und zuverlässig Informationen bereitgestellt werden können.
Des Weiteren übernimmt der Service Desk Routineaufgaben des Change- und
Configuration Managements, unterstützt das Release Management bei der Rollout-Phase oder stellt von sich aus Kontakt zu Anwendern her.[Bmi06, S. 13] Ein
Beispiel dafür sind Änderungsanträge, die zuvor bereits standardisiert wurden
und nun direkt umgesetzt werden können, ohne an entsprechendes Fachpersonal
8 Auf eine detaillierte Darstellung der operativen Ebene wird an dieser Stelle verzichtet, um
Überschneidungen mit dem folgenden Kapitel zu vermeiden.
9 Englischer Begriff für unvorhergesehenes Ereignis, Auftrag oder Störfall
91
weitergeleitet zu werden. Durch Soft- oder Hardwareinstallationen, wie z. B.
Patches10 oder Updates, können bestimmte Störungen schon vom Service Desk
behoben werden und entlasten somit das Release Management.
Der Service Desk ist aufgrund seiner Schnittstellenfunktion auch für sicherheitsrelevante Themen zuständig. So werden über Security Incidents Prozesse der ITSicherheit wie Passwortvergabe, Veränderungen von Zugriffsrechten oder auch
Benutzerkonten angesprochen und bearbeitet. Derartige Standardprozesse können direkt vom Service Desk durchgeführt oder aber an Experten weitergeleitet
werden. Der Service Desk ist somit ein Teil des Security Management und sollte
Anforderungen wie hohe Erreichbarkeit und Reaktionsgeschwindigkeit gerecht
werden. Zusammen mit dem für die Sicherheit zuständigem Management ist es
ratsam Strategien zur Sensibilisierung der Mitarbeiter bei hoch sicherheitsrelevanten Vorfällen (z. B. Flächenstörungen) auszuarbeiten, um die IT-Spezialisten
möglichst rasch zu alarmieren und Fehleinschätzungen vorzubeugen. Die Mitarbeiter des Service Desk sind ein wichtiger Aspekt in diesem Prozess, da durch
ihre Entscheidung Arbeitszeit und Aufwand gespart oder vergeudet wird.
Bei entsprechender Umsetzung kann der Service Desk einen großen Beitrag zu
der Incidentbearbeitung leisten. Durch seine vielfältigen Anforderungen kann
er allgemeine Aufgaben erfüllen und sogar spezifische Lösungen bereitstellen.
Letztendlich ermöglicht ein funktionierender Service Desk sogar die Leistung
des Security Management zumindest in Teilen messbar zu machen. In Verbindung mit der Leistungstransparenz, welche ITIL mit sich bringt, ermöglicht es
die Erfassung von Security Incidents bspw. Aussagen darüber zu machen, ob
die Anzahl an Security Incidents rückläufig ist oder um wie viel Prozent diese
zurückgegangen sind.
3.3.2
Incident Management
Nachdem eine Anfrage aufgenommen wurde, ist es die Aufgabe des Incident
Managements, diese zu verwalten und eine Übersicht über den aktuellen Status
aller Incidents zu gewährleisten. Um Auswirkungen auf die Geschäftsprozesse
so gering wie möglich zu halten und Imageschäden zu vermeiden, ist es Ziel
dieses Vorgangs, alle Anfragen und Vorfälle schnellstmöglich zu behandeln und
potentielle Fehler zu beheben. Früher wurden dazu Bücher geführt, die zentral
abgelegt und nur einen Zugriff zur selben Zeit zuließen. Im Gegensatz dazu
werden heutzutage moderne, computergestützte Verfahren eingesetzt, um die
Behandlung einer Vielzahl von Datensätzen zu ermöglichen, bei denen mehrere Benutzer gleichzeitig auf einen Incident zugreifen können. Auf dem Markt
erhältlich, sind dazu einige Softwarelösungen, die mit Ticket-Systemen arbeiten. Jeder Incident wird dadurch einem Ticket zugewiesen und ist über eine
Netzwerkverbindung jederzeit abrufbar.
Da Störungen die Informationssicherheit beeinflussen können oder ein unerkannter Sicherheitsvorfall Störungen hervorrufen kann, ist das Incident Management als Teilbereich des Security Managements anzusehen. ITIL liefert hierzu
einen Prozessansatz, bei dem je nach Qualität einer Störung eine oder mehrere
Support-Stufen durchlaufen werden. Die Bearbeitung von Störungen, in diesem Fall Security Incidents, lässt sich in mehrere Arbeitsschritte untergliedern.
[Bmi06, S. 17]
10 Ein Patch ist eine Korrekturauslieferung oder Nachbesserung für Software aus Endanwendersicht, bspw. um eine Sicherheitslücke zu schließen.
92
• Erkennen und erfassen von Incidents
• Klassifizierung und Erstlösungsversuch
• Analysieren und Lösungsvorschlag
• Incident lösen
• Überwachen und steuern
• Abschließen des Incidents
Erkennen und erfassen von Incidents. Das Erkennen von Störfällen kann
auf verschiedenen, dezentralen Wegen erfolgen. Zum einen wäre da der Anwender (Kunde, Zulieferer, Mitarbeiter), dem eine Unregelmäßigkeit bekannt wird
und diese an den Service Desk heranträgt. Ein weiterer Aspekt ist die Erkennung einer Störung durch ein System. Netzwerke mit ihren Peripheriegeräten
können über eine Software überwacht werden (Monitoring) und senden bei Überschreitung eines bestimmten kritischen Wertes eine Fehlermeldung. Wie oben
bereits erwähnt, werden diese Ereignisse von dem Service Desk erfasst und in
der CMDB gespeichert. Es kann in der Praxis sinnvoll sein, Security Incidents
getrennt von anderen Störungen an einer separaten Meldestelle aufzunehmen.
Vorteil dieser Maßnahme ist es, dass sensible Informationen weniger schnell an
die Öffentlichkeit gelangen. Auf der anderen Seite wird von einem Anwender
erwartet, festzustellen, ob ein Vorfall sicherheitsrelevant ist oder nicht. Die andere Möglichkeit ist eine zentrale Annahme aller Incidents. Dieser erste Schritt
in der Bearbeitung der Störungen wird First-Level-Support genannt.
Klassifizierung und Erstlösungsversuch. Durch eine Klassifizierung wird
Status und Art der Störung eingeordnet und festgestellt, welche Sicherheitsziele
betroffen sind. Über eine Risikoanalyse wird ermittelt, welche Schadensauswirkung entstehen kann und wie dringend das Sicherheitsziel wieder hergestellt
werden sollte. D. h., es wird ein Bearbeitungszeitraum zur Lösung des Problems
eingeplant und eine erste Priorisierung vorgenommen. Diese Prioritätseinstufung dient nur als eine erste Orientierung und kann später durch genauere Analyse von Fachpersonal oder im Change Management korrigiert werden. Anhand
der vorher definierten Security Policy, sollte es dem Mitarbeiter des First-LevelSupport möglich sein, eine Einschätzung gemäß ihrer Bedeutung für die Organisation zu tätigen.
Handelt es sich um ein Fehler, der die Security Policy verletzt und dessen Lösung
in der Configuration Management Datenbank dokumentiert ist, kann er an dieser Stelle direkt behoben werden und es kommt zu keiner weiteren Bearbeitung.
Grundsätzlich gilt es Aktionismus zu vermeiden.
Analysieren und Lösungsvorschlag. Die Prüfung des Störfalls beginnt mit
der Recherche über bereits bekannte Störungen oder ähnliche Vorfälle, die in
der Vergangenheit aufgetreten sind. Ist dies der Fall, wird der damals benutzte
Workaround vorgeschlagen oder eine entsprechende Eskalationsstrategie angewandt. Der Workaround dient dazu, Einflüsse auf Geschäfts- und Serviceprozesse so gering wie möglich zu halten, um der weiteren Lösungsfindung mehr Zeit
93
zu verschaffen. Da eine Fülle von möglichen Anwendungs- und Konfigurationsproblemen denkbar ist, wird es praktisch kaum möglich sein dem Support zu
jedem Vorfall eine entsprechende Handlungsvorschrift bereitzustellen. Vielmehr
sollten absehbare oder schon bekannte Sicherheitslücken dokumentiert vorliegen. Ist eine Problemlösung jedoch nicht bekannt und es kann keine schnelle
Lösung gefunden werden, wird der Vorfall an eine nächste Support-Ebene weitergeleitet. Das Security Management sollte zu Beginn helfen, diese Ebenen der
ITIL-Einführung zu strukturieren und aufgrund des fachlichen Wissens Verantwortlichkeiten verteilen. In den meisten Fällen der Security Incidents sind das
IT-Spezialisten oder Systemadministratoren, die auf zweiter oder dritter Ebene
agieren.
Incident lösen. Sofern ein Standardproblem nicht schon im Vorfeld gelöst
wurde, wird es von Fachkräften auf nächster Ebene behandelt. Da zur Bearbeitung der Störung vielfach externe Dienstleister oder Personen zu Rate gezogen
werden, sollte der Umgang mit sensiblen Informationen geklärt sein. Durch eine
strenge Authentisierung kann Missbrauch der Daten verhindert und die Integrität sichergestellt werden. Falls Daten einem speziellen Schutz in Bezug auf
die Informationssicherheit unterliegen, sollte das Security Management das Incident Management darüber informieren, wie solche Daten übermittelt werden
und welche Personen berechtigt sind, diese einzusehen.
Ist ein Missbrauch jedoch nicht auszuschließen, kann es zu Zielkonflikten zwischen forensischer Analyse und Servicemanagement kommen. Die Forensiker
konzentrieren sich auf genutzte Sicherheitslücken und Spurensicherung, während Mitarbeiter vom Service alle Energien zur Wiederherstellung betroffener
Services einsetzen.
Wurde ein Störfall erfolgreich gelöst, ist eine ausführliche Dokumentation von
großer Wichtigkeit. Die CMDB sollte um eine Handlungsvorschrift ergänzt werden, damit nachfolgenden, ähnlichen Incidents schneller behoben werden können. Sofern ein Incident nur durch eine Änderungsmaßnahme (z. B. Umgestaltung einer Netzwerkstruktur) gelöst werden kann, wird ein Request for Change 11
(RfC) beim Change Management eingereicht. Eine explizite Betrachtung des
Change Managements wird an einer anderen Stelle beschrieben.
Überwachen und steuern. Die Überwachung der Störungen ist Aufgabe des
Service Desks. Regelmäßig sind die Incidents zu Überprüfen, um die Wiederherstellung der Sicherheitsziele in der dafür vorgesehenen Zeit nicht zu gefährden.
Entwickelt sich eine Störung zu einem Notfall, sollte das Incident Management
in der Lage sein, einen Notfall rechtzeitig zu erkennen und angemessen reagieren. Auch in diesem Fall ist das Security Management gefragt, im Vorfeld einen
Notfallplan auszuarbeiten. Notfälle können Flächenstörungen, wie zum Beispiel
Serverausfall, Komplettausfälle von Netzwerken oder auch Stromausfall sein.
Die Verantwortung liegt bei Vorfällen diesen Ausmaßes bei dem Notfallmanagement.
Abschließen des Incidents. Nach Lösung des Störfalls wird der Incident
vom Service Desk abgeschlossen. Dazu gehört die Kontrolle über korrekte Bearbeitung und Nutzung der vorgegebenen Support-Ebenen. Zusätzlich wird der
11 Englischer
Begriff für Änderungsanfrage
94
Anwender über den Hergang informiert und es wird gegebenenfalls ein Feedback
angefordert. Anschließend wird die Dokumentation auf Vollständigkeit geprüft.
Das Incident Management hat die CMDB zu pflegen und sollte nach Security Policy und Security Management über mehrere Aspekte Auskunft geben
können. Dazu zählen beispielsweise Erfassungsdatum, Durchlaufzeit, Kurzbeschreibung und Effektivität der Untersuchung. Anhand dieser Daten ist eine
Auswertung möglich, um Präventivmaßnahmen durchzuführen oder in Zukunft
schneller reagieren zu können. Eine solche Datenauswertung ermöglicht es ferner
über folgende Fragestellungen Auskunft zu geben: ([Bmi06, S. 32])
• Wie hoch sind die Eintrittswahrscheinlichkeiten?
• Welche Schäden entstehen wirklich?
• Greifen die technischen und organisatorischen Maßnahmen?
• Wie hoch ist die Wiederholungsrate des gleichen Sicherheitsvorfalls?
• Sind die Investitionen in die Sicherheit richtig gesteuert?
3.3.3
Problem Management
Die Aufgabe des Problem Managements ist die Forschung nach den Ursachen
für Probleme12 Durch sogennante Ursachen-Wirkungsanalysen soll verhindert
werden, dass sich Fehler wiederholen. Auf diese Weise kann ein funktionierendes Problem Management die Anzahl von Incidents reduzieren und somit ein
erheblicher Teil zur Zuverlässigkeit und Wirtschaftlichkeit eines IT-Services beitragen.
Im Problem Management gibt es zwei unterschiedliche Verfahren, auf die in den
nächsten Absätzen eingegangen wird.
• Antrag aus dem Incident Management
• Das proaktive Problem Management
Antrag aus dem Incident Management. Wenn bei der Bearbeitung einer
Störung durch das Incident Management die Ursache nicht festgestellt werden
kann, wird aus dem Incident ein Problem und an das Problem Management
weitergeleitet. Dabei muss es sich nicht immer zwangsläufig um Probleme handeln, die nicht behoben werden können. Es können vom Incident Management
auch Anfragen für spezielle Probleme eingehen, die sie zwar schnell beheben
können, sich aber nicht in der Lage sehen, die Ursache dafür zu finden bzw.
zu beseitigen. Hier macht sich der generelle Unterschied bemerkbar. Während
das Incident Management einen Fehler schnellstmöglich beseitigen möchte, versucht das Problem Management das Auftreten solcher zu vermeiden. Dabei kann
dies mitunter zu Interessenskonflikten führen. Bspw. kann das Incident Management ein Netzwerkfehler schnell beheben, indem ein entsprechender Switch13
neu gestartet wird. Das Problem Management wird aber möglicherweise eine
Auswechslung der gesamten Switches beantragen, was mehrere Stunden dauern
12 Nach ITIL- Definition sind Probleme, die noch unbekannte Ursache für einen
Störung.[Bsi05, S. 18]
13 Ein Switch ist eine Netzwerkkomponente, die mehrere Computer verbindet.
95
kann und somit auch das Netzwerk für diese Zeit abgeschaltet werden muss.
Kurzfristig wird dadurch die Verfügbarkeit gestört. Geht man aber weiter und
führt sich vor Augen welche Zielsetzung das Problem Management verfolgt, ist
schnell zu erkennen, dass auf lange Sicht die Verfügbarkeit und die Wahrscheinlichkeit auf Erreichung der SLA erhöht wird.
Es sei nun angenommen, dass der oben beschrieben Netzwerkfehler nicht auf einem defekten Switch beruht, sondern auf einem Angriff von außen (etwa durch
einen Hacker oder Virus). In diesem Fall ist die Informationssicherheit des Netzwerkes der Unternehmung gefährdet. Das Security Management sollte aufgrund
seiner speziellen Funktion somit bereits in die Analyse mit einbezogen werden.
Durch sein Know-how kann das Security Management bei der Problem-Analyse
und Lösungsentwicklung einen wesentlichen Beitrag zu besseren Ergebnissen
leisten.
Das proaktive Problem Management. Eine weitere Aufgabe des Problem
Managements ist das proaktive Suchen nach Fehlern und Schwachstellen. Ziel
dabei ist es, durch präventive Maßnahmen Fehler zu verhindern, bevor sie auftreten. Hat man z. B. eine eigene Software oder bietet eine solche Kunden an14 ,
sollte eine Überprüfung auf Schwachstellen in regelmäßigen Abständen mit Hilfe von Penetrationstests erfolgen. Unter einem Penetrationstest versteht man,
den Versuch sich mit den Mitteln eines Eindringlings (Hacker, Virus, etc.) in
ein System einzuloggen. Wird eine Schwachstelle gefunden, sollte umgehend eine Lösung gefunden und gegebenenfalls die Software geändert werden. Über
die dazugehörigen Updates sollten dann die Kunden informiert und ihnen zur
Verfügung gestellt werden. In diesem Zusammenhang sollte darauf geachtet werden, dass die Schwachstelle erst dann an die Öffentlichkeit gelangt, wenn diese
beseitigt ist.
Durch die Integration des Security Management in den ITIL-Prozess Problem
Management entstehen potenzielle Synergieeffekte. Erfahrungsgemäß ist dabei
die Analyse von Sicherheitslücken und deren Beseitigung eine große Stärke des
Security Managements.[Bsi05, S. 18] Durch die Verflechtung beider Prozesse und
deren Aufgaben lässt sich eine deutliche Kompetenzsteigerung erreichen.
Die Suche nach Schwachstellen mittels Security Audits ist eine der Maßnahmen
des Security Managements.15 Ergänzt man die Verfahrensweisen des proaktiven
Problem Managements um diese Methode und optimiert diese für den eigenen
Zweck, ermöglicht dies Verletzungen von Sicherheitsrichtlinien frühzeitig zu erkennen und mögliche Ursachen für Fehler zu verhindern.
Nicht jedem Incident kann zu Beginn eindeutig zugeordnet werden, ob dieser
Auswirkungen auf die Informationssicherheit hat oder nicht. Daher muss abgewogen werden, wann das Security Management in den Prozess des Problem
Managements eingebunden werden soll, um eine bestmögliche Effizienz zu erreichen. Diese Frage sollte deshalb bereits bei der Entwicklung der internen
Sicherheitsrichtlinien beantwortet und die Vorgehensweise standarisiert werden,
um damit die Synergieeffekte optimal auszunutzen und ein bestimmtes Sicherheitsniveau gewährleisten zu können.
Die nachfolgende Abbildung verdeutlicht eine Problematik, mit der sich eigentlich primär das Change Management konfrontiert sieht. Da aber Lösungswege
14 Dabei
15 siehe
kann dieses Verhältnis auch betriebsintern bestehen.
Kapitel 3.2.3 Ziele und Aufgaben des IT-Security Management
96
für bestehende Probleme schon im Problem Management entwickelt werden und
sie damit eine gewisse Vorarbeit für das Change Management leisten, soll auf
die möglichen Auswirkungen vorgenommener Änderungen auf die Informationssicherheit bereits an dieser Stelle eingegangen werden.
Änderungen
Sicherheitslücken
Informationssicherheit
Fehler
Probleme
Abbildung 3.3: Auswirkungen von Änderungen auf die Informationssicherheit.
Handelt es sich bei einer Sicherheitslücke nicht um einen dokumentierten Fehler, liegt im Allgemeinen ein Problem vor, welches die Ursache oder Wirkung
von Service-Beeinträchtigungen sein und die Informationssicherheit gefährden
kann. Das Problem Management versucht die Ursachen hierfür zu ermitteln,
unternimmt Lösungsversuche oder schlägt Lösungswege vor.
Häufig entstehen hieraus konkrete Änderungsvorschläge (RfC). Diese Änderungen können Auswirkungen auf die Informationssicherheit haben und im schlimmsten Fall letztlich neue Sicherheitslücken verursachen. Es kann ein potenzieller
Kreislauf entstehen, durch den permanent die Informationssicherheit gefährdet
ist. Dies steht jedoch im Widerspruch zu den eigentlichen Zielsetzungen des
Problem Managements (vor allem die Reduzierung der Incidents). Aus diesem
Grund hat das Problem Management großes Interesse daran, diesen potenziellen Kreislauf gar nicht erst entstehen zu lassen. Wird nun das Security Management zusätzlich in den Prozess der Lösungsentwicklung einbezogen, kann
im Change Management eine Reduzierung der abgelehnten RfCs erreicht werden. Die Mitarbeiter des Security Managements können schon bei der Entwicklung von Änderungsvorschlägen eingreifen und diese auf sicherheitstechnischen
Aspekten überprüfen. Durch dieses Zusammenspiel von Problem- und Security Management kann eine höhere Effizienz bei Änderungen erreicht und somit
auch Kosten gesenkt werden.
3.3.4
Change Management
Die Zuständigkeit des Change Managements erstreckt sich von der Erfassung
über die Priorisierung bis hin zur Auswertung aller eingehenden RfCs. Ziel ist
97
es dabei, Änderungen, d. h. veränderte Eingriffe in Anwendungen, Infrastruktur, Dokumentationen, Prozesse und Verfahren steuerbar und kontrollierbar zu
machen. Störungen infolge von Änderungen sollen vermieden und die Effizienz
der Änderung gesteigert werden. Letzteres ist möglich, wenn z. B. Änderungen
vermieden werden, die keinen angemessenen Nutzen liefern, nicht gewünscht
sind oder mangels Durchführbarkeit wieder zurück genommen werden.[Bsi05,
S. 19] In diesem Kontext vollzieht das Change Management geeignete Tests, die
einen Nachweis über Nutzen und Kompatibilität mit anderen Systemen ermöglichen. Die zentrale Instanz des Change Managements ist das Change Advisory
Board (CAB). Dieses wird vom Change Manager zusammengerufen, um gemeinsam die gerade beschriebenen Aufgaben zu bewältigen. Verlaufen die Tests positiv, so kann der Change freigegeben und ausgeführt werden.
Das Security Management nach ITIL ist sowohl als Initiator, Realisierer sowie
als Planungs- und Freigabeinstanz von Changes in den Change Management
Prozess eingebunden.[Bsi05, S. 20]
Als Initiator von Changes. Wie im Kapitel 3.3.3 (Problem Management)
beschrieben, wird bei Incidents, die die Informationssicherheit betreffen, das
Security Management herangezogen. Häufig hat dies technische oder organisatorische RfCs zur Folge, die durch das Security Management im Laufe der
Problem-Analyse angeordnet und an das Change Management weitergeleitet
werden.
Als Realisierer von Changes. Das Security Management hat konkrete Verantwortungen für Teile der IT-Infrastruktur. So werden Security Maßnahmen
entwickelt und realisiert. Hierbei findet das Change Management in gleicher
Weise wie in anderen Bereichen des IT-Betriebs Berücksichtigung.
Als Planungs- und Freigabeinstanz. Um Auswirkungen auf die Informationssicherheit und den Datenschutz zu vermeiden, sollte das Security Management sowohl bei der Planung als auch bei der Freigabe von Änderungen
mit eingebunden werden. Sinnvoll ist es in diesem Zusammenhang, ein oder
mehrere Mitarbeiter des Security Managements in das Änderungsgremium mit
aufzunehmen. Auf diese Weise ist einerseits sichergestellt, dass jeder RfC auf
sicherheitsrelevante Merkmal überprüft wird, auf der anderen Seite stellt das
Security Management geeignete Test- und Abnahmeverfahren bereit, die verhindern sollen, dass durch Änderungen Sicherheitslücken entstehen. Abbildung
3.4 veranschaulicht, wie das Security Management bei der Überprüfung und
Abnahme von RfCs unterstützend mitwirken kann.
Schon im Service Desk werden Incidents bezüglich ihrer Dringlichkeit priorisiert. Wurde ein Incident als dringlich eingestuft, weil z. B. die Erfüllung einer
Servicevereinbarung nicht gewährleistet ist, so ist auch der dazu gehörige RfC in
den meistens dringlich. Ist dies der Fall, durchläuft der RfC ein verkürztes Verfahren, wobei hier die Sicherheit nicht vernachlässigt werden darf. Besonders bei
Sicherheitspatches besteht eine hohe Brisanz. Diese sind meistens dringend und
greifen teilweise tief in bestehende Funktionalitäten und Prozesse ein.[Bsi05, S.
20] Hier müssen mit besonderer Vorsicht genaue Vorgaben definiert werden, um
ein Ausgleich zwischen dem Termindruck und der Sicherheit zu erzielen. Im zweiten Schritt wird überprüft, ob die Informationssicherheit betroffen ist. Wenn der
98
Request for Change
Dringender Change ?
Informationssicherheit betroffen ?
Datenschutz betroffen ?
Test der Informationssicherheit
Smoke Test
Abnahme
Abbildung 3.4: Abnahme von RfCs. Quelle: [Bru06, S. 82].
RfC Auswirkungen auf die Informationssicherheit hat, wird überprüft, ob die
Sicherheitsziele des SLA berührt werden. Können diese nicht eingehalten werden oder ist die Einhaltung der Verfügbarkeit, Integrität oder Vertraulichkeit
nicht gewährleistet, muss das Security Management diesen Change ablehnen.
Im Falle der Ablehnung ist eine Kompromisslösung durch das CAB zu finden.
Dabei muss ein RfC nicht zwangsläufig vom CAB abgelehnt werden, wenn es
vom Security Management abgelehnt wurde. Das liegt daran, dass das CAB
Schwerpunkte auf andere Aspekte, wie z. B. das Kosten-Nutzen Verhältnis eines
Change, legt. Im dritten Schritt wird überprüft ob der Datenschutz betroffen
ist. Hierbei sollte z. B. bei Änderungen der Zugriffsrechte oder bei Software zur
Verwaltung der persönlichen Daten des gesamten Personals geprüft werden, ob
diese ausreichend vor Fremdeingriffen geschützt sind. Nachdem diese Schritte
durchlaufen sind, muss das Security Management Abnahmekriterien definieren,
anhand derer die Freigabe durch das Security Management erfolgt. Diese werden auch bei dringenden Changes angewandt, die in Form eines sogenannten
Smoke-Tests durchgeführt werden. Der Smoke-Test ist eine oberflächliche Überprüfung bzgl. der Grundfunktionalität einer Software nach deren Fertigstellung
oder Reparatur. Wenn die RfCs positiv bezüglich der Sicherheitsziele getestet
wurden, können sie aus Sicht des Security Managers freigegeben werden.
In der letzten Phase werden beim Rollout durch ausgiebige Tests nicht nur die
Korrektheit einer bestimmten Funktion getestet, sondern auch die Erreichung
und Einhaltung der Sicherheit. Insbesondere muss darauf geachtet werden, dass
nicht neue Lücken oder Hintertüren in Software-Applikationen entstehen und
die einmal erreichte Sicherheitsstufe nicht beeinträchtigt werden. Im Falle des
Scheiterns der RfCs bei diesen Tests, sollten, um die Informationssicherheit
zu gewährleisten, angemessene Rückfallverfahren bereit stehen, mit denen der
ursprünglichen Zustand schnell wieder hergestellt werden kann. In vorherigen
Kapitel 3.3.3 (Problem Management) wurde schon erwähnt, dass bei der Planung der RfCs das Security Management einbezogen werden soll. Durch diese
Einbindung sinkt die Wahrscheinlichkeit für die Entstehung neuer Sicherheitslücken und damit für die Ablehnung der RfCs enorm. Bei einer schnelleren und
99
wahrscheinlicheren Freigabe der RfCs aus sicherheitstechnischen Aspekten kann
zusätzlich die Verfügbarkeit im Unternehmen gesteigert werden. Diese Aspekte zeigen die Chancen, die sich bieten, wenn das Security Management in das
Problem- und Change Management früh eingebunden wird. Dafür muss zwingend ein Mitarbeiter aus dem Security Management ein ständiges Mitglied im
CAB sein. Dieser soll verhindern, dass RfCs, die ursprünglich nichts mit der
Informationssicherheit zu tun haben, fälschlicherweise Sicherheitslücken aufstoßen.
3.3.5
Release Management
Während das Change Management der Initiator aller Änderungen innerhalb
einer IT-Infrastruktur ist, diese realisiert und die Verantwortung dafür trägt,
liefert das Release Management die „Verfahren von der Anforderungsbearbeitung über die Planung der Umsetzung, Test und Abnahme von Soft- und Hardwareversionen bis hin zur organisatorischen und technischen Vorbereitung der
Einführung einer Komponente.“[Bsi05, S. 20] Dabei werden die Konfigurationselemente üblicherweise nicht einzeln implementiert, sondern zu einem Paket, der
sogenannten Release Unit 16 gebündelt. Die Einführung solcher Release Units hat
den Vorteil, dass der Aufwand für das Testen und die Inbetriebnahme erheblich
reduziert werden kann.
Die zentrale Aufgabe des Release Management in diesem Bezugsrahmen ist es,
mit Hilfe geeigneter Maßnahmen sicherzustellen, dass bei der Einführung eines Release keine unerwünschten Nebeneffekte oder Fehler auftreten. So gab es
in der Vergangenheit Fälle, in denen Unternehmensnetzwerke durch das Update eines Anti-Virenprogramms lahm gelegt wurden, da dieses irrtümlicherweise
unternehmenseigene Software als Virus erkannte und schließlich deaktivierte
[Bsi07, S. 3]. Der wirtschaftliche Schaden kann in solchen Fällen schnell ein immenses Ausmaß annehmen. Geht man bspw. von 500 Usern eines DV-Verfahrens
mit einem Durchschnittsstundenlohn von ca. 50 Euro/Stunde aus, so gehen mit
jeder Ausfallstunde 25.000 Euro an potentieller Arbeitsleistung verloren. (Beispiel ähnlich zu [Köh06, S. 103]) Dieses Beispiel verdeutlich unter anderem, dass
die Notwendigkeit besteht Sicherheitsüberlegungen in den Prozess des Release
Managements mit einzubeziehen.
Der Prozess des Release Managements, welcher durch einen vom CAB freigegebenen RfC, ausgelöst wird [Bru06, S. 90], lässt sich dabei im Allgemeinen in
drei Phasen einteilen:
• Planungs- und Entwicklungsphase
• Testphase
• Planung und Autorisierung des Rollouts
Die Möglichkeit Security Aspekte in das Release Management mit einfließen zu
lassen, ergibt sich während all dieser drei Phasen.
Planungsphase. Auf dieser ersten Stufe werden zunächst grundsätzlich Regeln hinsichtlich eines Release oder der Release Unit definiert und in der Release
16 Release:
Englischer Begriff für Version
100
Planungsphase
Testphase
Rollout-Phase
ReleaseRelease
Test
Rollout- Kommunikation, Verteilung
Release- Software
und
Grundsätze Planung entwickeln zusammenstellen und
Planung Verbreitung,
oder
Installation
Training
und konfigurieren Abnahme
beauftragen
Abbildung 3.5: Phasen des Release Management Prozesses und Aufgaben.
Policy festgehalten. Das Security Management sollte schon in dieser frühen Phase wirksam werden und dem Release Management Vorgaben über bestimmte
Sicherheitsanforderungen machen, etwa bzgl. der in Kapitel 3.2.1 vorgestellten
Hauptwerte der Informationssicherheit. Ansonsten bleibt dem Security Management nur noch die „Rolle des Verhinderers“[Bsi05, S. 12] im Vorfeld eines
Release, sofern dieses Sicherheitsrichtlinien verletzt.
In der Release Policy, die ein wesentlicher Bestandteil des Release Management
Prozesses ist, sollte ebenfalls fest verankert werden, dass sofern sicherheitsrelevante Patches verfügbar sind, diese eingespielt werden und nicht erst bis zum
nächst größeren Update gewartet wird. Dieses standardisierte Vorgehen ermöglicht es, potenzielle Sicherheitslücken frühzeitig zu beseitigen.
Schließlich kann das Security Management noch bei der Planung lösungsspezifischer Releases mit einbezogen werden. Das Security Management kann hierbei
entwicklungsbegleitend und unterstützend tätig werden, in dem es Risiko- und
Sicherheitskriterien fixiert, die während der Release Planung einzuhalten sind.
Testphase. Damit der reibungslose und funktionierende Ablauf des Systems
nicht gestört wird, werden auf der zweiten Stufe die jeweiligen Releases vor
ihrer Einführung diversen Tests sowie einer Qualitätsprüfung unterzogen. Dabei
soll in einer möglichst „produktionsidentischen Testumgebung“[Bru06, S. 91]
sichergestellt werden, dass durch das Release keine der, in der Planungsphase
definierten, Sicherheitskriterien verletzt und die Anforderungen an Stabilität,
Verfügbarkeit und Integrität eingehalten werden.[Bsi05, S. 21] Hierbei kann auf
das Know-how des Security Management zurück gegriffen werden. Es liefert die
entsprechenden Testverfahren.
Sofern das Release die Anforderungen erfüllt, erteilt das Security Management
die erforderliche Freigabe aus seinem Blickwinkel.
Rollout-Planung Mit der Freigabe des Releases beginnt die letzte Phase
des Release Management Prozess, das sogenannten Rollout 17 . Der Rollout Plan
17 Englischer Begriff, der das Verteilen, Ausliefern und Ausführen von Soft- und Hardwarereleases beschreibt.
101
beinhaltet alle Regeln und Vorgaben, die bei der Implementierung des Releases
durch das Change Management beachtet werden müssen. So wird bspw. festgehalten, wie im Falle eines nicht erfolgreichen Rollouts zu verfahren ist, d. h. ob
ein Fallback 18 oder ein Backout 19 durchzuführen ist. Das entscheidende Kriterium, welches in diesem Kontext beachtet werden muss, ist die Verfügbarkeit des
Systems.
Ferner muss bei der Rollout Planung die Nachvollziehbarkeit bzw. Revisionsfähigkeit der Änderungen an der IT-Infrastruktur sichergestellt werden. Eine
Übersicht über alle Änderungen liefert dem Security Management die Grundlage für eine releaseübergreifende Risikobetrachtung.[Bru06, S. 92] So sollte man
bspw. darauf bedacht sein, risikobehaftete Releases zu unterschiedlichen Zeitpunkten zu implementieren, um nicht zusätzlich die Verfügbarkeit des Systems
zu gefährden.
Abschließend sei angemerkt, dass nicht nur das Release Management von der
Berücksichtigung sicherheitsrelevanter Aspekte profitiert, sondern sich auch vorteilhafte Synergieeffekte für das Security Management ergeben. Auf SoftwareEbene etwa werden Sicherheitslösungen und -patches im Rahmen des Release
Management Prozesses geplant und realisiert. Von einer kooperativen Zusammenarbeit profitieren sowohl Release als auch Security Management.
3.3.6
Die Erfordernisse an die Datenverarbeitungsverfahren aus Sicht der Geschäftsprozesse eines Unternehmens haben in den letzten Jahrzehnten erheblich zugenommen. Immer mehr Detailinformationen, etwa bzgl. der Konfigurationselemente müssen erfasst, kontrolliert und verifiziert werden.
Genau an diesem Punkte setzt das Configuration Management an. Die zentrale
Aufgabe des Configuration Management besteht darin, die sogenannten Configuration Items 20 (CI) einer IT-Infrastruktur zu erfassen sowie deren Beziehungen zueinander darzustellen. Unter einem CI sind sowohl ganze IT-Systeme,
etwa ein Server oder Arbeitsplatz-PCs sowie einzelne Peripheriegeräte (Beamer,
Scanner, Drucker oder Tastatur) zu verstehen. Zusätzlich gehören auch Netzwerkkomponenten, Datenträger sowie Dokumentationen dazu.[Bru06, S. 84] Um
bei der Vielzahl an CIs Verwechselungen auszuschließen, ist jedes CI grundsätzlich durch einen eindeutige Identifikationsnummer gekennzeichnet.
Das Configuration Management ist der zentrale Prozess innerhalb des Service
Supports. Er schafft die Informationsgrundlage für die weiteren Prozesse, indem eine Übersicht über alle CIs, deren Attribute sowie deren Beziehungen
zueinander, geliefert wird. Archiviert und bereitgestellt, wird diese Vielzahl an
Information in der Configuration Management Database (CMDB), auf die ebenfalls andere Prozesse, wie etwa Problem- oder Incident Management zugreifen
können. Tritt bspw. bei einem bestimmten CI ein Incident oder Problem auf, so
genügt ein Blick in die CMDB, um abschätzen zu können, welche weiteren CIs
unter Umständen ebenfalls von dem Vorfall betroffen sind. Die CMDB liefert
18 „Ein Fallback ist die Wiederherstellung des vorherigen Releases, wodurch alle Changes,
die in einem Release zusammengefasst waren, rückgängig gemacht werden.“[Bru06, S. 93]
19 „Ein Backout ist ein Verfahren, die einzelnen Changes eines Release schrittweise rückgängig zu machen. Durch ein Backout wird ein neues Release definiert.“[Bru06, S. 93]
20 Englischer Begriff für Konfigurationselement. Dieser wird im Folgenden an Stelle des Begriffs Konfigurationselement verwendet.
102
somit neben der Infrastrukturtransparenz eine Servicetransparenz.
Durch die Verzahnung mit den anderen Prozessen des Service Supports bietet das Configuration Management optimal Voraussetzungen, um verschiedene
Aspekte des Security Management darin zu integrieren. Möglichkeiten dazu ergeben sich bereits und vor allem während der Configurations-Planung. In der
Planungsphase wird unter anderem das Design der CMDB festgelegt, welches
für ein funktionierendes Configuration Management von elementarer Bedeutung ist. Eine gut geführte und aktuelle CMDB kann sich innerhalb kurzer
Zeit zu einem universellen Werkzeug auch aus Sicht des Security Management
entwickeln.[Bsi05, S. 22]
Klassifikation. Bevor ein CI in die CMDB aufgenommen wird, muss er anhand bestimmter, in der Designphase festgelegter Kriterien, klassifiziert werden.
Dabei erhält ein CI grundsätzlich eine bestimmte Kategorie (z. B. Hardware,
Software, Dokumentation), verschiedene Attribute, wie etwa Standort, Verantwortlichkeit oder Version sowie einen Status (funktionsfähig, fehlerhaft, Kontrolle, etc.).[Köh06, S. 60] Zusätzlich werden, wie bereits erwähnt, die Abhängigkeiten zu anderen CIs erfasst. Ergänzt man dieses bestehende Beziehungsgeflecht um die drei Hauptwerte der Informationssicherheit (Verfügbarkeit, Integrität und Vertraulichkeit), eröffnet dies Chancen und Möglichkeiten sowohl für
Security- als auch Configuration Management.21
Standort
Name und
Beschreibung
Version
Beziehung
zu anderen CI´s
ID-Nummer
Configuration
Item
Verantwortlichkeit
Klassifikation
bzgl. InformationsSicherheit
Abbildung 3.6: Erweiterte Attribute eines Configuration Item.
Eine um diese Faktoren erweiterte CMDB liefert Transparenz über die sicherheitsrelevanten Abhängigkeiten der CIs, ermöglicht es Schwachstellen innerhalb
des Configuration Management zu identifizieren und liefert die Basis für Ausfallanalysen. Ferner wird es möglich, spezielle Maßnahmen und Verfahren für
CIs zu planen bzw. zu ergreifen, die eine bestimme Klassifikation hinsichtlich
der Informationssicherheit erhalten haben.
Die Klassifizierung der CIs muss hierbei von den jeweiligen Prozessverantwortlichen vollzogen werden, da nur diese die notwendigen Kenntnisse über die bereichsspezifischen Sicherheitsanforderungen haben.
21 Die in Kapitel 3.2.1 vorgestellten Dimensionen, Zurechenbarkeit und Rechtsverbindlichkeit
werden ebenfalls durch eine gut geführte Dokumentation innerhalb der CMDB unterstützt.
103
Die Einteilung in Hinblick auf Verfügbarkeit und Vertraulichkeit eines CI kann,
wie in den Tabellen 3.1 und 3.2 dargestellt, vorgenommen werden. Im Vordergrund sollte dabei nicht eine möglichst exakte Klassifizierung stehen, sondern
dass überhaupt eine solche vollzogen wird.
Klassifikation
Streng geheim
Vertraulich
Eingeschränkt
Kriterium
Zusammenhang mit strategischen Informationen, Betriebsgeheimnissen, Rezepturen,
Patenten und Kalkulationen
Zusammenhang mit interne Informationen,
z.B. Preislisten, Besprechungsnotizen, Personaldaten
Zusammenhang mit Informationen, die
durch Dritte eingesehen werden können,
aber nicht für diese bestimmt sind
Tabelle 3.1: Klassifikation Vertraulichkeit. Quelle: [Bru06, S. 87].
Klassifikation
Absolut
Hoch
Mittel
Niedrig
Kriterium
keine Ausfallzeiten gestattet
maximale Ausfallzeit 30 Minuten
maximale Ausfallzeit 4 Stunden
maximale Ausfallzeit 2 Tage
Tabelle 3.2: Mögliche Klassifikation Verfügbarkeit.
Große Aufmerksamkeit bedarf es bei der Klassifikation der Integrität eines CIs,
da in diesem Kontext schwer zu definieren ist, wie viele falsche Daten eine Datenbank verkraftet oder wie viele Verbindungsfehler in einem Netzwerk auftreten
dürfen. Der aktuelle Grad an Integrität lässt sich ebenfalls schwer quantifizieren. Aus diesem Grund findet deshalb in der Regel ein zweistufiges Klassifizierungssystem Anwendung.[Bru06, S. 88] Dabei wird zunächst für alle CIs eine
Baseline Integrität festgelegt, bspw. eine bestimmte Anzahl tolerierter Verbindungsabbrüche oder die Anzahl fehlerhafter Datensätze und auf zweiter Stufe
eine erweiterte Integrität, die sich nach den jeweiligen Anforderungen des CIs
richtet.
In Bezug auf die Klassifikation bleibt abschließend anzumerken, dass es nicht
erstrebenswert ist, für alle CIs eine solche vorzunehmen, schon alleine im Hinblick auf die Beherrschbarkeit der stetig wachsenden Datenmenge eines Unternehmens. Ebenso sprechen Praktikabilitätsgründe gegen die Einstufung eines
jeden CIs, da der Aufwand im Verhältnis zum Nutzen zu groß ist. Vielmehr
sollten überhaupt Risikoüberlegungen bzgl. der Informationssicherheit in Form
von Klassifizierung im Prozess des Configuration Management Berücksichtigung
finden. Ein Anfang kann hierbei mit den CIs gemacht werden, für die besondere
Aufmerksamkeit in puncto Verfügbarkeit, Vertraulichkeit und Integrität gilt.
Weitere Synergieeffekte. Neben der vorgestellten Klassifizierung gibt es eine Reihe weiterer Möglichkeiten die Schnittstellen zwischen Security und Configuration Management zu nutzen. Eine davon sind so genannte Audits der CMDB
104
in Bezug auf die Sicherheit. Darunter versteht man einen Soll-Ist-Vergleich
zwischen dem dokumentierten/geplanten Bestand der CMDB und dem tatsächlichen Bild, welches die IT- Infrastruktur liefert. Durch diese regelmäßigen Scans/Audits und Abgleich mit der CMDB lässt sich mit relativ geringem
Aufwand installierte, unautorisierte Software identifizieren. Die Auswahl und
Implementierung eines geeigneten Tools liegt dabei im Verantwortungsbereich
des Security Managements.
Auf Hardwareebene steigt die Transparenz mit jedem Incident oder RfC, da nur
für bekannte CIs solche aufgegeben werden können. Jeder Change oder Incident
führt dazu, dass noch nicht erfasste CIs in die CMDB aufgenommen werden.
Mit Hilfe dieses standardisierten Vorgehens werden automatisch Gefahren reduziert, die bspw. von nicht erkannten Verbindungen ausgehen. So stellt ein unbekanntes, aktives Modem in einem Notebook eine erhebliche Sicherheitslücke
dar.[Bru06, S. 89] Je eher solche Hardwarekomponenten identifiziert werden,
desto früher können diesbezüglich Sicherheitsmaßnahmen eingeleitet werden.
Darüber hinaus erleichtert ein funktionierendes Configuration Management die
Analyse von Security Incidents, da in der CMDB die Historiendaten inklusive aller Changes revisionssicher gespeichert sind. Somit ist auch die Rechtsverbindlichkeit als eine weitere Dimension der Informationssicherheit sichergestellt. Zudem ermöglichen ausführliche Installations- und Systemdokumentationen nicht nur im Wiederholungsfall eine schnellere Installation, sondern helfen auch bei der Ursachenforschung im Problemfall, bspw. können im Falle eines Hacker-Angriffs frühzeitig unbefugte Veränderungen am System identifiziert
werden.[Bsi07, S. 25]
Eine ganz entscheidende Frage, welche letztlich im Zusammenhang mit der
CMDB geklärt werden muss, ist: Wer erhält hierauf Lesezugriffsrechte und wer
darf den Datenbestand verändern? Die Notwendigkeit die Zugriffsrechte zu beschränken und zu kontrollieren, ergibt sich aus der Tatsache, dass die CMDB
streng vertrauliche Informationen (physisch, organisatorisch, finanziell) über die
jeweiligen Geschäftsprozesse enthält. Ein Verlust der Verfügbarkeit, Integrität
oder Vertraulichkeit dieser Daten kann mit erheblichen wirtschaftlichen Konsequenzen verbunden sein. Die Verantwortung dieses sicher zu stellen tragen
sowohl Security als auch Configuration Management.
3.4
Fazit
Die Auseinandersetzung mit dem Thema Informationssicherheit ist ein absolutes Muss für die Zukunftssicherung einer Unternehmung. Ein funktionierendes
IT-Security Management liefert hierzu einen wesentlichen Beitrag. Für viele ist
der Begriff Security Management dabei gleichbedeutend mit dem Einsatz von
Tools und Sicherheitslösungen zum Schutz vor potenziellen Bedrohungen. Eine andere Herangehensweise ist die Integration dieser Maßnahmen und Ideen
in einen standardisierten, prozessorientierten Ansatz, wie ihn das Rahmenwerk
ITIL bietet.
Vordergründiges Ziel dieser Arbeit war es, die Chancen und Möglichkeiten des
Zusammenwirkens von IT-Security Management und den Prozessen des Service
Supports darzustellen. Ferner sollte ein kurzer Überblick über das Thema ITSicherheit geliefert werden. Dazu wurden zu Beginn der vorliegenden Arbeit
grundlegende Begrifflichkeiten von der Informationssicherheit bis hin zum Se-
105
curity Management erläutert. Im dritten Kapitel, dem Hauptteil der Arbeit,
wurden dann zunächst die Prozesse des Service Supports vorgestellt und anschließend die sich bietenden Synergieeffekte aufgezeigt.
Im Rahmen dieser Analyse hat sich gezeigt, dass das Security Management bereits bei der Implementierung der Service Support Prozesse einzubeziehen ist
und sich die größten Potenziale während der Gestaltungs- und Planungsphasen
bieten. Aus Sicht des Security Managements liegt die Stärke dieses Ansatzes
in der frühzeitigen Berücksichtigung der Sicherheitsaspekte und -anforderungen
während aller Support Stufen sowie der ausführlichen Dokumentation von Sicherheitsvorfällen und deren Lösungen. Der Service Support profitiert neben
den Risiko- und Kritikalitätsüberlegungen von geeigneten Test- und Abnahmeverfahren, die das Security Management bereitstellt.
Trotz dieser Möglichkeiten, die die Verknüpfung von Service Support und Security Management im Zuge der Neustrukturierung gemäß ITIL bietet, bleibt
abschließend anzumerken, dass eine Wirtschaftlichkeitsbetrachtung nicht außer
Acht gelassen werden darf. Hierzu sind die Einspareffekte, die durch ein wirksameres und effizienteres Security Management entstehen, den Kosten für die
Implementierung gegenüber zu stellen. Mit Hilfe geeigneter Key Performace Indikatoren, wie bspw. die Prozentzahl der zurückgegangenen Sicherheitsvorfälle
und durch die gestiegene Transparenz und Messbarkeit der IT-Leistung dürfte
diese Wirtschaftlichkeitsprüfung letztlich unproblematisch sein.
106
[Bmi06] Bundesministerium des Innern: ITIL und Informationssicherheit,
Aspekte der Integration von Incident und Security Management,
2006, URL:
http://www.iznnet-kom.niedersachsen.de/IT-Sicherheit/
downloads/BMI-itil_und_informationssicherheit_v101.pdf,
[18.12.07]
[Bru06]
Brunnstein, Jochen: ITIL Security Management realisieren, Vieweg
Verlag, 1.Auflage 2006
[Bsi05]
Bundesamt für Sicherheit in der Informationstechnik: ITIL und
Informationssicherheit, 2005, URL:
www.bsi.de/literat/studien/ITinf/itil.pdf, [18.12.07]
[Bsi07]
Bundesamt für Sicherheit in der Informationstechnik: Leitfaden
IT-Sicherheit, 2007, URL:
www.bsi.bund.de/gshb/Leitfaden/GS-Leitfaden.pdf, [09.01.08]
[Die04]
Dierstein, Rüdiger: Sicherheit in der Informationstechnik - der Begriff
IT-Sicherheit. In: Informatik Spectrum August 2004 S. 343-353
[Iti07]
ITIL.org: Das Portal für Informationen rund um ITIL und
ISO20000, URL: http://www.itil.org/de, [15.02.08]
[Köh06] Köhler, Peter T.: ITIL, Springer Verlag, 2. Auflage, 2006, Berlin
[OfG07] Office of Government Commerce: ITIL - Service Design, TSO, 1.
Auflage 2007
[Vog02]
Vogt, Walter: fIT for benefit - IT Services kundenorientiert stuern
und planen, Perseo Consult, 1. Auflage 2002
107
108
Kapitel 4
ITIL-unterstützende
Werkzeuge
Formulierung von Anforderungen entlang des Service Supports
Sonja Bozionek, Linda Gerstenberger, Kathrin Stegmann
4.1
Einleitung
Der Übergang von einer technischorientierten zu einer dienstleistungsorientierten IT-Organisation hat in den letzten Jahren an Bedeutung gewonnen.[Nie07]
Die Schaffung von standardisiertem Informationsfluss und das Bestreben gewonnene Informationen für eine optimalere (Kunden-)Nutzung in geregelte Formen
zu bringen, sind nur einige Gründe, die für eine verstärkte Standardisierung der
IT sprechen. Gleichzeitig ist auch eine stärkere Serviceorientierung seitens der
Unternehmen zu nennen. Im Zusammenhang mit diesem Übergang ist auch der
Begriff der IT Infrastructure Library (ITIL) in den letzten Jahren in Deutschland verstärkt im Fokus des Interesses.[Its07]
Bei der Einführung von ITIL stellt sich unter anderem die Frage, ob softwareunterstützende Werkzeuge bei der Umsetzung und zur Effizienzsteigerung eingesetzt werden. Grundsätzlich ist es nach ITIL freigestellt, ob unterstützende
Werkzeuge verwendet werden sollen oder nicht. Interessant ist dann, ob ein eingesetztes Werkzeug die Arbeit erleichtert und sie effizienter gestalten kann.
Ziel dieser Arbeit ist es, sowohl Anforderungen an ein potentielles Werkzeug entlang des ITIL-Prozesses im Service Support herauszuarbeiten, als auch die sich
ergebenden Anforderungen mit den Funktionen von zwei ausgewählten Werkzeugen zu vergleichen.
Die Arbeit gliedert sich in einen Grundlagen- und einen Hauptteil sowie in ein
Fazit. Im Grundlagenteil wird zunächst das Verständnis der Begriffe ITIL und
Werkzeuge für diese Arbeit aufgeführt. Im Anschluss daran werden im Hauptteil
die Funktionalitäten des Service Supports und die dazugehörigen spezifischen
109
110
ITIL-unterstützende Werkzeuge
Anforderungen an die Werkzeuge näher betrachtet. An dieser Stelle schließt sich
die Betrachtung der Werkzeuge an, wobei eine Unterscheidung in kommerzielle und open-source Werkzeuge vorgenommen wird. In einem Fazit werden die
wichtigsten Ergebnisse dieser Arbeit abschließend pointiert wiedergegeben.
4.2
4.2.1
Begriffsabgrenzungen
ITIL
In der heutigen Zeit wird es immer schwieriger, den Anforderungen einer ITInfrastruktur innerhalb von Unternehmen zu genügen und auf einem bestimmten Qualitätsniveau zu halten. Für jedes Unternehmen ist es daher wichtig, die
IT-Struktur an neue Anwenderbedürfnisse auszurichten und den neuen Anforderungen anzupassen. Um diese Dienstleistung zu gewährleisten, wird versucht, die
Struktur innerhalb der IT bezüglich der Ausfallhäufigkeit oder der Verfügbarkeit
zu optimieren. Dieser Ansatz wird auch als IT Service-Management bezeichnet
und wird durch den ITIL-Leitfaden unterstützt. ITIL ist eine Sammlung von
Büchern, in denen ein Rahmenwerk von IT-Service-Managementprozessen beschrieben wird. Es existiert zu jedem Prozess ein Leitfaden sowie Empfehlungen
zur Umsetzung. ITIL ist somit kein Programm, sondern fungiert als Richtlinie
zur Strukturierung der eigenen IT-Abteilung im Unternehmen. ITIL hat sich
im Laufe der Zeit als defacto Standard etabliert und ist mittlerweile weiträumig
verbreitet.[Pfl05]
Die folgende Abbildung gibt einen Überblick über die ITIL-Inhalte.
Abbildung 4.1: Überblick ITIL. Quelle: Eigene Darstellung.
Die Arbeit bezieht sich auf den Bereich des Service Supports. Welche Prozesse
innerhalb dieses Bereichs stattfinden, zeigt die folgende Abbildung.
111
Abbildung 4.2: Überblick Service Support. Quelle: Eigene Darstellung.
Entlang dieser Prozesse werden im Kapitel 4.3 die Anforderungen an ein Werkzeug herausgearbeitet.
4.2.2
Werkzeuge
Unter (ITIL)-Werkzeugen1 werden im Verlauf dieser Arbeit Computerprogramme verstanden, welche die Implementierung und Umsetzung von ITIL in den
Unternehmen unterstützen.[Nie07] D.h. unter einem Tool wird eine Software
verstanden, die die veränderte Situation im Unternehmen jetzt und in Zukunft
unterstützt. Die Auswahl von Tools gestaltet sich insofern als schwierig, als dass
in den ITIL-Büchern keine Bewertung der vorhandenen Tools vorgenommen
wird und konkrete Aussagen ausbleiben.[Bre07]
Am Markt ist verschiedene Software erhältlich. Zu unterscheiden sind opensource Lösungen, die im Internet frei verfügbar sind und kommerzielle Angebote.
Im Rahmen dieser Projektarbeit wird die Software Open Ticket Request System (OTRS) näher betrachtet. Aus der Vielzahl kommerzieller Produkte wird
beispielhaft das Programm Remedy vorgestellt.[Här07]
Die betrachteten Werkzeuge in dieser Arbeit basieren auf dem Ticket-System.
Ein Ticket-System2 ist eine Verwaltungssoftware, mit der mehrere Personen
gleichzeitig Kundenanfragen und -aufträge verwalten können. Wesentlicher Bestandteil dieser Software ist das Ticket. Dabei ist es unerheblich, über welche
Medienart die Anfrage im System eingeht. Innerhalb dieser Software besteht
die Möglichkeit, diese Aufträge zu klassifizieren, zu bearbeiten oder sie weiterzuleiten. Wird eine bereits bekannte Anfrage an das System geschickt, erstellt
das Programm automatisch eine Verknüpfung zu dem schon gespeicherten Vorgang. Der Supportleistende kann das Ticket öffnen, und sich vorab Informa1 Die Bezeichnungen "Werkzeug" und "Tool" werden in dieser Arbeit im weiteren Verlauf
synonym verwendet.
2 Synonym wird die Bezeichnung Trouble-Ticket-System verwendet.
112
tionen zu dem vorliegenden Problem verschaffen. Es werden allgemeine Daten
gespeichert, welche wiederum zur Problemlösung verwendet werden können. Die
Möglichkeit zur Dokumentation der gesamten Daten wird auch Historiefunktion genannt.[Cla] Ist das Problem letztendlich gelöst, spricht man vom Schließen
des Tickets.[Här07] Auf die genauere Ausgestaltung eines Ticket-Systems wird
bei der Betrachtung von OTRS und Remedy näher eingegangen.
4.3
4.3.1
Service Support und Anforderungen an die
Werkzeuge
Vorgehensweise
Nachdem bisher ITIL und das Verständnis von Werkzeugen erläutert wurde,
werden im Folgenden die einzelnen Prozesse von ITIL näher betrachtet. Der
Fokus liegt hier ausschließlich auf dem Bereich des Service Support, da eine umfassendere Betrachtung im Rahmen dieser Arbeit aus zeitlichen Gründen nicht
möglich ist. Dieses Kapitel gliedert sich somit in die einzelnen Prozesse des Service Support, dem Incident Management, dem Problem Management, sowie dem
Change Management, dem Release Management und dem Configuration Management. Es wird jedoch nicht nur ein Einblick in den jeweiligen Prozess gegeben,
sondern vielmehr ist an dieser Stelle von Bedeutung, welche Anforderungen sich
jeweils für eine mögliche Softwareunterstützung durch ein eingesetztes Tool ergeben. Prinzipiell besteht durchaus die Möglichkeit, die Grundsätze von ITIL im
einfachsten Fall mit Papier und Bleistift umzusetzen.[Mar04] Durch eine Softwareunterstützung aber kann sich bei passendem Einsatz eine erhebliche Effizienzsteigerung ergeben, da ein größerer Informationsfluss schneller verarbeitet
werden kann. Sobald Tätigkeiten gehäuft und wiederholt vorkommen, kann es
sich lohnen, Aktivitäten durch Einsatz einer geeigneten Software zu automatisieren. Doch was genau müsste eine ITIL-konforme Software können? Welche
Fähigkeiten müsste sie haben, um den Menschen zu entlasten und dabei die
einzelnen Prozesse des Service Support funktionsfähig und zielführend abzubilden? Diese Anforderungen an ein Tool werden jeweils in den einzelnen Kapiteln
herausgearbeitet, um in Kapitel 4.4 die Funktionen der Werkzeuge OTRS und
Remedy darzustellen.
4.3.2
Incident Management mit Service Desk
Das Incident Management bildet in Verbindung mit dem noch zu erläuternden
Service Desk die Schnittstelle zwischen Anwender/ Kunden und dem Unternehmen. Primäres Ziel ist es, den IT-Service bei einem Incident wieder herzustellen
und aufrecht zu erhalten.
ITIL fasst unter der Bezeichnung Incident Störungen und Service Requests zusammen. Für die weitere Betrachtung werden zunächst die Begriffe Störungen
und Service Requests definiert. Ursächlich für eine Störung und auch einen Service Request sind jeweils auftretende Anliegen. Unter einer Störung wird dabei
"ein Ereignis [verstanden], das nicht zum standardmäßigen Betrieb eines Service gehört und das tatsächlich oder potentiell eine Unterbrechung oder Minderung der Servicequalität verursacht." [Its07] Anfragen, welche keine Störungen
113
im eigentlichen Sinne sind, werden unter dem Begriff Service Requests zusammengefasst. Darunter fallen unter anderem Statusnachfragen und Fragen zur
Handhabung.
Die Aufnahme einer Störung im Service Desk ist dabei als Ausgangspunkt für
das Incident Mangement zu nennen, und den Abschluss bildet dann die Wiederherstellung des Service. Bei der Bearbeitung der Störung unterscheidet man
zwischen verschiedenen Leveln, dessen grobe Einschätzung im Service Desk
stattfindet. Es erfolgt häufig eine Gliederung in verschiedene Ebenen oder Bearbeitungsstufen. Bezeichnet wird das als Multi-Level-Support-Modell. Einfache
Probleme oder Anfragen können oftmals direkt gelöst werden und werden als
First-Level-Support bezeichnet. Diese werden durch den Service Desk bearbeitet
und abgeschlossen.
Kompliziertere oder umfassendere Anliegen werden vom Service Desk weitegeleitet und dort durch Fachkräfte oder Teams im Rahmen des Second-LevelSupports gelöst. Kann das Problem auch an dieser Stelle nicht gelöst werden,
wird es an das Third-Level weitergegeben, in dem sich Experten damit befassen. Hier wird deutlich, dass es eine klare Abgrenzung der Kompetenzen geben
muss. Dies gilt nicht nur für das Incident Management, sondern auch für die
Organisation aller weiteren Prozesse. Eine zentrale Stellung hat in diesem Bereich der bereits erwähnte Service Desk, welcher nun im Folgenden betrachtet
wird.[Its07]
Service Desk Da der Service Desk nach ITIL kein Prozess sondern eine Funktion ist und damit eine Aufgabe erfüllt, wird er in dieser Arbeit innerhalb dieses
Kapitels betrachtet. Außerdem liefert er nicht nur dem Incident Management,
sondern auch den Service Support-Prozessen Problem Management, Change
Management, Release Management und Configuration Management wichtige
Informationen.
Der Service Desk ist also in erster Linie die Schnittstelle für den Anwender,
d.h. er dient als Kontaktpunkt für den Kunden bzw. für den Anwender zum gewünschten IT-Service. Diese Kommunikationsstelle wird auch als Single Point
of Contact (SPOC) bezeichnet.[Fis06] Synonym zum Service Desk wird auch die
Bezeichnung Help Desk verwendet.3 Zu den allgemeinen Aufgaben des Service
Desk zählen im Wesentlichen die Entgegennahme der Anliegen des Kunden. Im
weiteren Verlauf wird das Anliegen konkretisiert, also ob es sich um eine Anfrage eines Kunden im Sinne einer Änderung (Request for Change) handelt,
oder ob es sich um eine Störung (Incident) handelt. Jeder dieser Vorgänge wird
umfangreich dokumentiert und gespeichert, um bei Bedarf jederzeit darauf zurückgreifen zu können. Noch nicht abgeschlossene Vorgänge werden permanent
überwacht und deren weiterer Verlauf verfolgt. Es besteht auch die Möglichkeit,
die Kunden über den Verlauf des Anliegens zu benachrichtigen, wenn es nicht
sofort erledigt werden kann.
Es gibt unterschiedliche Möglichkeiten einen Help Desk zu organisieren. Zum
einen als zentrale Einheit, zum anderen als dezentrale Einheit. Ist der Help
Desk zentral organisiert, werden die Anliegen über einen SPOC koordiniert und
bearbeitet, egal ob es sich um ein Incident oder um ein Request for Change
(RFC) handelt. Vorteilig ist hier, dass der Kunde nur einen SPOC als Kon3 Darunter wird der Service zur Unterstützung oder auch zur Hilfe von Anwendern von
Hard- und Software verstanden.
114
taktpunkt hat. Er muss sich nicht verschiedene Kontaktadressen merken, sondern kann seine Anliegen einer Stelle zutragen. Nachteilig bei dieser Variante
ist, dass die Support-Mitarbeiter ein breiteres und umfassenderes Wissen für
die verschiedenen Anfragen benötigen, um den Kunden kompetent zur Seite zu
stehen. Für dieses Wissen benötigen die Mitarbeiter weitere und permanente
Schulungen. Ist dieses Wissen nicht vorhanden, kontaktieren die Kollegen aus
dem First-Level-Support öfter die Kollegen aus den anderen Supports, wobei
es zu einer Verzögerung gegenüber dem Kunden kommen kann, weil der Kunde länger auf seine Antwort warten muss. Des Weiteren kommt es so zu einer
Überlastung in den anderen Supporteinheiten. Bei einem dezentralen oder lokalen Help Desk gibt es einen Service-Support für verschiedene Kundengruppen
oder verschiedene Produktgruppen. Hier erhalten die Kunden meist schnellere
Hilfe als im zentralisierten Fall, haben dadurch aber auch mehrere Kontaktstellen. Problematisch kann sich hier die nicht einheitliche Datenbank erweisen.
Mehrere Supporter arbeiten an einem Problem, ohne dass es in einer Datei
gespeichert wird. Eine Lösungsmöglichkeit könnte der zentralisierte dezentrale
Ansatz, welcher auch als virtueller Ansatz bezeichnet wird, sein. Hier existiert
aus Sicht des Kunden nur ein Help Desk, also nur eine Kontaktstelle. Hinter
dieser verbergen sich jedoch dezentral weitere Service-Desk Supports. Kann ein
Mitarbeiter ein Anliegen nicht selber bearbeiten, wird es an den zuständigen
Help Desk weitergeleitet. [Els06, Bre07]
Um im Folgenden aus den Aufgaben und Zielen des Service Desk und damit
auch des Incident Managements Anforderungen an mögliche Software-Tools abzuleiten, wird der Prozess, der innerhalb der Service Desk abläuft, im Einzelnen
durchgegangen. Dabei soll stets die Frage im Hintergrund stehen: An welchen
Stellen ist eine Unterstützung durch ein Software-Tool besonders sinnvoll? Und
welche Aufgaben müsste dieses Tool im Einzelnen übernehmen? Hierbei ist anzumerken, dass der Prozess, der innerhalb des Service Desks abläuft, eng mit
anderen Abläufen verknüpft ist. Eine klare Grenze zwischen den Bereichen kann
nicht immer gezogen werden, so dass es zu einzelnen Überschneidungen kommt
und ggf. auf die anderen Prozesse verwiesen wird.
First-Level-Support. Der Ablauf innerhalb des Service Desks gliedert sich
in verschiedene Punkte.[Els06] Diese werden im Hinblick auf die obigen Fragen
betrachtet:
Anliegen entgegennehmen und registrieren: Die einzelnen Anliegen, die
im Service Desk als erste Anlaufstelle eingehen, können in verschiedener
Form vorliegen. Hier wären Anfragen in Form von E-Mail oder Telefon
denkbar. Für eine sinnvolle Erfassung bzw. Dokumentation der Anliegen
sind im Vorfeld grundsätzliche Entscheidungen zu treffen. Es stellt sich die
Frage nach der Art der Dokumentation, also wie die Daten erfasst werden sollen. Des Weiteren müssen natürlich die spezifischen Gegebenheiten
des aktuellen Anliegens erfasst werden. Es muss also entschieden werden,
welche Daten von Relevanz für die effiziente Be- und Verarbeitung sind.
Für die Zuweisung sind allgemeine Daten zum Kunden, also u.a. Name,
Adresse, Kundennummer und Datum inkl. Uhrzeit der Kontaktaufnahme
relevant. Für die Erfassung von Anliegen ist es ratsam, zentral und geregelt
vorzugehen, so dass keine Abhängigkeit von der willkürlichen Arbeitsweise eines Service Desk-Mitarbeiters besteht. Es lässt sich somit festhalten,
115
dass die Mitarbeiter einheitlich vorgehen müssen. Die Dokumentation der
Anliegen in einer Datenbank ist eine sinnvolle Vorgehensweise. Im Gegensatz zu einer einfachen Niederschrift des Problems kann mit Hilfe der
Datenbank strukturiert vorgegangen werden. Das Tool soll den Mitarbeiter des Service Desk dahingehend unterstützten, dass eine strukturierte
Erfassung des Anliegens möglich ist. So ist es für den Mitarbeiter zeitsparend, wenn er die einzelnen Daten in einer bereits fertigen Maske in
die dafür vorgesehenen Felder eintragen kann. Dadurch kann nicht nur
Zeit gespart werden, sondern es ist zudem noch gewährleistet, dass der
Mitarbeiter auch alle relevanten Informationen des Kunden strukturiert
erfasst. Es sollte möglich sein, die Anliegen der Kunden zu identifizieren, so dass eine mehrmalige Registrierung eines Anliegens ausgeschlossen
werden kann. Dies ist natürlich stets verbunden mit den jeweiligen spezifischen Gegebenheiten, die sich im Unternehmen wiederfinden. So sind
die Anliegen, welche im Service Desk eines Computerlieferanten auftreten
natürlich andere, als die bei einem Telekommunikationsunternehmen.
Klassifizierung des Anliegens: Sobald der Mitarbeiter alle relevanten Daten des Vorgangs aufgenommen hat, muss er eine erste Einordnung des
Anliegens vornehmen. Liegt bei dem Kunden keine Störung vor, sondern
handelt es sich um eine Anfrage für eine Änderung, leitet der Mitarbeiter des Service Desks die Daten zum Change Management weiter. Der
weitere Ablauf in diesem Fall wird somit bei der Behandlung des Change
Managements wieder aufgegriffen. Wichtig ist hier, wie bei allen Interaktionen zwischen den einzelnen Prozessen, dass eine gute und problemfreie
Kommunikation erfolgt. Liegt jedoch eine akute Störung beim Kunden
vor, so muss der Mitarbeiter weitere Schritte einleiten, um die Störung
möglichst schnell weiter zu klassifizieren und bestenfalls sogar gleich zu
beheben. Dazu muss er herausfinden, um welche Art von Störung es sich
handelt, oder ob das Problem evtl. sogar schon bekannt ist. Hierbei ist
es ein Vorteil für den Mitarbeiter, wenn er auf ein gutes Archiv vergangener Fälle zurückgreifen kann. Dies kann in kleinen Unternehmen oder
in einem überschaubaren Umfeld natürlich eine selbst erstellte Liste oder
einfach das Gedächtnis eines Mitarbeiters sein. Je größer ein Unternehmen
jedoch ist oder je mehr Störungsfälle auftreten, umso schwerer wird es sich
vorzustellen, dass der Mitarbeiter dies ohne technische Unterstützung leisten kann. So ist es für ihn an dieser Stelle hilfreich, wenn das manuelle
Suchen in langen Archivlisten entfällt und ein Tool ihm die Möglichkeit
bietet, per Schlagwortsuche nach vorherigen Störungsfällen zu suchen. Um
eine Klassifizierung vorzunehmen, die nicht nur von der Entscheidung des
Mitarbeiters abhängt, kann eine Art Bewertungsbogen generiert werden,
der aufgrund der Eingaben des Mitarbeiters auch eine Klassifizierung erleichtert. Sobald der Mitarbeiter die Störung an dieser Stelle klassifiziert
hat, entscheidet sich sein weiteres Vorgehen. Liegt eine Störung vor, die
zwar bekannt ist, er selbst jedoch nicht lösen kann, oder gibt es eine unbekannte Störung, erfolgt eine Weiterleitung im Incident bzw. zum Problem
Management. Auch die Behandlung dieser Fälle wird an entsprechender
Stelle wieder aufgegriffen. Handelt es sich jedoch um eine bekannte Störung, zu dessen Lösung der Service Desk Mitarbeiter alleine in der Lage
ist, sollte er für eine weitere Unterstützung des Kunden sorgen.
116
Bearbeitung von Störungen: Nachdem die Störung klassifiziert wurde und
bekannt ist, gilt es nun eine Lösung zu finden und die Störung zu beheben,
da eine schnellstmögliche Wiederherstellung des Service das oberste Ziel
des Service Desk ist. So gilt es auch an dieser Stelle Zeit zu sparen und
die Suche nach einer Lösung durch den Einsatz eines Software-Tools zu
beschleunigen. So ist es sinnvoll, wenn bei der vorherigen Suche nach einer
Störung auch gleich eine oder mehrere mögliche Lösungsvorschläge dazu
vermerkt sind. Auch dies setzt das Vorhandensein und die kontinuierliche
Pflege eines guten und vollständigen Archivs voraus. Hat der Mitarbeiter eine Lösung gefunden, kann dem Kunden geholfen werden und eine
schnelle Wiederherstellung des Service erfolgen.
Abschluss & Speicherung des Lösungsweges in der Datenbank: Ist der
Service wieder hergestellt, muss der Vorgang abgeschlossen und das Problem mit der Lösung in einer Datenbank vermerkt werden. Wie zuvor
erläutert spart es viel Zeit, wenn der Mitarbeiter auf eine gut gepflegte Datenbank zugreifen kann. Ein Tool kann die Suche innerhalb dieser
Daten vereinfachen, dies nützt jedoch nichts, wenn sie nicht durch die
Mitarbeiter ständig gepflegt und aktualisiert wird. Nur durch die korrekte
und vollständige Erfassung des Vorgangs durch den Mitarbeiter können
für zukünftig auftretende Probleme zeitnah Lösungen gefunden werden.
Falls das Problem innerhalb des First-Level-Supports nicht abgeschlossen werden kann, d.h. der Mitarbeiter im Service Desk das Anliegen nicht lösen kann,
so wird es an den Second-Level-Support weitergeleitet.
Second-, Third-, und N-Level-Support. Da bisher keine sofortige Lösung
der Störung vorhanden ist, erfolgt nun die Weiterleitung an den Second-LevelSupport. Dort beschäftigen sich spezialisiertere Support-Teams, die nach Fachbereichen gegliedert sind, weiter mit dem Problem.[Its07]
Analyse und Diagnose: In diesem Bereich beschäftigen sich die Experten mit
der weiteren Analyse, dessen Ziel die Diagnose der Störung ist. Da sie ein
größeres Fachwissen besitzen als die Service-Desk Mitarbeiter, findet hier
eine intensivere Suche statt. Die Anforderungen an ein eingesetztes Tool
sind ähnlich zu denen des Service Desk. Bei dieser Tätigkeit ist es möglich,
die Datenbank noch vielfältiger zu nutzen.
Abschluss oder Weiterleitung: Sobald eine Lösung gefunden wurde, findet
ein Abschluss der Störung statt. Dieser muss natürlich auch in der Datenbank dokumentiert werden, so dass er für spätere Anliegen auch als Recherche zur Verfügung steht. Ist auch hier der Abschluss nicht möglich, so
erfolgt eine Weiterleitung an den Third-Level-Support. Dieser besteht aus
Spezialisten-Teams, die sich analog zum Ablauf im Second-Level-Support
mit dem Anliegen befassen. Dieser Vorgang wird auf N-Leveln wiederholt,
bis die Störung abgeschlossen wird. Ggf. erfolgt eine Weiterleitung an das
Problem Management.
4.3.3
Problem Management
Vorangehend wurde das Incident Management betrachtet, dessen oberste Priorität die Wiederherstellung des Services ist. An dieser Stelle knüpft die Aufgabe
117
des Problem Managements an und bildet somit eine Art zweite Ebene des Incident Managements. Dort werden die Ursachen, die einer Störung zugrunde
liegen, meist nur sehr selten festgestellt. Sobald für einen Fall keine Ursache
festgestellt werden kann, bekommt ein Incident die Bezeichnung Problem. Die
Lösung dieser Probleme ist vielfach kompliziert und aufwendig, da unter anderem ein Problem durchaus auf mehrere Incidents zurückgeführt werden kann
und sie wiederholt auftreten. So kann ein bestimmter Abbruch durch ein Aufeinanderfolgen bestimmter Fehlerquellen herbeigeführt werden. Um diese komplexen Vorgänge erfassen zu können, bedarf es anderer Prozessverläufe als beim
Incident Management. So ist es Aufgabe des Problem Managements, die eigentliche Ursache für das Auftreten von Störungen zu ermitteln. Die Auswirkungen
dieses Problems sollen minimiert und ein Lösungsweg zur endgültigen Beseitigung der Störung erarbeitet werden. Als Known Error wird dann ein Problem
(oder Incident) bezeichnet, dessen Ursache bekannt ist. Außerdem sollte das
Problem Management versuchen bereits im Vorfeld, also proaktiv, das Auftreten
von Störungen durch vorbeugende Maßnahmen zu minimieren. Beispiele in der
IT gibt es viele, wie Hardware-Fehler, Netzwerkfehler oder Betriebssystemabstürze. Für diese Vorkommnisse können unterschiedliche Ursachen vorliegen, so
dass durchaus zeitgleich verschiedene Experten einzubinden sind.[Fis06, Els06]
Mit dem Problem Management werden verschiedene Ziele verfolgt. Dies ist zum
einen die Eliminierung der Ursachen der auftretenden Probleme und zum anderen, ähnlich wie beim Incident Management, eine Aufrechterhaltung der ITDienstleistungen. Außerdem sollen hier durch vorausschauendes Handeln Probleme und längerfristige IT-Systemunterbrechungen vermieden werden. Gegebenenfalls werden durch das Problem Management notwendige RFCs in der
IT-Infrastruktur eingeleitet.
In ITIL wird das Problem Management in drei Subprozesse unterteilt, die Problem Control, die Error-Control und das Proactive Problem Management. Diese
umfassen sowohl reaktive als auch proaktive Aktivitäten. Während das reaktive
Problem Management nach Ursachen bereits eingetretener Störungen sucht und
Verbesserungsvorschlägen macht, versucht das proaktive Problem Management
Schwachstellen aufzuspüren und Störungen im Vorfeld zu verhindern. Wie die
Abläufe der einzelnen Prozesse des Problem Managements nun genau aussehen
und welche Anforderungen sich an ein Software Tool dadurch ergeben, soll nun
im Einzelnen herausgearbeitet werden.[Els06]
Problem-Control. Die Tätigkeitsfelder der Problem- und Error-Control sind
verknüpft. Die Problem-Control befasst sich mit der Problembearbeitung. In
dieser ersten Phase des Problem Managements werden die vom Service Desk
und Incident Management weitergeleiteten Probleme beschrieben, klassifiziert
und abgespeichert. Daran anschließend erfolgen die Untersuchung des Problems
und dessen Auswirkungen auf den Service. Soweit möglich sollen hier die Ursachen gefunden werden. Ist die Ursache gefunden liegt nun kein Problem mehr
vor, sondern ein Known Error. Die fehlerhafte Komponente ist identifiziert, das
Problem ist jedoch noch nicht behoben. Für eine genauere Analyse wird der
Prozess der Problem-Control vereinfacht dargestellt.[Els06]
Klassifizierung und Kategorisierung des Problems: In dieser ersten Stufe treffen die Probleme ein, die durch das Incident Management von einer
Störung zu einem Problem deklariert und weitergeleitet worden sind. Man
118
spricht von Problemen, wenn mit einem wiederholten Auftreten gerechnet
wird. Bei der Identifikation müssen die Daten, die zu einem Problem gehören, erfasst und in eine Datenbank eingestellt werden, ähnlich wie bei einer
Störung. Das Problem wird beschrieben und erfasst, wobei es hilfreich ist,
die Daten der im Vorfeld aufgenommenen Störung vorliegen zu haben.
Auch hier kann ein eingesetztes Tool helfen, die Daten strukturiert und
vollständig zu erfassen, indem es durch eine fertige Maske dem Mitarbeiter die Eingabe der Daten erleichtert und außerdem dafür sorgt, dass die
Daten auch von anderen Mitarbeitern schnell wiedergefunden werden können. Des Weiteren müssen die Probleme insofern klassifiziert werden, dass
sie in unterschiedliche Gruppen unterteilt werden. Es muss erfasst werden
zu welcher Kategorie sie gehören, welche Auswirkungen es auf geschäftliche Abläufe geben kann, welche Dringlichkeit dem Problem zugesprochen
wird, welche Priorität es hat und wie der aktuelle Status des vorliegenden
Problems lautet.[Its07] Auch zur Aufnahme dieser Daten kann ein Tool
eine strukturierte Vorgehensweise ermöglichen und unterstützen.
Zuweisung zum Problem-Management Experten: Bevor die genaue Untersuchung und eine zeitnahe Lösung des Problems angestrebt werden
kann, müssen die Daten dem für das Problem zuständigen Experten zugewiesen werden. Dieses Vorgehen kann ein Tool insofern erleichtern, indem
es nach der Klassifizierung des Problems die für das Problem verantwortliche Person kennt, eine Verknüpfungen zu den zuständigen Problemlösern
bereitstellt und diese Experten, z. B. per E-Mail automatisch über das
Problem inklusive aller darüber vorhandenen Daten informiert werden.
Analyse und Diagnose des Problems: Nun erfolgt eine Analyse der für das
Problem zuständigen Experten. Die Untersuchung und die Diagnose des
Problems kann ein langwieriger Prozess sein, bei dem versucht wird herauszufinden, welche Ursache einem Problem zugrunde liegt. Dazu werden
wiederholt Tests durchgeführt, um das Problem immer weiter einzukreisen. Hierbei findet ständiger Kontakt mit den anderen Prozessen statt.
Hier müsste ein Tool in der Lage sein, sowohl den Verlauf eines Problems
zu dokumentieren als auch die Interaktion mit den anderen Prozessen
ausreichend abzubilden. Wichtig ist hier, wie eigentlich überall, dass außerdem eine gute und ständige Kommunikation zwischen den einzelnen
Prozessen stattfindet. Notwendige Informationen zur Untersuchung des
Problems werden also von und zu den anderen ITIL- oder ManagementProzessen geliefert. Auch hier ist ein Tool hilfreich, mit dem die eingegebenen Informationen zu jeglichen Vorgängen prozessübergreifend eingesehen
und verwendet werden können.
Abschluss des Problems oder Überleitung zur Error Control: Ist das
Problem identifiziert, erfolgt ein Abschluss in der Problem Control. Die
Lösung des vorliegenden Problems erfolgt dann in der sich anschließenden
Error-Control. Wichtig ist zu diesem Zeitpunkt, dass auch die anderen
Prozesse über den aktuellen Stand und die Identifizierung des Problems
informiert werden. Diese Arbeit kann ein Tool erleichtern, indem es automatisch Rückmeldung über die identifizierten Probleme und den Problemlösungsfortschritt zu den anderen Prozessen gibt. Somit wird dem
Mitarbeiter einerseits die Zeit erspart, die übrigen Mitarbeiter eigenhän-
119
dig zu informieren und andererseits auch sichergestellt, dass niemand diese
Informationen verspätet oder gar nicht erhält.
Error-Control. Bei der Error-Control erfolgt nun eine Fehlerbearbeitung.
Für die Known Errors sind die Ursachen und die Lösungsaktivitäten bereits
bekannt und können eingeleitet werden. Im Rahmen der Error-Control werden
Lösungswege neu ermittelter Probleme erarbeitet und im Bedarfsfall ein RFC an
das Change Management gestellt. Auch hier wird der dort stattfindende Prozess
vereinfacht dargestellt.[Els06]
Identifizierung des Fehlers : Für die Known Errors, die an dieser Stelle eintreffen, sind die Lösungswege bereits bekannt und können aus einer gut
gepflegten Datenbank entnommen werden. In dem Augenblick, in dem
die Ursache des Problems festgestellt wurde, wird das Problem zu einem
Fehler und die Fehlerbehandlung nimmt ihre Arbeit auf. Der Fortschritt
des Lösungswegs der bereits bekannten Fehler wird weiter überwacht. Für
die Ermittlung neuer Fehler sollten dem Mitarbeiter mehrere Hilfsmitteln zur Fehlersuche zur Verfügung stehen. Dazu werden eine Reihe von
Komponenten, Systemen, Datensammlungen und Programmen benötigt.
Auch hier muss er mit Unterstützung eines Tools in der Lage sein, auf die
notwendigen Informationen der anderen Prozesse zugreifen zu können.
Ermittlung eines Lösungswegs: Für die ermittelten Fehler müssen nun neu
initiierte Lösungswege gefunden werden. Hierbei ist es notwendig, dass
der Mitarbeiter auf bereits vorhandenes Lösungswissen einer Datenbank
zugreifen kann, welches ihm bei der Ermittlung einer neuen Lösung helfen kann. Alle Lösungsaktivitäten, die er vollzieht, müssen von ihm dabei
natürlich auch festgehalten werden, damit auch im Nachhinein nachvollzogen werden kann, welche Lösungsvorschläge ggf. auch zu keiner Lösung
führten, um in der Zukunft Zeit zu sparen. Die Auswirkungen der gefundenen Lösung müssen weiter beobachtet werden. Nach der Lösungssuche
wird dann eine optimale Lösung bestimmt. Diese führt bestenfalls zu einer
Beseitigung des Fehlers, ggf. mit einer Änderungsanforderung des Problem
Managements an das Change Management, also einem RFC. Eine Lösung
kann auch so aussehen, dass der bekannte Fehler weiter auftreten kann,
da er schnell behoben werden kann und eine endgültige Beseitigung zu
zeit- oder kostenintensiv wäre.[Its07]
Dokumentation der gefundenen Lösung: Wie auch immer die vorher getroffene Lösung aussieht, ist es wichtig, dass die Lösung umfassend dokumentiert wird. Somit kann sichergestellt werden, dass auch die Lösungen
in Zukunft auftretender Probleme schnell in einer Datenbank gefunden
werden können. Damit soll verhindert werden, dass eine Lösung nochmals
neu erarbeitet werden muss, weil sie vorher nicht vollständig dokumentiert
wurde und somit viel Zeit kostet. Abschließend müssen die anderen Prozesse über die Lösung informiert werden. Eine automatische Benachrichtigung an die betroffenen Anwendergruppen durch ein eingesetztes Tool
erleichtert und beschleunigt auch hier die Arbeit. Dies ist u.a. für das Incident Management besonders wichtig, da somit eine schnelle Verwendung
der neuen Lösungen dort gewährleistet ist. Auch hier gilt es nochmals zu
120
betonen, dass eine stetige Kommunikation der einzelnen Prozesse für einen
erfolgreichen Abschluss zwingend notwendig ist.
Proactive Problem Management. Das Proactive Problem Management
behandelt die frühzeitige Identifikation eines Problems oder allgemein die Erkennung von Schwächen in der Infrastruktur durch Trendanalysen. Somit ist es
kein Prozess im eigentlichen Sinn. Es sollen Vorkehrungen getroffen werden, um
ein Problem bestenfalls gar nicht erst entstehen zu lassen. Dazu können bereits
aufgetretene Störungen und deren Lösungen analysiert werden, um mögliche
Probleme schon im Vorfeld zu erkennen. Das Proactive Problem Management
erfüllt folgende Aufgaben ([Els06]):
Erstellung von Trendanalysen: Zur Einführung des Problem Managements
wird es überwiegend reaktiv sein, allerdings sollte eine Entwicklung hinsichtlich proaktiver Mechanismen erfolgen. Eine Aufgabe darin ist die Erstellung von Trendanalysen. Hierbei könnte ein Tool insofern hilfreich sein,
als dass es bereits eine Funktion enthält, um eine Trendanalyse der einzelnen Tickets zu erstellen, d.h. Themen und Vorfälle, die wiederholt auftreten, sollten angezeigt werden und eine Auswertung der Daten somit erleichtert werden. Somit können Komponenten, die anfällig sind, oder bei
denen eine Überlastung droht, genauer beobachtet werden. Genauso wird
versucht, Störungen, die in einem Bereich auftreten, bereits im Vorfeld in
anderen Bereichen zu verhindern.
Weiterleitung von Auswertungen an das IT-Management: Die Analysen und Auswertungen sind natürlich nur dann nutzbar, wenn die Informationen auch allen anderen bereitgestellt werden. Genau wie die Lösungen
eines Problems müssen auch die im Vorfeld ermittelten Schwächen an die
anderen Prozesse weitergeleitet werden. Die Aufgabe eines Tools könnte
es hierbei sein, sobald an einer Stelle eine Schwäche identifiziert wurde,
die Informationen automatisch an die betroffene Stelle weiterzuleiten und
zu informieren, ohne dass dies viel Zeit und Aufwand in Anspruch nimmt.
4.3.4
Change Management
Wie bereits im Kapitel 4.3.2. erwähnt, nehmen die Mitarbeiter des Service-Desk
zunächst alle Anliegen entgegen. Diese werden aufgenommen, und strukturiert
in einer Datenbank erfasst. Wenn sich bei der Kategorisierung nun herausstellt,
dass es sich um einen RFC handelt, wird es an das Change Management weitergeleitet. In diesem Abschnitt geht es nun um die Aufgaben, Funktionen und
Ziele des Change Managements. Die Erfahrung hat gezeigt, dass Probleme und
Störungen häufig auf Änderungen zurückzuführen sind. Ursache dieser Probleme sind oftmals überstürzte und wenig durchdachte Änderungen, oder unzureichende Planungen im Vorfeld.[Its07] Das Change Management soll nun gewährleisten, dass die oben genannten beantragten Änderungsanforderungen in
Form von RFCs geplant und kontrolliert ablaufen. Hierbei ist darauf zu achten,
dass änderungsbedingte Störungen zu vermeiden oder wenigstens zu minimieren sind.[Fis06] Voraussetzung für Änderungen ist jedoch, dass diese im Vorfeld
genau überprüft und kontrolliert werden, ob die Changes ohne weitere Rücksprache durchgeführt werden können. [Bre07] Die RFCs können im Wesentlichen in
drei Bereiche aufgeteilt werden ([Its07]):
121
Neuerungen und Verbesserungen: Diese beinhalten neue Methoden und
Konzepte, sowie technische Verbesserungen. Dadurch können neue strukturelle Fehler und Probleme entstehen, die vorher in dieser Art und Weise
nicht bekannt waren.
Änderungen: Änderungswünsche können sich auf Soft- und Hardwareänderungen beziehen oder auch auf Betriebssysteme. Aber auch Modernisierungen oder der Austausch von Kabeln und/oder Hardware gehört in diesen Bereich.
Korrekturen: Diese sollen die strukturellen Fehler und Probleme beheben.
Im weiteren Verlauf wird auf diese Unterteilung nicht weiter eingegangen, und
zur Vereinfachung wird der Ausdruck Änderungen oder Change für alle Anliegen
verwendet.
All diese Änderungen sind mit einem gewissen Risiko behaftet und können zu
einem Ausfall der Service-Leistungen führen. Es muss jedoch nicht nur darauf
geachtet werden, dass die Änderungen schnell und ohne Komplikationen durchgeführt werden, ebenso wichtig ist es auch, dass das System hinterher konsistent
und ohne Fehler und Probleme funktioniert. Aus diesem Grund muss eine Änderung geplant werden, und kann nicht ad hoc durchgeführt werden. Es ist auch
darauf zu achten, ob nur ein Mitarbeiter betroffen ist, oder die ganze Belegschaft eines Unternehmens. Diese Faktoren zu berücksichtigen ist die Hauptaufgabe des Change Managements. Zusätzlich zu beachten ist, dass Soft- und
Hardware selten kostenlos zur Verfügung gestellt werden. Es ist daher nicht ohne
weiteres möglich, ohne Lizenzprüfung die Programme zur Probe zu installieren.
Auch die Bevorratung der benötigten wichtigsten Ersatzteile ist Aufgabe dieses
Supports. Zusammengefasst lässt sich sagen, dass sich die Aufgaben aus einem
Zeitmanagement und aus vorbereitenden Aufgaben zur Implementierung von
Änderungen zusammensetzen. Nicht zu vergessen ist die permanente schrittweise und aktuelle Dokumentation aller Handlungen von jedem Mitarbeiter. Nur
durch diese sorgfältige Vorgehensweise wird eine effiziente und kostengünstigere
Arbeitsweise auf Dauer gewährleistet.[Els06]
Um nun auch hier aus den Aufgaben und Zielen des Change Manangement Anforderungen an mögliche Software-Tools abzuleiten, wird auch hier der Prozess,
der innerhalb des Change Managements abläuft, im Einzelnen durchgegangen.
[Els06] In einem ersten Schritt wurden die Daten im Service Desk als Change
deklariert und dann an das Change Management weitergeleitet.
Erfassung des RFC, Kontrolle und Speicherung in der Datenbank:
Wichtig ist vor allem die korrekte Erfassung der Änderung in Form
eines RFCs. Hier decken sich die Anforderungen an ein Tool mit den
Anforderungen aus dem Service Desk. Hier wäre es demnach auch wieder
von Vorteil, wenn für diese Erfassung eine vorgegebene Maske existiert,
so dass die wichtigen und wesentlichen Elemente erfasst werden müssen,
um überhaupt im Programm weiterzuarbeiten. Wichtige Informationen
können eine Identifikationsnummer, der Auslöser des Changes, eine
Begründung für die beantragte Änderung, Datum der Beantragung und
Datum der geplanten Durchführung sein. Dieses Verfahren schützt den
Benutzer vor der Gefahr, wichtige Daten bei der Eingabe zu übersehen.
Im weiteren Verlauf muss noch geklärt werden, ob der Antragsteller auch
122
berechtigt ist, diesen Änderungswunsch anzubringen. Ist das nicht der
Fall, wird das RFC sofort abgelehnt. Wünschenswert wäre an dieser Stelle,
wenn das Programm diese Kontrolle automatisch durchführt, indem sie
den Antragsteller mit den hinterlegten berechtigten Personen abgleicht
und bei entsprechendem Verstoß automatisch eine E-Mail verschickt, dass
diesem Änderungswunsch nicht weiter nachgegangen werden kann. Dieser
wird mit der entsprechenden Begründung versehen. [Its07] Nach der
Erfassung erfolgt eine Kontrolle auf eventuelle Doppelerfassung oder auch
auf nicht durchführbare RFCs. Diese Änderungen sollten dann automatisch mit einer entsprechenden Begründung abgewiesen werden. Zudem
werden dann auch nach der Akzeptanz des RFCs weitere Informationen
hinzugefügt, wie z.B. die Beurteilung der Auswirkungen. Das geplante
Datum zur Umsetzung und auch der aktuelle Bearbeitungsstatus sollte
angezeigt werden.
Im weiteren Verlauf wird eine Prioritätsstufe bzw. eine Kategorisierung
vorgenommen. Unter Priorität wird die Dringlichkeit des Changes verstanden. Die Kategorie bestimmt sich aus der Grundlage und den Auswirkungen der Änderungen. Nach ITIL werden die Prioritäten in vier Bereiche
eingeteilt. Es reicht von der höchsten, über die hohe und normale Priorität
bis zur niedrigen Priorität. Die Kategorien werden eingeteilt in geringfügige, erhebliche und weitreichende Folgen. Auch hier wäre es angenehmer,
wenn das Programm schon einen Vorschlag für die Kategorie bzw. Priorität macht. Dieser Vorschlag könnte auf vorhandenen RFCs aufbauen, bei
denen es zum Beispiel um eine ähnliche Angelegenheit geht, oder auch um
eine gleiche Dringlichkeit.
Erstellung von Zeit-/Installationsplänen und deren Implementierung:
Nachdem das RFC genehmigt wurde, muss nun bedacht werden, wie
umfangreich diese Änderung ist, um daraus Rückschlüsse auf die benötigte Mitarbeiteranzahl und auf die benötigten Arbeitsstundenzahlen zu
ziehen. In diesem Punkt arbeitet das Change Management eng mit dem
Release Management zusammen, denn dieses ist dafür verantwortlich,
dass genügend Ressourcen zur Verfügung gestellt werden. Von Vorteil ist
es hier auch, wenn das Change Management im permanenten Kontakt zu
den anderen laufenden Projekten steht, um sich auch hier immer wieder
über den aktuellen Stand zu informieren.
Ein weiterer Punkt ist das Erstellen eines Backout-Verfahrens. Dieses bietet die Möglichkeit, die Änderung wieder rückgängig zu machen, wenn diese nicht das erwünschte Ergebnis liefert. Das Change Management darf ein
RFC nicht ohne Backout-Verfahren genehmigen. Auch hier ist es von Vorteil, wenn das Programm einen Hinweis gibt, wenn kein Backout-Verfahren
verzeichnet ist, damit es nicht zu Schwierigkeiten nach einer unzulässigen
Genehmigung kommt.
Freigabe der Änderung, Evaluierung und Abschluss: Nach der Freigabe durch das Change Management sollte eine Evaluierung durchgeführt
werden. Dabei ist allerdings zu beachten, dass standardisierte Änderungen nicht jedes Mal evaluiert werden müssen, bzw. dies in abgeschwächter
Form erfolgen kann. Wünschenswert wäre hier ein Evaluierungsprogramm,
in dem man gewisse Kriterien ausfüllen muss, so dass eine Vergleichs-
123
möglichkeit entsteht. Letztendlich liegt es im Verantwortungsbereich des
Change Managements, die Änderung einzuführen und auch zu überwachen. Voraussetzung hierfür ist eine detaillierte Dokumentation und permanente Aktualisierung. Hilfreich ist somit eine Evaluierung in Form eines
geeigneten, selbstentwickelten Fragebogens, der es ermöglicht, standardisiert vorzugehen.
4.3.5
Release Management
Die umfassende Planung und Durchführung von Hard- und Softwareeinführungen findet im Release Management seine Umsetzung. Das Hauptaugenmerk des
Release Managements liegt auf der Stabilhaltung der IT-Infrastruktur.[Bre07]
Unter einem Release wird eine „Reihe neuer oder geänderter KonfigurationsElemente 4 , die zusammenhängend getestet und in die Produktionsumgebung
überführt werden“ [Its07] verstanden. Ein Release kann dabei ein vorhandenes CI ersetzen oder aber neu sein.[Els06] Releases werden unterteilt in MajorReleases, welche erhebliche Änderungen bzw. Erweiterungen der Funktionalität zur Folge haben, in Minor-Releases, welche geringfügige Änderungen bewirken, und in Emergency Fixes, welche vorübergehend kurzfristige Änderungen vornehmen.[Its07] Es werden drei Release Arten Full-, Delta- und PackageRelease differenziert.5
Die Dokumentation der Releases erfolgt innerhalb der Definitive Software Library (DSL) und dem Definite Hardware Store (DHS). In der DSL werden alle
freigegebenen Software Releases, die Masterkopien der Software, und deren zugehörige Dokumente aufgeführt. Sie sollte von den im Folgenden noch zu erläuternden Prozessen des Release Managements losgelöst sein. Im DHS sind alle
Hardware Ersatzteile enthalten. Diese beiden Datenbanken stehen in Verbindung zur Configuration Management Database (CMDB), welche den Prozess
von der Planung bis zur Umsetzung dokumentiert und im Configuration Management erläutert wird.[Its07] Bezüglich der Erfassung innerhalb der Datenbanken muss man sich dann neben der Identifikationsnummer für verschiedene
Datenfelder entscheiden, nach denen die Inhalte der Datenbanken aufgeführt
werden sollen. Zu beachten ist, dass eine eindeutige Identifikation möglich wird.
So kann zwischen Releases schon durch die Anordnung der Versionsnummer
unterschieden werden.6 Außerdem gilt auch im Hinblick auf die Verwendung
eines Tools, dass grundsätzliche Entscheidungen für die Arbeit mit den Datenbanken getroffen werden sollten. Da stets verschiedene Personen mit diesen
Datenbanken arbeiten, ist ein standardisiertes Vorgehen auch für die spätere
Verwendung und Anbindung an weitere Prozesse von Nutzen. Ein einheitliches
Vorgehen erleichtert im weiteren Verlauf auch den Zugriff auf die vorhandenen
Informationen. Darunter fällt neben Art der Darstellung auch die Pflege der Daten, d.h. dass sie sich stets auf dem neusten Stand befinden. Eine fortlaufende
Kontrolle der Datenbanken ist somit zu empfehlen, sie stehen auch im fortwährenden Austausch mit den Aktivitäten, welche im Release Prozess angesiedelt
4 Konfigurations Elemente bzw. Configuration Items werden im weiteren Verlauf der Arbeit
mit dem Akronym CI abgekürzt.
5 Ein Full-Release bezeichnet dabei einen kompletten Austausch eines Releases, während bei
einem Delta-Release Changes an einem einzigen Release vorgenommen werden. Ein PackageRelease wiederum ist der Austausch zusammenhängender CIs.[Els06]
6 Beispiel: Version 1.0 für ein Major Release, Version 1.1 für ein Minor Release und Version
1.1.1 für einen Emergency Fix.
124
sind. Denkbar sind für ein derartiges Vorgehen prozessbezogene Checklisten,
welche von den involvierten Mitarbeitern ausgefüllt werden müssen und an die
entsprechenden Stellen weitergeleitet werden.
Die Aktivitäten des Release Managements sind in die Bereiche Entwicklungsumgebung, überwachte Testumgebung und Produktionsumgebung unterteilt. Zwar
sind einige der Aktivitäten variierbar, aber im Sinne einer strukturierten Planung sollte ein einheitliches Vorgehen angestrebt werden.[Els06] Im Folgenden
wird näher auf die Bereiche und die darin angesiedelten Prozesse eingegangen.
[Its07] Im Gegensatz zum Incident, Change und Problem Management sind
die konkreten Anforderungen an ein Tool innerhalb dieser Aktivitäten kaum
zu formulieren. Die Bearbeitung der Releases ist in jedem Unternehmen sehr
spezifisch. Es kann daher nur Ziel bei der weiteren Betrachtung sein, auf grundsätzliche Anregungen einzugehen.
Entwicklungsumgebung. In der Entwicklungsumgebung findet der Release
Build statt. Dies beinhaltet die Planung und Festlegung der Versionsgrundsätze,
also die Erarbeitung der Release-Richtlinien. Weiterhin wird der grundlegende
Entwurf, Aufbau und die Formierung des Releases vorgenommen, so dass ein
Release-Plan erstellt wird. Empfehlenswert ist es hier, ein standardisiertes Verfahren zu entwickeln, welches dann für einen einheitlichen Ablauf steht, und
einem die Möglichkeit gibt, den aktuellen Entwicklungsstand besser nachvollziehen zu können.
Es muss darauf geachtet werden, dass die einzelnen Releases bereits nach bestimmten Kriterien gekennzeichnet werden, so dass die Identifikation jedes Release eindeutig möglich ist.[Its07]
Überwachte Testumgebung. Im Bereich der überwachten Testumgebung
ist die Versionsprüfung und Abnahme des Realeses, die Planung des Roll-Out
sowie die Kommunikationsvorbereitung und Schulung angesiedelt. Unzureichendes Testen gilt als die häufigste Ursache bei nicht erfolgreichen Änderungen, so
dass diesem Bereich ein hohes Maß an Aufmerksamkeit zukommen sollte.[Els06]
Für die Abnahme eines Releases muss dieses vorher ausführlich getestet werden.
Die Tests erstrecken sich über Installationstests, Einzeltests, Tests auf Anwenderfreundlichkeit, am besten in einer Umgebung, die ähnlich seiner späteren ist.
Bei der notwendigen Vielfältigkeit dieses Tests ist auch hier eine vorherige einheitliche Planung anzuraten, und die Erfassung der Testdaten muss für eine spätere Auswertung erfolgen. Für die Roll-Out-Planung ist der bis hierhin erstelle
Release-Plan der Ausgangspunkt, welcher jetzt um die Implementierungspläne
erweitert wird. Jetzt muss ein genauer Zeitplan für das Roll-Out entworfen,
ein Aktionsplan erstellt und die Vorbereitung für die Kommunikation getroffen
werden.[Its07]
In dem Bereich der Kommunikationsvorbereitung und Schulung soll die Information der beteiligten Personen vorgenommen werden. Neben den Kunden müssen natürlich auch die Mitarbeiter des Service Desk als erste Schnittstelle zum
Kunden über die Änderungen informiert werden.
Produktionsumgebung. Dem Release Management obliegt die Überwachung der Verteilung bis hin zur Installation und Übergabe von Software und
Hardware an den Nutzer. Für eine Kontrolle und Überwachung des Transports
125
und der Auslieferung ist eine Dokumentation wünschenswert, in der beispielsweise Status-Berichte oder auch Auslieferungsbelege aufgenommen werden. Bei
der Installation wiederum ist ein einheitliches Vorgehen zu beachten, und dass
es nur durch autorisiertes Personal durchgeführt wird.[Its07]
Bei der Betrachtung der Aktivitäten wird vor allem die notwendige und ständige Interaktion zwischen den verschiedenen angesprochenen Bereichen deutlich.
So steht das Release Management in enger Verbindung zum bereits angesprochenen Change Management. Auch das im anschließenden Kapitel betrachtete
Configuration Management ist für eine erfolgreiche Einführung ein wichtiger Kooperationspartner für das Release Management. Damit diese Interaktion auch
durchgeführt wird, kann ein Tool hier helfen, an den entsprechenden Stellen
daran zu erinnern.
Grundsätzlich ist anzumerken, dass die Vielzahl an Prozessen, welche im Release
Management ablaufen, nur durch eine angemessene Zeitspanne zu lösen sind.
Damit dies möglich ist, muss darauf geachtet werden, dass von der Planung
bis zum Roll-Out ein entsprechendes Zeitfenster zur Verfügung steht. An dieser
Stelle ist es ratsam, den Kunden einzubeziehen und zu informieren, so dass er
nachvollziehen kann, in welchem Stadium sich die Entwicklung gerade befindet
und wann er mit einer Installation rechnen kann. Dies könnte zum Beispiel über
einen Statusbericht geschehen, welcher dem Kunden in regelmäßigen Abständen
zukommt.
4.3.6
Das Configuration Management ist zuständig für die IT-Infrastruktur. Ziel dabei ist es, alle IT-Komponenten zu dokumentieren und gesicherte Informationen über die IT-Infrastruktur allen anderen Prozessen jederzeit zur Verfügung
zu stellen. Diese Informationen sollen dabei stets auf dem aktuellen Stand gehalten werden. Dafür identifiziert, überwacht und kontrolliert das Configuration
Management die CIs und ihre Versionen. Dies erfolgt, indem es die Attribute, die
zu einem CI gehören, sowie die Beziehungen zu denen es mit anderen CIs steht,
in der CMDB abspeichert. Dazu werden für die Informationsbeschaffung Hardund Software Datenbanken und Softwarepakete genutzt, um Veränderungen innerhalb der IT-Infrastruktur korrekt zu erfassen. Die CMDB ist vorstellbar als
große Kartei, in dem sämtliche IT-Betriebsmittel registriert sind und die Beziehungen zwischen den einzelnen Karten festgehalten werden. Die einfachste Form,
die für eine CMDB denkbar ist, wären Formulare. Die CMDB unterscheidet sich
von Datenbanken, die mit Hilfe von Inventarisierungsprogrammen aktualisiert
werden. Und zwar insofern, dass sie nicht nur Informationen über die momentan
aktiven Hard- und Softwareprodukte liefert, sondern eher aufzeigt, wie die Infrastruktur aussehen müsste, wenn alle Regeln inklusive der Dokumentationen
beachtet werden.
Alle weiteren ITIL-Prozesse nutzen diese Daten für ihre Zwecke und sind von seinen Leistungen abhängig. Das IT-Management benutzt diese Daten für Berichtsund Entscheidungsaktivitäten.
Die Vorteile des Configuration Managements liegen darin, dass die Auswirkungen von Changes vollständig sichtbar werden, nicht autorisierte CIs oder illegale Software-Kopien identifiziert werden können und sinnvolle Analysedaten
geliefert werden. Außerdem werden durch das Vorhandensein des Configuration
Managements alle anderen Prozesse unterstützt.[Its07]
126
Der Ablauf innerhalb des Configuration Managements wird nicht immer strikt
eingehalten, sondern die einzelnen Aktivitäten laufen vielmehr parallel ab. Die
Aktivitäten des Configuration Managements umfassen im Einzelnen: [Its07]
Planung. Im Rahmen der Planung des Aufbaus eines Configuration Managements wird dessen Zweck und Umfang bzw. die genaue Detaillierung und
Priorisierung festgelegt.
Identifikation. Unter die Identifikations-Phase fallen die Bestimmung und
Pflege der Bezeichnungen und auch der Versionsnummern der einzelnen Komponenten, sowie deren Beziehungen. Dazu muss die Beschreibungstiefe der überwachten CIs definiert, die Namenskonventionen festgelegt, sowie die Erfassung
von Varianten geregelt werden.
Statusüberwachung. Innerhalb der Statusüberwachung wird die Lebensdauer einer Komponente verfolgt, außerdem werden Auswertungen über aktuelle
und veraltete CIs erstellt.
Kontrolle. Hier erfolgt eine Pflege der Daten indem sichergestellt wird, dass
Änderungen, die durch das Change Management erfolgt sind, autorisiert, vollständig und richtig in der CMDB erfasst worden sind.
Verifizierung und Audits. Es erfolgt eine Überprüfung, ob die Daten in der
CMDB noch mit der aktuellen Situation übereinstimmen.
Da, wie erwähnt, die Prozesse innerhalb des Configuration Managements oftmals parallel ablaufen, werden die Anforderungen allgemein formuliert und nicht
spezifisch in die einzelnen Prozessabschnitte untergliedert.
Eine erste wichtige Anforderung ist, dass für den Aufbau eines Configuration
Managements in einem eingesetzten Tool bereits eine integrierte CMDB vorhanden ist, mit deren Hilfe die CIs inklusive deren Attribute verwaltet werden
können. Für die Verwaltung sollten die Attribute und Klassen eines CIs bereits implementiert sein. Um die Aktualität der CMDB zu gewährleisten, sollte
das Tool in der Lage sein, geänderte Konfigurationen automatisch zu erfassen
und zu kontrollieren. Das Tool sollte so ausgewählt werden, dass Änderungen
und Erweiterungen innerhalb des Configuration Managements nicht behindert
werden.
Obwohl die Daten aus dem Incident-, Problem- und Change Management eigentlich nicht Bestandteil der CMDB sind, sollte dennoch eine Verknüpfung zum
Change- und Release- Management vorhanden sein, damit alle zugehörigen Incidents, Problems und Changes ausgewiesen werden können.
Zur Verifizierung der Audits könnte ein Audit Tool z.B. automatisch
Arbeitsplatz-PCs durchforsten, um Unstimmigkeiten aufzudecken. Es sollte jedoch keine automatischen Aktualisierungen vornehmen, da diese Unstimmigkeiten auf eine Umgehung des Change Managements hindeuten und weiter untersucht werden müssen.[Its07]
4.4
4.4.1
127
Betrachtung ausgewählter ITIL-Werkzeuge
Vorgehensweise
Nachdem in dem vorherigen Kapitel Anforderungen an ein Werkzeug formuliert
wurden, stellt sich die Frage, inwiefern die am Markt vorhandenen Werkzeuge
diese Anforderungen auch erfüllen können. Da es unzählige verschiedene Werkzeuge gibt, kann es nicht Ziel dieser Arbeit sein, einen Vergleich aller vorhandenen Werkzeuge vorzunehmen. Vielmehr werden exemplarisch zwei verschiedene Werkzeuge näher betrachtet. Dies ist zum einen das open-source Werkzeug
OTRS und zum anderen das kommerzielle Werkzeug Remedy. Basierend auf
den Daten, welche die Anbieter dieser Software auf ihrer Homepage und in den
entsprechenden Handbüchern zur Verfügung stellen, werden die Funktionen der
Werkzeuge aufgeführt und exemplarisch mit den vorher herausgearbeiteten Anforderungen in Bezug gesetzt.[Otr08, Bmc08]
4.4.2
Das Open Source-Werkzeug OTRS
OTRS gilt als der bekannteste Vertreter aus dem open-source Bereich und unterliegt der GNU, der General Public License. Damit eine Software als open-source
bezeichnet werden darf, muss sie verschiedene Eigenschaften erfüllen. Zum einen
muss die Software in einer lesbaren und verständlichen Form vorliegen, sowie
beliebig oft kopierbar und nutzbar sein. Zum anderen muss die Software verändert werden können und auch in der geänderten Form weiter verbreitet werden
dürfen. OTRS ist lizenzfrei im Internet als Download erhältlich. Dadurch fallen
keine Kosten für Lizenzgebühren an. Zudem bietet die Software Schnittstellen
zu vielen Betriebssystemen wie Windows oder Linux. Es ist einfach und schnell
im Unternehmen zu implementieren.[Nie07]
OTRS basiert auf dem oben dargstellten Ticket-System. Aufgrund der Datenmengen, die in einem Unternehmen eingehen, ist so ein Ticket-System sinnvoller
als reine E-Mailkorrespondenz. Denn hier können die Anfragen wie bereits erläutert miteinander in Zusammenhang gebracht werden. Die Gefahr der doppelten
Bearbeitung wird reduziert bzw. minimiert. Das Ticket beinhaltet alle Informationen zu einem bestimmten Kunden oder zu einem konkreten Problem. Jedes
noch so kleine Detail wird dokumentiert, und kann jederzeit wieder aufgerufen werden. Es besteht auch die Möglichkeit Tickets an Kollegen weiterzuleiten, und diese mit zusätzlicher Information in einer separaten Mail auszustatten. Zudem können unterschiedliche Zugriffsrechte definiert werden. Außerdem
können Tickets nach Prioritäten geordnet werden, die dann je nach Dringlichkeit abgearbeitet werden können. Auch die erwünschte Kategorienbildung ist
möglich.[Här07]
Im weiteren Verlauf soll nun herausgearbeitet werden, ob OTRS den oben genannten Anforderungen genügen kann.
Incident Management mit Service Desk. Für das Incident Management
mit dem Service Desk wird nun die weitere Betrachtung anhand der einzelnen
Phasen innerhalb des Prozesses vorgenommen, in die das Incident Management
bereits oben untergliedert wurde.
Anliegen entgegennehmen und registrieren: Aufgrund
des
TicketSystems wird das Erfassen der Daten vereinfacht. Für jede Störung
128
oder für jede Änderung wird ein eigenes Ticket angelegt. Es ist auch
nicht relevant, ob die Daten per Telefon oder per Mail eingehen. Aus
den eingegangenen E-Mails wird automatisch ein Ticket erstellt. Den
Supportern7 steht für die telefonische Entgegennahme eine Telefon-Maske
zur Verfügung, in der alle wesentlichen und relevanten Daten strukturiert
eingegeben werden können. Diese Daten werden gespeichert und sind für
alle anderen Mitarbeiter zu jeder Zeit ersichtlich. Es besteht natürlich
auch die Möglichkeit, dass mehrere Mitarbeiter zeitgleich an einem Ticket
arbeiten, oder ein Supporter an mehreren Tickets gleichzeitig.
Zudem bietet OTRS die Möglichkeit, dass die Kunden über eine entsprechende Maske im Programm Incidents und Changes selbstständig erfassen
können und via E-Mail an die Supporter schicken. Des Weiteren können
sich die Kunden auch über den aktuellen Bearbeitungsstand ihrer eigenen
Tickets informieren und auch weitere Anmerkungen eingeben. Natürlich
können die Supporter auch jederzeit den aktuellen Bearbeitungsstand an
die Kunden weitergeben. Diese Vorgehensweise ist in der folgenden Abbildung dargestellt:
Abbildung 4.3: Kundensicht OTRS. Quelle: http://otrs.org/images/
screen-2.0/customer-newTicket.png.
Es ist zu erkennen, dass der Kunde sich nach dem Einloggen in dem Programm selbständig über OTRS ein Ticket erstellen kann. Dieses erfolgt
über eine E-Mail in einer vorgegebenen Maske. Die Daten dieser E-Mail
werden dann automatisch in ein Ticket übertragen. D. h. der Supporter
muss die Daten nicht aus der E-Mail heraus in ein Ticket übertragen,
7 Die
Service-Desk Mitarbeiter werden in OTRS als Supporter bezeichnet.
129
sondern dies geschieht automatisch. Ebenso hat der Kunde über diese
Funktion die Möglichkeit sich über den Bearbeitungsstand seiner bereits
vorhandenen Tickets zu informieren. Des Weiteren stehen dem Kunden
noch weitere Anwendungen zur Verfügung, die hier jedoch nicht näher
betrachtet werden sollen.
Klassifizierung des Anliegens: Nach der Datenerfassung werden die Anliegen klassifiziert. Dieser Vorgang wird z. B. bei einem Telefongespräch
schon während der Datenaufnahme erfolgen, um den weiteren Verlauf des
Telefonats zu beurteilen. Je nachdem ob es sich um ein Incident oder
um einen Change handelt, wird das weitere Vorgehen beeinflusst. Durch
die verbesserten Kommunikationsmöglichkeiten können Prozesse wie Incidents oder Changes schneller und effizienter weitergeleitet werden. Nachdem die Klassifizierung erfolgt ist, wird das Anliegen entweder sofort vom
Supporter bearbeitet und abgeschlossen, oder er leitet das Anliegen weiter
an das Incident bzw. Change Management. In der folgenden Abbildung
ist zu erkennen, wie die Benutzeroberfläche für den Supporter von OTRS
aussieht.
Abbildung 4.4: Benutzeroberfläche OTRS. Quelle: http://otrs.org/images/
screen-2.0/queue.png.
Aus der Abbildung ist ersichtlich, dass diese in verschiedene Bereiche gegliedert ist. In dem oberen schwarzen Balken werden allgemeine Daten,
wie der Name des Supporters, das Datum und die Uhrzeit angezeigt. In
dem weißen darunterliegenden Bereich befinden sich verschiedene Icons zur
Bearbeitung der Tickets. Ebenso werden hier neu eingegangene E-Mails
angezeigt. In dem darunterliegenden weißen Bereich werden die Inhalte zu
130
dem aktuell geöffneten Ticket angezeigt. Im unteren Bereich der Maske
werden Funktionen, wie die Historiefunktion, zu dem Ticket dargestellt.
Auf der rechten Seite der Maske befinden sich weitere Angaben zu dem
Ticket. Unter anderem die Priorität und der Bearbeitungsstatus.
Bearbeitung von Störungen: Durch die gespeicherte, integrierte Datenbank
können alle Supporter auf das gespeicherte Wissen zugreifen. Dadurch ist
es den Mitarbeitern im Service Desk möglich, leichtere, häufig auftretende Störungen schneller und kundenfreundlicher zu bearbeiten. Viele Anliegen können schon vorab vom First-Level-Support geklärt werden, und
es benötigt keine Rücksprache mit den anderen Levels. Dadurch wird eine Entlastung der Mitarbeiter hervorgerufen, die Mitarbeiterzufriedenheit
steigt. Des Weiteren erfolgt eine kundenfreundlichere Abwicklung, weil die
Wartezeiten sich nicht so lange hinziehen.
Diese Vereinfachung ist nur bei Standard-Anliegen möglich. Was genau
ein Standard-Anliegen ausmacht kann innerhalb der Software definiert
werden. Wenn diese Daten hinterlegt sind, kann OTRS durch eine Schlagwortsuche eingehende E-Mails durchsuchen, und dann entsprechend der
Vorgabe einem Ticket oder einer Störung zuordnen, ohne dass ein Mitarbeiter sich dieser E-Mail widmet. Diese Vereinfachung kann für alle
bekannten und leicht korrigierbaren Incidents Anwendung finden. Es besteht die Möglichkeit, dass vorformulierte E-Mails automatisch auf eine
bestimmte Anfrage hin versendet werden. Dieser Automatisierungsvorgang entlastet die Mitarbeiter und ermöglicht es den Supportern, sich mit
wesentlichen und schwierigeren Anliegen zu befassen und auch schneller
und konkreter auf Kundenwünsche einzugehen.
Abschluss und Speicherung des Lösungsweges in der Datenbank:
Nachdem die Störung behoben ist, wird das Ticket geschlossen. Es wird
in der Datenbank abgelegt, und kann jederzeit wieder gelesen werden.
Eine weitere Bearbeitung des Tickets ist dann jedoch nicht mehr möglich.
Bei Bedarf muss dann ein neues Ticket angelegt werden, welches mit dem
bestehenden dann verknüpft werden kann. Kann ein Incident oder ein
Änderungswunsch nicht sofort erledigt werden, gibt es bei OTRS auch
eine Wiedervorlagemöglichkeit. Dadurch gerät kein Ticket in Vergessenheit. Des Weiteren gibt es die Möglichkeit, Tickets zu einem bestimmten
Event wieder aufzurufen. Interessant ist diese Funktion zum Beispiel
nach einem Update, um zu überprüfen, ob der Fehler behoben oder ein
Änderungswunsch umgesetzt wurde.
Problem Management. Im Folgenden werden die oben formulierten Anforderungen an ein Tool im Rahmen des Problem Managements mit den angebotenen Funktionen von OTRS verglichen. Hier werden die einzelnen Phasen, die
innerhalb der Problem-Control, der Error Control und des Proactive Problem
Managements ablaufen, jedoch nicht separat, sondern, um Überschneidungen
zu vermeiden, zusammengefasst betrachtet. Wie bereits beschrieben, gehen im
Problem Management die Störungen ein, für die das Incident Management keine Ursache feststellen konnte und die somit als Problem klassifiziert werden.
Diese werden wieder als Ticket innerhalb des Systems weitergeleitet. Die hier
131
eingegangenen Probleme lassen sich nicht so einfach klären oder beseitigen, oder
führen zu dauerhaften Ausfällen.
Mit Hilfe von OTRS kann die Anforderung umgesetzt werden, dass ein Tool
in der Lage sein sollte, die Daten strukturiert erfassen zu können. OTRS bietet durchgängige Unterstützung bei der Problemidentifizierung und -erfassung,
sowie bei der Klassifizierung von Problemen. Die Priorisierung dient hier als
Grundlage der Ressourcenzuteilung, wodurch die Probleme an die entsprechenden Experten weitergeleitet werden.
Für eine tiefgehende Analyse der Probleme oder Fehler bietet OTRS die Möglichkeit, ständig auf vorhandenes Lösungswissen in der Wissensdatenbank zugreifen zu können. Darin sind alle aktuellen und historischen Problemlösungen dokumentiert und können somit zur Klärung des Problems beitragen. Die
Lösungsentwicklung kann jederzeit von allen anderen Anwendern angeschaut
werden und alle können jederzeit an dem Problem arbeiten. Somit lässt sich
ermitteln, ob ein ähnliches Problem bereits bekannt ist und ob dafür schon eine
Lösung gefunden wurde. Dabei werden alle relevanten Informationen zur Verfügung gestellt, sowohl aus dem Bereich des Problem Management, als auch aus
allen weiteren ITIL-Prozessen. Des Weiteren beinhaltet das OTRS-Tool eine
gezielte, automatische Benachrichtigung über den Problemlösungsfortschritt an
die betroffenen Anwender, um Zeit zu sparen und eine vollständige Übermittlung der Informationen zu gewährleisten.
Um proaktiv Störungen im Vorfeld verhindern zu können, bietet OTRS u. a. die
Möglichkeit Ticket-Trendanalysen durchführen zu können, um von den Trends
innerhalb der Tickets auf mögliche Schwachstellen schließen zu können.
Change Management. OTRS bietet zurzeit noch nicht die Möglichkeit das
Change Management zu implementieren. Anzumerken ist, dass die RFCs über
den in OTRS vorhandenen Service Desk erfasst werden können. Die weitere
Vorgehensweise bzgl. der RFCs wird jedoch von OTRS nicht unterstützt.
Release Management. Auch hier bietet OTRS noch nicht die Möglichkeit
das Release Management umzusetzen.
Configuration Management. Bei OTRS ist mit dem Vorhandensein einer
integrierten CMDB die Möglichkeit gegeben, das Configuration Management
umzusetzen. Mit Hilfe der CMDB können die CIs, sowie ihre gegenseitigen Beziehungen und Abhängigkeiten erfasst und verwaltet werden. Auch Änderungen
der Attribute der CIs können vorgenommen werden. Dabei ist es bei OTRS möglich, die CIs den verschiedenen Klassen, nämlich Computer, Hardware, Software,
Netze zuzuordnen. Außerdem bietet OTRS eine Möglichkeit zum Management
der historischen, aktuellen und zukünftigen CI-Status, die im Rahmen der Statusüberwachung bei Problem-Diagnosen oder geplanten Changes hilfreich sein
können. Diese können durch ein chronologisches Life-Cycle-Management für die
CIs verwaltet werden. Alle Konfigurationsänderungen an CMDB-Daten werden
durch das OTRS-Tool protokolliert.
Des Weiteren kann durch den Einsatz von OTRS die IT-Infrastruktur virtualisiert abgebildet werden. Die anderen ITIL- Prozesse können integriert werden,
womit eine Verknüpfung zum Incident, Problem und Change Management be-
132
steht und damit alle zugehörigen Incidents, Problems und Changes mit einbezogen werden können.
Zusammenfassung. Abschließend lässt sich zu OTRS festhalten, dass es nur
einige der von ITIL genannten Prozesse aus dem Bereich Service Support abbildet. Da OTRS auf einem Ticket-System basiert, deckt es hauptsächlich die
Prozesse des Incident Managements in Verbindung mit dem Service Desk sowie
das Problem Management ab. Aus diesem Grund werden auch hier die meisten im Rahmen dieser Projektarbeit genannten Anforderungen beachtet. Durch
die übersichtliche Oberfläche von OTRS, werden die grundlegenden Anforderungen, wie die strukturierte Erfassung und Verwaltung der Daten, erfüllt. Die
beiden Prozesse Change und Release Management werden gar nicht unterstützt,
so dass für diese keine Informationen auf der Homepage bereitgestellt werden
und eine Überprüfung der aufgestellten Anforderungen nicht durchgeführt werden konnte. Das Configuration Management wird durch die Software wiederum abgedeckt. Die Grundanforderungen für die Umsetzung des Configuration
Managements ist das Vorhandensein einer integrierten CMDB, welche in diesem Werkzeug implementiert ist. Der Aufbau und der vorgegebene Ablauf von
OTRS bieten die Möglichkeit der Verknüpfung der einzelnen Bereiche, so dass
eine prozessübergreifende Kommunikation und ein permanenter Datenzugriff
ermöglicht wird.
4.4.3
Das kommerzielle Werkzeug Remedy
Remedy ist eine kommerzielle Software, die von BMC Software Inc.8 entwickelt wurde und seitdem von dem Unternehmen vertrieben wird. Für die weitere Betrachtung werden hauptsächlich die Informationen von der Webseite des
Unternehmens verwendet. Anzumerken ist in diesem Zusammenhang, dass die
Informationspolitik eines kommerziellen Tools eine andere als bei einem Opensource Tool ist. So werden die Vorteile von Remedy besonders herausgestellt.
Die Beschreibung der Funktionen erfolgt jedoch nicht zu konkret, wie es bei
frei zugänglichen open-source Lösungen eher vorzufinden ist. Remedy bietet eine Lösung an, die individuell auf das jeweilige Unternehmen abgestimmt wird.
Dazu offeriert Remedy das Baukastensystem Remedy IT Service Management.
Es besteht aus den vier folgenden Modulen, die flexibel miteinander kombiniert
werden können:
• Remedy Help Desk, der den Service Desk, das Incident Management sowie
das Problem Management umfasst
• Remedy Asset Management, welches das Configuration Management in
das Remedy IT Service Management implementiert
• Remedy Change Management, mit dem der ITIL-Prozess des Change Managements unterstützt wird
• Remedy Service Level Agreements, da aber dieses Modul nicht Bestandteil
der Prozesse des Service Supports ist, wird es in dieser Arbeit nicht weiter
betrachtet
8 Die
Firma hat ihren Hauptsitz in Houston, Texas, sowie zahlreiche Tochterfirmen weltweit.
133
Diese Bausteine sind unabhängig voneinander. Wenn sie von einem Unternehmen eingesetzt werden, so stehen sie dann miteinander in Beziehung und sind
damit verknüpft.
Auch bei diesem Werkzeug wird nun untersucht, inwiefern die Software Remedy den aufgestellten Forderungen genügen kann. Aufgrund der angesprochenen
Informationsproblematik ist es im weiteren Verlauf nicht möglich, den Ablauf
innerhalb der einzelnen Prozesse detailliert zu betrachten, so dass die einzelnen
Prozesse insgesamt betrachtet werden.
Incident Management mit Service Desk. Das Incident Management ist
in Verbindung mit dem Service Desk innerhalb dem Remedy Help Desk angesiedelt. Mit dem Remedy Help Desk wird die Schnittstelle zur Kommunikation
zwischen Kunden und Unternehmen geboten. Ausgangspunkt ist die Aufnahme
der Service Requests. Der Remedy Help Desk ist an dem bereits angesprochen
Prozessablauf des Incident Managements ausgerichtet. Für den ersten Schritt,
die Aufnahme und Klassifizierung des Anliegens, ist es möglich, das Anliegen
über verschiedene Kommunikationsmöglichkeiten (z. B. E-Mail, Telefon) aufzunehmen und ein Ticket zu erzeugen. So bietet das Tool von Remedy entlang
des Ablaufs verschiedene Möglichkeiten, welche sowohl Mitarbeiter des Unternehmens hinsichtlich einer Effizienz- und Produktivitätssteigerung des Services
Supports, als auch die Kunden unterstützen sollen. Grundsätzlich wird dabei
ein hoher Automatisierungsgrad betont, der sich u.a. durch die automatisierte
Weiterleitung der Tickets an die relevanten Support-Bereiche zeigt. Der Kunde kann bspw. den Status „seines“ Requests abfragen und kann sich so über
den Status quo der Bearbeitung informieren. Der Mitarbeiter des Remedy Help
Desk wird dahingehend unterstützt, dass eine automatische Weiterleitung des
Tickets an den zuständigen Support-Bereich erfolgt. Remedy bietet ein System
für die Klassifizierung bzgl. der Priorität, der Abgrenzung und der Reichweite
des Incidents an. Des Weiteren wird die Datenbank angeführt, welche allgemeine Lösungen und auch Lösungen für bereits bekannte Fehler zur Bearbeitung
der Anliegen zur Verfügung stellt. Die Mitarbeiter können diese integrierte Datenbank durchsuchen und falls eine Lösung vorhanden ist, diese dann an den
Kunden weitergeben. Wird keine Lösung gefunden, erfolgt eine Weiterleitung
an Spezialisten.
Vor allem die angesprochene Automatisierung und die Vereinfachung der
Support-Prozesse sind Eigenschaften, die nach den Informationen der Homepage, als Pluspunkte für dieses Tool zu sehen sind. Weitere Informationen zum
Remedy Help Desk liefert auch die Betrachtung des Problem Managements.
Problem Management. Die Umsetzng des Problem Managements erfolgt
bei Remedy auch innerhalb des Moduls Remedy Help Desk. Da in diesem Modul
ebenfalls die Umsetzung des Incident Managements enthalten ist wird sichergestellt, dass das Problem Management auf die zuvor im Incident Management
aufgenommenen Daten zugreifen kann. Des Weiteren ist für das Problem Management ein separates Klassifikationssystem enthalten, durch das die Probleme
nun weiter beschrieben und klassifiziert werden können. Diese Klassifikation ist
wichtig, um die Auswirkungen, die Dringlichkeit, die Priorität und den Status
des vorliegenden Problems zu erfassen. Um im Folgenden die einem Problem
zugrunde liegenden Ursachen ausfindig zu machen, ist das Programm in der
134
Lage, das aufgenommene Problem automatisch auf Übereinstimmungen mit bereits vorhandenen Incidents, Problemen und Known-Errors zu überprüfen. Der
Vorteil ist hier das Vorhandensein einer CMDB, die einen Überblick über die
vorhandenen CIs gibt und somit als Hilfsmittel bei der Fehlersuche eingesetzt
werden kann. Die Probleme werden mit Hilfe des Programms über die verschiedenen Stufen innerhalb des Problem Management Prozesses verfolgt und
überwacht. Gleichzeitig werden Audits erstellt, um alle betroffenen Anwendergruppen über den aktuellen Stand informieren zu können. Da alle Schritte
dokumentiert werden, ist es möglich den Analyseprozess neuer Probleme weiter
zu unterstützen. Außerdem ist diese Dokumentation hilfreich, um auch die anderen Prozesse über den aktuellen Stand und über die Lösungen der Probleme
zu informieren. Da eine Anbindung an die anderen Prozesse durch den kombinierten Einsatz z. B. der Module Remedy Asset Management und Remedy
Change Management durch Remedy möglich ist, ist somit auch für die notwendige Kommunikation und Zusammenarbeit zwischen den Prozessen gesorgt.
Change Management. Remedy IT Service Management bietet für diesen
Bereich eine Unterstützung an. Für das Modul Remedy Change Management
wird genügend Information geboten, sodass es hier möglich ist, eine detailliertere
Vorgehensweise vorzunehmen. Im Folgenden sollen die genannten Forderungen
im Einzelnen durchgegangen werden:
Erfassung des RFCs, Kontrolle und Speicherung in der Datenbank:
Eine erste Anforderung war die ordnungsgemäße Erfassung der Tickets.
Hierfür bietet diese Software grundlegend die Möglichkeit jederzeit mit
anderen Abteilungen in Kontakt zu treten und gemeinsam über die Ziele,
die Gültigkeit sowie die Auswirkungen einer Änderung zu kommunizieren.
Remedy Change Management unterstützt die Arbeit dahingehend, dass
eine Klassifizierung hinsichtlich der Akzeptanz, der Erfassung sowie der
Speicherung vorgenommen wird. Das Ticket kann durch das ganze System
hindurch verfolgt werden und jederzeit aufgerufen und weiterbearbeitet
werden. Zudem bietet es einen Automatismus bzgl. des Genehmigungsverfahrens. Kunden, die durch diese Änderung betroffen sind, werden
benachrichtigt und können sich somit darauf einstellen.
Erstellung von Zeit-/Installationsplänen und deren Implementierung:
Im Rahmen der Implementierung muss bedacht werden, dass die Auswirkungen einer Änderung oftmals nicht vollständig vorhersehbar sind. Ein
Restrisiko bleibt stets vorhanden. Dieses gilt es jedoch zu minimieren. Aus
diesem Grund ist eine genannte Anforderung an das Werkzeug, dass ein
vorhandenes Backout-Verfahren vor der Implementierung zugrunde liegen
muss. Diese Möglichkeit bietet Remedy Change Management. Um jedoch
schon im Vorfeld das Risiko einer negativen Auswirkung gering zu halten,
kann mit Remedy dieses Szenario durchgespielt werden. Dadurch können
die Gefahren wie die eines Ausfalls oder sonstige Unannehmlichkeiten
minimiert werden.
Freigabe der Änderung, Evaluierung und Abschluss: Die Software bietet zudem Kontrollmöglichkeiten bezogen auf die Auswirkungen, die Kosten, die Ressourcen sowie die Risiken. Das Ergebnis kann wiederum als
Grundlage für weitere Änderungen verwendet werden. Remedy Change
135
Management bietet zudem nicht nur die Möglichkeit zur Ablaufplanung
und Aufgabenzuweisung, sondern stellt auch die Software für die anschließende Evaluierung zur Verfügung.
Release Management. Remedy hebt nicht explizit eine Umsetzung des Release Managements hervor.
Configuration Management. Das Configuration Management wird durch
das Remedy Asset Management unterstützt. Dies behandelt die Verwaltung der
Assets (IT-Anlagegüter).9 Als Ausgangspunkt für die Umsetzung des Configuration Managements verfügt Remedy über eine integrierte CMDB. Darin werden
alle CIs sowie deren Beziehungen gespeichert. Der Zugriff darauf ist prozessübergreifend möglich, um die Quellen verschiedener Probleme möglichst schnell
ausfindig zu machen. Des Weiteren besteht mit Remedy die Möglichkeit für verschiedene Personen oder Abteilungen Standardkonfigurationen zu definieren.
Im Rahmen der Funktion des Lifecycle Asset Management, welches im Remedy
Asset Management enthalten ist, können die CIs während ihrer gesamten Dauer
innerhalb des Unternehmens verfolgt und überwacht werden. So ist darin auch
eine Erstellung von Zeitplänen für die Wartung und Prüfungen möglich, um
einen Ausfall der Komponenten im Vorfeld zu verhindern. Durch diese Überwachung der einzelnen CIs ist es möglich, veraltete Soft- und Hardware zu erneuern
und damit Unstimmigkeiten zwischen der Datenbank und den tatsächlichen CIs
aufzufinden. Hierbei kann aus vorgegebenen Standardkonfigurationen gewählt
werden, damit die vorgegebenen Konfigurationen auch eingehalten werden. Nach
erfolgter Genehmigung wird die Bestellung durch das Programm automatisch
generiert.
Durch eine Verknüpfung mit den Modulen Remedy Help Desk und dem Remedy
Change Management, kann jederzeit der Bestand prozessübergreifend geprüft
und Bedarfsmeldungen an die anderen Prozesse geben werden. Um die Sicherheit und Vollständigkeit der Daten zu gewährleisten, enthält Remedy zusätzlich die Möglichkeit Autoritätsüberprüfungen oder Namensübereinstimmungen
durchzuführen.
Zusammenfassung. Für Remedy lässt sich festhalten, dass mehrere der von
ITIL genannten Prozesse im Service Support umsetzt werden. So umfasst der
Remedy Help Desk das Incident Management in Verbindung mit dem Service
Desk und das Problem Management.
Auch der Remedy Help Desk basiert auf einem Ticket-System, wodurch die aufgestellten Anforderungen nach einer organisierten Erfassung und Verarbeitung
der Daten umgesetzt werden. Durch das Modul Remedy Change Management
erfolgt eine Umsetzung des Change Managements. Die oben erarbeiteten Anforderungen für diesen Prozess werden dabei im Wesentlichen umgesetzt, als
Beispiel sei das in diesem Werkzeug vorhandene Backout-Verfahren erwähnt.
Auch die genannten Anforderungen an das Configuration Management werden
weitestgehend durch das Modul Remedy Asset Management umgesetzt. Auf eine Umsetzung des Release Managements wird nicht näher eingegangen, so dass
hier keine Überprüfung von Anforderungen möglich war.
9 Für
die Assets wurde bisher die Bezeichnung CIs verwendet
136
4.5
Fazit
Abschließend lässt sich sagen, dass es innerhalb von ITIL freigestellt ist, ob
unterstützende Werkzeuge verwendet werden sollen oder nicht. Die Grundsätze
von ITIL sind auch mit jeglichen Mitteln umsetzbar, im einfachsten Fall sogar
mit Papier und Bleistift. Dennoch kann der Einsatz eines Tools zur Effizienzsteigerung und damit auch zu Zeiteinsparungen führen. Damit stellte sich die
Frage, was ITIL-unterstützende Werkzeuge leisten sollten. Im Rahmen dieser
Arbeit war es das Ziel, Anforderungen an ein ITIL-unterstützendes Werkzeug
herauszuarbeiten.
Die Betrachtung von Anforderungen innerhalb der Prozesse im Service Support
hat aufgezeigt, dass verschiedene Punkte wiederholt auftreten. Diese lassen sich
folgendermaßen zusammenfassen:
• Möglichkeit zur strukturierten Erfassung von Daten
• Verwaltung der Daten innerhalb von entsprechenden Datenbanken
• Permanenter Informationszugriff für die Anwendergruppen
• Erleichterung der prozessübergreifenden Kommunikation und Information
Am Markt gibt es verschiedene Werkzeuge von denen OTRS und Remedy in
Kapitel 4.4 näher betrachtet wurden. Anhand dieser beiden ließ sich exemplarisch aufzeigen, dass die Programme einige Prozesse bereits umsetzen und somit
den aufgestellten Anforderungen teilweise genügen.
Die Werkzeuge können unterstützend wirken, der Erfolg ist aber natürlich zum
Großteil von der Fähigkeit des Menschen abhängig. So ist die Nutzung einer noch
so strukturierten Datenbank nur dann erfolgreich, wenn die Menschen sie auch
benutzen und bspw. die Aktualisierung der Datenbanken nicht vernachlässigen.
D. h. es ist ein Irrtum zu glauben, dass allein der Einsatz eines Tools bereits zu
einer erfolgreichen ITIL-Umsetzung führt. So gilt auch hier: „a fool with a tool
is still a fool“.
[Bre07]
Brenner, M.: Werkzeugunterstützung für ITIL-orientiertes
Dienstmanagement: Ein modellbasierter Ansatz, 1. Auflage,
Dissertation München 2007.
[Cla]
Clauss, C.: Beispielhafte Evaluierung der Anpassbarkeit von OTRS
an Prozesse im IT Service Management am LRZ,
Fortgeschrittenenpraktikum am Institut für Informatik.
Ludwig-Maximilians-Universität München. URL: http://www.
mnm-team.org/pub/Fopras/clau06/PDF-Version/clau06.pdf.
Datum der Abfrage: 18.12.07.
[Els06]
Elsässer, W.: ITIL Einführung und Umsetzen: Leitfaden für
effizientes IT-Management durch Prozessorientierung, 2. Auflage,
Hanser Verlag, 2006.
[Fis06]
Fischlin, R.: Leitfaden ITIL-Service Desk. Fraunhofer Institut für
Informations- und Datenverarbeitung. Network Operation Center
NOC. DFN Tagungsband 2006. Seite 95-104. URL:
http://edoc.hu-berlin.de/conferences/dfn2006/
fischlin-roger-105/PDF/fischlin.pdf. Datum der Abfrage:
18.12.07.
[Här07]
Härtl, M.: Konzeption und Unterstützung der technischen
Unterstützung eines zentralen IT-Service-Desk mit OTRS an der
TUM. Diplomarbeit am Institut für Informatik 26.07.07.
Ludwig-Maximilians-Universität München. URL:
http://www.mnm-team.org/pub/Diplomarbeiten/haer07/
PDF-Version/haer07.pdf. Datum der Abfrage:04.01.08.
[Its07]
itSMF-NL: Foundations in IT Service Management. Basierend auf
ITIL. Van Haren Publishing. Zaltbommel 2007.
[Mar04] Margulius, D.L.: Taking a page from ITIL’s best practices. URL:
http://www.infoworld.com/article/04/09/24/39FEitil_1.html.
Datum der Abfrage: 06.01.08.
[Nie07]
Niestermann, M.: Service Management-Lösungen für KMU.
ITIL-unterstützende Service Management Tools. Verlag Dr. Müller e.
K. und Lizenzgeber. Saarbrücken 2007.
137
138
[Otr08]
OTRS AG - Consulting, Software Development, Support und
Training rund um OTRS. URL: http://www.otrs.com/de. Datum
der Abfrage: 04.02.08.
[Pfl05]
Pfleger, B.: Evaluierung von Werkzeugen zur Unterstützung der ITIL
Service Management Prozesse. Diplomarbeit am Institut für
Informatik. Ludwig-Maximilians-Universität München. URL:
http://www.nm.ifi.lmu.de/pub/Diplomarbeiten/pfle05/
PDF-Version/pfle05.pdf. Datum der Abfrage: 03.01.08.
[Bmc08] BMC Software Inc. - Remedy Service Management is now on
BMC.com. URL: http://www.bmc.com/remedy/. Datum der
Abfrage: 26.02.08.

Betriebsinformatik-Projekt — ITIL und die IT-Wirklichkeit

Transcription

Documents pareils

ITIL – sozial verträglich!

ITIL Foundation V3 Seminarbeschreibung_EnTeCo

Definition Economies of scope

Prozessberatung und

ITIL in 60 Minuten

ITIL Foundation V3

20000Academy versus Umsetzung ohne Hilfe

ITIL Foundation Training

ITIL V3 Glossary

Kursunterlagen ITILv3 Foundations