Betriebsinformatik-Projekt ITIL und die IT- · PDF fileVorwort ITIL (IT Infrastructure Library) ist ein de facto-Standard für das IT Service Management. Er wurde gegen Ende der 1980er

Betriebsinformatik-Projekt—

ITIL und die IT-Wirklichkeit

Prof. Dr. Thorsten Spitta – Dipl.-Inform. Meik Teßmer

Universität BielefeldFakultät für Wirtschaftswissenschaften

Angewandte Informatik

Wintersemester 2007/2008

Vorwort

ITIL (IT Infrastructure Library) ist ein de facto-Standard für das IT ServiceManagement. Er wurde gegen Ende der 1980er Jahre in England entwickeltund hat sich seitdem ständig weiterentwickelt. ITIL definiert verschiedene Rol-len und Funktionen, die helfen sollen, die IT-Infrastruktur effizient einzusetzen,Dienstleistungen anzubieten und zu verbessern sowie eine hohe Service-Qualitätzu gewährleisten.Im Rahmen dieses BI-Projekts sollen die verschiedenen ITIL Service Management-Funktionen betrachtet werden sowie eine mögliche Anwendung des Standardsin 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 Kuhl-jürgen, Kathrin Stegmann, Julia-Vanessa Stork, Christian Teicher, ChristopherUhrig.

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 91.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Service Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2.1 Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . 121.2.2 Incident Management . . . . . . . . . . . . . . . . . . . . 161.2.3 Problem Management . . . . . . . . . . . . . . . . . . . . 221.2.4 Change Management . . . . . . . . . . . . . . . . . . . . . 271.2.5 Release Management . . . . . . . . . . . . . . . . . . . . . 301.2.6 Configuration Management . . . . . . . . . . . . . . . . . 32

1.3 Untersuchung des IT-Managements in der Universität Bielefeld . 371.3.1 Fakultät für Wirtschaftswissenschaften . . . . . . . . . . . 371.3.2 Fakultät für Rechtswissenschaft . . . . . . . . . . . . . . . 401.3.3 Kritik und Empfehlung . . . . . . . . . . . . . . . . . . . 42

1.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461.5 Fragebogen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2 ITIL-Zertifizierung nach ISO/IEC 20000 532.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.2 Der Standard ISO/IEC 20000 . . . . . . . . . . . . . . . . . . . . 54

2.2.1 Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . 542.2.2 Beziehung zu ITIL . . . . . . . . . . . . . . . . . . . . . . 542.2.3 Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.2.4 Anforderungen an ein Management-System . . . . . . . . 562.2.5 Planung und Implementierung des Service Managements . 572.2.6 Anforderungen an Service-Management-Prozesse . . . . . 58

2.3 Die Zertifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 632.3.1 Entscheidungsfindung . . . . . . . . . . . . . . . . . . . . 632.3.2 Prozessumsetzung . . . . . . . . . . . . . . . . . . . . . . 642.3.3 Fragenkatalog zur Prozessumsetzung . . . . . . . . . . . . 672.3.4 Zertifizierungsprozess . . . . . . . . . . . . . . . . . . . . 73

2.4 Beurteilung der Zertifizierung . . . . . . . . . . . . . . . . . . . . 742.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3 ITIL und IT-Sicherheit 813.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813.2 Grundlagen des IT-Security Management . . . . . . . . . . . . . 82

3.2.1 Informationssicherheit . . . . . . . . . . . . . . . . . . . . 823.2.2 Gesetzesanforderungen, Vorschriften und Standards . . . 84

5

6 INHALTSVERZEICHNIS

3.2.3 Ziele und Aufgaben des IT-Security Management . . . . . 853.2.4 Einordnung von Informationssicherheit und Security Ma-

nagement in ITIL . . . . . . . . . . . . . . . . . . . . . . . 883.3 Security Management mit ITIL auf operativer Ebene . . . . . . . 90

3.3.1 Service Desk . . . . . . . . . . . . . . . . . . . . . . . . . 903.3.2 Incident Management . . . . . . . . . . . . . . . . . . . . 913.3.3 Problem Management . . . . . . . . . . . . . . . . . . . . 943.3.4 Change Management . . . . . . . . . . . . . . . . . . . . . 963.3.5 Release Management . . . . . . . . . . . . . . . . . . . . . 993.3.6 Configuration Management . . . . . . . . . . . . . . . . . 101

3.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

4 ITIL-unterstützende Werkzeuge 1094.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1094.2 Begriffsabgrenzungen . . . . . . . . . . . . . . . . . . . . . . . . . 110

4.2.1 ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1104.2.2 Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . 111

4.3 Service Support und Anforderungen an die Werkzeuge . . . . . . 1124.3.1 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . 1124.3.2 Incident Management mit Service Desk . . . . . . . . . . 1124.3.3 Problem Management . . . . . . . . . . . . . . . . . . . . 1164.3.4 Change Management . . . . . . . . . . . . . . . . . . . . . 1204.3.5 Release Management . . . . . . . . . . . . . . . . . . . . . 1234.3.6 Configuration Management . . . . . . . . . . . . . . . . . 125

4.4 Betrachtung ausgewählter ITIL-Werkzeuge . . . . . . . . . . . . 1274.4.1 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . 1274.4.2 Das Open Source-Werkzeug OTRS . . . . . . . . . . . . . 1274.4.3 Das kommerzielle Werkzeug Remedy . . . . . . . . . . . . 132

4.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Gruppen

Thema TeilnehmerGruppe 1: Service Support-Umsetzung an zwei ausgewähl-ten Fakultäten

Carolin Ahlert, Julius Kuhljür-gen, Christian Teicher

Gruppe 2: ITIL-Zertifizierungnach ISO 20000

Julia-Vanessa Stork, André Krö-ger, Christopher Uhrig

Gruppe 3: Security-Managementmit ITIL

Björn Borgmeier, Michael Bo-chenek, Tim Kattner

Gruppe 4: Werkzeuge für ITIL Linda Gerstenberger, Sonja Bo-zionek, Kathrin Stegmann

7

8 INHALTSVERZEICHNIS

Kapitel 1

ITIL-Wirklichkeit an derUniversität BielefeldService Support-Umsetzung an zwei ausgewähl-ten Fakultäten

Carolin Ahlert, Julius Kuhljürgen, Christian Teicher

1.1 Einleitung

Nahezu jedes Unternehmen, sei es in der Dienstleistungsbranche oder in derProduktion tätig, sei es ein Krankenhaus oder eine Universität, ist mit demtäglichen Gebrauch der IT konfrontiert. Es ist nicht weiter verwunderlich, dassSätze wie „Mein Computer stürzt dauernd ab.“, „Ich habe keinen Zugriff aufdie Datenbank.“ oder „Mein alter Computer kann mit seiner noch älteren Soft-ware 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öglichstreibungsloser Betriebsablauf gewährleistet werden? Dafür liefert ITIL eine mög-liche Lösung. Mit Hilfe von Funktionen und Prozessen, die sich in der Praxisbereits bewährt haben, soll nun die Vielzahl der verschiedenen Probleme an-gegangen werden. Allerdings stellt sich die Frage: Wo fängt die Problemlösungan und wo hört sie auf? Oder allgemeiner: Wie kann der Kunde resp. der Useram besten unterstützt werden? Laut der ITIL-Philosophie ist dafür der ServiceSupport zuständig. Wie dieser Service Support den User auf operativer Ebeneunterstützen kann, soll in dieser Arbeit detailliert dargestellt werden. Auf Grundder Behauptung, dass die Anwendung von ITIL für jedes Unternehmen von Vor-teil sei, kann daraus gefolgert werden, dass dieser de facto-Standard auch füreine Universität vorteilhaft sein muss. Um dieser These nachzugehen, wird inder vorliegenden Arbeit die Universität Bielefeld resp. zwei ihrer größten Fakul-täten als Untersuchungsgegenstand im Bezug auf ITIL gewählt. Es drängt sichallerdings die Frage auf, ob der von ITIL vorgeschlagene Service Support wirk-lich 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 Pro-fessoren, den Sekretärinnen und allen, die mit der Organisation der Universitätbeschäftigt sind, wirklich geholfen werden? Werden die IT-Probleme der stu-dentischen Hilfskräfte besser gelöst und die Anfragen der Professoren für neueComputer schneller bearbeitet? Wenn diese Fragen mit „ja“ beantwortet werdenkönnen, dann sollte der Service Support sofort in der Universität implementiertwerden. Zudem sollten sich in der Universität Bielefeld bereits Grundzüge derITIL vorfinden lassen, da diese auf dem Best Practice-Konzept beruhen und je-des Unternehmen, auch die Universität Bielefeld, an einer möglichst effizientenIT-Lösung schon lange vor der Einführung von ITIL interessiert sein sollte.Ziel dieser Arbeit ist es, diesen Fragen bzw. Behauptungen nachzugehen unddas Konzept der ITIL im serviceorientierten IT-Management in der Realitätkritisch zu hinterfragen. Aus diesem Grund sollen zunächst die Anforderungenvon ITIL im Bereich des Service Supports in Kapitel 1.2 vorgestellt werden. Dieausführliche Darstellung dieses Kapitels hat mehrere Gründe. Zum einen soll da-durch gewährleistet werden, dass der Leser einen umfangreichen Überblick überdie einzelnen Anforderungen an einen ITIL-konformen Service Support erhält,zum anderen soll die Komplexität und die damit verbundene Schwierigkeit derImplementierung von ITIL verdeutlicht werden. Anschließend wird die möglicheAnwendung des von ITIL vorgeschlagenen Standards anhand zweier ausgewähl-ten Fakultäten der Universität Bielefeld kritisch evaluiert. Dabei wird zunächstauf die jetzige Situation des Service Supports der jeweiligen Fakultät verwiesen.Dieser IST-Zustand wurde anhand von Interviews mit den zuständigen EDV-Mitarbeitern der Fakultäten festgestellt und wird in Kapitel 1.3 behandelt. Einedaran anschließende Kritik im Bezug auf den IST-Zustand des IT-Services derjeweiligen Fakultäten soll ebenfalls in diesem Kapitel ausgeübt werden. DesWeiteren werden diverse Empfehlungen, die auf den von ITIL vorgeschlagenenService Support basieren, Gegenstand dieses Abschnitts sein. Das Fazit dieserArbeit wird anschließend Thema des Abschnitts 1.4 sein. Hier sollen die letz-ten noch offen gebliebenen Fragen im Bezug auf die ITIL-Wirklichkeit an derUniversität Bielefeld bzw. die Service Support-Umsetzung an zwei ausgewähltenFakultäten geklärt werden. Um ein besseres Verständnis für den Service Supportvon ITIL zu bekommen, sollen nun in dem folgenden Kapitel die theoretischenGrundlagen des Service Supports im Hinblick auf seine Funktionen und Prozessevorgestellt werden.

1.2 Service SupportFür die bereits oben beschriebenen Störungsfällen soll nun der Service Supportnach ITIL als Unterstützung im Bereich des operativen IT-Services fungierenund dem Kunden1 bei der Lösung seiner Probleme behilflich sein. Allerdingsgestaltet sich der Aufgabenbereich des Service Supports wesentlich komplexer,da der Service Support nicht nur die Probleme der Endanwender lösen soll, son-dern auch einen reibungslosen Betriebsablauf im Bereich der IT gewährleistensoll.Nach der ITIL-Philosophie lässt sich der Service Support im wesentlichen infünf Geschäftsprozesse und eine unterstützende Funktion untergliedern:

1Es ist hier sowohl der unternehmensexterne als auch der unternehmensinterne Kunde(Endanwender bzw. User) gemeint.

Service Support-Umsetzung an zwei ausgewählten Fakultäten 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 sichmit diesem Vorfall, auch Incident2 genannt, an eine zentrale Kontaktstelle, densogenannten Service Desk, wenden. Dieser soll also dem Kunden als zentrale An-laufstelle für Probleme und Wünsche bzw. Anregungen, die laut ITIL auch alsRequest 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 wirdauch die enge Verknüpfung des Service Desks mit dem Incident Managementdeutlich. Denn sollte die primäre Hilfe des Service Desks nichts bewirken, so wirdder Prozess des Incident Managements in Gang gebracht. Das Incident Mana-gement hat zur Aufgabe, möglichst schnell auf etwaige Incidents zu reagierenund diese zu beheben, um einen reibungslosen Betriebsablauf zu gewährleis-ten. Beim sogenannten Problem Management wiederum geht es vielmehr umdie Ursachenforschung. Wenn die Ursache einer Störung noch nicht bekannt ist,dann liegt laut ITIL ein Problem vor, welches vom Problem Management zu do-kumentieren, je nach Schweregrad zu klassifizieren und zu untersuchen ist. Istdie Ursache bzw. der Grund für eine Störung gefunden, geht von dem ProblemManagement ein Request for Change an das Change Management, um solcheStörungen zu vermeiden. Das Change Management klassifiziert die erhaltendenRfCs und ordnet sie nach ihrer Wichtigkeit. Anschließend wird hier entschieden,welche Änderungen zu welchem Zeitpunkt durchgeführt werden sollen. Hier er-folgt ebenfalls eine Dokumentation der Entscheidungen. Die Kontrolle über alleÄnderungen und die Entwicklung bzw. Einführung von standardisierten Ände-rungsverfahren zählen zu den wichtigsten Aufgaben des Change Managements.Im Release Management werden dann sämtliche bewilligte Änderungen bezüg-lich der Hardware- und Softwarekomponenten der IT gebündelt und zu neu-en Releases zusammengefasst. Dabei wird die Durchführung der Änderungengeplant, getestet, kontrolliert und selbstverständlich auch dokumentiert. DasRelease Management hat somit nach der ITIL-Philosophie die Systemordnungdes Betriebs sicherzustellen. Das Configuration Management ist für die Pfle-ge der zentralen Informationsquelle sämtlicher Prozesse des Service Supportszuständig. Alle Informationen, wie zum Beispiel die bereits erwähnte Dokumen-tation in den Prozessen, die vorhandene Hardware im Betrieb, die Verbindun-gen zwischen Datenbanken oder die Lizenzen der Betriebssoftware, werden ineiner sogenannten Konfigurationsdatenbank gespeichert, für die das Configura-tion Management zuständig ist.Abbildung 1.1 stellt den Aufbau des Service Supports dar.

2engl. Incident = Vorfall, Störung3Änderungsanforderung an eine Systemkomponente


ServIce

Desk

Incident

RfC

Incident Management

Problem Management

RfC

Change Management Release Management

ConfigurationManagement

IT OperationsIncident

Incident / Request for Change

Informationsfluss

Abbildung 1.1: Service Support.

Aus Abbildung 1.1 wird ersichtlich, stellt jeder Prozess eine in sich geschlos-sene Einheit dar, allerdings existieren Schnittstellen, die eine Kommunikationzwischen den verschiedenen Prozesse ermöglichen.Des Weiteren ist noch anzumerken, dass ITIL oft den Begriff Rolle innerhalbder Prozesse verwendet. So sind zum Beispiel die Aufgaben des Incident Mana-gements in der Rolle des Incident Managers zu beschreiben. Grund dafür ist,dass die ITIL-Prozesse unabhängig von der Organisationsstruktur des Betriebssein sollten, da somit eine höhere Flexibilität bei der Einführung bzw. der Um-setzung von ITIL gewährleistet werden kann. So kann beispielsweise in kleinerenBetrieben eine Person sowohl Incident Manager als auch Configuration Mana-ger sein, ohne die von ITIL vorgeschlagene Aufteilung des Service Supports zuverletzen.Nachdem die Zusammenhänge bzw. der Aufbau der operativen Ebene des ser-viceorientierten IT-Managements, d.h. des Service Supports, kurz dargestelltwurden, sollen nun in den folgenden Abschnitten die einzelnen Prozesse, al-so Incident Management, Problem Management, Configuration Management,Change Management und Release Management, und die Funktion Service Deskdetailliert beschrieben werden.

1.2.1 Service Desk

Wie bereits in dem vorangegangenen Abschnitt gesagt, existieren eine Reihevon verschiedenster Vorfälle, die in einem laufenden Betrieb im Bereich der ITzum Alltag gehören. Fragen, Beschwerden, Probleme aller Art, sie werden vonITIL als Incident bezeichnet, müssen möglichst schnell erfasst, bearbeitet undgelöst werden, um eine Störung des laufenden Betriebs zu vermeiden. In diesem


Zusammenhang kommt der sogenannte Service Desk4 ins Spiel.Der Service Desk soll laut ITIL als zentraler Anlaufpunkt für sämtliche In-cidents dienen und das Kommunikationsinstrument zwischen Service Supportund Endanwender sein. Aus diesem Grund wird der Service Desk als eine Funk-tion und nicht als Prozess des Service Supports verstanden, da er mehr oderweniger 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 Mana-gement deutlich. Der Service Desk übernimmt teilweise die Aufgaben des Inci-dent Managements, da versucht werden soll, die Fragen oder Störungen bereitshier zu klären und zu beseitigen, bevor sich das Incident Management mit ihnenbeschäftigt. Es besteht daher durchaus die Möglichkeit, dass ein Incident Ma-nager auch Mitarbeiter des Service Desk ist et vice versa. Das Ziel des ServiceDesks sollte somit eine hohe Erstlösungsrate sein. „Ziel des Service Desks ist es,möglichst viele Anfragen bereits bei Erstkontaktaufnahme durch den Anwendervollständig zu beantworten und abzuschließen.“ [Vic05, S. 34]Auf Grund der Tatsache, dass der Service Desk die einzige Kommunikationsstel-le zwischen Support und Kunden ist, wird er auch als Single Point of Contact,kurz SPOC, bezeichnet. Warum der Service Desk der einzige Kommunikations-kanal zwischen Support und Kunden ist, lässt sich am einfachsten anhand einesBeispiels verdeutlichen.Angenommen, ein Mitarbeiter hat Probleme mit seiner Netzwerkkarte. Da erjemanden vom Service Support kennt, umgeht er den Service Desk und bittetseinen Bekannten direkt um Hilfe. Dieser kümmert sich sofort um die Netzwerk-karte. Die Problematik ist allerdings dabei, dass, da mehrere Netzwerkkartenstreiken, der Vorfall und der passende Lösungsweg bereits im Service Desk be-kannt sind. Dadurch entsteht ein unnötiger Mehraufwand, der hätte vermiedenwerden können. Ebenso hätten weitaus schlimmerere Konsequenzen eintretenkönnen, wenn das gesamte Netzwerk ausgefallen wäre und der Mitarbeiter desService Supports sich lediglich um diese eine Netzwerkkarte kümmern würde.Somit zeigt sich, dass der Service Desk als einziger Kommunikationsweg wesent-liche Vorteile besitzt. „Schwerwiegende Störungen oder sogenannte Massenstö-rungen könnten nicht mit der ihnen zustehenden notwendigen Priorität behan-delt und die Ausweitung auf weitere Anwender könnte nicht verhindert werden.Die gleichmäßige Arbeitsbelastung der unterstützenden Spezialisten wäre nichtmehr steuerbar und eine zügige Abarbeitung von Incidents oder Problemen mithoher Priorität wäre gefährdet.“ [Vic05, S. 33] Die wichtigsten Aufgaben desService Desk sind demnach:

• einheitliche zentrale Kommunikationsschnittstelle (SPOC) zwischen Usernund Support in Verbindung mit Ausgabe von Informationen, zum Beispieldes aktuellen Status von Vorgängen, geplanten Änderungen, usw.,

• Aufnahme, Dokumentation und Auswertung von Vorfällen,

• Bearbeitung von Problemen mit „Erste Hilfe“ -Charakter, auch First LevelSupport genannt,

4Service 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 dieDienstleistung, die aktive Unterstützung des Mitarbeiters, die hinter dieser Funktion steckt,zu betonen.


• Einschätzung von Vorfällen und damit verbundene Weiterleitung der In-cidents zu den Supportstellen Incident Management und Problem Mana-gement (Second und Third Level Support).

Aus den Aufgaben des Service Desks wird ersichtlich, dass die Anforderungen anden Mitarbeiter des Service Desks sehr umfangreich sind. Dieser muss bei einemhohen Kommunikationsaufkommen, begründet durch die SPOC-Eigenschaft desService Desks, nicht nur eine gewisse Kenntnis von der Materie, sondern viel-mehr auch eine gute fachliche Kompetenz vorweisen können. Des Weiteren emp-fiehlt es sich, dass der Mitarbeiter rhetorische und soziale Fähigkeiten besitzt,um einen geeigneten Umgang mit ungeduldigen bzw. unzufriedenen Kunden zufinden.5

Nachdem wir uns mit den Aufgaben, Eigenschaften und Zielen des Service Desksbeschäftigt haben, wollen wir uns nun dem Service Desk hinsichtlich seinerStruktur bzw. seiner Organisation widmen. Im nun folgenden Abschnitt sollennun kurz drei verschiedene Architekturmodelle zur Implementierung des ServiceDesks vorgestellt werden.

Lokaler Service Desk. Zum einen besteht die Möglichkeit eines lokalen Ser-vice Desk. Hierbei handelt es sich um eine dezentrale Struktur. Beispielsweisekö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 Fa-kultät verfügt, haben. Die Vorteile wären eine hohe Intensität im Bereich derKundenbetreuung und eine verkürzte Reaktionszeit auf sämtliche Incidents derFakultät. Die Voraussetzung für die Einführung eines lokalen Service Desks istallerdings die Bereitstellung eine großen Menge an Ressourcen6. Dies findet sei-ne Begründung darin, dass jeder lokale Service Desk auch für die Bereitstellungeines lokalen Service Supports sorgen muss. Außerdem kann sich eine Einfüh-rung eines lokalen Service Supports in Bezug auf die Zusammenarbeit von Un-ternehmensbereichen, in unserem Beispiel bezüglich der Zusammenarbeit vonFakultäten, als problematisch erweisen. Es besteht die Möglichkeit, dass jederUnternehmensbereich oder jede Fakultät anders mit Incidents verfährt und da-her andere Systeme oder Prozesse zur Behandlung von Incidents benutzt. Einemögliche Zusammenarbeit von Fakultäten wäre somit gefährdet.Abbildung 1.2 soll den Grundgedanken des lokalen Service Desks nochmals ver-deutlichen. Sie zeigt auch eine weitere Möglichkeit, den Service Desk zu struk-turieren.

Zentraler Service Desk. Der zentrale Service Desk ist die einzige Anlauf-stelle für alle Unternehmensbereiche. Die Problematik der Zusammenarbeit derUnternehmensbereiche, wie sie beim lokalen Service Desk auftrat, ist hier nichtgegeben, da nicht nur ein System zur Bewältigung von Incidents existiert, son-dern auch sämtliche Prozesse vereinheitlicht werden. Bei einem zentralen ServiceDesk ist zwar der Kommunikations- bzw. Informationsfluss wesentlich größer alsder bei einem lokalen Service Desk, der Informationsgewinn steigt aber eben-falls. Mit steigendem Informationsgewinn kann die Verteilung der Ressourcenoptimiert werden und somit können Kosten gesenkt werden.

5Auch in diesem Dienstleistungssegment gilt: Der Kunde ist König.6In besondere Weise monetäre Ressourcen


ServIce

Desk

1stLevel

Support

Service Support„User“

„Funktion“ „Prozesse“

A



B

Zentraler

ServIce

Desk

1stLevel

Support

Service Support

„User“


A

„User“

B

Lokaler Service Desk Zentraler Service Desk

ServIce

Desk

1stLevel

Support

Abbildung 1.2: Lokaler und zentraler Service Desk.

Durch ein Beispiel soll dieser Vorteil verdeutlicht werden. Angenommen, es liegtein Request for Change vor. Ein Mitarbeiter benötigt einen neuen Computer.Die verschiedenen lokalen Service Desks haben folglich die Aufgabe, sich um die-sen RfC zu kümmern und an die passende lokale Supportstelle weiterzuleiten.Diese wird das ihrer Meinung nach beste Angebot einholen und den Compu-ter bestellen. Durch einen zentralen Service Desk bzw. einen zentralen ServiceSupport besteht nun aber die Wahrscheinlichkeit, ein noch besseres Angeboteinzuholen, da die Mitarbeiter des Service Supports sich über Angebote undPreise austauschen können. Man kann demnach einen Nutzen aus dem somitgewonnenen Informationsgewinn ziehen.Ein anderes Beispiel wäre die Behandlung von Incidents. Während sich bei demlokalen Service Desk jeweils ein Mitarbeiter mit ein und demselben Incidentbeschäftigen würden, könnte man bei einem zentralen Service Desk einen Mit-arbeiter mit der Behandlung des Incidents beauftragen, während der andere Mit-arbeiter bereits einen neuen Incident entgegennimmt, auch hier könnten Kostengespart werden.Allerdings können bei einer Einführung eines zentralen Service Desks auch Pro-bleme entstehen. Je größer ein Kundenstamm wird, desto schwieriger wird sichdie kundennahe Betreuung erweisen. Somit nimmt selbstverständlich auch derOrgansisationsbedarf bzw. -aufwand erheblich zu.

Virtueller Service Desk. Die dritte Service Desk-Struktur versucht die Vor-teile der bereits vorgestellten Strukturen zu kombinieren. Abbildung 1.3 zeigtden sogenannten virtuellen Service Desk. Der virtuelle Service Desk sieht zwar


ServIce

Desk

1stLevel

Support


„Funktion“

„Prozesse“

B

ServIce

Desk

1stLevel

Support

„User“

„Funktion“

A

Abbildung 1.3: Virtueller Service Desk.

lokale Annahmestellen und lokale Support Teams7 vor, aber auch eine zentraleDatenbank. Somit sind die Vorteile des lokalen Service Supports, nämlich einekundennahe Betreuung und eine verkürzte Reaktionszeit auf Incidents, ebenfallsbei dem virtuellen Service Desk vorzufinden, wie auch der erhöhte Informati-onsgewinn des zentralen Service Desks. Demgegenüber steht aber ein entschei-dender Nachteil. Der Aufwand, den virtuellen Service Desk zu organisieren, isterheblich und dementsprechend teuer.Wir haben nun gesehen, wie der Service Desk als eine Funktionseinheit auf deroperativen Ebene des serviceorientierten IT-Managements wirkt. Des Weiterenwurden Aufgaben, Ziele und Organisationsstrukturen des Service Desks vor-gestellt. Warum aber der Service Desk und das Incident Management so engmiteinander verknüpft sind und wie die Incidents im einzelnen behandelt wer-den, soll nun im folgendem Kapitel betrachtet werden.

1.2.2 Incident Management

Bevor man sich mit den Aufgaben, den Zielen und dem Prozess des IncidentManagements beschäftigt, müssen vorab zwei Sachverhalte erklärt werden. Zumeinen muss definiert werden, was genau ein Incident ist, und zum anderen muss

7Diese sollen vom virtuellen Service Support gesteuert und verwaltet werden


gekläre werden, wie der Zusammenhang zwischen Incident Management undService Desk aussieht.Laut dem Office of Government Commerce [OGC07, S. 46] ist ein Incidentdefiniert als:

An unplanned interruption to an IT service or reduction in thequality of an IT Service. Failure of a configuration item that has notyet impacted service is also an incident, for example failure of onedisk from a mirror set.

Ein Incident kann also als ein Ereignis verstanden werden, das zu einer Unterbre-chung oder zu einer Abnahme der Qualität des IT-Services8 führt. Es existierteine Vielzahl von Incidents, diese lassen sich zum Beispiel in Abhängigkeit ihresUrsprungs 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 Verlust-Wertes einer Firma errechnet den falschen Wert,

– der Zugriff auf eine Software wird verweigert, obwohl man selbst Ad-ministrator 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 Inci-dent Managements darstellt, entgegengenommen und bearbeitet. „Der ServiceDesk übernimmt als Funktion innerhalb des Incident Managements weitge-hend die operative Steuerung und Dokumentation der Aktivitäten der Incident-Bearbeitung.“ [Olb06, S. 28] Gegenstand dieses Kapitels ist aber vorrangig, dieZiele, die Aufgaben und insbesondere den Prozess des Incident Managementsdarzustellen.Die wichtigsten Ziele des Incident Managements sind, bei Eintritt eines Stö-rungsfalles die schnellstmögliche Wiederherstellung des normalen Betriebs zugewährleisten, mögliche Einflüsse durch Störungen auf den Betrieb zu minimie-ren und das vertraglich vereinbarte Service Level Agreements (SLA)10 halten zu

8Unter dem Begriff „Abnahme der Qualität des IT Services“ wird hier die Unterschreitungder voher vereinbarten Service-Grenzen verstanden.

9Wie bereits im vorherigen Kapitel ausführlich beschrieben.10Vereinbarungen, die mit dem User oder Kunden über die Höhe der Service-Dienstleistung

getroffen wurden.


können. Laut ITIL gilt, dass jeder Incident, der im Service Desk aufgenommenwird, einen entsprechenden Prozess im Incident Management auslöst. Dabei istanzumerken, dass die einzelnen Schritte des Prozesses zugleich die Aufgabendes Incident Managements bei Eintritt eines Incidents darstellen. Wie genaudieser Prozess nach der ITIL-Empfehlung aussehen sollte, wird nun anhand derAbbildung 1.4 dargestellt und erläutert.

Service RequestVerfahren

Incident aufnehmen und dokumentieren

Klassifizierung underste Unterstützung

Service Request?

Untersuchung und Diagnose

Monitoring, C

ontrol & C

omm

unication

Lösung,Wiederherstellung

Service

Incident Closure

ja

nein

Service Request?

nein

jaProblem?

Weiterleitungan den Support

Abbildung 1.4: Flussdiagramm Incident.

Incident aufnehmen und dokumentieren. Im ersten Schritt wird der In-cident aufgenommen, das heißt alle wichtigen Informationen bezüglich des Inci-dents, 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 Ab-teilung er arbeitet, usw.

werden hier erfasst und unter einer gemeinsamen Referenznummer in einer Da-tenbank, der sogenannten Configuration Management Data Base (CMBD)11

abgespeichert bzw. dokumentiert.11Diese Datenbank wird noch ausführlich in dem Abschnitt 1.2.6. beschrieben.


Da diese Aufgabe vom Service Desk ausgeführt wird, wird an dieser Stelle noch-mal die enge Verknüpfung des Incident Managements als Prozess mit dem Ser-vice Desk als operative Funktion des Incident Managements deutlich. Die Erfas-sung des Incidents ist äußerst wichtig, da die nachfolgenden Support-Gruppenebenfalls 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), theywill have all relevant information to hand to assist them.“ [OGC07, S. 49]

Klassifizierung und erste Unterstützung. Nachdem nun der Incident auf-genommen und dokumentiert wurde, gilt es nun zwei Fragen zu beantworten.Es muss geklärt werden, welcher sogenannten „Klasse“ der Incident angehörtund ob die Möglichkeit besteht, den Incident bereits im Service Desk, von daherim Incident Management-Prozess, zu lösen.Wie bereit zu Anfang dieses Kapitels beschrieben, lassen sich Incidents ihrerQuelle nach kategorisieren. Es wurde zwischen Störungen im Software- undHardwarebereich und Anfragen unterschieden. Die Klassifizierung von Incidentsbeinhaltet aber nicht nur die Kategorisierung, sondern auch die sogenannte Prio-risierung, 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, zumBeispiel wie viele User von diesem Incident betroffen sind, zusammen12. Darausfolgt:

Priorität = Dringlichkeit + Auswirkung

Wie sich die Priorität im einzelnen dann bestimmen lässt, kann laut ITIL übersogenannte Bewertungsmatrizen erfolgen, in denen zum Beispiel die Anzahl derbetroffenen User und die Auswirkung des Incidents gegeneinander abgetragenwerden. 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 bereitsim Service Desk und somit am Anfang des Incident Managements zu beantwor-ten sein13. Bezieht sich die Anfrage auf eine Änderung im IT-Bereich, so sprichtman von einem Request for Change (RfC), dieser Änderungsantrag wird geson-dert in einem Service Request-Verfahren behandelt, das aber in Abschnitt 1.2.4.

12Es existieren aber auch andere Definitionen von Dringlichkeit und Auswirkungen. So siehtdie Dringlichkeit, wenn der „Chef“ einen neuen Computer will, anders aus, als wenn derPraktikant einen neuen benötigt

13Ein guter Service Desk zeichnet sich unter anderem dadurch aus, dass er die meisteneinfachen Fragen der IT-User bereits im Vorfeld klären kann.


separat behandelt wird. Liegt allerdings eine Störung vor, so wird erstmal un-abhängig davon, ob die Ursache bekannt oder unbekannt ist, der Prozess desIncident Managements fortgesetzt.Wichtig sei hier noch zu erwähnen, dass sowohl die Klassifizierung als auch dieerste Unterstützung durch den Service Support dokumentiert und in der CMBDabgespeichert wird.

Untersuchung und Diagnose. Da die Anfragen als Incident bereits in denvorangegangenen Schritten des Incident Management-Prozesses bearbeitet wur-den, werden ab hier nur noch Störungen des laufenden Betriebs behandelt. Dabeiwird zwischen zwei Arten von Störungen unterschieden.Die Störungen, die als Ursache einen bereits bekannten Fehler haben, werdenals Known Error bezeichnet, die Störungen, deren Ursache unbekannt ist14, alsUnknown Error bzw. Problem. Nun gilt es den Incident hinsichtlich seiner Art zuuntersuchen, um anschließend eine Diagnose erstellen zu können, ob der Incidentdurch das Incident Management selbst oder durch die anderen Support-Stellenbehoben werden kann.Stellt sich heraus, dass es sich um einen Known Error handelt, so existiertbereits eine Lösung für diesen Fehler. Dies kann eine einfache Handlungsan-weisung, 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 sichsämtliche durch das Problem Management erarbeitete Lösungen für die ver-schiedensten Incidents befindet15. Das Incident Management hat zu jeder ZeitZugriff auf diese Datenbank und die sich darauf befindlichen Lösungen. Hierkann das Incident Management durch seinen First Level Support bereits helfenund aktive Unterstützung durch Bereitstellung der Lösung leisten.Wird der First Level Support an seine Grenzen gebracht, ein Incident wird daherals Problem diagnostiziert, wird dieses Problem dann an das Problem Mana-gement weitergeleitet. Dieser Vorgang wird bei ITIL als funktionale Eskalationbezeichnet. Der Incident wird somit an eine Gruppe von Spezialisten weiter-gegeben. Diese Spezialisten werden als Second Level Support bezeichnet undverfügen im Gegensatz zum First Level Support über ein größeres Fachwissenund eine bessere Ausstattung, um Incidents zu behandeln. Diese Weiterleitungan eine Gruppe von Spezialisten kann theoretisch n-mal geschehen, also bis zueinem n-ten Level Support fortgesetzt werden.In Anlehnung an [Olb06] soll Abbildung 1.5 die funktionale Eskalation verdeut-lichen.Bei ITIL wird aber lediglich von einem Third Level Support gesprochen, derbereits aus den Herstellern der fehlerhaften Software bzw. Hardware besteht.Das Problem Management stellt hier somit in diesem Prozess den Second LevelSupport dar.An dieser Stelle wird auch nochmals das Ziel des Incident Managements unddamit der Unterschied zum Problem Management mehr als deutlich. Währenddas Incident Management versucht, Fehler und die damit verbundenen Störun-gen zu vermeiden, geht das Problem Management den Fehler auf den Grund.Falls ein Incident „unbekannter Natur“ ist, es sich von daher um ein Problem

14Es kann auch mehrere Ursachen für ein Problem geben15Dies soll aber erst im folgenden Abschnitt genauer erläutert werden.



Lösung,Wiederherstellung

Service

nein

jaProblem?

1st Level Support


ja

neinLösung?

2nd Level Support


ja

neinLösung?

3rd Level Support


ja

Lösung?

n-ter Level Support

Abbildung 1.5: Ablauf der funktionalen Eskalation.

handelt, oder ein Incident immer wiederkehrt, so ist das Problem Managementdavon in Kenntnis zu setzen und der Incident zu übergeben.

Lösung, Wiederherstellung des Services. Nachdem alle Informationenbezüglich des Incidents zusammengetragen und untersucht wurden, kann nunein möglicher Lösungsweg ausgewählt und getestet werden. Für die Wiederher-stellung des standardisierten Betriebs kommen hier folgende Möglichkeiten inFrage:

• Der Workaround, der lediglich eine Umgehungslösung darstellt. Die Ur-sache des Incidents wurde nicht untersucht. An dieser Wiederherstellungdes Betriebs wird daher nochmal die Aufgabe des Incident Managements,nicht die Ursachen des Incidents zu untersuchen, sondern lediglich denlaufenden 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 seinaltes Passwort vergessen hat.

• Die Lösung, die vom nachfolgenden Problem Management bzw. ServiceSupport erarbeitet wurde, bereitstellen. Das heißt, ein Unknown Errorwird zum Known Error und es kann durch das Incident Management dar-auf zugegriffen werden.

• Auf einen Request for Change, der zuvor an das Change Management wei-tergeleitet und von diesem bearbeitet wurde, antworten. In dieser Antwortkann dann enthalten sein, dass der Auftrag ausgeführt, aber auch, dass erabgelehnt wurde.


Es sei hier noch erwähnt, dass für die Ausführung der gerade dargestellten Mög-lichkeiten sowohl der Service Desk selbst als auch extra dafür eingerichtete Ser-vice Support Teams, sozusagen die IT Operater, in Frage kommen.

Incident Closure. Nachdem die Anfrage beantwortet oder die Störung besei-tigt und somit der User zufrieden gestellt wurde, kann der Incident im IncidentClosure „formell“ abgeschlossen werden. Doch damit ist der Prozess noch nichtganz beendet. Wichtig ist nämlich hierbei das sämtliche Informationen bezüg-lich des Verlaufs der Incident-Behandlung im Incident Record abgespeichertwerden. Dies betrifft im besonderem Maße die Lösung des Incidents, da somitgewährleistet werden kann, dass bereits der Service Desk bei Eintritt desselbenIncidents auf die passenden Incident-Details zurückgreifen und entsprechendeMaßnahmen ergreifen kann, ohne das aufwendige Analysen durchgeführt wer-den müssen.

Monitoring, Control & Communication. Wichtige und dauerhafte Be-gleiter aller Subprozesse des Incident Managements sind Monitoring, Kontrolleund Kommunikation. Unter dem Begriff Monitoring wird hier die Erfassung,Beobachtung und Überwachung des Incident Managements verstanden. So be-steht zum Beispiel zu keiner Zeit die Möglichkeit zur Stagnation der Behandlungeines Incidents, was natürlich ganz klar von Vorteil ist. Ein weiterer wichtigerBegleiter des Incident Managements ist die Kontrolle des Incidents. Dies lässtsich am einfachsten anhand eines Beispiels verdeutlichen.Angenommen, ein Incident würde sich zu lange im Subprozess „Klassifikationund erste Unterstützung“ befinden, da er als zu unwichtig eingestuft wird. Nacheiner 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 befindetund überhaupt befinden darf.Der letzte wichtige Aspekt ist die Kommunikation. Hier ist sowohl die Kommu-nikation zwischen Incident Management und User als auch die Kommunikationdes Incident Managements und dem Service Support gemeint. So kann zum Bei-spiel ein User immer über den Prozess informiert werden und ist somit immer„auf dem Laufenden“. Dies kann sich positiv auf die Resonanz auf den ServiceDesk bzw. auf das Incident Management auswirken.Es wurde nun gezeigt, dass sämtliche Incidents den hier vorgestellten Prozessdurchlaufen. Des Weiteren wurden das Ziel, die Gewährleistung eines laufendenBetriebs, die Aufgaben und somit der Prozess mit allen einzelnen Instanzen desIncident Managements vorgestellt. Doch was passiert mit den Problemen, alsoden Incidents, dessen Ursache nicht klar ist, diese Frage soll nun im nächstenAbschnitt geklärt werden.

1.2.3 Problem Management

Im vorangegangenen Abschnitt wurde das Ziel des Incident Managements dar-gestellt, nämlich eine schnelle Wiederherstellung des laufenden Betriebs. Einmögliches Mittel ist hierzu zum Beispiel die Bereitstellung einer bereits bekann-ten Lösung in Form von einer Handlungsanweisung oder die Anwendung einesWorkarounds. Doch woher kommen die bekannten Lösungen von Fehlern bzw.


Problemen und woher kommen die Workarounds, die im Incident Managementihre Anwendung finden? Die Antworten dafür sind im Problem Management zufinden.Sobald ein Incident eine unbekannte Ursache hat, wird dieser Incident zum Pro-blem. Dieses wird vom Incident Management, das nicht in der Lage ist, diesesProblem zu behandeln, weitergeleitet zum Problem Management. Hierbei ist zuerwähnen, dass ein Problem durchaus ein Resultat von mehreren Incidents seinkann. „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 Sach-verhalten. Zum einen kann das Incident Management nicht mehr weiterhelfen,zum anderen kann das Incident Management zwar einen Workaround bzw. eineLösung liefern, aber ein und derselbe Incident tritt immer wieder von neuemauf.Als Beispiel könnte hier ein Computer genannt werden, dessen Programme nichtordnungsgemäß ausgeführt werden, und deshalb nicht einwandfrei läuft. AlsWorkaround würde das Incident Management einen Neustart des Computersempfehlen. Hilft dieser Neustart nicht, nach gewisser Zeit wird also derselbeIncident, also die nicht ordnungsgemäße Ausführung der Programme, erneutauftreten, 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 Personengrup-pen darstellen zu können, sollen kurz weitere Beispiele folgen. Als Problemekommen in Frage:

Virenprobleme: Hiervon können einzelne Mitarbeiter, aber auch ganze Un-ternehmen betroffen sein. Die Auswirkungen beziehen sich auf den Ausfalleines Computers bis hin zu ganzen Servern.

Hardwareprobleme: Man kann nicht mehr auf eine bestimmte Festplatte zu-greifen, da sie defekt ist. Bei einzelnen Computerfestplatten wäre dieserVorfall nicht so schlimm, hingegen hat der Ausfall eines Server auf Grundeines Defektes aber einen ganz anderen Stellenwert. Bei einer Bank zumBeispiel könnte dies katastrophale Auswirkungen haben.

Softwareprobleme: Einmal angenommen, eine Universität würde eine be-stimmte Software zur Verwaltung von Noten benutzen. Diese arbeitetallerdings immer wieder fehlerhaft und ordnet die Noten nicht den ge-wünschten Personen zu. Auch hier wären die Auswirkungen definitiv zumerken.

Diese Reihe an Beispielen für Probleme könnte beliebig lang fortgesetzt wer-den und verdeutlicht ganz klar, welches Ziel das Problem Management habensollte 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 andresulting incidents from happening, to eliminate recurring incidents and to mi-nimize the impact of incidents that cannot be prevented.“ [OGC07, S. 58 f.] DasZiel ist daher, Probleme bzw. Incidents zu vermeiden, wiederkehrende Incidentszu eliminieren und die Auswirkungen der Incidents, die nicht vermieden werdenkonnten, zu minimieren. Es lässt sich der ITIL-Philosophie nach dann erreichen,wenn die drei Aufgabenbereiche des Problem Managements, Problem Control,


Error Control und Proactive Problem Management, erfolgreich ausgeführt wer-den. Während die Prozesse der ersten beiden Aufgabenbereiche, genauso wie diedes Service Desks bzw. Incident Managements, dann ausgelöst werden, sobaldein Incident bzw. Problem eintrifft, wird dem Proactive Problem Managementeine besondere Bedeutung zugesprochen und separat behandelt. Doch sollenzunä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 Ma-nagement.

Problem Closure

Unknown Error Identifizieren & aufzeichnen

KnownError ?

Problem Klassifizierung

Untersuchung &Diagnose

Problem?

RfC?

PIR

FehlerBeschluss

Untersuchung &Diagnose

Known Error Identifizieren

& aufzeichnen

ja

nein

Eskalation

ja

nein

Change Management

ja

nein

„Incident“ „Problem“-Control

„Change“„Error“-Control

Abbildung 1.6: Flussdiagramm-Problem.

Problem Control. Wie bereits schon erwähnt, werden Incidents mit unbe-kannter Ursache als Problems bezeichnet. Ob es sich tatsächlich um ein Pro-blem handelt, wird, wie aus den Abbildungen 1.4 und 1.6 ersichtlich, bereits imIncident Management entschieden. Ist dies der Fall, so wird das Problem weiter-geleitet. Der Auslöser für den Prozess des Problem Managements ist somit einUnknown Error, ein Fehler ohne bekannte Lösung. Ein Ziel des Problem Con-trols ist es also, aus dem Unknown Error einen Known Error, einen bekanntenFehler mit Lösung, zu machen und ihn damit, wie das Wort „Control“ bereitssagt, kontrollieren zu können. Dies geschieht in den nun folgenden Schritten.


Unknown Error identifizieren & aufzeichnen: Im ersten Schritt wird derUnkown Error identifiziert. Es soll herausgefunden werden, um welche Artvon Unknown Error es sich hier handelt, ebenso ob mehrere Incidents andiesem Unkown Error beteiligt sind, welche Software davon betroffen istusw.. Des Weiteren wird der Unknown Error oder auch das Problem ineinem sogenannten Problem Record aufgezeichnet und in einer Datenbankabgespeichert. Alle Schritte, von dem Zeitpunkt der Feststellung des Pro-blems bis hin zur Beendigung des Problems, werden in diesem ProblemRecord und somit in der Datenbank festgehalten.

Problem Klassifizierung: Nachdem das Problem aufgenommen ist, muss esnun klassifiziert werden. Es wird hier sowohl die Kategorie des Problemsals auch die Priorität des Problems festgelegt. Da diese Klassifizierungähnlich zu der Klassifizierung eines Incidents verläuft, soll hier näher dar-auf eingegangen werden.16

Untersuchung & Diagnose: In den nun folgenden Subprozessen Untersu-chung & Diagnose und Eskalation wird nun versucht, aus dem UnknownError ein Known Error zu machen und eine Lösung für eventuelle Fehlerzu finden. Die Aufgabe hier ist es „den Problemursachen auf den Grundzu 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 demError Control übergeben.

Eskalation: Zur Ermittlung der gerade vorgestellten Lösungen werden Exper-ten herangezogen. Sollte das Wissen dieser Experten nicht ausreichen, eshandelt sich deshalb immer noch um ein ungelöstes Problem, kurz umeinen Unknown Error, so werden weitere Fachkräfte zu Rate gezogen. Eskommt zu der bereits vorgestellten funktionalen Eskalation.17

Error Control. Nachdem sich das Problem Control mit der Ursache des Pro-blems beschäftigt hat und der Unknown Error zu einem Known Error umge-wandelt wurde, befasst sich das Error Control mit der konkreten Beseitigungdes Fehlers. Dies erfolgt in den Schritten:

Known Error identifizieren & aufzeichnen: Zuerst müssen auch die um-gewandelten Known Errors identifiziert und aufgezeichnet werden. Natür-lich könnte man in diesem Fall mit unnötigen Mehraufwand argumentie-ren, da bereits sowohl der Incident als auch das Problem identifiziert undaufgezeichnet wurden, es geht hier allerdings vielmehr um die Verknüpfungzwischen Known und Unknown Error.

Untersuchung & Diagnose: Nachdem der Fehler bekannt gemacht und do-kumentiert wurde, sollen hier die verschiedenen Lösungsmöglichkeiten er-arbeitet werden. Die Lösungen können Workarounds oder Requests forChange sein. Welche der Lösungen genau gewählt wird, erfolgt im nächs-ten Schritt. Es ist noch anzumerken, dass auch vor der „Untersuchung

16Vgl. Abschnitt 1.2.2.17Da die funktionale Eskalation in dem Abschnitt 1.2.2 behandelt wurde, soll hier nicht

weiter darauf eingegangen werden.


& Diagnose“ des Known Errors wiederum eine Klassifizierung des Errorsstattfinden kann, da diese aber sehr ähnlich zu der des Unknown Errorsist, wird sie hier nicht weiter erwähnt.

Fehler Beschluss: In diesem Schritt wird nun eine der erarbeiteten Lösungs-möglickeiten zur Beseitigung des bekannten Fehlers ausgewählt. Handeltes sich um Workarounds, müssen diese unverzüglich umgesetzt werden.Im Gegensatz dazu stehen die Requests for Change. Wird nämlich zurBehebung des bekannten Fehlers eine Änderung einer Komponente desIT-Bereiches benötigt, so darf das Problem Management diese Änderungnicht einfach durchführen, sondern muss ein RfC, einen Antrag auf Ände-rung, an das sogenannte Change Management weiterleiten. Das ChangeManagement überprüft diesen Antrag auf seine Notwendigkeit und aufdie Auswirkungen, die es im Unternehmen verursacht. Nicht unerwähntsollte hier bleiben, dass das Change Management sowohl einem Requestfor Change zustimmen als auch ihn ablehnen kann. Bei Anlehnung desRequest for Change muss das Problem Management eine andere Lösungauswählen und gegebenenfalls einen neuen Request for Change formulie-ren. Aus diesem Zusammenhang wird deutlich, dass Probleme bzw. Fehlernicht nur einmal diese Prozesse durchlaufen. Auf Grund ihrer Entwicklungim Bezug auf Auswirkung im Betrieb und Priorität müssen sie dauerhaftbeobachtet und, wenn nötig, neu bewertet werden.

Post Implementation Review (PIR): Wurden alle notwendigen Änderun-gen umgesetzt, erfolgt durch das Change Management im Error Controlein sogenannter Post Implementation Review. Dabei wird geprüft, ob dievorgegebenen Ziele, wie zum Beispiel die Beseitigung des Fehlers, durchdie Ä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 er-fasst und dokumentiert wurde. Ist dies nicht der Fall, so muss der Recordergänzt werden.

Proactive Problem Management. Die beiden gerade vorgestellten Aufga-benbereich bzw. Prozesse „Problem Control“ und „Error Control“ sind eherreaktiver18 Natur. Daher sollte ein Problem resp. Fehler eintreten, so wird aufdiesen reagiert und die Prozesse werden in Gang gesetzt. Ganz anders ist es beidem Proactive Problem Management. Hier wird eine Art Voruntersuchung aufzukünftige Problems und Incidents betrieben, um diese bereits im Voraus zuvermeiden und gar nicht erst entstehen zu lassen. Dazu werden:

• Problemfelder und Fehlerquellen analysiert. Deshalb werden hier Fragenuntersucht, 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 undwie es aussieht.

18reaktiv (lat.)=rückwirkend; auf Reize reagierend


Sind diese Fragen beantwortet, werden:

• Präventivmassnahmen zur Vermeidung von Incidents und Problems vor-bereitet. Daher werden hier Möglichkeiten erörtert und ausgearbeitet, diedie Problemfelder und Fehlerquellen beseitigen sollen.19

Ein Beispiel für die beiden Aktivitäten könnte folgendermaßen sein. Angenom-men, eine Firma würde die Daten ihrer Kunden auf einem einzigen Computerspeichern. Diese Datensätze würden neben der Anschrift auch den Briefwech-sel mit besagtem Kunden enthalten. Durch einen wirtschaftlichen Boom würdees nun zu einem rasanten Anstieg der Kundenzahl kommen. In diesem Augen-blick ist das Problem Management gefragt. Es muss erkennen, dass es durcheine höhere Anzahl an Kunden zu mehr Datensätzen auf dem Computer kommtund dieser daher Gefahr läuft, immer wieder abzustürzen, da er mit der großenDatenmenge nicht mehr einwandfrei arbeiten kann. Als zweiten Schritt mussdas Proaktive Problem Management eine Präventivmassnahme zur Vermeidungdieses Problems durchführen. Eine Möglichkeit wäre der Kauf eines weiterenComputers.Auch wenn das vorangegangene Beispiel recht einfach war, so zeigt es aber diehohe Anforderung, die an das Problem Management und seinen Mitarbeiterngestellt wird. Es muss nicht nur ein hohes Fachwissen sondern auch eine Wis-sensdatenbank, ausführliche Dokumentationen vorangegangener Probleme, eineausreichende Anzahl an Programmen usw. vorhanden sein. Des Weiteren wurdegezeigt, dass im Problem Management nicht nur auf Problems reagiert, sondernauch diese vorhergesehen und im Voraus vermieden werden sollen. Wer die Än-derungen, die vom Problem Management zur Beseitigung bzw. Vermeidung vonProblemen erarbeitet und vorgeschlagen werden, im Endeffekt kontrolliert undsteuert, 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-Komponentenhäufig Änderungen unterworfen sind, besteht die Aufgabe des Change Mana-gements darin, standardisierte Methoden und Verfahren zur Abwicklung undÜberwachung von Änderungen zu entwickeln. Darüber hinaus darf nur dasChange Management autorisierte Änderungen durchführen. Es soll somit eineordnungsmäßige Implementierung der Änderung in die IT-Infrastruktur sicher-gestellt werden und mögliche Störungsrisiken minimiert werden.Bevor eine Änderung durchgeführt werden kann, muss ein Änderungsantrag, einsogenannter Request for Change (RfC), an das Change Management übermitteltwerden. Die Änderung kann sich auf die Bereiche der Hardware-Komponenten,Kommunikationsgeräte, Anwendungs- und Systemsoftware, Dokumente sowieProzeduren beziehen. Im Grunde wird jede beabsichtigte Änderung an Kom-ponenten der IT-Infrastruktur, den sogennanten Configuration Items (CIs)20,

19Allerdings ist hier anzumerken, dass das Problem Management die Präventivmassnah-men nicht einfach durchführen darf. Es müssen zuvor Kosten-Nutzen Rechnungen durchge-führt werden, um zu sehen, ob sich der eingesetzte Aufwand zur Vermeidung von Problemenüberhaupt lohnt.

20Eine genauere Erklärung eines CIs ist im Abschnitt 1.2.6 zu finden.


mit einem RfC an das Change Management übermittelt. Ist zum Beispiel ei-ne Hardware-Komponente defekt, wie die Festplatte, der Monitor oder sogarder Server, muss dies dem Change Management übermittelt werden, damit eineÄnderung durchgeführt werden kann. Darüber hinaus muss das Change Ma-nagement entscheiden, welche Änderungen zuerst durchgeführt werden sollen.So hat die Reparatur eines Servers eine höhere Priorität als ein defekter Moni-tor. Zu den weiteren Aufgaben, die das Change Management bzw. der ChangeManager 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 einesRfC,

• abschließende Revision (PIR)21.

Ein RfC kann von allen Benutzern der IT versendet werden. Vorteilhaft istdie elektronische Übermittelung mit Hilfe von standardisierten Anträgen.22 DerChange Manager entscheidet in einer Vorauswahl, ob ein RfC akzeptiert oderabgelehnt wird. Ähnlichen RfCs können auch zusammengefasst werden. JederRfC bekommt eine eindeutige Identifikationsnummer zugewiesen und wird do-kumentiert. Während der gesamten Durchführungsphase wird jeder einzelneSchritt eines RfC protokolliert und an die Configuration Management Data-base (CMDB)23 übermittelt. Am Ende der Durchführung sollen nach den ITIL-Empfehlungen die nachfolgenden Fragen ([TRA07, S. 53]) beantwortet werdenkö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 Implementierungder Veränderung?

Ist eine grobe Vorauswahl für die Ausführung einer Änderung getroffen, wirddie Priorität und Kategorie des RfC eingestuft. Die Einstufung erfolgt nach derDringlichkeit oder dem Ausmaß bzw. dem Risiko einer Änderung. Hierzu gehörtauch eine Kosten/Nutzen-Rechnung, die mit darüber entscheidet, ob eine Ände-rungen wirklich durchgeführt werden soll. Des Weiteren müssen Ressourcen fürÄnderungen bereitgestellt werden. Zu den Ressourcen gehören unter anderemPersonal, Hardware, Software und finanzielle Mittel.Handelt es sich um einen RfC mit geringer Priorität, wie zum Beispiel eine Än-derung der Zugriffsrechte eines Users oder andere routinemäßigen Aufgaben, so

21PIR steht für Post Implementation Review.22Hierbei können Service Tools eingesetzt werden.23Eine genauere Erklärung einer CMDB ist im Abschnitt 1.2.6 zu finden.


obliegt die Entscheidung der Durchführung allein bei dem Configuration Mana-ger. Bei dieser Art von RfC sind meistens nur ein oder wenige User betroffenund es ist kein großer Ressourcenaufwand nötig.Ist es hingegen eine Priorität und Kategorie höherer Stufe, wird das sogenannteChange Advisory Board (CAB) oder in einigen Fälle sogar das Emergency CAB(ECAB) einberufen. Das CAB ist zuständig für Änderungen mit mittlerer undhoher Priorität und Kategorie, wie zum Beispiel die Umstellung des Betriebs-systems bei sämtlichen Computern von Windows XP auf Windows Vista. Meistsind hier mehrere User von den Änderungen betroffen und ein höherer Aufwandan Ressourcen ist nötig. Das CAB setzt sich aus mehreren Mitgliedern zusam-men. Diese können sowohl aus dem Bereich des Incident Managements, ProblemManagements, Service Desks, usw. kommen als auch IT-Experten, etc. sein undsollten regelmäßig in Kontakt zueinander stehen. Bei größeren Änderungen sollteauch der jeweilige betroffene Personenkreis mit in die Entscheidung einbezogenwerden. Wird das ECAB einberufen, liegt ein dringendes Problem vor, dass nurmit hohen Aufwand an Ressourcen zu lösen ist. Dieses Problem betrifft meist al-le User und muss sehr schnell behoben werden. Hierzu gehört beispielsweise derAusfall des gesamten Netzwerkes. Das ECAB besteht aus wenigen Mitgliederndes CABs, die stellvertretend für die restlichen Mitglieder schnelle Entscheidun-gen treffen können. Die Abbildung 1.7 zeigt die einzelnen Schritte, die ein RfCdurchläuft.Wurde der RfC genehmigt, beginnt die zeitliche Planung der Änderung. Je nachDringlichkeit werden die RfC geordnet und die benötigten Ressourcen bereit-gestellt. Die Informationen werden an die CMDB übermittelt, so dass sicher-gestellt ist, dass sich der User über den genauen Bearbeitungsstand des RfCinformieren kann. Im nächsten Schritt werden die für die Umsetzung bzw. fürdie Durchführung der Änderungen zuständigen Bereiche kontaktiert. Die Haupt-aufgabe des Change Managements besteht nun aus der formalen Koordinationund Überwachung der Änderungen. Es muss darauf geachtet werden, dass diebereitgestellten Ressourcen ausreichend sind, um den Change planmäßig durch-zuführen. Dies geschieht in enger Zusammenarbeit mit dem Release Manage-ment, das für die tatsächliche technische Umsetzung der Änderung zuständigist. Nach einer Testphase, in der sichergestellt werden soll, dass die Änderun-gen ordnungsgemäß funktionieren, erfolgt die abschließende Implementierungder Änderungen. Dies sollte zu einem Zeitpunkt geschehen, bei dem möglichstwenige andere Prozesse beeinträchtigt werden. Nach der Implementierung soll-te nach einiger Zeit eine abschließende Revision (PIR) zur Qualitätssicherungerfolgen. Es wird dabei festgestellt, ob die Ziele der Änderung erreicht wurdenoder ob unerwünschte Nebeneffekte aufgetreten sind. Aber es wird auch über-prüft, inwieweit die eingeplanten Ressourcen ausreichend waren. Mit Hilfe dieserabschließenden Revision lassen sich mögliche Schwachstellen aufdecken, die beizukü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 effizientdurchgeführt und Fehlerquellen minimiert werden. Auf den ersten Blick er-scheint es, dass es ein großer Aufwand für den Anwender ist, jede Änderungeines CI erst durch das Change Management genehmigen zulassen. Denn oft-mals lassen sich die Änderungen schnell von dem Anwender selbst durchführen.Doch es kann dann passieren, dass das IT-System nicht mehr konsistent ist unddas System dadurch nicht mehr fehlerfrei arbeitet. Um dies zu vermeiden, ist es


ablehnen gering mittel hoch dringend

RFC

Change Manager

• RFC filtern• Priorität festlegen

ChangeManager

CAB/ECAB

genehmigt ?

ja

Changeplanen & durchführen

abschließende Revision

Erfolg ?

ja

nein

nein

Ende

Configuration Management

(CMDB)

Release Management

Abbildung 1.7: RfC-Ablauf.

wichtig, einen RfC an das Change Management zu übermitteln. Um die Syste-mintegrität der genehmigten Änderungen sicherzustellen, arbeitet das ChangeManagement eng mit dem Release Management zusammen, das im folgendenAbschnitt näher erläutert wird.

1.2.5 Release Management

Das Release Management ist für die Bereitstellung, Einführung und Verwal-tung von autorisierter Software und Hardware zuständig. Während das ChangeManagement für die Entwicklung von standardisierten Methoden und Verfah-ren zur Durchführung und Überwachung von Änderungen verantwortlich ist,befasst sich das Release Management unter anderem mit der Sicherstellung derSystemintegrität der Änderungen. Des Weiteren entwickelt das Release Manage-ment qualitätssichernde Richtlinien und Grundkonfigurationen zur Installationvon IT-Systemen. Es lässt sich somit festhalten, dass das Release Managementmaßgeblich die Verantwortung dafür trägt, dass neue oder veränderte CIs vollfunktionsfähig in die IT-Umgebung implementiert werden. Zu den Hauptaufga-ben des Release Managements gehören:


• Festlegung der Release Policy,

• enge Zusammenarbeit und inhaltliche Abstimmung mit dem Change Ma-nagement,

• Planung, Überwachung und Durchführung von Änderungen bzw. Einfüh-rungen von Software und Hardware,

• Dokumentation, Verwaltung, Versionierung und Speicherung von geneh-migten Releases.

Im Kontext der ITIL wird jedes neue oder veränderte CI, dass von dem ReleaseManagement veröffentlicht wird, als Release bezeichnet. Hierbei können ähn-liche Releases auch gebündelt und als Paket veröffentlicht werden. In diesemZusammenhang lassen sich drei verschiedene Release-Arten nach ihrem Umfangunterscheiden:

Full Release: Alle Software- und Hardwarekomponenten werden zusammenentwickelt, getestet und verteilt.

Delta Release: Es sind nur Komponenten enthalten, die seit dem letzten Re-lease geändert worden sind.

Package Release: Full Releases und Delta Releases werden zu einem Paketgebündelt und veröffentlicht.

Hilfreich hierbei ist eine zentrale Softwareverteilung, die die Releases auf die re-levanten Computer verteilt. Die Implementierung von Releases werden als Rol-lout 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 ReleaseManagement die Definitive Software Library (DSL). Es handelt sich dabei umeine Datenbank auf der sich sämtliche autorisierte Software befindet. Mit Hilfedes Backup-Systems bzw. Repository kann auf eine lauffähige Sofwareversionzurückgegriffen werden. Darüber hinaus werden in der DSL auch die Software-lizenzen verwaltet. Die DSL ist in die CMDB des Configuration Managementsimplementiert, untersteht aber der Kontrolle des Release Managements. Diesesverwaltet auch den Definitive Hardware Store (DHS). Es handelt sich dabei umein Lager mit wichtigen Hardwarekomponenten. Auf Grund der hohen Kosteneiner Vorratshaltung sollten nur kritische Komponenten als Ersatz gelagert wer-den. Die Informationen, an welcher Stelle die Ersatzteile gelagert sind, werdenin der CMDB gespeichert.Mit Hilfe von Abbildung 1.8 soll auf die wichtigsten Aufgaben des Release Ma-nagements eingegangen werden. Wie aus ihr ersichtlich wird, sind die Aufgaben-bereiche des Release Managements in die Entwicklungs-, Test- und Produkti-onsumgebung integriert. Dadurch wird sichergestellt, dass die Releases fehlerfreiin das IT-System implementiert werden. Wie der allgemeine Vorgang eines Re-leases durchgeführt wird, hängt von der Release Policy ab. Die Release Policybestimmt die Richtlinien für die Bearbeitung und Dokumentation eines Releaseund ist als Leitfaden für die weitere Bearbeitung zu verstehen. Wird ein auto-risierter RfC an das Release Management übermittelt, beginnen die Planungen


Entwicklungs-umgebung

Test-umgebung

Produktions-umgebung

Configuration Management

CMDB

DSL

Informationen über den DHS

Planung Entwicklung/Bestellung

Erstellung/Konfiguration

Testphase/Akzeptanz

Rollout-planung

Information/Training Installation

Release Management

ReleasePolitik

Abbildung 1.8: Release Management.

für die Änderungen. Dies geschieht in enger Zusammenarbeit mit dem ChangeManagement.So müssen Releaseinhalte, Prioritäten, benötigten Ressourcen, Notfallpläne usw.festgelegt werden, um eine schnelle Umsetzung zu gewährleisten. Im nächstenSchritt wird der Release entwickelt. Handelt es sich bei dem Release um ei-ne Softwareänderung, muss sichergestellt sein, dass sich eine lauffähige Versi-on der Software auf der DSL befindet. Anschließend sollte der Release in einerealitätsnahe Testumgebung implementiert werden, um die Systemintegrität zuüberprüfen. Wenn der Release die Anforderungen erfüllt, beginnen die Planun-gen für den Rollout. Dieser Schritt umfasst die Terminplanung und Koordina-tion der Implemetierung des Release in die Produktionsumgebung. Bevor derRelease veröffentlicht wird, sollten die betroffenen User über die Änderungenunterrichtet werden. Im letzten Schritt erfolgt die endgültige Verteilung undImplementation des Release. Sämtliche Schritte werden dokumentiert und demConfiguration Management übermittelt. Dadurch lassen sich die Änderungenund deren Auswirkungen nachvollziehen und gegebenenfalls korrigieren. Die wei-teren Aufgaben des Configuration Managements werden im folgenden Abschnitterläutert.

1.2.6 Configuration Management

Das Configuration Management stellt eine wichtige Komponente im Bereich derService Support-Prozesse dar. Aufgabe des Configuration Managements ist es,den anderen ITIL-Prozessen Informationen über die IT-Infrastruktur bereitzu-stellen. Somit fungiert das Configuration Management unter anderem als Daten-bank. Wichtig hierbei ist, dass sich die Informationen auf dem aktuellsten Standbefinden. Um dies zu gewährleisten, muss jede Veränderung der IT-Infrastruktur


durch das Change Management bzw. das Release Management an das Configu-ration Management übermittelt werden. Zu den Veränderungen zählen nebenModifikationen an Komponenten der Hardware und Software auch Änderungenan Dokumenten.24

Anhand der Abbildung 1.9 wird die zentrale Bedeutung des Configuration Ma-nagements und die wechselseitige Beziehung zu den anderen ITIL Support Pro-zessen verdeutlicht.

Incident Management

ProblemManagement

ChangeManagement

ReleaseManagement

ConfigurationManagement

Informationsfluss

Abbildung 1.9: Informationsfluss Configuration Management und Service Sup-port Prozesse.

Alle Komponenten, die in der IT-Infrastruktur von dem Configuration Mana-gement erfasst werden, bezeichnet man als Configuration Item (CI). Die CIswerden in einer zentralen Datenbank, der sogenannten Configuration Manage-ment Database (CMDB), gespeichert und verwaltet. Die Besonderheit bei derCMDB ist, dass sie nicht bloß die einzelnen CIs speichert, wie es bei einer Be-standsdatenbank der Fall ist, sondern ebenfalls deren Verflechtungen zueinanderwiderspiegelt. Ein CI setzt sich oft aus mehreren CIs zusammen. So besteht einComputer, der auch ein CI ist, aus einer Festplatte, CD-Rom, Netzwerkkarte,Software usw., die ebenfalls einzelne CIs sind. Der Computer ist natürlich auchnur ein Bestandteil eines höher geordneten CIs.Auf Grund dieser vielfältigen Verflechtungen ist es wichtig, jedem CI eine ein-deutige Identifikationsnummer zuzuteilen, um einen Überblick über alle CIs si-cherzustellen. Des Weiteren müssen zu jedem CI die wichtigsten Eigenschaftenresp. Attribute gespeichert werden. Ein Vorteil dieses Aufbaus der CMDB ist,dass bei einer Störung oder bei einem Ausfall eines CIs genau nachvollzogenwerden kann, welche Komponenten mitbetroffen sind. Da auch Änderungen, In-

24Zu den Dokumenten zählen zum Beispiel Problem- und Fehlerbehebungs-Beschreibungen,Installationsanleitungen, usw..


cidents, Problems, Known Errors und Releases und deren Beziehungen als CIsgespeichert sind, ist eine effiziente Fehlerbehebung möglich.Abbildung 3.6 zeigt eine vereinfachte Darstellung der Struktur der CIs und derenEigenschaften.

CMDB

Hardware

CI

ComputerID:1234Prozessor : Intel Core

2 GHHD : 60 GBSoftware : MS Vista

MS OfficeMonitor : LCDusw.

Software Dokumentation

Abbildung 1.10: CI-Verflechtung in der CMDB.

Zusätzlich ist innerhalb der CMDB die Definitive Software Library (DSL)25 im-plementiert. Darüber hinaus sind die Informationen über den Definitive Hard-ware Store (DHS), die von dem Release Management verwaltet werden, aufder CMDB gespeichert. Aus diesem Zusammenhang wird ersichtlich, dass dieCMDB ein zentraler Punkt hoher Komplexität ist. Um diese Arbeit zu bewälti-gen, müssen folgende Aufgaben von dem Configuration Management bzw. vonder Rolle des Configuration Managers erfüllt werden:

Aufbau und Planung des Configuration Managements: Pläne und Pro-zeduren für sämtliche Aktivitäten des Configuration Managements müssenfestgelegt werden. Dieser Punkt umfasst unter anderem auch die Definiti-on der CIs und eine einheitliche Namenskonvention der CIs, dadurch sollein konsistenter Zustand der Datenbanken sichergestellt werden. Des Wei-teren muss der Umfang und die Struktur der CMDB festgesetzt werden,zum Beispiel die Festlegung der Speicherkapazitäten der CMDB und derDSL. Um ein effizientes Arbeiten zu ermöglichen, müssen auch geeigne-te Configuration Management-Tools implementiert werden, die die Arbeitmit den Datenbanken erleichtern sollen. Da im Zeitablauf der Arbeitsauf-

25Zur Erklärung vgl. Abschnitt 1.2.5.


wand wächst, sollte durch einen regelmäßigen Soll/Ist-Abgleich sicherge-stellt sein, dass die zur Verfügung gestellten Ressourcen ausreichend sind.

Identifikation der CIs: Eine wesentliche Komponente bei der Identifizierungder CIs ist das Maß der Differenzierung der IT-Infrastruktur. So ist derAufwand abhängig von der Definition der CIs. Soll zum Beispiel ein PC in-kl. Maus, Tastatur und Monitor ein einzelnes CI darstellen oder sollen dieBestandteile auch als CIs definiert sein? Diesen Fragen werden zuvor beidem Aufbau und der Planung des Configuration Managements geklärt. Jenach Maß der Differenzierung muss die IT-Infrastruktur in ihre Bestand-teile zerlegt werden und sämtliche CIs erfasst werden. Zu den möglichenCIs gehören beispielsweise die Hardware, Software, Dokumentationen derSystemkonfiguration, RfC, Dokumentationen über Änderungen und Ab-weichungen, Fehlerbehebungs-Beschreibungen, usw..

Kontrolle der CIs: Das Configuraion Management sorgt dafür, dass sich nurautorisierte und aktuelle Einträge über die CIs in der CMDB befinden.Um dieses zu gewährleisten, gehört dazu die Registrierung neuer CIs, dieAktualisierung bestehender CIs, Lizenz-Kontrollen, Kontrolle der DSL,usw..

Statusinformationen über die CIs: Über den gesamten Einsatzzeitraum ei-nes CIs werden Berichte mit allen relevanten Informationen und dem ak-tuellen Zustand angefertigt. Auf diese Weise können die anderen ServiceSupport-Prozesse immer auf aktuelle Informationen zurückgreifen.

Verifizierung und Audits: Damit die Aktualität der CMDB sichergestelltist, müssen die gespeicherten Daten in regelmäßigen Abständen überprüftwerden. Bei dieser Verifizierung bzw. Audit wird festgestellt, ob die gespei-cherten Daten der CIs die aktuellen Daten der CIs widerspiegeln. Solltedies nicht mehr der Fall sein, wird ein RfC mit Hilfe des Change Manage-ments und Release Managements durchgeführt.

Abbildung 1.2.6 zeigt die Aufgabenbereiche und die Schnittstellen des Configu-ration Managements mit den anderen Service Support-Prozessen anhand einesIncidents.Bei der Registrierung eines Incidents sendet das Incident Management die Da-ten zu der CMDB. Falls es sich um einen bekannten Fehler handelt und dazuLösungskonzepte oder andere Details existieren, stellt die CMDB diese bereit.Wird nur eine temporäre oder keine Lösung erreicht, wird der Vorfall an dasProblem Management weitergereicht. Auch hier findet ein Austausch von Datenstatt. 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 undzu einem Known Error, wird dies der CMDB übermittelt. Um das Problem zulösen, wird ein RfC an das Change Management weitergeleitet. In enger Zusam-menarbeit mit dem Release Management werden die notwendigen Änderungendurchgeführt und an die CMDB übermittelt.Mit Hilfe des Configuration Managements und den dazugehörigen Komponen-ten sollte es möglich sein, die Effizienz und die Effektivität der IT-Organisationzu steigern. Es eignen sich verschiedene Vorgehensweisen für die Einführung


Service Desk

IncidentManagement

ChangeundRelease Management

ProblemManagement Configuration

Management

Start

Incident

Problem

Known Error

Request for Change

Autorisierter Change

Change ausgeführt

Ende

CMDB

(inkl. DSLund Info.

DHS)

Abbildung 1.11: Schnittstelle zwischen CM und andere ServiceSupport Prozesse. Quelle: Eigene Darstellung in Anlehnung an[Vic05, S. 56]

eines Configuration Managements. Von Vorteil ist es, wenn von Anfang an ei-ne ITIL konforme Implementierung erfolgt, denn dadurch verringert sich derArbeitsaufwand. Natürlich ist eine schrittweise Einführung möglich, die Vor-raussetzung dafür ist aber eine genaue IST-Analyse der IT-Infrastruktur. EinHinderungsgrund für einen reibungslosen Ablauf des Prozesses ist oft die feh-lende Akzeptanz der Mitarbeiter. Sie müssen jede Veränderung der IT an dasConfiguration Management weitergeben, oftmals erscheint ihnen dies als zu bü-rokratisch. Es ist aber eine Notwendigkeit, um eine aktuelle CMDB und diedamit verbundenen Vorteile zu garantieren.

Im nächsten Kapitel erfolgt eine Untersuchung des aktuellen IT-Managementsbzw. Service Supports an der Universität Bielefeld anhand der Fakultät fürWirtschaftswissenschaften und der Fakultät für Rechtswissenschaft. Das Ziel solles sein, mit Hilfe des in Kapitel 2 vorgestellten idealtypischen Verlaufes des ITILService Supports die Möglichkeit der Implementierung eines ITIL konformenService Supports an der Universität Bielefeld darzustellen.


1.3 Untersuchung des IT-Managements in derUniversität Bielefeld

In diesem Kapitel soll der Service Support anhand von zwei ausgewählten Fa-kultäten untersucht werden. Es wird sowohl die Fakultät für Wirtschaftswis-senschaften als auch die Fakultät für Rechtswissenschaft betrachtet. Zu diesemZweck haben wir mit den System-Administratoren der jeweiligen Fakultät Ge-spräche geführt. Der Fragenkatalog wurde in die einzelnen Prozesse bezüglichdes Service Supports gegliedert. Grundsätzlich kann man die IT der beiden Fa-kultäten nicht in die Funktion des Service Desks und die einzelnen Prozesseeinteilen, da die Aufgaben und Zuständigkeiten der einzelnen Mitarbeiter nichtklar abgegrenzt sind, dennoch wird dies hier versucht. Dementsprechend kannauch nicht von den unterschiedlichen „Rollen“ der einzelnen Prozesse gespro-chen werden.

1.3.1 Fakultät für Wirtschaftswissenschaften

Zuerst wird der Aufbau der IT in der Fakultät für Wirtschaftswissenschaftenbeschrieben. Die Fakultät für Wirtschaftswissenschaften betreibt ihre lokalenNetzwerke mit minimalem Personalaufwand. Die wesentlichen Aufgaben sinddie 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 Desknach ITIL als ein „Single Point of Contact“ für die Kommunikation mit demEndanwender verantwortlich sein. Auch die Administratoren der Fakultät fürWirtschaftswissenschaften sind die einzigen Ansprechpartner für sämtliche Inci-dents, Problems und Request for Changes bezüglich der Hardware und Software,zumindest sollten sie dies sein. Die Kontaktaufnahme mit den Administratorenerfolgt über verschiedene Weisen, zum einen kommen die User persönlich bei ih-nen im Büro vorbei, zum anderen teilen sie ihnen telefonisch oder auch per eMailden Vorfall mit. Dies kann auch in mehrfacher Form geschehen. Wenn möglich,sollten die Probleme und Fehler mit möglichst genauer Beschreibung per eMailan die Systembetreuer gesendet werden. Auf Grund der geringen Anzahl anMitarbeitern kann jedoch nicht zwischen First Level Support oder Second LevelSupport unterschieden werden.

Incident Management. Bei Meldung eines Incidents sollte prinzipiell keinUnterschied gemacht werden, wer den Vorfall meldet. Dennoch muss im Nach-hinein differenziert werden, welchen Status der User innerhalb der Fakultätinnehat. Außerdem kann es von den persönlichen Vorlieben des Mitarbeitersabhängen.Dieses kann am Beispiel „Drucker“ betrachtet werden. Es sind in der Fakultätzwei unterschiedliche Kategorien an Druckern vorhanden, es gibt sowohl Büro-drucker, die lokal an einem Computer angeschlossen sind, als auch Netzwerk-drucker, die von mehreren Personen genutzt werden. Auf Grund der Nutzungvon mehreren Personen genießen die Netzwerkdrucker einen wesentlich höherenSupport als die Bürodrucker, deshalb haben Netzwerkdrucker auch eine hohe


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 eineinzelner von dem Incident betroffen ist.Die Priorität kann in drei unterschiedliche Kategorien eingeteilt werden, Inci-dents können hoch, mittel oder niedrig eingestuft werden. Grundsätzlich werdendie meisten Vorfälle bei Auftreten oder bei Meldung erstmal hoch eingestuft.Nach einer kurzen Beschäftigung mit dem Incident wird der Vorfall eventuellneu priorisiert, da bemerkt wird, dass dieser für den Moment nicht so wich-tig ist. Wartet man zum Beispiel auf die Lieferung eines Ersatzteils, so stelltman den Incident zurück und behaftet ihn mit einer Information, dass auf denLieferungeingang gewartet wird.Zu den einzelnen Incidents werden unterschiedliche Informationen abgespei-chert, nicht nur Informationen zu dem User und dessen Computer, sondernauch zum Beispiel der letzte Bearbeiter.Auf Nachfrage bekommen die User, die ein Incident vorliegen haben, eine Über-sicht über den Stand der Dinge. Auch bei Bestellungen wird der User darüberinformiert, dass zum Beispiel die Bestellung aufgegeben wurde und wann miteiner Lieferung zu rechnen ist. Jedoch reagieren oftmals die Kunden ganz unter-schiedlich, die einen möchten auf dem Laufenden gehalten, den anderen reichtdie Meldung, dass sich darum gekümmert wird.

Problem Management. Nach ITIL wird zwischen „Incident“ und „Pro-blem“ unterschieden, ein Problem ist schwerwiegender als ein Incident. Bei denAdministratoren der Fakultät für Wirtschaftswissenschaften gibt es eine sol-che Unterscheidung nicht. Auf den Computern in der Fakultät wird Standard-Software installiert. Dennoch möchten manche User eine spezielle Software aufihren Computern haben, treten bei diesen dann Fehler auf, so ist der Support-level von den Administratoren sehr gering. Es wird bei Anschaffung darauf hin-gewiesen, dass bei eventuellen Problemen mit der Software keine Unterstützungdurch die Administratoren gewährleistet werden kann. Tritt ein Fehler oder einProblem bei einer Standard-Software, verfügen sie über eine selbst angeeignetenWissensbasis. Dennoch kann man auch Hilfe im Internet oder in verschiedenenAdministratoren-Foren finden, da die Standard-Software oftmals eine sehr ver-breitete Software ist. Ist trotzdem zu einem gewissen Zeitpunkt der Supportnicht mehr möglich, so wird der Hersteller der Hardware oder Software kontak-tiert. Dies kommt jedoch in den seltensten Fällen vor. Um Fehler oder Problemean der Software im Voraus zu verhindern, wird, sobald sich Software in einerneuen Version auf dem Markt befindet, diese getestet und überprüft. Damit dieSchadensbegrenzung so gering wie möglich zu halten, wird eine Empfehlung zurNichtnutzung der bestimmten Software ausgesprochen.

Change Management. In Bezug auf finanzielle Mittel sind alle Lehrstühleder Fakultät für Wirtschaftswissenschaften selbst verwaltet, also alle haben eineigenes Budget, das ihnen frei zur Verfügung steht. Dieses wird von der Fakul-tätsverwaltung verwaltet, jedoch hat die Fakultätsverwaltung kein technischesKnow-How bezüglich der Software oder Hardware. Aus diesem Grund könnendie Administratoren nur leiten und beratend eingreifen, was die Beschaffungenbetrifft, haben aber keinen direkten Einfluss darauf. Sie haben nicht die Mög-lichkeit, zum Beispiel „unvernünftige “ Beschaffungen, die von den Lehrstühlen


gewünscht werden, zu verhindern. Auch bezüglich der Hardware besteht einStandard, der eingehalten werden soll. Da man sich bereits Kenntnisse überdie standardisierte Hardware angeeignet hat, kann so Zeit eingespart werden,die man unnötig vergeuden würde, wenn man sich ständig mit unterschiedlicherHardware auseinandersetzen müsste.An erster Stelle steht das HRZ, das Empfehlungen bezüglich der Hardware oderSoftware herausgibt. Bevor die Software den Usern angeboten wird, wird dieLauffähigkeit im universitären Umfeld getestet, wie sie im universitären Umfeldläuft, vor allem mit dem Server.Die PC-Nutzer verfügen in der Regel keine Administratoren-Rechte, sie habennur Hauptbenutzer-Rechte.

Release Management. Die Administratoren sind sowohl für Beschaffung,Installation, Wartung und Entsorgung Hardware als auch für Beschaffung, In-stallation und Pflege von System- und Anwendungssoftware zuständig. Sie kön-nen Hardware oder Software kostengünstig beschaffen, außerdem können dieBeschaffungen dann auch gebündelt werden. die Administratoren können be-ratend eingreifen, da innerhalb der Fakultät bezüglich Hardware und Softwaregewisse Standards eingehalten werden sollen.Die Computer-Arbeitsplätze werden für die Benutzer funktionsfähig eingerich-tet. Die Erstinstallation umfasst das HRZ-Basic-Bundle. Im Hochschulrechen-zentrum (HRZ) wird ein Software-Bundle bereit gestellt, das es in zwei unter-schiedlichen Ausführungen gibt. Dies ist zum einen das Basic-Bundle und zumanderen das Classic-Bundle, das das Basic-Bundle beinhaltet. Die Konfigurati-on, die Implementierung und die Beratung der HRZ PC-Services in der Fakultätsollte durch die Administratoren mit beratender Unterstützung durch das HRZgeschehen. Die Software wird ausschließlich von den Administratoren beschafftund installiert. Sonstige Software aus dem Classic-Bundle und weitere Installa-tionen, die nicht aus dem Bundle stammen, werden per Antrag auf Kosten desbetreffenden Lehrstuhls beschafft. Bei gekaufter Software ist der Lizenznehmerimmer die Fakultät, die Kopien und die Originalen werden bei den Administra-toren aufbewahrt. Sie sind also Ansprechpartner für Softwareangelegenheiten,außer es wird spezielle Software genutzt, die zum Beispiel aus dem HRZ-Classic-Bundle kommt.Bei einem Backup-System oder einer Repository muss man zwischen Programm-Dateien und User-Dateien unterscheiden. Jeder Benutzer sollte aus Sicherheits-gründen seine eigenen User-Dateien auf der persönlichen Home Directory spei-chern, da sich dieses Laufwerk auf den Servern des HRZ befindet und täglichgesichert wird. Außerdem befinden sich mehrere Versionen der User-Dateien aufden Servern.Bei Problemen in der Konfiguration, die durch fehlerhafte Programme ausgelöstwerden, werden diese gelöscht und anschließend neu installiert. Es gibt also keinsogenanntes Lifecycle-Management.In der ITIL gibt es den sogenannten Definitive Hardware Store (DHS). Hierbeihandelt es sich um ein Lager mit wichtigen Hardwarekomponenten. Aus Platz-gründen wird Hardware nicht gelagert, sondern erst bei Bedarf beschafft, dannfür den Einsatz vorbereitet und kommt dann zu dem Endnutzer. Es sind nurStandard-Sachen in geringer Anzahl vorhanden, wie zum Beispiel Tastaturen,Computer-Mäuse, Laufwerke etc. Da die Administratoren für die Netzwerkdru-


cker zuständig sind, müssen sie sich auch um Toner für diese kümmern und einpaar auf Lager haben.

Configuration Management. Die Computer, die für die Fakultät beschafftwerden, werden zentral von der Universität verwaltet, deshalb werden sie einersogenannten Inventarisierungsnummer zugeordnet. Dies wird mit jedem Rech-ner gehandhabt. Außerdem wird in der Universitätsverwaltung dokumentiert,wer den Rechner nutzt, wo dieser steht, etc.. Auch die Administratoren habeneine solche Datenbank, in der neben den bereits oben erwähnten alle sonstigenInformationen 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ürdie Wirtschaftswissenschaften. Jedoch ist sie nicht an die Active Directory desHRZ angeschlossen, sondern sie betreibt ihre eigene Domäne26.

Service Desk. Auch in der Fakultät für Rechtswissenschaften existiert teil-weise ein Service Desk. Die EDV ist täglich von zwei Personen besetzt, eineVollzeitkraft und eine studentische Hilfskraft. Einer von beiden ist im Büroanzutreffen und arbeitet organisatorisch, der andere erledigt die Problembe-handlung an den Lehrstühlen. Auch hier werden Incidents oder Requests forChange durch die übliche Art und Weise an die EDV-Betreuer herangetragen,sprich persönlich, durch einen Anruf oder per eMail. Es soll aber vornehmlichper eMail mit den EDV-Betreuern Kontakt aufgenommen werden. Eine Unter-scheidung zwischen einem First Level Support und einem Second Level Supportkann man an dieser Stelle auch nicht entdecken. Der Third Level Support sindAnfragen an den Hersteller der Software oder Hardware.

Incident Management. Generell wird bei der Meldung eines Incidents kei-ne Unterschiede gemacht, wer den Incident meldet, jedoch hängt es auch hiersehr von dem Status in der Fakultät ab. Ein Professor bzw. seine Sekretäringenießen klar Vorrang. Trotzdessen wird aber auch festzustellen versucht, wiesehr der Incident den Arbeitsfähigkeit der Person einschränkt, also wie hoch derArbeitsausfall ist.Momentan läuft die Aufnahme eines Incidents größtenteils über eMail ab, sprichman schreibt den Kollegen und somit auch sich selbst eine eMail, in der dannnähere Details zu dem Incident stehen und was gemacht werden soll. Nach Ab-handlung des Incidents wird die dazugehörige eMail in einen anderen Ordnergeschoben. Es werden weder irgendwelche Daten erfasst noch wird dokumen-tiert, wie hoch der Zeitaufwand war, es gibt also weder den sogenannten Inci-dent Record noch den Problem Record. Es soll aber ein Open Ticket RequestSystem (OTRS) eingeführt werden, mit dem sich dann Probleme und Anfragenbearbeiten lassen. Außerdem existiert ein internes Wiki27. Es dient nicht nur als

26Eine Domäne ist ein Server zur zentralen Authentifizierung und Autorisierung von Com-putern und Benutzern in einem Rechnernetz.

27Unter 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ück-gegriffen werden.


organisatorische sondern auch als technische Datenbank, in der jedoch nur Pro-bleme, 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 Pro-bleme besprochen werden und Lösungsvorschläge gemacht werden. Bei der Be-handlung von Problemen an der Software dienen zum Beispiel Mailinglisten derOpen Source Produkte als Hilfe, manchmal wird auch Rücksprache mit demHRZ getroffen. Bei Hardwareproblemen lässt man einen Techniker des passen-den Herstellers kommen.

Problem Management. Auch für die Fakultät für Rechtswissenschaft gibtes eine Standardsoftware-Installation. Bei speziellen Wünschen bezüglich derSoftware wird die sich auf dem Markt befindliche Software gesichtet, so dassdann eine als Standardsoftware definiert. Für eine Aufgabenstellung gibt es je-weils auch nur eine Standardsoftware. Wird eine andere Software für die gleicheAufgabe gewünscht, so muss man sich mit der Standardsoftware begnügen. Solassen sich Probleme an der Software schneller beheben, da jeder Computer ander Fakultät mit der gleichen Software ausgestattet ist.Die Benutzer haben keine Administratoren-Rechte, sie können daher auch keineSoftware 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 gibteine Standard-PC-Ausstattung. Bis zu einem Betrag von 200 Euro kann allessofort beschafft werden, alles andere läuft über die Beschaffungsstelle der Fa-kultät. Diese leitet es dann an die Zentrale Beschaffungsstelle der Universität.Extrawünsche werden mit einer Empfehlung der EDV an die Verwaltung wei-tergeleitet, jedoch werden diese oft abgeblockt. Es wird versucht, den PC-Poolmöglichst identisch zu halten.Die Softwareeinführung, zum Beispiel die Einführung einer neuen Windows-Version, wird durch die Lehrkörperkonferenz abgehandelt. Zuerst wird mit demDV-Beauftragten kommuniziert, dieser stellt dann das Vorhaben in der Lehr-körperkonferenz vor. Es muss von der ganzen Fakultät beschlossen, damit esauch 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 kau-fen, denn dafür ist die EDV-Abteilung zuständig. Es muss ein Beschaffungsauf-trag 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 nichtauf 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 Lehr-stühle die neue Software oder -version bekommen. Meistens wird die Softwarevor 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üh-le die Software. So wird der Software-Pool auf dem aktuellsten Stand gehalten,zumindest die gängige Software.


Da die Fakultät für Rechtswissenschaft, wie bereits schon erwähnt, ihre eigeneDomäne betreibt, werden die Daten des Benutzers auf den Rechnern gespeichert.Jeder Benutzer hat sein eigenes Benutzerprofil, ein sogenanntes „Roaming-User-Profile“ , er kann damit an jedem Computer in der Fakultät auf seine persönlicheBenutzeroberfläche und seine Daten zurückgreifen. Bei Abmeldung des Benut-zers vom System wird alles wieder zurück auf den Server geschrieben. Einmalin der Nacht wird dann ein Backup gemacht.

Configuration Management. Das System zum Rollout der Software inven-tarisiert jeden Computer. Es kann also genau festgestellt werden, welche Soft-ware sich auf welchem Rechner befindet. Durch ein Suchfunktion in dem Sys-tem wird manchmal geschaut, ob unerlaubte Software, wie zum Beispiel InstantMessenger, auf den Rechnern vorhanden ist. Bei Eintreten dieses Falls wird derBenutzer darüber aufgeklärt und die Software umgehend entfernt. Es gibt aberdennoch Informationen, die nicht automatisch in dem Inventarisierungsclientauftauchen, diese müssen nachträglich per Hand eingegeben werden. Zu die-sen Informationen gehören zum Beispiel der Standort des Rechners, an welcherNetzwerkdose der Rechner angeschlossen ist, außerdem wird die Inventarisie-rungsnummer, die die Universität verteilt, und das Anschaffungsdatum verwal-tet. Man weiß also zum Beispiel auch, an welchem Rechner welcher Bildschirmangeschlossen ist.Neben dem Domäne-Server existieren noch zwei weitere Server, ein Web-Serverund ein Backup-Server. Wenn der Domäne-Server ausfällt, steht die Arbeit inder gesamten Fakultät stillt. Alle drei Server werden durch ein Monitoring-System bewacht. Die EDV-Betreuer werden per SMS und per eMail über denAusfall eines Servers oder womöglich aller Server informiert.Im Allgemeinen gibt es keinen Überblick über alle Lizenzen, die in der Fakultätvorhanden sind. In dem vorhandenen Wiki kann nachvollzogen werden, welcherLehrstuhl 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 derGrundgedanke von ITIL aufgezeigt werden. Denn daran wird die Problematikfür die Einführung eines ITIL-konformen Service Supports an einer Universitätverdeutlicht.Im Vordergrund bei der Implementierung von ITIL steht, wie bereits erwähnt,im Allgemeinen die Verbesserung des IT-Service Managements. Dies ist in ers-ter Linie für Unternehmen besonders im Hinblick auf Wirtschaftlichkeit vonenormer Bedeutung. Insbesondere geht es dabei um die Verbesserung des Kun-denservices und der effizienten Strukturierung der IT-Infrastruktur. In einerUniversität haben solche Faktoren in der Regel einen nicht so hohen Stellen-wert.Wie in Kapitel 1.2 dargelegt wurde, basiert der Service Support nach ITILauf festgelegten Strukturen und Arbeitsabläufen. Es ist somit ein hohes Maßan Standardisierung und eine exakte Rollenverteilung resp. Arbeitsaufteilungnotwendig, um die Vorteile der ITIL-Prozesse zu nutzen. Entsprechend müs-sen dafür auch genügend Ressourcen in Form von Arbeitsplätzen, finanziellenMitteln etc. bereitgestellt werden.


Anhand des im vorangegangenen Abschnittes dargestellten IST-Zustandes desIT-Managements der beiden Fakultäten ist es offensichtlich, dass die Implemen-tierung eines ITIL-konformen Service Supports an der Universität Bielefeld sichals äußerst schwierig erweisen würde und nur mit einem großem Arbeits- undKostenaufwand zu realisieren wäre.Im einzelnen zeigt sich die Problematik für eine Einführung von ITIL-konformenProzessen bereits bei der allgemeinen Zusammenarbeit der EDV-Abteilungender einzelnen Fakultäten. Im Grunde ist jede EDV-Abteilung autark und fürdie IT-Struktur der jeweiligen Fakultät verantwortlich. Die Probleme, die mitdiesem Sachverhalt zusammenhängen, werden im Verlauf dieses Abschnittes an-hand der verschiedenen Prozessen des Service Supports näher erläutert. Einweiteres Umsetzungsproblem besteht darin, dass auf Grund der geringen per-sonellen Größe der einzelnen EDV-Abteilungen die Mitarbeiter sich fast alleAufgaben teilen und es dadurch nicht möglich ist, die verschiedenen Rollen re-sp. Aufgabenbereiche klar voneinander abzugrenzen.Im Folgendem werden aufbauend auf der Kritik mögliche Verbesserungsvor-schläge nach ITIL-Empfehlungen dargestellt. Es wird hierbei auf die ServiceSupport-Funktion Service Desk bzw. -Prozesse Incident Management, ProblemManagement, Change Management, Release Management und ConfigurationManagement im Einzelnen eingegangen. Es soll aber nicht das Ziel sein, sämtli-che Punkte des Service Supports nach ITIL auf die Universität zu übertragen,sondern nur solche, die sinnvoll erscheinen. Des Weiteren werden manche Punktezusammengefasst, da eine klare Abgrenzung auf Grund der geringen personellenGröße der Abteilungen oftmals nicht möglich ist.

Service Desk, Incident und Problem Management. Nach ITIL dientder Service Desk als zentrale Kommunikationsschnittstelle zwischen Usern undSupport. Die Architektur des Service Desks an der Universität Bielefeld ent-spricht dem eines lokalen Service Desk. Dies lässt sich damit begründen, dassjede Fakultät eine eigene EDV-Abteilung beinhaltet und diese als Ansprechpart-ner für die jeweiligen Fakultätsmitarbeiter dient. Somit ist gewährleistet, dassauf Probleme, Fragen, Anregungen etc. seitens der User schnell reagiert werdenkann. Aber diese Struktur verhindert auch eine Zusammenarbeit zwischen denFakultäten. Wünschenswert wäre ein virtueller Service Desk, um die Koope-ration der Fakultäten zu verbessern. Insbesondere die Implementierung einergemeinsamen Configuration Management Database wäre wichtig, dies wird sichnoch im Verlauf dieses Abschnittes zeigen.Ein weiterer wichtiger Punkt ist die Aufnahme eines Incidents und dessen Prio-risierung bzw. Klassifizierung. An der Universität sind sachliche Gründe bei derBearbeitung eines Incidents oftmals nicht das Hauptkriterium. Vielmehr erfolgtdie Klassifizierung häufig anhand personenbezogenen Gründen. Wünschenswertwäre eine ITIL-konforme Priorisierung, bei der Dringlichkeit und Auswirkungdes Problems maßgebende Kriterien sind.Als ein weiterer kritischer Punkt ist in diesem Zusammenhang die Bearbeitungvon Incidents zu sehen. Wird zum Beispiel von einem User der Fakultät fürWirtschaftswissenschaften ein bisher unbekanntes Problem bzw. Fehler einerSoftware der entsprechenden EDV-Abteilung gemeldet, kann die Problembehe-bung unter Umständen sehr aufwendig sein, da man erst die Gründe des Fehlerssuchen muss, um die entsprechende Lösung zu erarbeiten. In diesem Zusammen-


hang besteht die Möglichkeit, dass eine andere Fakultät einen ähnlichen Vorfallhatte und diesen bereits gelöst hat. Somit hat die EDV-Abteilung der Wirt-schaftswissenschaften einen unnötigen Mehraufwand. Denn wäre der Abteilungdas Problem bekannt gewesen, hätten sie den Fehler schneller beheben können.Im Kontext des Service Supports nach ITIL wäre einen Fakultäts übergreifendeConfiguration Management Database (CMDB) von Vorteil, um einen solchenMehraufwand zu vermeiden. Dadurch hätte man eine Plattform, auf der dieEDV-Mitarbeiter ihre erarbeiteten Lösungen, auch im Rahmen des ProactiveProblem Managements, für bestimmte Probleme den anderen Fakultäten zurVerfügung stellen können. Dies könnte zum Beispiel in Form eines Wikis ge-schehen. Um die Suche nach einer Lösung für den Benutzer zu erleichtern, wärees vorteilhaft, wenn das Wiki mit einer Volltextsuche ausgestattet wäre.Mit Hilfe einer solchen Datenbasis könnte auch ein weiteres Problem gelöstwerden. Denn auf Grund der Tatsache, dass es sich bei den Mitarbeitern zumGroßteil um studentische Hilfskräfte handelt und diese meistens nur über einenbegrenzten Zeitraum in der EDV-Abteilung arbeiten, herrscht eine hohe Mitar-beiterfluktuation und damit geht häufig Wissen verloren. Um diesen Problementgegenzuwirken, wäre es von Vorteil, anstatt zwei oder drei studentischenHilfskräften eine Vollzeitkraft anzustellen und zusätzlich mit Hilfe einer Daten-basis das Wissen nachhaltig zu sichern. Die Voraussetzung dafür ist zum einendie Bereitschaft der Mitarbeiter, ihr Wissen zu teilen, und zum anderen dieDokumentation jeglicher Incidents. In einem Unternehmen kann dies beispiels-weise durch Abmahnung gewährleisten werden, in der Universität gestaltet sichdies oftmals als schwierig, da entsprechende Sanktionierungsmaßnahmen keineWirkung haben.Abschließend lässt sich für die Bereiche Service Desk, Incident Management undProblem Management festhalten, dass die Implementierung einer gemeinsamenDatenbasis in der Universität ein wichtiger Fortschritt wäre. Sie sollte aber nichtnur als reine Wissensdatenbank fungieren, sondern darüber hinaus als Mittel deraktiven Kommunikation zwischen den verschiedenen Fakultäten.

Change Management und Release Management. Das Ziel eines ITIL-konformen Change Managements und Release Managements ist die Implemen-tierung von autorisierter Software und Hardware mit Hilfe standardisierter Ver-fahren. Dies gestaltet sich an der Universität Bielefeld auf Grund der autarkenFakultäten als äußerst schwierig.Im Bereich der Software lässt sich für die Universität festhalten, dass es keineeinheitliche Softwarestandards für die Fakultäten gibt. Das HRZ stellt zwar stan-dardisierte Softwarepakete bereit, doch jede Fakultät erweitert das Software-Bundle um fakultätsinterne Software. Dadurch besitzt jede Fakultät eigeneSoftwarestandards, die auf den fakultätsinternen Computern installiert werdenund von den jeweiligen EDV-Abteilungen betreut werden. Infolgedessen ist esschwierig, einen einheitlichen Standard zu realisieren. Eine Lösungsansatz fürdie Problematik könnte eine Definitive Software Library (DSL) sein, die vondem HRZ verwaltet werden könnte. Mit Hilfe dieses Konzeptes könnte danndie Software von dem HRZ zentral verteilt werden. Die Wartung der Softwareobliegt dann auch dem HRZ, welches dann auch die entsprechenden Rolloutsdurchführt. Welche Programme auf der DSL installiert werden, müsste dann inAbsprache mit den einzelnen Fakultäten festgelegt werden. Dieses Lösungskon-


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. DieFakultäten haben, wie in Abschnitt 1.3.1 und 1.3.2 gezeigt wurde, unterschied-liche Verfahren für die Verwaltung von Softwarelizenzen. Dadurch besteht dieGefahr, dass manche Fakultäten überlizenziert und andere unterlizenziert sind.Eine mögliche Lösung wäre der Erwerb von Campuslizenzen für die gängigsteSoftware, wie Microsoft Windows oder Microsoft Office.Im Bereich der Hardware empfiehlt das HRZ Standard-Computer für die Uni-versität. Es ist aber keine zwingende Vorgabe, dementsprechend gibt es eineVielzahl von unterschiedlichen Systemen. Um diesen Umstand zu begegnen,sollten zwingend geltende Richtlinien für die Beschaffung von Computern inden Fakultäten der Universität eingeführt werden. Die Informationen, der IT-Infrastruktur der jeweiligen Fakultäten, sollten dann in der Configuration Ma-nagement Database (CMDB) gespeichert werden. Diese kann dann als Informa-tionsdatenbank für die Hardware dienen.Ein weiteres Problem bei der Beschaffung der Hardware ist die Frage der Not-wendigkeit. Oftmals werden für Lehrstühle neue Computer beschafft, obwohlderen „alte“ Geräte noch ausreichend sind. Aus diesem Grund sollte an jederFakultät ein Change Advisory Board (CAB) eingeführt werden. Dieses solltedann über die Zweckmäßigkeit einer teureren Anschaffung bestimmen.Es zeigt sich, dass besonders im Hinblick der Softwareverwaltung, Lizenzierungund Hardwareverwaltung Handlungsbedarf an der Universität Bielefeld besteht.

Configuration Management. Die wesentliche Aufgabe des ConfigurationManagement ist die Bereitstellung von Informationen mit Hilfe einer Daten-bank. Anhand der bereits genannten Kritikpunkte ist die Implementierung ei-ner Configuration Management Database (CMDB) in die IT-Infrastruktur derUniversität Bielefeld die wichtigste Empfehlung. Sie soll als Wissensdatenbank,Informationsdatenbank für Hardware, Mittel der Kommunikation und DSL dereinzelnen Fakultäten dienen. Es ist in diesem Zusammenhang empfehlenswert,dass die Verwaltung der CMDB dem HRZ obliegt. Die Abbildung 1.12 stelltein mögliches Lösungskonzept28 der Funktionsweise der CMDB und der DSLan der Universität Bielefeld dar.

CMDB+DSL

HRZ

Rollout

Informationen

Rollout

Informationen

Fakultät Wirtschafts-

wissenschaften

Fakultät Rechts-

wissenschaften

Abbildung 1.12: Funktionsweise der CMDB und der DSL.

Zusammenfassend lässt sich festhalten, dass eine vollständige Implementierungeines ITIL-konformen Service Support-Prozesses an der Universität Bielefeld

28Aus Gründen der Übersicht wird das Konzept nur mit zwei Fakultäten dargestellt.


nicht realisierbar ist. Die Gründe dafür sind vielfältig, zum Beispiel spricht dievorhandene IT-Infrastruktur dagegen, ein weiterer wichtiger Punkt ist die ge-ringe Größe der einzelnen EDV-Abteilungen. Diese wären nur mit einem großenAufwand zu ändern, die damit zusammenhängenden Kosten würden aber denNutzen nicht rechtfertigen. Auch die Bereitschaft zur Veränderung und der Ko-operation der einzelnen EDV-Abteilungen spielen bei der Einführung von ITILeine wichtige Rolle, diese sind jedoch nicht im ausreichenden Maße vorhanden.Trotz dieser Gründen sollte aber versucht werden, einige Ideen von ITIL auf-zugreifen und diese in der Universität umzusetzen. Hierzu gehört zum Beispieldie Implementierung einer Configuration Management Database (CMDB) undeiner Definitive Software Library (DSL).

1.4 Fazit„Mein Computer stürzt dauernd ab.“, „Ich habe keinen Zugriff auf die Daten-bank.“, „Mein alter Computer kann mit seiner noch älteren Software diesesProblem nicht lösen.“ Wir haben nun gesehen, dass ITIL für solche Incidentsresp. Problems immer einen Prozess auf Basis des Best Practice-Konzeptes zurLösung vorschlägt. Daher löst ITIL Probleme nicht, sondern zeigt Mittel undWege auf, Probleme zu bewältigen. Wie umfangreich die Incidents bzw. Pro-blems und die damit verbundene Struktur des Service Supports ist, wurde inAbschnitt 1.2 mehr als deutlich.Das Ziel der ausführlichen Darstellung war es, die Schwierigkeit der Implemen-tierung eines ITIL-konformen Service Supports und die Komplexität der An-forderungen an die jeweiligen Prozesse darstellen zu können. Allerdings gibtAbschnitt 1.2 auch zu verstehen, dass ITIL mit dem Service Support ein Pro-blemlösungskonzept zur Verfügung stellt, das den Kunden resp. den User injeglicher 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 Betrieb-sablauf gewährleisten können. Somit sind die Vorteile von ITIL nicht von derHand zu weisen.In den Abschnitten 1.3.1 bzw. 1.3.2 wurde dann zunächst auf den IST-Zustandder Fakultät für Wirtschaftswissenschaften und der Fakultät für Rechtswissen-schaft der Universität Bielefeld eingegangen. Hierbei wurden mit Hilfe einesbereits vorab ausgearbeiteten Fragenkatalogs29 Interviews mit den zuständi-gen EDV-Mitarbeiter geführt. Anschließend wurden die Interviews zusammen-gefasst und separat abgehandelt. Hier war der Aufbau der einzelnen Abschnitteidentisch mit dem Abschnitt 1.2, in dem die theoretische Struktur des ServiceSupports vorgestellt wurde.In dem Abschnitt 1.3.3 kamen Kritik und Empfehlungen hinsichtlich des IST-Zustandes der Fakultäten in Bezug auf einen ITIL-konformen Service Support zuihrer Geltung. Hier wurde zum Beispiel festgestellt, dass die jeweiligen Fakultä-ten autark voneinander arbeiten und dies zu einem unnötigen Mehraufwand beieiner Problemlösung führen kann. Weitere Probleme sind die fehlende Kommu-nikationsbereitschaft der Fakultäten untereinander, die Unflexibilität gewisserMitarbeiter und die unökonomische Betrachtungsweise der Universität. Auchhierzu wurden im Abschnitt 1.3.3 diverse Vorschläge gemacht, die die Probleme

29Siehe Anhang.


an der Universität Bielefeld nicht lösen, aber zumindest die Situation verbessernwürden.Am Anfang dieser Arbeit stellte sich die Frage, ob der von ITIL vorgeschlageneService Support wirklich so sinnvoll ist. Grundsätzlich lässt sich diese Frage miteinem „Ja“ beantworten. ITIL bietet tatsächlich mit dem Service Support einegute Möglichkeit, auf operativer Ebene des serviceorientierten IT-Managementseffizient zu arbeiten. Diese Tatsache ist allerdings nicht weiter verwunderlich,da die vorgeschlagenen Funktionen und Prozesse sich bereits in der Praxis be-währt haben. Als „Allheilmittel“ sämtlicher User-Probleme kann ITIL nichtverstanden werden. Es gibt lediglich die Richtung und die Organisation derProblemlösung vor, die Incidents bzw. Problems des Users zu behandeln.Die durchzuführenden Prozesse und die damit verbundene Qualität der Prozesseliegen im Aufgabenbereich der zuständigen EDV-Mitarbeiter. Aber die in dieserArbeit wichtigste Frage, ob sich ITIL bzw. ein ITIL-konformer Service Supportwirklich für jeden lohnt, muss mit „Nein“ beantwortet werden. ITIL ist vorallem für große Unternehmen von Interesse, da sich hier mit Hilfe von ITILeine bessere Übersicht in der Problembewältigung und somit ein reibungslosererBetriebsablauf im Unternehmen gewährleisten lassen. Auch Unternehmen, die inder IT-Branche tätig sind, werden eine Umsetzung von ITIL im eigenen Betriebkaum hinterfragen. Doch der Versuch, ITIL zum Beispiel an einer Hochschule,wie die Universität Bielefeld, umzusetzen, ist, wie bereits aus Abschnitt 1.3ersichtlich, nur begrenzt sinnvoll.Dies hat verschiedene Gründe. Zum einen sind da die unterschiedlichen Aus-richtungen der jeweiligen Unternehmungen zu nennen. Während ein Unterneh-men eher monetäre Ziele verfolgt, sind Forschung und Entwicklung im Bereichder Wissenschaft sowie Ausbildung von Wissenschaftlern die vorrangigen Zieleeiner Universität. Dies wurde auch im Verlauf dieser Arbeit deutlich. Zum an-deren sind die doch teilweise undurchsichtigen Strukturen ein weiteres Problem,welches eine Einführung von ITIL erschwert. Im Vergleich zu einem Unterneh-men, in dem eine klare Organisation unabdingbar für das Bestehen in der freienMarktwirtschaft ist, wird in der Universität zwar nicht darauf verzichtet, aberauch nicht viel Wert gelegt. Zum Schluß ist noch die personelle Problematik, dieebenfalls eine Barriere für ITIL darstellt, zu nennen. Somit ist von einer Umset-zung 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 ServiceSupport in seinen Grundzügen eine sehr gute Möglichkeit zur Gewährleistungeines reibungslosen Betriebsablaufes und zur Bewältigung von IT-Problemendarstellt. Aus diesem Grund sollte die Universität den Grundgedanken von ITILaufnehmen und auf seine spezielle Ausrichtung resp. Bedürfnisse auslegen.


1.5 Fragebogen

Prozess FrageIncident Management 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 kategori-siert und priorisiert, vor allem wie wird Priorität definiert?Wie werden Incidents aufgenommen, dokumentiert und ausgewer-tet? Welche Informationen werden aufgenommen?(Incident Re-cords)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 undSupport Informationen in Form von speziellen Dokumentmanage-mentsystemen oder Wissensdatenbanken?Gibt es eine Klassifizierung zwischen bekannten Fehlern und Pro-blemen?Werden die bekannten Fehler in einer eigenen Datenbank (KnownError Database)?Gibt es schnelle, kurzfristig verfügbare Lösungsmöglichkeiten zumUmgang von Fehlern (Workarounds)?Treten Eskalationsfälle auf?

Problem Management 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 ermit-telt?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 geschiehtdas?Werden alle Prozessschritte zur Behebung überwacht und nach-verfolgt?Werden definierte Methoden ein, um Anzahl und Schwere vonStörungsmeldungen nachhaltig zu senken? (Pro-Aktives ProblemManagement)

Change Management Gibt es standardisierte Änderungsschritte? Werden alle Ände-rungsvorhaben geprüft, genehmigt und geordnet?Gibt es ein Change Advisory Board, dem die Entscheidungsgewaltobliegt?

Release Management Wird sichergestellt, dass durch eine Änderung an einer Stelle keineStörungen oder andere Beeinträchtigungen an einer anderen Stelleneu verursacht werden?Gibt es qualitätsgesicherte Standards und Grundkonfigurationenzur Installation von IT-Systemen?


Prozess FrageRelease Management Ist das Change Management in das Release Management einge-

bunden?Existiert ein BackUp-System bzw. Repository?Wird die ordnungsgemäße Durchführung der Änderungen organi-siert, überwacht und dokumentiert?Werden bei Änderungen an Systemkomponenten alle wichtigenDaten gesichert und alle Komponenten gründlich getestet?

Configuration Mana-gement

Gibt es eine Datenbank für bekannte und gelöste Probleme?

Gibt es gesicherte Informationen bzgl. Lizenzen und Hersteller-support?Gibt es Verfahren zur Beschaffung, Verwaltung, Verfolgung undBewertung von Hardware- und Softwareinventars?Werden die Konfiguration aller IT-Komponenten (Kommunikati-on, Netzwerk, Hardware, Software) an zentraler Stelle dokumen-tiert?

Allgemein Sind die Aufgaben und Zuständigkeiten klar abgegrenzt? Gibt eseinen Manager?Werden Kennzahlen und Statistiken über Störungsverläufe ge-führt? Welche Kennzahlen gibt es?Erfolgt die Softwareverteilung und der Aufbau von Rechnern au-tomatisiert?Wie sehen die Tools für die einzelnen Geschäftsprozesse aus?


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


Kapitel 2

ITIL-Zertifizierung nachISO/IEC 20000Eine Darstellung des Standards und des Zertifi-zierungsprozesses

Julia-Vanessa Stork, André Kröger, Christopher Uhrig

2.1 Einleitung

Mit ITIL steht IT-Dienstleistern eine detaillierte Sammlung von Best Practi-ce Empfehlungen für die Gestaltung der Arbeitsabläufe im IT Service Mana-gement zur Verfügung. Anhand der in ITIL definierten Prozesse können dieIT-Infrastruktur und die IT-Dienstleistungen übersichtlich und nachvollziehbarorganisiert und kontinuierlich verbessert werden. Die damit einhergehende ge-steigerte Servicequalität können Organisationen nach außen hin kommunizie-ren, indem sie sich als „ITIL-konform“ bezeichnen. Allerdings ist diese Aussagenicht nachprüfbar, da ITIL kein offizieller Standard ist. Es ist nicht möglich,eine Organisation ITIL-zertifizieren zu lassen. Nur Einzelpersonen können einZertifikat erwerben (ITIL Foundation, ITIL Service Manager, ITIL Practitio-ner). Der Standard ISO/IEC 20000 schließt diese Lücke. Es handelt sich dabeium einen international anerkannten Standard, in dem die Anforderungen an dasIT Service Management einer Organisation zur Erlangung einer Zertifizierungformell dokumentiert sind. Da ITIL die Basis dieses Standards bildet, kann miteinem Zertifikat die Konformität mit dem ITIL Rahmenwerk belegt werden.Der Standard kann dazu verwendet werden, die Service-Qualität zu überwachenund zu optimieren, als Referenzwert für IT Management Services, als Basis füreine unabhängige Zertifizierung und damit als Beleg für die Fähigkeit, Serviceszu erbringen, die den Kundenbedürfnissen entsprechen. Die Anforderungen desStandards stellen einen Branchenkonsens für Qualitätsstandards bei IT Ser-vice 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 Marktfor-schungsunternehmen Gartner davon aus, dass bis Ende 2008 mindestens 60% derrelevanten Beschaffungsvorhaben der öffentlichen Verwaltung und mindestens30% des privaten Sektors eine ISO/IEC 20000 Zertifizierung verlangen werden.[Gar06]Ziel dieser Arbeit ist es, den Standard ISO/IEC 20000 mit seinen Anforde-rungen an das Service Management von IT-Organisationen darzustellen sowieMöglichkeiten seiner praktischen Umsetzung und den Ablauf der Zertifizierungaufzuzeigen. Es soll die Frage beantwortet werden, inwiefern sich für eine Organi-sation die Umsetzung des Standards oder die Zertifizierung lohnt. Dazu werdenzunächst im Kapitel 2.2 die Entwicklung des Standards und seine Beziehung zuITIL sowie die Anforderungen an die verschiedenen IT Service Management-Prozesse vorgestellt. Das Kapitel 2.3 behandelt die Zertifizierung. Von der Ent-scheidungsfindung und Planung über die Umsetzung der Vorgaben des Stan-dards bis hin zum Ablauf der Zertifizierung wird hier Schritt für Schritt derWeg zum Zertifikat dargestellt. Im Kapitel 2.4 erfolgt eine Gegenüberstellungder Vor- und Nachteile der Zertifizierung nach ISO/IEC 20000. Abschließendwerden im Kapitel 2.5 die wichtigsten Ergebnisse zusammengefasst.

2.2 Der Standard ISO/IEC 20000

2.2.1 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 Ma-nagement festgelegt. Im Jahr 2002 wurde eine überarbeitete Version unter derBezeichnung BS 15000-1:2002 herausgegeben. Ergänzt wurde dieses Dokumentim Jahr 2003 durch den BS 15000-2:2003, den „Code of Practice for ServiceManagement“. Dieser zweite Teil des BS 15000 enthielt Empfehlungen und An-leitungen zu den Anforderungen des ersten Teils. Im Mai 2005 entschieden dieMitglieder der ISO (International Organization for Standardization) und derIEC (International Electrotechnical Commission), den BS 15000 in einen neu-en internationalen Standard zu überführen. Am 15. Dezember 2005 wurde derStandard ISO/IEC 20000 veröffentlicht. Dieser enthält nur geringfügige Än-derungen gegenüber dem Originaltext des BS 15000. Seit der Einführung desISO/IEC 20000 findet nur noch eine Zertifizierung nach diesem Standard statt.Die für den BS 15000 ausgegebenen Zertifikate verloren nach dem 15. Juni 2007ihre Gültigkeit [SMF06, S. 11f.]. Aufgrund dessen ist in dieser Arbeit nicht vomBS 15000 die Rede, auch wenn dieser in der einschlägigen Literatur häufig ver-wendet wird, sondern es wird ausschließlich auf den Standard ISO/IEC 20000Bezug genommen.

2.2.2 Beziehung zu ITIL

Der Standard ISO/IEC 20000 und ITIL ergänzen sich gegenseitig. Der Stan-dard spezifiziert die Anforderungen an das IT Service Management und ITILdokumentiert zu den Prozessen des IT Service Management Best Practice Emp-fehlungen. Während der Standard kurz gefasst die Kriterien für eine Zertifizie-

Eine Darstellung des Standards und des Zertifizierungsprozesses 55

ISO/IEC20.000

Specification

ISO/IEC20.000

Best Practices

ITILIT Infrastructure Library

Betriebsinterne Abläufe / Arbeitsabläufe

Abbildung 2.1: Spezialisierungsgrad der ISO 20000 Richtlinien. Quelle: EigeneDarstellung in Anlehnung an [SMF06].

rung festlegt, beschreiben die ITIL-Bücher die möglichen Wege, diese Kriterienzu erfüllen. Der Standard ISO/IEC 20000 behandelt alle Service ManagementProzesse, die in den ITIL Publikationen „Service Support“ und „Service De-livery“ sowie „Security Management“ dokumentiert sind. Darüber hinaus wer-den noch einige zusätzliche Prozesse sowie übergeordnete Anforderungen an einManagement-System definiert. Der Zusammenhang zwischen ISO/IEC 20000und ITIL ist in Abbildung 2.1 dargestellt. ITIL stellt eine Sammlung von BestPractice Empfehlungen für die betriebsinternen Arbeitsabläufe im IT-Bereich ei-ner Organisation dar. Die formelle Spezifikation des Standards ISO/IEC 20000wurde auf der Basis von ITIL entwickelt und enthält spezielle verbindliche Vor-gaben für eine Zertifizierung. Ergänzt wird der Standard um den Code of Prac-tice, der Leitlinien und Empfehlungen für die Umsetzung enthält. Dieser istvergleichbar mit den Best Practice Empfehlungen von ITIL, bezogen auf denRahmen des formellen Standards.

2.2.3 Struktur

Der Standard ISO/IEC 20000 besteht aus zwei Dokumenten. Der erste Teil20000-1 „Specification“ definiert verbindliche Vorgaben („shall“) für das ITService Management, die für eine Zertifizierung vollständig umgesetzt werdenmüssen. Der zweite Teil 20000-2 „Code of Practice“ enthält Leitlinien und Emp-fehlungen („should“) zur Umsetzung der Anforderungen des ersten Teils. Ab-weichungen von diesen Erläuterungen der Best Practices sind erlaubt, für eineerfolgreiche Zertifizierung sind sie nicht zwingend erforderlich. Grundlage fürdie Zertifizierung ist Teil 1 des Standards.Beide Teile sind inhaltlich gleich strukturiert. Einem einführenden Kapitel zumAnwendungsbereich des Standards folgt die Einführung und Definition von


Relationship Processes

Business Relationship Management

Supplier Management

Resolution Processes

Incident Management

Problem Management

ReleaseProcesses

Release Management

Information Security Management

Budgeting and Accounting for IT services

Service Level Management

Service Reporting

Capacity Management

Service Continuity and Availibility Management

Service Delivery Processes

Control Processes

Configuration ManagementChange Management

Abbildung 2.2: Service Management Processes. Quelle: Eigene Darstellung inAnlehnung an [Spe05].

Fachbegriffen. Die Kapitel 3 bis 5 behandeln das Management-System. Zu-nächst werden die Anforderungen in Bezug auf die Verantwortlichkeiten, dieDokumentation und die Kompetenz der Mitarbeiter definiert. Dann erfolgt ei-ne Beschreibung der „Plan-Do-Check-Act“-Methode, die zur Planung und Im-plementierung des Service Managements sowie neuer oder geänderter Serviceseingesetzt werden kann. In den Kapiteln 6 bis 10 werden insgesamt 13 ServiceManagement Prozesse definiert, die in die 5 übergeordneten Gruppen ServiceDelivery-Prozesse, Relationship-Prozesse, Lösungsprozesse, Steuerungsprozesseund Release-Prozesse aufgeteilt sind (siehe Abbildung 2.2). Die Anforderungendes Standards sind unterteilt in Ziele (Objectives) und definierte Anforderungenzur Erfüllung dieser Ziele (Requirements).

2.2.4 Anforderungen an ein Management-System

Das vorgegebene Ziel ist ein Management-System mit Grundsätzen und Struk-turen, die eine effektive Implementierung und Verwaltung aller IT Services er-möglichen [Spe05, S. 3].Um dieses Ziel zu erreichen, müssen die Rollen und Verantwortlichkeiten desManagements klar definiert sein. Dazu gehört die Festlegung von Grundsät-zen, Plänen und Zielen des Service Managements sowie die Beschreibung, wiediese Ziele erreicht werden sollen. Für die Koordination und die Verwaltungsämtlicher Services ist eine verantwortliche Person zu ernennen und es ist einRisiko-Management zu implementieren. Die Anforderungen der Kunden müs-sen ermittelt und Maßnahmen, diesen auch gerecht zu werden, müssen getroffenwerden. In festgelegten Abständen sind Service Management Reviews durchzu-führen, um eine kontinuierliche Angemessenheit und Effektivität sicherzustellen[Spe05, S. 3f.]. Für jede Rolle im Service Management muss festgelegt werden,


Business

requirements

Customer

requirements

Request for new / changed

services

Other processese.g. business,

supplier, customer

Service Desk

Other teams,e.g. security,IT operations

Business

results

Customer

satisfaction

New / changed

services

Other processes,e.g. business,

supplier, customer

Team and people

satisfaction

Management responsibility

Manage services

PLANPlan servicemanagement

CHECKMonitor, measure

and review

ACTContinual

improvement

DOImplement service

management

Abbildung 2.3: Regelkreislauf. Quelle: Eigene Darstellung in Anlehnung an[Spe05].

welche Kompetenzen zur effektiven Erfüllung der Aufgaben benötigt werden. DieMitarbeiter müssen wissen, wie sie zur Erreichung der festgelegten Ziele beitra-gen. Desweiteren müssen sie sich der Bedeutung ihrer Aktivitäten bewusst sein[Spe05, S. 4]. Um dieses sicherzustellen, sollte ein Weiterbildungsplan erstelltwerden [Cod05, S. 3]. Eine weitere Anforderung ist die Bereitstellung von Doku-mentationen 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 dieAktualität sichergestellt ist. Zu den Dokumentationen gehören die Grundsätzeund Pläne, die Abläufe und Prozesse sowie sonstige erforderliche Aufzeichnun-gen [Spe05, S.4].

2.2.5 Planung und Implementierung des Service Manage-ments

Zur Umsetzung der Implementierung des Service Managements gibt der Stan-dard die „Plan-Do-Check-Act“-Methode vor [Spe05, S. 4]. Dabei handelt es sichum ein Modell, bei dem vier Schritte in einem Kreislauf immer wieder durchlau-fen werden (siehe Abbildung 2.3). Die Festlegung der Ziele und notwendigen Pro-zesse (Plan), die Durchführung der Implementierung (Do), die Überprüfung derProzesse hinsichtlich der Grundsätze, Ziele und Anforderungen (Check) sowiedas Ergreifen von Maßnahmen zur kontinuierlichen Verbesserung der Prozesse(Act). Durch diese Methode wird eine ständige Qualitätsverbesserung sicherge-stellt.Bei der Planung des Service Managements müssen der Umfang des Service Ma-nagements, die zu erreichenden Ziele sowie die auszuführenden Prozesse definiertwerden. Es ist zu beschreiben, wie die Prozesse in Aktivitäten umgesetzt wer-


den und wie das Risikomanagement durchgeführt wird. Darüber hinaus sind dieVerantwortlichkeiten, Ressourcen, Hilfsmittel und das Budget anzugeben. AllePläne müssen durch einen Review überprüft und kommuniziert werden [Spe05,S. 5].Die Implementierung des Service Management Plans hat durch die Zuweisungvon Verantwortlichkeiten, Budgets und Hilfsmitteln sowie durch die Koordina-tion 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 Prozessezu dokumentieren und einzuhalten. Bezüglich des Fortschritts müssen Berichteangefertigt werden [Spe05, S. 6].Es müssen Methoden zur Überwachung der Prozesse eingeführt werden, diebelegen können, dass die Ziele durch die Prozesse erreicht werden können. Inregelmäßigen Abständen sind Reviews durchzuführen, um die Service-Qualität,die Kundenzufriedenheit und die Auslastung der Ressourcen zu überprüfen. Esmuss ein Prüfprogramm erarbeitet werden, das den Status und die Bedeutungdes Prozesses, die Ergebnisse vorheriger Prüfungen und die Auswahl der Prüferberücksichtigt. Die Ergebnisse sind mit den beteiligten Personen zu kommuni-zieren [Spe05, S. 6].Für die Verbesserung der Service-Aktivitäten muss alles, was nicht mit den Ser-vice Management Plänen übereinstimmt, entfernt werden. Dafür sind Rollenund Verantwortlichkeiten klar zu definieren. Für die Bearbeitung von Service-Verbesserungen muss ein Prozess definiert und ein Service-Verbesserungsplanerstellt werden. Diese müssen die Informationen zu den Verbesserungen und diefestgelegten Ziele sowie die Methoden zur Identifizierung, Planung, Kommunika-tion und Implementierung der Verbesserungsmaßnahmen beinhalten. Danebensind die Methoden zur Messung, Berichterstattung und Sicherstellung der Aus-führung und Zielerreichung der Aktionen anzuführen. Vor der Durchführungeiner Verbesserungsmaßnahme muss die Servicequalität als Vergleichsmaßstabdokumentiert werden [Spe05, S. 7].Die Planung und Implementierung neuer oder geänderter Services muss im Rah-men eines formellen Change-Management erfolgen. Dafür ist eine Analyse derkostenbezogenen, organisatorischen, technischen und wirtschaftlichen Auswir-kungen notwendig. Die zu erstellenden Pläne müssen die Rollen und Verant-wortlichkeiten für die Implementierung, Ausführung und Betreuung und dieÄnderungen an bestehenden Grundsätzen und Services beinhalten. Die Anfor-derungen an die Mitarbeiter sind zu dokumentieren und die Positionen zu be-setzen. Es wird festgelegt, welche Prozesse, Maßnahmen, Methoden und Toolseingesetzt werden und wie viel Zeit und Geld dafür zur Verfügung steht. Ab-schließend sind messbare Ergebnisse für die Ausführung vorzugeben [Spe05, S.7f.].

2.2.6 Anforderungen an Service-Management-ProzesseFür alle Prozesse müssen das Ziel und der Ablauf des Prozesses, die Rollen undVerantwortlichkeiten, die Messung definierter Kennzahlen, die Schnittstellen-Spezifikation sowie die kontinuierliche Verbesserung ersichtlich und beweisbarsein [SMF06, S. 23].

Service Level Management Für das Service Level Management gibt derStandard als Ziel vor, die Service-Level zu definieren, zu vereinbaren, aufzu-


zeichnen und zu verwalten.Jeder Service, der angeboten wird, muss in einer Service-Level-Vereinbarung(service level agreement) zusammen mit dem zugehörigen Ziel dokumentiertwerden. Der gesamte Serviceumfang sollte in einem Servicekatalog dargestelltwerden, der vom Change-Management zu verwalten ist und sowohl Kunden alsauch Mitarbeitern jederzeit zugänglich sein sollte [Cod05, S. 8]. Unterstützen-de Vereinbarungen und Lieferantenverträge sind ebenfalls aufzuzeichnen. Durchregelmäßige Reviews ist sicherzustellen, dass die Vereinbarungen stets auf demneuesten Stand sind. Die Service-Level müssen überwacht werden und es hat eineBerichterstattung zu den festgelegten Zielen zu erfolgen. Notwendige Maßnah-men 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 Kommunikationzu gewährleisten und damit informationsbezogene Entscheidungen möglich zumachen.Jeder Service Report muss eine Beschreibung seines Zweckes, der Zielgruppeund Details über die Datenquelle enthalten. Es ist festzuhalten, inwiefern dieerbrachten Services die definierten Ziele erreicht haben und es müssen Leis-tungsmerkmale aller Prozesse aufgezeichnet werden. Es sind Zufriedenheits-und Trendanalysen durchzuführen und nach besonderen Ereignissen sind Leis-tungsberichte anzufertigen. Managemententscheidungen und Korrekturen müs-sen umgehend dokumentiert und kommuniziert werden [Spe05, S. 9].

Service Continuity und Availability-Management Zielvorgabe für dasService Continuity und Availability-Management ist die Sicherstellung der Ser-vice-Kontinuität und Verfügbarkeit, so dass Vereinbarungen gegenüber demKunden unter allen Umständen eingehalten werden können.Um diese zu erreichen, müssen auf Basis der Service-Level-Vereinbarungen Ver-fügbarkeitspläne und Servickontinuitätspläne entwickelt und regelmäßig gepflegtund getestet werden. Dabei sind Risiko-Bewertungen durchzuführen und zu do-kumentieren. Anforderungen an Zugriffsrechte und Reaktionszeiten sowie andie Verfügbarkeit der Systemkomponenten müssen definiert werden und es istsicherzustellen, dass diese erfüllt werden. Die Verfügbarkeit muss gemessen undaufgezeichnet werden. Ist diese außerplanmäßig nicht gegeben, müssen die Ursa-chen analysiert und angemessene Gegenmaßnahmen eingeleitet werden [Spe05,S. 9]. Es sollte eine enge Zusammenarbeit mit dem Change-Management er-folgen, um die Auswirkungen von Changes auf die Verfügbarkeit und Service-Kontinuität zu kontrollieren. Wo dies möglich ist, sollten potenzielle Problemeprognostiziert werden, damit vorbeugende Maßnahmen getroffen werden können[Cod05, S. 11f.].

Finanzplanung und Kostenrechnung für IT Services Ziel der Finanz-planung und Kostenrechnung für IT Services ist es, einen Plan für die finanziellenRessourcen zu erstellen und die Kosten für die Bereitstellung von Services zuberechnen.Für die Finanzplanung und Kostenrechnung, für die Kontrolle und Genehmi-gung des Budgets sowie für die Ermittlung und Zuordnung von indirekten Kos-


ten müssen klare Grundsätze und Prozesse definiert werden. Kostenrechnungs-prozesse sollten die Nutzung der finanziellen Ressourcen aufzeigen und die Er-mittlung der Stückkosten ermöglichen [Cod05, S. 14]. Die Kosten sind so detail-liert zu planen, dass die Kontrolle des Budgets und die Entscheidungsfindungeffektiv gestaltet werden können. Die Kosten müssen hinsichtlich des Budgetsüberwacht und dokumentiert werden, Finanzprognosen sind zu überprüfen unddementsprechend müssen die Kosten verwaltet werden [Spe05, S. 10].

Capacity-Management Zielvorgabe für das Capacity-Management ist dieSicherstellung der Verfügbarkeit ausreichender Kapazitäten, so dass die mit demKunden vereinbarte Nachfrage jederzeit befriedigt werden kann.Im Rahmen des Capacity-Managements muss ein Kapazitätsplan erstellt undgepflegt werden, um die Service-Kapazität zu überwachen, anzupassen und eineangemessene Kapazität bereitstellen zu können. Dafür sind Methoden, Abläufeund Techniken zu identifizieren und anzuwenden. Der Kapazitätsplan muss Pro-gnosen über zukünftige Anforderungen sowie Einflüsse durch neue technologi-sche Entwicklungen und Auswirkungen externer Veränderungen berücksichtigen[Spe05, S. 10].

Information-Security-Management Ziel des Information-Security-Mana-gements ist eine effektive Verwaltung der Informations-Sicherheit innerhalb allerService-Aktivitäten.Grundsätze zur Informations-Sicherheit müssen definiert und kommuniziert wer-den. Dazu sind Sicherheitskontrollen einzuführen, die die Anforderungen derGrundsätze implementieren, und die die Risiken bezüglich des Zugriffs auf denService oder auf die Systeme verwalten. Eine Dokumentation der Kontrollenmuss die Durchführung und Wartung der Kontrollmaßnahmen beschreiben unddie Risiken nennen, auf die sie sich beziehen. Für sämtliche Informationsträgersollte eine Bestandsaufnahme, eine Kategorisierung entsprechend der Bedeutungfür den Service und eine Bewertung der erforderlichen Sicherheitsstufe durch-geführt werden [Cod05, S. 16]. Der externe Zugriff auf Services und Systemeist durch geeignete formelle Vereinbarungen zu regeln. Treten sicherheitsrele-vante Störungen auf, sind in Übereinstimmung mit dem Incident-ManagementBerichte und Aufzeichnungen zu erstellen. Es müssen Abläufe definiert sein, diedafür sorgen, dass jede sicherheitsrelevante Störung überprüft wird, und dassentsprechende Maßnahmen getroffen werden [Spe05, S. 10f.].

Business-Relationship-Management Ziel des Business-Relationship-Man-agements ist es, den Kunden und seine geschäftsfördernde Abläufe zu verstehenund auf dieser Basis eine gute Beziehung zu dem Kunden herzustellen und zupflegen.Das Business-Relationship-Management muss alle Kunden und die an den Ser-vices beteiligten Personen identifizieren und dokumentieren. Zusammen mit denKunden müssen mindestens einmal pro Jahr Reviews durchgeführt werden, umGeschäftsanforderungen, erbrachte Leistungen und Changes in Service-Umfang,Service-Level-Vereinbarungen und Verträgen zu diskutieren. Es sind regelmäßi-ge Meetings abzuhalten und zu protokollieren, um die Leistung, die erreichtenZiele, die Schwierigkeiten und die Aktionspläne zu erörtern. Für den Umgang


mit Beschwerden muss ein formeller Ablauf festgelegt und mit den Kunden ab-gestimmt werden. Alle Beschwerden sind aufzuzeichnen und zu untersuchen.Es müssen Maßnahmen ergriffen und dokumentiert werden und die Beschwer-de muss formell abgeschlossen werden. Die Kundenzufriedenheit ist regelmäßigzu messen und zu dokumentieren. Für die Erfassung des Feedbacks und dieReaktion darauf muss ein Prozess erstellt werden [Spe05, S. 11f.]. Schwankun-gen im Zufriedenheitsgrad sollten auf ihre Ursachen hin untersucht werden. DieErgebnisse der Feedback- und der Beschwerdeanalyse fließen in den Service-Verbesserungsplan ein. Verbesserungs-Empfehlungen sollten an das Service De-livery Team weitergereicht werden [Cod05, S. 18].

Lieferanten-Management Zielvorgabe für das Lieferanten-Management istdie Sicherstellung einer nahtlosen Bereitstellung von qualitativ hochwertigenServices.Für die Verwaltung der Lieferanten müssen Prozesse implementiert und doku-mentiert werden und jedem Lieferanten ist ein zuständiger Vertragsmanager zu-zuordnen. Die Services müssen definiert werden und die Lieferantenverträge sindmit den Service-Level-Vereinbarungen abzustimmen und durch Reviews regel-mäßig zu überprüfen. Werden Lieferungen indirekt über einen Hauptlieferantenbezogen, muss dieser nachweisen, dass die nachgeordneten Lieferanten die Ver-tragsanforderungen erfüllen. Die Rollen und Beziehungen zwischen den Haupt-lieferanten und den Lieferanten mit Unterverträgen sind klar zu dokumentieren.Es muss ein Prozess festgelegt werden, der Vertragsänderungen, Vertragsstrei-tigkeiten und die Beendigung des Service regelt. Die Leistungen sind zu überwa-chen, zu überprüfen und aufzuzeichnen. Sie müssen mit den Service-Level-Zielenverglichen werden und es sind Verbesserungsmaßnahmen zu identifizieren undaufzuzeichnen. Diese dienen als Input für den Service-Verbesserungsplan [Spe05,S. 12].

Incident-Management Ziel des Incident-Managements ist die Reaktion aufService-Requests und die schnellstmögliche Wiederherstellung des vereinbartenService.Sämtliche Incidents müssen aufgezeichnet werden und es sind Verfahren anzu-wenden, um die Auswirkungen von Incidents zu verwalten. Diese Verfahren müs-sen die Aufzeichnung der Incidents und Prioritätsabfolgen, die Klassifizierungund Aktualisierung, die Auswirkungen auf Geschäftsabläufe sowie die Lösungund den formellen Abschluss definieren. Für bedeutende Incidents ist ein Pro-zess zu entwickeln, der die Klassifizierung und Behandlung vorgibt. Der Kundemuss über den Fortschritt der gemeldeten Incidents oder Service-Requests in-formiert werden. Er ist vorab zu benachrichtigen, wenn sein Service-Level nichterreicht werden kann. Sämtliche Mitarbeiter des Incident-Managements müssenauf die relevanten Informationen zugreifen können [Spe05, S. 13].

Problem-Management Ziel des Problem-Managements ist es, durch Iden-tifizierung und Analyse der Ursache von Incidents und einer Verwaltung derProbleme bis zum Abschluss die Unterbrechungen des Geschäftsprozesses aufein Minimum zu reduzieren.Alle identifizierten Probleme müssen aufgezeichnet werden und es sind Ver-fahren anzuwenden, um die Auswirkungen von Incidents und Problemen zu


identifizieren, zu minimieren oder zu vermeiden. Diese Verfahren müssen dieAufzeichnung aller Probleme, deren Klassifizierung und Aktualisierung sowiederen Lösung und formellen Abschluss definieren. Die Problembehebung ist zuüberwachen und es sind Reviews und Berichte dazu anzufertigen. PotenzielleProbleme sind durch vorbeugende Maßnahmen zu reduzieren. Aktuelle Infor-mationen von bekannten Fehlern und behobenen Problemen müssen für dasIncident-Management verfügbar gemacht werden und notwendige Änderungensind an das Change-Management weiterzuleiten. Identifizierte Verbesserungs-maßnahmen müssen aufgezeichnet und dem Service-Verbesserungsplan hinzu-gefügt werden [Spe05, S. 13].

Configuration-Management Ziel des Configuration-Managements ist dieDefinition und Steuerung der Service- und Infrastrukturkomponenten sowie dieAufrechterhaltung korrekter Konfigurationsinformationen.Für die Planung des Change- und Configuration-Managements muss ein integra-tiver Ansatz verfolgt werden. Es ist ein Konfigurationsplan erforderlich, in demdie Konfigurations-Elemente und deren Grundbestandteile aufgeführt werden.Darin sind die Eigenschaften der Elemente und deren Beziehung zueinander zudefinieren. Es müssen Methoden zur Identifizierung, Kontrolle und Überwachungvon Service- und Infrastrukturkomponenten entwickelt werden. Informationenzu 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 Systemenund Services sind Prozesse zur Steuerung der Konfigurationen erforderlich. AlleKonfigurations-Elemente sind in einer Configuration-Management-Datenbank(CMDB) aufzuzeichnen. Diese muss aktiv gepflegt werden, um deren Zuverläs-sigkeit und Aktualität sicherzustellen. Der Zugriff auf die Datenbank ist striktzu kontrollieren. Informationen zum Status der Konfigurations-Elemente, derenVersionen, Standorte und damit zusammenhängende Änderungen und Proble-me müssen den Personen zur Verfügung stehen, die diese benötigen. Es sindProzesse zur Überprüfung der Konfigurationen zu implementieren, die Mängelaufzeichnen, 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. Al-le Requests for Changes sind aufzuzeichnen und zu klassifizieren. Es müssenBewertungen bezüglich der Risiken, der Auswirkungen und des Geschäftsnut-zens durchgeführt werden. Changes sind zu genehmigen, zu überprüfen undkontrolliert zu implementieren. Es muss ein Zeitplan mit Details zu allen Chan-ges erstellt werden, deren Implementierung genehmigt wurde. Die Implemen-tierungszeiten sind allen beteiligten Parteien mitzuteilen. Es müssen Richtlini-en 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. Nachder Implementierung ist ein Review durchzuführen, dessen Ergebnisse in denService-Verbesserungsplan einfließen. Die Aufzeichnungen von Changes müs-sen regelmäßig analysiert werden, um sich häufende Changes, wiederkehrendeChange-Kategorien, Trends und andere relevanten Informationen zu ermitteln[Spe05, S. 14f.].


Release-Management-Prozess Ziel des Release-Management-Prozesses istdie Bereitstellung, Verteilung und Verfolgung eines oder mehrerer Changes ineinem Release in der Live-Umgebung.Der Release-Management-Prozess sollte in die Configuration und Change Ma-nagement Prozesse integriert werden. Grundsätze, die die Häufigkeit und denTyp der Releases angeben, sind zu dokumentieren und zu vereinbaren. Es mussein Plan für das Release von Services, Systemen, Software und Hardware erstelltwerden. Die Einführung (Rollout) des Release ist zwischen allen beteiligten Par-teien zu vereinbaren und von allen Parteien zu genehmigen. Das Release mussso konzipiert und implementiert werden, dass die Integrität der Hardware undSoftware während der Installation, Bearbeitung, Verpackung und Auslieferunggewährleistet ist. Vor der Bereitstellung müssen alle Releases in einer kontrollier-ten Testumgebung erstellt und getestet werden. Es sind Richtlinien und Abläufefür Notfall-Releases zu erstellen und es muss definiert werden, wie nicht erfolg-reiche Releases rückgängig gemacht oder entfernt werden. Es sind Messungenbezüglich des Erfolges von Releases durchzuführen [Spe05, S. 15].

2.3 Die Zertifizierung

2.3.1 Entscheidungsfindung

Grundlage für die Entscheidung für eine Zertifizierung nach ISO/IEC 20000ist die Durchführung einer Standortbestimmung des IT-Bereiches und die Er-arbeitung eines Maßnahmenplanes für die notwendigen Anpassungen. Daraufaufbauend kann im Fall einer Entscheidung für die Einführung der Anforde-rungen des Standards ein Projektplan für die Umsetzung der Prozesse erstelltwerden.Ein geeigneter Weg für die Standortbestimmung ist die Durchführung einesAssessments. Dabei wird der konkrete Reifegrad aller IT-Service-Management-Prozesse ermittelt und es werden Empfehlungen abgeleitet, was für eine erfolg-reiche Zertifizierung noch zu tun ist. Für die Durchführung des Assessmentssollte ein geeignetes Beratungsunternehmen beauftragt werden. Es ist ein Pro-jektteam mit einem Projektleiter und den Prozessverantwortlichen zusammen-zustellen. Die Vorgehensweise des Assessments sollte mit dem Beratungsunter-nehmen in einem Vorgespräch geklärt werden. Dabei werden die Prozesse bereitsgrob durchgesprochen und die Prozessdokumentationen werden gesichtet. Dieentsprechenden Dokumente sollten rechtzeitig vorbereitet werden. Es muss eindetaillierter Zeitplan für die Durchführung erstellt werden und die Mitarbeiterdes IT-Bereiches sind darüber zu informieren, so dass sie zu den vereinbar-ten Zeiten verfügbar sind und die erforderlichen Dokumente griffbereit haben.Das eigentliche Assessment wird in Form von Interviews durchgeführt. Dabeiwird aufgezeichnet, was bei den Prozessen jeweils bereits vorhanden ist. DasBeratungsunternehmen erstellt dazu einen Bericht, der für jeden Prozess einenkonkreten Reifegrad benennt und Empfehlungen ausspricht, welche nächstenSchritte in welcher Reihenfolge unternommen werden sollten. Abschließend wer-den die Ergebnisse des Assessments allen IT-Mitarbeitern präsentiert [Boc06,S. 38 f.].Es ist sinnvoll, sich von dem Beratungsunternehmen einen Maßnahmenplan er-stellen zu lassen. Auf der Grundlage der Ergebnisse des Assessments werden


darin alle für eine Zertifizierung notwendigen Maßnahmen und Umsetzungser-fordernisse aufgelistet. Der Plan ist nach den Prozessen zu strukturieren und esist eine Prozesslandkarte als Übersicht zu erstellen [Boc06, S. 49f.].

2.3.2 Prozessumsetzung

Das folgende Kapitel thematisiert die praktische Umsetzung der Anforderungendes ISO/IEC 20000. Es wird beschrieben, wie die vorgegebenen Prozesse im Be-trieb realisiert werden können und was dabei zu beachten ist. Behandelt werdennur die über ITIL hinausgehenden Teile, also das Management-System, die Pla-nung und Implementierung des Service-Managements, das Service Reporting,das Information-Security-Management, das Business-Relationship-Managementsowie das Lieferanten-Management. Auf die Umsetzung der auf ITIL basieren-den Prozesse wird ausführlich in den Arbeiten der anderen Gruppen eingegan-gen.

Management-System Das Management-System ist ein Rahmenwerk, dasdie Politik, die Organisation und die Strategie des IT-Bereichs festlegt. Voraus-setzung für die Umsetzung ist, dass eine ausformulierte Unternehmensstrategieexistiert. Daraus abzuleiten ist eine IT-Strategie, deren wesentliche Bestandteilein der Abbildung 2.4 dargestellt werden. Rahmenbedingungen dieses Strategie-konzepts sind die Unternehmensumgebung und die vorhandenen IT-Strukturensowie die Vorgaben zur Effektivität und Effizienz. Die Aufgaben, Ziele und Prio-ritäten sind in einem Leitbild zu definieren. Die Philosophie, wie diese umzu-setzen sind, wird in einer Anwendungsstrategie formuliert. Darauf aufbauendwerden in einer Systemstrategie und einer Organisationsstrategie festgelegt, wiedie IT strukturiert und organisiert wird. Die Ressourcenstrategie beantwortetdie Frage, mit welchen Mitteln die vorgegebenen Ziele erreicht werden sollen.Die IT-Strategie ist schriftlich auszuformulieren und an die Mitarbeiter zu ver-breiten [Boc06, S. 81].Die Ziele und Strategien heruntergebrochen auf die einzelnen Prozesse ergebenzusammengefasst die Service-Management-Politik. Darin ist zu beschreiben, aufwelche Art und Weise die IT-Services erbracht werden sollen. Die konkretenZiele und Vorhaben für das kommende Geschäftsjahr sind in einem Service-Management-Plan zu definieren. Es muss formuliert werden, wie man sicher-stellt, dass die Ziele auch erreicht werden und wie man gewährleistet, dass dieDokumente stets aktuell sind [Boc06, S. 72].In einem Dokument Management-System sind organisatorische Grundprinzipi-en sowie die Rollen und Verantwortlichkeiten für die Prozesse und Dokumentefestzulegen. Für die Umsetzung eines Risikomanagements ist ein Vorgehen zudefinieren, wie Risiken erkannt, erfasst und bewertet werden und wie Gegen-maßnahmen ergriffen werden. Aufzeichnungen über relevante Risiken könnenbeispielsweise in Form einer Risikomatrix, die Eintrittswahrscheinlichkeit undSchadenshöhe einander gegenüberstellt, geführt werden [Boc06, S. 76f.]. DieUmsetzung und die Wirksamkeit der Gegenmaßnahmen sind laufend zu über-wachen. Bei der Formulierung sämtlicher Dokumente ist zu beachten, dass diesenicht nur von Spezialisten verstanden werden müssen, und dass durch die Ver-wendung von konkreten Begriffen ein einheitliches Verständnis gewährleistetsein muss [Boc06, S. 81].


Abbildung 2.4: Strategiekonzept. Quelle: Eigene Darstellung in Anlehnung an[Boc06].

Eine weitere Aufgabe des Management-Systems ist die Bereitstellung von Do-kumentationen. Es sind standardisierte Abläufe zu definieren, wie Dokumentezu erstellen, zu ändern und zu archivieren sind. Von jeder Version eines Do-kumentes sollte eine Archivdatei erstellt werden und die Versionsführung solltedokumentiert werden. Für alle Abläufe muss es klare Verantwortlichkeiten geben[Boc06, S. 107f.].

Planung und Implementierung des Service-Managements Zur Umset-zung der Planung und Implementierung des Service-Managements ist die inKapitel 2.2.5 vorgestellte „Plan-Do-Check-Act“ -Methode zu verwenden. DieImplementierung von Services anhand dieser Methode bewirkt einen kontinu-ierlichen Verbesserungsprozess (KVP) der Leistungen. Es muss ein Prozessma-nager (KVP-Manager) bestimmt und eine Prozessbeschreibung erstellt werden.Wenn bei der Überprüfung der implementierten Prozesse Nonkonformitäten mitden festgelegten Zielen und Anforderungen auftreten, hat der Prozessmanagerdie Aufgabe, eine Bewertung durchzuführen. Bei den Nonkonformitäten kannes sich um einen Verstoß gegen die Anforderungen oder um Verbesserungspo-tential 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 Handlungs-bedarf abzuleiten und entsprechende Maßnahmen zu ermitteln. Diese werdenin einem Maßnahmenkatalog gesammelt, der mit einem Tool verwaltet werdensollte. Darin sind die Zuständigkeiten und der Zeitrahmen für die Umsetzungfestzulegen. Der KVP-Manager hat die ergriffenen Maßnahmen zu überprüfenund zu bewerten. Alle Mitarbeiter müssen über die Maßnahmen informiert wer-den [Boc06, S. 86f.].


Service Reporting Aufgabe des Prozesses Service Reporting ist es, einePlattform für eine effektive Kommunikation innerhalb des IT-Bereiches zur Ver-fügung zu stellen. Zur Umsetzung ist ein Prozessmanager zu bestimmen, derfestlegt, welche Berichte verfasst und verbreitet werden sollen. Sämtliche erfor-derlichen Reports können beispielsweise auf einer Intranetseite dargestellt undverlinkt werden [Boc06, S. 103]. Auf diese Weise entsteht eine Sammlung vonBerichten, auf die jederzeit zugegriffen werden kann. Dabei muss deutlich wer-den, welche Person für den Report verantwortlich ist, an wen er sich richtet, aufwelcher Datenquelle er basiert und in welchem Rhythmus er erstellt wird. DieseInformationen können zur übersichtlichen Strukturierung in die Darstellung derBerichte übernommen werden. Darüber hinaus ist es sinnvoll, die Berichte nachden Prozessen zu kategorisieren, durchgängig zu nummerieren und regelmäßigauf ihre Aktualität zu überprüfen [Boc06, S. 103f.].Die Mitarbeiter des IT-Bereichs haben in diesem Zusammenhang verschiedeneAufgaben zu erfüllen. Grundsätzlich hat sich jeder über die für ihn relevantenBerichte zu informieren. Die Prozessverantwortlichen müssen Prozessänderun-gen und die Archivierung von Dokumenten bekannt machen und für die Ak-tualisierung 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 Infor-mation-Security Management ist eine Sicherheitspolitik zu definieren. Darin sollfür jeden verständlich die Grundhaltung zum Thema Sicherheit festgelegt wer-den, um ein einheitliches Verständnis davon im Unternehmen zu etablieren.Es sollte formuliert werden welche Bedrohungen existieren, was grundsätzlichwie schutzbedürftig ist, welches Maß an Schutz angemessen ist, inwiefern Vor-kehrungen hinsichtlich der IT-Systeme und des Personals nötig sind und wiedie Kontrolle und Verbesserung der Schutzmechanismen sichergestellt werdenkann. Die Sicherheitspolitik ist mit der Geschäftsleitung abzustimmen und imUnternehmen 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 benennenund es ist zu beschreiben, wie damit umzugehen ist. Diesbezüglich müssen dieMitarbeiter geschult und für das Thema Sicherheit im Allgemeinen sensibilisiertwerden. Alle Geschäftsprozesse des Unternehmens sind auf mögliche Sicherheits-risiken zu untersuchen. Die Eintrittswahrscheinlichkeit eines Security Incidentsund die potentielle Schadenshöhe müssen bewertet werden, so dass man Priori-täten erkennen kann. Aus dieser Beurteilung sind Gegenmaßnahmen abzuleiten[Boc06, S. 134f.].

Business-Relationship-Management Für den Umgang mit Kunden sindklare Regeln zu definieren. Es ist sinnvoll, Anfragen nach einer standardisiertenVorgehensweise zu bearbeiten und Vorlagen für die strukturierte Durchführungvon Kundenterminen zu erstellen. Die Kommunikation mit den Kunden ist zudokumentieren. Als zentrale Ansprechpartner für alle IT-Fragen können Ge-schäftsfeldbetreuer bestimmt werden, die die Kundenanforderungen verwalten.In regelmäßigen Abständen sind Reviews mit den Kunden durchzuführen, umdie erbrachten Services und Änderungswünsche zu diskutieren. Für den Umgang


mit Beschwerden muss ein Prozess erstellt werden, der sicherstellt, dass alleBeschwerden aufgezeichnet, bearbeitet und abgeschlossen werden. Die Kunden-zufriedenheit ist regelmäßig durch eine Umfrage zu überprüfen. Die erhobenenInformationen sollen helfen, die Leistungen zu verbessern [Boc06, S. 121f.].

Lieferanten-Management Es sind Grundsätze zu formulieren, wie die Zu-sammenarbeit mit den Lieferanten aussehen soll. Jedem Lieferanten wird ein ver-antwortlicher Manager zugeordnet, der als zentraler Ansprechpartner alle Vor-gänge im Blick hat. Es sollte definiert werden, wer was bestellen darf und welcheVerträge durch Juristen geprüft werden müssen. Die Lieferantenverträge sindan die Anforderungen der Service-Level-Vereinbarungen anzupassen. Es sollteein laufendes Monitoring von Leistungen und Preisen durchgeführt werden. Inregelmäßigen Gesprächen müssen mit den Lieferanten die erbrachten Leistun-gen und Maßnahmen zur Verbesserung der Zusammenarbeit diskutiert sowiedie zukünftigen Strategien abgestimmt werden. Für den Vertragsabschluss, Än-derungen und die Auflösung von Verträgen, insbesondere bei Streitfällen, sindProzesse zu definieren. Es empfiehlt sich, alle Festlegungen dieses Prozesses ineinem zentralen Dokument festzuhalten [Boc06, S. 114f.].

2.3.3 Fragenkatalog zur Prozessumsetzung

Die in diesem Kapitel wiedergegebenen Fragen jedes einzelnen Prozesses stelleneine Art Checkliste für eine Zertifizierung nach ISO/IEC 20000 dar. Sie zeigenAnhaltspunkte für die jeweiligen Prozessmanager auf und dienen der Aufde-ckung von Schwachstellen innerhalb des jeweiligen Prozesses.

Management-System

• Ist ein IT-Service-Management, eine Strategie, bzw. eine Zielsetzung vor-handen?

• Sind genügend Ressourcen zur Planung, Überwachung, Durchführung undVerbesserung einzelner Handlungen vorhanden?

• Werden die Zuständigkeiten und die hinreichenden Kompetenzen für alleRollen bestimmt?

• Sind Verantwortliche und Zuständigkeiten zur Erstellung und Aktualisie-rung von Dokumenten vorhanden?

• Ist der Schulungsbedarf der Mitarbeiter so geregelt, dass diese ihre Auf-gaben kompetent und effektiv erfüllen?

• Ist eine Identifikation von Kundenanforderungen vorhanden und wird die-se von den Mitarbeitern erfüllt?

• Sind sich die Mitarbeiter des Unternehmens über die Orientierung anKundenanforderungen bewusst, d.h. sehen sie die Relevanz der Service-Erbringung?

• Sind die einzelnen Prozesse aufeinander abgestimmt?


Planung und Implementierung des Service-Managements

• Werden die Prozesse des IT-Service-Managements im Unternehmen iden-tifiziert?

• Besteht eine klare Vision bzw. klare Leitlinien des Managements zur Über-prüfung des Service-Managements-Plans?

• Ist die Zuständigkeit in Fragen zur Serviceverbesserung eindeutig festge-legt?

• Legt der Service-Management-Plan den Bereich des Service-Managementsin dem Unternehmen fest und zeigt dieser verschiedene Zielerreichungenund Schnittstellen zwischen den Service-Management-Prozessen auf?

• Stimmen die Prozessziele mit denen des Service-Management-Plans über-ein?

• Sind alle Verbesserungsmöglichkeiten überprüft, dokumentiert und freige-geben?

• Besteht die Möglichkeit, Verbesserungsmaßnahmen überhaupt zu identi-fizieren, die mehr als einen einzelnen Prozess betreffen?

• Gibt es Management-Reviews, die überprüfen, ob Konformität der An-forderungen an das Service-Management mit den Vorgaben des ISO/IEC20000 besteht.

• Wurden alle Non-Konformitäten behoben?

• Werden durch das Unternehmen Handlungen durchgeführt, die Verbes-serungen identifizieren, ggf. Strategien und Ziele überarbeiten, sowie dieUmsetzung aller freigegebenen Maßnahmen sicherstellen?

• Wird die Objektivität bei einem internen Audit sichergestellt, d.h. dasAuditoren nicht ihre eigene Arbeit auditieren?

Service-Level-Management

• Werden die angebotenen Services in einem Service-Level-Agreement defi-niert und dokumentiert?

• Ist eine Berichterstattung und Überprüfung sowie aktuelle Informationenund Entwicklungen über die erreichten Service-Levels vorhanden?

• Werden die Gründe, wenn ein Ziel nicht erreicht wird, korrigiert und über-prüft?

• Werden verschiedene Reviews durchgeführt?


Service Reporting

• Steht eine detaillierte Beschreibung der einzelnen Berichte, die Informa-tionen über verwendete Datenquellen, Zwecke und Identitäten enthalten,zur Verfügung?

• Sind alle erforderlichen Berichte und Dokumente vorhanden und stets ak-tuell?

• Werden erlangte Ergebnisse und Optimierungspotentiale in den Entschei-dungen des Managements berücksichtigt?

Service-Continuity-Management

• Sind Pläne vorhanden, die die Services nach einem Ausfall und den Nor-malzustand des Systems wieder herstellen?

• Wenn ein normaler Zugang zum Büro nicht möglich ist, sind dann dieCDMB, die Kontaktliste und der Notfallplan für die befugten Mitarbeiterzugänglich?

• Ist ein proaktives Vorgehen, die Zusammensetzung der Teams im Notfallund 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 Ge-schäftsanforderungen aktualisiert?

• Wird die Verfügbarkeit des benötigten Services für den Geschäftsprozesssichergestellt?

• 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 alleKomponenten vorhanden?

• Besteht eine effiziente Kontrolle und Genehmigung der Finanzen?

• Reichen die Finanzen aus, um eine zukünftige Kontrolle und Entschei-dungsfindung durchzuführen?

• Erfolgt ein kontinuierlicher Vergleich der anfallenden Kosten mit dem vor-handenen Budget und werden Maßnahmen bei einer erheblichen Abwei-chung eingeleitet?


Capacity-Management

• Ist ein Kapazitätsplan vorhanden und wird dieser kontinuierlich aktuali-siert?

• Werden Request for Changes erstellt?

• Werden vom Kapazitätsmanagement zukünftige Geschäftsanforderungen,vorhersehbare Auswirkungen neuer Technologien und Techniken, Auswir-kungen externer Veränderungen, aktuelle Leistungs- und Kapazitätsanfor-derungen 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 festge-legt?

• Sind effiziente Sicherheitsmaßnahmen zur Implementierung dieser Vorga-ben 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 verschiedeneRisiken und Wartung dieser genommen?

• Wird untersucht, ob Changes ein Sicherheitsrisiko darstellen?

• Werden alle Security-Incidents erkannt, überprüft, entsprechend dem Inci-dent-Prozess abgearbeitet und werden entsprechende Maßnahmen ergrif-fen?

Business-Relationship-Management

• Werden die Stakeholder der einzelnen Services identifiziert und schriftlichfestgehalten?

• Sind Verantwortliche für die Bestimmung der Kundenzufriedenheit fest-gelegt?

• Ist das Unternehmen auf zukünftige Änderungen der Geschäftsanforde-rungen der Kunden vorbereitet?

• Werden regelmäßige Besprechungen mit den Kunden zur Standortbestim-mung durchgeführt und dokumentiert?

• Sind für Reklamationen von Kunden entsprechende Prozesse eingeführt?


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 Haupt-und Unterlieferanten?

• Werden, um die vertraglichen Verpflichtungen und die geschäftlichen Not-wendigkeiten einzuhalten, größere Reviews mindestens einmal im Jahrdurchgeführt?

• Gibt es Verfahren für die Überwachung der Leistung interner und externerLieferanten?

Incident-Management

• Besteht eine Aufzeichnung aller Incidents und eine nachgelagerte Ticke-terfassung?

• Enthält der Prozess die Aktivität der Aufzeichnung, Priorisierung, Beur-teilung der Geschäftsauswirkungen, Klassifikation, Aktualisierung, Eska-lation, Lösung und ein formaler Abschluss?

• Werden alle offenen Tickets ausgewertet und die Kunden über die Ent-wicklung ihrer gemeldeten Incidents informiert?

• Erfolgt eine eindeutige Zurechenbarkeit der Tickets zu einem Mitarbeiterund zu einem Kunden?

• Wie wird mit der Eskalation umgegangen?

• Ist die Übergabe der Incidents ins Problem-Management eindeutig mög-lich?

Problem-Management

• Erfolgt eine Dokumentation der auftretenden Probleme durch die Verant-wortlichen?

• Wird die Prävention von Fehlern als ein relevanter Teil des Problem-Managements angesehen?

• Werden die Probleme eindeutig klassifiziert?

• Erfolgt eine Weiterleitung aller Verbesserungen und Veränderungen, dieIncidents und Fehler verhindern können, über das Change-Managements?

• Unterliegt die Wirksamkeit des Prozesses einer Überwachung und Über-prüfung?


Configuration-Management

• Sind Schnittstellen zur Anlagenbuchhaltung vorhanden?

• Existiert eine Begriffsabgrenzung eines Konfigurationselements (CI) undderen zugehörigen Komponenten?

• Werden durch das Configuration-Management Mechanismen zur Identifi-kation, Steuerungsmöglichkeiten und Versionsverfolgung bereitgestellt?

• Informiert das Configuration-Management das Change-Management überVeränderungen?

• Wird die Configuration Management Data Base (CMDB) überprüft undverwaltet, um Zuverlässigkeit und Genauigkeit zu garantieren?

• Erfolgen Audits zur CMDB?

Change-Management

• Werden Veränderungen des Services und der Infrastruktur in einem ange-messenen Umfang dokumentiert?

• Erfolgt eine Beurteilung sogenannter Veränderungsanträge hinsichtlich be-stimmter Risiken, Auswirkungen, Sicherheitskontrollen und finanziellerGegebenheiten?

• Existieren formelle Verfahren, die alle Changes hinsichtlich ihrer Aussichtauf Erfolg prüfen, kontrollierend einführen und genehmigen?

• Werden wiederkehrende Ergebnisse und relevante Informationen aufge-deckt?

• Gibt es bei der Einführung veränderter und neuer Services eine wirksamePlanung und Überprüfung durch das Change-Management?

• Befasst sich das Unternehmen bei einer Veränderung des Services mit Zeit-plänen, bestimmten Zuständigkeiten der Mitarbeiter, Kommunikation mitrelevanten Abteilungen, erwarteten Ergebnissen sowie Handlung bzgl. desKompetenz- und Schulungsbedarfs?

• Erfolgt eine Weitergabe der veränderten Ergebnisse an alle Mitarbeiterdes IT-Bereichs?

Release-Management

• Existiert eine Politik, die verschiedene Arten von Releases enthält?

• Besteht eine Absprache der Planung der Releases bzw. der Software undHardware mit dem Kunden?

• Werden Vorgehensweisen beschrieben, wie z.B. die Revidierung von nichterfolgreichen Releases erfolgt?

• Werden die Changes nach Ausbringung eines Releases auf dem aktuellemStand gehalten?


Assessment

Maßnahmenplan

Entscheidung

Prozessumsetzung

Internes Auditvor der Zertifizierung

Korrekturmaßmahmen

Zertifizierungsaudit

Zertifikat

Erforderliche Korrekturen

Abbildung 2.5: Der Weg zum Zertifikat. Quelle: Eigene Darstellung in Anleh-nung an [Boc06].

• Werden Erfolge und Misserfolge von Releases bewertet, gemessen und re-gelmäßig analysiert, um deren Folgen auf bestimmte IT-Tätigkeiten undGeschä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 derZertifizierungsprozess eingeleitet werden. Dieser beinhaltet die interne Auditie-rung und entsprechende Korrekturmaßnahmen unmittelbar vor der Zertifizie-rung sowie den eigentlichen Zertifizierungsaudit und die weitere Vorgehensweiseim Anschluss daran. Der Prozess wird in Abbildung 2.5 dargestellt.Das interne Audit stellt einen letzten Check vor der Zertifizierung dar, bei demerforderliche Korrekturen identifiziert werden sollen, um noch rechtzeitig ent-sprechende Maßnahmen einleiten zu können. Es wird überprüft, ob die Anfor-derungen des Standards ISO/IEC 20000 verstanden, umgesetzt und gelebt wer-den. Es ist zu empfehlen, dafür jenes Beratungsunternehmen zu beauftragen,das bereits das Assessment durchgeführt hat. Das interne Audit dauert norma-lerweise zwei bis drei Tage [Boc06, S. 233]. Es sind Besprechungsräume zu reser-vieren und sämtliche Dokumente zur Verfügung zu stellen. In Gesprächen mitdem IT-Management werden grundsätzliche Dinge geklärt, wie die Umsetzungdes Management-Systems. Die Prozessmanager müssen den jeweiligen Prozessbeschreiben und berichten, was bereits umgesetzt ist. Sämtliche erforderlichen


Prozessaufzeichnungen und Dokumente werden überprüft. Als Ergebnis erhältman einen Maßnahmenplan, was bis zur Zertifizierung noch umgesetzt werdenmuss. Es sollte genügend Zeit eingeplant werden, um die Korrekturmaßnah-men, die für eine erfolgreiche Zertifizierung zwingend erforderlich sind, bis zumZertifizierungsaudit durchführen zu können [Boc06, S. 239].

Der Zertifizierungsaudit wird durch eine offizielle Zertifizierungsstelle (Regis-tered Certificated Body) durchgeführt. Die Mitgliedsländer der InternationalOrganization for Standardization (ISO) verfügen über nationale Akkreditie-rungsstellen, die geprüften Zertifizierungsstellen das Recht übertragen, Organi-sationen nach ISO/IEC 20000 zu zertifizieren [SMF06, S. 17f.]. In Deutschlandzählt beispielsweise die TÜV SÜD Management Service GmbH zu den offiziellenZertifizierungsstellen. Dabei ist zu beachten, dass Prüfungsunternehmen keineBeratungsleistungen anbieten dürfen, um die Unabhängigkeit zu gewährleisten.

Die Anmeldung zur Zertifizierung sollte mindestens vier Monate vor dem ge-planten Termin erfolgen. Die Unterlagen dazu sind bei der Zertifizierungsstelleanzufordern. Es müssen Angaben zum Unternehmen und dem zu zertifizierendenBereich gemacht werden und es ist ein Termin aus den Vorschlägen der Zertifi-zierungsstelle auszuwählen. Spätestens einen Monat vor der Zertifizierung sindsämtliche erforderlichen Unterlagen bei der Zertifizierungsstelle einzureichen.Sobald der zeitliche Ablauf mit der Zertifizierungsstelle abgestimmt ist, sind dieRäumlichkeiten vorzubereiten und die Anwesenheit aller erforderlichen Perso-nen ist sicherzustellen. Es empfiehlt sich, die Mitarbeiter durch Schulungen undBewusstseinsbildung auf die Zertifizierung vorzubereiten, beispielsweise durchdie Teilnahme an einem ITIL-Foundation-Kurs [Boc06, S. 240f.].

Der Ablauf des Zertifizierungsaudits ähnelt dem des internen Audits bzw. desAssessments. Bei einem einführenden Gespräch mit allen Teilnehmern verschafftsich der Zertifizierer einen Überblick über die Aufgaben und Tätigkeiten underklärt den Ablauf der Zertifizierung. Es folgt ein Interview mit der IT-Führunghinsichtlich der Anforderungen an das Management-System und den kontinuier-lichen Verbesserungsprozess. Im Anschluss daran wird für jeden Prozess eine Be-fragung des zuständigen Prozessmanagers durchgeführt. Dabei wird zum einenkontrolliert, ob der Prozessmanager den Prozess auch wirklich versteht, undzum anderen wird die Umsetzung aller Anforderungen des Standards ISO/IEC20000 überprüft. Zum Abschluss trägt der Zertifizierer seine Erkenntnisse vorund gibt bekannt, ob er der Zertifizierungsstelle die Ausstellung des Zertifikatsvorschlägt. Die Zertifizierungsstelle trifft dann anhand dieses Vorschlags und derProtokolle des Audits eine Entscheidung [Boc06, S. 252f.].

Bei erfolgreicher Zertifizierung erhält der IT-Service-Provider das Zertifikat, under ist ermächtigt, das offizielle Zertifizierungslogo zu verwenden. Desweiterenwird er gesondert auf der Internetseite der Zertifizierungsstelle gelistet. DieserProjekterfolg sollte durch professionelles Marketing bekannt gemacht werden.Das Zertifikat hat eine Gültigkeit von drei Jahren. Danach findet ein Wieder-holungsaudit statt. Jährlich werden zudem Überwachungsaudits durchgeführt[SMF06, S.19f.]. Insofern ist nach der Zertifizierung besonders wichtig, dass dieProzesse im Unternehmen auch gelebt werden und eine kontinuierliche Weiter-entwicklung und Verbesserung nach dem KVP-Ansatz erfolgt. Dies kann durcheine regelmäßige Erfassung und Überprüfung der für die Prozesse etabliertenKennzahlen sichergestellt werden [Boc06, S. 270f.].


2.4 Beurteilung der Zertifizierung

Der IT-Service spielt bei der Kundenbetreuung eine wichtige Rolle. Die Um-setzung der Anforderungen des Standards ISO/IEC 20000 führt dazu, dass dieIT-Dienstleistungen effizient gesteuert werden und den Kundenbedürfnissen an-gepasst sind. Mit der Zertifizierung nach ISO/IEC 20000 durch eine offizielleunabhängige Zertifizierungsstelle kann somit eine hohe Servicequalität objektivnachgewiesen und den Kunden gegenüber belegt werden. Das ist insbesonderefür Unternehmen relevant, die das Outsourcing und die Verwaltung und vonIT-Services anbieten. Das Zertifikat kann als Marketing-Instrument verwendetwerden, um die Reputation am Markt zu erhöhen und damit die Wettbewerbsfä-higkeit zu steigern. Gegenüber Kunden, Kreditgebern, Aktionären, Mitarbeiternund öffentlichen Einrichtungen wird eine breite Vertrauensbasis geschaffen. Auf-grund der Aktualität der Thematik gilt ein zertifiziertes Unternehmen zudemals besonders innovativ [Boc06, S. 269].Firmenintern hat die Zertifizierung zur Folge, dass die IT-Mitarbeiter durchdie intensive Beschäftigung mit dem Thema ein besseres Verständnis von denProzessen, den Zielen und Strategien sowie von ihrer eigenen Rolle im Unterneh-men entwickeln. Es bilden sich eine gemeinsame Sprache und ein einheitlicherKenntnisstand von den Prozessabläufen. Durch Effizienzsteigerungen können dieKosten für die eingesetzten Systeme reduziert werden. Die unabhängige Beur-teilung des Reifegrads der Prozesse und des Service Managements bildet eineOrientierungshilfe und die Grundlage für den kontinuierlichen Verbesserungs-prozess [Boc06, S. 268f.].Allerdings ist bis zum Erhalt des Zertifikats ein langer Weg zurückzulegen, wiesich in den vorangegangenen Kapiteln gezeigt hat. Der Standard ISO/IEC 20000stellt hohe Anforderungen an Unternehmen und Prozesse. Dies gilt auch für Un-ternehmen, die ITIL-erfahren sind. Eine Vielzahl von Unternehmen beschränktsich bei der Einführung von ITIL auf nur wenige Prozesse, wie zum Beispieldas Incident-Management, das Change-Management oder das Configuration-Management. Voraussetzung für die Zertifizierung ist allerdings, dass alle vor-gegebenen Prozesse im Unternehmen umgesetzt sind. Es ist ein großer Aufwandzu betreiben, um dieses Ziel zu erreichen. Und da das Zertifikat nur eine be-grenzte Gültigkeit besitzt, fallen auch langfristig Aufwände an.Auch für Unternehmen, die zunächst keine Zertifizierung anstreben, stellt derStandard ISO/IEC 20000 eine wertvolle Informationsquelle und Leitlinie dar.Dies gilt insbesondere für Unternehmen, die ihr Handeln und Vorgehen auf dieITIL-Prinzipien abgestimmt haben und sich bei der Implementierung der Pro-zesse des IT Service Managements auf die ITIL-Richtlinien berufen. Wenn sichein Unternehmen an die Vorgaben des Standards ISO/IEC 20000 hält, kann essicher sein, dass seine IT-Dienstleistungen eine hohe Qualität besitzen. Der imStandard beschriebene kontinuierliche Verbesserungsprozess bietet die Möglich-keit, die Servicequalität regelmäßig zu überprüfen und ständig weiterzuentwi-ckeln.Unternehmen müssen die Einhaltung einer Vielzahl behördlicher Vorschriftenund Regelungen nachweisen. Besonders auf das IT Service Management und dieIT-Services beziehen sich viele der Vorschriften. Zu nennen ist das Sarbanes-Oxley-Gesetz und das HIPAA-Gesetz (Health Insurance Portability and Ac-countability Act) von 1996 aus den USA. Zum Nachweis der Einhaltung dieserVorschriften fordern Wirtschaftsprüfer bislang keine Zertifizierung für bestimm-


te Standards und Normen. Aufgrund seines Bezugs zur Qualität des IT ServiceManagements bietet sich der Standard ISO/IEC 20000 als internationaler Stan-dard zur Überprüfung der Einhaltung behördlicher Vorschriften im Rahmen vonWirtschaftsprüfungen an [BMC06, S. 5].Die Zertifizierung nach ISO/IEC 20000 wird sich für viele IT-Service-Anbietertrotz des hohen Aufwands lohnen. Ein offizielles Prüfsiegel nach internationalanerkannten Standards ist wohl der beste Qualitätsnachweis gegenüber denKunden. Bei der Auftragsvergabe im IT-Sektor wird eine Zertifizierung nachISO/IEC 20000 zunehmend zur zwingenden Voraussetzung. Unternehmen, diesich aufgrund einer Kosten-Nutzen-Analyse gegen die Zertifizierung und den da-mit verbundenen Wettbewerbsvorteil entscheiden, können den Standard in Er-gä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-Dienstleisterndie Möglichkeit, die Konformität mit dem ITIL Rahmenwerk objektiv zu bele-gen. Der Standard definiert verbindliche Vorgaben für das IT Service Manage-ment, die für eine Zertifizierung vollständig umgesetzt werden müssen. Es sindneben den auf ITIL basierenden Prozessen das Management-System, die Pla-nung und Implementierung des Service-Managements, das Service Reporting,das Information-Security-Management, das Business-Relationship-Managementsowie das Lieferanten-Management umzusetzen.Die Entscheidung für eine Zertifizierung nach ISO/IEC 20000 sollte auf derGrundlage einer Standortbestimmung des IT-Bereiches und eines dabei erarbei-teten Maßnahmenplanes mit notwendigen Korrekturen getroffen werden. Diepraktische Umsetzung der Anforderungen ist abhängig von den gegebenen Rah-menbedingungen sowie der Unternehmensstrategie und den Zielen. Der Codeof Practice des Standards stellt Leitlinien und Empfehlungen zur Umsetzungder Anforderungen zur Verfügung. Abweichungen von diesen Erläuterungen derBest Practices sind erlaubt, so dass das IT Service Management individuell aus-gestaltet werden kann. Der in der Arbeit dargestellte Fragenkatalog dient alsHilfestellung bei der Prozessumsetzung.Vor der Zertifizierung wird ein interner Audit durchgeführt, um letzte erforder-liche Anpassungen zu identifizieren. Sind die Korrekturmaßnahmen umgesetzt,kann der Zertifizierungsaudit durchgeführt werden. Dies erfolgt durch eine of-fizielle Zertifizierungsstelle in Form von Interviews. Dabei wird überprüft, obdie Anforderungen des Standards ISO/IEC 20000 verstanden, umgesetzt undgelebt werden. Erfüllt der IT-Service-Anbieter sämtliche Voraussetzungen, wirdein Zertifikat ausgestellt.Durch eine erfolgreiche Zertifizierung wird nachgewiesen, dass effiziente IT-Services angeboten werden, die den Kundenbedürfnissen entsprechen. Da in derGeschäftspraxis dieser Nachweis der Servicequalität zunehmend vorausgesetztwird, wird dadurch die Wettbewerbsfähigkeit gesteigert. Daneben erhöht sichdie Reputation des Unternehmens am Markt. Trotz des hohen Aufwands wirdsich daher für viele IT-Service-Anbieter die Zertifizierung nach ISO/IEC 20000lohnen. Und auch für Unternehmen, die keine Zertifizierung anstreben, bringtdie Umsetzung des Standards eine Reihe von Vorteilen mit sich.Die vorliegende Arbeit bezieht sich primär auf das Buch „ITIL Zertifizierung


nach BS 15000/ISO 20000“ von den Autoren Wolfgang Bock, Günter Macek,Thomas Oberndorfer und Robert Pumsenberger und auf den Standard ISO/IEC20000 selbst. Dies liegt daran, dass zum Zeitpunkt der Erstellung der Arbeitnoch keine weitere einschlägige Literatur zur Verfügung stand. Für Interessier-te an weiterer Literatur sind wir bei unserer Recherche auf folgende Büchergestoß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. Auf-lage, Zeewolde / Niederlande 2008.

• Implementing ISO/IEC 20000 Certification - The Roadmap. itSMF, VanHaren Publishing, 1. Auflage, Zeewolde / Niederlande 2008.



[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.: ITILZertifizierung nach BS 15000 / ISO 20000, Galileo Computing,1.Auflage, Bonn 2006.

[Cod05] International Organization for Standardization / InternationalElectrotechnical 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 - DasTaschenbuch, Van Haren Publishing, 1. Auflage, Zeewolde /Niederlande 2006.

[Spe05] International Organization for Standardization / InternationalElectrotechnical Commission: ISO/IEC 20000-1: Specification, 1.Auflage, Geneva / Schweiz 2005.

79

http://documents.bmc.com/products/documents/49/66/64966/64966.pdf

http://documents.bmc.com/products/documents/49/66/64966/64966.pdf

http://www.competence-site.de/itmanagement.nsf/5438155EE69CF678C125728B0042967B/$File/it-service-management_iso_20000.pdf




Kapitel 3

ITIL und IT-SicherheitSynergien zwischen Security Management und Ser-vice Support nutzen

Björn Borgmeier, Michael Bochenek, Tim Kattner

3.1 EinleitungSicherheit 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ängig-keit von der IT stetig wächst, nehmen ebenso Gefahren und Risiken für In-formationstechnologien zu. Die Bedrohungen sind vielfältiger Art und reichenvon 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 effizientesIT-Security Management zugenommen.Trotz dieser Entwicklung herrscht in vielen Fällen eine weit verbreitete Fehl-einschätzung über den eigenen Schutzbedarf bei den Unternehmen. Im Zugesinkender IT-Budgets werden Maßnahmen nur noch implementiert, sofern siedie Produktivität der Geschäftsprozesse erhöhen oder einen Wettbewerbsvorteilgenerieren. Die Tatsache alleine, dass in der Vergangenheit keine Sicherheitsvor-fälle erkannt wurden, bedeutete nicht, dass keine Vorlagen oder die Sicherheits-maß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 erfolgreichimplementiert worden sind und einen Großteil des Aufgabenspektrums abde-cken. Eine solche Best Practice Lösung ist ITIL. Der momentane Trend gehtdazu, IT-Prozesse gemäß ITIL neu zu entwickeln bzw. zu restrukturieren. Diesbietet einerseits die Möglichkeit Informationssicherheit vorteilhafter in die IT-Prozesse zu integrieren und andererseits eine bessere Arbeitsverteilung zwischenIT-Bereich und Security Management zu ermöglichen. Zudem bietet es die Chan-ce das Thema Sicherheit stärker in den Fokus zu rücken und diesbezüglich die

81

82 ITIL und IT-Sicherheit

Akzeptanz seitens der Unternehmensleitung zu erhöhen.[Bsi05, S. 12].Ziel dieser Arbeit soll es zum einen sein, einen kurzen Überblick über das ThemaIT-Sicherheit zu liefern, aber vor allem sollen die positiven Effekte des Zusam-menwirkens von IT-Security und IT-Service Management aufgezeigt werden.Hierbei stehen nicht die konkreten Maßnahmen des Security Managements imVordergrund, sondern ein prozessorientiertes Vorgehen, welches exemplarischam Beispiel des Service Supports, der operativen Ebene beschrieben wird.Die vorliegende Arbeit gliedert sich dabei in vier Kapitel. Nach der Einleitungfolgt ein Grundlagenkapitel, indem die für den weiteren Verlauf notwendigenBegrifflichkeiten des Security Managements erörtert werden. Das dritte Kapi-tel stellt den Hauptteil der Arbeit dar. Hier werden die einzelnen Prozesse desService Supports kurz vorgestellt und anschließend die sich bietenden Synergie-effekte mit dem Security Management aufgezeigt. Einen Abschluss findet dieArbeit in einem kurzen Fazit und der Zusammenfassung der gewonnenen Er-kenntnisse.

3.2 Grundlagen des IT-Security Management

Das nachfolgende Kapitel stellt eine Einführung in den Bereich des Security Ma-nagements dar. Um eine Diskussionsgrundlage für die weiteren Kapitel zu schaf-fen, wird zunächst der Begriff Informationssicherheit definiert und die einzelnenDimensionen der Informationssicherheit vorgestellt. Da die IT-Sicherheit unteranderem bedingt durch das Gesetz zur Kontrolle und Transparenz im Unterneh-mensbereich (§ 91 Abs. 2 AktG) nicht mehr nur Aufgabe der IT-Abteilung ist,sondern auch die Unternehmensleitung gesetzlich verpflichtet ist, dafür Sorge zutragen [Köh06, S. 204], werden zusätzlich gesetzliche Anforderungen und Vor-schriften an die Informationssicherheit und den Datenschutz vorgestellt. Nach-dem Ziele und Aufgaben des Security Managements präsentiert werden, findetdas Kapitel seinen Abschluss mit einer Einordnung des Security Managementsin ITIL.

3.2.1 Informationssicherheit

Oftmals sind es bestimmte Informationen oder fachspezifisches Know-how, dasden Unternehmen auf den hart umkämpften Märkten einen Wettbewerbsvorteilgegenüber ihren Konkurrenten verschafft.[Bru06, Vorwort des Verfassers] Ausdiesem Grund kommt der Sicherung und dem Schutz dieser Informationen undderen Systemen eine hohe Bedeutung zu.Der Begriff IT-Informationssicherheit ist stark durch die Sicht der Verlässlich-keit [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 Standhält.[Die04, S. 347] Es handelt sich bei diesen Bedrohungen um unbefugtenInformationsgewinn, unbefugte Veränderung der Funktionalität und unbefugteModifikation.

Vertraulichkeit. Unbefugter Informationsgewinn geht einher mit dem Ver-lust der Vertraulichkeit. Geraten wichtige Informationen in die falschen Hände,

Synergien zwischen Security Management und Service Support nutzen 83

kann dieses schwerwiegende wirtschaftliche Schäden nach sich ziehen. Um die-sem Datendiebstahl/ -missbrauch entgegen zu wirken, gibt es diverse Möglich-keiten, angefangen bei der Nutzung sicherer Informationskanäle über Verschlüs-selungsalgorithmen bis hin zur Schaffung von Zugangsbarrieren (Passwörter,PIN, etc.).Obendrein sollte in diesem Zusammenhang nach dem sogenannten „Need-to-know-Prinzip“ verfahren werden, nach dem jeder Benutzer (auch der Adminis-trator) lediglich die Berechtigungen (Zugriffe auf Datenbestände und Program-me) 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. gehtverloren, wenn die Funktionalität unbefugt oder durch technisches Versagen ge-stört wird. Mögliche Indikatoren für eine solche gestörte Verfügbarkeit sind derAusfall der Informationsverarbeitung, Sabotage der Verarbeitungsprozesse undZerstörung bzw. Löschen von Daten durch unbefugte Personen. Die Etablie-rung redundanter Einheiten (Backup Server, etc.) oder die Verschärfung derZugangsrestriktionen für Unbefugte sind zwei von mehreren Optionen, um die-sem 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 Inte-grität ein. Ein solcher Verlust der Integrität liegt bspw. vor, wenn Informationenunbewusst falsch verarbeitet oder verfälscht werden.[Köh06, S., 208] Ebenso istdenkbar, dass bewusste Veränderungen an Informationen vorgenommen wurden,wie es bspw. MalWare1 tut. Auch in diesem Fall sind eine restriktive Vergabeder Nutzungsrechte und Zugangskontrollen Alternativen, um die Vollständig-keit, Korrektheit und Unverfälschtheit der Informationen zu gewährleisten.Neben der Verlässlichkeit schützenswerter Informationen hat in der jüngerenVergangenheit auch deren Beherrschbarkeit mehr und mehr an Bedeutung ge-wonnen. Dabei steht nicht die technische Sicht (Sicherheit der Systeme), sonderndie Sicherheit der Betroffenen (Schutz vor dem System) im Vordergrund. ImZeitalter des Internets und der damit verbundenen Nutzung für Rechtsgeschäfte(Online-Banking, E-Commerce, etc.) sind die bereits vorgestellten Hauptmerk-male der Informationssicherheit (Integrität, Vertraulichkeit und Verfügbarkeit)deshalb um zwei Dimensionen zu erweitern. Es handelt sich hierbei um Zu-rechenbarkeit und Rechtsverbindlichkeit/Revisionsfähigkeit, die zusammen dieSicht der Beherrschbarkeit bilden.[Die04, S. 249] Ist es möglich Daten oder Vor-gänge einem Verursacher oder eine auslösende Instanz eindeutig zu zuordnenund sind diese darüber hinaus von unabhängigen Personen oder Instanzen nach-vollziehbar bzw. beweisbar, so sind Zurechenbarkeit sowie Rechtsverbindlichkeitgewährleistet.Die fünf vorgestellten Dimensionen der Informationssicherheit (Vertraulichkeit,Verfügbarkeit, Integrität, Zurechenbarkeit und Rechtsverbindlichkeit)2 könnenauch als Qualitätsmerkmale eines IT-Systems verstanden werden. Das Security

1Als Malware bezeichnet man Computerprogramme, welche vom Benutzer unerwünschteund ggf. schädliche Funktionen ausführen.

2Neben diesen fünf Dimensionen wurden in der letzen Zeit eine Reihe weiterer möglicherDimensionen diskutiert, wie etwa Robustheit, Stabilität, Wartbarkeit, Flexibilität oder Beob-achtbarkeit.


Management sollte bestrebt sein, diese Qualitätsmerkmale entsprechend der je-weiligen Anforderungen zu gewichten und anhand definierter Kriterien auf allenUnternehmensebenen umzusetzen. Dabei darf jedoch nicht außer Acht gelassenwerden, dass der Aufwand für die Implementierung im Verhältnis zum Nutzenstehen muss.[Bru06, S. 9]

3.2.2 Gesetzesanforderungen, Vorschriften und Standards

Ein IT-Sicherheitsvorfall kann nicht nur wirtschaftliche Schäden nach sich zie-hen, sondern es bestehen mittlerweile auch gesetzliche Regelungen, aus denensich Handlungs- und Haftungsverpflichtungen für die Unternehmung (vor al-lem für die Geschäftsleitung) ableiten lassen. Aus diesem Grund soll in die-sem Abschnitt kurz auf die gesetzlichen Anforderungen und Vorschriften an dieIT-Sicherheit sowie Standards, welche das IT-Security Management betreffen,eingegangen werden.Es gibt eine Reihe von Rechtsvorschriften, welche die verantwortlichen Personeneiner Unternehmung zur Rechenschaft ziehen, wenn es aufgrund eines nicht an-gemessenen IT-Sicherheitsniveaus zu wirtschaftlichen Schäden kommt. In Ver-bindung mit anderen gilt dies insbesondere für das Gesetz zur Kontrolle undTransparenz in Unternehmensbereichen (KonTraG). Dieses Gesetz ist ein soge-nanntes Artikelgesetz, welches verschiedene Gesetze wie das HGB oder AktGändert bzw. ergänzt. Kern des KonTraG ist eine Vorschrift, die die Unterneh-mensleitungen von Kapitalgesellschaften dazu zwingt, ein unternehmensweitesFrüherkennungssystem für Risiken (Risikomanagement) einzuführen und zu be-treiben sowie Aussagen bzgl. Risiken und Risikostruktur des Unternehmens imLagebericht des Jahresabschlusses der Gesellschaft zu veröffentlichen. Dies um-fasst ebenfalls IT-Risiken.Gemäß § 91 Abs. 2 des Aktiengesetzes hat der Vorstand einer Aktiengesell-schaft geeignete Maßnahmen zu ergreifen, insbesondere ein Überwachungssys-tem einzurichten, damit gefährdende Entwicklungen früh erkannt werden, umden Fortbestand der Unternehmung zu gewährleisten. Kommt der Vorstand die-ser Forderung nicht nach, so haftet er persönlich.(§ 93 Abs. 2 AktG) Der Gel-tungsbereich dieser Vorschriften erstreckt sich auch auf das HGB.(§ 317 Abs. 4HGB) Des Weiteren verpflichtet § 317 Abs. 2 HGB Abschlussprüfer zu prüfen,ob die Risiken auch zutreffend dargestellt werden. Eine weitere Regelung, wel-che betroffen sein kann, ist der Paragraph 43 Abs. 1 des GmbHG, wonach fürdie Geschäftsführung die „Sorgfalt eines ordentlichen Geschäftsmannes“ gilt.Der Umgang mit personenbezogenen Daten wird in den Datenschutzgesetzendes Bundes und der Länder geregelt.Während bei der Datensicherheit die Gewährleistung der Verfügbarkeit, Ver-traulichkeit und Integrität von Daten im Vordergrund steht, ist das Ziel desDatenschutzes die freie Entfaltung der Persönlichkeit.[Köh06, S. 210] Um dies zugewährleisten, muss ein Schutz des Einzelnen vor Erhebung, Speicherung, Ver-wendung und Weitergabe seiner persönlichen Daten sichergestellt sein. Damitliegt der Wirkungskreis des Datenschutzes in der Sicherstellung der informellenSelbstbestimmung des Einzelnen.Für bestimmte Berufsgruppen, wie Ärzte, Anwälte oder Angehörige sozialerBerufe, gibt es im Strafgesetzbuch Sonderregelungen, die sogar Freiheitsstrafenvorsehen, wenn vertrauliche Daten ihrer Patienten oder Klienten ohne deren


Zustimmung an die Öffentlichkeit gelangen.3 Bereits einen fahrlässiger Umgangmit der Informationstechnik (z. B. durch unsichere Passwörter oder ungeeigneteVerschlüsselungsalgorithmen) kann unter Umständen diesen Tatbestand erfül-len.Neben den Gesetzesanforderungen und Vorschriften gibt es zugleich diverseStandards (BS/ISO), welche das IT-Security Management thematisieren und esunter anderem ermöglichen sollen, die oben angesprochenen gesetzlichen Vorga-ben zu erfüllen.Einer der ersten dieser Art war der britische Standard BS 7799, auf Basis dessenim späteren Verlauf der ISO/IEC 17799:2005 entwickelt wurde. Genau wie dieUrfassung des britischen Standards beruht der ISO/IEC 17799 auf einem BestPractice Ansatz, welcher die Aufstellung von Maßnahmen umfasst, deren Ziel esist, die Informationssicherheit zu gewährleisten.[Bru06, S. 213] Der große Vorteilder ISO-Standards ist die internationale Akzeptanz und damit besonders fürglobal agierende Unternehmen von Bedeutung.Der ISO/IEC 27001:2005 dagegen beschreibt den Aufbau eines Information Se-curity Management Systems (ISMS) und referenziert im Anhang auf die Maß-nahmen, die durch den ISO/IEC 17799 detailliert beschrieben werden. Dabeiwerden Anforderungen an ein dokumentiertes Informationssicherheits-Manage-mentsystem im Hinblick auf Implementierung, Erhaltung, Verbesserung, War-tung und Überwachung detailliert dargestellt.Auch in Deutschland hat man sich dieser Thematik angenommen, woraufhin dasBundesamt für Sicherheit in der Informationstechnik (BSI) das IT-Grundschutz-handbuch herausgab und später zu den IT-Grundschutzkatalogen weiter entwi-ckelte. 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 Er-stellung eines Sicherheitsprozesses über die Implementierung bis hin zur Defini-tion der konkreten Aufgaben. Weiterhin werden sogenannte Bausteine beschrie-ben, die übergeordnete Prozesse und Verfahren, wie z. B. die Notfallplanung, IT-Security Management und Organisation darstellen. Jeder Baustein beschreibtein 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 ange-wandt, auch die Wirtschaft fragt dieses immer stärker nach. In seiner aktuellstenVersion 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 Zusam-menfassung der wichtigsten Sicherheitsmaßnahmen sowie Praxisbeispiele undChecklisten geliefert.

3.2.3 Ziele und Aufgaben des IT-Security Management

Die Zeiten, in denen die IT-Infrastruktur hinter sicheren Mauern vor den Blickender Umwelt geschützt war und einige wenige Sicherheitsmaßnahmen genügten,um die Datensicherheit zu gewährleisten, sind längst vorbei. „Sicherheit ist heutemehr als das Abschlie[ß]en von Serverräumen und die peinlich genaue Beach-tung von Passwortregeln.“[Vog02, S. 270] Die Anforderungen an das Security

3§ 203 StGB, die so genannte Schweigepflicht


Management haben in unserer heutigen hochtechnisierten und auf den eigenenVorteil ausgerichteten Welt, erheblich zugenommen.[Köh06, S. 203] Aus diesemGrund sollen im Folgenden Anforderungen, Ziele und Maßnahmen des SecurityManagements vorgestellt werden.

Security Policy. Bevor Maßnahmen zum Schutz der IT-Infrastruktur vorpotenziellen Bedrohungen, wie etwa Hackerangriffen, Viren oder Datendiebstahlergriffen werden können, sind zunächst die Anforderungen an die jeweiligenProzesse zu ermitteln und in Form konkreter Sicherheitsziele zu definieren.Elementarer Baustein innerhalb des Security Managements ist in diesem Zusam-menhang die Security Policy4. Neben den langfristigen Sicherheitszielen beinhal-tet sie die Personalverantwortlichkeiten und Sicherheitsstufen für die jeweiligenProzesse und Daten eines Unternehmens. Ferner werden auch Sicherheitsrichtli-nien in der Policy definiert und festgehalten. Für die konkrete Ausgestaltung derSicherheitsrichtlinien liefert bspw. das IT-Grundschutzhandbuch des BSI geeig-nete 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 wirddie 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 zwi-schen den jeweiligen Prozessverantwortlichen zu rechnen, bspw. zwischen Daten-schutz- und Sicherheitsbeauftragten. Beide vertreten unterschiedliche Auffassun-gen im Hinblick auf die Protokollierung persönlicher Zugriffe von Mitarbeitern.[Köh06, S. 210] Während der Datenschutzbeauftragte den Schutz personenbe-zogener Daten als Ziel verfolgt, liegt es im Interesse des Sicherheitsbeauftrag-ten diese Informationen möglichst detailliert zu erfassen, um einem Missbrauchvorzubeugen oder für den Fall eines Missbrauchs die Nachvollziehbarkeit zu er-möglichen.

4Englischer Begriff für IT-Sicherheitspolitik


Ziele. Für den reibungslosen Ablauf bzw. das Funktionieren eines Unterneh-mens 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 Bedeutungfür die Unternehmung zu gewährleisten. Der Schutz der Vertraulichkeit, Ver-fügbarkeit und Integrität vor potenziellen Bedrohungen soll dabei auf effizienteund ressourcenschonende Weise erfolgen (Wirtschaftlichkeit).Neben der Datensicherheit stehen auch Aspekte des Datenschutzes im Fokus desSecurity Managements. Maßgeblich ist in diesem Zusammenhang das gesetzlicheRahmenwerk.6 Zielsetzung in diesem Kontext ist es, die gesetzlichen Auflageneinzuhalten.

Geschäfts-leitung

Security Policy

IT-Sicherheits- Management

Informations und Prozess-sicherheitsstandards

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 Auf-gabenspektrum dabei von der Auswahl adäquater Firewalls, Anti-Viren- undAnti-Malware-Programmen über die Schulung des Sicherheitsbewusstseins derMitarbeiter bis hin zu Risikoanalysen. Bei Risikoanalysen werden Betriebsmittelauf Schwachstellen und potentielle Bedrohung untersucht und diesbezüglich Be-wertungen vorgenommen. Die Risikobewertung richtet sich einerseits nach demSchadenspotenzial und zum anderen nach der Bedeutung für das Unterneh-men. 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 Auswirkun-gen für Geschäftsprozesse frühzeitig zu identifizieren und rechzeitig präventive

5siehe dazu ausführlicher Kapitel 3.2.1 IT-Informationssicherheit6siehe dazu ausführlicher Kapitel 3.2.2 Gesetzesanforderungen, Vorschriften und Standards


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 wer-den

Die nachfolgende Abbildung dient abschließend dazu, den Prozess des SecurityManagements zu veranschaulichen und verdeutlicht, dass die IT-Sicherheit keinstatischer Zustand ist, sondern ein dynamischer Prozess.[Bsi07, S. 6]

Plan

DoCheck

Act

ReportReport

Management-Report zuIT- Risiken undIT- Sicherheit,Dokumentation vonSicherheitsvorfällen

Plan

Security Policy,Service Level Agreement,Operational LevelAgreement

Check

Einhaltung der Security Policy überprüfen,Security Audits,Interne u. ExterneÜberprüfung

Do

Bedrohungsanalysen,Priorisierung,Sicherheitsbewusstseinschulen/fördern,Auswahl geeigneter Software/ Tools zum Schutz vor Viren, Würmern, MalWare, etc.

Act

Notwendige Änderungen herbeiführen, Verbesserung derProzesse

Abbildung 3.2: Erweiterter PDCA-Zyklus des Security Management Prozesses.

3.2.4 Einordnung von Informationssicherheit und Securi-ty Management in ITIL

Heutzutage sind Unternehmen und Organisationen zunehmend dem Druck aus-gesetzt, ihre IT-Prozesse zu überarbeiten und zu verbessern. Dynamische Ge-schäftsprozesse und der steigende Informationsbedarf sind Auslöser zur Neu-strukturierung und stellen ein Unternehmen vor Probleme in Bezug auf derenUmsetzung. Nicht zuletzt trägt der technologische Fortschritt in der Informa-tionsübertragung und -verarbeitung zusätzlich dazu bei. Um solchen Anforde-rungen gerecht zu werden, führt kein Weg an Standardisierung vorbei, wodurch

7Security Audits sind regelmäßige Prüfungen des Softwarebestands und gleichzeitiger Ab-gleich mit Securitylisten, wodurch Gefahren frühzeitig erkannt werden können.


nicht nur versucht wird Geschäftsprozesse und Verhaltensweisen, sondern auchserviceorientiertes Management aneinander anzupassen.Die ITIL hat sich dieser Thematik angenommen und dient als Orientierung füreine solche Prozessstandardisierung. Als „IT-Infrastructure Library“ hat sichdieses Rahmenwerk als Instrument zur Planung und Umsetzung etabliert.Ein oft vernachlässigter Bereich ist in diesem Zusammenhang das Thema Infor-mationssicherheit. Auch dieser Problematik hat sich ITIL angenommen und ver-sucht ein Leitfaden für den sicheren Umgang mit Informationen im Service Ma-nagement zu sein. ITIL beruht auf Best Practice Ansätzen und sieht Sicherheits-aspekte als unverzichtbaren Bestandteil eines ordnungsgemäßen IT-Betriebesan. In der Version V2 umfasst das komplette ITIL-Paket sieben Bücher. Ei-nes davon ist das Buch „Security Management“, welches sich dieser Thematikwidmet und versucht eine Verbindung zwischen Sicherheitsanforderungen undGeschäftsprozessen zu schaffen. Im Gegensatz dazu wird dem Thema Sicherheitin der aktuellen, dritten Version (V3) kein eigenes Buch gewidmet, sondern fin-det in Teilbereichen der fünf Buchbände Berücksichtigung. Wird diese Thematiknach ITIL eingeführt und allumfassend umgesetzt, ergeben sich viele Chancenfür einen effizienten Umgang mit sicherheitsrelevanten Ereignissen.Informationssicherheit betrifft alle Personen und Bereiche innerhalb einer Or-ganisation, vom einfachen Mitarbeiter bis hin zur Chefetage. ITIL unterteiltdeswegen seine Prozesse in drei Ebenen.

Strategische Ebene. Das Top-Management stellt die oberste, die strategi-sche Ebene dar. Auf ihr wird entschieden, ob ein Security Management auf-gebaut wird und gegebenenfalls werden Verantwortlichkeiten festgelegt. Zudemsollte die von dem Security Management erarbeitete Security Policy an die Ge-schäftsleitung herangetragen werden, um eine gesamtheitliche Akzeptanz undUnterstützung zu gewährleisten. Strategische Ausrichtung, Finanzierung undKontrollfunktion sind weitere Aufgaben, die das Top-Management betreffen.

Taktische Ebene. Die zweite Ebene wird auch taktische Ebene genannt unddient der Qualität der Services. Auf ihr werden alle Prozesse des Service Deliveryzusammengefasst. Das Service Level Management bestimmt die Anforderungenan das Service Delivery, also die zu erbringenden IT-Dienstleistungen. DieseVereinbarungen, die die Erbringung von Serviceleistungen betreffen, bilden dasService Level Agreement (SLA). Hier tritt der Kunde als Auftraggeber der Leis-tungen auf und kann über seinen Bedarf die Serviceangebote der IT-Abteilungbeeinflussen. Ebenfalls auf dieser Ebene anzusiedeln, ist das Security Manage-ment, dessen Aufgabe es ist die gesamte Netzwerkstruktur in puncto Sicherheitzu betreuen und zu überwachen. Gegebenenfalls wird zusätzlich ein SecurityOfficer ernannt, der die Verantwortung diesbezüglich trägt und Ansprechpart-ner der Geschäftsleitung ist. Aus den, in den SLAs definierten, Anforderungenleiten sich Sicherheitsziele ab, welche in der Security Policy zusammengefasstwerden. Wie im vorigen Kapitel bereits erläutert, zählen hierzu beispielsweiseDatenschutz, gesetzliche Bestimmungen oder Sicherheitsstufen.

Operative Ebene. Die operative Ebene ist für die konkrete Umsetzung dieserZiele verantwortlich und beinhaltet die Prozesse des Service Supports. DieseEbene steht in direktem Kontakt mit Anwendern und verwaltet alle Wünsche,


Anfragen und Änderungen. Der zentrale Anlaufpunkt ist der Service Desk. Hierlaufen Anfragenzusammen und es wird die Funktion des Incident Managements mit Schnittstel-len zu Problem-, Change- und Release Management etabliert.8

3.3 Security Management mit ITIL auf operati-ver Ebene

Nachdem im vorherigen Kapitel grundlegende Aspekte, wie IT-Security Ma-nagement oder Informationssicherheit erläutert wurden, soll nun im Folgendenaufgezeigt werden, wo sich Chancen und Möglichkeiten des Zusammenwirkensvon Security Management und Service Support im Zuge der Restrukturierungbzw. Neustrukturierung der Geschäftsprozesse nach ITIL bieten. Ferner soll ex-plizit dargestellt werden, wie sich diese Synergieeffekte nutzen lassen.Dazu werden in den folgenden Abschnitten die einzelnen Prozesse des ServiceSupports kurz erläutert und anschließend die Vorteile der wechselseitigen Be-ziehung aufgezeigt.Ziel dieses Kapitels ist es nicht, konkrete Sicherheitsmaßnahmen vorzustellen,wie es bspw. das BSI-Grundschutzhandbuch tut. Zwar sollen auch solche Aspek-te angesprochen werden, der Fokus dieses Kapitels liegt jedoch eindeutig auf derDarstellung der prozessorientierten Maßnahmenplanung.

3.3.1 Service DeskHat ein Anwender eine Anfrage oder treten Komplikationen in Bezug auf be-stimmte Anwendungen oder Services auf, ist der Service Desk die erste Station,an die er gelangt. Er ist der zentrale Anlaufpunkt einer IT-Organisation und solleine professionelle Anwenderunterstützung garantieren. Mittels Email, „Face-to-Face“-Kommunikation oder wie in den meisten Fällen per Telefon, werdensogenannte Incidents9 aufgenommen und bearbeitet. Das können unter anderemtriviale Fragen zu Soft- und Hardware sein oder auch Meldungen zu Produkt-fehlern oder Servicestörungen. Der Mitarbeiter am Service Desk ist nun gefragtweitere Schritte zur Behebung dieser Incidents einzuleiten und Ereignisdaten ineiner Datenbank zu speichern. Gemäß ITIL ist dies die Configuration Mana-gement Database (CMDB), auf die in Kapitel 3.3.6 ausführlicher eingegangenwird. Im Gegensatz zu den nachfolgenden Servicemanagement-Prozessen in ITILstellt 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 Statusdes Incidents abgerufen und kontrolliert werden, so dass Geschäftsleitung oderKunden schnell und zuverlässig Informationen bereitgestellt werden können.Des Weiteren übernimmt der Service Desk Routineaufgaben des Change- undConfiguration Managements, unterstützt das Release Management bei der Roll-out-Phase oder stellt von sich aus Kontakt zu Anwendern her.[Bmi06, S. 13] EinBeispiel dafür sind Änderungsanträge, die zuvor bereits standardisiert wurdenund nun direkt umgesetzt werden können, ohne an entsprechendes Fachpersonal

8Auf eine detaillierte Darstellung der operativen Ebene wird an dieser Stelle verzichtet, umÜberschneidungen mit dem folgenden Kapitel zu vermeiden.

9Englischer Begriff für unvorhergesehenes Ereignis, Auftrag oder Störfall


weitergeleitet zu werden. Durch Soft- oder Hardwareinstallationen, wie z. B.Patches10 oder Updates, können bestimmte Störungen schon vom Service Deskbehoben werden und entlasten somit das Release Management.Der Service Desk ist aufgrund seiner Schnittstellenfunktion auch für sicherheits-relevante Themen zuständig. So werden über Security Incidents Prozesse der IT-Sicherheit wie Passwortvergabe, Veränderungen von Zugriffsrechten oder auchBenutzerkonten angesprochen und bearbeitet. Derartige Standardprozesse kön-nen direkt vom Service Desk durchgeführt oder aber an Experten weitergeleitetwerden. Der Service Desk ist somit ein Teil des Security Management und sollteAnforderungen wie hohe Erreichbarkeit und Reaktionsgeschwindigkeit gerechtwerden. Zusammen mit dem für die Sicherheit zuständigem Management ist esratsam Strategien zur Sensibilisierung der Mitarbeiter bei hoch sicherheitsrele-vanten Vorfällen (z. B. Flächenstörungen) auszuarbeiten, um die IT-Spezialistenmöglichst rasch zu alarmieren und Fehleinschätzungen vorzubeugen. Die Mitar-beiter des Service Desk sind ein wichtiger Aspekt in diesem Prozess, da durchihre Entscheidung Arbeitszeit und Aufwand gespart oder vergeudet wird.Bei entsprechender Umsetzung kann der Service Desk einen großen Beitrag zuder Incidentbearbeitung leisten. Durch seine vielfältigen Anforderungen kanner allgemeine Aufgaben erfüllen und sogar spezifische Lösungen bereitstellen.Letztendlich ermöglicht ein funktionierender Service Desk sogar die Leistungdes Security Management zumindest in Teilen messbar zu machen. In Verbin-dung mit der Leistungstransparenz, welche ITIL mit sich bringt, ermöglicht esdie Erfassung von Security Incidents bspw. Aussagen darüber zu machen, obdie Anzahl an Security Incidents rückläufig ist oder um wie viel Prozent diesezurückgegangen sind.

3.3.2 Incident ManagementNachdem eine Anfrage aufgenommen wurde, ist es die Aufgabe des IncidentManagements, diese zu verwalten und eine Übersicht über den aktuellen Statusaller Incidents zu gewährleisten. Um Auswirkungen auf die Geschäftsprozesseso gering wie möglich zu halten und Imageschäden zu vermeiden, ist es Zieldieses Vorgangs, alle Anfragen und Vorfälle schnellstmöglich zu behandeln undpotentielle Fehler zu beheben. Früher wurden dazu Bücher geführt, die zentralabgelegt und nur einen Zugriff zur selben Zeit zuließen. Im Gegensatz dazuwerden heutzutage moderne, computergestützte Verfahren eingesetzt, um dieBehandlung einer Vielzahl von Datensätzen zu ermöglichen, bei denen mehre-re Benutzer gleichzeitig auf einen Incident zugreifen können. Auf dem Markterhältlich, sind dazu einige Softwarelösungen, die mit Ticket-Systemen arbei-ten. Jeder Incident wird dadurch einem Ticket zugewiesen und ist über eineNetzwerkverbindung jederzeit abrufbar.Da Störungen die Informationssicherheit beeinflussen können oder ein uner-kannter Sicherheitsvorfall Störungen hervorrufen kann, ist das Incident Mana-gement als Teilbereich des Security Managements anzusehen. ITIL liefert hierzueinen Prozessansatz, bei dem je nach Qualität einer Störung eine oder mehrereSupport-Stufen durchlaufen werden. Die Bearbeitung von Störungen, in die-sem Fall Security Incidents, lässt sich in mehrere Arbeitsschritte untergliedern.[Bmi06, S. 17]

10Ein Patch ist eine Korrekturauslieferung oder Nachbesserung für Software aus Endanwen-dersicht, bspw. um eine Sicherheitslücke zu schließen.


• 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 kannauf verschiedenen, dezentralen Wegen erfolgen. Zum einen wäre da der Anwen-der (Kunde, Zulieferer, Mitarbeiter), dem eine Unregelmäßigkeit bekannt wirdund diese an den Service Desk heranträgt. Ein weiterer Aspekt ist die Erken-nung einer Störung durch ein System. Netzwerke mit ihren Peripheriegerätenkönnen über eine Software überwacht werden (Monitoring) und senden bei Über-schreitung eines bestimmten kritischen Wertes eine Fehlermeldung. Wie obenbereits erwähnt, werden diese Ereignisse von dem Service Desk erfasst und inder CMDB gespeichert. Es kann in der Praxis sinnvoll sein, Security Incidentsgetrennt von anderen Störungen an einer separaten Meldestelle aufzunehmen.Vorteil dieser Maßnahme ist es, dass sensible Informationen weniger schnell andie Öffentlichkeit gelangen. Auf der anderen Seite wird von einem Anwendererwartet, festzustellen, ob ein Vorfall sicherheitsrelevant ist oder nicht. Die an-dere Möglichkeit ist eine zentrale Annahme aller Incidents. Dieser erste Schrittin der Bearbeitung der Störungen wird First-Level-Support genannt.

Klassifizierung und Erstlösungsversuch. Durch eine Klassifizierung wirdStatus und Art der Störung eingeordnet und festgestellt, welche Sicherheitszielebetroffen sind. Über eine Risikoanalyse wird ermittelt, welche Schadensauswir-kung entstehen kann und wie dringend das Sicherheitsziel wieder hergestelltwerden sollte. D. h., es wird ein Bearbeitungszeitraum zur Lösung des Problemseingeplant und eine erste Priorisierung vorgenommen. Diese Prioritätseinstu-fung dient nur als eine erste Orientierung und kann später durch genauere Ana-lyse von Fachpersonal oder im Change Management korrigiert werden. Anhandder vorher definierten Security Policy, sollte es dem Mitarbeiter des First-Level-Support möglich sein, eine Einschätzung gemäß ihrer Bedeutung für die Orga-nisation zu tätigen.Handelt es sich um ein Fehler, der die Security Policy verletzt und dessen Lösungin der Configuration Management Datenbank dokumentiert ist, kann er an die-ser 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 mitder Recherche über bereits bekannte Störungen oder ähnliche Vorfälle, die inder Vergangenheit aufgetreten sind. Ist dies der Fall, wird der damals benutzteWorkaround vorgeschlagen oder eine entsprechende Eskalationsstrategie ange-wandt. Der Workaround dient dazu, Einflüsse auf Geschäfts- und Serviceprozes-se so gering wie möglich zu halten, um der weiteren Lösungsfindung mehr Zeit


zu verschaffen. Da eine Fülle von möglichen Anwendungs- und Konfigurations-problemen denkbar ist, wird es praktisch kaum möglich sein dem Support zujedem Vorfall eine entsprechende Handlungsvorschrift bereitzustellen. Vielmehrsollten absehbare oder schon bekannte Sicherheitslücken dokumentiert vorlie-gen. Ist eine Problemlösung jedoch nicht bekannt und es kann keine schnelleLösung gefunden werden, wird der Vorfall an eine nächste Support-Ebene wei-tergeleitet. Das Security Management sollte zu Beginn helfen, diese Ebenen derITIL-Einführung zu strukturieren und aufgrund des fachlichen Wissens Verant-wortlichkeiten verteilen. In den meisten Fällen der Security Incidents sind dasIT-Spezialisten oder Systemadministratoren, die auf zweiter oder dritter Ebeneagieren.

Incident lösen. Sofern ein Standardproblem nicht schon im Vorfeld gelöstwurde, wird es von Fachkräften auf nächster Ebene behandelt. Da zur Bearbei-tung der Störung vielfach externe Dienstleister oder Personen zu Rate gezogenwerden, sollte der Umgang mit sensiblen Informationen geklärt sein. Durch einestrenge Authentisierung kann Missbrauch der Daten verhindert und die Inte-grität sichergestellt werden. Falls Daten einem speziellen Schutz in Bezug aufdie Informationssicherheit unterliegen, sollte das Security Management das In-cident Management darüber informieren, wie solche Daten übermittelt werdenund welche Personen berechtigt sind, diese einzusehen.Ist ein Missbrauch jedoch nicht auszuschließen, kann es zu Zielkonflikten zwi-schen forensischer Analyse und Servicemanagement kommen. Die Forensikerkonzentrieren sich auf genutzte Sicherheitslücken und Spurensicherung, wäh-rend Mitarbeiter vom Service alle Energien zur Wiederherstellung betroffenerServices einsetzen.Wurde ein Störfall erfolgreich gelöst, ist eine ausführliche Dokumentation vongroßer Wichtigkeit. Die CMDB sollte um eine Handlungsvorschrift ergänzt wer-den, damit nachfolgenden, ähnlichen Incidents schneller behoben werden kön-nen. Sofern ein Incident nur durch eine Änderungsmaßnahme (z. B. Umgestal-tung einer Netzwerkstruktur) gelöst werden kann, wird ein Request for Change11

(RfC) beim Change Management eingereicht. Eine explizite Betrachtung desChange Managements wird an einer anderen Stelle beschrieben.

Überwachen und steuern. Die Überwachung der Störungen ist Aufgabe desService Desks. Regelmäßig sind die Incidents zu Überprüfen, um die Wiederher-stellung der Sicherheitsziele in der dafür vorgesehenen Zeit nicht zu gefährden.Entwickelt sich eine Störung zu einem Notfall, sollte das Incident Managementin der Lage sein, einen Notfall rechtzeitig zu erkennen und angemessen reagie-ren. Auch in diesem Fall ist das Security Management gefragt, im Vorfeld einenNotfallplan auszuarbeiten. Notfälle können Flächenstörungen, wie zum BeispielServerausfall, Komplettausfälle von Netzwerken oder auch Stromausfall sein.Die Verantwortung liegt bei Vorfällen diesen Ausmaßes bei dem Notfallmana-gement.

Abschließen des Incidents. Nach Lösung des Störfalls wird der Incidentvom Service Desk abgeschlossen. Dazu gehört die Kontrolle über korrekte Be-arbeitung und Nutzung der vorgegebenen Support-Ebenen. Zusätzlich wird der

11Englischer Begriff für Änderungsanfrage


Anwender über den Hergang informiert und es wird gegebenenfalls ein Feedbackangefordert. Anschließend wird die Dokumentation auf Vollständigkeit geprüft.Das Incident Management hat die CMDB zu pflegen und sollte nach Secu-rity Policy und Security Management über mehrere Aspekte Auskunft gebenkönnen. Dazu zählen beispielsweise Erfassungsdatum, Durchlaufzeit, Kurzbe-schreibung und Effektivität der Untersuchung. Anhand dieser Daten ist eineAuswertung möglich, um Präventivmaßnahmen durchzuführen oder in Zukunftschneller 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 ManagementDie Aufgabe des Problem Managements ist die Forschung nach den Ursachenfür Probleme12 Durch sogennante Ursachen-Wirkungsanalysen soll verhindertwerden, dass sich Fehler wiederholen. Auf diese Weise kann ein funktionieren-des Problem Management die Anzahl von Incidents reduzieren und somit einerheblicher Teil zur Zuverlässigkeit und Wirtschaftlichkeit eines IT-Services bei-tragen.Im Problem Management gibt es zwei unterschiedliche Verfahren, auf die in dennächsten Absätzen eingegangen wird.

• Antrag aus dem Incident Management

• Das proaktive Problem Management

Antrag aus dem Incident Management. Wenn bei der Bearbeitung einerStörung durch das Incident Management die Ursache nicht festgestellt werdenkann, wird aus dem Incident ein Problem und an das Problem Managementweitergeleitet. Dabei muss es sich nicht immer zwangsläufig um Probleme han-deln, die nicht behoben werden können. Es können vom Incident Managementauch Anfragen für spezielle Probleme eingehen, die sie zwar schnell behebenkö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ährenddas Incident Management einen Fehler schnellstmöglich beseitigen möchte, ver-sucht das Problem Management das Auftreten solcher zu vermeiden. Dabei kanndies mitunter zu Interessenskonflikten führen. Bspw. kann das Incident Mana-gement ein Netzwerkfehler schnell beheben, indem ein entsprechender Switch13

neu gestartet wird. Das Problem Management wird aber möglicherweise eineAuswechslung der gesamten Switches beantragen, was mehrere Stunden dauern

12Nach ITIL- Definition sind Probleme, die noch unbekannte Ursache für einenStörung.[Bsi05, S. 18]

13Ein Switch ist eine Netzwerkkomponente, die mehrere Computer verbindet.


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 undführt sich vor Augen welche Zielsetzung das Problem Management verfolgt, istschnell zu erkennen, dass auf lange Sicht die Verfügbarkeit und die Wahrschein-lichkeit auf Erreichung der SLA erhöht wird.Es sei nun angenommen, dass der oben beschrieben Netzwerkfehler nicht auf ei-nem defekten Switch beruht, sondern auf einem Angriff von außen (etwa durcheinen Hacker oder Virus). In diesem Fall ist die Informationssicherheit des Netz-werkes der Unternehmung gefährdet. Das Security Management sollte aufgrundseiner speziellen Funktion somit bereits in die Analyse mit einbezogen werden.Durch sein Know-how kann das Security Management bei der Problem-Analyseund Lösungsentwicklung einen wesentlichen Beitrag zu besseren Ergebnissenleisten.

Das proaktive Problem Management. Eine weitere Aufgabe des ProblemManagements ist das proaktive Suchen nach Fehlern und Schwachstellen. Zieldabei ist es, durch präventive Maßnahmen Fehler zu verhindern, bevor sie auf-treten. 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 Hil-fe von Penetrationstests erfolgen. Unter einem Penetrationstest versteht man,den Versuch sich mit den Mitteln eines Eindringlings (Hacker, Virus, etc.) inein System einzuloggen. Wird eine Schwachstelle gefunden, sollte umgehend ei-ne Lösung gefunden und gegebenenfalls die Software geändert werden. Überdie dazugehörigen Updates sollten dann die Kunden informiert und ihnen zurVerfügung gestellt werden. In diesem Zusammenhang sollte darauf geachtet wer-den, dass die Schwachstelle erst dann an die Öffentlichkeit gelangt, wenn diesebeseitigt ist.Durch die Integration des Security Management in den ITIL-Prozess ProblemManagement entstehen potenzielle Synergieeffekte. Erfahrungsgemäß ist dabeidie Analyse von Sicherheitslücken und deren Beseitigung eine große Stärke desSecurity Managements.[Bsi05, S. 18] Durch die Verflechtung beider Prozesse undderen Aufgaben lässt sich eine deutliche Kompetenzsteigerung erreichen.Die Suche nach Schwachstellen mittels Security Audits ist eine der Maßnahmendes Security Managements.15 Ergänzt man die Verfahrensweisen des proaktivenProblem Managements um diese Methode und optimiert diese für den eigenenZweck, ermöglicht dies Verletzungen von Sicherheitsrichtlinien frühzeitig zu er-kennen und mögliche Ursachen für Fehler zu verhindern.Nicht jedem Incident kann zu Beginn eindeutig zugeordnet werden, ob dieserAuswirkungen auf die Informationssicherheit hat oder nicht. Daher muss ab-gewogen werden, wann das Security Management in den Prozess des ProblemManagements eingebunden werden soll, um eine bestmögliche Effizienz zu er-reichen. Diese Frage sollte deshalb bereits bei der Entwicklung der internenSicherheitsrichtlinien beantwortet und die Vorgehensweise standarisiert werden,um damit die Synergieeffekte optimal auszunutzen und ein bestimmtes Sicher-heitsniveau gewährleisten zu können.Die nachfolgende Abbildung verdeutlicht eine Problematik, mit der sich eigent-lich primär das Change Management konfrontiert sieht. Da aber Lösungswege

14Dabei kann dieses Verhältnis auch betriebsintern bestehen.15siehe Kapitel 3.2.3 Ziele und Aufgaben des IT-Security Management


für bestehende Probleme schon im Problem Management entwickelt werden undsie damit eine gewisse Vorarbeit für das Change Management leisten, soll aufdie möglichen Auswirkungen vorgenommener Änderungen auf die Informations-sicherheit bereits an dieser Stelle eingegangen werden.

Informationssicherheit

Sicherheits-lücken

ProblemeFehler

Änderungen

Abbildung 3.3: Auswirkungen von Änderungen auf die Informationssicherheit.

Handelt es sich bei einer Sicherheitslücke nicht um einen dokumentierten Feh-ler, liegt im Allgemeinen ein Problem vor, welches die Ursache oder Wirkungvon Service-Beeinträchtigungen sein und die Informationssicherheit gefährdenkann. 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 Änderun-gen können Auswirkungen auf die Informationssicherheit haben und im schlim-msten Fall letztlich neue Sicherheitslücken verursachen. Es kann ein potenziellerKreislauf entstehen, durch den permanent die Informationssicherheit gefährdetist. Dies steht jedoch im Widerspruch zu den eigentlichen Zielsetzungen desProblem Managements (vor allem die Reduzierung der Incidents). Aus diesemGrund hat das Problem Management großes Interesse daran, diesen potenzi-ellen Kreislauf gar nicht erst entstehen zu lassen. Wird nun das Security Ma-nagement zusätzlich in den Prozess der Lösungsentwicklung einbezogen, kannim Change Management eine Reduzierung der abgelehnten RfCs erreicht wer-den. Die Mitarbeiter des Security Managements können schon bei der Entwick-lung von Änderungsvorschlägen eingreifen und diese auf sicherheitstechnischenAspekten überprüfen. Durch dieses Zusammenspiel von Problem- und Securi-ty Management kann eine höhere Effizienz bei Änderungen erreicht und somitauch Kosten gesenkt werden.

3.3.4 Change ManagementDie Zuständigkeit des Change Managements erstreckt sich von der Erfassungüber die Priorisierung bis hin zur Auswertung aller eingehenden RfCs. Ziel ist


es dabei, Änderungen, d. h. veränderte Eingriffe in Anwendungen, Infrastruk-tur, Dokumentationen, Prozesse und Verfahren steuerbar und kontrollierbar zumachen. Störungen infolge von Änderungen sollen vermieden und die Effizienzder Änderung gesteigert werden. Letzteres ist möglich, wenn z. B. Änderungenvermieden werden, die keinen angemessenen Nutzen liefern, nicht gewünschtsind oder mangels Durchführbarkeit wieder zurück genommen werden.[Bsi05,S. 19] In diesem Kontext vollzieht das Change Management geeignete Tests, dieeinen Nachweis über Nutzen und Kompatibilität mit anderen Systemen ermög-lichen. Die zentrale Instanz des Change Managements ist das Change AdvisoryBoard(CAB). Dieses wird vom Change Manager zusammengerufen, um gemein-sam die gerade beschriebenen Aufgaben zu bewältigen. Verlaufen die Tests po-sitiv, so kann der Change freigegeben und ausgeführt werden.Das Security Management nach ITIL ist sowohl als Initiator, Realisierer sowieals Planungs- und Freigabeinstanz von Changes in den Change ManagementProzess eingebunden.[Bsi05, S. 20]

Als Initiator von Changes. Wie im Kapitel 3.3.3 (Problem Management)beschrieben, wird bei Incidents, die die Informationssicherheit betreffen, dasSecurity Management herangezogen. Häufig hat dies technische oder organi-satorische RfCs zur Folge, die durch das Security Management im Laufe derProblem-Analyse angeordnet und an das Change Management weitergeleitetwerden.

Als Realisierer von Changes. Das Security Management hat konkrete Ver-antwortungen für Teile der IT-Infrastruktur. So werden Security Maßnahmenentwickelt und realisiert. Hierbei findet das Change Management in gleicherWeise wie in anderen Bereichen des IT-Betriebs Berücksichtigung.

Als Planungs- und Freigabeinstanz. Um Auswirkungen auf die Informa-tionssicherheit und den Datenschutz zu vermeiden, sollte das Security Mana-gement sowohl bei der Planung als auch bei der Freigabe von Änderungenmit eingebunden werden. Sinnvoll ist es in diesem Zusammenhang, ein odermehrere Mitarbeiter des Security Managements in das Änderungsgremium mitaufzunehmen. Auf diese Weise ist einerseits sichergestellt, dass jeder RfC aufsicherheitsrelevante Merkmal überprüft wird, auf der anderen Seite stellt dasSecurity Management geeignete Test- und Abnahmeverfahren bereit, die ver-hindern sollen, dass durch Änderungen Sicherheitslücken entstehen. Abbildung3.4 veranschaulicht, wie das Security Management bei der Überprüfung undAbnahme von RfCs unterstützend mitwirken kann.Schon im Service Desk werden Incidents bezüglich ihrer Dringlichkeit priori-siert. Wurde ein Incident als dringlich eingestuft, weil z. B. die Erfüllung einerServicevereinbarung nicht gewährleistet ist, so ist auch der dazu gehörige RfC inden meistens dringlich. Ist dies der Fall, durchläuft der RfC ein verkürztes Ver-fahren, wobei hier die Sicherheit nicht vernachlässigt werden darf. Besonders beiSicherheitspatches besteht eine hohe Brisanz. Diese sind meistens dringend undgreifen teilweise tief in bestehende Funktionalitäten und Prozesse ein.[Bsi05, S.20] Hier müssen mit besonderer Vorsicht genaue Vorgaben definiert werden, umein Ausgleich zwischen dem Termindruck und der Sicherheit zu erzielen. Im zwei-ten Schritt wird überprüft, ob die Informationssicherheit betroffen ist. Wenn der


Request for Change

Dringender Change ?

Informationssicherheit betroffen ?

Datenschutz betroffen ?

Smoke TestTest der Informationssicherheit

Abnahme

Abbildung 3.4: Abnahme von RfCs. Quelle: [Bru06, S. 82].

RfC Auswirkungen auf die Informationssicherheit hat, wird überprüft, ob dieSicherheitsziele des SLA berührt werden. Können diese nicht eingehalten wer-den oder ist die Einhaltung der Verfügbarkeit, Integrität oder Vertraulichkeitnicht 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 esvom Security Management abgelehnt wurde. Das liegt daran, dass das CABSchwerpunkte auf andere Aspekte, wie z. B. das Kosten-Nutzen Verhältnis einesChange, legt. Im dritten Schritt wird überprüft ob der Datenschutz betroffenist. Hierbei sollte z. B. bei Änderungen der Zugriffsrechte oder bei Software zurVerwaltung der persönlichen Daten des gesamten Personals geprüft werden, obdiese ausreichend vor Fremdeingriffen geschützt sind. Nachdem diese Schrittedurchlaufen sind, muss das Security Management Abnahmekriterien definieren,anhand derer die Freigabe durch das Security Management erfolgt. Diese wer-den auch bei dringenden Changes angewandt, die in Form eines sogenanntenSmoke-Tests durchgeführt werden. Der Smoke-Test ist eine oberflächliche Über-prüfung bzgl. der Grundfunktionalität einer Software nach deren Fertigstellungoder Reparatur. Wenn die RfCs positiv bezüglich der Sicherheitsziele getestetwurden, können sie aus Sicht des Security Managers freigegeben werden.In der letzten Phase werden beim Rollout durch ausgiebige Tests nicht nur dieKorrektheit einer bestimmten Funktion getestet, sondern auch die Erreichungund Einhaltung der Sicherheit. Insbesondere muss darauf geachtet werden, dassnicht neue Lücken oder Hintertüren in Software-Applikationen entstehen unddie einmal erreichte Sicherheitsstufe nicht beeinträchtigt werden. Im Falle desScheiterns der RfCs bei diesen Tests, sollten, um die Informationssicherheitzu gewährleisten, angemessene Rückfallverfahren bereit stehen, mit denen derursprünglichen Zustand schnell wieder hergestellt werden kann. In vorherigenKapitel 3.3.3 (Problem Management) wurde schon erwähnt, dass bei der Pla-nung der RfCs das Security Management einbezogen werden soll. Durch dieseEinbindung sinkt die Wahrscheinlichkeit für die Entstehung neuer Sicherheits-lücken und damit für die Ablehnung der RfCs enorm. Bei einer schnelleren und


wahrscheinlicheren Freigabe der RfCs aus sicherheitstechnischen Aspekten kannzusätzlich die Verfügbarkeit im Unternehmen gesteigert werden. Diese Aspek-te zeigen die Chancen, die sich bieten, wenn das Security Management in dasProblem- und Change Management früh eingebunden wird. Dafür muss zwin-gend ein Mitarbeiter aus dem Security Management ein ständiges Mitglied imCAB sein. Dieser soll verhindern, dass RfCs, die ursprünglich nichts mit derInformationssicherheit zu tun haben, fälschlicherweise Sicherheitslücken aufsto-ßen.

3.3.5 Release Management

Während das Change Management der Initiator aller Änderungen innerhalbeiner IT-Infrastruktur ist, diese realisiert und die Verantwortung dafür trägt,liefert das Release Management die „Verfahren von der Anforderungsbearbei-tung über die Planung der Umsetzung, Test und Abnahme von Soft- und Hard-wareversionen bis hin zur organisatorischen und technischen Vorbereitung derEinführung einer Komponente.“[Bsi05, S. 20] Dabei werden die Konfigurations-elemente üblicherweise nicht einzeln implementiert, sondern zu einem Paket, dersogenannten Release Unit16 gebündelt. Die Einführung solcher Release Units hatden Vorteil, dass der Aufwand für das Testen und die Inbetriebnahme erheblichreduziert werden kann.Die zentrale Aufgabe des Release Management in diesem Bezugsrahmen ist es,mit Hilfe geeigneter Maßnahmen sicherzustellen, dass bei der Einführung ei-nes Release keine unerwünschten Nebeneffekte oder Fehler auftreten. So gab esin der Vergangenheit Fälle, in denen Unternehmensnetzwerke durch das Upda-te eines Anti-Virenprogramms lahm gelegt wurden, da dieses irrtümlicherweiseunternehmenseigene Software als Virus erkannte und schließlich deaktivierte[Bsi07, S. 3]. Der wirtschaftliche Schaden kann in solchen Fällen schnell ein im-menses Ausmaß annehmen. Geht man bspw. von 500 Usern eines DV-Verfahrensmit einem Durchschnittsstundenlohn von ca. 50 Euro/Stunde aus, so gehen mitjeder Ausfallstunde 25.000 Euro an potentieller Arbeitsleistung verloren. (Bei-spiel ähnlich zu [Köh06, S. 103]) Dieses Beispiel verdeutlich unter anderem, dassdie Notwendigkeit besteht Sicherheitsüberlegungen in den Prozess des ReleaseManagements mit einzubeziehen.Der Prozess des Release Managements, welcher durch einen vom CAB freige-gebenen RfC, ausgelöst wird [Bru06, S. 90], lässt sich dabei im Allgemeinen indrei Phasen einteilen:

• Planungs- und Entwicklungsphase

• Testphase

• Planung und Autorisierung des Rollouts

Die Möglichkeit Security Aspekte in das Release Management mit einfließen zulassen, ergibt sich während all dieser drei Phasen.

Planungsphase. Auf dieser ersten Stufe werden zunächst grundsätzlich Re-geln hinsichtlich eines Release oder der Release Unit definiert und in der Release

16Release: Englischer Begriff für Version


Testphase Rollout-PhasePlanungsphase

Release-Grundsätze

Release-Planung

Softwareentwickelnoderbeauftragen

Releasezusammenstellenund konfigurieren

TestundAbnahme

Rollout-Planung

Kommunikation,Verbreitung,Training

Verteilungund Installation

Abbildung 3.5: Phasen des Release Management Prozesses und Aufgaben.

Policy festgehalten. Das Security Management sollte schon in dieser frühen Pha-se wirksam werden und dem Release Management Vorgaben über bestimmteSicherheitsanforderungen machen, etwa bzgl. der in Kapitel 3.2.1 vorgestelltenHauptwerte der Informationssicherheit. Ansonsten bleibt dem Security Mana-gement nur noch die „Rolle des Verhinderers“[Bsi05, S. 12] im Vorfeld einesRelease, sofern dieses Sicherheitsrichtlinien verletzt.In der Release Policy, die ein wesentlicher Bestandteil des Release ManagementProzesses ist, sollte ebenfalls fest verankert werden, dass sofern sicherheitsrele-vante Patches verfügbar sind, diese eingespielt werden und nicht erst bis zumnächst größeren Update gewartet wird. Dieses standardisierte Vorgehen ermög-licht es, potenzielle Sicherheitslücken frühzeitig zu beseitigen.Schließlich kann das Security Management noch bei der Planung lösungsspezifi-scher Releases mit einbezogen werden. Das Security Management kann hierbeientwicklungsbegleitend und unterstützend tätig werden, in dem es Risiko- undSicherheitskriterien fixiert, die während der Release Planung einzuhalten sind.

Testphase. Damit der reibungslose und funktionierende Ablauf des Systemsnicht gestört wird, werden auf der zweiten Stufe die jeweiligen Releases vorihrer Einführung diversen Tests sowie einer Qualitätsprüfung unterzogen. Dabeisoll in einer möglichst „produktionsidentischen Testumgebung“[Bru06, S. 91]sichergestellt werden, dass durch das Release keine der, in der Planungsphasedefinierten, Sicherheitskriterien verletzt und die Anforderungen an Stabilität,Verfügbarkeit und Integrität eingehalten werden.[Bsi05, S. 21] Hierbei kann aufdas Know-how des Security Management zurück gegriffen werden. Es liefert dieentsprechenden Testverfahren.Sofern das Release die Anforderungen erfüllt, erteilt das Security Managementdie erforderliche Freigabe aus seinem Blickwinkel.

Rollout-Planung Mit der Freigabe des Releases beginnt die letzte Phasedes Release Management Prozess, das sogenannten Rollout17. Der Rollout Plan

17Englischer Begriff, der das Verteilen, Ausliefern und Ausführen von Soft- und Hardware-releases beschreibt.


beinhaltet alle Regeln und Vorgaben, die bei der Implementierung des Releasesdurch das Change Management beachtet werden müssen. So wird bspw. festge-halten, wie im Falle eines nicht erfolgreichen Rollouts zu verfahren ist, d. h. obein Fallback18 oder ein Backout19 durchzuführen ist. Das entscheidende Kriteri-um, welches in diesem Kontext beachtet werden muss, ist die Verfügbarkeit desSystems.Ferner muss bei der Rollout Planung die Nachvollziehbarkeit bzw. Revisions-fähigkeit der Änderungen an der IT-Infrastruktur sichergestellt werden. EineÜbersicht über alle Änderungen liefert dem Security Management die Grundla-ge für eine releaseübergreifende Risikobetrachtung.[Bru06, S. 92] So sollte manbspw. darauf bedacht sein, risikobehaftete Releases zu unterschiedlichen Zeit-punkten zu implementieren, um nicht zusätzlich die Verfügbarkeit des Systemszu gefährden.Abschließend sei angemerkt, dass nicht nur das Release Management von derBerücksichtigung sicherheitsrelevanter Aspekte profitiert, sondern sich auch vor-teilhafte Synergieeffekte für das Security Management ergeben. Auf Software-Ebene etwa werden Sicherheitslösungen und -patches im Rahmen des ReleaseManagement Prozesses geplant und realisiert. Von einer kooperativen Zusam-menarbeit profitieren sowohl Release als auch Security Management.


Die Erfordernisse an die Datenverarbeitungsverfahren aus Sicht der Geschäfts-prozesse eines Unternehmens haben in den letzten Jahrzehnten erheblich zuge-nommen. Immer mehr Detailinformationen, etwa bzgl. der Konfigurationsele-mente müssen erfasst, kontrolliert und verifiziert werden.Genau an diesem Punkte setzt das Configuration Management an. Die zentraleAufgabe des Configuration Management besteht darin, die sogenannten Con-figuration Items20 (CI) einer IT-Infrastruktur zu erfassen sowie deren Bezie-hungen 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 Netz-werkkomponenten, Datenträger sowie Dokumentationen dazu.[Bru06, S. 84] Umbei der Vielzahl an CIs Verwechselungen auszuschließen, ist jedes CI grundsätz-lich durch einen eindeutige Identifikationsnummer gekennzeichnet.Das Configuration Management ist der zentrale Prozess innerhalb des ServiceSupports. Er schafft die Informationsgrundlage für die weiteren Prozesse, in-dem eine Übersicht über alle CIs, deren Attribute sowie deren Beziehungenzueinander, geliefert wird. Archiviert und bereitgestellt, wird diese Vielzahl anInformation in der Configuration Management Database (CMDB), auf die eben-falls andere Prozesse, wie etwa Problem- oder Incident Management zugreifenkönnen. Tritt bspw. bei einem bestimmten CI ein Incident oder Problem auf, sogenügt ein Blick in die CMDB, um abschätzen zu können, welche weiteren CIsunter 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än-gig zu machen. Durch ein Backout wird ein neues Release definiert.“[Bru06, S. 93]

20Englischer Begriff für Konfigurationselement. Dieser wird im Folgenden an Stelle des Be-griffs Konfigurationselement verwendet.


somit neben der Infrastrukturtransparenz eine Servicetransparenz.Durch die Verzahnung mit den anderen Prozessen des Service Supports bie-tet das Configuration Management optimal Voraussetzungen, um verschiedeneAspekte des Security Management darin zu integrieren. Möglichkeiten dazu er-geben sich bereits und vor allem während der Configurations-Planung. In derPlanungsphase wird unter anderem das Design der CMDB festgelegt, welchesfür ein funktionierendes Configuration Management von elementarer Bedeu-tung ist. Eine gut geführte und aktuelle CMDB kann sich innerhalb kurzerZeit zu einem universellen Werkzeug auch aus Sicht des Security Managemententwickeln.[Bsi05, S. 22]

Klassifikation. Bevor ein CI in die CMDB aufgenommen wird, muss er an-hand 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, Verant-wortlichkeit oder Version sowie einen Status (funktionsfähig, fehlerhaft, Kon-trolle, etc.).[Köh06, S. 60] Zusätzlich werden, wie bereits erwähnt, die Abhän-gigkeiten zu anderen CIs erfasst. Ergänzt man dieses bestehende Beziehungsge-flecht um die drei Hauptwerte der Informationssicherheit (Verfügbarkeit, Inte-grität und Vertraulichkeit), eröffnet dies Chancen und Möglichkeiten sowohl fürSecurity- als auch Configuration Management.21

ConfigurationItem

Name undBeschreibung

Version

Standort

ID-Nummer

Verantwortlichkeit

Beziehungzu anderen CI´s Klassifikation

bzgl. Informations-Sicherheit

Abbildung 3.6: Erweiterte Attribute eines Configuration Item.

Eine um diese Faktoren erweiterte CMDB liefert Transparenz über die sicher-heitsrelevanten Abhängigkeiten der CIs, ermöglicht es Schwachstellen innerhalbdes Configuration Management zu identifizieren und liefert die Basis für Aus-fallanalysen. Ferner wird es möglich, spezielle Maßnahmen und Verfahren fürCIs zu planen bzw. zu ergreifen, die eine bestimme Klassifikation hinsichtlichder Informationssicherheit erhalten haben.Die Klassifizierung der CIs muss hierbei von den jeweiligen Prozessverantwort-lichen vollzogen werden, da nur diese die notwendigen Kenntnisse über die be-reichsspezifischen Sicherheitsanforderungen haben.

21Die in Kapitel 3.2.1 vorgestellten Dimensionen, Zurechenbarkeit und Rechtsverbindlichkeitwerden ebenfalls durch eine gut geführte Dokumentation innerhalb der CMDB unterstützt.


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 Vorder-grund sollte dabei nicht eine möglichst exakte Klassifizierung stehen, sonderndass überhaupt eine solche vollzogen wird.

Klassifikation KriteriumStreng geheim Zusammenhang mit strategischen Informa-

tionen, Betriebsgeheimnissen, Rezepturen,Patenten und Kalkulationen

Vertraulich Zusammenhang mit interne Informationen,z.B. Preislisten, Besprechungsnotizen, Per-sonaldaten

Eingeschränkt Zusammenhang mit Informationen, diedurch Dritte eingesehen werden können,aber nicht für diese bestimmt sind

Tabelle 3.1: Klassifikation Vertraulichkeit. Quelle: [Bru06, S. 87].

Klassifikation KriteriumAbsolut keine Ausfallzeiten gestattetHoch maximale Ausfallzeit 30 MinutenMittel maximale Ausfallzeit 4 StundenNiedrig 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 Daten-bank verkraftet oder wie viele Verbindungsfehler in einem Netzwerk auftretendürfen. Der aktuelle Grad an Integrität lässt sich ebenfalls schwer quantifizie-ren. Aus diesem Grund findet deshalb in der Regel ein zweistufiges Klassifizie-rungssystem Anwendung.[Bru06, S. 88] Dabei wird zunächst für alle CIs eineBaseline Integrität festgelegt, bspw. eine bestimmte Anzahl tolerierter Verbin-dungsabbrüche oder die Anzahl fehlerhafter Datensätze und auf zweiter Stufeeine erweiterte Integrität, die sich nach den jeweiligen Anforderungen des CIsrichtet.In Bezug auf die Klassifikation bleibt abschließend anzumerken, dass es nichterstrebenswert ist, für alle CIs eine solche vorzunehmen, schon alleine im Hin-blick auf die Beherrschbarkeit der stetig wachsenden Datenmenge eines Unter-nehmens. Ebenso sprechen Praktikabilitätsgründe gegen die Einstufung einesjeden CIs, da der Aufwand im Verhältnis zum Nutzen zu groß ist. Vielmehrsollten überhaupt Risikoüberlegungen bzgl. der Informationssicherheit in Formvon Klassifizierung im Prozess des Configuration Management Berücksichtigungfinden. Ein Anfang kann hierbei mit den CIs gemacht werden, für die besondereAufmerksamkeit in puncto Verfügbarkeit, Vertraulichkeit und Integrität gilt.

Weitere Synergieeffekte. Neben der vorgestellten Klassifizierung gibt es ei-ne Reihe weiterer Möglichkeiten die Schnittstellen zwischen Security und Confi-guration Management zu nutzen. Eine davon sind so genannte Audits der CMDB


in Bezug auf die Sicherheit. Darunter versteht man einen Soll-Ist-Vergleichzwischen dem dokumentierten/geplanten Bestand der CMDB und dem tat-sächlichen Bild, welches die IT- Infrastruktur liefert. Durch diese regelmäßi-gen Scans/Audits und Abgleich mit der CMDB lässt sich mit relativ geringemAufwand installierte, unautorisierte Software identifizieren. Die Auswahl undImplementierung eines geeigneten Tools liegt dabei im Verantwortungsbereichdes Security Managements.Auf Hardwareebene steigt die Transparenz mit jedem Incident oder RfC, da nurfür bekannte CIs solche aufgegeben werden können. Jeder Change oder Incidentführt dazu, dass noch nicht erfasste CIs in die CMDB aufgenommen werden.Mit Hilfe dieses standardisierten Vorgehens werden automatisch Gefahren redu-ziert, die bspw. von nicht erkannten Verbindungen ausgehen. So stellt ein un-bekanntes, aktives Modem in einem Notebook eine erhebliche Sicherheitslückedar.[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 dieAnalyse von Security Incidents, da in der CMDB die Historiendaten inklusi-ve aller Changes revisionssicher gespeichert sind. Somit ist auch die Rechts-verbindlichkeit als eine weitere Dimension der Informationssicherheit sicherge-stellt. Zudem ermöglichen ausführliche Installations- und Systemdokumentatio-nen nicht nur im Wiederholungsfall eine schnellere Installation, sondern hel-fen auch bei der Ursachenforschung im Problemfall, bspw. können im Falle ei-nes Hacker-Angriffs frühzeitig unbefugte Veränderungen am System identifiziertwerden.[Bsi07, S. 25]Eine ganz entscheidende Frage, welche letztlich im Zusammenhang mit derCMDB geklärt werden muss, ist: Wer erhält hierauf Lesezugriffsrechte und werdarf den Datenbestand verändern? Die Notwendigkeit die Zugriffsrechte zu be-schränken und zu kontrollieren, ergibt sich aus der Tatsache, dass die CMDBstreng vertrauliche Informationen (physisch, organisatorisch, finanziell) über diejeweiligen Geschäftsprozesse enthält. Ein Verlust der Verfügbarkeit, Integritätoder Vertraulichkeit dieser Daten kann mit erheblichen wirtschaftlichen Kon-sequenzen verbunden sein. Die Verantwortung dieses sicher zu stellen tragensowohl Security als auch Configuration Management.

3.4 Fazit

Die Auseinandersetzung mit dem Thema Informationssicherheit ist ein absolu-tes Muss für die Zukunftssicherung einer Unternehmung. Ein funktionierendesIT-Security Management liefert hierzu einen wesentlichen Beitrag. Für viele istder Begriff Security Management dabei gleichbedeutend mit dem Einsatz vonTools und Sicherheitslösungen zum Schutz vor potenziellen Bedrohungen. Ei-ne andere Herangehensweise ist die Integration dieser Maßnahmen und Ideenin einen standardisierten, prozessorientierten Ansatz, wie ihn das RahmenwerkITIL bietet.Vordergründiges Ziel dieser Arbeit war es, die Chancen und Möglichkeiten desZusammenwirkens von IT-Security Management und den Prozessen des ServiceSupports darzustellen. Ferner sollte ein kurzer Überblick über das Thema IT-Sicherheit geliefert werden. Dazu wurden zu Beginn der vorliegenden Arbeitgrundlegende Begrifflichkeiten von der Informationssicherheit bis hin zum Se-


curity Management erläutert. Im dritten Kapitel, dem Hauptteil der Arbeit,wurden dann zunächst die Prozesse des Service Supports vorgestellt und an-schließend die sich bietenden Synergieeffekte aufgezeigt.Im Rahmen dieser Analyse hat sich gezeigt, dass das Security Management be-reits bei der Implementierung der Service Support Prozesse einzubeziehen istund sich die größten Potenziale während der Gestaltungs- und Planungsphasenbieten. Aus Sicht des Security Managements liegt die Stärke dieses Ansatzesin der frühzeitigen Berücksichtigung der Sicherheitsaspekte und -anforderungenwährend aller Support Stufen sowie der ausführlichen Dokumentation von Si-cherheitsvorfällen und deren Lösungen. Der Service Support profitiert nebenden Risiko- und Kritikalitätsüberlegungen von geeigneten Test- und Abnahme-verfahren, die das Security Management bereitstellt.Trotz dieser Möglichkeiten, die die Verknüpfung von Service Support und Se-curity Management im Zuge der Neustrukturierung gemäß ITIL bietet, bleibtabschließend anzumerken, dass eine Wirtschaftlichkeitsbetrachtung nicht außerAcht gelassen werden darf. Hierzu sind die Einspareffekte, die durch ein wirk-sameres und effizienteres Security Management entstehen, den Kosten für dieImplementierung gegenüber zu stellen. Mit Hilfe geeigneter Key Performace In-dikatoren, wie bspw. die Prozentzahl der zurückgegangenen Sicherheitsvorfälleund durch die gestiegene Transparenz und Messbarkeit der IT-Leistung dürftediese Wirtschaftlichkeitsprüfung letztlich unproblematisch sein.



[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, ViewegVerlag, 1.Auflage 2006

[Bsi05] Bundesamt für Sicherheit in der Informationstechnik: ITIL undInformationssicherheit, 2005, URL:www.bsi.de/literat/studien/ITinf/itil.pdf, [18.12.07]

[Bsi07] Bundesamt für Sicherheit in der Informationstechnik: LeitfadenIT-Sicherheit, 2007, URL:www.bsi.bund.de/gshb/Leitfaden/GS-Leitfaden.pdf, [09.01.08]

[Die04] Dierstein, Rüdiger: Sicherheit in der Informationstechnik - der BegriffIT-Sicherheit. In: Informatik Spectrum August 2004 S. 343-353

[Iti07] ITIL.org: Das Portal für Informationen rund um ITIL undISO20000, 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 stuernund planen, Perseo Consult, 1. Auflage 2002

107

http://www.iznnet-kom.niedersachsen.de/IT-Sicherheit/downloads/BMI-itil_und_informationssicherheit_v101.pdf

http://www.iznnet-kom.niedersachsen.de/IT-Sicherheit/downloads/BMI-itil_und_informationssicherheit_v101.pdf

www.bsi.de/literat/studien/ITinf/itil.pdf

www.bsi.bund.de/gshb/Leitfaden/GS-Leitfaden.pdf

http://www.itil.org/de


Kapitel 4

ITIL-unterstützendeWerkzeugeFormulierung von Anforderungen entlang des Ser-vice Supports

Sonja Bozionek, Linda Gerstenberger, Kathrin Stegmann

4.1 Einleitung

Der Übergang von einer technischorientierten zu einer dienstleistungsorientier-ten IT-Organisation hat in den letzten Jahren an Bedeutung gewonnen.[Nie07]Die Schaffung von standardisiertem Informationsfluss und das Bestreben gewon-nene Informationen für eine optimalere (Kunden-)Nutzung in geregelte Formenzu bringen, sind nur einige Gründe, die für eine verstärkte Standardisierung derIT sprechen. Gleichzeitig ist auch eine stärkere Serviceorientierung seitens derUnternehmen zu nennen. Im Zusammenhang mit diesem Übergang ist auch derBegriff der IT Infrastructure Library (ITIL) in den letzten Jahren in Deutsch-land verstärkt im Fokus des Interesses.[Its07]Bei der Einführung von ITIL stellt sich unter anderem die Frage, ob software-unterstützende Werkzeuge bei der Umsetzung und zur Effizienzsteigerung ein-gesetzt werden. Grundsätzlich ist es nach ITIL freigestellt, ob unterstützendeWerkzeuge verwendet werden sollen oder nicht. Interessant ist dann, ob ein ein-gesetztes Werkzeug die Arbeit erleichtert und sie effizienter gestalten kann.Ziel dieser Arbeit ist es, sowohl Anforderungen an ein potentielles Werkzeug ent-lang des ITIL-Prozesses im Service Support herauszuarbeiten, als auch die sichergebenden Anforderungen mit den Funktionen von zwei ausgewählten Werk-zeugen zu vergleichen.Die Arbeit gliedert sich in einen Grundlagen- und einen Hauptteil sowie in einFazit. Im Grundlagenteil wird zunächst das Verständnis der Begriffe ITIL undWerkzeuge für diese Arbeit aufgeführt. Im Anschluss daran werden im Hauptteildie 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 sichdie Betrachtung der Werkzeuge an, wobei eine Unterscheidung in kommerziel-le und open-source Werkzeuge vorgenommen wird. In einem Fazit werden diewichtigsten Ergebnisse dieser Arbeit abschließend pointiert wiedergegeben.

4.2 Begriffsabgrenzungen

4.2.1 ITIL

In der heutigen Zeit wird es immer schwieriger, den Anforderungen einer IT-Infrastruktur innerhalb von Unternehmen zu genügen und auf einem bestimm-ten Qualitätsniveau zu halten. Für jedes Unternehmen ist es daher wichtig, dieIT-Struktur an neue Anwenderbedürfnisse auszurichten und den neuen Anforde-rungen anzupassen. Um diese Dienstleistung zu gewährleisten, wird versucht, dieStruktur innerhalb der IT bezüglich der Ausfallhäufigkeit oder der Verfügbarkeitzu optimieren. Dieser Ansatz wird auch als IT Service-Management bezeichnetund wird durch den ITIL-Leitfaden unterstützt. ITIL ist eine Sammlung vonBüchern, in denen ein Rahmenwerk von IT-Service-Managementprozessen be-schrieben wird. Es existiert zu jedem Prozess ein Leitfaden sowie Empfehlungenzur Umsetzung. ITIL ist somit kein Programm, sondern fungiert als Richtliniezur Strukturierung der eigenen IT-Abteilung im Unternehmen. ITIL hat sichim Laufe der Zeit als defacto Standard etabliert und ist mittlerweile weiträumigverbreitet.[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 Prozesseinnerhalb dieses Bereichs stattfinden, zeigt die folgende Abbildung.

Formulierung von Anforderungen entlang des Service Supports 111

Abbildung 4.2: Überblick Service Support. Quelle: Eigene Darstellung.

Entlang dieser Prozesse werden im Kapitel 4.3 die Anforderungen an ein Werk-zeug herausgearbeitet.

4.2.2 Werkzeuge

Unter (ITIL)-Werkzeugen1 werden im Verlauf dieser Arbeit Computerprogram-me verstanden, welche die Implementierung und Umsetzung von ITIL in denUnternehmen unterstützen.[Nie07] D.h. unter einem Tool wird eine Softwareverstanden, die die veränderte Situation im Unternehmen jetzt und in Zukunftunterstützt. Die Auswahl von Tools gestaltet sich insofern als schwierig, als dassin den ITIL-Büchern keine Bewertung der vorhandenen Tools vorgenommenwird und konkrete Aussagen ausbleiben.[Bre07]Am Markt ist verschiedene Software erhältlich. Zu unterscheiden sind open-source Lösungen, die im Internet frei verfügbar sind und kommerzielle Angebote.Im Rahmen dieser Projektarbeit wird die Software Open Ticket Request Sys-tem (OTRS) näher betrachtet. Aus der Vielzahl kommerzieller Produkte wirdbeispielhaft 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 Personengleichzeitig Kundenanfragen und -aufträge verwalten können. Wesentlicher Be-standteil dieser Software ist das Ticket. Dabei ist es unerheblich, über welcheMedienart die Anfrage im System eingeht. Innerhalb dieser Software bestehtdie Möglichkeit, diese Aufträge zu klassifizieren, zu bearbeiten oder sie weiter-zuleiten. Wird eine bereits bekannte Anfrage an das System geschickt, erstelltdas Programm automatisch eine Verknüpfung zu dem schon gespeicherten Vor-gang. Der Supportleistende kann das Ticket öffnen, und sich vorab Informa-

1Die Bezeichnungen "Werkzeug" und "Tool" werden in dieser Arbeit im weiteren Verlaufsynonym verwendet.

2Synonym wird die Bezeichnung Trouble-Ticket-System verwendet.


tionen zu dem vorliegenden Problem verschaffen. Es werden allgemeine Datengespeichert, welche wiederum zur Problemlösung verwendet werden können. DieMöglichkeit zur Dokumentation der gesamten Daten wird auch Historiefunkti-on genannt.[Cla] Ist das Problem letztendlich gelöst, spricht man vom Schließendes Tickets.[Här07] Auf die genauere Ausgestaltung eines Ticket-Systems wirdbei der Betrachtung von OTRS und Remedy näher eingegangen.

4.3 Service Support und Anforderungen an dieWerkzeuge

4.3.1 Vorgehensweise

Nachdem bisher ITIL und das Verständnis von Werkzeugen erläutert wurde,werden im Folgenden die einzelnen Prozesse von ITIL näher betrachtet. DerFokus liegt hier ausschließlich auf dem Bereich des Service Support, da eine um-fassendere Betrachtung im Rahmen dieser Arbeit aus zeitlichen Gründen nichtmöglich ist. Dieses Kapitel gliedert sich somit in die einzelnen Prozesse des Ser-vice Support, dem Incident Management, dem Problem Management, sowie demChange Management, dem Release Management und dem Configuration Mana-gement. Es wird jedoch nicht nur ein Einblick in den jeweiligen Prozess gegeben,sondern vielmehr ist an dieser Stelle von Bedeutung, welche Anforderungen sichjeweils für eine mögliche Softwareunterstützung durch ein eingesetztes Tool er-geben. Prinzipiell besteht durchaus die Möglichkeit, die Grundsätze von ITIL imeinfachsten Fall mit Papier und Bleistift umzusetzen.[Mar04] Durch eine Soft-wareunterstützung aber kann sich bei passendem Einsatz eine erhebliche Effi-zienzsteigerung ergeben, da ein größerer Informationsfluss schneller verarbeitetwerden kann. Sobald Tätigkeiten gehäuft und wiederholt vorkommen, kann essich lohnen, Aktivitäten durch Einsatz einer geeigneten Software zu automati-sieren. Doch was genau müsste eine ITIL-konforme Software können? WelcheFähigkeiten müsste sie haben, um den Menschen zu entlasten und dabei dieeinzelnen Prozesse des Service Support funktionsfähig und zielführend abzubil-den? Diese Anforderungen an ein Tool werden jeweils in den einzelnen Kapitelnherausgearbeitet, um in Kapitel 4.4 die Funktionen der Werkzeuge OTRS undRemedy darzustellen.

4.3.2 Incident Management mit Service Desk

Das Incident Management bildet in Verbindung mit dem noch zu erläuterndenService Desk die Schnittstelle zwischen Anwender/ Kunden und dem Unterneh-men. Primäres Ziel ist es, den IT-Service bei einem Incident wieder herzustellenund aufrecht zu erhalten.ITIL fasst unter der Bezeichnung Incident Störungen und Service Requests zu-sammen. Für die weitere Betrachtung werden zunächst die Begriffe Störungenund Service Requests definiert. Ursächlich für eine Störung und auch einen Ser-vice Request sind jeweils auftretende Anliegen. Unter einer Störung wird dabei"ein Ereignis [verstanden], das nicht zum standardmäßigen Betrieb eines Ser-vice gehört und das tatsächlich oder potentiell eine Unterbrechung oder Minde-rung der Servicequalität verursacht." [Its07] Anfragen, welche keine Störungen


im eigentlichen Sinne sind, werden unter dem Begriff Service Requests zusam-mengefasst. Darunter fallen unter anderem Statusnachfragen und Fragen zurHandhabung.Die Aufnahme einer Störung im Service Desk ist dabei als Ausgangspunkt fürdas Incident Mangement zu nennen, und den Abschluss bildet dann die Wieder-herstellung des Service. Bei der Bearbeitung der Störung unterscheidet manzwischen verschiedenen Leveln, dessen grobe Einschätzung im Service Deskstattfindet. Es erfolgt häufig eine Gliederung in verschiedene Ebenen oder Bear-beitungsstufen. Bezeichnet wird das als Multi-Level-Support-Modell. EinfacheProbleme oder Anfragen können oftmals direkt gelöst werden und werden alsFirst-Level-Support bezeichnet. Diese werden durch den Service Desk bearbeitetund abgeschlossen.Kompliziertere oder umfassendere Anliegen werden vom Service Desk weite-geleitet und dort durch Fachkräfte oder Teams im Rahmen des Second-Level-Supports 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 befas-sen. Hier wird deutlich, dass es eine klare Abgrenzung der Kompetenzen gebenmuss. Dies gilt nicht nur für das Incident Management, sondern auch für dieOrganisation aller weiteren Prozesse. Eine zentrale Stellung hat in diesem Be-reich der bereits erwähnte Service Desk, welcher nun im Folgenden betrachtetwird.[Its07]

Service Desk Da der Service Desk nach ITIL kein Prozess sondern eine Funk-tion ist und damit eine Aufgabe erfüllt, wird er in dieser Arbeit innerhalb diesesKapitels betrachtet. Außerdem liefert er nicht nur dem Incident Management,sondern auch den Service Support-Prozessen Problem Management, ChangeManagement, Release Management und Configuration Management wichtigeInformationen.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 ge-wünschten IT-Service. Diese Kommunikationsstelle wird auch als Single Pointof Contact (SPOC) bezeichnet.[Fis06] Synonym zum Service Desk wird auch dieBezeichnung Help Desk verwendet.3 Zu den allgemeinen Aufgaben des ServiceDesk zählen im Wesentlichen die Entgegennahme der Anliegen des Kunden. Imweiteren Verlauf wird das Anliegen konkretisiert, also ob es sich um eine An-frage eines Kunden im Sinne einer Änderung (Request for Change) handelt,oder ob es sich um eine Störung (Incident) handelt. Jeder dieser Vorgänge wirdumfangreich dokumentiert und gespeichert, um bei Bedarf jederzeit darauf zu-rü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 nichtsofort erledigt werden kann.Es gibt unterschiedliche Möglichkeiten einen Help Desk zu organisieren. Zumeinen als zentrale Einheit, zum anderen als dezentrale Einheit. Ist der HelpDesk zentral organisiert, werden die Anliegen über einen SPOC koordiniert undbearbeitet, 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 Kon-

3Darunter wird der Service zur Unterstützung oder auch zur Hilfe von Anwendern vonHard- und Software verstanden.


taktpunkt hat. Er muss sich nicht verschiedene Kontaktadressen merken, son-dern kann seine Anliegen einer Stelle zutragen. Nachteilig bei dieser Varianteist, dass die Support-Mitarbeiter ein breiteres und umfassenderes Wissen fürdie verschiedenen Anfragen benötigen, um den Kunden kompetent zur Seite zustehen. Für dieses Wissen benötigen die Mitarbeiter weitere und permanenteSchulungen. Ist dieses Wissen nicht vorhanden, kontaktieren die Kollegen ausdem First-Level-Support öfter die Kollegen aus den anderen Supports, wobeies zu einer Verzögerung gegenüber dem Kunden kommen kann, weil der Kun-de länger auf seine Antwort warten muss. Des Weiteren kommt es so zu einerÜberlastung in den anderen Supporteinheiten. Bei einem dezentralen oder loka-len Help Desk gibt es einen Service-Support für verschiedene Kundengruppenoder verschiedene Produktgruppen. Hier erhalten die Kunden meist schnellereHilfe als im zentralisierten Fall, haben dadurch aber auch mehrere Kontakt-stellen. Problematisch kann sich hier die nicht einheitliche Datenbank erweisen.Mehrere Supporter arbeiten an einem Problem, ohne dass es in einer Dateigespeichert wird. Eine Lösungsmöglichkeit könnte der zentralisierte dezentraleAnsatz, welcher auch als virtueller Ansatz bezeichnet wird, sein. Hier existiertaus Sicht des Kunden nur ein Help Desk, also nur eine Kontaktstelle. Hinterdieser verbergen sich jedoch dezentral weitere Service-Desk Supports. Kann einMitarbeiter ein Anliegen nicht selber bearbeiten, wird es an den zuständigenHelp Desk weitergeleitet. [Els06, Bre07]Um im Folgenden aus den Aufgaben und Zielen des Service Desk und damitauch des Incident Managements Anforderungen an mögliche Software-Tools ab-zuleiten, wird der Prozess, der innerhalb der Service Desk abläuft, im Einzelnendurchgegangen. Dabei soll stets die Frage im Hintergrund stehen: An welchenStellen ist eine Unterstützung durch ein Software-Tool besonders sinnvoll? Undwelche Aufgaben müsste dieses Tool im Einzelnen übernehmen? Hierbei ist an-zumerken, dass der Prozess, der innerhalb des Service Desks abläuft, eng mitanderen Abläufen verknüpft ist. Eine klare Grenze zwischen den Bereichen kannnicht immer gezogen werden, so dass es zu einzelnen Überschneidungen kommtund ggf. auf die anderen Prozesse verwiesen wird.

First-Level-Support. Der Ablauf innerhalb des Service Desks gliedert sichin verschiedene Punkte.[Els06] Diese werden im Hinblick auf die obigen Fragenbetrachtet:

Anliegen entgegennehmen und registrieren: Die einzelnen Anliegen, dieim Service Desk als erste Anlaufstelle eingehen, können in verschiedenerForm vorliegen. Hier wären Anfragen in Form von E-Mail oder Telefondenkbar. Für eine sinnvolle Erfassung bzw. Dokumentation der Anliegensind im Vorfeld grundsätzliche Entscheidungen zu treffen. Es stellt sich dieFrage nach der Art der Dokumentation, also wie die Daten erfasst wer-den sollen. Des Weiteren müssen natürlich die spezifischen Gegebenheitendes 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 Kontaktaufnahmerelevant. Für die Erfassung von Anliegen ist es ratsam, zentral und geregeltvorzugehen, so dass keine Abhängigkeit von der willkürlichen Arbeitswei-se eines Service Desk-Mitarbeiters besteht. Es lässt sich somit festhalten,


dass die Mitarbeiter einheitlich vorgehen müssen. Die Dokumentation derAnliegen in einer Datenbank ist eine sinnvolle Vorgehensweise. Im Ge-gensatz zu einer einfachen Niederschrift des Problems kann mit Hilfe derDatenbank strukturiert vorgegangen werden. Das Tool soll den Mitarbei-ter des Service Desk dahingehend unterstützten, dass eine strukturierteErfassung des Anliegens möglich ist. So ist es für den Mitarbeiter zeit-sparend, wenn er die einzelnen Daten in einer bereits fertigen Maske indie dafür vorgesehenen Felder eintragen kann. Dadurch kann nicht nurZeit gespart werden, sondern es ist zudem noch gewährleistet, dass derMitarbeiter auch alle relevanten Informationen des Kunden strukturierterfasst. Es sollte möglich sein, die Anliegen der Kunden zu identifizie-ren, so dass eine mehrmalige Registrierung eines Anliegens ausgeschlossenwerden kann. Dies ist natürlich stets verbunden mit den jeweiligen spe-zifischen Gegebenheiten, die sich im Unternehmen wiederfinden. So sinddie Anliegen, welche im Service Desk eines Computerlieferanten auftretennatürlich andere, als die bei einem Telekommunikationsunternehmen.

Klassifizierung des Anliegens: Sobald der Mitarbeiter alle relevanten Da-ten des Vorgangs aufgenommen hat, muss er eine erste Einordnung desAnliegens vornehmen. Liegt bei dem Kunden keine Störung vor, sondernhandelt es sich um eine Anfrage für eine Änderung, leitet der Mitarbei-ter des Service Desks die Daten zum Change Management weiter. Derweitere Ablauf in diesem Fall wird somit bei der Behandlung des ChangeManagements wieder aufgegriffen. Wichtig ist hier, wie bei allen Interak-tionen zwischen den einzelnen Prozessen, dass eine gute und problemfreieKommunikation erfolgt. Liegt jedoch eine akute Störung beim Kundenvor, so muss der Mitarbeiter weitere Schritte einleiten, um die Störungmöglichst schnell weiter zu klassifizieren und bestenfalls sogar gleich zubeheben. Dazu muss er herausfinden, um welche Art von Störung es sichhandelt, oder ob das Problem evtl. sogar schon bekannt ist. Hierbei istes ein Vorteil für den Mitarbeiter, wenn er auf ein gutes Archiv vergan-gener Fälle zurückgreifen kann. Dies kann in kleinen Unternehmen oderin einem überschaubaren Umfeld natürlich eine selbst erstellte Liste odereinfach das Gedächtnis eines Mitarbeiters sein. Je größer ein Unternehmenjedoch ist oder je mehr Störungsfälle auftreten, umso schwerer wird es sichvorzustellen, dass der Mitarbeiter dies ohne technische Unterstützung leis-ten kann. So ist es für ihn an dieser Stelle hilfreich, wenn das manuelleSuchen in langen Archivlisten entfällt und ein Tool ihm die Möglichkeitbietet, per Schlagwortsuche nach vorherigen Störungsfällen zu suchen. Umeine Klassifizierung vorzunehmen, die nicht nur von der Entscheidung desMitarbeiters abhängt, kann eine Art Bewertungsbogen generiert werden,der aufgrund der Eingaben des Mitarbeiters auch eine Klassifizierung er-leichtert. Sobald der Mitarbeiter die Störung an dieser Stelle klassifizierthat, entscheidet sich sein weiteres Vorgehen. Liegt eine Störung vor, diezwar bekannt ist, er selbst jedoch nicht lösen kann, oder gibt es eine unbe-kannte Störung, erfolgt eine Weiterleitung im Incident bzw. zum ProblemManagement. Auch die Behandlung dieser Fälle wird an entsprechenderStelle wieder aufgegriffen. Handelt es sich jedoch um eine bekannte Stö-rung, zu dessen Lösung der Service Desk Mitarbeiter alleine in der Lageist, sollte er für eine weitere Unterstützung des Kunden sorgen.


Bearbeitung von Störungen: Nachdem die Störung klassifiziert wurde undbekannt ist, gilt es nun eine Lösung zu finden und die Störung zu beheben,da eine schnellstmögliche Wiederherstellung des Service das oberste Zieldes Service Desk ist. So gilt es auch an dieser Stelle Zeit zu sparen unddie Suche nach einer Lösung durch den Einsatz eines Software-Tools zubeschleunigen. So ist es sinnvoll, wenn bei der vorherigen Suche nach einerStörung auch gleich eine oder mehrere mögliche Lösungsvorschläge dazuvermerkt sind. Auch dies setzt das Vorhandensein und die kontinuierlichePflege eines guten und vollständigen Archivs voraus. Hat der Mitarbei-ter eine Lösung gefunden, kann dem Kunden geholfen werden und eineschnelle Wiederherstellung des Service erfolgen.

Abschluss & Speicherung des Lösungsweges in der Datenbank: Ist derService wieder hergestellt, muss der Vorgang abgeschlossen und das Pro-blem mit der Lösung in einer Datenbank vermerkt werden. Wie zuvorerläutert spart es viel Zeit, wenn der Mitarbeiter auf eine gut gepfleg-te Datenbank zugreifen kann. Ein Tool kann die Suche innerhalb dieserDaten vereinfachen, dies nützt jedoch nichts, wenn sie nicht durch dieMitarbeiter ständig gepflegt und aktualisiert wird. Nur durch die korrekteund vollständige Erfassung des Vorgangs durch den Mitarbeiter könnenfür zukünftig auftretende Probleme zeitnah Lösungen gefunden werden.

Falls das Problem innerhalb des First-Level-Supports nicht abgeschlossen wer-den 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ösungder Störung vorhanden ist, erfolgt nun die Weiterleitung an den Second-Level-Support. Dort beschäftigen sich spezialisiertere Support-Teams, die nach Fach-bereichen gegliedert sind, weiter mit dem Problem.[Its07]

Analyse und Diagnose: In diesem Bereich beschäftigen sich die Experten mitder weiteren Analyse, dessen Ziel die Diagnose der Störung ist. Da sie eingrößeres Fachwissen besitzen als die Service-Desk Mitarbeiter, findet hiereine intensivere Suche statt. Die Anforderungen an ein eingesetztes Toolsind ä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, findetein Abschluss der Störung statt. Dieser muss natürlich auch in der Daten-bank dokumentiert werden, so dass er für spätere Anliegen auch als Re-cherche zur Verfügung steht. Ist auch hier der Abschluss nicht möglich, soerfolgt eine Weiterleitung an den Third-Level-Support. Dieser besteht ausSpezialisten-Teams, die sich analog zum Ablauf im Second-Level-Supportmit dem Anliegen befassen. Dieser Vorgang wird auf N-Leveln wiederholt,bis die Störung abgeschlossen wird. Ggf. erfolgt eine Weiterleitung an dasProblem Management.

4.3.3 Problem ManagementVorangehend wurde das Incident Management betrachtet, dessen oberste Prio-rität die Wiederherstellung des Services ist. An dieser Stelle knüpft die Aufgabe


des Problem Managements an und bildet somit eine Art zweite Ebene des In-cident Managements. Dort werden die Ursachen, die einer Störung zugrundeliegen, meist nur sehr selten festgestellt. Sobald für einen Fall keine Ursachefestgestellt werden kann, bekommt ein Incident die Bezeichnung Problem. DieLösung dieser Probleme ist vielfach kompliziert und aufwendig, da unter ande-rem ein Problem durchaus auf mehrere Incidents zurückgeführt werden kannund sie wiederholt auftreten. So kann ein bestimmter Abbruch durch ein Auf-einanderfolgen bestimmter Fehlerquellen herbeigeführt werden. Um diese kom-plexen Vorgänge erfassen zu können, bedarf es anderer Prozessverläufe als beimIncident Management. So ist es Aufgabe des Problem Managements, die eigent-liche Ursache für das Auftreten von Störungen zu ermitteln. Die Auswirkungendieses Problems sollen minimiert und ein Lösungsweg zur endgültigen Beseiti-gung der Störung erarbeitet werden. Als Known Error wird dann ein Problem(oder Incident) bezeichnet, dessen Ursache bekannt ist. Außerdem sollte dasProblem Management versuchen bereits im Vorfeld, also proaktiv, das Auftretenvon Störungen durch vorbeugende Maßnahmen zu minimieren. Beispiele in derIT gibt es viele, wie Hardware-Fehler, Netzwerkfehler oder Betriebssystemab-stürze. Für diese Vorkommnisse können unterschiedliche Ursachen vorliegen, sodass durchaus zeitgleich verschiedene Experten einzubinden sind.[Fis06, Els06]Mit dem Problem Management werden verschiedene Ziele verfolgt. Dies ist zumeinen die Eliminierung der Ursachen der auftretenden Probleme und zum an-deren, ähnlich wie beim Incident Management, eine Aufrechterhaltung der IT-Dienstleistungen. Außerdem sollen hier durch vorausschauendes Handeln Pro-bleme und längerfristige IT-Systemunterbrechungen vermieden werden. Gege-benenfalls werden durch das Problem Management notwendige RFCs in derIT-Infrastruktur eingeleitet.In ITIL wird das Problem Management in drei Subprozesse unterteilt, die Pro-blem Control, die Error-Control und das Proactive Problem Management. Dieseumfassen sowohl reaktive als auch proaktive Aktivitäten. Während das reaktiveProblem Management nach Ursachen bereits eingetretener Störungen sucht undVerbesserungsvorschlägen macht, versucht das proaktive Problem ManagementSchwachstellen aufzuspüren und Störungen im Vorfeld zu verhindern. Wie dieAbläufe der einzelnen Prozesse des Problem Managements nun genau aussehenund welche Anforderungen sich an ein Software Tool dadurch ergeben, soll nunim Einzelnen herausgearbeitet werden.[Els06]

Problem-Control. Die Tätigkeitsfelder der Problem- und Error-Control sindverknüpft. Die Problem-Control befasst sich mit der Problembearbeitung. Indieser ersten Phase des Problem Managements werden die vom Service Deskund Incident Management weitergeleiteten Probleme beschrieben, klassifiziertund abgespeichert. Daran anschließend erfolgen die Untersuchung des Problemsund dessen Auswirkungen auf den Service. Soweit möglich sollen hier die Ursa-chen gefunden werden. Ist die Ursache gefunden liegt nun kein Problem mehrvor, sondern ein Known Error. Die fehlerhafte Komponente ist identifiziert, dasProblem ist jedoch noch nicht behoben. Für eine genauere Analyse wird derProzess der Problem-Control vereinfacht dargestellt.[Els06]

Klassifizierung und Kategorisierung des Problems: In dieser ersten Stu-fe treffen die Probleme ein, die durch das Incident Management von einerStörung zu einem Problem deklariert und weitergeleitet worden sind. Man


spricht von Problemen, wenn mit einem wiederholten Auftreten gerechnetwird. Bei der Identifikation müssen die Daten, die zu einem Problem gehö-ren, erfasst und in eine Datenbank eingestellt werden, ähnlich wie bei einerStö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 undvollständig zu erfassen, indem es durch eine fertige Maske dem Mitarbei-ter die Eingabe der Daten erleichtert und außerdem dafür sorgt, dass dieDaten auch von anderen Mitarbeitern schnell wiedergefunden werden kön-nen. Des Weiteren müssen die Probleme insofern klassifiziert werden, dasssie in unterschiedliche Gruppen unterteilt werden. Es muss erfasst werdenzu welcher Kategorie sie gehören, welche Auswirkungen es auf geschäftli-che Abläufe geben kann, welche Dringlichkeit dem Problem zugesprochenwird, welche Priorität es hat und wie der aktuelle Status des vorliegendenProblems lautet.[Its07] Auch zur Aufnahme dieser Daten kann ein Tooleine strukturierte Vorgehensweise ermöglichen und unterstützen.

Zuweisung zum Problem-Management Experten: Bevor die genaue Un-tersuchung und eine zeitnahe Lösung des Problems angestrebt werdenkann, müssen die Daten dem für das Problem zuständigen Experten zuge-wiesen werden. Dieses Vorgehen kann ein Tool insofern erleichtern, indemes nach der Klassifizierung des Problems die für das Problem verantwortli-che Person kennt, eine Verknüpfungen zu den zuständigen Problemlösernbereitstellt und diese Experten, z. B. per E-Mail automatisch über dasProblem inklusive aller darüber vorhandenen Daten informiert werden.

Analyse und Diagnose des Problems: Nun erfolgt eine Analyse der für dasProblem zuständigen Experten. Die Untersuchung und die Diagnose desProblems kann ein langwieriger Prozess sein, bei dem versucht wird her-auszufinden, welche Ursache einem Problem zugrunde liegt. Dazu werdenwiederholt Tests durchgeführt, um das Problem immer weiter einzukrei-sen. Hierbei findet ständiger Kontakt mit den anderen Prozessen statt.Hier müsste ein Tool in der Lage sein, sowohl den Verlauf eines Problemszu dokumentieren als auch die Interaktion mit den anderen Prozessenausreichend abzubilden. Wichtig ist hier, wie eigentlich überall, dass au-ßerdem eine gute und ständige Kommunikation zwischen den einzelnenProzessen stattfindet. Notwendige Informationen zur Untersuchung desProblems werden also von und zu den anderen ITIL- oder Management-Prozessen geliefert. Auch hier ist ein Tool hilfreich, mit dem die eingegebe-nen Informationen zu jeglichen Vorgängen prozessübergreifend eingesehenund verwendet werden können.

Abschluss des Problems oder Überleitung zur Error Control: Ist dasProblem identifiziert, erfolgt ein Abschluss in der Problem Control. DieLösung des vorliegenden Problems erfolgt dann in der sich anschließendenError-Control. Wichtig ist zu diesem Zeitpunkt, dass auch die anderenProzesse über den aktuellen Stand und die Identifizierung des Problemsinformiert werden. Diese Arbeit kann ein Tool erleichtern, indem es au-tomatisch Rückmeldung über die identifizierten Probleme und den Pro-blemlösungsfortschritt zu den anderen Prozessen gibt. Somit wird demMitarbeiter einerseits die Zeit erspart, die übrigen Mitarbeiter eigenhän-


dig zu informieren und andererseits auch sichergestellt, dass niemand dieseInformationen 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 bereitsbekannt und können eingeleitet werden. Im Rahmen der Error-Control werdenLösungswege neu ermittelter Probleme erarbeitet und im Bedarfsfall ein RFC andas Change Management gestellt. Auch hier wird der dort stattfindende Prozessvereinfacht dargestellt.[Els06]

Identifizierung des Fehlers : Für die Known Errors, die an dieser Stelle ein-treffen, sind die Lösungswege bereits bekannt und können aus einer gutgepflegten Datenbank entnommen werden. In dem Augenblick, in demdie Ursache des Problems festgestellt wurde, wird das Problem zu einemFehler und die Fehlerbehandlung nimmt ihre Arbeit auf. Der Fortschrittdes Lösungswegs der bereits bekannten Fehler wird weiter überwacht. Fürdie Ermittlung neuer Fehler sollten dem Mitarbeiter mehrere Hilfsmit-teln zur Fehlersuche zur Verfügung stehen. Dazu werden eine Reihe vonKomponenten, Systemen, Datensammlungen und Programmen benötigt.Auch hier muss er mit Unterstützung eines Tools in der Lage sein, auf dienotwendigen Informationen der anderen Prozesse zugreifen zu können.

Ermittlung eines Lösungswegs: Für die ermittelten Fehler müssen nun neuinitiierte Lösungswege gefunden werden. Hierbei ist es notwendig, dassder Mitarbeiter auf bereits vorhandenes Lösungswissen einer Datenbankzugreifen kann, welches ihm bei der Ermittlung einer neuen Lösung hel-fen kann. Alle Lösungsaktivitäten, die er vollzieht, müssen von ihm dabeinatürlich auch festgehalten werden, damit auch im Nachhinein nachvoll-zogen werden kann, welche Lösungsvorschläge ggf. auch zu keiner Lösungführten, um in der Zukunft Zeit zu sparen. Die Auswirkungen der gefun-denen Lösung müssen weiter beobachtet werden. Nach der Lösungssuchewird dann eine optimale Lösung bestimmt. Diese führt bestenfalls zu einerBeseitigung des Fehlers, ggf. mit einer Änderungsanforderung des ProblemManagements an das Change Management, also einem RFC. Eine Lösungkann auch so aussehen, dass der bekannte Fehler weiter auftreten kann,da er schnell behoben werden kann und eine endgültige Beseitigung zuzeit- oder kostenintensiv wäre.[Its07]

Dokumentation der gefundenen Lösung: Wie auch immer die vorher ge-troffene Lösung aussieht, ist es wichtig, dass die Lösung umfassend doku-mentiert wird. Somit kann sichergestellt werden, dass auch die Lösungenin Zukunft auftretender Probleme schnell in einer Datenbank gefundenwerden können. Damit soll verhindert werden, dass eine Lösung nochmalsneu erarbeitet werden muss, weil sie vorher nicht vollständig dokumentiertwurde und somit viel Zeit kostet. Abschließend müssen die anderen Pro-zesse über die Lösung informiert werden. Eine automatische Benachrich-tigung an die betroffenen Anwendergruppen durch ein eingesetztes Toolerleichtert und beschleunigt auch hier die Arbeit. Dies ist u.a. für das In-cident Management besonders wichtig, da somit eine schnelle Verwendungder neuen Lösungen dort gewährleistet ist. Auch hier gilt es nochmals zu


betonen, dass eine stetige Kommunikation der einzelnen Prozesse für einenerfolgreichen Abschluss zwingend notwendig ist.

Proactive Problem Management. Das Proactive Problem Managementbehandelt die frühzeitige Identifikation eines Problems oder allgemein die Er-kennung von Schwächen in der Infrastruktur durch Trendanalysen. Somit ist eskein Prozess im eigentlichen Sinn. Es sollen Vorkehrungen getroffen werden, umein Problem bestenfalls gar nicht erst entstehen zu lassen. Dazu können bereitsaufgetretene Störungen und deren Lösungen analysiert werden, um möglicheProbleme schon im Vorfeld zu erkennen. Das Proactive Problem Managementerfüllt folgende Aufgaben ([Els06]):

Erstellung von Trendanalysen: Zur Einführung des Problem Managementswird es überwiegend reaktiv sein, allerdings sollte eine Entwicklung hin-sichtlich proaktiver Mechanismen erfolgen. Eine Aufgabe darin ist die Er-stellung von Trendanalysen. Hierbei könnte ein Tool insofern hilfreich sein,als dass es bereits eine Funktion enthält, um eine Trendanalyse der ein-zelnen Tickets zu erstellen, d.h. Themen und Vorfälle, die wiederholt auf-treten, sollten angezeigt werden und eine Auswertung der Daten somit er-leichtert werden. Somit können Komponenten, die anfällig sind, oder beidenen eine Überlastung droht, genauer beobachtet werden. Genauso wirdversucht, Störungen, die in einem Bereich auftreten, bereits im Vorfeld inanderen Bereichen zu verhindern.

Weiterleitung von Auswertungen an das IT-Management: Die Analy-sen und Auswertungen sind natürlich nur dann nutzbar, wenn die Informa-tionen auch allen anderen bereitgestellt werden. Genau wie die Lösungeneines Problems müssen auch die im Vorfeld ermittelten Schwächen an dieanderen Prozesse weitergeleitet werden. Die Aufgabe eines Tools könntees hierbei sein, sobald an einer Stelle eine Schwäche identifiziert wurde,die Informationen automatisch an die betroffene Stelle weiterzuleiten undzu informieren, ohne dass dies viel Zeit und Aufwand in Anspruch nimmt.

4.3.4 Change ManagementWie bereits im Kapitel 4.3.2. erwähnt, nehmen die Mitarbeiter des Service-Deskzunächst alle Anliegen entgegen. Diese werden aufgenommen, und strukturiertin einer Datenbank erfasst. Wenn sich bei der Kategorisierung nun herausstellt,dass es sich um einen RFC handelt, wird es an das Change Management wei-tergeleitet. In diesem Abschnitt geht es nun um die Aufgaben, Funktionen undZiele des Change Managements. Die Erfahrung hat gezeigt, dass Probleme undStörungen häufig auf Änderungen zurückzuführen sind. Ursache dieser Proble-me sind oftmals überstürzte und wenig durchdachte Änderungen, oder unzu-reichende Planungen im Vorfeld.[Its07] Das Change Management soll nun ge-währleisten, dass die oben genannten beantragten Änderungsanforderungen inForm von RFCs geplant und kontrolliert ablaufen. Hierbei ist darauf zu achten,dass änderungsbedingte Störungen zu vermeiden oder wenigstens zu minimie-ren sind.[Fis06] Voraussetzung für Änderungen ist jedoch, dass diese im Vorfeldgenau überprüft und kontrolliert werden, ob die Changes ohne weitere Rückspra-che durchgeführt werden können. [Bre07] Die RFCs können im Wesentlichen indrei Bereiche aufgeteilt werden ([Its07]):


Neuerungen und Verbesserungen: Diese beinhalten neue Methoden undKonzepte, sowie technische Verbesserungen. Dadurch können neue struk-turelle Fehler und Probleme entstehen, die vorher in dieser Art und Weisenicht bekannt waren.

Änderungen: Änderungswünsche können sich auf Soft- und Hardwareände-rungen beziehen oder auch auf Betriebssysteme. Aber auch Modernisie-rungen oder der Austausch von Kabeln und/oder Hardware gehört in die-sen Bereich.

Korrekturen: Diese sollen die strukturellen Fehler und Probleme beheben.

Im weiteren Verlauf wird auf diese Unterteilung nicht weiter eingegangen, undzur Vereinfachung wird der Ausdruck Änderungen oder Change für alle Anliegenverwendet.All diese Änderungen sind mit einem gewissen Risiko behaftet und können zueinem Ausfall der Service-Leistungen führen. Es muss jedoch nicht nur daraufgeachtet werden, dass die Änderungen schnell und ohne Komplikationen durch-geführt werden, ebenso wichtig ist es auch, dass das System hinterher konsistentund ohne Fehler und Probleme funktioniert. Aus diesem Grund muss eine Ände-rung geplant werden, und kann nicht ad hoc durchgeführt werden. Es ist auchdarauf zu achten, ob nur ein Mitarbeiter betroffen ist, oder die ganze Beleg-schaft eines Unternehmens. Diese Faktoren zu berücksichtigen ist die Haupt-aufgabe des Change Managements. Zusätzlich zu beachten ist, dass Soft- undHardware selten kostenlos zur Verfügung gestellt werden. Es ist daher nicht ohneweiteres möglich, ohne Lizenzprüfung die Programme zur Probe zu installieren.Auch die Bevorratung der benötigten wichtigsten Ersatzteile ist Aufgabe diesesSupports. Zusammengefasst lässt sich sagen, dass sich die Aufgaben aus einemZeitmanagement und aus vorbereitenden Aufgaben zur Implementierung vonÄnderungen zusammensetzen. Nicht zu vergessen ist die permanente schrittwei-se und aktuelle Dokumentation aller Handlungen von jedem Mitarbeiter. Nurdurch diese sorgfältige Vorgehensweise wird eine effiziente und kostengünstigereArbeitsweise auf Dauer gewährleistet.[Els06]Um nun auch hier aus den Aufgaben und Zielen des Change Manangement An-forderungen 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 Changedeklariert 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 Formeines RFCs. Hier decken sich die Anforderungen an ein Tool mit denAnforderungen aus dem Service Desk. Hier wäre es demnach auch wiedervon 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 Informationenkönnen eine Identifikationsnummer, der Auslöser des Changes, eineBegründung für die beantragte Änderung, Datum der Beantragung undDatum der geplanten Durchführung sein. Dieses Verfahren schützt denBenutzer vor der Gefahr, wichtige Daten bei der Eingabe zu übersehen.Im weiteren Verlauf muss noch geklärt werden, ob der Antragsteller auch


berechtigt ist, diesen Änderungswunsch anzubringen. Ist das nicht derFall, wird das RFC sofort abgelehnt. Wünschenswert wäre an dieser Stelle,wenn das Programm diese Kontrolle automatisch durchführt, indem sieden Antragsteller mit den hinterlegten berechtigten Personen abgleichtund bei entsprechendem Verstoß automatisch eine E-Mail verschickt, dassdiesem Änderungswunsch nicht weiter nachgegangen werden kann. Dieserwird mit der entsprechenden Begründung versehen. [Its07] Nach derErfassung erfolgt eine Kontrolle auf eventuelle Doppelerfassung oder auchauf nicht durchführbare RFCs. Diese Änderungen sollten dann automa-tisch mit einer entsprechenden Begründung abgewiesen werden. Zudemwerden dann auch nach der Akzeptanz des RFCs weitere Informationenhinzugefügt, wie z.B. die Beurteilung der Auswirkungen. Das geplanteDatum zur Umsetzung und auch der aktuelle Bearbeitungsstatus sollteangezeigt werden.

Im weiteren Verlauf wird eine Prioritätsstufe bzw. eine Kategorisierungvorgenommen. Unter Priorität wird die Dringlichkeit des Changes ver-standen. Die Kategorie bestimmt sich aus der Grundlage und den Auswir-kungen der Änderungen. Nach ITIL werden die Prioritäten in vier Bereicheeingeteilt. Es reicht von der höchsten, über die hohe und normale Prioritätbis 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. Priori-tät macht. Dieser Vorschlag könnte auf vorhandenen RFCs aufbauen, beidenen es zum Beispiel um eine ähnliche Angelegenheit geht, oder auch umeine gleiche Dringlichkeit.

Erstellung von Zeit-/Installationsplänen und deren Implementierung:Nachdem das RFC genehmigt wurde, muss nun bedacht werden, wieumfangreich diese Änderung ist, um daraus Rückschlüsse auf die benö-tigte Mitarbeiteranzahl und auf die benötigten Arbeitsstundenzahlen zuziehen. In diesem Punkt arbeitet das Change Management eng mit demRelease Management zusammen, denn dieses ist dafür verantwortlich,dass genügend Ressourcen zur Verfügung gestellt werden. Von Vorteil istes hier auch, wenn das Change Management im permanenten Kontakt zuden 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 bie-tet die Möglichkeit, die Änderung wieder rückgängig zu machen, wenn die-se nicht das erwünschte Ergebnis liefert. Das Change Management darf einRFC nicht ohne Backout-Verfahren genehmigen. Auch hier ist es von Vor-teil, wenn das Programm einen Hinweis gibt, wenn kein Backout-Verfahrenverzeichnet ist, damit es nicht zu Schwierigkeiten nach einer unzulässigenGenehmigung kommt.

Freigabe der Änderung, Evaluierung und Abschluss: Nach der Freiga-be durch das Change Management sollte eine Evaluierung durchgeführtwerden. Dabei ist allerdings zu beachten, dass standardisierte Änderun-gen nicht jedes Mal evaluiert werden müssen, bzw. dies in abgeschwächterForm erfolgen kann. Wünschenswert wäre hier ein Evaluierungsprogramm,in dem man gewisse Kriterien ausfüllen muss, so dass eine Vergleichs-


möglichkeit entsteht. Letztendlich liegt es im Verantwortungsbereich desChange Managements, die Änderung einzuführen und auch zu überwa-chen. Voraussetzung hierfür ist eine detaillierte Dokumentation und per-manente Aktualisierung. Hilfreich ist somit eine Evaluierung in Form einesgeeigneten, selbstentwickelten Fragebogens, der es ermöglicht, standardi-siert vorzugehen.

4.3.5 Release ManagementDie umfassende Planung und Durchführung von Hard- und Softwareeinführun-gen findet im Release Management seine Umsetzung. Das Hauptaugenmerk desRelease Managements liegt auf der Stabilhaltung der IT-Infrastruktur.[Bre07]Unter einem Release wird eine „Reihe neuer oder geänderter Konfigurations-Elemente 4, die zusammenhängend getestet und in die Produktionsumgebungüberführt werden“ [Its07] verstanden. Ein Release kann dabei ein vorhande-nes CI ersetzen oder aber neu sein.[Els06] Releases werden unterteilt in Major-Releases, welche erhebliche Änderungen bzw. Erweiterungen der Funktionali-tät zur Folge haben, in Minor-Releases, welche geringfügige Änderungen be-wirken, und in Emergency Fixes, welche vorübergehend kurzfristige Änderun-gen vornehmen.[Its07] Es werden drei Release Arten Full-, Delta- und Package-Release differenziert.5Die Dokumentation der Releases erfolgt innerhalb der Definitive Software Li-brary (DSL) und dem Definite Hardware Store (DHS). In der DSL werden allefreigegebenen Software Releases, die Masterkopien der Software, und deren zu-gehörige Dokumente aufgeführt. Sie sollte von den im Folgenden noch zu erläu-ternden Prozessen des Release Managements losgelöst sein. Im DHS sind alleHardware Ersatzteile enthalten. Diese beiden Datenbanken stehen in Verbin-dung zur Configuration Management Database (CMDB), welche den Prozessvon der Planung bis zur Umsetzung dokumentiert und im Configuration Ma-nagement erläutert wird.[Its07] Bezüglich der Erfassung innerhalb der Daten-banken muss man sich dann neben der Identifikationsnummer für verschiedeneDatenfelder entscheiden, nach denen die Inhalte der Datenbanken aufgeführtwerden sollen. Zu beachten ist, dass eine eindeutige Identifikation möglich wird.So kann zwischen Releases schon durch die Anordnung der Versionsnummerunterschieden werden.6 Außerdem gilt auch im Hinblick auf die Verwendungeines Tools, dass grundsätzliche Entscheidungen für die Arbeit mit den Da-tenbanken getroffen werden sollten. Da stets verschiedene Personen mit diesenDatenbanken arbeiten, ist ein standardisiertes Vorgehen auch für die spätereVerwendung und Anbindung an weitere Prozesse von Nutzen. Ein einheitlichesVorgehen erleichtert im weiteren Verlauf auch den Zugriff auf die vorhandenenInformationen. Darunter fällt neben Art der Darstellung auch die Pflege der Da-ten, d.h. dass sie sich stets auf dem neusten Stand befinden. Eine fortlaufendeKontrolle der Datenbanken ist somit zu empfehlen, sie stehen auch im fortwäh-renden Austausch mit den Aktivitäten, welche im Release Prozess angesiedelt

4Konfigurations Elemente bzw. Configuration Items werden im weiteren Verlauf der Arbeitmit dem Akronym CI abgekürzt.

5Ein Full-Release bezeichnet dabei einen kompletten Austausch eines Releases, während beieinem Delta-Release Changes an einem einzigen Release vorgenommen werden. Ein Package-Release wiederum ist der Austausch zusammenhängender CIs.[Els06]

6Beispiel: Version 1.0 für ein Major Release, Version 1.1 für ein Minor Release und Version1.1.1 für einen Emergency Fix.


sind. Denkbar sind für ein derartiges Vorgehen prozessbezogene Checklisten,welche von den involvierten Mitarbeitern ausgefüllt werden müssen und an dieentsprechenden Stellen weitergeleitet werden.Die Aktivitäten des Release Managements sind in die Bereiche Entwicklungsum-gebung, überwachte Testumgebung und Produktionsumgebung unterteilt. Zwarsind einige der Aktivitäten variierbar, aber im Sinne einer strukturierten Pla-nung sollte ein einheitliches Vorgehen angestrebt werden.[Els06] Im Folgendenwird näher auf die Bereiche und die darin angesiedelten Prozesse eingegangen.[Its07] Im Gegensatz zum Incident, Change und Problem Management sinddie konkreten Anforderungen an ein Tool innerhalb dieser Aktivitäten kaumzu formulieren. Die Bearbeitung der Releases ist in jedem Unternehmen sehrspezifisch. Es kann daher nur Ziel bei der weiteren Betrachtung sein, auf grund-sätzliche Anregungen einzugehen.

Entwicklungsumgebung. In der Entwicklungsumgebung findet der ReleaseBuild statt. Dies beinhaltet die Planung und Festlegung der Versionsgrundsätze,also die Erarbeitung der Release-Richtlinien. Weiterhin wird der grundlegendeEntwurf, Aufbau und die Formierung des Releases vorgenommen, so dass einRelease-Plan erstellt wird. Empfehlenswert ist es hier, ein standardisiertes Ver-fahren zu entwickeln, welches dann für einen einheitlichen Ablauf steht, undeinem die Möglichkeit gibt, den aktuellen Entwicklungsstand besser nachvoll-ziehen zu können.Es muss darauf geachtet werden, dass die einzelnen Releases bereits nach be-stimmten Kriterien gekennzeichnet werden, so dass die Identifikation jedes Re-lease eindeutig möglich ist.[Its07]

Überwachte Testumgebung. Im Bereich der überwachten Testumgebungist die Versionsprüfung und Abnahme des Realeses, die Planung des Roll-Outsowie die Kommunikationsvorbereitung und Schulung angesiedelt. Unzureichen-des Testen gilt als die häufigste Ursache bei nicht erfolgreichen Änderungen, sodass 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 Anwend-erfreundlichkeit, am besten in einer Umgebung, die ähnlich seiner späteren ist.Bei der notwendigen Vielfältigkeit dieses Tests ist auch hier eine vorherige ein-heitliche 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 erstelleRelease-Plan der Ausgangspunkt, welcher jetzt um die Implementierungspläneerweitert wird. Jetzt muss ein genauer Zeitplan für das Roll-Out entworfen,ein Aktionsplan erstellt und die Vorbereitung für die Kommunikation getroffenwerden.[Its07]In dem Bereich der Kommunikationsvorbereitung und Schulung soll die Infor-mation der beteiligten Personen vorgenommen werden. Neben den Kunden müs-sen natürlich auch die Mitarbeiter des Service Desk als erste Schnittstelle zumKunden über die Änderungen informiert werden.

Produktionsumgebung. Dem Release Management obliegt die Überwa-chung der Verteilung bis hin zur Installation und Übergabe von Software undHardware an den Nutzer. Für eine Kontrolle und Überwachung des Transports


und der Auslieferung ist eine Dokumentation wünschenswert, in der beispiels-weise Status-Berichte oder auch Auslieferungsbelege aufgenommen werden. Beider Installation wiederum ist ein einheitliches Vorgehen zu beachten, und dasses nur durch autorisiertes Personal durchgeführt wird.[Its07]Bei der Betrachtung der Aktivitäten wird vor allem die notwendige und ständi-ge Interaktion zwischen den verschiedenen angesprochenen Bereichen deutlich.So steht das Release Management in enger Verbindung zum bereits angespro-chenen Change Management. Auch das im anschließenden Kapitel betrachteteConfiguration Management ist für eine erfolgreiche Einführung ein wichtiger Ko-operationspartner für das Release Management. Damit diese Interaktion auchdurchgeführt wird, kann ein Tool hier helfen, an den entsprechenden Stellendaran zu erinnern.Grundsätzlich ist anzumerken, dass die Vielzahl an Prozessen, welche im ReleaseManagement ablaufen, nur durch eine angemessene Zeitspanne zu lösen sind.Damit dies möglich ist, muss darauf geachtet werden, dass von der Planungbis zum Roll-Out ein entsprechendes Zeitfenster zur Verfügung steht. An dieserStelle ist es ratsam, den Kunden einzubeziehen und zu informieren, so dass ernachvollziehen kann, in welchem Stadium sich die Entwicklung gerade befindetund wann er mit einer Installation rechnen kann. Dies könnte zum Beispiel übereinen Statusbericht geschehen, welcher dem Kunden in regelmäßigen Abständenzukommt.


Das Configuration Management ist zuständig für die IT-Infrastruktur. Ziel da-bei ist es, alle IT-Komponenten zu dokumentieren und gesicherte Informatio-nen über die IT-Infrastruktur allen anderen Prozessen jederzeit zur Verfügungzu stellen. Diese Informationen sollen dabei stets auf dem aktuellen Stand ge-halten werden. Dafür identifiziert, überwacht und kontrolliert das ConfigurationManagement die CIs und ihre Versionen. Dies erfolgt, indem es die Attribute, diezu einem CI gehören, sowie die Beziehungen zu denen es mit anderen CIs steht,in der CMDB abspeichert. Dazu werden für die Informationsbeschaffung Hard-und Software Datenbanken und Softwarepakete genutzt, um Veränderungen in-nerhalb der IT-Infrastruktur korrekt zu erfassen. Die CMDB ist vorstellbar alsgroße Kartei, in dem sämtliche IT-Betriebsmittel registriert sind und die Bezie-hungen zwischen den einzelnen Karten festgehalten werden. Die einfachste Form,die für eine CMDB denkbar ist, wären Formulare. Die CMDB unterscheidet sichvon Datenbanken, die mit Hilfe von Inventarisierungsprogrammen aktualisiertwerden. Und zwar insofern, dass sie nicht nur Informationen über die momentanaktiven Hard- und Softwareprodukte liefert, sondern eher aufzeigt, wie die In-frastruktur aussehen müsste, wenn alle Regeln inklusive der Dokumentationenbeachtet werden.Alle weiteren ITIL-Prozesse nutzen diese Daten für ihre Zwecke und sind von sei-nen Leistungen abhängig. Das IT-Management benutzt diese Daten für Berichts-und Entscheidungsaktivitäten.Die Vorteile des Configuration Managements liegen darin, dass die Auswirkun-gen von Changes vollständig sichtbar werden, nicht autorisierte CIs oder ille-gale Software-Kopien identifiziert werden können und sinnvolle Analysedatengeliefert werden. Außerdem werden durch das Vorhandensein des ConfigurationManagements alle anderen Prozesse unterstützt.[Its07]


Der Ablauf innerhalb des Configuration Managements wird nicht immer strikteingehalten, sondern die einzelnen Aktivitäten laufen vielmehr parallel ab. DieAktivitäten des Configuration Managements umfassen im Einzelnen: [Its07]

Planung. Im Rahmen der Planung des Aufbaus eines Configuration Mana-gements wird dessen Zweck und Umfang bzw. die genaue Detaillierung undPriorisierung festgelegt.

Identifikation. Unter die Identifikations-Phase fallen die Bestimmung undPflege der Bezeichnungen und auch der Versionsnummern der einzelnen Kom-ponenten, sowie deren Beziehungen. Dazu muss die Beschreibungstiefe der über-wachten CIs definiert, die Namenskonventionen festgelegt, sowie die Erfassungvon Varianten geregelt werden.

Statusüberwachung. Innerhalb der Statusüberwachung wird die Lebens-dauer einer Komponente verfolgt, außerdem werden Auswertungen über aktuelleund veraltete CIs erstellt.

Kontrolle. Hier erfolgt eine Pflege der Daten indem sichergestellt wird, dassÄnderungen, die durch das Change Management erfolgt sind, autorisiert, voll-ständig und richtig in der CMDB erfasst worden sind.

Verifizierung und Audits. Es erfolgt eine Überprüfung, ob die Daten in derCMDB noch mit der aktuellen Situation übereinstimmen.Da, wie erwähnt, die Prozesse innerhalb des Configuration Managements oft-mals parallel ablaufen, werden die Anforderungen allgemein formuliert und nichtspezifisch in die einzelnen Prozessabschnitte untergliedert.Eine erste wichtige Anforderung ist, dass für den Aufbau eines ConfigurationManagements in einem eingesetzten Tool bereits eine integrierte CMDB vor-handen ist, mit deren Hilfe die CIs inklusive deren Attribute verwaltet werdenkönnen. Für die Verwaltung sollten die Attribute und Klassen eines CIs be-reits implementiert sein. Um die Aktualität der CMDB zu gewährleisten, solltedas Tool in der Lage sein, geänderte Konfigurationen automatisch zu erfassenund zu kontrollieren. Das Tool sollte so ausgewählt werden, dass Änderungenund Erweiterungen innerhalb des Configuration Managements nicht behindertwerden.Obwohl die Daten aus dem Incident-, Problem- und Change Management ei-gentlich nicht Bestandteil der CMDB sind, sollte dennoch eine Verknüpfung zumChange- und Release- Management vorhanden sein, damit alle zugehörigen In-cidents, Problems und Changes ausgewiesen werden können.Zur Verifizierung der Audits könnte ein Audit Tool z.B. automatischArbeitsplatz-PCs durchforsten, um Unstimmigkeiten aufzudecken. Es sollte je-doch keine automatischen Aktualisierungen vornehmen, da diese Unstimmigkei-ten auf eine Umgehung des Change Managements hindeuten und weiter unter-sucht werden müssen.[Its07]


4.4 Betrachtung ausgewählter ITIL-Werkzeuge

4.4.1 VorgehensweiseNachdem in dem vorherigen Kapitel Anforderungen an ein Werkzeug formuliertwurden, stellt sich die Frage, inwiefern die am Markt vorhandenen Werkzeugediese Anforderungen auch erfüllen können. Da es unzählige verschiedene Werk-zeuge gibt, kann es nicht Ziel dieser Arbeit sein, einen Vergleich aller vorhande-nen Werkzeuge vorzunehmen. Vielmehr werden exemplarisch zwei verschiede-ne Werkzeuge näher betrachtet. Dies ist zum einen das open-source WerkzeugOTRS und zum anderen das kommerzielle Werkzeug Remedy. Basierend aufden Daten, welche die Anbieter dieser Software auf ihrer Homepage und in denentsprechenden Handbüchern zur Verfügung stellen, werden die Funktionen derWerkzeuge aufgeführt und exemplarisch mit den vorher herausgearbeiteten An-forderungen in Bezug gesetzt.[Otr08, Bmc08]

4.4.2 Das Open Source-Werkzeug OTRSOTRS gilt als der bekannteste Vertreter aus dem open-source Bereich und unter-liegt der GNU, der General Public License. Damit eine Software als open-sourcebezeichnet werden darf, muss sie verschiedene Eigenschaften erfüllen. Zum einenmuss die Software in einer lesbaren und verständlichen Form vorliegen, sowiebeliebig oft kopierbar und nutzbar sein. Zum anderen muss die Software verän-dert werden können und auch in der geänderten Form weiter verbreitet werdendürfen. OTRS ist lizenzfrei im Internet als Download erhältlich. Dadurch fallenkeine Kosten für Lizenzgebühren an. Zudem bietet die Software Schnittstellenzu vielen Betriebssystemen wie Windows oder Linux. Es ist einfach und schnellim Unternehmen zu implementieren.[Nie07]OTRS basiert auf dem oben dargstellten Ticket-System. Aufgrund der Daten-mengen, die in einem Unternehmen eingehen, ist so ein Ticket-System sinnvollerals reine E-Mailkorrespondenz. Denn hier können die Anfragen wie bereits erläu-tert miteinander in Zusammenhang gebracht werden. Die Gefahr der doppeltenBearbeitung wird reduziert bzw. minimiert. Das Ticket beinhaltet alle Informa-tionen zu einem bestimmten Kunden oder zu einem konkreten Problem. Jedesnoch so kleine Detail wird dokumentiert, und kann jederzeit wieder aufgeru-fen werden. Es besteht auch die Möglichkeit Tickets an Kollegen weiterzulei-ten, und diese mit zusätzlicher Information in einer separaten Mail auszustat-ten. Zudem können unterschiedliche Zugriffsrechte definiert werden. Außerdemkönnen Tickets nach Prioritäten geordnet werden, die dann je nach Dringlich-keit abgearbeitet werden können. Auch die erwünschte Kategorienbildung istmöglich.[Här07]Im weiteren Verlauf soll nun herausgearbeitet werden, ob OTRS den oben ge-nannten Anforderungen genügen kann.

Incident Management mit Service Desk. Für das Incident Managementmit dem Service Desk wird nun die weitere Betrachtung anhand der einzelnenPhasen innerhalb des Prozesses vorgenommen, in die das Incident Managementbereits oben untergliedert wurde.

Anliegen entgegennehmen und registrieren: Aufgrund des Ticket-Systems wird das Erfassen der Daten vereinfacht. Für jede Störung


oder für jede Änderung wird ein eigenes Ticket angelegt. Es ist auchnicht relevant, ob die Daten per Telefon oder per Mail eingehen. Ausden eingegangenen E-Mails wird automatisch ein Ticket erstellt. DenSupportern7 steht für die telefonische Entgegennahme eine Telefon-Maskezur Verfügung, in der alle wesentlichen und relevanten Daten strukturierteingegeben werden können. Diese Daten werden gespeichert und sind füralle anderen Mitarbeiter zu jeder Zeit ersichtlich. Es besteht natürlichauch die Möglichkeit, dass mehrere Mitarbeiter zeitgleich an einem Ticketarbeiten, oder ein Supporter an mehreren Tickets gleichzeitig.Zudem bietet OTRS die Möglichkeit, dass die Kunden über eine entspre-chende Maske im Programm Incidents und Changes selbstständig erfassenkönnen und via E-Mail an die Supporter schicken. Des Weiteren könnensich die Kunden auch über den aktuellen Bearbeitungsstand ihrer eigenenTickets informieren und auch weitere Anmerkungen eingeben. Natürlichkönnen die Supporter auch jederzeit den aktuellen Bearbeitungsstand andie Kunden weitergeben. Diese Vorgehensweise ist in der folgenden Abbil-dung 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 Pro-gramm selbständig über OTRS ein Ticket erstellen kann. Dieses erfolgtüber eine E-Mail in einer vorgegebenen Maske. Die Daten dieser E-Mailwerden dann automatisch in ein Ticket übertragen. D. h. der Supportermuss die Daten nicht aus der E-Mail heraus in ein Ticket übertragen,

7Die Service-Desk Mitarbeiter werden in OTRS als Supporter bezeichnet.

http://otrs.org/images/screen-2.0/customer-newTicket.png

http://otrs.org/images/screen-2.0/customer-newTicket.png


sondern dies geschieht automatisch. Ebenso hat der Kunde über dieseFunktion die Möglichkeit sich über den Bearbeitungsstand seiner bereitsvorhandenen Tickets zu informieren. Des Weiteren stehen dem Kundennoch weitere Anwendungen zur Verfügung, die hier jedoch nicht näherbetrachtet werden sollen.

Klassifizierung des Anliegens: Nach der Datenerfassung werden die An-liegen klassifiziert. Dieser Vorgang wird z. B. bei einem Telefongesprächschon während der Datenaufnahme erfolgen, um den weiteren Verlauf desTelefonats zu beurteilen. Je nachdem ob es sich um ein Incident oderum einen Change handelt, wird das weitere Vorgehen beeinflusst. Durchdie verbesserten Kommunikationsmöglichkeiten können Prozesse wie Inci-dents oder Changes schneller und effizienter weitergeleitet werden. Nach-dem die Klassifizierung erfolgt ist, wird das Anliegen entweder sofort vomSupporter bearbeitet und abgeschlossen, oder er leitet das Anliegen weiteran das Incident bzw. Change Management. In der folgenden Abbildungist zu erkennen, wie die Benutzeroberfläche für den Supporter von OTRSaussieht.

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 ge-gliedert ist. In dem oberen schwarzen Balken werden allgemeine Daten,wie der Name des Supporters, das Datum und die Uhrzeit angezeigt. Indem weißen darunterliegenden Bereich befinden sich verschiedene Icons zurBearbeitung der Tickets. Ebenso werden hier neu eingegangene E-Mailsangezeigt. In dem darunterliegenden weißen Bereich werden die Inhalte zu

http://otrs.org/images/screen-2.0/queue.png

http://otrs.org/images/screen-2.0/queue.png


dem aktuell geöffneten Ticket angezeigt. Im unteren Bereich der Maskewerden Funktionen, wie die Historiefunktion, zu dem Ticket dargestellt.Auf der rechten Seite der Maske befinden sich weitere Angaben zu demTicket. Unter anderem die Priorität und der Bearbeitungsstatus.

Bearbeitung von Störungen: Durch die gespeicherte, integrierte Datenbankkönnen alle Supporter auf das gespeicherte Wissen zugreifen. Dadurch istes den Mitarbeitern im Service Desk möglich, leichtere, häufig auftreten-de Störungen schneller und kundenfreundlicher zu bearbeiten. Viele An-liegen können schon vorab vom First-Level-Support geklärt werden, undes benötigt keine Rücksprache mit den anderen Levels. Dadurch wird ei-ne Entlastung der Mitarbeiter hervorgerufen, die Mitarbeiterzufriedenheitsteigt. Des Weiteren erfolgt eine kundenfreundlichere Abwicklung, weil dieWartezeiten sich nicht so lange hinziehen.

Diese Vereinfachung ist nur bei Standard-Anliegen möglich. Was genauein Standard-Anliegen ausmacht kann innerhalb der Software definiertwerden. Wenn diese Daten hinterlegt sind, kann OTRS durch eine Schlag-wortsuche eingehende E-Mails durchsuchen, und dann entsprechend derVorgabe einem Ticket oder einer Störung zuordnen, ohne dass ein Mit-arbeiter sich dieser E-Mail widmet. Diese Vereinfachung kann für allebekannten und leicht korrigierbaren Incidents Anwendung finden. Es be-steht die Möglichkeit, dass vorformulierte E-Mails automatisch auf einebestimmte Anfrage hin versendet werden. Dieser Automatisierungsvor-gang entlastet die Mitarbeiter und ermöglicht es den Supportern, sich mitwesentlichen und schwierigeren Anliegen zu befassen und auch schnellerund 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 wirdin 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 dembestehenden dann verknüpft werden kann. Kann ein Incident oder einÄnderungswunsch nicht sofort erledigt werden, gibt es bei OTRS aucheine Wiedervorlagemöglichkeit. Dadurch gerät kein Ticket in Vergessen-heit. Des Weiteren gibt es die Möglichkeit, Tickets zu einem bestimmtenEvent wieder aufzurufen. Interessant ist diese Funktion zum Beispielnach einem Update, um zu überprüfen, ob der Fehler behoben oder einÄnderungswunsch umgesetzt wurde.

Problem Management. Im Folgenden werden die oben formulierten Anfor-derungen an ein Tool im Rahmen des Problem Managements mit den angebo-tenen Funktionen von OTRS verglichen. Hier werden die einzelnen Phasen, dieinnerhalb der Problem-Control, der Error Control und des Proactive ProblemManagements ablaufen, jedoch nicht separat, sondern, um Überschneidungenzu vermeiden, zusammengefasst betrachtet. Wie bereits beschrieben, gehen imProblem Management die Störungen ein, für die das Incident Management kei-ne Ursache feststellen konnte und die somit als Problem klassifiziert werden.Diese werden wieder als Ticket innerhalb des Systems weitergeleitet. Die hier


eingegangenen Probleme lassen sich nicht so einfach klären oder beseitigen, oderführen zu dauerhaften Ausfällen.Mit Hilfe von OTRS kann die Anforderung umgesetzt werden, dass ein Toolin der Lage sein sollte, die Daten strukturiert erfassen zu können. OTRS bie-tet durchgängige Unterstützung bei der Problemidentifizierung und -erfassung,sowie bei der Klassifizierung von Problemen. Die Priorisierung dient hier alsGrundlage der Ressourcenzuteilung, wodurch die Probleme an die entsprechen-den Experten weitergeleitet werden.Für eine tiefgehende Analyse der Probleme oder Fehler bietet OTRS die Mög-lichkeit, ständig auf vorhandenes Lösungswissen in der Wissensdatenbank zu-greifen zu können. Darin sind alle aktuellen und historischen Problemlösun-gen dokumentiert und können somit zur Klärung des Problems beitragen. DieLösungsentwicklung kann jederzeit von allen anderen Anwendern angeschautwerden und alle können jederzeit an dem Problem arbeiten. Somit lässt sichermitteln, ob ein ähnliches Problem bereits bekannt ist und ob dafür schon eineLösung gefunden wurde. Dabei werden alle relevanten Informationen zur Verfü-gung gestellt, sowohl aus dem Bereich des Problem Management, als auch ausallen weiteren ITIL-Prozessen. Des Weiteren beinhaltet das OTRS-Tool einegezielte, automatische Benachrichtigung über den Problemlösungsfortschritt andie betroffenen Anwender, um Zeit zu sparen und eine vollständige Übermitt-lung der Informationen zu gewährleisten.Um proaktiv Störungen im Vorfeld verhindern zu können, bietet OTRS u. a. dieMöglichkeit Ticket-Trendanalysen durchführen zu können, um von den Trendsinnerhalb der Tickets auf mögliche Schwachstellen schließen zu können.

Change Management. OTRS bietet zurzeit noch nicht die Möglichkeit dasChange Management zu implementieren. Anzumerken ist, dass die RFCs überden in OTRS vorhandenen Service Desk erfasst werden können. Die weitereVorgehensweise bzgl. der RFCs wird jedoch von OTRS nicht unterstützt.

Release Management. Auch hier bietet OTRS noch nicht die Möglichkeitdas Release Management umzusetzen.

Configuration Management. Bei OTRS ist mit dem Vorhandensein einerintegrierten CMDB die Möglichkeit gegeben, das Configuration Managementumzusetzen. Mit Hilfe der CMDB können die CIs, sowie ihre gegenseitigen Be-ziehungen und Abhängigkeiten erfasst und verwaltet werden. Auch Änderungender Attribute der CIs können vorgenommen werden. Dabei ist es bei OTRS mög-lich, die CIs den verschiedenen Klassen, nämlich Computer, Hardware, Software,Netze zuzuordnen. Außerdem bietet OTRS eine Möglichkeit zum Managementder historischen, aktuellen und zukünftigen CI-Status, die im Rahmen der Sta-tusüberwachung bei Problem-Diagnosen oder geplanten Changes hilfreich seinkönnen. Diese können durch ein chronologisches Life-Cycle-Management für dieCIs verwaltet werden. Alle Konfigurationsänderungen an CMDB-Daten werdendurch das OTRS-Tool protokolliert.Des Weiteren kann durch den Einsatz von OTRS die IT-Infrastruktur virtuali-siert abgebildet werden. Die anderen ITIL- Prozesse können integriert werden,womit eine Verknüpfung zum Incident, Problem und Change Management be-


steht und damit alle zugehörigen Incidents, Problems und Changes mit einbe-zogen werden können.

Zusammenfassung. Abschließend lässt sich zu OTRS festhalten, dass es nureinige der von ITIL genannten Prozesse aus dem Bereich Service Support ab-bildet. Da OTRS auf einem Ticket-System basiert, deckt es hauptsächlich dieProzesse des Incident Managements in Verbindung mit dem Service Desk sowiedas Problem Management ab. Aus diesem Grund werden auch hier die meis-ten im Rahmen dieser Projektarbeit genannten Anforderungen beachtet. Durchdie übersichtliche Oberfläche von OTRS, werden die grundlegenden Anforde-rungen, wie die strukturierte Erfassung und Verwaltung der Daten, erfüllt. Diebeiden Prozesse Change und Release Management werden gar nicht unterstützt,so dass für diese keine Informationen auf der Homepage bereitgestellt werdenund eine Überprüfung der aufgestellten Anforderungen nicht durchgeführt wer-den konnte. Das Configuration Management wird durch die Software wieder-um abgedeckt. Die Grundanforderungen für die Umsetzung des ConfigurationManagements ist das Vorhandensein einer integrierten CMDB, welche in die-sem Werkzeug implementiert ist. Der Aufbau und der vorgegebene Ablauf vonOTRS bieten die Möglichkeit der Verknüpfung der einzelnen Bereiche, so dasseine prozessübergreifende Kommunikation und ein permanenter Datenzugriffermöglicht wird.

4.4.3 Das kommerzielle Werkzeug Remedy

Remedy ist eine kommerzielle Software, die von BMC Software Inc.8 entwi-ckelt wurde und seitdem von dem Unternehmen vertrieben wird. Für die wei-tere Betrachtung werden hauptsächlich die Informationen von der Webseite desUnternehmens verwendet. Anzumerken ist in diesem Zusammenhang, dass dieInformationspolitik eines kommerziellen Tools eine andere als bei einem Open-source Tool ist. So werden die Vorteile von Remedy besonders herausgestellt.Die Beschreibung der Funktionen erfolgt jedoch nicht zu konkret, wie es beifrei zugänglichen open-source Lösungen eher vorzufinden ist. Remedy bietet ei-ne 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 kombiniertwerden können:

• Remedy Help Desk, der den Service Desk, das Incident Management sowiedas Problem Management umfasst

• Remedy Asset Management, welches das Configuration Management indas Remedy IT Service Management implementiert

• Remedy Change Management, mit dem der ITIL-Prozess des Change Ma-nagements unterstützt wird

• Remedy Service Level Agreements, da aber dieses Modul nicht Bestandteilder Prozesse des Service Supports ist, wird es in dieser Arbeit nicht weiterbetrachtet

8Die Firma hat ihren Hauptsitz in Houston, Texas, sowie zahlreiche Tochterfirmen weltweit.


Diese Bausteine sind unabhängig voneinander. Wenn sie von einem Unterneh-men eingesetzt werden, so stehen sie dann miteinander in Beziehung und sinddamit verknüpft.Auch bei diesem Werkzeug wird nun untersucht, inwiefern die Software Reme-dy den aufgestellten Forderungen genügen kann. Aufgrund der angesprochenenInformationsproblematik ist es im weiteren Verlauf nicht möglich, den Ablaufinnerhalb der einzelnen Prozesse detailliert zu betrachten, so dass die einzelnenProzesse insgesamt betrachtet werden.

Incident Management mit Service Desk. Das Incident Management istin Verbindung mit dem Service Desk innerhalb dem Remedy Help Desk ange-siedelt. Mit dem Remedy Help Desk wird die Schnittstelle zur Kommunikationzwischen Kunden und Unternehmen geboten. Ausgangspunkt ist die Aufnahmeder Service Requests. Der Remedy Help Desk ist an dem bereits angesprochenProzessablauf 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) aufzu-nehmen und ein Ticket zu erzeugen. So bietet das Tool von Remedy entlangdes Ablaufs verschiedene Möglichkeiten, welche sowohl Mitarbeiter des Unter-nehmens hinsichtlich einer Effizienz- und Produktivitätssteigerung des ServicesSupports, als auch die Kunden unterstützen sollen. Grundsätzlich wird dabeiein hoher Automatisierungsgrad betont, der sich u.a. durch die automatisierteWeiterleitung der Tickets an die relevanten Support-Bereiche zeigt. Der Kun-de kann bspw. den Status „seines“ Requests abfragen und kann sich so überden Status quo der Bearbeitung informieren. Der Mitarbeiter des Remedy HelpDesk wird dahingehend unterstützt, dass eine automatische Weiterleitung desTickets an den zuständigen Support-Bereich erfolgt. Remedy bietet ein Systemfür die Klassifizierung bzgl. der Priorität, der Abgrenzung und der Reichweitedes Incidents an. Des Weiteren wird die Datenbank angeführt, welche allgemei-ne Lösungen und auch Lösungen für bereits bekannte Fehler zur Bearbeitungder Anliegen zur Verfügung stellt. Die Mitarbeiter können diese integrierte Da-tenbank durchsuchen und falls eine Lösung vorhanden ist, diese dann an denKunden weitergeben. Wird keine Lösung gefunden, erfolgt eine Weiterleitungan Spezialisten.Vor allem die angesprochene Automatisierung und die Vereinfachung derSupport-Prozesse sind Eigenschaften, die nach den Informationen der Home-page, als Pluspunkte für dieses Tool zu sehen sind. Weitere Informationen zumRemedy Help Desk liefert auch die Betrachtung des Problem Managements.

Problem Management. Die Umsetzng des Problem Managements erfolgtbei Remedy auch innerhalb des Moduls Remedy Help Desk. Da in diesem Modulebenfalls die Umsetzung des Incident Managements enthalten ist wird sicher-gestellt, dass das Problem Management auf die zuvor im Incident Managementaufgenommenen Daten zugreifen kann. Des Weiteren ist für das Problem Mana-gement ein separates Klassifikationssystem enthalten, durch das die Problemenun weiter beschrieben und klassifiziert werden können. Diese Klassifikation istwichtig, um die Auswirkungen, die Dringlichkeit, die Priorität und den Statusdes vorliegenden Problems zu erfassen. Um im Folgenden die einem Problemzugrunde liegenden Ursachen ausfindig zu machen, ist das Programm in der


Lage, das aufgenommene Problem automatisch auf Übereinstimmungen mit be-reits vorhandenen Incidents, Problemen und Known-Errors zu überprüfen. DerVorteil ist hier das Vorhandensein einer CMDB, die einen Überblick über dievorhandenen CIs gibt und somit als Hilfsmittel bei der Fehlersuche eingesetztwerden kann. Die Probleme werden mit Hilfe des Programms über die ver-schiedenen Stufen innerhalb des Problem Management Prozesses verfolgt undüberwacht. Gleichzeitig werden Audits erstellt, um alle betroffenen Anwend-ergruppen über den aktuellen Stand informieren zu können. Da alle Schrittedokumentiert werden, ist es möglich den Analyseprozess neuer Probleme weiterzu unterstützen. Außerdem ist diese Dokumentation hilfreich, um auch die an-deren Prozesse über den aktuellen Stand und über die Lösungen der Problemezu informieren. Da eine Anbindung an die anderen Prozesse durch den kom-binierten Einsatz z. B. der Module Remedy Asset Management und RemedyChange Management durch Remedy möglich ist, ist somit auch für die notwen-dige Kommunikation und Zusammenarbeit zwischen den Prozessen gesorgt.

Change Management. Remedy IT Service Management bietet für diesenBereich eine Unterstützung an. Für das Modul Remedy Change Managementwird genügend Information geboten, sodass es hier möglich ist, eine detailliertereVorgehensweise vorzunehmen. Im Folgenden sollen die genannten Forderungenim 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 mitanderen 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, dasseine Klassifizierung hinsichtlich der Akzeptanz, der Erfassung sowie derSpeicherung vorgenommen wird. Das Ticket kann durch das ganze Systemhindurch verfolgt werden und jederzeit aufgerufen und weiterbearbeitetwerden. Zudem bietet es einen Automatismus bzgl. des Genehmigungs-verfahrens. Kunden, die durch diese Änderung betroffen sind, werdenbenachrichtigt und können sich somit darauf einstellen.

Erstellung von Zeit-/Installationsplänen und deren Implementierung:Im Rahmen der Implementierung muss bedacht werden, dass die Auswir-kungen einer Änderung oftmals nicht vollständig vorhersehbar sind. EinRestrisiko bleibt stets vorhanden. Dieses gilt es jedoch zu minimieren. Ausdiesem Grund ist eine genannte Anforderung an das Werkzeug, dass einvorhandenes Backout-Verfahren vor der Implementierung zugrunde liegenmuss. Diese Möglichkeit bietet Remedy Change Management. Um jedochschon im Vorfeld das Risiko einer negativen Auswirkung gering zu halten,kann mit Remedy dieses Szenario durchgespielt werden. Dadurch könnendie Gefahren wie die eines Ausfalls oder sonstige Unannehmlichkeitenminimiert werden.

Freigabe der Änderung, Evaluierung und Abschluss: Die Software bie-tet zudem Kontrollmöglichkeiten bezogen auf die Auswirkungen, die Kos-ten, die Ressourcen sowie die Risiken. Das Ergebnis kann wiederum alsGrundlage für weitere Änderungen verwendet werden. Remedy Change


Management bietet zudem nicht nur die Möglichkeit zur Ablaufplanungund Aufgabenzuweisung, sondern stellt auch die Software für die anschlie-ßende Evaluierung zur Verfügung.

Release Management. Remedy hebt nicht explizit eine Umsetzung des Re-lease Managements hervor.

Configuration Management. Das Configuration Management wird durchdas Remedy Asset Management unterstützt. Dies behandelt die Verwaltung derAssets (IT-Anlagegüter).9 Als Ausgangspunkt für die Umsetzung des Configura-tion Managements verfügt Remedy über eine integrierte CMDB. Darin werdenalle CIs sowie deren Beziehungen gespeichert. Der Zugriff darauf ist prozess-übergreifend möglich, um die Quellen verschiedener Probleme möglichst schnellausfindig zu machen. Des Weiteren besteht mit Remedy die Möglichkeit für ver-schiedene Personen oder Abteilungen Standardkonfigurationen zu definieren.Im Rahmen der Funktion des Lifecycle Asset Management, welches im RemedyAsset Management enthalten ist, können die CIs während ihrer gesamten Dauerinnerhalb des Unternehmens verfolgt und überwacht werden. So ist darin aucheine Erstellung von Zeitplänen für die Wartung und Prüfungen möglich, umeinen Ausfall der Komponenten im Vorfeld zu verhindern. Durch diese Überwa-chung der einzelnen CIs ist es möglich, veraltete Soft- und Hardware zu erneuernund damit Unstimmigkeiten zwischen der Datenbank und den tatsächlichen CIsaufzufinden. Hierbei kann aus vorgegebenen Standardkonfigurationen gewähltwerden, damit die vorgegebenen Konfigurationen auch eingehalten werden. Nacherfolgter Genehmigung wird die Bestellung durch das Programm automatischgeneriert.Durch eine Verknüpfung mit den Modulen Remedy Help Desk und dem RemedyChange Management, kann jederzeit der Bestand prozessübergreifend geprüftund Bedarfsmeldungen an die anderen Prozesse geben werden. Um die Sicher-heit und Vollständigkeit der Daten zu gewährleisten, enthält Remedy zusätz-lich die Möglichkeit Autoritätsüberprüfungen oder Namensübereinstimmungendurchzuführen.

Zusammenfassung. Für Remedy lässt sich festhalten, dass mehrere der vonITIL genannten Prozesse im Service Support umsetzt werden. So umfasst derRemedy Help Desk das Incident Management in Verbindung mit dem ServiceDesk und das Problem Management.Auch der Remedy Help Desk basiert auf einem Ticket-System, wodurch die auf-gestellten Anforderungen nach einer organisierten Erfassung und Verarbeitungder Daten umgesetzt werden. Durch das Modul Remedy Change Managementerfolgt eine Umsetzung des Change Managements. Die oben erarbeiteten An-forderungen für diesen Prozess werden dabei im Wesentlichen umgesetzt, alsBeispiel sei das in diesem Werkzeug vorhandene Backout-Verfahren erwähnt.Auch die genannten Anforderungen an das Configuration Management werdenweitestgehend durch das Modul Remedy Asset Management umgesetzt. Auf ei-ne Umsetzung des Release Managements wird nicht näher eingegangen, so dasshier keine Überprüfung von Anforderungen möglich war.

9Für die Assets wurde bisher die Bezeichnung CIs verwendet


4.5 FazitAbschließend lässt sich sagen, dass es innerhalb von ITIL freigestellt ist, obunterstützende Werkzeuge verwendet werden sollen oder nicht. Die Grundsätzevon ITIL sind auch mit jeglichen Mitteln umsetzbar, im einfachsten Fall sogarmit Papier und Bleistift. Dennoch kann der Einsatz eines Tools zur Effizienz-steigerung und damit auch zu Zeiteinsparungen führen. Damit stellte sich dieFrage, was ITIL-unterstützende Werkzeuge leisten sollten. Im Rahmen dieserArbeit war es das Ziel, Anforderungen an ein ITIL-unterstützendes Werkzeugherauszuarbeiten.Die Betrachtung von Anforderungen innerhalb der Prozesse im Service Supporthat aufgezeigt, dass verschiedene Punkte wiederholt auftreten. Diese lassen sichfolgendermaß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 inKapitel 4.4 näher betrachtet wurden. Anhand dieser beiden ließ sich exempla-risch aufzeigen, dass die Programme einige Prozesse bereits umsetzen und somitden aufgestellten Anforderungen teilweise genügen.Die Werkzeuge können unterstützend wirken, der Erfolg ist aber natürlich zumGroßteil von der Fähigkeit des Menschen abhängig. So ist die Nutzung einer nochso strukturierten Datenbank nur dann erfolgreich, wenn die Menschen sie auchbenutzen und bspw. die Aktualisierung der Datenbanken nicht vernachlässigen.D. h. es ist ein Irrtum zu glauben, dass allein der Einsatz eines Tools bereits zueiner erfolgreichen ITIL-Umsetzung führt. So gilt auch hier: „a fool with a toolis still a fool“.


[Bre07] Brenner, M.: Werkzeugunterstützung für ITIL-orientiertesDienstmanagement: Ein modellbasierter Ansatz, 1. Auflage,Dissertation München 2007.

[Cla] Clauss, C.: Beispielhafte Evaluierung der Anpassbarkeit von OTRSan 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üreffizientes IT-Management durch Prozessorientierung, 2. Auflage,Hanser Verlag, 2006.

[Fis06] Fischlin, R.: Leitfaden ITIL-Service Desk. Fraunhofer Institut fürInformations- und Datenverarbeitung. Network Operation CenterNOC. 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 technischenUnterstützung eines zentralen IT-Service-Desk mit OTRS an derTUM. 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 aufITIL. 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

http://www.mnm-team.org/pub/Fopras/clau06/PDF-Version/clau06.pdf

http://www.mnm-team.org/pub/Fopras/clau06/PDF-Version/clau06.pdf

http://edoc.hu-berlin.de/conferences/dfn2006/fischlin-roger-105/PDF/fischlin.pdf

http://edoc.hu-berlin.de/conferences/dfn2006/fischlin-roger-105/PDF/fischlin.pdf

http://www.mnm-team.org/pub/Diplomarbeiten/haer07/PDF-Version/haer07.pdf

http://www.mnm-team.org/pub/Diplomarbeiten/haer07/PDF-Version/haer07.pdf

http://www.infoworld.com/article/04/09/24/39FEitil_1.html


[Otr08] OTRS AG - Consulting, Software Development, Support undTraining rund um OTRS. URL: http://www.otrs.com/de. Datumder Abfrage: 04.02.08.

[Pfl05] Pfleger, B.: Evaluierung von Werkzeugen zur Unterstützung der ITILService Management Prozesse. Diplomarbeit am Institut fürInformatik. 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 onBMC.com. URL: http://www.bmc.com/remedy/. Datum derAbfrage: 26.02.08.

http://www.otrs.com/de

http://www.nm.ifi.lmu.de/pub/Diplomarbeiten/pfle05/PDF-Version/pfle05.pdf.

http://www.nm.ifi.lmu.de/pub/Diplomarbeiten/pfle05/PDF-Version/pfle05.pdf.

http://www.bmc.com/remedy/

Documents

Betriebsinformatik-Projekt ITIL und die IT- · PDF fileVorwort ITIL (IT Infrastructure Library) ist ein de facto-Standard für das IT Service Management. Er wurde gegen Ende der 1980er