You are on page 1of 138

Betriebsinformatik-Projekt — ITIL und die IT-Wirklichkeit

Prof. Dr. Thorsten Spitta – Dipl.-Inform. Meik Teßmer Universität Bielefeld Fakultät für Wirtschaftswissenschaften Angewandte Informatik Wintersemester 2007/2008

Vorwort
ITIL (IT Infrastructure Library) ist ein de facto-Standard für das IT Service Management. Er wurde gegen Ende der 1980er Jahre in England entwickelt und hat sich seitdem ständig weiterentwickelt. ITIL definiert verschiedene Rollen und Funktionen, die helfen sollen, die IT-Infrastruktur effizient einzusetzen, Dienstleistungen anzubieten und zu verbessern sowie eine hohe Service-Qualität zu gewährleisten. Im Rahmen dieses BI-Projekts sollen die verschiedenen ITIL Service ManagementFunktionen betrachtet werden sowie eine mögliche Anwendung des Standards in der lokalen IT. Auch Gründe, die gegen einen Einsatz von ITIL sprechen, sollen untersucht werden. Die Teilnehmer waren: Carolin Ahlert, Michael Bochenek, Björn Borgmeier, Sonja Bozionek, Linda Gerstenberger, Tim Kattner, Andre Kröger, Julius Kuhljürgen, Kathrin Stegmann, Julia-Vanessa Stork, Christian Teicher, Christopher Uhrig.

Bielefeld, im März 2008 Prof. Dr. Thorsten Spitta Dipl.-Inform. Meik Teßmer

3

4 .

. . . . . . . . . 1. 3. . . . . . . . . . . . . . . . . 1. . . . 1. . . . . . . . .3. . . . . . . . . . . . . . . . . . . . . . .2. . 2 ITIL-Zertifizierung nach ISO/IEC 20000 2. . . . . 2. .1 Einleitung . . . . . . . . .1 Entwicklung . . . . 1. . . . . . . . . . . . . . . . 2. . . . .2. . .2 Incident Management . . .5 Planung und Implementierung des Service Managements 2. . . . . . . . . . . .2 Grundlagen des IT-Security Management . . . .4 Fazit . . . . 1. . . . . . . . . . . . . . . . . . . 3 ITIL und IT-Sicherheit 3. .3 Kritik und Empfehlung . .5 Release Management . .3. . . . . 2. . . .2 Service Support . . . . . . . . . . . . . . . . . . . . . . .6 Anforderungen an Service-Management-Prozesse .3 Problem Management . .3 Untersuchung des IT-Managements in der Universität Bielefeld 1. . . . .2. . . . . . . . . . . . . . . . . . . . . . . 1. . . . . . . . . . . . . .3. . . . . .1 Fakultät für Wirtschaftswissenschaften . . . . . . . . . . . . . . . . 2. . . . . . . .5 Fazit . . . . . . . . . . . . . . . .4 Change Management . . . . . .1 Einleitung . . .1 Entscheidungsfindung . . 2. . . . . . . . . 2. . . . . . . .2 Fakultät für Rechtswissenschaft .2. . .4 Zertifizierungsprozess . . . . . . . . . 2. . .Inhaltsverzeichnis 1 ITIL-Wirklichkeit an der Universität Bielefeld 1. . . . . 2. . .2. . . .3 Struktur . . . . . . .2. . . . . . . . . . . . . . . . .3. . . . . . . . .1 Service Desk .2. . . . .5 Fragebogen . . . . .2 Beziehung zu ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Gesetzesanforderungen.3. .2 Prozessumsetzung . . .2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Die Zertifizierung . . . . . 1. . . . . . . . . . . . 1. 2. . 1. . .1 Einleitung . . . . .2. . .3. . . . . . . . . . . . . . . . . . .6 Configuration Management . . 3. . . . . . .2. . . . . . . . 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . . . .3 Fragenkatalog zur Prozessumsetzung . . . . . . . . . . . . . . . . . . . . . Vorschriften und Standards 5 9 9 10 12 16 22 27 30 32 37 37 40 42 46 48 53 53 54 54 54 55 56 57 58 63 63 64 67 73 74 76 81 81 82 82 84 . . . . . . 2. . . . . . . . . 3. . . . . .2. . .2. . .4 Beurteilung der Zertifizierung . . . . . . . . . . . . . . . 2. . . . . . . . . . . . . 1. . 1. . . . . .4 Anforderungen an ein Management-System . . . . . . 2. . . . .2 Der Standard ISO/IEC 20000 . . . . . . . . .3. . . . . 1. . . . . .2. . . . . . . .1 Informationssicherheit . . . . . . . .

.5 Release Management . . . 4. . . . . . . . . . . . . . . . . . . .2 Werkzeuge . . . . . . . . . 4. . . . .3. . . . .3. 4. . . . . . . . . . . . . . . . . . . . . 4. . . . . . . 4. . . . . 4. . . . . . . . . . 4. . . .4. . . . 94 3. . .2 Das Open Source-Werkzeug OTRS . . . . . . . . .2. . . . . . . . .3 Problem Management . . . . . . . . . . . . . . . . . . . . . . . . . .6 Configuration Management . . . . . .3. . . . . . . . . . . . . . . . . . .4 Change Management . . . . . . .3. . . . . . . . . . . . . . . . .6 3. . . 101 Fazit . . .4 INHALTSVERZEICHNIS Ziele und Aufgaben des IT-Security Management . . . .2. . . . . . . . .4 Change Management . .2 Incident Management . . . . . . . . . . . . . . . . . 4. . . . 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 109 109 110 110 111 112 112 112 116 120 123 125 127 127 127 132 136 3. . . . . . . . . . . . . . . . .6 Configuration Management . 91 3. . 90 3. . . . . . . 99 3. . . . 4. . . . . . . . . . . . . . . . . . . . . . . . 88 Security Management mit ITIL auf operativer Ebene . . . . . . . . . . . . . 4.3. . 90 3. . . . . . . . . . . .2. . . . . . . . . . . .3 Problem Management .4. . . . . . . . . .3. . . . . . .5 Release Management . . . . . . .3 Das kommerzielle Werkzeug Remedy . . . . . . . 4. . 4. . . . . . . . . . . . . .2 Incident Management mit Service Desk . . . . . . . . . . . . . . . . .3. . . . . . . . . . . . .1 ITIL . . . . . . . . . 96 3. .3 3. . . . . . . . . . . . . . . . . . . . . . .1 Einleitung .3.2. . . .4.2 Begriffsabgrenzungen . . . . . . . .1 Vorgehensweise . . . . . . .3 Service Support und Anforderungen an die Werkzeuge 4. . . . .3. . . . . . . . .3. .3. . . . 4. .3. . . . 85 Einordnung von Informationssicherheit und Security Management in ITIL . . . . . . . . . . . . .1 Service Desk . . . . .5 Fazit . . .3 3.4 Betrachtung ausgewählter ITIL-Werkzeuge . . . . . . . . . . . . .1 Vorgehensweise . . . .4 4 ITIL-unterstützende Werkzeuge 4. . . .

Christian Teicher Julia-Vanessa Stork. Julius Kuhljürgen. Michael Bochenek. Sonja Bozionek. André Kröger.Gruppen Thema Gruppe 1: Service SupportUmsetzung an zwei ausgewählten Fakultäten Gruppe 2: ITIL-Zertifizierung nach ISO 20000 Gruppe 3: Security-Management mit ITIL Gruppe 4: Werkzeuge für ITIL Teilnehmer Carolin Ahlert. Tim Kattner Linda Gerstenberger. Christopher Uhrig Björn Borgmeier. Kathrin Stegmann 7 .

8 INHALTSVERZEICHNIS .

Christian Teicher 1.Kapitel 1 ITIL-Wirklichkeit an der Universität Bielefeld Service Support-Umsetzung an zwei ausgewählten Fakultäten Carolin Ahlert. soll nun die Vielzahl der verschiedenen Probleme angegangen werden. sei es ein Krankenhaus oder eine Universität. kann daraus gefolgert werden. soll in dieser Arbeit detailliert dargestellt werden. die sich in der Praxis bereits bewährt haben. Allerdings stellt sich die Frage: Wo fängt die Problemlösung an und wo hört sie auf? Oder allgemeiner: Wie kann der Kunde resp. ist mit dem täglichen Gebrauch der IT konfrontiert. dass dieser de facto-Standard auch für eine Universität vorteilhaft sein muss. dass die Anwendung von ITIL für jedes Unternehmen von Vorteil sei.1 Einleitung Nahezu jedes Unternehmen. Es drängt sich allerdings die Frage auf. Es ist nicht weiter verwunderlich. sei es in der Dienstleistungsbranche oder in der Produktion tätig. Julius Kuhljürgen.“ oder „Mein alter Computer kann mit seiner noch älteren Software dieses Problem nicht lösen. der User am besten unterstützt werden? Laut der ITIL-Philosophie ist dafür der Service Support zuständig. dass Sätze wie „Mein Computer stürzt dauernd ab.“ in diesen Unternehmen zum Alltag gehören. „Ich habe keinen Zugriff auf die Datenbank. Doch wie können diese Probleme bewältigt werden? Wie kann ein möglichst reibungsloser Betriebsablauf gewährleistet werden? Dafür liefert ITIL eine mögliche Lösung.“. ob der von ITIL vorgeschlagene Service Support wirklich so sinnvoll und als „Allheilmittel“ für sämtliche User-Probleme zu verstehen 9 . wird in der vorliegenden Arbeit die Universität Bielefeld resp. Auf Grund der Behauptung. zwei ihrer größten Fakultäten als Untersuchungsgegenstand im Bezug auf ITIL gewählt. Um dieser These nachzugehen. Mit Hilfe von Funktionen und Prozessen. Wie dieser Service Support den User auf operativer Ebene unterstützen kann.

Aus diesem Grund sollen zunächst die Anforderungen von ITIL im Bereich des Service Supports in Kapitel 1. die Service Support-Umsetzung an zwei ausgewählten Fakultäten geklärt werden. Dieser IST-Zustand wurde anhand von Interviews mit den zuständigen EDVMitarbeitern der Fakultäten festgestellt und wird in Kapitel 1. die auf den von ITIL vorgeschlagenen Service Support basieren. Des Weiteren werden diverse Empfehlungen. zum anderen soll die Komplexität und die damit verbundene Schwierigkeit der Implementierung von ITIL verdeutlicht werden. an einer möglichst effizienten IT-Lösung schon lange vor der Einführung von ITIL interessiert sein sollte. Hier sollen die letzten noch offen gebliebenen Fragen im Bezug auf die ITIL-Wirklichkeit an der Universität Bielefeld bzw. Zudem sollten sich in der Universität Bielefeld bereits Grundzüge der ITIL vorfinden lassen. Die ausführliche Darstellung dieses Kapitels hat mehrere Gründe. Gegenstand dieses Abschnitts sein.2 Service Support Für die bereits oben beschriebenen Störungsfällen soll nun der Service Support nach ITIL als Unterstützung im Bereich des operativen IT-Services fungieren und dem Kunden1 bei der Lösung seiner Probleme behilflich sein. Behauptungen nachzugehen und das Konzept der ITIL im serviceorientierten IT-Management in der Realität kritisch zu hinterfragen. sondern auch einen reibungslosen Betriebsablauf im Bereich der IT gewährleisten soll. sollen nun in dem folgenden Kapitel die theoretischen Grundlagen des Service Supports im Hinblick auf seine Funktionen und Prozesse vorgestellt werden. diesen Fragen bzw. Nach der ITIL-Philosophie lässt sich der Service Support im wesentlichen in fünf Geschäftsprozesse und eine unterstützende Funktion untergliedern: 1 Es ist hier sowohl der unternehmensexterne als auch der unternehmensinterne Kunde (Endanwender bzw. Kann mit ITIL bzw. Allerdings gestaltet sich der Aufgabenbereich des Service Supports wesentlich komplexer. Um ein besseres Verständnis für den Service Support von ITIL zu bekommen. Das Fazit dieser Arbeit wird anschließend Thema des Abschnitts 1. . da diese auf dem Best Practice-Konzept beruhen und jedes Unternehmen. auch die Universität Bielefeld.4 sein. da der Service Support nicht nur die Probleme der Endanwender lösen soll. dann sollte der Service Support sofort in der Universität implementiert werden. Anschließend wird die mögliche Anwendung des von ITIL vorgeschlagenen Standards anhand zweier ausgewählten Fakultäten der Universität Bielefeld kritisch evaluiert. Eine daran anschließende Kritik im Bezug auf den IST-Zustand des IT-Services der jeweiligen Fakultäten soll ebenfalls in diesem Kapitel ausgeübt werden. den Sekretärinnen und allen. Zum einen soll dadurch gewährleistet werden.2 vorgestellt werden.3 behandelt. User) gemeint. Ziel dieser Arbeit ist es.10 ITIL-Wirklichkeit an der Universität Bielefeld ist. die mit der Organisation der Universität beschäftigt sind. mit einem ITIL-konformen Service Support den Professoren. 1. Dabei wird zunächst auf die jetzige Situation des Service Supports der jeweiligen Fakultät verwiesen. wirklich geholfen werden? Werden die IT-Probleme der studentischen Hilfskräfte besser gelöst und die Anfragen der Professoren für neue Computer schneller bearbeitet? Wenn diese Fragen mit „ ja“ beantwortet werden können. dass der Leser einen umfangreichen Überblick über die einzelnen Anforderungen an einen ITIL-konformen Service Support erhält.

diese zu beheben bzw. den sogenannten Service Desk. Beim sogenannten Problem Management wiederum geht es vielmehr um die Ursachenforschung. wie zum Beispiel die bereits erwähnte Dokumentation in den Prozessen. die Verbindungen zwischen Datenbanken oder die Lizenzen der Betriebssoftware. welches vom Problem Management zu dokumentieren. • Incident Management. um solche Störungen zu vermeiden. Abbildung 1.und Softwarekomponenten der IT gebündelt und zu neuen Releases zusammengefasst. 3 Änderungsanforderung Incident = Vorfall. je nach Schweregrad zu klassifizieren und zu untersuchen ist. um einen reibungslosen Betriebsablauf zu gewährleisten. dann liegt laut ITIL ein Problem vor. Das Change Management klassifiziert die erhaltenden RfCs und ordnet sie nach ihrer Wichtigkeit. der Grund für eine Störung gefunden. so muss der User sich mit diesem Vorfall. Alle Informationen. auch Incident 2 genannt. dienen. 2 engl. Das Configuration Management ist für die Pflege der zentralen Informationsquelle sämtlicher Prozesse des Service Supports zuständig. Das Incident Management hat zur Aufgabe. als unterstützende Funktion. • Problem Management. Anschließend wird hier entschieden. Dieser soll also dem Kunden als zentrale Anlaufstelle für Probleme und Wünsche bzw. Das Release Management hat somit nach der ITIL-Philosophie die Systemordnung des Betriebs sicherzustellen. Wenn die Ursache einer Störung noch nicht bekannt ist. • Release Management. Dadurch wird auch die enge Verknüpfung des Service Desks mit dem Incident Management deutlich. welche Änderungen zu welchem Zeitpunkt durchgeführt werden sollen. wenden. Ist die Ursache bzw. Hier erfolgt ebenfalls eine Dokumentation der Entscheidungen. werden in einer sogenannten Konfigurationsdatenbank gespeichert. Denn sollte die primäre Hilfe des Service Desks nichts bewirken. Störung an eine Systemkomponente . • Change Management. Einführung von standardisierten Änderungsverfahren zählen zu den wichtigsten Aufgaben des Change Managements. Im Release Management werden dann sämtliche bewilligte Änderungen bezüglich der Hardware. Dabei wird die Durchführung der Änderungen geplant. die laut ITIL auch als Request for Change (RfC) 3 bezeichnet werden. zu erfüllen. kontrolliert und selbstverständlich auch dokumentiert. dokumentiert und versucht. 11 Treten Störungen oder Fehler beim Gebrauch der IT auf. geht von dem Problem Management ein Request for Change an das Change Management. • Configuration Management.Service Support-Umsetzung an zwei ausgewählten Fakultäten • Service Desk. an eine zentrale Kontaktstelle. die vorhandene Hardware im Betrieb. möglichst schnell auf etwaige Incidents zu reagieren und diese zu beheben. Es werden sowohl Störungen im Bereich der IT als auch Wünsche der Kunden entgegengenommen. Anregungen. so wird der Prozess des Incident Managements in Gang gebracht. für die das Configuration Management zuständig ist. getestet. Die Kontrolle über alle Änderungen und die Entwicklung bzw.1 stellt den Aufbau des Service Supports dar.

also Incident Management.1: Service Support. und die Funktion Service Desk detailliert beschrieben werden. des Service Supports. die eine Kommunikation zwischen den verschiedenen Prozesse ermöglichen. Probleme aller Art. Grund dafür ist.1 wird ersichtlich. Change Management und Release Management. So sind zum Beispiel die Aufgaben des Incident Managements in der Rolle des Incident Managers zu beschreiben. um eine Störung des laufenden Betriebs zu vermeiden. dass ITIL oft den Begriff Rolle innerhalb der Prozesse verwendet. ohne die von ITIL vorgeschlagene Aufteilung des Service Supports zu verletzen. sie werden von ITIL als Incident bezeichnet. Beschwerden. stellt jeder Prozess eine in sich geschlossene Einheit dar.2. kurz dargestellt wurden.h. Aus Abbildung 1. da somit eine höhere Flexibilität bei der Einführung bzw. sollen nun in den folgenden Abschnitten die einzelnen Prozesse. allerdings existieren Schnittstellen. bearbeitet und gelöst werden. 1. der Aufbau der operativen Ebene des serviceorientierten IT-Managements. Fragen. Des Weiteren ist noch anzumerken. existieren eine Reihe von verschiedenster Vorfälle. müssen möglichst schnell erfasst. So kann beispielsweise in kleineren Betrieben eine Person sowohl Incident Manager als auch Configuration Manager sein.12 ITIL-Wirklichkeit an der Universität Bielefeld Incident S e r v I c e D e s k Incident Management Incident IT Operations Problem Management Configuration Management RfC RfC Change Management Release Management Incident / Request for Change Informationsfluss Abbildung 1. In diesem . dass die ITIL-Prozesse unabhängig von der Organisationsstruktur des Betriebs sein sollten. der Umsetzung von ITIL gewährleistet werden kann. d. Configuration Management. Nachdem die Zusammenhänge bzw. die in einem laufenden Betrieb im Bereich der IT zum Alltag gehören.1 Service Desk Wie bereits in dem vorangegangenen Abschnitt gesagt. Problem Management.

Dadurch entsteht ein unnötiger Mehraufwand. 4 Service Desk wird oft auch mit den Begriffen Help Desk oder User Desk beschrieben. 34] Auf Grund der Tatsache. dass ein Incident Manager auch Mitarbeiter des Service Desk ist et vice versa. Ebenso hätten weitaus schlimmerere Konsequenzen eintreten können. Der Service Desk soll laut ITIL als zentraler Anlaufpunkt für sämtliche Incidents dienen und das Kommunikationsinstrument zwischen Service Support und Endanwender sein. die aktive Unterstützung des Mitarbeiters. Die Problematik ist allerdings dabei. 33] Die wichtigsten Aufgaben des Service Desk sind demnach: • einheitliche zentrale Kommunikationsschnittstelle (SPOC) zwischen Usern und Support in Verbindung mit Ausgabe von Informationen. Fragen. auch First Level Support genannt. dass der Service Desk die einzige Kommunikationsstelle zwischen Support und Kunden ist. da er mehr oder weniger die Schaltstelle für die übrigen Prozesse darstellt. wird er auch als Single Point of Contact. geplanten Änderungen. der hätte vermieden werden können. Angenommen. „Ziel des Service Desks ist es. da versucht werden soll. . Dokumentation und Auswertung von Vorfällen. Da er jemanden vom Service Support kennt.. sollen hier gesammelt. möglichst viele Anfragen bereits bei Erstkontaktaufnahme durch den Anwender vollständig zu beantworten und abzuschließen. S.“ [Vic05. zu betonen. klassifiziert und. Warum der Service Desk der einzige Kommunikationskanal zwischen Support und Kunden ist. umgeht er den Service Desk und bittet seinen Bekannten direkt um Hilfe. kurz SPOC. Wünsche. die Fragen oder Störungen bereits hier zu klären und zu beseitigen. Aus diesem Grund wird der Service Desk als eine Funktion und nicht als Prozess des Service Supports verstanden. Das Ziel des Service Desks sollte somit eine hohe Erstlösungsrate sein. „Schwerwiegende Störungen oder sogenannte Massenstörungen könnten nicht mit der ihnen zustehenden notwendigen Priorität behandelt und die Ausweitung auf weitere Anwender könnte nicht verhindert werden.“ [Vic05. die hinter dieser Funktion steckt. dass der Service Desk als einziger Kommunikationsweg wesentliche Vorteile besitzt. um die Dienstleistung. Der Service Desk übernimmt teilweise die Aufgaben des Incident Managements. S. ein Mitarbeiter hat Probleme mit seiner Netzwerkkarte. Belange. Es besteht daher durchaus die Möglichkeit. Hier wird auch die enge Verbindung zum Incident Management deutlich. etc. dass. wenn das gesamte Netzwerk ausgefallen wäre und der Mitarbeiter des Service Supports sich lediglich um diese eine Netzwerkkarte kümmern würde. Grundsätzlich ist aber ihre Bedeutung gleich. zum Beispiel des aktuellen Status von Vorgängen. da mehrere Netzwerkkarten streiken. bevor sich das Incident Management mit ihnen beschäftigt. Probleme. wenn möglich. • Bearbeitung von Problemen mit „Erste Hilfe“ -Charakter. Dieser kümmert sich sofort um die Netzwerkkarte. ITIL benutzt den Ausdruck Service Desk. der Vorfall und der passende Lösungsweg bereits im Service Desk bekannt sind. usw. beantwortet werden. lässt sich am einfachsten anhand eines Beispiels verdeutlichen. • Aufnahme. Die gleichmäßige Arbeitsbelastung der unterstützenden Spezialisten wäre nicht mehr steuerbar und eine zügige Abarbeitung von Incidents oder Problemen mit hoher Priorität wäre gefährdet.Service Support-Umsetzung an zwei ausgewählten Fakultäten 13 Zusammenhang kommt der sogenannte Service Desk 4 ins Spiel. Somit zeigt sich. bezeichnet.

Im nun folgenden Abschnitt sollen nun kurz drei verschiedene Architekturmodelle zur Implementierung des Service Desks vorgestellt werden. seiner Organisation widmen.bzw. nicht nur eine gewisse Kenntnis von der Materie. der über optimale Kenntnisse bezüglich aller Vorgänge innerhalb der jeweiligen Fakultät verfügt. dass jeder Unternehmensbereich oder jede Fakultät anders mit Incidents verfährt und daher andere Systeme oder Prozesse zur Behandlung von Incidents benutzt.14 ITIL-Wirklichkeit an der Universität Bielefeld • Einschätzung von Vorfällen und damit verbundene Weiterleitung der Incidents zu den Supportstellen Incident Management und Problem Management (Second und Third Level Support ). sondern vielmehr auch eine gute fachliche Kompetenz vorweisen können. dass jeder lokale Service Desk auch für die Bereitstellung eines lokalen Service Supports sorgen muss. als problematisch erweisen. 5 Auch 6 In in diesem Dienstleistungssegment gilt: Der Kunde ist König. Die Voraussetzung für die Einführung eines lokalen Service Desks ist allerdings die Bereitstellung eine großen Menge an Ressourcen6 . Aus den Aufgaben des Service Desks wird ersichtlich. Hierbei handelt es sich um eine dezentrale Struktur. Der zentrale Service Desk ist die einzige Anlaufstelle für alle Unternehmensbereiche. dass der Mitarbeiter rhetorische und soziale Fähigkeiten besitzt. Eine mögliche Zusammenarbeit von Fakultäten wäre somit gefährdet. Mit steigendem Informationsgewinn kann die Verteilung der Ressourcen optimiert werden und somit können Kosten gesenkt werden. Es besteht die Möglichkeit.5 Nachdem wir uns mit den Aufgaben. Dies findet seine Begründung darin. da nicht nur ein System zur Bewältigung von Incidents existiert. haben. Zum einen besteht die Möglichkeit eines lokalen Service Desk. Die Vorteile wären eine hohe Intensität im Bereich der Kundenbetreuung und eine verkürzte Reaktionszeit auf sämtliche Incidents der Fakultät.2 soll den Grundgedanken des lokalen Service Desks nochmals verdeutlichen. Abbildung 1. Beispielsweise könnte so eine Universität für jede Fakultät einen eigenen Service Desk. Eigenschaften und Zielen des Service Desks beschäftigt haben. Die Problematik der Zusammenarbeit der Unternehmensbereiche. Sie zeigt auch eine weitere Möglichkeit. Zentraler Service Desk. sondern auch sämtliche Prozesse vereinheitlicht werden. Dieser muss bei einem hohen Kommunikationsaufkommen. in unserem Beispiel bezüglich der Zusammenarbeit von Fakultäten. Bei einem zentralen Service Desk ist zwar der Kommunikations. dass die Anforderungen an den Mitarbeiter des Service Desks sehr umfangreich sind. wie sie beim lokalen Service Desk auftrat. den Service Desk zu strukturieren. Lokaler Service Desk. um einen geeigneten Umgang mit ungeduldigen bzw. ist hier nicht gegeben. Außerdem kann sich eine Einführung eines lokalen Service Supports in Bezug auf die Zusammenarbeit von Unternehmensbereichen. besondere Weise monetäre Ressourcen . unzufriedenen Kunden zu finden. wollen wir uns nun dem Service Desk hinsichtlich seiner Struktur bzw. Des Weiteren empfiehlt es sich. Informationsfluss wesentlich größer als der bei einem lokalen Service Desk. der Informationsgewinn steigt aber ebenfalls. begründet durch die SPOC-Eigenschaft des Service Desks.

einen zentralen Service Support besteht nun aber die Wahrscheinlichkeit. Ein anderes Beispiel wäre die Behandlung von Incidents. desto schwieriger wird sich die kundennahe Betreuung erweisen. Ein Mitarbeiter benötigt einen neuen Computer. Man kann demnach einen Nutzen aus dem somit gewonnenen Informationsgewinn ziehen. da die Mitarbeiter des Service Supports sich über Angebote und Preise austauschen können.Service Support-Umsetzung an zwei ausgewählten Fakultäten 15 „Funktion“ S e r v I c e D e s k 1 st L e v e l S u p p o r t „Prozesse“ „Funktion“ „Prozesse“ A A Z e n t r a l e r S e r v I c e D e s k „User“ Service Support „User“ 1 st L e v e l S u p p o r t „Funktion“ S e r v I c e D e s k 1 st L e v e l S u p p o r t „Prozesse“ B B „User“ Service Support „User“ Service Support Lokaler Service Desk Zentraler Service Desk Abbildung 1. Abbildung 1. Die dritte Service Desk-Struktur versucht die Vorteile der bereits vorgestellten Strukturen zu kombinieren. Der virtuelle Service Desk sieht zwar . -aufwand erheblich zu. es liegt ein Request for Change vor. Angenommen. Allerdings können bei einer Einführung eines zentralen Service Desks auch Probleme entstehen. Die verschiedenen lokalen Service Desks haben folglich die Aufgabe. während der andere Mitarbeiter bereits einen neuen Incident entgegennimmt. ein noch besseres Angebot einzuholen.3 zeigt den sogenannten virtuellen Service Desk. Durch ein Beispiel soll dieser Vorteil verdeutlicht werden. auch hier könnten Kosten gespart werden. Je größer ein Kundenstamm wird. Somit nimmt selbstverständlich auch der Organsisationsbedarf bzw. Durch einen zentralen Service Desk bzw. Virtueller Service Desk. Diese wird das ihrer Meinung nach beste Angebot einholen und den Computer bestellen. Während sich bei dem lokalen Service Desk jeweils ein Mitarbeiter mit ein und demselben Incident beschäftigen würden. könnte man bei einem zentralen Service Desk einen Mitarbeiter mit der Behandlung des Incidents beauftragen.2: Lokaler und zentraler Service Desk. sich um diesen RfC zu kümmern und an die passende lokale Supportstelle weiterzuleiten.

2 Incident Management Bevor man sich mit den Aufgaben. Warum aber der Service Desk und das Incident Management so eng miteinander verknüpft sind und wie die Incidents im einzelnen behandelt werden. lokale Annahmestellen und lokale Support Teams7 vor. Der Aufwand. ebenfalls bei dem virtuellen Service Desk vorzufinden. Des Weiteren wurden Aufgaben.3: Virtueller Service Desk. wie der Service Desk als eine Funktionseinheit auf der operativen Ebene des serviceorientierten IT-Managements wirkt. soll nun im folgendem Kapitel betrachtet werden. Ziele und Organisationsstrukturen des Service Desks vorgestellt. ist erheblich und dementsprechend teuer. Zum einen muss definiert werden.16 ITIL-Wirklichkeit an der Universität Bielefeld „Funktion“ S e r v I c e D e s k 1st L e v e l S u p p o r t A „User“ „Prozesse“ „Funktion“ S e r v I c e D e s k 1st L e v e l S u p p o r t B „User“ Service Support Abbildung 1. was genau ein Incident ist. müssen vorab zwei Sachverhalte erklärt werden. Wir haben nun gesehen. und zum anderen muss 7 Diese sollen vom virtuellen Service Support gesteuert und verwaltet werden . wie auch der erhöhte Informationsgewinn des zentralen Service Desks. Somit sind die Vorteile des lokalen Service Supports. nämlich eine kundennahe Betreuung und eine verkürzte Reaktionszeit auf Incidents. den virtuellen Service Desk zu organisieren. den Zielen und dem Prozess des Incident Managements beschäftigt. 1. aber auch eine zentrale Datenbank.2. Demgegenüber steht aber ein entscheidender Nachteil.

beispielsweise: – „Ich habe mein Passwort vergessen. S. die Ziele. 46] ist ein Incident definiert als: An unplanned interruption to an IT service or reduction in the quality of an IT Service. S. beispielsweise: – bestimmte Netzwerkkarten funktionieren nicht. – ein benötigter Treiber wurde falsch oder gar nicht installiert. wie der Zusammenhang zwischen Incident Management und Service Desk aussieht. – der Zugriff auf eine Software wird verweigert.und VerlustWertes einer Firma errechnet den falschen Wert. • Störung im Bereich der Software. Es existiert eine Vielzahl von Incidents. for example failure of one disk from a mirror set. diese lassen sich zum Beispiel in Abhängigkeit ihres Ursprungs kategorisieren: • Störung im Bereich der Hardware. • Anfragen. Failure of a configuration item that has not yet impacted service is also an incident. das zu einer Unterbrechung oder zu einer Abnahme der Qualität des IT-Services8 führt. Können Sie mir weiterhelfen?“ – „Ich brauche einen neuen Laserdrucker. – Prozessoren haben einen technischen Defekt. – Bildschirme einer gewissen Marke empfangen nicht das gewünschte Signal. Ein Incident kann also als ein Ereignis verstanden werden. „Der Service Desk übernimmt als Funktion innerhalb des Incident Managements weitgehend die operative Steuerung und Dokumentation der Aktivitäten der IncidentBearbeitung.“ [Olb06. beispielsweise: – die Software des Users zur Berechnung des Gewinn. Laut dem Office of Government Commerce [OGC07. . die mit dem User oder Kunden über die Höhe der Service-Dienstleistung getroffen wurden. mögliche Einflüsse durch Störungen auf den Betrieb zu minimieren und das vertraglich vereinbarte Service Level Agreements (SLA) 10 halten zu 8 Unter dem Begriff „Abnahme der Qualität des IT Services“ wird hier die Unterschreitung der voher vereinbarten Service-Grenzen verstanden. 28] Gegenstand dieses Kapitels ist aber vorrangig. obwohl man selbst Administrator ist. bei Eintritt eines Störungsfalles die schnellstmögliche Wiederherstellung des normalen Betriebs zu gewährleisten. 10 Vereinbarungen. Können Sie mir einen Bestellen?“ Die Incidents werden im Service Desk9 . die Aufgaben und insbesondere den Prozess des Incident Managements darzustellen. entgegengenommen und bearbeitet. 9 Wie bereits im vorherigen Kapitel ausführlich beschrieben. Mein alter Drucker macht es nicht mehr lange.Service Support-Umsetzung an zwei ausgewählten Fakultäten 17 gekläre werden. Die wichtigsten Ziele des Incident Managements sind. der die zentrale Funktion des Incident Managements darstellt.

• wie der User heißt. Im ersten Schritt wird der Incident aufgenommen. werden hier erfasst und unter einer gemeinsamen Referenznummer in einer Datenbank. der den Incident festgestellt hat. dokumentiert. Control & Communication Service Request Verfahren Problem? ja Weiterleitung an den Support nein Lösung.18 ITIL-Wirklichkeit an der Universität Bielefeld können. 11 Diese Datenbank wird noch ausführlich in dem Abschnitt 1. Wie genau dieser Prozess nach der ITIL-Empfehlung aussehen sollte. dass die einzelnen Schritte des Prozesses zugleich die Aufgaben des Incident Managements bei Eintritt eines Incidents darstellen.4 dargestellt und erläutert. das heißt alle wichtigen Informationen bezüglich des Incidents. dass jeder Incident. und in welcher Abteilung er arbeitet. Dabei ist anzumerken. der sogenannten Configuration Management Data Base (CMBD) 11 abgespeichert bzw. Wiederherstellung Service Incident Closure Abbildung 1. Incident aufnehmen und dokumentieren Klassifizierung und erste Unterstützung Service Request? nein Untersuchung und Diagnose ja Incident aufnehmen und dokumentieren. der im Service Desk aufgenommen wird. einen entsprechenden Prozess im Incident Management auslöst. wie: • wann der Incident festgestellt wurde. usw. Laut ITIL gilt. Monitoring.6. beschrieben. .2. • welcher Kategorie der Incident angehört. wird nun anhand der Abbildung 1.4: Flussdiagramm Incident.

sondern auch die sogenannte Priorisierung. Wie bereit zu Anfang dieses Kapitels beschrieben. „and so that if the incident has to be referred to other support group(s). als wenn der Praktikant einen neuen benötigt 13 Ein guter Service Desk zeichnet sich unter anderem dadurch aus. deren Ursache bekannt ist. von daher im Incident Management-Prozess. zusammen12 . zum Beispiel wie viele User von diesem Incident betroffen sind. . die Priorität setzt sich wiederum aus der Dringlichkeit.Service Support-Umsetzung an zwei ausgewählten Fakultäten 19 Da diese Aufgabe vom Service Desk ausgeführt wird. lassen sich Incidents ihrer Quelle nach kategorisieren. so sollte diese bereits im Service Desk und somit am Anfang des Incident Managements zu beantworten sein13 . aussehen: • einfache Anfragen.und Hardwarebereich und Anfragen unterschieden. • Störungen. deren Ursache unbekannt ist. in denen zum Beispiel die Anzahl der betroffenen User und die Auswirkung des Incidents gegeneinander abgetragen werden. den Incident bereits im Service Desk. 49] Klassifizierung und erste Unterstützung. • Störungen. Es wurde zwischen Störungen im Software. wird an dieser Stelle nochmal die enge Verknüpfung des Incident Managements als Prozess mit dem Service Desk als operative Funktion des Incident Managements deutlich.2. das aber in Abschnitt 1.4. Es gilt: Klassifizierung = Kategorie + Priorität Die Priorisierung bzw.“ [OGC07. welcher sogenannten „Klasse“ der Incident angehört und ob die Möglichkeit besteht. • Anfragen bezüglich einer Änderung im IT-Bereich. wie schnell der Incident behandelt werden muss. Es muss geklärt werden. zu lösen. da die nachfolgenden Support-Gruppen ebenfalls auf die entscheidenden Daten bezüglich des Incidents angewiesen sind. wie folgt. die einem Incident zugesprochen wird. dieser Änderungsantrag wird gesondert in einem Service Request-Verfahren behandelt. wenn der „Chef“ einen neuen Computer will. S. so spricht man von einem Request for Change (RfC). Bezieht sich die Anfrage auf eine Änderung im IT-Bereich. Die Erfassung des Incidents ist äußerst wichtig. Nachdem nun der Incident aufgenommen und dokumentiert wurde. kann laut ITIL über sogenannte Bewertungsmatrizen erfolgen. anders aus. 12 Es existieren aber auch andere Definitionen von Dringlichkeit und Auswirkungen. they will have all relevant information to hand to assist them. So sieht die Dringlichkeit. Die Klassifizierung von Incidents beinhaltet aber nicht nur die Kategorisierung. Eine Klassifizierung von Incidents könnte. Daraus folgt: Priorität = Dringlichkeit + Auswirkung Wie sich die Priorität im einzelnen dann bestimmen lässt. und der Auswirkung. gilt es nun zwei Fragen zu beantworten. Handelt es sich um eine einfache Anfrage seitens des Users. dass er die meisten einfachen Fragen der IT-User bereits im Vorfeld klären kann.

Das Problem Management stellt hier somit in diesem Prozess den Second Level Support dar. die als Ursache einen bereits bekannten Fehler haben. geht das Problem Management den Fehler auf den Grund. Diese Weiterleitung an eine Gruppe von Spezialisten kann theoretisch n-mal geschehen. Dabei wird zwischen zwei Arten von Störungen unterschieden. Da die Anfragen als Incident bereits in den vorangegangenen Schritten des Incident Management-Prozesses bearbeitet wurden. werden ab hier nur noch Störungen des laufenden Betriebs behandelt. . Stellt sich heraus. als Unknown Error bzw. Der Incident wird somit an eine Gruppe von Spezialisten weitergegeben. um anschließend eine Diagnose erstellen zu können. der bereits aus den Herstellern der fehlerhaften Software bzw. sein. Nun gilt es den Incident hinsichtlich seiner Art zu untersuchen. In Anlehnung an [Olb06] soll Abbildung 1. werden als Known Error bezeichnet. Fehler und die damit verbundenen Störungen zu vermeiden. Während das Incident Management versucht. Die bekannten Lösungen werden durch die CMDB bereitgestellt. Das Incident Management hat zu jeder Zeit Zugriff auf diese Datenbank und die sich darauf befindlichen Lösungen. deren Ursache unbekannt ist14 . Hier kann das Incident Management durch seinen First Level Support bereits helfen und aktive Unterstützung durch Bereitstellung der Lösung leisten. Wird der First Level Support an seine Grenzen gebracht. also bis zu einem n-ten Level Support fortgesetzt werden. mit der der Fehler endgültig gelöst wird. in der sich sämtliche durch das Problem Management erarbeitete Lösungen für die verschiedensten Incidents befindet15 . so existiert bereits eine Lösung für diesen Fehler.5 die funktionale Eskalation verdeutlichen. die Störungen. An dieser Stelle wird auch nochmals das Ziel des Incident Managements und damit der Unterschied zum Problem Management mehr als deutlich. ein sogenannter Workaround. Untersuchung und Diagnose.20 ITIL-Wirklichkeit an der Universität Bielefeld separat behandelt wird. Die Störungen. Dieser Vorgang wird bei ITIL als funktionale Eskalation bezeichnet. der Prozess des Incident Managements fortgesetzt. Problem. dass sowohl die Klassifizierung als auch die erste Unterstützung durch den Service Support dokumentiert und in der CMBD abgespeichert wird. mit der der Fehler lediglich umgangen wird. ob der Incident durch das Incident Management selbst oder durch die anderen Support-Stellen behoben werden kann. so wird erstmal unabhängig davon. Hardware besteht. ob die Ursache bekannt oder unbekannt ist. wird dieses Problem dann an das Problem Management weitergeleitet. Diese Spezialisten werden als Second Level Support bezeichnet und verfügen im Gegensatz zum First Level Support über ein größeres Fachwissen und eine bessere Ausstattung. Liegt allerdings eine Störung vor. Dies kann eine einfache Handlungsanweisung. Falls ein Incident „unbekannter Natur“ ist. es sich von daher um ein Problem 14 Es 15 Dies kann auch mehrere Ursachen für ein Problem geben soll aber erst im folgenden Abschnitt genauer erläutert werden. dass es sich um einen Known Error handelt. oder eine Umgehungslösung. um Incidents zu behandeln. Bei ITIL wird aber lediglich von einem Third Level Support gesprochen. ein Incident wird daher als Problem diagnostiziert. Wichtig sei hier noch zu erwähnen.

5: Ablauf der funktionalen Eskalation. Nachdem alle Informationen bezüglich des Incidents zusammengetragen und untersucht wurden. Service Support erarbeitet wurde. dass der Auftrag ausgeführt. An dieser Wiederherstellung des Betriebs wird daher nochmal die Aufgabe des Incident Managements. bereitstellen. . Die Ursache des Incidents wurde nicht untersucht. der zuvor an das Change Management weitergeleitet und von diesem bearbeitet wurde. bereitstellen. Für die Wiederherstellung des standardisierten Betriebs kommen hier folgende Möglichkeiten in Frage: • Der Workaround. In dieser Antwort kann dann enthalten sein. der lediglich eine Umgehungslösung darstellt. der sein altes Passwort vergessen hat. dass er abgelehnt wurde. nicht die Ursachen des Incidents zu untersuchen.Service Support-Umsetzung an zwei ausgewählten Fakultäten 1st Level Support Untersuchung und Diagnose 21 2nd Level Support Problem? ja Untersuchung und Diagnose 3rd Level Support Untersuchung und Diagnose n-ter Level Support Untersuchung und Diagnose nein Lösung? nein Lösung? nein Lösung? ja ja ja Lösung. aber auch. • Auf einen Request for Change. so ist das Problem Management davon in Kenntnis zu setzen und der Incident zu übergeben. die bereits im Incident Management bekannt ist. handelt. Das heißt. Wiederherstellung des Services. antworten. die vom nachfolgenden Problem Management bzw. Wiederherstellung Service Abbildung 1. • Die Lösung. oder ein Incident immer wiederkehrt. kann nun ein möglicher Lösungsweg ausgewählt und getestet werden. • Die Lösung. ein Unknown Error wird zum Known Error und es kann durch das Incident Management darauf zugegriffen werden. Lösung. mehr als deutlich. sondern lediglich den laufenden Betrieb zu gewährleisten. Das heißt zum Beispiel ein neues Passwort an einen User liefern.

Doch damit ist der Prozess noch nicht ganz beendet. Doch was passiert mit den Problemen. was natürlich ganz klar von Vorteil ist. nämlich eine schnelle Wiederherstellung des laufenden Betriebs. die kontrolliert. Ein weiterer wichtiger Begleiter des Incident Managements ist die Kontrolle des Incidents. die Aufgaben und somit der Prozess mit allen einzelnen Instanzen des Incident Managements vorgestellt. Ein mögliches Mittel ist hierzu zum Beispiel die Bereitstellung einer bereits bekannten Lösung in Form von einer Handlungsanweisung oder die Anwendung eines Workarounds. sozusagen die IT Operater. ein Incident würde sich zu lange im Subprozess „Klassifikation und erste Unterstützung“ befinden. Es wurde nun gezeigt. dass für die Ausführung der gerade dargestellten Möglichkeiten sowohl der Service Desk selbst als auch extra dafür eingerichtete Service Support Teams. die Gewährleistung eines laufenden Betriebs. Um solche Fälle zu vermeiden. kann der Incident im Incident Closure „formell“ abgeschlossen werden. So besteht zum Beispiel zu keiner Zeit die Möglichkeit zur Stagnation der Behandlung eines Incidents. dass sämtliche Incidents den hier vorgestellten Prozess durchlaufen. könnte man zum Beispiel eine Art „Zeitkontrolle“ einführen. Nachdem die Anfrage beantwortet oder die Störung beseitigt und somit der User zufrieden gestellt wurde. diese Frage soll nun im nächsten Abschnitt geklärt werden.3 Problem Management Im vorangegangenen Abschnitt wurde das Ziel des Incident Managements dargestellt. Incident Closure. dessen Ursache nicht klar ist. wie lange sich ein Incident in einer Instanz des Incident Managements befindet und überhaupt befinden darf. Wichtige und dauerhafte Begleiter aller Subprozesse des Incident Managements sind Monitoring. Dies lässt sich am einfachsten anhand eines Beispiels verdeutlichen. Hier ist sowohl die Kommunikation zwischen Incident Management und User als auch die Kommunikation des Incident Managements und dem Service Support gemeint. Des Weiteren wurden das Ziel. Angenommen. Monitoring. Dies kann sich positiv auf die Resonanz auf den Service Desk bzw. ohne das aufwendige Analysen durchgeführt werden müssen. Unter dem Begriff Monitoring wird hier die Erfassung. da somit gewährleistet werden kann. Control & Communication. Kontrolle und Kommunikation. Dies betrifft im besonderem Maße die Lösung des Incidents. Der letzte wichtige Aspekt ist die Kommunikation. auf das Incident Management auswirken. Wichtig ist nämlich hierbei das sämtliche Informationen bezüglich des Verlaufs der Incident-Behandlung im Incident Record abgespeichert werden. also den Incidents.22 ITIL-Wirklichkeit an der Universität Bielefeld Es sei hier noch erwähnt. . in Frage kommen. Doch woher kommen die bekannten Lösungen von Fehlern bzw. Beobachtung und Überwachung des Incident Managements verstanden. So kann zum Beispiel ein User immer über den Prozess informiert werden und ist somit immer „auf dem Laufenden“. 1.2. da er als zu unwichtig eingestuft wird. Nach einer Weile würde er in Vergessenheit geraten. dass bereits der Service Desk bei Eintritt desselben Incidents auf die passenden Incident-Details zurückgreifen und entsprechende Maßnahmen ergreifen kann.

wie folgt. und deshalb nicht einwandfrei läuft. wird dieser Incident zum Problem. wenn die drei Aufgabenbereiche des Problem Managements. erneut auftreten. dessen Programme nicht ordnungsgemäß ausgeführt werden. aber ein und derselbe Incident tritt immer wieder von neuem auf. zu minimieren. dass ein Problem durchaus ein Resultat von mehreren Incidents sein kann. welches Ziel das Problem Management haben sollte und welche Anforderungen an das Problem Management gestellt werden. Incidents zu vermeiden. hingegen hat der Ausfall eines Server auf Grund eines Defektes aber einen ganz anderen Stellenwert. 58] Dass man es mit einem Problem zu tun hat. definieren: „The primary objectives of Problem Management are to prevent problems and resulting incidents from happening. „ITIL defines a problem as the cause of one or more Incidents“. Bei einzelnen Computerfestplatten wäre dieser Vorfall nicht so schlimm. Hierbei ist zu erwähnen. 58 f. S.] Das Ziel ist daher. Als Beispiel könnte hier ein Computer genannt werden. nach gewisser Zeit wird also derselbe Incident. [OGC07. S. Sobald ein Incident eine unbekannte Ursache hat. das nicht in der Lage ist. Problem Control. weitergeleitet zum Problem Management. eine Universität würde eine bestimmte Software zur Verwaltung von Noten benutzen. aber auch ganze Unternehmen betroffen sein. zum anderen kann das Incident Management zwar einen Workaround bzw. Hilft dieser Neustart nicht. sollen kurz weitere Beispiele folgen. Um die Vielfältigkeit von Problemen und die damit betroffenen Personengruppen darstellen zu können. merkt man an zwei Sachverhalten. Bei einer Bank zum Beispiel könnte dies katastrophale Auswirkungen haben. Auch hier wären die Auswirkungen definitiv zu merken. Softwareprobleme: Einmal angenommen.Service Support-Umsetzung an zwei ausgewählten Fakultäten 23 Problemen und woher kommen die Workarounds. Diese arbeitet allerdings immer wieder fehlerhaft und ordnet die Noten nicht den gewünschten Personen zu. Als Probleme kommen in Frage: Virenprobleme: Hiervon können einzelne Mitarbeiter. die nicht vermieden werden konnten.“ [OGC07. Zum einen kann das Incident Management nicht mehr weiterhelfen. wiederkehrende Incidents zu eliminieren und die Auswirkungen der Incidents. Hardwareprobleme: Man kann nicht mehr auf eine bestimmte Festplatte zugreifen. to eliminate recurring incidents and to minimize the impact of incidents that cannot be prevented. so spricht man hier eher von einem Problem als von einem Incident. Es lässt sich der ITIL-Philosophie nach dann erreichen. da sie defekt ist. also die nicht ordnungsgemäße Ausführung der Programme. Als Workaround würde das Incident Management einen Neustart des Computers empfehlen. Dieses wird vom Incident Management. Laut ITIL lässt sich das Ziel des Problem Managements. Diese Reihe an Beispielen für Probleme könnte beliebig lang fortgesetzt werden und verdeutlicht ganz klar. dieses Problem zu behandeln. Die Auswirkungen beziehen sich auf den Ausfall eines Computers bis hin zu ganzen Servern. eine Lösung liefern. . Dieses muss dann von dem Problem Management behandelt werden. Probleme bzw. die im Incident Management ihre Anwendung finden? Die Antworten dafür sind im Problem Management zu finden.

6 verdeutlicht die Zusammenhänge der beiden Aufgabenbereiche. einen bekannten Fehler mit Lösung. sobald ein Incident bzw.6: Flussdiagramm-Problem. ein Fehler ohne bekannte Lösung. Während die Prozesse der ersten beiden Aufgabenbereiche. Ein Ziel des Problem Controls ist es also. . erfolgreich ausgeführt werden. so wird das Problem weitergeleitet. wie aus den Abbildungen 1. aber auch die Schnittstelle des Incidents Managements mit dem Problem Management. genauso wie die des Service Desks bzw.4 und 1. zu machen und ihn damit. bereits im Incident Management entschieden. wird. kontrollieren zu können. dann ausgelöst werden. Abbildung 1. Problem Control. Dies geschieht in den nun folgenden Schritten. Ist dies der Fall. wird dem Proactive Problem Management eine besondere Bedeutung zugesprochen und separat behandelt. Ob es sich tatsächlich um ein Problem handelt. werden Incidents mit unbekannter Ursache als Problems bezeichnet. aus dem Unknown Error einen Known Error. Problem eintrifft. Wie bereits schon erwähnt.24 ITIL-Wirklichkeit an der Universität Bielefeld Error Control und Proactive Problem Management. „Incident“ „Problem“Control Unknown Error Identifizieren & aufzeichnen „Error“Control „Change“ Problem? nein ja Problem Klassifizierung Untersuchung & Diagnose Known Error ? nein Eskalation ja Known Error Identifizieren & aufzeichnen Untersuchung & Diagnose Fehler Beschluss RfC? ja Change Management nein PIR Problem Closure Abbildung 1. wie das Wort „Control“ bereits sagt. Incident Managements.6 ersichtlich. Der Auslöser für den Prozess des Problem Managements ist somit ein Unknown Error. Doch sollen zunächst die Bereiche Problem Control und Error Control dargestellt werden.

Nachdem sich das Problem Control mit der Ursache des Problems beschäftigt hat und der Unknown Error zu einem Known Error umgewandelt wurde.. sollen hier die verschiedenen Lösungsmöglichkeiten erarbeitet werden. .17 Error Control. von dem Zeitpunkt der Feststellung des Problems bis hin zur Beendigung des Problems. Lösungsmöglichkeiten und Workarounds an die Hand zu geben. Sollte das Wissen dieser Experten nicht ausreichen. so werden weitere Fachkräfte zu Rate gezogen. Es ist noch anzumerken.Service Support-Umsetzung an zwei ausgewählten Fakultäten 25 Unknown Error identifizieren & aufzeichnen: Im ersten Schritt wird der Unkown Error identifiziert.. Untersuchung & Diagnose: Nachdem der Fehler bekannt gemacht und dokumentiert wurde. Da diese Klassifizierung ähnlich zu der Klassifizierung eines Incidents verläuft. welche Software davon betroffen ist usw. kurz um einen Unknown Error. Welche der Lösungen genau gewählt wird. da bereits sowohl der Incident als auch das Problem identifiziert und aufgezeichnet wurden. Es soll herausgefunden werden. Des Weiteren wird der Unknown Error oder auch das Problem in einem sogenannten Problem Record aufgezeichnet und in einer Datenbank abgespeichert.16 Untersuchung & Diagnose: In den nun folgenden Subprozessen Untersuchung & Diagnose und Eskalation wird nun versucht. es handelt sich deshalb immer noch um ein ungelöstes Problem. es geht hier allerdings vielmehr um die Verknüpfung zwischen Known und Unknown Error. Es wird hier sowohl die Kategorie des Problems als auch die Priorität des Problems festgelegt.] und dem Service Desk so weit wie möglich Informationen. wird dieser dem Error Control übergeben. Problem Klassifizierung: Nachdem das Problem aufgenommen ist. Dies erfolgt in den Schritten: Known Error identifizieren & aufzeichnen: Zuerst müssen auch die umgewandelten Known Errors identifiziert und aufgezeichnet werden. soll hier näher darauf eingegangen werden. werden in diesem Problem Record und somit in der Datenbank festgehalten. S.. dass auch vor der „Untersuchung Abschnitt 1. 17 Da 16 Vgl. um welche Art von Unknown Error es sich hier handelt.“ [Olb06.2. ebenso ob mehrere Incidents an diesem Unkown Error beteiligt sind. die funktionale Eskalation in dem Abschnitt 1. 43] Handelt es sich so dann um einen Known Error.2 behandelt wurde. muss es nun klassifiziert werden. Eskalation: Zur Ermittlung der gerade vorgestellten Lösungen werden Experten herangezogen. erfolgt im nächsten Schritt.2. Die Aufgabe hier ist es „den Problemursachen auf den Grund zu gehen [. aus dem Unknown Error ein Known Error zu machen und eine Lösung für eventuelle Fehler zu finden. Natürlich könnte man in diesem Fall mit unnötigen Mehraufwand argumentieren. Alle Schritte. Die Lösungen können Workarounds oder Requests for Change sein. soll hier nicht weiter darauf eingegangen werden. befasst sich das Error Control mit der konkreten Beseitigung des Fehlers. Es kommt zu der bereits vorgestellten funktionalen Eskalation.2.

dass das Change Management sowohl einem Request for Change zustimmen als auch ihn ablehnen kann. die es im Unternehmen verursacht. ob die vorgegebenen Ziele. wo das nächste Problem entstehen wird und wie es aussieht. Dabei wird geprüft. – entsprechen die Fehler immer einem bestimmten Typ von Fehler. – kann man schon sagen. wird sie hier nicht weiter erwähnt. um diese bereits im Voraus zu vermeiden und gar nicht erst entstehen zu lassen. Deshalb werden hier Fragen untersucht. wie zum Beispiel: – Kommen dieselben Incidents immer aus derselben Abteilung. so muss der Record ergänzt werden. Handelt es sich um Workarounds. an das sogenannte Change Management weiterleiten. Aus diesem Zusammenhang wird deutlich. müssen diese unverzüglich umgesetzt werden. Prozesse „Problem Control“ und „Error Control“ sind eher reaktiver18 Natur. Problem Closure: Nach Abschluss der Prozesse soll in diesem letzten Schritt überprüft werden.)=rückwirkend. Auf Grund ihrer Entwicklung im Bezug auf Auswirkung im Betrieb und Priorität müssen sie dauerhaft beobachtet und.26 ITIL-Wirklichkeit an der Universität Bielefeld & Diagnose“ des Known Errors wiederum eine Klassifizierung des Errors stattfinden kann. wie zum Beispiel die Beseitigung des Fehlers. Post Implementation Review (PIR): Wurden alle notwendigen Änderungen umgesetzt. so darf das Problem Management diese Änderung nicht einfach durchführen. Bei Anlehnung des Request for Change muss das Problem Management eine andere Lösung auswählen und gegebenenfalls einen neuen Request for Change formulieren. 18 reaktiv (lat. wenn nötig. durch die Änderung erreicht wurden. Das Change Management überprüft diesen Antrag auf seine Notwendigkeit und auf die Auswirkungen. Ganz anders ist es bei dem Proactive Problem Management. Nicht unerwähnt sollte hier bleiben. so wird auf diesen reagiert und die Prozesse werden in Gang gesetzt. Fehler nicht nur einmal diese Prozesse durchlaufen. dass Probleme bzw. Fehler eintreten. Im Gegensatz dazu stehen die Requests for Change. erfolgt durch das Change Management im Error Control ein sogenannter Post Implementation Review. Dazu werden: • Problemfelder und Fehlerquellen analysiert. auf Reize reagierend . Wird nämlich zur Behebung des bekannten Fehlers eine Änderung einer Komponente des IT-Bereiches benötigt. da diese aber sehr ähnlich zu der des Unknown Errors ist. Hier wird eine Art Voruntersuchung auf zukünftige Problems und Incidents betrieben. Fehler Beschluss: In diesem Schritt wird nun eine der erarbeiteten Lösungsmöglickeiten zur Beseitigung des bekannten Fehlers ausgewählt. Daher sollte ein Problem resp. einen Antrag auf Änderung. ob die gesamte Historie des Problems tatsächlich erfasst und dokumentiert wurde. sondern muss ein RfC. Proactive Problem Management. Die beiden gerade vorgestellten Aufgabenbereich bzw. Ist dies nicht der Fall. neu bewertet werden.

Wer die Änderungen. Auch wenn das vorangegangene Beispiel recht einfach war. die vom Problem Management zur Beseitigung bzw. besteht die Aufgabe des Change Managements darin. Kommunikationsgeräte. an das Change Management übermittelt werden. wird nun im nächsten Kapitel behandelt. den sogennanten Configuration Items (CIs)20 . immer wieder abzustürzen.6 zu finden.Service Support-Umsetzung an zwei ausgewählten Fakultäten Sind diese Fragen beantwortet.2. die an das Problem Management und seinen Mitarbeitern gestellt wird.19 Ein Beispiel für die beiden Aktivitäten könnte folgendermaßen sein. werden: 27 • Präventivmassnahmen zur Vermeidung von Incidents und Problems vorbereitet. sondern auch diese vorhergesehen und im Voraus vermieden werden sollen. im Endeffekt kontrolliert und steuert.2.4 Change Management Das Change Management befasst sich mit der Kontrolle und Steuerung aller Änderungen (Changes) innerhalb der IT-Infrastruktur. Vermeidung von Problemen erarbeitet und vorgeschlagen werden. 20 Eine genauere Erklärung eines CIs ist im Abschnitt 1. dass es durch eine höhere Anzahl an Kunden zu mehr Datensätzen auf dem Computer kommt und dieser daher Gefahr läuft. da er mit der großen Datenmenge nicht mehr einwandfrei arbeiten kann. 1. Durch einen wirtschaftlichen Boom würde es nun zu einem rasanten Anstieg der Kundenzahl kommen. Als zweiten Schritt muss das Proaktive Problem Management eine Präventivmassnahme zur Vermeidung dieses Problems durchführen. Da die IT-Komponenten häufig Änderungen unterworfen sind. Bevor eine Änderung durchgeführt werden kann. eine ausreichende Anzahl an Programmen usw. Anwendungs. Es müssen zuvor Kosten-Nutzen Rechnungen durchgeführt werden. Dokumente sowie Prozeduren beziehen. Es muss nicht nur ein hohes Fachwissen sondern auch eine Wissensdatenbank. um zu sehen. Es muss erkennen. die die Problemfelder und Fehlerquellen beseitigen sollen. ausführliche Dokumentationen vorangegangener Probleme. ein sogenannter Request for Change (RfC). Angenommen. dass das Problem Management die Präventivmassnahmen nicht einfach durchführen darf. Eine Möglichkeit wäre der Kauf eines weiteren Computers. so zeigt es aber die hohe Anforderung. dass im Problem Management nicht nur auf Problems reagiert. Darüber hinaus darf nur das Change Management autorisierte Änderungen durchführen.und Systemsoftware. Die Änderung kann sich auf die Bereiche der Hardware-Komponenten. Daher werden hier Möglichkeiten erörtert und ausgearbeitet. Diese Datensätze würden neben der Anschrift auch den Briefwechsel mit besagtem Kunden enthalten. . In diesem Augenblick ist das Problem Management gefragt. standardisierte Methoden und Verfahren zur Abwicklung und Überwachung von Änderungen zu entwickeln. ob sich der eingesetzte Aufwand zur Vermeidung von Problemen überhaupt lohnt. muss ein Änderungsantrag. Im Grunde wird jede beabsichtigte Änderung an Komponenten der IT-Infrastruktur. eine Firma würde die Daten ihrer Kunden auf einem einzigen Computer speichern. Es soll somit eine ordnungsmäßige Implementierung der Änderung in die IT-Infrastruktur sichergestellt werden und mögliche Störungsrisiken minimiert werden. Des Weiteren wurde gezeigt. 19 Allerdings ist hier anzumerken. vorhanden sein.

ob ein RfC akzeptiert oder abgelehnt wird. Am Ende der Durchführung sollen nach den ITILEmpfehlungen die nachfolgenden Fragen ([TRA07. wird die Priorität und Kategorie des RfC eingestuft. Während der gesamten Durchführungsphase wird jeder einzelne Schritt eines RfC protokolliert und an die Configuration Management Database (CMDB) 23 übermittelt. muss dies dem Change Management übermittelt werden.2. • Planung und Organisation der Durchführung eines RfC. Vorteilhaft ist die elektronische Übermittelung mit Hilfe von standardisierten Anträgen. ob eine Änderungen wirklich durchgeführt werden soll. die mit darüber entscheidet. wie die Festplatte. Jeder RfC bekommt eine eindeutige Identifikationsnummer zugewiesen und wird dokumentiert. • 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. 53]) beantwortet werden können. Handelt es sich um einen RfC mit geringer Priorität. • kontinuierliche Überwachung und Kontrolle bei der Durchführung eines RfC. damit eine Änderung durchgeführt werden kann. der Monitor oder sogar der Server.6 zu finden. können Service Tools eingesetzt werden. die das Change Management bzw. Ein RfC kann von allen Benutzern der IT versendet werden. Hardware. der Change Manager erfüllen muss. Ist zum Beispiel eine Hardware-Komponente defekt. dem Risiko einer Änderung.22 Der Change Manager entscheidet in einer Vorauswahl. Software und finanzielle Mittel. Zu den weiteren Aufgaben. Des Weiteren müssen Ressourcen für Änderungen bereitgestellt werden. 22 Hierbei . welche Änderungen zuerst durchgeführt werden sollen. Test und Implementierung der Veränderung? Ist eine grobe Vorauswahl für die Ausführung einer Änderung getroffen. Hierzu gehört auch eine Kosten/Nutzen-Rechnung. Die Einstufung erfolgt nach der Dringlichkeit oder dem Ausmaß bzw. Zu den Ressourcen gehören unter anderem Personal. wie zum Beispiel eine Änderung der Zugriffsrechte eines Users oder andere routinemäßigen Aufgaben. Darüber hinaus muss das Change Management entscheiden.28 ITIL-Wirklichkeit an der Universität Bielefeld mit einem RfC an das Change Management übermittelt. so 21 PIR steht für Post Implementation Review. gehören folgende Punkte: • Erfassung und Filterung von RfCs. S. Dadurch lässt sich jede Änderung leicht nachvollziehen. So hat die Reparatur eines Servers eine höhere Priorität als ein defekter Monitor. Ähnlichen RfCs können auch zusammengefasst werden. • abschließende Revision (PIR)21 . 23 Eine genauere Erklärung einer CMDB ist im Abschnitt 1.

Bei größeren Änderungen sollte auch der jeweilige betroffene Personenkreis mit in die Entscheidung einbezogen werden. dass es ein großer Aufwand für den Anwender ist. Nach der Implementierung sollte nach einiger Zeit eine abschließende Revision (PIR) zur Qualitätssicherung erfolgen. wie zum Beispiel die Umstellung des Betriebssystems bei sämtlichen Computern von Windows XP auf Windows Vista.7 zeigt die einzelnen Schritte. ist es . Das CAB ist zuständig für Änderungen mit mittlerer und hoher Priorität und Kategorie. Nach einer Testphase. Je nach Dringlichkeit werden die RfC geordnet und die benötigten Ressourcen bereitgestellt. inwieweit die eingeplanten Ressourcen ausreichend waren. Dies sollte zu einem Zeitpunkt geschehen. dass das IT-System nicht mehr konsistent ist und das System dadurch nicht mehr fehlerfrei arbeitet. sein und sollten regelmäßig in Kontakt zueinander stehen. die bei zukünftigen ähnlichen Änderungen korrigiert werden können. Ist es hingegen eine Priorität und Kategorie höherer Stufe. Diese können sowohl aus dem Bereich des Incident Managements. Hierzu gehört beispielsweise der Ausfall des gesamten Netzwerkes. Die Abbildung 1. Bei dieser Art von RfC sind meistens nur ein oder wenige User betroffen und es ist kein großer Ressourcenaufwand nötig. die ein RfC durchläuft. das für die tatsächliche technische Umsetzung der Änderung zuständig ist. Problem Managements. jede Änderung eines CI erst durch das Change Management genehmigen zulassen. Wurde der RfC genehmigt. um den Change planmäßig durchzuführen. Das ECAB besteht aus wenigen Mitgliedern des CABs. erfolgt die abschließende Implementierung der Änderungen. für die Durchführung der Änderungen zuständigen Bereiche kontaktiert. dass nur mit hohen Aufwand an Ressourcen zu lösen ist. Im nächsten Schritt werden die für die Umsetzung bzw. dass die bereitgestellten Ressourcen ausreichend sind. Es muss darauf geachtet werden. Denn oftmals lassen sich die Änderungen schnell von dem Anwender selbst durchführen. Dies geschieht in enger Zusammenarbeit mit dem Release Management. ob die Ziele der Änderung erreicht wurden oder ob unerwünschte Nebeneffekte aufgetreten sind. so dass sichergestellt ist. Aber es wird auch überprüft. etc. Doch es kann dann passieren. Service Desks. Das CAB setzt sich aus mehreren Mitgliedern zusammen. bei dem möglichst wenige andere Prozesse beeinträchtigt werden. usw. Es wird dabei festgestellt. kommen als auch IT-Experten. Dieses Problem betrifft meist alle User und muss sehr schnell behoben werden. Die Hauptaufgabe des Change Managements besteht nun aus der formalen Koordination und Überwachung der Änderungen.Service Support-Umsetzung an zwei ausgewählten Fakultäten 29 obliegt die Entscheidung der Durchführung allein bei dem Configuration Manager. die stellvertretend für die restlichen Mitglieder schnelle Entscheidungen treffen können. dass die Änderungen ordnungsgemäß funktionieren. Auf den ersten Blick erscheint es. liegt ein dringendes Problem vor. Anhand des vorgestellten Schemas sollten sämtliche RfC abgewickelt werden. Denn nur durch diesen standardisierten Ablauf können Änderungen effizient durchgeführt und Fehlerquellen minimiert werden. Meist sind hier mehrere User von den Änderungen betroffen und ein höherer Aufwand an Ressourcen ist nötig. dass sich der User über den genauen Bearbeitungsstand des RfC informieren kann. Um dies zu vermeiden. beginnt die zeitliche Planung der Änderung. Die Informationen werden an die CMDB übermittelt. Wird das ECAB einberufen. wird das sogenannte Change Advisory Board (CAB) oder in einigen Fälle sogar das Emergency CAB (ECAB) einberufen. in der sichergestellt werden soll. Mit Hilfe dieser abschließenden Revision lassen sich mögliche Schwachstellen aufdecken.

Es lässt sich somit festhalten. das im folgenden Abschnitt näher erläutert wird. Zu den Hauptaufgaben des Release Managements gehören: .30 ITIL-Wirklichkeit an der Universität Bielefeld RFC Change Manager • RFC filtern • Priorität festlegen ablehnen gering mittel hoch dringend Change Manager CAB/ ECAB Configuration Management (CMDB) nein genehmigt ? ja Change planen & durchführen Release Management abschließende Revision nein Erfolg ? ja Ende Abbildung 1. Des Weiteren entwickelt das Release Management qualitätssichernde Richtlinien und Grundkonfigurationen zur Installation von IT-Systemen. einen RfC an das Change Management zu übermitteln.5 Release Management Das Release Management ist für die Bereitstellung. Um die Systemintegrität der genehmigten Änderungen sicherzustellen. 1. dass neue oder veränderte CIs voll funktionsfähig in die IT-Umgebung implementiert werden.2. wichtig. dass das Release Management maßgeblich die Verantwortung dafür trägt.7: RfC-Ablauf. arbeitet das Change Management eng mit dem Release Management zusammen. Einführung und Verwaltung von autorisierter Software und Hardware zuständig. Während das Change Management für die Entwicklung von standardisierten Methoden und Verfahren zur Durchführung und Überwachung von Änderungen verantwortlich ist. befasst sich das Release Management unter anderem mit der Sicherstellung der Systemintegrität der Änderungen.

Versionierung und Speicherung von genehmigten Releases. die die Releases auf die relevanten Computer verteilt. dass die Releases fehlerfrei in das IT-System implementiert werden. Test. In diesem Zusammenhang lassen sich drei verschiedene Release-Arten nach ihrem Umfang unterscheiden: Full Release: Alle Software. Die Informationen. werden in der CMDB gespeichert. Soll ein bereits implementierter Release wieder entfernt werden. Auf Grund der hohen Kosten einer Vorratshaltung sollten nur kritische Komponenten als Ersatz gelagert werden. Wie aus ihr ersichtlich wird. Dadurch wird sichergestellt. verwaltet das Release Management die Definitive Software Library (DSL). Verwaltung.Service Support-Umsetzung an zwei ausgewählten Fakultäten • Festlegung der Release Policy. als Release bezeichnet.und Hardwarekomponenten werden zusammen entwickelt. Delta Release: Es sind nur Komponenten enthalten. Einführungen von Software und Hardware. beginnen die Planungen . sind die Aufgabenbereiche des Release Managements in die Entwicklungs-. Repository kann auf eine lauffähige Sofwareversion zurückgegriffen werden. Mit Hilfe des Backup-Systems bzw. dass bei einem fehlerhaften Release immer auf eine lauffähige Version einer Software zurückgegriffen werden kann. untersteht aber der Kontrolle des Release Managements. dass von dem Release Management veröffentlicht wird. getestet und verteilt. Mit Hilfe von Abbildung 1. Wird ein autorisierter RfC an das Release Management übermittelt. Darüber hinaus werden in der DSL auch die Softwarelizenzen verwaltet.8 soll auf die wichtigsten Aufgaben des Release Managements eingegangen werden. Überwachung und Durchführung von Änderungen bzw. Es handelt sich dabei um ein Lager mit wichtigen Hardwarekomponenten.und Produktionsumgebung integriert. Um sicherzustellen. • Dokumentation. Hierbei können ähnliche Releases auch gebündelt und als Paket veröffentlicht werden. Die DSL ist in die CMDB des Configuration Managements implementiert. Dieses verwaltet auch den Definitive Hardware Store (DHS). • Planung. Es handelt sich dabei um eine Datenbank auf der sich sämtliche autorisierte Software befindet. Im Kontext der ITIL wird jedes neue oder veränderte CI. die seit dem letzten Release geändert worden sind. wird dies als Rollin beschrieben. Package Release: Full Releases und Delta Releases werden zu einem Paket gebündelt und veröffentlicht. Wie der allgemeine Vorgang eines Releases durchgeführt wird. an welcher Stelle die Ersatzteile gelagert sind. 31 • enge Zusammenarbeit und inhaltliche Abstimmung mit dem Change Management. hängt von der Release Policy ab. Die Release Policy bestimmt die Richtlinien für die Bearbeitung und Dokumentation eines Release und ist als Leitfaden für die weitere Bearbeitung zu verstehen. Die Implementierung von Releases werden als Rollout bezeichnet. Hilfreich hierbei ist eine zentrale Softwareverteilung.

Dadurch lassen sich die Änderungen und deren Auswirkungen nachvollziehen und gegebenenfalls korrigieren. Wichtig hierbei ist. sollten die betroffenen User über die Änderungen unterrichtet werden. Im letzten Schritt erfolgt die endgültige Verteilung und Implementation des Release. Die weiteren Aufgaben des Configuration Managements werden im folgenden Abschnitt erläutert. muss sichergestellt sein. Dieser Schritt umfasst die Terminplanung und Koordination der Implemetierung des Release in die Produktionsumgebung.6 Configuration Management Das Configuration Management stellt eine wichtige Komponente im Bereich der Service Support-Prozesse dar. Anschließend sollte der Release in eine realitätsnahe Testumgebung implementiert werden. beginnen die Planungen für den Rollout. für die Änderungen. Sämtliche Schritte werden dokumentiert und dem Configuration Management übermittelt.8: Release Management. muss jede Veränderung der IT-Infrastruktur . Um dies zu gewährleisten. Notfallpläne usw. Aufgabe des Configuration Managements ist es. 1. dass sich eine lauffähige Version der Software auf der DSL befindet. den anderen ITIL-Prozessen Informationen über die IT-Infrastruktur bereitzustellen. So müssen Releaseinhalte. Wenn der Release die Anforderungen erfüllt. festgelegt werden. Somit fungiert das Configuration Management unter anderem als Datenbank. dass sich die Informationen auf dem aktuellsten Stand befinden. Im nächsten Schritt wird der Release entwickelt. Bevor der Release veröffentlicht wird.2. Dies geschieht in enger Zusammenarbeit mit dem Change Management.32 ITIL-Wirklichkeit an der Universität Bielefeld Entwicklungsumgebung Testumgebung Produktionsumgebung Release Management Release Politik Planung Entwicklung/ Bestellung Erstellung/ Konfiguration Testphase/ Akzeptanz Rolloutplanung Information/ Training Installation Configuration Management CMDB DSL Informationen über den DHS Abbildung 1. um eine schnelle Umsetzung zu gewährleisten. benötigten Ressourcen. Prioritäten. um die Systemintegrität zu überprüfen. Handelt es sich bei dem Release um eine Softwareänderung.

bezeichnet man als Configuration Item (CI).. die ebenfalls einzelne CIs sind. wie es bei einer Bestandsdatenbank der Fall ist.und Fehlerbehebungs-Beschreibungen. Attribute gespeichert werden. gespeichert und verwaltet.24 Anhand der Abbildung 1. Auf Grund dieser vielfältigen Verflechtungen ist es wichtig. sondern ebenfalls deren Verflechtungen zueinander widerspiegelt. . Incident Management Change Management Configuration Management Problem Management Release Management Informationsfluss Abbildung 1. dass bei einer Störung oder bei einem Ausfall eines CIs genau nachvollzogen werden kann. Netzwerkkarte. Installationsanleitungen. der sogenannten Configuration Management Database (CMDB). aus einer Festplatte. So besteht ein Computer.9: Informationsfluss Configuration Management und Service Support Prozesse. Des Weiteren müssen zu jedem CI die wichtigsten Eigenschaften resp. welche Komponenten mitbetroffen sind. Alle Komponenten. die in der IT-Infrastruktur von dem Configuration Management erfasst werden. dass sie nicht bloß die einzelnen CIs speichert. um einen Überblick über alle CIs sicherzustellen. Zu den Veränderungen zählen neben Modifikationen an Komponenten der Hardware und Software auch Änderungen an Dokumenten. Da auch Änderungen. Ein Vorteil dieses Aufbaus der CMDB ist. Der Computer ist natürlich auch nur ein Bestandteil eines höher geordneten CIs. usw. das Release Management an das Configuration Management übermittelt werden.9 wird die zentrale Bedeutung des Configuration Managements und die wechselseitige Beziehung zu den anderen ITIL Support Prozessen verdeutlicht. Ein CI setzt sich oft aus mehreren CIs zusammen. Die CIs werden in einer zentralen Datenbank. der auch ein CI ist. Die Besonderheit bei der CMDB ist. Software usw.Service Support-Umsetzung an zwei ausgewählten Fakultäten 33 durch das Change Management bzw. CD-Rom.. In24 Zu den Dokumenten zählen zum Beispiel Problem. jedem CI eine eindeutige Identifikationsnummer zuzuteilen.

die die Arbeit mit den Datenbanken erleichtern sollen. ist eine effiziente Fehlerbehebung möglich.34 ITIL-Wirklichkeit an der Universität Bielefeld cidents. von der Rolle des Configuration Managers erfüllt werden: Aufbau und Planung des Configuration Managements: Pläne und Prozeduren für sämtliche Aktivitäten des Configuration Managements müssen festgelegt werden. auf der CMDB gespeichert. dass die CMDB ein zentraler Punkt hoher Komplexität ist. müssen folgende Aufgaben von dem Configuration Management bzw.10: CI-Verflechtung in der CMDB. Abschnitt 1. Abbildung 1. . Abbildung 3.6 zeigt eine vereinfachte Darstellung der Struktur der CIs und deren Eigenschaften. Known Errors und Releases und deren Beziehungen als CIs gespeichert sind. Um diese Arbeit zu bewältigen.5. Darüber hinaus sind die Informationen über den Definitive Hardware Store (DHS). Da im Zeitablauf der Arbeitsauf25 Zur Erklärung vgl. Zusätzlich ist innerhalb der CMDB die Definitive Software Library (DSL) 25 implementiert. Dieser Punkt umfasst unter anderem auch die Definition der CIs und eine einheitliche Namenskonvention der CIs. CMDB Hardware Software Dokumentation CI ComputerID:1234 Prozessor : Intel Core 2 GH HD : 60 GB Software : MS Vista MS Office Monitor : LCD usw. Des Weiteren muss der Umfang und die Struktur der CMDB festgesetzt werden. Problems. die von dem Release Management verwaltet werden. dadurch soll ein konsistenter Zustand der Datenbanken sichergestellt werden.2. zum Beispiel die Festlegung der Speicherkapazitäten der CMDB und der DSL. Um ein effizientes Arbeiten zu ermöglichen. müssen auch geeignete Configuration Management-Tools implementiert werden. Aus diesem Zusammenhang wird ersichtlich.

Auch hier findet ein Austausch von Daten statt. So stellt die CMDB dem Problem Management wichtige Informationen über die Verflechtung der betroffenen CIs und weitere relevante Daten zur Verfügung. Verifizierung und Audits: Damit die Aktualität der CMDB sichergestellt ist. wird der Vorfall an das Problem Management weitergereicht. Statusinformationen über die CIs: Über den gesamten Einsatzzeitraum eines CIs werden Berichte mit allen relevanten Informationen und dem aktuellen Zustand angefertigt. In enger Zusammenarbeit mit dem Release Management werden die notwendigen Änderungen durchgeführt und an die CMDB übermittelt. ob die gespeicherten Daten der CIs die aktuellen Daten der CIs widerspiegeln. stellt die CMDB diese bereit. usw. Es eignen sich verschiedene Vorgehensweisen für die Einführung . um eine schnelle Lösung zu gewährleisten. Mit Hilfe des Configuration Managements und den dazugehörigen Komponenten sollte es möglich sein. dass sich nur autorisierte und aktuelle Einträge über die CIs in der CMDB befinden. Sollte dies nicht mehr der Fall sein. Kontrolle der CIs: Das Configuraion Management sorgt dafür.Service Support-Umsetzung an zwei ausgewählten Fakultäten 35 wand wächst.2..6 zeigt die Aufgabenbereiche und die Schnittstellen des Configuration Managements mit den anderen Service Support-Prozessen anhand eines Incidents. usw. wird dies der CMDB übermittelt. sollte durch einen regelmäßigen Soll/Ist-Abgleich sichergestellt sein. Zu den möglichen CIs gehören beispielsweise die Hardware. Lizenz-Kontrollen. die Effizienz und die Effektivität der IT-Organisation zu steigern. Audit wird festgestellt. müssen die gespeicherten Daten in regelmäßigen Abständen überprüft werden. die Aktualisierung bestehender CIs.. Maus. Wird das Problem erkannt und zu einem Known Error. Um das Problem zu lösen. wird ein RfC mit Hilfe des Change Managements und Release Managements durchgeführt. Je nach Maß der Differenzierung muss die IT-Infrastruktur in ihre Bestandteile zerlegt werden und sämtliche CIs erfasst werden. Um dieses zu gewährleisten. Kontrolle der DSL. Bei dieser Verifizierung bzw. Falls es sich um einen bekannten Fehler handelt und dazu Lösungskonzepte oder andere Details existieren. Fehlerbehebungs-Beschreibungen. gehört dazu die Registrierung neuer CIs. Tastatur und Monitor ein einzelnes CI darstellen oder sollen die Bestandteile auch als CIs definiert sein? Diesen Fragen werden zuvor bei dem Aufbau und der Planung des Configuration Managements geklärt. Auf diese Weise können die anderen Service Support-Prozesse immer auf aktuelle Informationen zurückgreifen. Soll zum Beispiel ein PC inkl. Dokumentationen der Systemkonfiguration. dass die zur Verfügung gestellten Ressourcen ausreichend sind. So ist der Aufwand abhängig von der Definition der CIs. Software. wird ein RfC an das Change Management weitergeleitet. Abbildung 1. RfC. Identifikation der CIs: Eine wesentliche Komponente bei der Identifizierung der CIs ist das Maß der Differenzierung der IT-Infrastruktur. Wird nur eine temporäre oder keine Lösung erreicht. Dokumentationen über Änderungen und Abweichungen. Bei der Registrierung eines Incidents sendet das Incident Management die Daten zu der CMDB.

56] eines Configuration Managements. Natürlich ist eine schrittweise Einführung möglich. DHS) Configuration Management Request for Change Autorisierter Change Change und Release Management Change ausgeführt Ende Abbildung 1. Das Ziel soll es sein. Von Vorteil ist es.11: Schnittstelle zwischen CM und andere Service Support Prozesse. Service Supports an der Universität Bielefeld anhand der Fakultät für Wirtschaftswissenschaften und der Fakultät für Rechtswissenschaft. mit Hilfe des in Kapitel 2 vorgestellten idealtypischen Verlaufes des ITIL Service Supports die Möglichkeit der Implementierung eines ITIL konformen Service Supports an der Universität Bielefeld darzustellen. Ein Hinderungsgrund für einen reibungslosen Ablauf des Prozesses ist oft die fehlende Akzeptanz der Mitarbeiter. um eine aktuelle CMDB und die damit verbundenen Vorteile zu garantieren. Quelle: Eigene Darstellung in Anlehnung an [Vic05. Es ist aber eine Notwendigkeit. die Vorraussetzung dafür ist aber eine genaue IST-Analyse der IT-Infrastruktur. wenn von Anfang an eine ITIL konforme Implementierung erfolgt. . denn dadurch verringert sich der Arbeitsaufwand. oftmals erscheint ihnen dies als zu bürokratisch.36 ITIL-Wirklichkeit an der Universität Bielefeld Service Desk Incident Management Start Incident Problem Problem Management Known Error C M D B (inkl. Im nächsten Kapitel erfolgt eine Untersuchung des aktuellen IT-Managements bzw. Sie müssen jede Veränderung der IT an das Configuration Management weitergeben. DSL und Info. S.

Es wird sowohl die Fakultät für Wirtschaftswissenschaften als auch die Fakultät für Rechtswissenschaft betrachtet. die von mehreren Personen genutzt werden. Die Fakultät für Wirtschaftswissenschaften betreibt ihre lokalen Netzwerke mit minimalem Personalaufwand.Service Support-Umsetzung an zwei ausgewählten Fakultäten 37 1.3. es gibt sowohl Bürodrucker. deshalb haben Netzwerkdrucker auch eine hohe . Wie im Kapitel 1. Wenn möglich. 1. Außerdem kann es von den persönlichen Vorlieben des Mitarbeiters abhängen. Der Fragenkatalog wurde in die einzelnen Prozesse bezüglich des Service Supports gegliedert.2.3 Untersuchung des IT-Managements in der Universität Bielefeld In diesem Kapitel soll der Service Support anhand von zwei ausgewählten Fakultäten untersucht werden. Auf Grund der geringen Anzahl an Mitarbeitern kann jedoch nicht zwischen First Level Support oder Second Level Support unterschieden werden. Dementsprechend kann auch nicht von den unterschiedlichen „Rollen“ der einzelnen Prozesse gesprochen werden. wer den Vorfall meldet. zum anderen teilen sie ihnen telefonisch oder auch per eMail den Vorfall mit. Die wesentlichen Aufgaben sind die Sicherstellung des reibungslosen Betriebs zentraler Komponenten (Server) und die Pflege der Infrastruktur (Hardware). Grundsätzlich kann man die IT der beiden Fakultäten nicht in die Funktion des Service Desks und die einzelnen Prozesse einteilen. Auf Grund der Nutzung von mehreren Personen genießen die Netzwerkdrucker einen wesentlich höheren Support als die Bürodrucker. Problems und Request for Changes bezüglich der Hardware und Software. Zu diesem Zweck haben wir mit den System-Administratoren der jeweiligen Fakultät Gespräche geführt. als auch Netzwerkdrucker. zum einen kommen die User persönlich bei ihnen im Büro vorbei. dennoch wird dies hier versucht. Auch die Administratoren der Fakultät für Wirtschaftswissenschaften sind die einzigen Ansprechpartner für sämtliche Incidents. Dieses kann am Beispiel „Drucker“ betrachtet werden. sollten die Probleme und Fehler mit möglichst genauer Beschreibung per eMail an die Systembetreuer gesendet werden. Incident Management. Service Desk. Bei Meldung eines Incidents sollte prinzipiell kein Unterschied gemacht werden. Es sind in der Fakultät zwei unterschiedliche Kategorien an Druckern vorhanden. die lokal an einem Computer angeschlossen sind. da die Aufgaben und Zuständigkeiten der einzelnen Mitarbeiter nicht klar abgegrenzt sind. Die Kontaktaufnahme mit den Administratoren erfolgt über verschiedene Weisen. zumindest sollten sie dies sein. Dennoch muss im Nachhinein differenziert werden. welchen Status der User innerhalb der Fakultät innehat.1 beschrieben wird.1 Fakultät für Wirtschaftswissenschaften Zuerst wird der Aufbau der IT in der Fakultät für Wirtschaftswissenschaften beschrieben. soll der Service Desk nach ITIL als ein „Single Point of Contact“ für die Kommunikation mit dem Endanwender verantwortlich sein. Dies kann auch in mehrfacher Form geschehen.

38

ITIL-Wirklichkeit an der Universität Bielefeld

Priorität. Generell kann also gesagt werden, dass Vorfälle genau dann eine höhere Priorität haben, wenn mehrere User davon betroffen sind, als wenn nur ein einzelner von dem Incident betroffen ist. Die Priorität kann in drei unterschiedliche Kategorien eingeteilt werden, Incidents können hoch, mittel oder niedrig eingestuft werden. Grundsätzlich werden die meisten Vorfälle bei Auftreten oder bei Meldung erstmal hoch eingestuft. Nach einer kurzen Beschäftigung mit dem Incident wird der Vorfall eventuell neu priorisiert, da bemerkt wird, dass dieser für den Moment nicht so wichtig ist. Wartet man zum Beispiel auf die Lieferung eines Ersatzteils, so stellt man den Incident zurück und behaftet ihn mit einer Information, dass auf den Lieferungeingang gewartet wird. Zu den einzelnen Incidents werden unterschiedliche Informationen abgespeichert, nicht nur Informationen zu dem User und dessen Computer, sondern auch zum Beispiel der letzte Bearbeiter. Auf Nachfrage bekommen die User, die ein Incident vorliegen haben, eine Übersicht über den Stand der Dinge. Auch bei Bestellungen wird der User darüber informiert, dass zum Beispiel die Bestellung aufgegeben wurde und wann mit einer Lieferung zu rechnen ist. Jedoch reagieren oftmals die Kunden ganz unterschiedlich, die einen möchten auf dem Laufenden gehalten, den anderen reicht die Meldung, dass sich darum gekümmert wird. Problem Management. Nach ITIL wird zwischen „Incident“ und „Problem“ unterschieden, ein Problem ist schwerwiegender als ein Incident. Bei den Administratoren der Fakultät für Wirtschaftswissenschaften gibt es eine solche Unterscheidung nicht. Auf den Computern in der Fakultät wird StandardSoftware installiert. Dennoch möchten manche User eine spezielle Software auf ihren Computern haben, treten bei diesen dann Fehler auf, so ist der Supportlevel von den Administratoren sehr gering. Es wird bei Anschaffung darauf hingewiesen, dass bei eventuellen Problemen mit der Software keine Unterstützung durch die Administratoren gewährleistet werden kann. Tritt ein Fehler oder ein Problem bei einer Standard-Software, verfügen sie über eine selbst angeeigneten Wissensbasis. Dennoch kann man auch Hilfe im Internet oder in verschiedenen Administratoren-Foren finden, da die Standard-Software oftmals eine sehr verbreitete Software ist. Ist trotzdem zu einem gewissen Zeitpunkt der Support nicht mehr möglich, so wird der Hersteller der Hardware oder Software kontaktiert. Dies kommt jedoch in den seltensten Fällen vor. Um Fehler oder Probleme an der Software im Voraus zu verhindern, wird, sobald sich Software in einer neuen Version auf dem Markt befindet, diese getestet und überprüft. Damit die Schadensbegrenzung so gering wie möglich zu halten, wird eine Empfehlung zur Nichtnutzung der bestimmten Software ausgesprochen. Change Management. In Bezug auf finanzielle Mittel sind alle Lehrstühle der Fakultät für Wirtschaftswissenschaften selbst verwaltet, also alle haben ein eigenes Budget, das ihnen frei zur Verfügung steht. Dieses wird von der Fakultätsverwaltung verwaltet, jedoch hat die Fakultätsverwaltung kein technisches Know-How bezüglich der Software oder Hardware. Aus diesem Grund können die Administratoren nur leiten und beratend eingreifen, was die Beschaffungen betrifft, haben aber keinen direkten Einfluss darauf. Sie haben nicht die Möglichkeit, zum Beispiel „unvernünftige “ Beschaffungen, die von den Lehrstühlen

Service Support-Umsetzung an zwei ausgewählten Fakultäten

39

gewünscht werden, zu verhindern. Auch bezüglich der Hardware besteht ein Standard, der eingehalten werden soll. Da man sich bereits Kenntnisse über die standardisierte Hardware angeeignet hat, kann so Zeit eingespart werden, die man unnötig vergeuden würde, wenn man sich ständig mit unterschiedlicher Hardware auseinandersetzen müsste. An erster Stelle steht das HRZ, das Empfehlungen bezüglich der Hardware oder Software herausgibt. Bevor die Software den Usern angeboten wird, wird die Lauffähigkeit im universitären Umfeld getestet, wie sie im universitären Umfeld läuft, vor allem mit dem Server. Die PC-Nutzer verfügen in der Regel keine Administratoren-Rechte, sie haben nur Hauptbenutzer-Rechte. Release Management. Die Administratoren sind sowohl für Beschaffung, Installation, Wartung und Entsorgung Hardware als auch für Beschaffung, Installation und Pflege von System- und Anwendungssoftware zuständig. Sie können Hardware oder Software kostengünstig beschaffen, außerdem können die Beschaffungen dann auch gebündelt werden. die Administratoren können beratend eingreifen, da innerhalb der Fakultät bezüglich Hardware und Software gewisse Standards eingehalten werden sollen. Die Computer-Arbeitsplätze werden für die Benutzer funktionsfähig eingerichtet. Die Erstinstallation umfasst das HRZ-Basic-Bundle. Im Hochschulrechenzentrum (HRZ) wird ein Software-Bundle bereit gestellt, das es in zwei unterschiedlichen Ausführungen gibt. Dies ist zum einen das Basic-Bundle und zum anderen das Classic-Bundle, das das Basic-Bundle beinhaltet. Die Konfiguration, die Implementierung und die Beratung der HRZ PC-Services in der Fakultät sollte durch die Administratoren mit beratender Unterstützung durch das HRZ geschehen. Die Software wird ausschließlich von den Administratoren beschafft und installiert. Sonstige Software aus dem Classic-Bundle und weitere Installationen, die nicht aus dem Bundle stammen, werden per Antrag auf Kosten des betreffenden Lehrstuhls beschafft. Bei gekaufter Software ist der Lizenznehmer immer die Fakultät, die Kopien und die Originalen werden bei den Administratoren aufbewahrt. Sie sind also Ansprechpartner für Softwareangelegenheiten, außer es wird spezielle Software genutzt, die zum Beispiel aus dem HRZ-ClassicBundle kommt. Bei einem Backup-System oder einer Repository muss man zwischen ProgrammDateien und User-Dateien unterscheiden. Jeder Benutzer sollte aus Sicherheitsgründen seine eigenen User-Dateien auf der persönlichen Home Directory speichern, da sich dieses Laufwerk auf den Servern des HRZ befindet und täglich gesichert wird. Außerdem befinden sich mehrere Versionen der User-Dateien auf den Servern. Bei Problemen in der Konfiguration, die durch fehlerhafte Programme ausgelöst werden, werden diese gelöscht und anschließend neu installiert. Es gibt also kein sogenanntes Lifecycle-Management. In der ITIL gibt es den sogenannten Definitive Hardware Store (DHS). Hierbei handelt es sich um ein Lager mit wichtigen Hardwarekomponenten. Aus Platzgründen wird Hardware nicht gelagert, sondern erst bei Bedarf beschafft, dann für den Einsatz vorbereitet und kommt dann zu dem Endnutzer. Es sind nur Standard-Sachen in geringer Anzahl vorhanden, wie zum Beispiel Tastaturen, Computer-Mäuse, Laufwerke etc. Da die Administratoren für die Netzwerkdru-

40

ITIL-Wirklichkeit an der Universität Bielefeld

cker zuständig sind, müssen sie sich auch um Toner für diese kümmern und ein paar auf Lager haben. Configuration Management. Die Computer, die für die Fakultät beschafft werden, werden zentral von der Universität verwaltet, deshalb werden sie einer sogenannten Inventarisierungsnummer zugeordnet. Dies wird mit jedem Rechner gehandhabt. Außerdem wird in der Universitätsverwaltung dokumentiert, wer den Rechner nutzt, wo dieser steht, etc.. Auch die Administratoren haben eine solche Datenbank, in der neben den bereits oben erwähnten alle sonstigen Informationen bezüglich der Hardware und Software gespeichert werden.

1.3.2

Fakultät für Rechtswissenschaft

Die Fakultät für Rechtswissenschaft hat eine ähnliche IT wie die Fakultät für die Wirtschaftswissenschaften. Jedoch ist sie nicht an die Active Directory des HRZ angeschlossen, sondern sie betreibt ihre eigene Domäne26 . Service Desk. Auch in der Fakultät für Rechtswissenschaften existiert teilweise ein Service Desk. Die EDV ist täglich von zwei Personen besetzt, eine Vollzeitkraft und eine studentische Hilfskraft. Einer von beiden ist im Büro anzutreffen und arbeitet organisatorisch, der andere erledigt die Problembehandlung an den Lehrstühlen. Auch hier werden Incidents oder Requests for Change durch die übliche Art und Weise an die EDV-Betreuer herangetragen, sprich persönlich, durch einen Anruf oder per eMail. Es soll aber vornehmlich per eMail mit den EDV-Betreuern Kontakt aufgenommen werden. Eine Unterscheidung zwischen einem First Level Support und einem Second Level Support kann man an dieser Stelle auch nicht entdecken. Der Third Level Support sind Anfragen an den Hersteller der Software oder Hardware. Incident Management. Generell wird bei der Meldung eines Incidents keine Unterschiede gemacht, wer den Incident meldet, jedoch hängt es auch hier sehr von dem Status in der Fakultät ab. Ein Professor bzw. seine Sekretärin genießen klar Vorrang. Trotzdessen wird aber auch festzustellen versucht, wie sehr der Incident den Arbeitsfähigkeit der Person einschränkt, also wie hoch der Arbeitsausfall ist. Momentan läuft die Aufnahme eines Incidents größtenteils über eMail ab, sprich man schreibt den Kollegen und somit auch sich selbst eine eMail, in der dann nähere Details zu dem Incident stehen und was gemacht werden soll. Nach Abhandlung des Incidents wird die dazugehörige eMail in einen anderen Ordner geschoben. Es werden weder irgendwelche Daten erfasst noch wird dokumentiert, wie hoch der Zeitaufwand war, es gibt also weder den sogenannten Incident Record noch den Problem Record. Es soll aber ein Open Ticket Request System (OTRS) eingeführt werden, mit dem sich dann Probleme und Anfragen bearbeiten lassen. Außerdem existiert ein internes Wiki27 . Es dient nicht nur als
26 Eine Domäne ist ein Server zur zentralen Authentifizierung und Autorisierung von Computern und Benutzern in einem Rechnernetz. 27 Unter einem Wiki versteht man eine Sammlung von Webseiten, die nicht nur gelesen, sondern auch online verändert werden kann. Dabei kann auch auf frühere Versionen zurückgegriffen werden.

so wird sie zuerst auf die Computer eines Lehrstuhls ausgerollt. Zuerst wird mit dem DV-Beauftragten kommuniziert. Vorher kann festgelegt werden. Für die Installation von Software gibt es ein System zum Rollout der Software. Es wird versucht. Geld zu sparen. Es muss ein Beschaffungsauftrag gestellt werden. Wird sie als lauffähig identifiziert. in der jedoch nur Probleme.Service Support-Umsetzung an zwei ausgewählten Fakultäten 41 organisatorische sondern auch als technische Datenbank. Alles kann nicht streng dokumentiert werden. und ihre Problembehandlung eingetragen werden. Auch für die Fakultät für Rechtswissenschaft gibt es eine Standardsoftware-Installation. Extrawünsche werden mit einer Empfehlung der EDV an die Verwaltung weitergeleitet. es wird also nicht auf Vorrat gekauft. ob alle Lehrstühle oder nur bestimmte Lehrstühle die neue Software oder -version bekommen. Falls dann keinen Beschwerden kommen. Bei Hardwareproblemen lässt man einen Techniker des passenden Herstellers kommen. Die Benutzer haben keine Administratoren-Rechte. da es oft zu zeitintensiv ist. jedoch werden diese oft abgeblockt. Bis zu einem Betrag von 200 Euro kann alles sofort beschafft werden. Diese leitet es dann an die Zentrale Beschaffungsstelle der Universität. wird durch die Lehrkörperkonferenz abgehandelt. Keiner der Fakultätsmitarbeiter darf Software kaufen. Einmal die Woche findet eine EDV-Besprechung statt. Wird eine andere Software für die gleiche Aufgabe gewünscht. denn man wird angehalten. Es wird immer nur das bestellt. was momentan benötigt wird. Bei der Behandlung von Problemen an der Software dienen zum Beispiel Mailinglisten der Open Source Produkte als Hilfe. sie können daher auch keine Software installieren. So lassen sich Probleme an der Software schneller beheben. Release Management. damit es auch Akzeptanz findet. alles andere läuft über die Beschaffungsstelle der Fakultät. . dieser stellt dann das Vorhaben in der Lehrkörperkonferenz vor. denn dafür ist die EDV-Abteilung zuständig. in der dann auch Probleme besprochen werden und Lösungsvorschläge gemacht werden. manchmal wird auch Rücksprache mit dem HRZ getroffen. zumindest die gängige Software. bekommen auch die übrigen Lehrstühle die Software. Die Softwareeinführung. die häufiger auftreten. wird auch hier zentral verwaltet. Meistens wird die Software vor dem Rollout auf den Rechnern in der EDV getestet. Bei speziellen Wünschen bezüglich der Software wird die sich auf dem Markt befindliche Software gesichtet. So wird der Software-Pool auf dem aktuellsten Stand gehalten. Für eine Aufgabenstellung gibt es jeweils auch nur eine Standardsoftware. Das Geld. zum Beispiel die Einführung einer neuen WindowsVersion. Problem Management. den PC-Pool möglichst identisch zu halten. die in die Registry eingreift. Es muss von der ganzen Fakultät beschlossen. Hardware wird von der EDV beschafft. da jeder Computer an der Fakultät mit der gleichen Software ausgestattet ist. so dass dann eine als Standardsoftware definiert. es gibt eine Standard-PC-Ausstattung. der dann an das Dispatching des HRZ weitergeleitet wird. das den Lehrstühlen zur Verfügung steht. Change Management. Auch in diesem Fall spielt das Geld eine große Rolle. so muss man sich mit der Standardsoftware begnügen.

Das System zum Rollout der Software inventarisiert jeden Computer. ob unerlaubte Software. In einer Universität haben solche Faktoren in der Regel einen nicht so hohen Stellenwert. um die Vorteile der ITIL-Prozesse zu nutzen. einkaufen lassen hat. Arbeitsaufteilung notwendig. Einmal in der Nacht wird dann ein Backup gemacht. Denn daran wird die Problematik für die Einführung eines ITIL-konformen Service Supports an einer Universität verdeutlicht. ein sogenanntes „Roaming-UserProfile“ . Bei Eintreten dieses Falls wird der Benutzer darüber aufgeklärt und die Software umgehend entfernt. und das Anschaffungsdatum verwaltet. Wenn der Domäne-Server ausfällt. Alle drei Server werden durch ein MonitoringSystem bewacht. Bei Abmeldung des Benutzers vom System wird alles wieder zurück auf den Server geschrieben. Im Vordergrund bei der Implementierung von ITIL steht. Es kann also genau festgestellt werden. im Allgemeinen die Verbesserung des IT-Service Managements. Durch ein Suchfunktion in dem System wird manchmal geschaut. welche Software sich auf welchem Rechner befindet. auf den Rechnern vorhanden ist. steht die Arbeit in der gesamten Fakultät stillt. Im Allgemeinen gibt es keinen Überblick über alle Lizenzen. wie bereits schon erwähnt.2 dargelegt wurde. ihre eigene Domäne betreibt. die nicht automatisch in dem Inventarisierungsclient auftauchen. diese müssen nachträglich per Hand eingegeben werden. Man weiß also zum Beispiel auch.42 ITIL-Wirklichkeit an der Universität Bielefeld Da die Fakultät für Rechtswissenschaft. welcher Lehrstuhl welche Software-Lizenz eingekauft hat bzw. Neben dem Domäne-Server existieren noch zwei weitere Server. wie bereits erwähnt. Jeder Benutzer hat sein eigenes Benutzerprofil. ein Web-Server und ein Backup-Server. Es gibt aber dennoch Informationen. Dies ist in erster Linie für Unternehmen besonders im Hinblick auf Wirtschaftlichkeit von enormer Bedeutung. die die Universität verteilt. bereitgestellt werden.3. Entsprechend müssen dafür auch genügend Ressourcen in Form von Arbeitsplätzen. Die EDV-Betreuer werden per SMS und per eMail über den Ausfall eines Servers oder womöglich aller Server informiert. . wie zum Beispiel Instant Messenger. an welchem Rechner welcher Bildschirm angeschlossen ist. In dem vorhandenen Wiki kann nachvollzogen werden. er kann damit an jedem Computer in der Fakultät auf seine persönliche Benutzeroberfläche und seine Daten zurückgreifen. Insbesondere geht es dabei um die Verbesserung des Kundenservices und der effizienten Strukturierung der IT-Infrastruktur. Zu diesen Informationen gehören zum Beispiel der Standort des Rechners. finanziellen Mitteln etc. basiert der Service Support nach ITIL auf festgelegten Strukturen und Arbeitsabläufen. werden die Daten des Benutzers auf den Rechnern gespeichert. Configuration Management.3 Kritik und Empfehlung Bevor auf Kritik und Empfehlungen eingegangen wird. Wie in Kapitel 1. die in der Fakultät vorhanden sind. 1. Es ist somit ein hohes Maß an Standardisierung und eine exakte Rollenverteilung resp. außerdem wird die Inventarisierungsnummer. an welcher Netzwerkdose der Rechner angeschlossen ist. soll noch einmal der Grundgedanke von ITIL aufgezeigt werden.

Fehler einer Software der entsprechenden EDV-Abteilung gemeldet. dass die Implementierung eines ITIL-konformen Service Supports an der Universität Bielefeld sich als äußerst schwierig erweisen würde und nur mit einem großem Arbeits. Aber diese Struktur verhindert auch eine Zusammenarbeit zwischen den Fakultäten. Die Probleme. Im Folgendem werden aufbauend auf der Kritik mögliche Verbesserungsvorschläge nach ITIL-Empfehlungen dargestellt. In diesem Zusammen- . Es wird hierbei auf die Service Support-Funktion Service Desk bzw. um die entsprechende Lösung zu erarbeiten. Des Weiteren werden manche Punkte zusammengefasst. Anregungen etc. Wünschenswert wäre ein virtueller Service Desk. dies wird sich noch im Verlauf dieses Abschnittes zeigen. da man erst die Gründe des Fehlers suchen muss. die sinnvoll erscheinen. um die Kooperation der Fakultäten zu verbessern. Im einzelnen zeigt sich die Problematik für eine Einführung von ITIL-konformen Prozessen bereits bei der allgemeinen Zusammenarbeit der EDV-Abteilungen der einzelnen Fakultäten. Klassifizierung. seitens der User schnell reagiert werden kann. bei der Dringlichkeit und Auswirkung des Problems maßgebende Kriterien sind. Change Management. die verschiedenen Rollen resp. -Prozesse Incident Management. die mit diesem Sachverhalt zusammenhängen. Somit ist gewährleistet. werden im Verlauf dieses Abschnittes anhand der verschiedenen Prozessen des Service Supports näher erläutert.und Kostenaufwand zu realisieren wäre. Wünschenswert wäre eine ITIL-konforme Priorisierung. dass auf Probleme. Fragen. Dies lässt sich damit begründen. sondern nur solche. Vielmehr erfolgt die Klassifizierung häufig anhand personenbezogenen Gründen. Ein weiterer wichtiger Punkt ist die Aufnahme eines Incidents und dessen Priorisierung bzw. Problem Management. Aufgabenbereiche klar voneinander abzugrenzen. Als ein weiterer kritischer Punkt ist in diesem Zusammenhang die Bearbeitung von Incidents zu sehen. Incident und Problem Management. da eine klare Abgrenzung auf Grund der geringen personellen Größe der Abteilungen oftmals nicht möglich ist. Insbesondere die Implementierung einer gemeinsamen Configuration Management Database wäre wichtig.Service Support-Umsetzung an zwei ausgewählten Fakultäten 43 Anhand des im vorangegangenen Abschnittes dargestellten IST-Zustandes des IT-Managements der beiden Fakultäten ist es offensichtlich. Ein weiteres Umsetzungsproblem besteht darin. Wird zum Beispiel von einem User der Fakultät für Wirtschaftswissenschaften ein bisher unbekanntes Problem bzw. kann die Problembehebung unter Umständen sehr aufwendig sein. Nach ITIL dient der Service Desk als zentrale Kommunikationsschnittstelle zwischen Usern und Support. dass jede Fakultät eine eigene EDV-Abteilung beinhaltet und diese als Ansprechpartner für die jeweiligen Fakultätsmitarbeiter dient. Service Desk. Im Grunde ist jede EDV-Abteilung autark und für die IT-Struktur der jeweiligen Fakultät verantwortlich. An der Universität sind sachliche Gründe bei der Bearbeitung eines Incidents oftmals nicht das Hauptkriterium. Release Management und Configuration Management im Einzelnen eingegangen. dass auf Grund der geringen personellen Größe der einzelnen EDV-Abteilungen die Mitarbeiter sich fast alle Aufgaben teilen und es dadurch nicht möglich ist. Die Architektur des Service Desks an der Universität Bielefeld entspricht dem eines lokalen Service Desk. Es soll aber nicht das Ziel sein. sämtliche Punkte des Service Supports nach ITIL auf die Universität zu übertragen.

welches dann auch die entsprechenden Rollouts durchführt.44 ITIL-Wirklichkeit an der Universität Bielefeld hang besteht die Möglichkeit. herrscht eine hohe Mitarbeiterfluktuation und damit geht häufig Wissen verloren. in der Universität gestaltet sich dies oftmals als schwierig. Infolgedessen ist es schwierig. die auf den fakultätsinternen Computern installiert werden und von den jeweiligen EDV-Abteilungen betreut werden. um einen solchen Mehraufwand zu vermeiden. wenn das Wiki mit einer Volltextsuche ausgestattet wäre. Dieses Lösungskon- . Change Management und Release Management. Dadurch besitzt jede Fakultät eigene Softwarestandards. und zum anderen die Dokumentation jeglicher Incidents. Das HRZ stellt zwar standardisierte Softwarepakete bereit. auch im Rahmen des Proactive Problem Managements. die von dem HRZ verwaltet werden könnte. dass es sich bei den Mitarbeitern zum Großteil um studentische Hilfskräfte handelt und diese meistens nur über einen begrenzten Zeitraum in der EDV-Abteilung arbeiten. doch jede Fakultät erweitert das SoftwareBundle um fakultätsinterne Software. einen einheitlichen Standard zu realisieren. Denn wäre der Abteilung das Problem bekannt gewesen. Die Voraussetzung dafür ist zum einen die Bereitschaft der Mitarbeiter. Dies gestaltet sich an der Universität Bielefeld auf Grund der autarken Fakultäten als äußerst schwierig. Mit Hilfe einer solchen Datenbasis könnte auch ein weiteres Problem gelöst werden. Das Ziel eines ITILkonformen Change Managements und Release Managements ist die Implementierung von autorisierter Software und Hardware mit Hilfe standardisierter Verfahren. hätten sie den Fehler schneller beheben können. Dies könnte zum Beispiel in Form eines Wikis geschehen. auf der die EDV-Mitarbeiter ihre erarbeiteten Lösungen. Incident Management und Problem Management festhalten. Abschließend lässt sich für die Bereiche Service Desk. Im Kontext des Service Supports nach ITIL wäre einen Fakultäts übergreifende Configuration Management Database (CMDB) von Vorteil. da entsprechende Sanktionierungsmaßnahmen keine Wirkung haben. anstatt zwei oder drei studentischen Hilfskräften eine Vollzeitkraft anzustellen und zusätzlich mit Hilfe einer Datenbasis das Wissen nachhaltig zu sichern. dass die Implementierung einer gemeinsamen Datenbasis in der Universität ein wichtiger Fortschritt wäre. Somit hat die EDV-Abteilung der Wirtschaftswissenschaften einen unnötigen Mehraufwand. Um die Suche nach einer Lösung für den Benutzer zu erleichtern. wäre es vorteilhaft. Eine Lösungsansatz für die Problematik könnte eine Definitive Software Library (DSL) sein. dass eine andere Fakultät einen ähnlichen Vorfall hatte und diesen bereits gelöst hat. Denn auf Grund der Tatsache. Um diesen Problem entgegenzuwirken. sondern darüber hinaus als Mittel der aktiven Kommunikation zwischen den verschiedenen Fakultäten. dass es keine einheitliche Softwarestandards für die Fakultäten gibt. müsste dann in Absprache mit den einzelnen Fakultäten festgelegt werden. Die Wartung der Software obliegt dann auch dem HRZ. Dadurch hätte man eine Plattform. Im Bereich der Software lässt sich für die Universität festhalten. Welche Programme auf der DSL installiert werden. für bestimmte Probleme den anderen Fakultäten zur Verfügung stellen können. Mit Hilfe dieses Konzeptes könnte dann die Software von dem HRZ zentral verteilt werden. ihr Wissen zu teilen. Sie sollte aber nicht nur als reine Wissensdatenbank fungieren. In einem Unternehmen kann dies beispielsweise durch Abmahnung gewährleisten werden. wäre es von Vorteil.

Zusammenfassend lässt sich festhalten. Ein weiteres Problem bei der Beschaffung der Hardware ist die Frage der Notwendigkeit. Eine mögliche Lösung wäre der Erwerb von Campuslizenzen für die gängigste Software. Die wesentliche Aufgabe des Configuration Management ist die Bereitstellung von Informationen mit Hilfe einer Datenbank. dass besonders im Hinblick der Softwareverwaltung. Aus diesem Grund sollte an jeder Fakultät ein Change Advisory Board (CAB) eingeführt werden. Dadurch besteht die Gefahr. Im Bereich der Hardware empfiehlt das HRZ Standard-Computer für die Universität. sollten zwingend geltende Richtlinien für die Beschaffung von Computern in den Fakultäten der Universität eingeführt werden. sollten dann in der Configuration Management Database (CMDB) gespeichert werden. Die Abbildung 1. dass manche Fakultäten überlizenziert und andere unterlizenziert sind. Es ist aber keine zwingende Vorgabe. Ein weiteres Problem im Bereich der Software ist die Softwarelizenzierung. Die Informationen. dementsprechend gibt es eine Vielzahl von unterschiedlichen Systemen. Oftmals werden für Lehrstühle neue Computer beschafft. dass eine vollständige Implementierung eines ITIL-konformen Service Support-Prozesses an der Universität Bielefeld 28 Aus Gründen der Übersicht wird das Konzept nur mit zwei Fakultäten dargestellt.3. der ITInfrastruktur der jeweiligen Fakultäten. Informationsdatenbank für Hardware. dass die Verwaltung der CMDB dem HRZ obliegt.12 stellt ein mögliches Lösungskonzept28 der Funktionsweise der CMDB und der DSL an der Universität Bielefeld dar. obwohl deren „alte“ Geräte noch ausreichend sind.12: Funktionsweise der CMDB und der DSL.1 und 1. Mittel der Kommunikation und DSL der einzelnen Fakultäten dienen.3. Es ist in diesem Zusammenhang empfehlenswert.Service Support-Umsetzung an zwei ausgewählten Fakultäten 45 zept basiert auf der Bereitschaft zur Zusammenarbeit der einzelnen Fakultäten. unterschiedliche Verfahren für die Verwaltung von Softwarelizenzen. CMDB+DSL Fakultät Wirtschaftswissenschaften Fakultät Rechtswissenschaften Rollout Informationen Rollout Informationen HRZ Abbildung 1. Es zeigt sich. wie in Abschnitt 1. Diese kann dann als Informationsdatenbank für die Hardware dienen. . Um diesen Umstand zu begegnen. Anhand der bereits genannten Kritikpunkte ist die Implementierung einer Configuration Management Database (CMDB) in die IT-Infrastruktur der Universität Bielefeld die wichtigste Empfehlung. da Standards festgelegt werden müssen. wie Microsoft Windows oder Microsoft Office. Configuration Management. Lizenzierung und Hardwareverwaltung Handlungsbedarf an der Universität Bielefeld besteht. Sie soll als Wissensdatenbank. Dieses sollte dann über die Zweckmäßigkeit einer teureren Anschaffung bestimmen. Die Fakultäten haben.2 gezeigt wurde.

dass ITIL mit dem Service Support ein Problemlösungskonzept zur Verfügung stellt. .46 ITIL-Wirklichkeit an der Universität Bielefeld nicht realisierbar ist. die die Probleme 29 Siehe Anhang.4 Fazit „Mein Computer stürzt dauernd ab.2 auch zu verstehen. Das Ziel der ausführlichen Darstellung war es. Daher löst ITIL Probleme nicht.2 mehr als deutlich. zum Beispiel spricht die vorhandene IT-Infrastruktur dagegen. 1. Von der Aufnahme des Incidents bis hin zur Lösung des Problems stehen nach ITIL Funktionen und Prozesse zur Verfügung. Die Gründe dafür sind vielfältig. ein weiterer wichtiger Punkt ist die geringe Größe der einzelnen EDV-Abteilungen. Hierzu gehört zum Beispiel die Implementierung einer Configuration Management Database (CMDB) und einer Definitive Software Library (DSL). Allerdings gibt Abschnitt 1. Probleme zu bewältigen. Somit sind die Vorteile von ITIL nicht von der Hand zu weisen. den User in jeglicher Hinsicht unterstützt. Problems und die damit verbundene Struktur des Service Supports ist. „Ich habe keinen Zugriff auf die Datenbank.2 wurde dann zunächst auf den IST-Zustand der Fakultät für Wirtschaftswissenschaften und der Fakultät für Rechtswissenschaft der Universität Bielefeld eingegangen.3 kamen Kritik und Empfehlungen hinsichtlich des ISTZustandes der Fakultäten in Bezug auf einen ITIL-konformen Service Support zu ihrer Geltung. In dem Abschnitt 1. Auch die Bereitschaft zur Veränderung und der Kooperation der einzelnen EDV-Abteilungen spielen bei der Einführung von ITIL eine wichtige Rolle.3. das den Kunden resp. die Unflexibilität gewisser Mitarbeiter und die unökonomische Betrachtungsweise der Universität. dass die jeweiligen Fakultäten autark voneinander arbeiten und dies zu einem unnötigen Mehraufwand bei einer Problemlösung führen kann. in dem die theoretische Struktur des Service Supports vorgestellt wurde. die sich in der Praxis bereits bewährt haben und einen reibungslosen Betriebsablauf gewährleisten können. Trotz dieser Gründen sollte aber versucht werden.3.3. Hier wurde zum Beispiel festgestellt. Diese wären nur mit einem großen Aufwand zu ändern. sondern zeigt Mittel und Wege auf. dass ITIL für solche Incidents resp. „Mein alter Computer kann mit seiner noch älteren Software dieses Problem nicht lösen. Hierbei wurden mit Hilfe eines bereits vorab ausgearbeiteten Fragenkatalogs29 Interviews mit den zuständigen EDV-Mitarbeiter geführt.1 bzw.3 diverse Vorschläge gemacht.“.“. Wie umfangreich die Incidents bzw. Weitere Probleme sind die fehlende Kommunikationsbereitschaft der Fakultäten untereinander. die Schwierigkeit der Implementierung eines ITIL-konformen Service Supports und die Komplexität der Anforderungen an die jeweiligen Prozesse darstellen zu können. einige Ideen von ITIL aufzugreifen und diese in der Universität umzusetzen. Problems immer einen Prozess auf Basis des Best Practice-Konzeptes zur Lösung vorschlägt.2. Auch hierzu wurden im Abschnitt 1. diese sind jedoch nicht im ausreichenden Maße vorhanden. Anschließend wurden die Interviews zusammengefasst und separat abgehandelt. 1. wurde in Abschnitt 1.“ Wir haben nun gesehen. In den Abschnitten 1.3. Hier war der Aufbau der einzelnen Abschnitte identisch mit dem Abschnitt 1. die damit zusammenhängenden Kosten würden aber den Nutzen nicht rechtfertigen.

ein ITIL-konformer Service Support wirklich für jeden lohnt. Dies hat verschiedene Gründe. umzusetzen. da die Kosten den Nutzen übersteigen würden. Als „Allheilmittel“ sämtlicher User-Probleme kann ITIL nicht verstanden werden. wie bereits aus Abschnitt 1. Bedürfnisse auslegen. aber auch nicht viel Wert gelegt. Auch Unternehmen. ob der von ITIL vorgeschlagene Service Support wirklich so sinnvoll ist. Somit ist von einer Umsetzung von ITIL an der Universität Bielefeld abzuraten. in dem eine klare Organisation unabdingbar für das Bestehen in der freien Marktwirtschaft ist. welches eine Einführung von ITIL erschwert.Service Support-Umsetzung an zwei ausgewählten Fakultäten 47 an der Universität Bielefeld nicht lösen. da sich hier mit Hilfe von ITIL eine bessere Übersicht in der Problembewältigung und somit ein reibungsloserer Betriebsablauf im Unternehmen gewährleisten lassen. da die vorgeschlagenen Funktionen und Prozesse sich bereits in der Praxis bewährt haben. auf operativer Ebene des serviceorientierten IT-Managements effizient zu arbeiten. Grundsätzlich lässt sich diese Frage mit einem „Ja“ beantworten. die ebenfalls eine Barriere für ITIL darstellt. Dies wurde auch im Verlauf dieser Arbeit deutlich. nur begrenzt sinnvoll. ist. die in der IT-Branche tätig sind. Im Vergleich zu einem Unternehmen. Problems des Users zu behandeln. Während ein Unternehmen eher monetäre Ziele verfolgt. Es gibt lediglich die Richtung und die Organisation der Problemlösung vor. Es lässt sich aber feststellen. ITIL ist vor allem für große Unternehmen von Interesse. aber zumindest die Situation verbessern würden.3 ersichtlich. ITIL bietet tatsächlich mit dem Service Support eine gute Möglichkeit. dass ITIL mit dem Service Support in seinen Grundzügen eine sehr gute Möglichkeit zur Gewährleistung eines reibungslosen Betriebsablaufes und zur Bewältigung von IT-Problemen darstellt. sind Forschung und Entwicklung im Bereich der Wissenschaft sowie Ausbildung von Wissenschaftlern die vorrangigen Ziele einer Universität. wird in der Universität zwar nicht darauf verzichtet. Zum einen sind da die unterschiedlichen Ausrichtungen der jeweiligen Unternehmungen zu nennen. werden eine Umsetzung von ITIL im eigenen Betrieb kaum hinterfragen. Zum anderen sind die doch teilweise undurchsichtigen Strukturen ein weiteres Problem. Zum Schluß ist noch die personelle Problematik. zu nennen. Die durchzuführenden Prozesse und die damit verbundene Qualität der Prozesse liegen im Aufgabenbereich der zuständigen EDV-Mitarbeiter. ITIL zum Beispiel an einer Hochschule. Diese Tatsache ist allerdings nicht weiter verwunderlich. wie die Universität Bielefeld. muss mit „Nein“ beantwortet werden. die Incidents bzw. ob sich ITIL bzw. Doch der Versuch. Aber die in dieser Arbeit wichtigste Frage. Aus diesem Grund sollte die Universität den Grundgedanken von ITIL aufnehmen und auf seine spezielle Ausrichtung resp. Am Anfang dieser Arbeit stellte sich die Frage. .

kurzfristig verfügbare Lösungsmöglichkeiten zum Umgang von Fehlern (Workarounds)? Treten Eskalationsfälle auf? Wird bei Problemen ein Problem-Record erstellt? Versucht man die Ursachen von Störungen zu erforschen? Werden die betroffenen CIs ermittelt? Wie werden die CIs ermittelt? Werden dem Service Desk so weit wie möglich Informationen. persönlich. dem die Entscheidungsgewalt obliegt? Wird sichergestellt.. dass durch eine Änderung an einer Stelle keine Störungen oder andere Beeinträchtigungen an einer anderen Stelle neu verursacht werden? Gibt es qualitätsgesicherte Standards und Grundkonfigurationen zur Installation von IT-Systemen? Prozess Incident Management Problem Management Change Management Release Management . Lösungsmöglichkeiten und Workarounds an die Hand gegeben? Werden unbekannte Fehler zu bekannten Fehlern? Wie geschieht das? Werden alle Prozessschritte zur Behebung überwacht und nachverfolgt? Werden definierte Methoden ein.48 ITIL-Wirklichkeit an der Universität Bielefeld 1. genehmigt und geordnet? Gibt es ein Change Advisory Board. vor allem wie wird Priorität definiert? Wie werden Incidents aufgenommen.5 Fragebogen Frage Ist ein zentraler Service Desk vorhanden? Wie funktioniert die Kontaktaufnahme?(eMail.. Anruf. dokumentiert und ausgewertet? Welche Informationen werden aufgenommen?(Incident Records) Deckt der Service Desk die Anforderungen der Kunden? Werden die Kunden über den Stand der Dinge informiert? Gibt es einen schnellen Zugriff auf verschiedene Dokumente und Support Informationen in Form von speziellen Dokumentmanagementsystemen oder Wissensdatenbanken? Gibt es eine Klassifizierung zwischen bekannten Fehlern und Problemen? Werden die bekannten Fehler in einer eigenen Datenbank (Known Error Database)? Gibt es schnelle. daher wie werden sie kategorisiert und priorisiert.) 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.. um Anzahl und Schwere von Störungsmeldungen nachhaltig zu senken? (Pro-Aktives Problem Management) Gibt es standardisierte Änderungsschritte? Werden alle Änderungsvorhaben geprüft.

Service Support-Umsetzung an zwei ausgewählten Fakultäten Prozess Release Management 49 Configuration gement Mana- Frage Ist das Change Management in das Release Management eingebunden? Existiert ein BackUp-System bzw. Netzwerk. Software) an zentraler Stelle dokumentiert? Sind die Aufgaben und Zuständigkeiten klar abgegrenzt? Gibt es einen Manager? Werden Kennzahlen und Statistiken über Störungsverläufe geführt? Welche Kennzahlen gibt es? Erfolgt die Softwareverteilung und der Aufbau von Rechnern automatisiert? Wie sehen die Tools für die einzelnen Geschäftsprozesse aus? Allgemein . Hardware. Lizenzen und Herstellersupport? Gibt es Verfahren zur Beschaffung.und Softwareinventars? Werden die Konfiguration aller IT-Komponenten (Kommunikation. Repository? Wird die ordnungsgemäße Durchführung der Änderungen organisiert. überwacht und dokumentiert? Werden bei Änderungen an Systemkomponenten alle wichtigen Daten gesichert und alle Komponenten gründlich getestet? Gibt es eine Datenbank für bekannte und gelöste Probleme? Gibt es gesicherte Informationen bzgl. Verfolgung und Bewertung von Hardware. Verwaltung.

50 ITIL-Wirklichkeit an der Universität Bielefeld .

: ITIL kompakt und verständlich. und Günther. 2. 1. TSO. TSO.Auflage 2006 Victor. H. Vieweg Verlag. 1.Literaturverzeichnis [Olb06] [Vic05] Olbrich. Auflage 2007 51 . Auflage 2007 [TRA07] Office of Government Commerce: ITIL .: Optimiertes IT-Management mit ITIL. F. Vieweg Verlag. 3.Auflage 2005 [OGC07] Office of Government Commerce: ITIL .Service Operation. A.Service Transition.

52 ITIL-Wirklichkeit an der Universität Bielefeld .

indem sie sich als „ITIL-konform“ bezeichnen. Allerdings ist diese Aussage nicht nachprüfbar. [Cod05. als Basis für eine unabhängige Zertifizierung und damit als Beleg für die Fähigkeit. Nur Einzelpersonen können ein Zertifikat erwerben (ITIL Foundation. eine Organisation ITIL-zertifizieren zu lassen. als Referenzwert für IT Management Services. die den Kundenbedürfnissen entsprechen. André Kröger. Die Anforderungen des Standards stellen einen Branchenkonsens für Qualitätsstandards bei IT Service Management-Prozessen dar. Es ist nicht möglich. S. in dem die Anforderungen an das IT Service Management einer Organisation zur Erlangung einer Zertifizierung formell dokumentiert sind. Es handelt sich dabei um einen international anerkannten Standard. Christopher Uhrig 2. 1] In der Geschäftspraxis wird der 53 . ITIL Service Manager. Services zu erbringen. die Service-Qualität zu überwachen und zu optimieren. Die damit einhergehende gesteigerte Servicequalität können Organisationen nach außen hin kommunizieren.1 Einleitung Mit ITIL steht IT-Dienstleistern eine detaillierte Sammlung von Best Practice Empfehlungen für die Gestaltung der Arbeitsabläufe im IT Service Management zur Verfügung. ITIL Practitioner). Da ITIL die Basis dieses Standards bildet. Anhand der in ITIL definierten Prozesse können die IT-Infrastruktur und die IT-Dienstleistungen übersichtlich und nachvollziehbar organisiert und kontinuierlich verbessert werden. kann mit einem Zertifikat die Konformität mit dem ITIL Rahmenwerk belegt werden. Der Standard kann dazu verwendet werden.Kapitel 2 ITIL-Zertifizierung nach ISO/IEC 20000 Eine Darstellung des Standards und des Zertifizierungsprozesses Julia-Vanessa Stork. da ITIL kein offizieller Standard ist. Der Standard ISO/IEC 20000 schließt diese Lücke.

Im Kapitel 2. den BS 15000 in einen neuen internationalen Standard zu überführen. Abschließend werden im Kapitel 2. Am 15. Dieser wurde im November 2000 von der BSI. Juni 2007 ihre Gültigkeit [SMF06. Dazu werden zunächst im Kapitel 2. Im Jahr 2002 wurde eine überarbeitete Version unter der Bezeichnung BS 15000-1:2002 herausgegeben.3 behandelt die Zertifizierung. inwiefern sich für eine Organisation die Umsetzung des Standards oder die Zertifizierung lohnt. Darin wurden die Anforderungen an ein effektives IT Service Management festgelegt. Aufgrund dessen ist in dieser Arbeit nicht vom BS 15000 die Rede. Es soll die Frage beantwortet werden. Ergänzt wurde dieses Dokument im Jahr 2003 durch den BS 15000-2:2003.2.2 2. S. den Standard ISO/IEC 20000 mit seinen Anforderungen an das Service Management von IT-Organisationen darzustellen sowie Möglichkeiten seiner praktischen Umsetzung und den Ablauf der Zertifizierung aufzuzeigen. der British Standards Institution. Der Standard spezifiziert die Anforderungen an das IT Service Management und ITIL dokumentiert zu den Prozessen des IT Service Management Best Practice Empfehlungen.2 die Entwicklung des Standards und seine Beziehung zu ITIL sowie die Anforderungen an die verschiedenen IT Service ManagementProzesse vorgestellt. Die für den BS 15000 ausgegebenen Zertifikate verloren nach dem 15. Dieser enthält nur geringfügige Änderungen gegenüber dem Originaltext des BS 15000.54 ITIL-Zertifizierung nach ISO/IEC 20000 Nachweis der Servicequalität zunehmend vorausgesetzt.]. [Gar06] Ziel dieser Arbeit ist es. 2.5 die wichtigsten Ergebnisse zusammengefasst. Dieser zweite Teil des BS 15000 enthielt Empfehlungen und Anleitungen zu den Anforderungen des ersten Teils. veröffentlicht.2. 2.2 Beziehung zu ITIL Der Standard ISO/IEC 20000 und ITIL ergänzen sich gegenseitig. Von der Entscheidungsfindung und Planung über die Umsetzung der Vorgaben des Standards bis hin zum Ablauf der Zertifizierung wird hier Schritt für Schritt der Weg zum Zertifikat dargestellt. den „Code of Practice for Service Management“. 11f. auch wenn dieser in der einschlägigen Literatur häufig verwendet wird. Während der Standard kurz gefasst die Kriterien für eine Zertifizie- .und Nachteile der Zertifizierung nach ISO/IEC 20000. sondern es wird ausschließlich auf den Standard ISO/IEC 20000 Bezug genommen. dass bis Ende 2008 mindestens 60% der relevanten Beschaffungsvorhaben der öffentlichen Verwaltung und mindestens 30% des privaten Sektors eine ISO/IEC 20000 Zertifizierung verlangen werden. Seit der Einführung des ISO/IEC 20000 findet nur noch eine Zertifizierung nach diesem Standard statt. Das Kapitel 2. Dezember 2005 wurde der Standard ISO/IEC 20000 veröffentlicht. So geht das Marktforschungsunternehmen Gartner davon aus. Im Mai 2005 entschieden die Mitglieder der ISO (International Organization for Standardization) und der IEC (International Electrotechnical Commission).4 erfolgt eine Gegenüberstellung der Vor.1 Der Standard ISO/IEC 20000 Entwicklung Der Standard ISO/IEC 20000 geht auf den British Standard BS 15000 zurück.

bezogen auf den Rahmen des formellen Standards.Eine Darstellung des Standards und des Zertifizierungsprozesses 55 ISO/IEC 20.1 dargestellt. ITIL stellt eine Sammlung von Best Practice Empfehlungen für die betriebsinternen Arbeitsabläufe im IT-Bereich einer Organisation dar. Quelle: Eigene Darstellung in Anlehnung an [SMF06]. rung festlegt.000 Best Practices ITIL IT Infrastructure Library Betriebsinterne Abläufe / Arbeitsabläufe Abbildung 2. Ergänzt wird der Standard um den Code of Practice. beschreiben die ITIL-Bücher die möglichen Wege. Dieser ist vergleichbar mit den Best Practice Empfehlungen von ITIL. Einem einführenden Kapitel zum Anwendungsbereich des Standards folgt die Einführung und Definition von .000 Specification ISO/IEC 20. diese Kriterien zu erfüllen. Grundlage für die Zertifizierung ist Teil 1 des Standards. 2. Die formelle Spezifikation des Standards ISO/IEC 20000 wurde auf der Basis von ITIL entwickelt und enthält spezielle verbindliche Vorgaben für eine Zertifizierung. Darüber hinaus werden noch einige zusätzliche Prozesse sowie übergeordnete Anforderungen an ein Management-System definiert. der Leitlinien und Empfehlungen für die Umsetzung enthält. die in den ITIL Publikationen „Service Support“ und „Service Delivery“ sowie „Security Management“ dokumentiert sind. Beide Teile sind inhaltlich gleich strukturiert. Der Standard ISO/IEC 20000 behandelt alle Service Management Prozesse.1: Spezialisierungsgrad der ISO 20000 Richtlinien. Der erste Teil 20000-1 „Specification“ definiert verbindliche Vorgaben („shall“) für das IT Service Management. die für eine Zertifizierung vollständig umgesetzt werden müssen. Der Zusammenhang zwischen ISO/IEC 20000 und ITIL ist in Abbildung 2.3 Struktur Der Standard ISO/IEC 20000 besteht aus zwei Dokumenten. für eine erfolgreiche Zertifizierung sind sie nicht zwingend erforderlich. Abweichungen von diesen Erläuterungen der Best Practices sind erlaubt. Der zweite Teil 20000-2 „Code of Practice“ enthält Leitlinien und Empfehlungen („should“) zur Umsetzung der Anforderungen des ersten Teils.2.

Lösungsprozesse. die eine effektive Implementierung und Verwaltung aller IT Services ermöglichen [Spe05. Zunächst werden die Anforderungen in Bezug auf die Verantwortlichkeiten.2. Fachbegriffen. Die Kapitel 3 bis 5 behandeln das Management-System. 3]. 2. müssen getroffen werden. Die Anforderungen des Standards sind unterteilt in Ziele (Objectives) und definierte Anforderungen zur Erfüllung dieser Ziele (Requirements). müssen die Rollen und Verantwortlichkeiten des Managements klar definiert sein. Steuerungsprozesse und Release-Prozesse aufgeteilt sind (siehe Abbildung 2. S. In den Kapiteln 6 bis 10 werden insgesamt 13 Service Management Prozesse definiert. wie diese Ziele erreicht werden sollen. Für jede Rolle im Service Management muss festgelegt werden. S. um eine kontinuierliche Angemessenheit und Effektivität sicherzustellen [Spe05.]. Dann erfolgt eine Beschreibung der „Plan-Do-Check-Act“-Methode. Quelle: Eigene Darstellung in Anlehnung an [Spe05]. In festgelegten Abständen sind Service Management Reviews durchzuführen. .2).56 ITIL-Zertifizierung nach ISO/IEC 20000 Service Delivery Processes Capacity Management Service Continuity and Availibility Management Service Level Management Service Reporting Budgeting and Accounting for IT services Information Security Management Control Processes Configuration Management Change Management Release Processes Release Management Resolution Processes Incident Management Problem Management Relationship Processes Business Relationship Management Supplier Management Abbildung 2. die Dokumentation und die Kompetenz der Mitarbeiter definiert.2: Service Management Processes. diesen auch gerecht zu werden. die zur Planung und Implementierung des Service Managements sowie neuer oder geänderter Services eingesetzt werden kann. 3f. Dazu gehört die Festlegung von Grundsätzen. Um dieses Ziel zu erreichen.4 Anforderungen an ein Management-System Das vorgegebene Ziel ist ein Management-System mit Grundsätzen und Strukturen. die in die 5 übergeordneten Gruppen Service Delivery-Prozesse. Relationship-Prozesse. Plänen und Zielen des Service Managements sowie die Beschreibung. Für die Koordination und die Verwaltung sämtlicher Services ist eine verantwortliche Person zu ernennen und es ist ein Risiko-Management zu implementieren. Die Anforderungen der Kunden müssen ermittelt und Maßnahmen.

"# operations Abbildung 2. die Abläufe und Prozesse sowie sonstige erforderliche Aufzeichnungen [Spe05. business.5 Planung und Implementierung des Service Managements Zur Umsetzung der Implementierung des Service Managements gibt der Standard die „Plan-Do-Check-Act“-Methode vor [Spe05.4]. 2. Bei der Planung des Service Managements müssen der Umfang des Service Managements. Desweiteren müssen sie sich der Bedeutung ihrer Aktivitäten bewusst sein [Spe05. 4]. S. S. supplier.g. bei dem vier Schritte in einem Kreislauf immer wieder durchlaufen werden (siehe Abbildung 2. Quelle: Eigene Darstellung in Anlehnung an [Spe05]. welche Kompetenzen zur effektiven Erfüllung der Aufgaben benötigt werden. customer DO "mplement service management CHECK %onitor. S.3).g.2.Eine Darstellung des Standards und des Zertifizierungsprozesses 57 Business requirements Customer requirements Request for new / changed services Other processes e. wie sie zur Erreichung der festgelegten Ziele beitragen. securit!. Entsorgung und Kontrolle der Dokumente festgelegt werden. Zu den Dokumentationen gehören die Grundsätze und Pläne. die Durchführung der Implementierung (Do). Die Festlegung der Ziele und notwendigen Prozesse (Plan). Dabei handelt es sich um ein Modell. 4]. measure and review #eam and people satisfaction Service Des Other teams.3: Regelkreislauf. die zu erreichenden Ziele sowie die auszuführenden Prozesse definiert werden. business. dass Abläufe und Verantwortlichkeiten für die Erstellung. und dass die Aktualität sichergestellt ist. Um dieses sicherzustellen. supplier. Ziele und Anforderungen (Check) sowie das Ergreifen von Maßnahmen zur kontinuierlichen Verbesserung der Prozesse (Act).g. customer Manage services %anagement responsibilit! Business results Customer PLAN &lan service management ACT Continual improvement satisfaction $ew / changed services Other processes. e. wie die Prozesse in Aktivitäten umgesetzt wer- . Die Mitarbeiter müssen wissen. Es ist zu beschreiben. sollte ein Weiterbildungsplan erstellt werden [Cod05. 3]. Durch diese Methode wird eine ständige Qualitätsverbesserung sichergestellt. S. Dabei ist zu beachten. die Überprüfung der Prozesse hinsichtlich der Grundsätze. Pflege. Eine weitere Anforderung ist die Bereitstellung von Dokumentationen und Aufzeichnungen zur Unterstützung der Management-Prozesse. e.

Vor der Durchführung einer Verbesserungsmaßnahme muss die Servicequalität als Vergleichsmaßstab dokumentiert werden [Spe05. um die Service-Qualität. die Kundenzufriedenheit und die Auslastung der Ressourcen zu überprüfen. S. Es müssen Methoden zur Überwachung der Prozesse eingeführt werden. Die Planung und Implementierung neuer oder geänderter Services muss im Rahmen eines formellen Change-Management erfolgen. die Ergebnisse vorheriger Prüfungen und die Auswahl der Prüfer berücksichtigt.6 Anforderungen an Service-Management-Prozesse Für alle Prozesse müssen das Ziel und der Ablauf des Prozesses. Planung. Dafür ist eine Analyse der kostenbezogenen.2. Abschließend sind messbare Ergebnisse für die Ausführung vorzugeben [Spe05. die Messung definierter Kennzahlen. S.]. Alle Pläne müssen durch einen Review überprüft und kommuniziert werden [Spe05. was nicht mit den Service Management Plänen übereinstimmt. 7]. Hilfsmittel und das Budget anzugeben. zu vereinbaren.58 ITIL-Zertifizierung nach ISO/IEC 20000 den und wie das Risikomanagement durchgeführt wird. Darüber hinaus sind die Verantwortlichkeiten. Methoden und Tools eingesetzt werden und wie viel Zeit und Geld dafür zur Verfügung steht. dass die Ziele durch die Prozesse erreicht werden können. Ausführung und Betreuung und die Änderungen an bestehenden Grundsätzen und Services beinhalten. Berichterstattung und Sicherstellung der Ausführung und Zielerreichung der Aktionen anzuführen. S. Daneben sind die Methoden zur Messung. Maßnahmen. technischen und wirtschaftlichen Auswirkungen notwendig. In regelmäßigen Abständen sind Reviews durchzuführen. Die Anforderungen an die Mitarbeiter sind zu dokumentieren und die Positionen zu besetzen. Diese müssen die Informationen zu den Verbesserungen und die festgelegten Ziele sowie die Methoden zur Identifizierung. Service Level Management Für das Service Level Management gibt der Standard als Ziel vor. die Rollen und Verantwortlichkeiten. welche Prozesse. S. das den Status und die Bedeutung des Prozesses. S. Es wird festgelegt. Kommunikation und Implementierung der Verbesserungsmaßnahmen beinhalten. die SchnittstellenSpezifikation sowie die kontinuierliche Verbesserung ersichtlich und beweisbar sein [SMF06. organisatorischen. 5]. entfernt werden. Abläufe und Definitionen für die Prozesse zu dokumentieren und einzuhalten. Die zu erstellenden Pläne müssen die Rollen und Verantwortlichkeiten für die Implementierung. Dabei sind Pläne und Grundsätze. die belegen können. Bezüglich des Fortschritts müssen Berichte angefertigt werden [Spe05. Budgets und Hilfsmitteln sowie durch die Koordination der Prozesse und die Auswahl und Schulung von Mitarbeitern zu erfolgen. 7f. Ressourcen. 2. 23]. S. Dafür sind Rollen und Verantwortlichkeiten klar zu definieren. 6]. Die Implementierung des Service Management Plans hat durch die Zuweisung von Verantwortlichkeiten. aufzu- . die Service-Level zu definieren. Es muss ein Prüfprogramm erarbeitet werden. Für die Bearbeitung von ServiceVerbesserungen muss ein Prozess definiert und ein Service-Verbesserungsplan erstellt werden. 6]. Die Ergebnisse sind mit den beteiligten Personen zu kommunizieren [Spe05. Für die Verbesserung der Service-Aktivitäten muss alles.

für die Kontrolle und Genehmigung des Budgets sowie für die Ermittlung und Zuordnung von indirekten Kos- .Eine Darstellung des Standards und des Zertifizierungsprozesses 59 zeichnen und zu verwalten. Durch regelmäßige Reviews ist sicherzustellen. dass die Vereinbarungen stets auf dem neuesten Stand sind. der angeboten wird. der Zielgruppe und Details über die Datenquelle enthalten. Der gesamte Serviceumfang sollte in einem Servicekatalog dargestellt werden. Für die Finanzplanung und Kostenrechnung. sollten potenzielle Probleme prognostiziert werden. der vom Change-Management zu verwalten ist und sowohl Kunden als auch Mitarbeitern jederzeit zugänglich sein sollte [Cod05. Jeder Service Report muss eine Beschreibung seines Zweckes. 8]. Um diese zu erreichen. 9]. 9]. S. müssen die Ursachen analysiert und angemessene Gegenmaßnahmen eingeleitet werden [Spe05. Es sind Zufriedenheitsund Trendanalysen durchzuführen und nach besonderen Ereignissen sind Leistungsberichte anzufertigen. um eine effektive Kommunikation zu gewährleisten und damit informationsbezogene Entscheidungen möglich zu machen. inwiefern die erbrachten Services die definierten Ziele erreicht haben und es müssen Leistungsmerkmale aller Prozesse aufgezeichnet werden. Die Verfügbarkeit muss gemessen und aufgezeichnet werden. Wo dies möglich ist. 11f. rechtzeitig vereinbarte. um die Auswirkungen von Changes auf die Verfügbarkeit und ServiceKontinuität zu kontrollieren. Anforderungen an Zugriffsrechte und Reaktionszeiten sowie an die Verfügbarkeit der Systemkomponenten müssen definiert werden und es ist sicherzustellen. S. Notwendige Maßnahmen zur Verbesserung sind in Service-Verbesserungsplänen zu dokumentieren [Spe05. Unterstützende Vereinbarungen und Lieferantenverträge sind ebenfalls aufzuzeichnen. Ist diese außerplanmäßig nicht gegeben. Jeder Service. Dabei sind Risiko-Bewertungen durchzuführen und zu dokumentieren. Es ist festzuhalten. dass diese erfüllt werden. S. Service Continuity und Availability-Management Zielvorgabe für das Service Continuity und Availability-Management ist die Sicherstellung der Service-Kontinuität und Verfügbarkeit.]. Die Service-Level müssen überwacht werden und es hat eine Berichterstattung zu den festgelegten Zielen zu erfolgen. Managemententscheidungen und Korrekturen müssen umgehend dokumentiert und kommuniziert werden [Spe05. so dass Vereinbarungen gegenüber dem Kunden unter allen Umständen eingehalten werden können. einen Plan für die finanziellen Ressourcen zu erstellen und die Kosten für die Bereitstellung von Services zu berechnen. Finanzplanung und Kostenrechnung für IT Services Ziel der Finanzplanung und Kostenrechnung für IT Services ist es. muss in einer Service-Level-Vereinbarung (service level agreement) zusammen mit dem zugehörigen Ziel dokumentiert werden. S. Es sollte eine enge Zusammenarbeit mit dem Change-Management erfolgen. damit vorbeugende Maßnahmen getroffen werden können [Cod05. zuverlässige und genaue Berichte zu erstellen. S. Service Reporting Ziel des Service Reporting ist es. 8]. müssen auf Basis der Service-Level-Vereinbarungen Verfügbarkeitspläne und Servickontinuitätspläne entwickelt und regelmäßig gepflegt und getestet werden.

Für den Umgang . 16]. so dass die mit dem Kunden vereinbarte Nachfrage jederzeit befriedigt werden kann. 10f. Grundsätze zur Informations-Sicherheit müssen definiert und kommuniziert werden. Information-Security-Management Ziel des Information-Security-Managements ist eine effektive Verwaltung der Informations-Sicherheit innerhalb aller Service-Aktivitäten. Eine Dokumentation der Kontrollen muss die Durchführung und Wartung der Kontrollmaßnahmen beschreiben und die Risiken nennen. S. S. Die Kosten müssen hinsichtlich des Budgets überwacht und dokumentiert werden. sind in Übereinstimmung mit dem Incident-Management Berichte und Aufzeichnungen zu erstellen. Service-Level-Vereinbarungen und Verträgen zu diskutieren. Abläufe und Techniken zu identifizieren und anzuwenden. den Kunden und seine geschäftsfördernde Abläufe zu verstehen und auf dieser Basis eine gute Beziehung zu dem Kunden herzustellen und zu pflegen. Der externe Zugriff auf Services und Systeme ist durch geeignete formelle Vereinbarungen zu regeln.60 ITIL-Zertifizierung nach ISO/IEC 20000 ten müssen klare Grundsätze und Prozesse definiert werden. Das Business-Relationship-Management muss alle Kunden und die an den Services beteiligten Personen identifizieren und dokumentieren. 10]. Im Rahmen des Capacity-Managements muss ein Kapazitätsplan erstellt und gepflegt werden. Dazu sind Sicherheitskontrollen einzuführen. Dafür sind Methoden. Es müssen Abläufe definiert sein. und dass entsprechende Maßnahmen getroffen werden [Spe05. um Geschäftsanforderungen. die dafür sorgen. Zusammen mit den Kunden müssen mindestens einmal pro Jahr Reviews durchgeführt werden. die erreichten Ziele. Der Kapazitätsplan muss Prognosen über zukünftige Anforderungen sowie Einflüsse durch neue technologische Entwicklungen und Auswirkungen externer Veränderungen berücksichtigen [Spe05. die Schwierigkeiten und die Aktionspläne zu erörtern. Treten sicherheitsrelevante Störungen auf. erbrachte Leistungen und Changes in Service-Umfang. 14]. und die die Risiken bezüglich des Zugriffs auf den Service oder auf die Systeme verwalten. dass jede sicherheitsrelevante Störung überprüft wird. Für sämtliche Informationsträger sollte eine Bestandsaufnahme.]. um die Service-Kapazität zu überwachen. die die Anforderungen der Grundsätze implementieren. Es sind regelmäßige Meetings abzuhalten und zu protokollieren. anzupassen und eine angemessene Kapazität bereitstellen zu können. Capacity-Management Zielvorgabe für das Capacity-Management ist die Sicherstellung der Verfügbarkeit ausreichender Kapazitäten. Die Kosten sind so detailliert zu planen. eine Kategorisierung entsprechend der Bedeutung für den Service und eine Bewertung der erforderlichen Sicherheitsstufe durchgeführt werden [Cod05. S. Kostenrechnungsprozesse sollten die Nutzung der finanziellen Ressourcen aufzeigen und die Ermittlung der Stückkosten ermöglichen [Cod05. Finanzprognosen sind zu überprüfen und dementsprechend müssen die Kosten verwaltet werden [Spe05. um die Leistung. S. S. auf die sie sich beziehen. dass die Kontrolle des Budgets und die Entscheidungsfindung effektiv gestaltet werden können. 10]. Business-Relationship-Management Ziel des Business-Relationship-Managements ist es.

Für die Verwaltung der Lieferanten müssen Prozesse implementiert und dokumentiert werden und jedem Lieferanten ist ein zuständiger Vertragsmanager zuzuordnen. S. Für bedeutende Incidents ist ein Prozess zu entwickeln.Eine Darstellung des Standards und des Zertifizierungsprozesses 61 mit Beschwerden muss ein formeller Ablauf festgelegt und mit den Kunden abgestimmt werden. Diese dienen als Input für den Service-Verbesserungsplan [Spe05. Die Rollen und Beziehungen zwischen den Hauptlieferanten und den Lieferanten mit Unterverträgen sind klar zu dokumentieren. S. Es muss ein Prozess festgelegt werden. 13]. Sie müssen mit den Service-Level-Zielen verglichen werden und es sind Verbesserungsmaßnahmen zu identifizieren und aufzuzeichnen. wenn sein Service-Level nicht erreicht werden kann. Incident-Management Ziel des Incident-Managements ist die Reaktion auf Service-Requests und die schnellstmögliche Wiederherstellung des vereinbarten Service. 11f. Sämtliche Incidents müssen aufgezeichnet werden und es sind Verfahren anzuwenden. S.]. Es müssen Maßnahmen ergriffen und dokumentiert werden und die Beschwerde muss formell abgeschlossen werden. die Klassifizierung und Aktualisierung. um die Auswirkungen von Incidents und Problemen zu . Sämtliche Mitarbeiter des Incident-Managements müssen auf die relevanten Informationen zugreifen können [Spe05. durch Identifizierung und Analyse der Ursache von Incidents und einer Verwaltung der Probleme bis zum Abschluss die Unterbrechungen des Geschäftsprozesses auf ein Minimum zu reduzieren. zu überprüfen und aufzuzeichnen. Lieferanten-Management Zielvorgabe für das Lieferanten-Management ist die Sicherstellung einer nahtlosen Bereitstellung von qualitativ hochwertigen Services. Die Kundenzufriedenheit ist regelmäßig zu messen und zu dokumentieren. Alle identifizierten Probleme müssen aufgezeichnet werden und es sind Verfahren anzuwenden. um die Auswirkungen von Incidents zu verwalten. Der Kunde muss über den Fortschritt der gemeldeten Incidents oder Service-Requests informiert werden. Schwankungen im Zufriedenheitsgrad sollten auf ihre Ursachen hin untersucht werden. Er ist vorab zu benachrichtigen.und der Beschwerdeanalyse fließen in den ServiceVerbesserungsplan ein. S. Problem-Management Ziel des Problem-Managements ist es. dass die nachgeordneten Lieferanten die Vertragsanforderungen erfüllen. Die Leistungen sind zu überwachen. 12]. Verbesserungs-Empfehlungen sollten an das Service Delivery Team weitergereicht werden [Cod05. Vertragsstreitigkeiten und die Beendigung des Service regelt. der Vertragsänderungen. Diese Verfahren müssen die Aufzeichnung der Incidents und Prioritätsabfolgen. muss dieser nachweisen. 18]. Die Ergebnisse der Feedback. der die Klassifizierung und Behandlung vorgibt. Werden Lieferungen indirekt über einen Hauptlieferanten bezogen. Für die Erfassung des Feedbacks und die Reaktion darauf muss ein Prozess erstellt werden [Spe05. Die Services müssen definiert werden und die Lieferantenverträge sind mit den Service-Level-Vereinbarungen abzustimmen und durch Reviews regelmäßig zu überprüfen. Alle Beschwerden sind aufzuzeichnen und zu untersuchen. die Auswirkungen auf Geschäftsabläufe sowie die Lösung und den formellen Abschluss definieren.

Alle Konfigurations-Elemente sind in einer Configuration-Management-Datenbank (CMDB) aufzuzeichnen. Changes sind zu genehmigen. Kontrolle und Überwachung von Service. Changes müssen einen klar definierten und dokumentierten Umfang haben. Standorte und damit zusammenhängende Änderungen und Probleme müssen den Personen zur Verfügung stehen. Es müssen Methoden zur Identifizierung. genehmigt. Korrekturen einleiten und Ergebnisberichte erstellen [Spe05. Änderungen an Konfigurations-Elementen müssen verfolgt und überprüft werden können. Diese Verfahren müssen die Aufzeichnung aller Probleme. Identifizierte Verbesserungsmaßnahmen müssen aufgezeichnet und dem Service-Verbesserungsplan hinzugefügt werden [Spe05. die diese benötigen. zu überprüfen und kontrolliert zu implementieren. Es ist ein Konfigurationsplan erforderlich. Es muss ein Zeitplan mit Details zu allen Changes erstellt werden. wiederkehrende Change-Kategorien. dass alle Changes bewertet. Nach der Implementierung ist ein Review durchzuführen. Diese muss aktiv gepflegt werden. 14]. deren Implementierung genehmigt wurde. Informationen zum Status der Konfigurations-Elemente. 14f.und Infrastrukturkomponenten sowie die Aufrechterhaltung korrekter Konfigurationsinformationen. deren Klassifizierung und Aktualisierung sowie deren Lösung und formellen Abschluss definieren. wie nicht erfolgreiche Changes rückgängig gemacht oder entfernt werden. Trends und andere relevanten Informationen zu ermitteln [Spe05. Informationen zu Auswirkungen von Veränderungen sind dem Change-Management zur Verfügung zu stellen. Change-Management Ziel des Change-Managements ist es sicherzustellen. Es sind Prozesse zur Überprüfung der Konfigurationen zu implementieren. . 13]. der Auswirkungen und des Geschäftsnutzens durchgeführt werden. Es müssen Richtlinien und Abläufe für Notfall-Changes erstellt werden und es ist zu definieren. Für die Planung des Change. in dem die Konfigurations-Elemente und deren Grundbestandteile aufgeführt werden.62 ITIL-Zertifizierung nach ISO/IEC 20000 identifizieren. um sich häufende Changes. Darin sind die Eigenschaften der Elemente und deren Beziehung zueinander zu definieren. Alle Requests for Changes sind aufzuzeichnen und zu klassifizieren. Die Implementierungszeiten sind allen beteiligten Parteien mitzuteilen.und Infrastrukturkomponenten entwickelt werden.]. die Mängel aufzeichnen. Configuration-Management Ziel des Configuration-Managements ist die Definition und Steuerung der Service. Aktuelle Informationen von bekannten Fehlern und behobenen Problemen müssen für das Incident-Management verfügbar gemacht werden und notwendige Änderungen sind an das Change-Management weiterzuleiten. Potenzielle Probleme sind durch vorbeugende Maßnahmen zu reduzieren. Die Problembehebung ist zu überwachen und es sind Reviews und Berichte dazu anzufertigen. deren Versionen.und Configuration-Managements muss ein integrativer Ansatz verfolgt werden. um deren Zuverlässigkeit und Aktualität sicherzustellen. implementiert und überprüft werden. Es müssen Bewertungen bezüglich der Risiken. Der Zugriff auf die Datenbank ist strikt zu kontrollieren. Die Aufzeichnungen von Changes müssen regelmäßig analysiert werden. S. dessen Ergebnisse in den Service-Verbesserungsplan einfließen. S. Zur Aufrechterhaltung der Integrität von Systemen und Services sind Prozesse zur Steuerung der Konfigurationen erforderlich. zu minimieren oder zu vermeiden. S.

Abschließend werden die Ergebnisse des Assessments allen IT-Mitarbeitern präsentiert [Boc06. welche nächsten Schritte in welcher Reihenfolge unternommen werden sollten. Für die Durchführung des Assessments sollte ein geeignetes Beratungsunternehmen beauftragt werden. Es muss ein detaillierter Zeitplan für die Durchführung erstellt werden und die Mitarbeiter des IT-Bereiches sind darüber zu informieren. Dabei wird aufgezeichnet. Bearbeitung. Auf der Grundlage der Ergebnisse des Assessments werden . sind zu dokumentieren und zu vereinbaren. 38 f.1 Die Zertifizierung Entscheidungsfindung Grundlage für die Entscheidung für eine Zertifizierung nach ISO/IEC 20000 ist die Durchführung einer Standortbestimmung des IT-Bereiches und die Erarbeitung eines Maßnahmenplanes für die notwendigen Anpassungen. Es ist sinnvoll. Die entsprechenden Dokumente sollten rechtzeitig vorbereitet werden. sich von dem Beratungsunternehmen einen Maßnahmenplan erstellen zu lassen. Das Beratungsunternehmen erstellt dazu einen Bericht. Es ist ein Projektteam mit einem Projektleiter und den Prozessverantwortlichen zusammenzustellen. was für eine erfolgreiche Zertifizierung noch zu tun ist. Es sind Messungen bezüglich des Erfolges von Releases durchzuführen [Spe05. Systemen. Dabei wird der konkrete Reifegrad aller IT-Service-ManagementProzesse ermittelt und es werden Empfehlungen abgeleitet. was bei den Prozessen jeweils bereits vorhanden ist. Ein geeigneter Weg für die Standortbestimmung ist die Durchführung eines Assessments. wie nicht erfolgreiche Releases rückgängig gemacht oder entfernt werden. Das eigentliche Assessment wird in Form von Interviews durchgeführt. Die Einführung (Rollout) des Release ist zwischen allen beteiligten Parteien zu vereinbaren und von allen Parteien zu genehmigen.Eine Darstellung des Standards und des Zertifizierungsprozesses 63 Release-Management-Prozess Ziel des Release-Management-Prozesses ist die Bereitstellung.3 2. 15]. Es sind Richtlinien und Abläufe für Notfall-Releases zu erstellen und es muss definiert werden. Es muss ein Plan für das Release von Services. der für jeden Prozess einen konkreten Reifegrad benennt und Empfehlungen ausspricht. Die Vorgehensweise des Assessments sollte mit dem Beratungsunternehmen in einem Vorgespräch geklärt werden. S.3. Vor der Bereitstellung müssen alle Releases in einer kontrollierten Testumgebung erstellt und getestet werden. Verteilung und Verfolgung eines oder mehrerer Changes in einem Release in der Live-Umgebung. so dass sie zu den vereinbarten Zeiten verfügbar sind und die erforderlichen Dokumente griffbereit haben. S. dass die Integrität der Hardware und Software während der Installation. Der Release-Management-Prozess sollte in die Configuration und Change Management Prozesse integriert werden. die die Häufigkeit und den Typ der Releases angeben. Das Release muss so konzipiert und implementiert werden. 2. Dabei werden die Prozesse bereits grob durchgesprochen und die Prozessdokumentationen werden gesichtet. Verpackung und Auslieferung gewährleistet ist.]. Darauf aufbauend kann im Fall einer Entscheidung für die Einführung der Anforderungen des Standards ein Projektplan für die Umsetzung der Prozesse erstellt werden. Grundsätze. Software und Hardware erstellt werden.

. mit welchen Mitteln die vorgegebenen Ziele erreicht werden sollen. das Business-Relationship-Management sowie das Lieferanten-Management. und dass durch die Verwendung von konkreten Begriffen ein einheitliches Verständnis gewährleistet sein muss [Boc06. die Organisation und die Strategie des IT-Bereichs festlegt. Die IT-Strategie ist schriftlich auszuformulieren und an die Mitarbeiter zu verbreiten [Boc06. also das Management-System. wird in einer Anwendungsstrategie formuliert. Aufzeichnungen über relevante Risiken können beispielsweise in Form einer Risikomatrix.].3. S. Ziele und Prioritäten sind in einem Leitbild zu definieren. Die Philosophie. Behandelt werden nur die über ITIL hinausgehenden Teile. dass eine ausformulierte Unternehmensstrategie existiert. Die Umsetzung und die Wirksamkeit der Gegenmaßnahmen sind laufend zu überwachen. Auf die Umsetzung der auf ITIL basierenden Prozesse wird ausführlich in den Arbeiten der anderen Gruppen eingegangen. S. 81]. das Service Reporting. 81]. Voraussetzung für die Umsetzung ist. Für die Umsetzung eines Risikomanagements ist ein Vorgehen zu definieren. S. wie die vorgegebenen Prozesse im Betrieb realisiert werden können und was dabei zu beachten ist. wie die IT strukturiert und organisiert wird. auf welche Art und Weise die IT-Services erbracht werden sollen. Die Ressourcenstrategie beantwortet die Frage. S. das Information-Security-Management. S. dass die Ziele auch erreicht werden und wie man gewährleistet. Management-System Das Management-System ist ein Rahmenwerk. 2.4 dargestellt werden. wie Risiken erkannt.64 ITIL-Zertifizierung nach ISO/IEC 20000 darin alle für eine Zertifizierung notwendigen Maßnahmen und Umsetzungserfordernisse aufgelistet.2 Prozessumsetzung Das folgende Kapitel thematisiert die praktische Umsetzung der Anforderungen des ISO/IEC 20000. Daraus abzuleiten ist eine IT-Strategie. Rahmenbedingungen dieses Strategiekonzepts sind die Unternehmensumgebung und die vorhandenen IT-Strukturen sowie die Vorgaben zur Effektivität und Effizienz. wie man sicherstellt. Bei der Formulierung sämtlicher Dokumente ist zu beachten. Die Ziele und Strategien heruntergebrochen auf die einzelnen Prozesse ergeben zusammengefasst die Service-Management-Politik. Der Plan ist nach den Prozessen zu strukturieren und es ist eine Prozesslandkarte als Übersicht zu erstellen [Boc06. wie diese umzusetzen sind. erfasst und bewertet werden und wie Gegenmaßnahmen ergriffen werden. Es wird beschrieben. geführt werden [Boc06. 49f. Die Aufgaben. Darin ist zu beschreiben. das die Politik. Die konkreten Ziele und Vorhaben für das kommende Geschäftsjahr sind in einem ServiceManagement-Plan zu definieren. dass diese nicht nur von Spezialisten verstanden werden müssen. 72]. 76f.]. Es muss formuliert werden. Darauf aufbauend werden in einer Systemstrategie und einer Organisationsstrategie festgelegt. die Eintrittswahrscheinlichkeit und Schadenshöhe einander gegenüberstellt. dass die Dokumente stets aktuell sind [Boc06. In einem Dokument Management-System sind organisatorische Grundprinzipien sowie die Rollen und Verantwortlichkeiten für die Prozesse und Dokumente festzulegen. deren wesentliche Bestandteile in der Abbildung 2. die Planung und Implementierung des Service-Managements.

. Bei den Nonkonformitäten kann es sich um einen Verstoß gegen die Anforderungen oder um Verbesserungspotential handeln. zu ändern und zu archivieren sind. S. Eine weitere Aufgabe des Management-Systems ist die Bereitstellung von Dokumentationen. Der KVP-Manager hat die ergriffenen Maßnahmen zu überprüfen und zu bewerten. Darin sind die Zuständigkeiten und der Zeitrahmen für die Umsetzung festzulegen. der gleichzeitig Lösungsvorschläge ausarbeitet.]. Alle Mitarbeiter müssen über die Maßnahmen informiert werden [Boc06. hat der Prozessmanager die Aufgabe.Eine Darstellung des Standards und des Zertifizierungsprozesses 65 Abbildung 2. Quelle: Eigene Darstellung in Anlehnung an [Boc06]. Die Implementierung von Services anhand dieser Methode bewirkt einen kontinuierlichen Verbesserungsprozess (KVP) der Leistungen. wie Dokumente zu erstellen. Es sind standardisierte Abläufe zu definieren. Wenn bei der Überprüfung der implementierten Prozesse Nonkonformitäten mit den festgelegten Zielen und Anforderungen auftreten.4: Strategiekonzept. Diese werden in einem Maßnahmenkatalog gesammelt. Von jeder Version eines Dokumentes sollte eine Archivdatei erstellt werden und die Versionsführung sollte dokumentiert werden. eine Bewertung durchzuführen. Planung und Implementierung des Service-Managements Zur Umsetzung der Planung und Implementierung des Service-Managements ist die in Kapitel 2. Daraus hat der KVP-Manager den erforderlichen Handlungsbedarf abzuleiten und entsprechende Maßnahmen zu ermitteln. Für alle Abläufe muss es klare Verantwortlichkeiten geben [Boc06. meist durch den zuständigen Prozessmanager. der mit einem Tool verwaltet werden sollte.5 vorgestellte „Plan-Do-Check-Act“ -Methode zu verwenden. S.]. Es muss ein Prozessmanager (KVP-Manager) bestimmt und eine Prozessbeschreibung erstellt werden. 107f.2. 86f. Die Ermittlung der Ursachen erfolgt durch einen Spezialisten.

66 ITIL-Zertifizierung nach ISO/IEC 20000 Service Reporting Aufgabe des Prozesses Service Reporting ist es. Ausgehend von der Sicherheitspolitik sind Sicherheitsrichtlinien zu definieren. Dabei sind die sicherheitsrelevanten Ereignisse (Security Incidents) zu benennen und es ist zu beschreiben. was grundsätzlich wie schutzbedürftig ist. inwiefern Vorkehrungen hinsichtlich der IT-Systeme und des Personals nötig sind und wie die Kontrolle und Verbesserung der Schutzmechanismen sichergestellt werden kann. welches Maß an Schutz angemessen ist. Für den Umgang . wie damit umzugehen ist. Auf diese Weise entsteht eine Sammlung von Berichten.]. durchgängig zu nummerieren und regelmäßig auf ihre Aktualität zu überprüfen [Boc06. Aus dieser Beurteilung sind Gegenmaßnahmen abzuleiten [Boc06. Die Mitarbeiter des IT-Bereichs haben in diesem Zusammenhang verschiedene Aufgaben zu erfüllen. 134f. auf die jederzeit zugegriffen werden kann. Dabei muss deutlich werden.]. Es ist sinnvoll. S. der festlegt. 127f. um ein einheitliches Verständnis davon im Unternehmen zu etablieren. die die Kundenanforderungen verwalten. S. auf welcher Datenquelle er basiert und in welchem Rhythmus er erstellt wird.]. an wen er sich richtet. die Berichte nach den Prozessen zu kategorisieren. so dass man Prioritäten erkennen kann. die jeder Mitarbeiter zwingend einhalten muss. Anfragen nach einer standardisierten Vorgehensweise zu bearbeiten und Vorlagen für die strukturierte Durchführung von Kundenterminen zu erstellen. Die Prozessverantwortlichen müssen Prozessänderungen und die Archivierung von Dokumenten bekannt machen und für die Aktualisierung der Berichte ihrer Prozesse sorgen. welche Berichte verfasst und verbreitet werden sollen. eine Plattform für eine effektive Kommunikation innerhalb des IT-Bereiches zur Verfügung zu stellen. Darin soll für jeden verständlich die Grundhaltung zum Thema Sicherheit festgelegt werden.]. S. Darüber hinaus ist es sinnvoll. S. S. Die Eintrittswahrscheinlichkeit eines Security Incidents und die potentielle Schadenshöhe müssen bewertet werden. 279f. 103f. die sämtliche Regeln enthalten. Die Sicherheitspolitik ist mit der Geschäftsleitung abzustimmen und im Unternehmen bekannt zu machen [Boc06. Die Kommunikation mit den Kunden ist zu dokumentieren. Business-Relationship-Management Für den Umgang mit Kunden sind klare Regeln zu definieren. Diese Informationen können zur übersichtlichen Strukturierung in die Darstellung der Berichte übernommen werden. Sämtliche erforderlichen Reports können beispielsweise auf einer Intranetseite dargestellt und verlinkt werden [Boc06. In regelmäßigen Abständen sind Reviews mit den Kunden durchzuführen. welche Person für den Report verantwortlich ist. Diesbezüglich müssen die Mitarbeiter geschult und für das Thema Sicherheit im Allgemeinen sensibilisiert werden. Der Service-Manager ist für die Änderung der Prozessdokumentation verantwortlich [Boc06. um die erbrachten Services und Änderungswünsche zu diskutieren. Information-Security Management Als Grundlage für den Prozess Information-Security Management ist eine Sicherheitspolitik zu definieren. Es sollte formuliert werden welche Bedrohungen existieren. Als zentrale Ansprechpartner für alle IT-Fragen können Geschäftsfeldbetreuer bestimmt werden. Alle Geschäftsprozesse des Unternehmens sind auf mögliche Sicherheitsrisiken zu untersuchen. 103]. Grundsätzlich hat sich jeder über die für ihn relevanten Berichte zu informieren. Zur Umsetzung ist ein Prozessmanager zu bestimmen.

bearbeitet und abgeschlossen werden. sind Prozesse zu definieren.3 Fragenkatalog zur Prozessumsetzung Die in diesem Kapitel wiedergegebenen Fragen jedes einzelnen Prozesses stellen eine Art Checkliste für eine Zertifizierung nach ISO/IEC 20000 dar. alle Festlegungen dieses Prozesses in einem zentralen Dokument festzuhalten [Boc06. Durchführung und Verbesserung einzelner Handlungen vorhanden? • Werden die Zuständigkeiten und die hinreichenden Kompetenzen für alle Rollen bestimmt? • Sind Verantwortliche und Zuständigkeiten zur Erstellung und Aktualisierung von Dokumenten vorhanden? • Ist der Schulungsbedarf der Mitarbeiter so geregelt.Eine Darstellung des Standards und des Zertifizierungsprozesses 67 mit Beschwerden muss ein Prozess erstellt werden. Es sollte ein laufendes Monitoring von Leistungen und Preisen durchgeführt werden. Für den Vertragsabschluss. Überwachung. 2. die Leistungen zu verbessern [Boc06. Es sollte definiert werden. Die erhobenen Informationen sollen helfen. der sicherstellt. Management-System • Ist ein IT-Service-Management. d. dass alle Beschwerden aufgezeichnet. Änderungen und die Auflösung von Verträgen. Jedem Lieferanten wird ein verantwortlicher Manager zugeordnet. Es empfiehlt sich. Die Lieferantenverträge sind an die Anforderungen der Service-Level-Vereinbarungen anzupassen. bzw. 121f. insbesondere bei Streitfällen. Sie zeigen Anhaltspunkte für die jeweiligen Prozessmanager auf und dienen der Aufdeckung von Schwachstellen innerhalb des jeweiligen Prozesses. Lieferanten-Management Es sind Grundsätze zu formulieren. dass diese ihre Aufgaben kompetent und effektiv erfüllen? • Ist eine Identifikation von Kundenanforderungen vorhanden und wird diese von den Mitarbeitern erfüllt? • Sind sich die Mitarbeiter des Unternehmens über die Orientierung an Kundenanforderungen bewusst. In regelmäßigen Gesprächen müssen mit den Lieferanten die erbrachten Leistungen und Maßnahmen zur Verbesserung der Zusammenarbeit diskutiert sowie die zukünftigen Strategien abgestimmt werden. der als zentraler Ansprechpartner alle Vorgänge im Blick hat. sehen sie die Relevanz der ServiceErbringung? • Sind die einzelnen Prozesse aufeinander abgestimmt? .h. S. wie die Zusammenarbeit mit den Lieferanten aussehen soll. S. Die Kundenzufriedenheit ist regelmäßig durch eine Umfrage zu überprüfen.3. eine Strategie. eine Zielsetzung vorhanden? • Sind genügend Ressourcen zur Planung.]. wer was bestellen darf und welche Verträge durch Juristen geprüft werden müssen.]. 114f.

sowie die Umsetzung aller freigegebenen Maßnahmen sicherstellen? • Wird die Objektivität bei einem internen Audit sichergestellt. ob Konformität der Anforderungen an das Service-Management mit den Vorgaben des ISO/IEC 20000 besteht. wenn ein Ziel nicht erreicht wird. die Verbesserungen identifizieren.68 ITIL-Zertifizierung nach ISO/IEC 20000 Planung und Implementierung des Service-Managements • Werden die Prozesse des IT-Service-Managements im Unternehmen identifiziert? • Besteht eine klare Vision bzw. das Auditoren nicht ihre eigene Arbeit auditieren? Service-Level-Management • Werden die angebotenen Services in einem Service-Level-Agreement definiert und dokumentiert? • Ist eine Berichterstattung und Überprüfung sowie aktuelle Informationen und Entwicklungen über die erreichten Service-Levels vorhanden? • Werden die Gründe. die überprüfen. Strategien und Ziele überarbeiten. • Wurden alle Non-Konformitäten behoben? • Werden durch das Unternehmen Handlungen durchgeführt. Verbesserungsmaßnahmen überhaupt zu identifizieren.h. ggf. korrigiert und überprüft? • Werden verschiedene Reviews durchgeführt? . die mehr als einen einzelnen Prozess betreffen? • Gibt es Management-Reviews. klare Leitlinien des Managements zur Überprüfung des Service-Managements-Plans? • Ist die Zuständigkeit in Fragen zur Serviceverbesserung eindeutig festgelegt? • Legt der Service-Management-Plan den Bereich des Service-Managements in dem Unternehmen fest und zeigt dieser verschiedene Zielerreichungen und Schnittstellen zwischen den Service-Management-Prozessen auf? • Stimmen die Prozessziele mit denen des Service-Management-Plans überein? • Sind alle Verbesserungsmöglichkeiten überprüft. d. dokumentiert und freigegeben? • Besteht die Möglichkeit.

sind dann die CDMB. die Informationen über verwendete Datenquellen. um eine zukünftige Kontrolle und Entscheidungsfindung durchzuführen? • Erfolgt ein kontinuierlicher Vergleich der anfallenden Kosten mit dem vorhandenen Budget und werden Maßnahmen bei einer erheblichen Abweichung eingeleitet? .Eine Darstellung des Standards und des Zertifizierungsprozesses Service Reporting 69 • Steht eine detaillierte Beschreibung der einzelnen Berichte. die die Services nach einem Ausfall und den Normalzustand des Systems wieder herstellen? • Wenn ein normaler Zugang zum Büro nicht möglich ist. Zwecke und Identitäten enthalten. die Kontaktliste und der Notfallplan für die befugten Mitarbeiter zugänglich? • Ist ein proaktives Vorgehen. zur Verfügung? • Sind alle erforderlichen Berichte und Dokumente vorhanden und stets aktuell? • Werden erlangte Ergebnisse und Optimierungspotentiale in den Entscheidungen des Managements berücksichtigt? Service-Continuity-Management • Sind Pläne vorhanden. die Zusammensetzung der Teams im Notfall und ein Vorgehen im Notfall definiert? • Existiert eine jährliche Überprüfung der Notfallpläne? • Werden die Ergebnisse einer Prüfung in Maßnahmeplänen festgehalten? Availability-Management • Ist ein Verfügbarkeitsplan vorhanden und wird dieser auf veränderte Geschäftsanforderungen aktualisiert? • Wird die Verfügbarkeit des benötigten Services für den Geschäftsprozess sichergestellt? • Existieren präventive Maßnahmen für ungeplante Ausfallzeiten? • Wird die Verfügbarkeit des Services gemessen und dokumentiert? Finanzplanung mit Kostenrechnung für IT-Service • Ist eine eindeutig definierte Finanzplanung und Kostenrechnung für alle Komponenten vorhanden? • Besteht eine effiziente Kontrolle und Genehmigung der Finanzen? • Reichen die Finanzen aus.

70 Capacity-Management ITIL-Zertifizierung nach ISO/IEC 20000 • Ist ein Kapazitätsplan vorhanden und wird dieser kontinuierlich aktualisiert? • Werden Request for Changes erstellt? • Werden vom Kapazitätsmanagement zukünftige Geschäftsanforderungen. überprüft.und Kapazitätsanforderungen sowie Daten und Prozesse zur Analysenbetrachtung aufgezeigt? • Erfolgt die Identifizierung von Verfahren. Mechanismen und Techniken. Auswirkungen externer Veränderungen. aktuelle Leistungs. um die Serviceleistungen und -kapazität aufzuzeigen? Information-Security-Management • Ist die Sicherheitspolitik für Mitarbeiter und Kunden ausreichend festgelegt? • Sind effiziente Sicherheitsmaßnahmen zur Implementierung dieser Vorgaben der Politik vorhanden? • Existieren Maßnahmen zur Behandlung von Risiken? • Existiert die Dokumentation der Sicherheitsmaßnahmen? • Wird bei der Beschreibung dieser Maßnahmen Bezug auf verschiedene Risiken und Wartung dieser genommen? • Wird untersucht. ob Changes ein Sicherheitsrisiko darstellen? • Werden alle Security-Incidents erkannt. vorhersehbare Auswirkungen neuer Technologien und Techniken. entsprechend dem Incident-Prozess abgearbeitet und werden entsprechende Maßnahmen ergriffen? Business-Relationship-Management • Werden die Stakeholder der einzelnen Services identifiziert und schriftlich festgehalten? • Sind Verantwortliche für die Bestimmung der Kundenzufriedenheit festgelegt? • Ist das Unternehmen auf zukünftige Änderungen der Geschäftsanforderungen der Kunden vorbereitet? • Werden regelmäßige Besprechungen mit den Kunden zur Standortbestimmung durchgeführt und dokumentiert? • Sind für Reklamationen von Kunden entsprechende Prozesse eingeführt? .

über das Change-Managements? • Unterliegt die Wirksamkeit des Prozesses einer Überwachung und Überprüfung? . Priorisierung. die Incidents und Fehler verhindern können. Lösung und ein formaler Abschluss? • Werden alle offenen Tickets ausgewertet und die Kunden über die Entwicklung ihrer gemeldeten Incidents informiert? • Erfolgt eine eindeutige Zurechenbarkeit der Tickets zu einem Mitarbeiter und zu einem Kunden? • Wie wird mit der Eskalation umgegangen? • Ist die Übergabe der Incidents ins Problem-Management eindeutig möglich? Problem-Management • Erfolgt eine Dokumentation der auftretenden Probleme durch die Verantwortlichen? • Wird die Prävention von Fehlern als ein relevanter Teil des ProblemManagements angesehen? • Werden die Probleme eindeutig klassifiziert? • Erfolgt eine Weiterleitung aller Verbesserungen und Veränderungen. um die vertraglichen Verpflichtungen und die geschäftlichen Notwendigkeiten einzuhalten. Beurteilung der Geschäftsauswirkungen. größere Reviews mindestens einmal im Jahr durchgeführt? • Gibt es Verfahren für die Überwachung der Leistung interner und externer Lieferanten? Incident-Management • Besteht eine Aufzeichnung aller Incidents und eine nachgelagerte Ticketerfassung? • Enthält der Prozess die Aktivität der Aufzeichnung. Klassifikation.Eine Darstellung des Standards und des Zertifizierungsprozesses Lieferanten-Management • Sind dokumentierte Lieferanten-Management-Prozesse vorhanden? • Existiert für jeden Lieferanten ein Verantwortlicher? • Sind alle Prozessschnittstellen vereinbart und beschrieben? 71 • Besteht eine Dokumentation von Rollen und Interaktionen von Hauptund Unterlieferanten? • Werden. Aktualisierung. Eskalation.

die Revidierung von nicht erfolgreichen Releases erfolgt? • Werden die Changes nach Ausbringung eines Releases auf dem aktuellem Stand gehalten? . Steuerungsmöglichkeiten und Versionsverfolgung bereitgestellt? • Informiert das Configuration-Management das Change-Management über Veränderungen? • Wird die Configuration Management Data Base (CMDB) überprüft und verwaltet. bestimmten Zuständigkeiten der Mitarbeiter. um Zuverlässigkeit und Genauigkeit zu garantieren? • Erfolgen Audits zur CMDB? Change-Management • Werden Veränderungen des Services und der Infrastruktur in einem angemessenen Umfang dokumentiert? • Erfolgt eine Beurteilung sogenannter Veränderungsanträge hinsichtlich bestimmter Risiken. die alle Changes hinsichtlich ihrer Aussicht auf Erfolg prüfen. erwarteten Ergebnissen sowie Handlung bzgl.72 Configuration-Management ITIL-Zertifizierung nach ISO/IEC 20000 • Sind Schnittstellen zur Anlagenbuchhaltung vorhanden? • Existiert eine Begriffsabgrenzung eines Konfigurationselements (CI) und deren zugehörigen Komponenten? • Werden durch das Configuration-Management Mechanismen zur Identifikation. Kommunikation mit relevanten Abteilungen.B. Auswirkungen. der Software und Hardware mit dem Kunden? • Werden Vorgehensweisen beschrieben. die verschiedene Arten von Releases enthält? • Besteht eine Absprache der Planung der Releases bzw. Sicherheitskontrollen und finanzieller Gegebenheiten? • Existieren formelle Verfahren. wie z. des Kompetenz.und Schulungsbedarfs? • Erfolgt eine Weitergabe der veränderten Ergebnisse an alle Mitarbeiter des IT-Bereichs? Release-Management • Existiert eine Politik. kontrollierend einführen und genehmigen? • Werden wiederkehrende Ergebnisse und relevante Informationen aufgedeckt? • Gibt es bei der Einführung veränderter und neuer Services eine wirksame Planung und Überprüfung durch das Change-Management? • Befasst sich das Unternehmen bei einer Veränderung des Services mit Zeitplänen.

5 dargestellt.]) 2. Quelle: Eigene Darstellung in Anlehnung an [Boc06]. S. 233]. Es sind Besprechungsräume zu reservieren und sämtliche Dokumente zur Verfügung zu stellen. Die Prozessmanager müssen den jeweiligen Prozess beschreiben und berichten. um deren Folgen auf bestimmte IT-Tätigkeiten und Geschäftstätigkeiten zu überwachen? • Erfolgt eine Zuordnung von Incidents zu den entsprechenden Releases? • Wie funktioniert die Zusammenarbeit mit dem Change-Management? ([Boc06.5: Der Weg zum Zertifikat.Eine Darstellung des Standards und des Zertifizierungsprozesses 73 Assessment Maßnahmenplan Entscheidung Prozessumsetzung Internes Audit vor der Zertifizierung Erforderliche Korrekturen Korrekturmaßmahmen Zertifizierungsaudit Zertifikat Abbildung 2. ob die Anforderungen des Standards ISO/IEC 20000 verstanden. das bereits das Assessment durchgeführt hat. Es wird überprüft. S.3. 255ff. wie die Umsetzung des Management-Systems. In Gesprächen mit dem IT-Management werden grundsätzliche Dinge geklärt. gemessen und regelmäßig analysiert. Es ist zu empfehlen. Das interne Audit stellt einen letzten Check vor der Zertifizierung dar. • Werden Erfolge und Misserfolge von Releases bewertet. Sämtliche erforderlichen . dafür jenes Beratungsunternehmen zu beauftragen. umgesetzt und gelebt werden. was bereits umgesetzt ist. Dieser beinhaltet die interne Auditierung und entsprechende Korrekturmaßnahmen unmittelbar vor der Zertifizierung sowie den eigentlichen Zertifizierungsaudit und die weitere Vorgehensweise im Anschluss daran. kann der Zertifizierungsprozess eingeleitet werden. Das interne Audit dauert normalerweise zwei bis drei Tage [Boc06. um noch rechtzeitig entsprechende Maßnahmen einleiten zu können.4 Zertifizierungsprozess Sind die Anforderungen des Standards ISO/IEC 20000 umgesetzt. bei dem erforderliche Korrekturen identifiziert werden sollen. Der Prozess wird in Abbildung 2.

um die Unabhängigkeit zu gewährleisten. des Assessments. Dabei ist zu beachten. Der Ablauf des Zertifizierungsaudits ähnelt dem des internen Audits bzw. beispielsweise durch die Teilnahme an einem ITIL-Foundation-Kurs [Boc06. Es empfiehlt sich. ob der Prozessmanager den Prozess auch wirklich versteht. 270f. Jährlich werden zudem Überwachungsaudits durchgeführt [SMF06. Spätestens einen Monat vor der Zertifizierung sind sämtliche erforderlichen Unterlagen bei der Zertifizierungsstelle einzureichen. S. S. Organisationen nach ISO/IEC 20000 zu zertifizieren [SMF06. Zum Abschluss trägt der Zertifizierer seine Erkenntnisse vor und gibt bekannt. 252f. 17f.]. Als Ergebnis erhält man einen Maßnahmenplan. Die Zertifizierungsstelle trifft dann anhand dieses Vorschlags und der Protokolle des Audits eine Entscheidung [Boc06.]. die Mitarbeiter durch Schulungen und Bewusstseinsbildung auf die Zertifizierung vorzubereiten.74 ITIL-Zertifizierung nach ISO/IEC 20000 Prozessaufzeichnungen und Dokumente werden überprüft. . die für eine erfolgreiche Zertifizierung zwingend erforderlich sind. Im Anschluss daran wird für jeden Prozess eine Befragung des zuständigen Prozessmanagers durchgeführt. Es sollte genügend Zeit eingeplant werden. was bis zur Zertifizierung noch umgesetzt werden muss. Es folgt ein Interview mit der IT-Führung hinsichtlich der Anforderungen an das Management-System und den kontinuierlichen Verbesserungsprozess.19f.]. Bei einem einführenden Gespräch mit allen Teilnehmern verschafft sich der Zertifizierer einen Überblick über die Aufgaben und Tätigkeiten und erklärt den Ablauf der Zertifizierung. Dies kann durch eine regelmäßige Erfassung und Überprüfung der für die Prozesse etablierten Kennzahlen sichergestellt werden [Boc06. 240f. Das Zertifikat hat eine Gültigkeit von drei Jahren. sind die Räumlichkeiten vorzubereiten und die Anwesenheit aller erforderlichen Personen ist sicherzustellen. Dieser Projekterfolg sollte durch professionelles Marketing bekannt gemacht werden.]. ob er der Zertifizierungsstelle die Ausstellung des Zertifikats vorschlägt. S. Der Zertifizierungsaudit wird durch eine offizielle Zertifizierungsstelle (Registered Certificated Body) durchgeführt. Die Unterlagen dazu sind bei der Zertifizierungsstelle anzufordern. In Deutschland zählt beispielsweise die TÜV SÜD Management Service GmbH zu den offiziellen Zertifizierungsstellen. bis zum Zertifizierungsaudit durchführen zu können [Boc06. Danach findet ein Wiederholungsaudit statt. S. Sobald der zeitliche Ablauf mit der Zertifizierungsstelle abgestimmt ist. Desweiteren wird er gesondert auf der Internetseite der Zertifizierungsstelle gelistet. Die Anmeldung zur Zertifizierung sollte mindestens vier Monate vor dem geplanten Termin erfolgen. dass Prüfungsunternehmen keine Beratungsleistungen anbieten dürfen. S. und zum anderen wird die Umsetzung aller Anforderungen des Standards ISO/IEC 20000 überprüft. Die Mitgliedsländer der International Organization for Standardization (ISO) verfügen über nationale Akkreditierungsstellen. Dabei wird zum einen kontrolliert.]. dass die Prozesse im Unternehmen auch gelebt werden und eine kontinuierliche Weiterentwicklung und Verbesserung nach dem KVP-Ansatz erfolgt. Insofern ist nach der Zertifizierung besonders wichtig. die geprüften Zertifizierungsstellen das Recht übertragen. 239]. das offizielle Zertifizierungslogo zu verwenden. um die Korrekturmaßnahmen. Es müssen Angaben zum Unternehmen und dem zu zertifizierenden Bereich gemacht werden und es ist ein Termin aus den Vorschlägen der Zertifizierungsstelle auszuwählen. und er ist ermächtigt. Bei erfolgreicher Zertifizierung erhält der IT-Service-Provider das Zertifikat. S.

Allerdings ist bis zum Erhalt des Zertifikats ein langer Weg zurückzulegen. dass seine IT-Dienstleistungen eine hohe Qualität besitzen. Dies gilt insbesondere für Unternehmen. Und da das Zertifikat nur eine begrenzte Gültigkeit besitzt. Voraussetzung für die Zertifizierung ist allerdings. Der Standard ISO/IEC 20000 stellt hohe Anforderungen an Unternehmen und Prozesse. Die Umsetzung der Anforderungen des Standards ISO/IEC 20000 führt dazu. das Change-Management oder das ConfigurationManagement. Dies gilt auch für Unternehmen.]. dass die IT-Dienstleistungen effizient gesteuert werden und den Kundenbedürfnissen angepasst sind. wie zum Beispiel das Incident-Management. Wenn sich ein Unternehmen an die Vorgaben des Standards ISO/IEC 20000 hält. Eine Vielzahl von Unternehmen beschränkt sich bei der Einführung von ITIL auf nur wenige Prozesse. stellt der Standard ISO/IEC 20000 eine wertvolle Informationsquelle und Leitlinie dar. Durch Effizienzsteigerungen können die Kosten für die eingesetzten Systeme reduziert werden. Es ist ein großer Aufwand zu betreiben. den Zielen und Strategien sowie von ihrer eigenen Rolle im Unternehmen entwickeln. dass die IT-Mitarbeiter durch die intensive Beschäftigung mit dem Thema ein besseres Verständnis von den Prozessen. S. Die unabhängige Beurteilung des Reifegrads der Prozesse und des Service Managements bildet eine Orientierungshilfe und die Grundlage für den kontinuierlichen Verbesserungsprozess [Boc06. kann es sicher sein. die Servicequalität regelmäßig zu überprüfen und ständig weiterzuentwickeln. 269]. S. Zu nennen ist das SarbanesOxley-Gesetz und das HIPAA-Gesetz (Health Insurance Portability and Accountability Act) von 1996 aus den USA. Besonders auf das IT Service Management und die IT-Services beziehen sich viele der Vorschriften. Auch für Unternehmen. Es bilden sich eine gemeinsame Sprache und ein einheitlicher Kenntnisstand von den Prozessabläufen. um die Reputation am Markt zu erhöhen und damit die Wettbewerbsfähigkeit zu steigern. Zum Nachweis der Einhaltung dieser Vorschriften fordern Wirtschaftsprüfer bislang keine Zertifizierung für bestimm- . die zunächst keine Zertifizierung anstreben. Aktionären. 268f. wie sich in den vorangegangenen Kapiteln gezeigt hat. Firmenintern hat die Zertifizierung zur Folge. dass alle vorgegebenen Prozesse im Unternehmen umgesetzt sind. um dieses Ziel zu erreichen. Gegenüber Kunden.4 Beurteilung der Zertifizierung Der IT-Service spielt bei der Kundenbetreuung eine wichtige Rolle. Mitarbeitern und öffentlichen Einrichtungen wird eine breite Vertrauensbasis geschaffen. Unternehmen müssen die Einhaltung einer Vielzahl behördlicher Vorschriften und Regelungen nachweisen. die ITIL-erfahren sind. Das Zertifikat kann als Marketing-Instrument verwendet werden. Mit der Zertifizierung nach ISO/IEC 20000 durch eine offizielle unabhängige Zertifizierungsstelle kann somit eine hohe Servicequalität objektiv nachgewiesen und den Kunden gegenüber belegt werden. Der im Standard beschriebene kontinuierliche Verbesserungsprozess bietet die Möglichkeit. Aufgrund der Aktualität der Thematik gilt ein zertifiziertes Unternehmen zudem als besonders innovativ [Boc06. die das Outsourcing und die Verwaltung und von IT-Services anbieten. Kreditgebern.Eine Darstellung des Standards und des Zertifizierungsprozesses 75 2. die ihr Handeln und Vorgehen auf die ITIL-Prinzipien abgestimmt haben und sich bei der Implementierung der Prozesse des IT Service Managements auf die ITIL-Richtlinien berufen. fallen auch langfristig Aufwände an. Das ist insbesondere für Unternehmen relevant.

Vor der Zertifizierung wird ein interner Audit durchgeführt.5 Fazit Die Zertifizierung nach dem Standard ISO/IEC 20000 bietet IT-Dienstleistern die Möglichkeit. kann der Zertifizierungsaudit durchgeführt werden. die sich aufgrund einer Kosten-Nutzen-Analyse gegen die Zertifizierung und den damit verbundenen Wettbewerbsvorteil entscheiden. Aufgrund seines Bezugs zur Qualität des IT Service Managements bietet sich der Standard ISO/IEC 20000 als internationaler Standard zur Überprüfung der Einhaltung behördlicher Vorschriften im Rahmen von Wirtschaftsprüfungen an [BMC06. Erfüllt der IT-Service-Anbieter sämtliche Voraussetzungen. das Information-Security-Management. Es sind neben den auf ITIL basierenden Prozessen das Management-System. ob die Anforderungen des Standards ISO/IEC 20000 verstanden. Bei der Auftragsvergabe im IT-Sektor wird eine Zertifizierung nach ISO/IEC 20000 zunehmend zur zwingenden Voraussetzung. Ein offizielles Prüfsiegel nach international anerkannten Standards ist wohl der beste Qualitätsnachweis gegenüber den Kunden. das Service Reporting. Die Entscheidung für eine Zertifizierung nach ISO/IEC 20000 sollte auf der Grundlage einer Standortbestimmung des IT-Bereiches und eines dabei erarbeiteten Maßnahmenplanes mit notwendigen Korrekturen getroffen werden. die den Kundenbedürfnissen entsprechen. um letzte erforderliche Anpassungen zu identifizieren. das Business-Relationship-Management sowie das Lieferanten-Management umzusetzen. Der Code of Practice des Standards stellt Leitlinien und Empfehlungen zur Umsetzung der Anforderungen zur Verfügung. Dabei wird überprüft. Abweichungen von diesen Erläuterungen der Best Practices sind erlaubt. Unternehmen. wird dadurch die Wettbewerbsfähigkeit gesteigert. Der in der Arbeit dargestellte Fragenkatalog dient als Hilfestellung bei der Prozessumsetzung.76 ITIL-Zertifizierung nach ISO/IEC 20000 te Standards und Normen. Die Zertifizierung nach ISO/IEC 20000 wird sich für viele IT-Service-Anbieter trotz des hohen Aufwands lohnen. Daneben erhöht sich die Reputation des Unternehmens am Markt. so dass das IT Service Management individuell ausgestaltet werden kann. Die vorliegende Arbeit bezieht sich primär auf das Buch „ITIL Zertifizierung . Die praktische Umsetzung der Anforderungen ist abhängig von den gegebenen Rahmenbedingungen sowie der Unternehmensstrategie und den Zielen. bringt die Umsetzung des Standards eine Reihe von Vorteilen mit sich. Durch eine erfolgreiche Zertifizierung wird nachgewiesen. Trotz des hohen Aufwands wird sich daher für viele IT-Service-Anbieter die Zertifizierung nach ISO/IEC 20000 lohnen. die Planung und Implementierung des Service-Managements. umgesetzt und gelebt werden. dass effiziente ITServices angeboten werden. wird ein Zertifikat ausgestellt. 2. Der Standard definiert verbindliche Vorgaben für das IT Service Management. S. die Konformität mit dem ITIL Rahmenwerk objektiv zu belegen. können den Standard in Ergänzung zu ITIL als Leitlinie zur Verbesserung ihrer IT-Services nutzen [ISM06]. 5]. Und auch für Unternehmen. Dies erfolgt durch eine offizielle Zertifizierungsstelle in Form von Interviews. die für eine Zertifizierung vollständig umgesetzt werden müssen. Da in der Geschäftspraxis dieser Nachweis der Servicequalität zunehmend vorausgesetzt wird. Sind die Korrekturmaßnahmen umgesetzt. die keine Zertifizierung anstreben.

R. 1. Zeewolde / Niederlande 2008. Auflage.The Roadmap. 1. Dohle. • ISO 20000 . Symposion Publishing. Dpunkt Verlag. 2008. Düsseldorf 2008. H. 1. Auflage. • ISO/IEC 20000 .. Günter Macek. dass zum Zeitpunkt der Erstellung der Arbeit noch keine weitere einschlägige Literatur zur Verfügung stand. Andenmatten. Zeewolde / Niederlande 2008.An Introduction. itSMF. / Schmidt. Van Haren Publishing. deren Veröffentlichung noch aussteht: • ISO 20000 .. Van Haren Publishing.Praxishandbuch für Servicemanagement und IT-Governance. Für Interessierte an weiterer Literatur sind wir bei unserer Recherche auf folgende Bücher gestoßen.Eine Darstellung des Standards und des Zertifizierungsprozesses 77 nach BS 15000/ISO 20000“ von den Autoren Wolfgang Bock. . Thomas Oberndorfer und Robert Pumsenberger und auf den Standard ISO/IEC 20000 selbst.Eine Einführung für Manager und Projektleiter. M. Auflage. itSMF. • Implementing ISO/IEC 20000 Certification . Dies liegt daran.

78 ITIL-Zertifizierung nach ISO/IEC 20000 .

Galileo Computing.com/products/ documents/49/66/64966/64966.01. W.gartner.pdf [21. T.08].com [15.competence-site. http://documents.Auflage. 1. [Spe05] International Organization for Standardization / International Electrotechnical Commission: ISO/IEC 20000-1: Specification. [SMF06] The IT Service Management Forum: ISO/IEC 20000 .: ITIL Zertifizierung nach BS 15000 / ISO 20000.Das Taschenbuch.01. Van Haren Publishing. Auflage. R. 79 . 1.nsf/5438155EE69CF678C125728B0042967B/$File/ it-service-management_iso_20000. Auflage. URL: www. / Pumsenberger.bmc.pdf [21. Auflage.01. [Cod05] International Organization for Standardization / International Electrotechnical Commission: ISO/IEC 20000-2: Code of practice.de/ itmanagement. Zeewolde / Niederlande 2006. [ISM06] Competence Site. Geneva / Schweiz 2005. Geneva / Schweiz 2005. [Boc06] Bock. [Gar06] Marktforschungsunternehmen Gartner. / Macek. 1. / Oberndorfer.08].08]. Bonn 2006. URL: http://www. G.Literaturverzeichnis [BMC06] BMC Software. 1.

80 ITIL-Zertifizierung nach ISO/IEC 20000 .

Während in Zeiten immer größere Vernetzung die Komplexität und Abhängigkeit von der IT stetig wächst. zu restrukturieren. Der momentane Trend geht dazu. bedeutete nicht.und Kommunikationstechnik (IT). Im gleichen Maße gilt dies für Prozesse der Informations. Tim Kattner 3. Die Bedrohungen sind vielfältiger Art und reichen von Wirtschaftsspionen und Hackern über Viren bis hin zu eigenen Anwendern. Dies bietet einerseits die Möglichkeit Informationssicherheit vorteilhafter in die ITProzesse zu integrieren und andererseits eine bessere Arbeitsverteilung zwischen IT-Bereich und Security Management zu ermöglichen.Kapitel 3 ITIL und IT-Sicherheit Synergien zwischen Security Management und Service Support nutzen Björn Borgmeier. sofern sie die Produktivität der Geschäftsprozesse erhöhen oder einen Wettbewerbsvorteil generieren.1 Einleitung Sicherheit und Schutz sind Grundbedürfnisse der Menschheit. Zudem bietet es die Chance das Thema Sicherheit stärker in den Fokus zu rücken und diesbezüglich die 81 . Trotz dieser Entwicklung herrscht in vielen Fällen eine weit verbreitete Fehleinschätzung über den eigenen Schutzbedarf bei den Unternehmen. Michael Bochenek. Im Zuge sinkender IT-Budgets werden Maßnahmen nur noch implementiert. 6] Unternehmen suchen oftmals nach praxisbewährten Lösungen. dass in der Vergangenheit keine Sicherheitsvorfälle erkannt wurden. dass keine Vorlagen oder die Sicherheitsmaßnahmen ausreichend sind. S. sondern ein dynamischer Prozess. nehmen ebenso Gefahren und Risiken für Informationstechnologien zu. Bedingt durch die gestiegene Verwundbarkeit und Gefahr wirtschaftlicher Schäden haben sowohl Handlungsdruck als auch Anforderungen an ein effizientes IT-Security Management zugenommen. IT-Prozesse gemäß ITIL neu zu entwickeln bzw.[Bsi07. die erfolgreich implementiert worden sind und einen Großteil des Aufgabenspektrums abdecken. Security Management ist kein statischer Zustand. Die Tatsache alleine. Eine solche Best Practice Lösung ist ITIL.

[Bsi05. dafür Sorge zu tragen [Köh06. 3. unbefugte Veränderung der Funktionalität und unbefugte Modifikation. Die vorliegende Arbeit gliedert sich dabei in vier Kapitel.1 Informationssicherheit Oftmals sind es bestimmte Informationen oder fachspezifisches Know-how. 2 AktG) nicht mehr nur Aufgabe der IT-Abteilung ist. sondern auch die Unternehmensleitung gesetzlich verpflichtet ist. S. wird zunächst der Begriff Informationssicherheit definiert und die einzelnen Dimensionen der Informationssicherheit vorgestellt. einen kurzen Überblick über das Thema IT-Sicherheit zu liefern. Nachdem Ziele und Aufgaben des Security Managements präsentiert werden. Vertraulichkeit und Integrität gekennzeichnet ist. welche durch die drei Dimensionen Verfügbarkeit. welches exemplarisch am Beispiel des Service Supports. findet das Kapitel seinen Abschluss mit einer Einordnung des Security Managements in ITIL. 347] Es handelt sich bei diesen Bedrohungen um unbefugten Informationsgewinn. Vorwort des Verfassers] Aus diesem Grund kommt der Sicherung und dem Schutz dieser Informationen und deren Systemen eine hohe Bedeutung zu. Hier werden die einzelnen Prozesse des Service Supports kurz vorgestellt und anschließend die sich bietenden Synergieeffekte mit dem Security Management aufgezeigt. Unbefugter Informationsgewinn geht einher mit dem Verlust der Vertraulichkeit. Hierbei stehen nicht die konkreten Maßnahmen des Security Managements im Vordergrund. Nach der Einleitung folgt ein Grundlagenkapitel. sofern es den drei Grundbedrohungen jeder Informationsverarbeitung Stand hält.[Bru06. das den Unternehmen auf den hart umkämpften Märkten einen Wettbewerbsvorteil gegenüber ihren Konkurrenten verschafft. aber vor allem sollen die positiven Effekte des Zusammenwirkens von IT-Security und IT-Service Management aufgezeigt werden. Ziel dieser Arbeit soll es zum einen sein.[Die04. 346] geprägt.2. der operativen Ebene beschrieben wird. Da die IT-Sicherheit unter anderem bedingt durch das Gesetz zur Kontrolle und Transparenz im Unternehmensbereich (§ 91 Abs. Um eine Diskussionsgrundlage für die weiteren Kapitel zu schaffen. werden zusätzlich gesetzliche Anforderungen und Vorschriften an die Informationssicherheit und den Datenschutz vorgestellt. sondern ein prozessorientiertes Vorgehen. S. Einen Abschluss findet die Arbeit in einem kurzen Fazit und der Zusammenfassung der gewonnenen Erkenntnisse.2 Grundlagen des IT-Security Management Das nachfolgende Kapitel stellt eine Einführung in den Bereich des Security Managements dar. Ein IT-System gilt als sicher. 12].82 ITIL und IT-Sicherheit Akzeptanz seitens der Unternehmensleitung zu erhöhen. Vertraulichkeit. . indem die für den weiteren Verlauf notwendigen Begrifflichkeiten des Security Managements erörtert werden. Das dritte Kapitel stellt den Hauptteil der Arbeit dar. Der Begriff IT-Informationssicherheit ist stark durch die Sicht der Verlässlichkeit [Die04. S. Geraten wichtige Informationen in die falschen Hände. 3. 204]. S.

Auch in diesem Fall sind eine restriktive Vergabe der Nutzungsrechte und Zugangskontrollen Alternativen. MalWare1 tut. E-Commerce. Das Security 1 Als Malware bezeichnet man Computerprogramme. Löschen von Daten durch unbefugte Personen. etc. Um diesem Datendiebstahl/ -missbrauch entgegen zu wirken. die zusammen die Sicht der Beherrschbarkeit bilden. Neben der Verlässlichkeit schützenswerter Informationen hat in der jüngeren Vergangenheit auch deren Beherrschbarkeit mehr und mehr an Bedeutung gewonnen. angefangen bei der Nutzung sicherer Informationskanäle über Verschlüsselungsalgorithmen bis hin zur Schaffung von Zugangsbarrieren (Passwörter. Integrität. gibt es diverse Möglichkeiten.[Bsi07.) oder die Verschärfung der Zugangsrestriktionen für Unbefugte sind zwei von mehreren Optionen. so sind Zurechenbarkeit sowie Rechtsverbindlichkeit gewährleistet. wenn Informationen unbewusst falsch verarbeitet oder verfälscht werden.[Köh06. Verfügbarkeit. 208] Ebenso ist denkbar. etc. Es handelt sich hierbei um Zurechenbarkeit und Rechtsverbindlichkeit/Revisionsfähigkeit. Stabilität. Die fünf vorgestellten Dimensionen der Informationssicherheit (Vertraulichkeit. Vertraulichkeit und Verfügbarkeit) deshalb um zwei Dimensionen zu erweitern. wenn die Funktionalität unbefugt oder durch technisches Versagen gestört wird. vor. welche vom Benutzer unerwünschte und ggf.Synergien zwischen Security Management und Service Support nutzen 83 kann dieses schwerwiegende wirtschaftliche Schäden nach sich ziehen. etc. Obendrein sollte in diesem Zusammenhang nach dem sogenannten „Need-toknow-Prinzip“ verfahren werden. Im Zeitalter des Internets und der damit verbundenen Nutzung für Rechtsgeschäfte (Online-Banking. sondern die Sicherheit der Betroffenen (Schutz vor dem System) im Vordergrund.. Flexibilität oder Beobachtbarkeit. beweisbar. S. so tritt eine Beeinträchtigung oder der Verlust der Integrität ein. modifiziert.). Die Etablierung redundanter Einheiten (Backup Server. geht verloren. 14] Verfügbarkeit. Ein solcher Verlust der Integrität liegt bspw. 249] Ist es möglich Daten oder Vorgänge einem Verursacher oder eine auslösende Instanz eindeutig zu zuordnen und sind diese darüber hinaus von unabhängigen Personen oder Instanzen nachvollziehbar bzw.[Die04. wie es bspw. . um diesem entgegen zu treten. um die Vollständigkeit. PIN. S. Integrität. die er für seine tägliche Arbeit benötigt. Sabotage der Verarbeitungsprozesse und Zerstörung bzw. Werden sensible Daten. Programme oder Geräte unerlaubt verändert bzw. Dabei steht nicht die technische Sicht (Sicherheit der Systeme). Wartbarkeit. schädliche Funktionen ausführen. Mögliche Indikatoren für eine solche gestörte Verfügbarkeit sind der Ausfall der Informationsverarbeitung. dass bewusste Veränderungen an Informationen vorgenommen wurden. nach dem jeder Benutzer (auch der Administrator) lediglich die Berechtigungen (Zugriffe auf Datenbestände und Programme) erhält. Korrektheit und Unverfälschtheit der Informationen zu gewährleisten.) sind die bereits vorgestellten Hauptmerkmale der Informationssicherheit (Integrität. Die Verfügbarkeit eines DV-Systems ist gefährdet bzw. Zurechenbarkeit und Rechtsverbindlichkeit)2 können auch als Qualitätsmerkmale eines IT-Systems verstanden werden. wie etwa Robustheit. S. 2 Neben diesen fünf Dimensionen wurden in der letzen Zeit eine Reihe weiterer möglicher Dimensionen diskutiert.

In Verbindung mit anderen gilt dies insbesondere für das Gesetz zur Kontrolle und Transparenz in Unternehmensbereichen (KonTraG). Es gibt eine Reihe von Rechtsvorschriften. damit gefährdende Entwicklungen früh erkannt werden. Risiken und Risikostruktur des Unternehmens im Lagebericht des Jahresabschlusses der Gesellschaft zu veröffentlichen.[Bru06. ergänzt. Dabei darf jedoch nicht außer Acht gelassen werden. um den Fortbestand der Unternehmung zu gewährleisten. 4 HGB) Des Weiteren verpflichtet § 317 Abs. S.2. 2 des Aktiengesetzes hat der Vorstand einer Aktiengesellschaft geeignete Maßnahmen zu ergreifen. 210] Um dies zu gewährleisten. 2 HGB Abschlussprüfer zu prüfen. S. Damit liegt der Wirkungskreis des Datenschutzes in der Sicherstellung der informellen Selbstbestimmung des Einzelnen. welches verschiedene Gesetze wie das HGB oder AktG ändert bzw. Während bei der Datensicherheit die Gewährleistung der Verfügbarkeit.(§ 93 Abs. wie Ärzte. eingegangen werden. gibt es im Strafgesetzbuch Sonderregelungen.84 ITIL und IT-Sicherheit Management sollte bestrebt sein. ein unternehmensweites Früherkennungssystem für Risiken (Risikomanagement) einzuführen und zu betreiben sowie Aussagen bzgl. welche die verantwortlichen Personen einer Unternehmung zur Rechenschaft ziehen. 2 AktG) Der Geltungsbereich dieser Vorschriften erstreckt sich auch auf das HGB. 9] 3.(§ 317 Abs. diese Qualitätsmerkmale entsprechend der jeweiligen Anforderungen zu gewichten und anhand definierter Kriterien auf allen Unternehmensebenen umzusetzen. Für bestimmte Berufsgruppen. dass der Aufwand für die Implementierung im Verhältnis zum Nutzen stehen muss. wonach für die Geschäftsführung die „Sorgfalt eines ordentlichen Geschäftsmannes“ gilt. Dieses Gesetz ist ein sogenanntes Artikelgesetz. sondern es bestehen mittlerweile auch gesetzliche Regelungen. Kommt der Vorstand dieser Forderung nicht nach. ist das Ziel des Datenschutzes die freie Entfaltung der Persönlichkeit. Aus diesem Grund soll in diesem Abschnitt kurz auf die gesetzlichen Anforderungen und Vorschriften an die IT-Sicherheit sowie Standards. ist der Paragraph 43 Abs. Verwendung und Weitergabe seiner persönlichen Daten sichergestellt sein. so haftet er persönlich. muss ein Schutz des Einzelnen vor Erhebung. Kern des KonTraG ist eine Vorschrift. Gemäß § 91 Abs. Anwälte oder Angehörige sozialer Berufe.und Haftungsverpflichtungen für die Unternehmung (vor allem für die Geschäftsleitung) ableiten lassen. Speicherung.2 Gesetzesanforderungen. ob die Risiken auch zutreffend dargestellt werden. Dies umfasst ebenfalls IT-Risiken. welche das IT-Security Management betreffen. 1 des GmbHG. die sogar Freiheitsstrafen vorsehen.[Köh06. aus denen sich Handlungs. insbesondere ein Überwachungssystem einzurichten. welche betroffen sein kann. Eine weitere Regelung. Vertraulichkeit und Integrität von Daten im Vordergrund steht. Vorschriften und Standards Ein IT-Sicherheitsvorfall kann nicht nur wirtschaftliche Schäden nach sich ziehen. die die Unternehmensleitungen von Kapitalgesellschaften dazu zwingt. wenn es aufgrund eines nicht angemessenen IT-Sicherheitsniveaus zu wirtschaftlichen Schäden kommt. wenn vertrauliche Daten ihrer Patienten oder Klienten ohne deren . Der Umgang mit personenbezogenen Daten wird in den Datenschutzgesetzen des Bundes und der Länder geregelt.

in denen die IT-Infrastruktur hinter sicheren Mauern vor den Blicken der Umwelt geschützt war und einige wenige Sicherheitsmaßnahmen genügten. wie z.“[Vog02. um die Datensicherheit zu gewährleisten. ebenfalls herausgegeben vom BSI. Dabei werden Anforderungen an ein dokumentiertes Informationssicherheits-Managementsystem im Hinblick auf Implementierung. sind längst vorbei. woraufhin das Bundesamt für Sicherheit in der Informationstechnik (BSI) das IT-Grundschutzhandbuch herausgab und später zu den IT-Grundschutzkatalogen weiter entwickelte. Diese können dann mit den Security Baselines verglichen werden. 3. ITSecurity Management und Organisation darstellen. auf Basis dessen im späteren Verlauf der ISO/IEC 17799:2005 entwickelt wurde.3 Bereits einen fahrlässiger Umgang mit der Informationstechnik (z. Auch in Deutschland hat man sich dieser Thematik angenommen. B. In der heutigen Zeit wird das Grundschutzhandbuch nicht nur in Behörden angewandt. die oben angesprochenen gesetzlichen Vorgaben zu erfüllen.Synergien zwischen Security Management und Service Support nutzen 85 Zustimmung an die Öffentlichkeit gelangen. 213] Der große Vorteil der ISO-Standards ist die internationale Akzeptanz und damit besonders für global agierende Unternehmen von Bedeutung. weist ihm Gefährdungen zu und leitet daraus Maßnahmen ab. Dabei beschreibt das IT-Grundschutzhandbuch die Vorgehensweise von der Erstellung eines Sicherheitsprozesses über die Implementierung bis hin zur Definition der konkreten Aufgaben. deren Ziel es ist. durch unsichere Passwörter oder ungeeignete Verschlüsselungsalgorithmen) kann unter Umständen diesen Tatbestand erfüllen. die so genannte Schweigepflicht . die übergeordnete Prozesse und Verfahren. S. S. 270] Die Anforderungen an das Security 3§ 203 StGB. Diese enthalten Gefährdungs.[Bru06. Einer der ersten dieser Art war der britische Standard BS 7799. Weiterhin werden sogenannte Bausteine beschrieben. die helfen sollen. Erhaltung. Wartung und Überwachung detailliert dargestellt. Genau wie die Urfassung des britischen Standards beruht der ISO/IEC 17799 auf einem Best Practice Ansatz. Verbesserung. In kompakter Form werden eine Zusammenfassung der wichtigsten Sicherheitsmaßnahmen sowie Praxisbeispiele und Checklisten geliefert. die durch den ISO/IEC 17799 detailliert beschrieben werden. „Sicherheit ist heute mehr als das Abschlie[ß]en von Serverräumen und die peinlich genaue Beachtung von Passwortregeln. In seiner aktuellsten Version wurde es mit dem ISO/IEC 27001:2005 kompatibel gemacht. welcher die Aufstellung von Maßnahmen umfasst. B. Jeder Baustein beschreibt ein Szenario.2.3 Ziele und Aufgaben des IT-Security Management Die Zeiten. Eine weniger detaillierte Darstellung liefert der Leitfaden zur IT-Sicherheit. Neben den Gesetzesanforderungen und Vorschriften gibt es zugleich diverse Standards (BS/ISO). die Informationssicherheit zu gewährleisten.und Maßnahmekataloge. die Notfallplanung. auch die Wirtschaft fragt dieses immer stärker nach. Der ISO/IEC 27001:2005 dagegen beschreibt den Aufbau eines Information Security Management Systems (ISMS) und referenziert im Anhang auf die Maßnahmen. die Arbeit des Security Managements sinnvoll zu strukturieren. welche das IT-Security Management thematisieren und es unter anderem ermöglichen sollen.

zwischen Datenschutz.und Sicherheitsbeauftragten. Für die konkrete Ausgestaltung der Sicherheitsrichtlinien liefert bspw. 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. liegt es im Interesse des Sicherheitsbeauftragten diese Informationen möglichst detailliert zu erfassen. wie etwa Hackerangriffen. 4 Englischer Begriff für IT-Sicherheitspolitik . erheblich zugenommen.86 ITIL und IT-Sicherheit Management haben in unserer heutigen hochtechnisierten und auf den eigenen Vorteil ausgerichteten Welt. S. In der Regel umfasst die Security Policy folgende Aspekte: ([Köh06. Dennoch sollte sie dabei nicht mit den Unternehmenszielen konfligieren. bspw. um einem Missbrauch vorzubeugen oder für den Fall eines Missbrauchs die Nachvollziehbarkeit zu ermöglichen. Security Policy. Zudem ist bei der Erstellung mit dem Auftreten von Interessenskonflikten zwischen den jeweiligen Prozessverantwortlichen zu rechnen. sind zunächst die Anforderungen an die jeweiligen Prozesse zu ermitteln und in Form konkreter Sicherheitsziele zu definieren. 203] Aus diesem Grund sollen im Folgenden Anforderungen. Elementarer Baustein innerhalb des Security Managements ist in diesem Zusammenhang die Security Policy 4 . [Köh06. Ziele und Maßnahmen des Security Managements vorgestellt werden. Mit ihr wird die Basis für ein effizientes und funktionierendes Security Management gelegt. Bevor Maßnahmen zum Schutz der IT-Infrastruktur vor potenziellen Bedrohungen. S.[Köh06. Ferner werden auch Sicherheitsrichtlinien in der Policy definiert und festgehalten. Viren oder Datendiebstahl ergriffen werden können. Beide vertreten unterschiedliche Auffassungen im Hinblick auf die Protokollierung persönlicher Zugriffe von Mitarbeitern. das IT-Grundschutzhandbuch des BSI geeignete Anhaltspunkte. S. Neben den langfristigen Sicherheitszielen beinhaltet sie die Personalverantwortlichkeiten und Sicherheitsstufen für die jeweiligen Prozesse und Daten eines Unternehmens. 210]) • Sicherheitsziele • Zweck und Geltungsbereich • Personalzuständigkeit und Rolle • Aufgaben. 210] Während der Datenschutzbeauftragte den Schutz personenbezogener Daten als Ziel verfolgt.

Aufgaben und Aktivitäten des Security Management. Verfügbarkeit und Integrität vor potenziellen Bedrohungen soll dabei auf effiziente und ressourcenschonende Weise erfolgen (Wirtschaftlichkeit). Neben der Behebung von Sicherheitsvorfällen reicht das Aufgabenspektrum dabei von der Auswahl adäquater Firewalls.6 Zielsetzung in diesem Kontext ist es. 270] Daher verfolgt das IT-Security Management als primäres Ziel. Für den reibungslosen Ablauf bzw. Bei Risikoanalysen werden Betriebsmittel auf Schwachstellen und potentielle Bedrohung untersucht und diesbezüglich Bewertungen vorgenommen. S. Geschäftsleitung Security Policy IT-SicherheitsManagement Informations und Prozesssicherheitsstandards Fachbereiche Datensicherheit Sicherheitsadministrator System. den durch die definierten Ziele vorgegebenen Sicherheitsgrad zu erreichen bzw. Neben der Datensicherheit stehen auch Aspekte des Datenschutzes im Fokus des Security Managements. Der Schutz der Vertraulichkeit. die Informationssicherheit5 von Daten und Prozessen gemäß ihrer Bedeutung für die Unternehmung zu gewährleisten. Zu den Maßnahmen des Security Managements zählen alle Vorkehrungen. das Funktionieren eines Unternehmens sind aktuelle und fehlerfreie sowie konsistente Informationen unerlässlich.Synergien zwischen Security Management und Service Support nutzen 87 Ziele. Die Risikobewertung richtet sich einerseits nach dem Schadenspotenzial und zum anderen nach der Bedeutung für das Unternehmen.1 IT-Informationssicherheit dazu ausführlicher Kapitel 3. die geeignet sind. [Vog02. Maßgeblich ist in diesem Zusammenhang das gesetzliche Rahmenwerk.2. dass die Ressourcen des Security Management optimal verteilt werden können. Gefahren und Auswirkungen für Geschäftsprozesse frühzeitig zu identifizieren und rechzeitig präventive 5 siehe 6 siehe dazu ausführlicher Kapitel 3. Eine solche Einstufung in Risikoklassen (Klassifizierung) hat den Vorteil. die gesetzlichen Auflagen einzuhalten. Vorschriften und Standards .2 Gesetzesanforderungen. Quelle: [Köh06. 216]. Letztlich bietet eine Risikoanalyse die Möglichkeit.und Netzwerksicherheit Mitarbeiter im Produktionsprozess Sicherheitsbewusstsein und Sicherheitskompetenz Abbildung 3. Anti-Viren.1: Sicherheitsziele nach Hierarchieebenen.und Anti-Malware-Programmen über die Schulung des Sicherheitsbewusstseins der Mitarbeiter bis hin zu Risikoanalysen. S.2. aufrecht zu halten.

3. dass die IT-Sicherheit kein statischer Zustand ist. Um solchen Anforderungen gerecht zu werden. Security Audits.Sicherheit. Dynamische Geschäftsprozesse und der steigende Informationsbedarf sind Auslöser zur Neustrukturierung und stellen ein Unternehmen vor Probleme in Bezug auf deren Umsetzung. . Verbesserung der Prozesse Act Plan Do Bedrohungsanalysen. Externe Überprüfung Check Do Abbildung 3. Auswahl geeigneter Software/ Tools zum Schutz vor Viren. Priorisierung.4 Einordnung von Informationssicherheit und Security Management in ITIL Heutzutage sind Unternehmen und Organisationen zunehmend dem Druck ausgesetzt. Service Level Agreement. sondern ein dynamischer Prozess. führt kein Weg an Standardisierung vorbei.[Bsi07.88 ITIL und IT-Sicherheit Maßnahmen einzuleiten. Operational Level Agreement Act Notwendige Änderungen herbeiführen. S. Dokumentation von Sicherheitsvorfällen Report Plan Security Policy. etc. ob die eingeführten Sicherheitsmaßnahmen eingehalten werden Die nachfolgende Abbildung dient abschließend dazu.2: Erweiterter PDCA-Zyklus des Security Management Prozesses. wodurch 7 Security Audits sind regelmäßige Prüfungen des Softwarebestands und gleichzeitiger Abgleich mit Securitylisten. S. Sicherheitsbewusstsein schulen/fördern. ihre IT-Prozesse zu überarbeiten und zu verbessern. wodurch Gefahren frühzeitig erkannt werden können. 6] Report ManagementReport zu IT. 28] Weitere wichtige Aufgaben des Security Management sind: • Durchführung von Security Audits7 • Erstellen von Management Reports zur IT-Sicherheit • Überprüfen.2. MalWare. Nicht zuletzt trägt der technologische Fortschritt in der Informationsübertragung und -verarbeitung zusätzlich dazu bei. Interne u.Risiken und IT. den Prozess des Security Managements zu veranschaulichen und verdeutlicht. Würmern.[Bru06. Check Einhaltung der Security Policy überprüfen.

Diese Ebene steht in direktem Kontakt mit Anwendern und verwaltet alle Wünsche. zählen hierzu beispielsweise Datenschutz. welche in der Security Policy zusammengefasst werden. Finanzierung und Kontrollfunktion sind weitere Aufgaben. Auch dieser Problematik hat sich ITIL angenommen und versucht ein Leitfaden für den sicheren Umgang mit Informationen im Service Management zu sein. Die ITIL hat sich dieser Thematik angenommen und dient als Orientierung für eine solche Prozessstandardisierung. die strategische Ebene dar. Auf ihr werden alle Prozesse des Service Delivery zusammengefasst. Strategische Ebene.Synergien zwischen Security Management und Service Support nutzen 89 nicht nur versucht wird Geschäftsprozesse und Verhaltensweisen. Ebenfalls auf dieser Ebene anzusiedeln. Strategische Ausrichtung. . dritten Version (V3) kein eigenes Buch gewidmet. ergeben sich viele Chancen für einen effizienten Umgang mit sicherheitsrelevanten Ereignissen. Als „IT-Infrastructure Library“ hat sich dieses Rahmenwerk als Instrument zur Planung und Umsetzung etabliert. Diese Vereinbarungen. Hier tritt der Kunde als Auftraggeber der Leistungen auf und kann über seinen Bedarf die Serviceangebote der IT-Abteilung beeinflussen. welches sich dieser Thematik widmet und versucht eine Verbindung zwischen Sicherheitsanforderungen und Geschäftsprozessen zu schaffen. ITIL unterteilt deswegen seine Prozesse in drei Ebenen. Aus den. Das Service Level Management bestimmt die Anforderungen an das Service Delivery. Auf ihr wird entschieden. Eines davon ist das Buch „Security Management“. gesetzliche Bestimmungen oder Sicherheitsstufen. sondern auch serviceorientiertes Management aneinander anzupassen. Ein oft vernachlässigter Bereich ist in diesem Zusammenhang das Thema Informationssicherheit. Gegebenenfalls wird zusätzlich ein Security Officer ernannt. Die operative Ebene ist für die konkrete Umsetzung dieser Ziele verantwortlich und beinhaltet die Prozesse des Service Supports. Wie im vorigen Kapitel bereits erläutert. Operative Ebene. Zudem sollte die von dem Security Management erarbeitete Security Policy an die Geschäftsleitung herangetragen werden. bilden das Service Level Agreement (SLA). Die zweite Ebene wird auch taktische Ebene genannt und dient der Qualität der Services. Informationssicherheit betrifft alle Personen und Bereiche innerhalb einer Organisation. In der Version V2 umfasst das komplette ITIL-Paket sieben Bücher. ITIL beruht auf Best Practice Ansätzen und sieht Sicherheitsaspekte als unverzichtbaren Bestandteil eines ordnungsgemäßen IT-Betriebes an. sondern findet in Teilbereichen der fünf Buchbände Berücksichtigung. die die Erbringung von Serviceleistungen betreffen. in den SLAs definierten. ob ein Security Management aufgebaut wird und gegebenenfalls werden Verantwortlichkeiten festgelegt. Anforderungen leiten sich Sicherheitsziele ab. Wird diese Thematik nach ITIL eingeführt und allumfassend umgesetzt. die das Top-Management betreffen. um eine gesamtheitliche Akzeptanz und Unterstützung zu gewährleisten. also die zu erbringenden IT-Dienstleistungen. Das Top-Management stellt die oberste. Taktische Ebene. der die Verantwortung diesbezüglich trägt und Ansprechpartner der Geschäftsleitung ist. Im Gegensatz dazu wird dem Thema Sicherheit in der aktuellen. ist das Security Management. dessen Aufgabe es ist die gesamte Netzwerkstruktur in puncto Sicherheit zu betreuen und zu überwachen. vom einfachen Mitarbeiter bis hin zur Chefetage.

die eine Schnittstelle zwischen Anwendern und IT-Organisation bildet.3 Security Management mit ITIL auf operativer Ebene Nachdem im vorherigen Kapitel grundlegende Aspekte. Change. ohne an entsprechendes Fachpersonal 8 Auf eine detaillierte Darstellung der operativen Ebene wird an dieser Stelle verzichtet. soll nun im Folgenden aufgezeigt werden. 13] Über den gesamten Zeitraum der Bearbeitung kann der aktuelle Status des Incidents abgerufen und kontrolliert werden. wie sich diese Synergieeffekte nutzen lassen. „Faceto-Face“-Kommunikation oder wie in den meisten Fällen per Telefon. Auftrag oder Störfall . sondern eine Funktion.3. 13] Ein Beispiel dafür sind Änderungsanträge.8 3.und Configuration Managements. Das können unter anderem triviale Fragen zu Soft. unterstützt das Release Management bei der Rollout-Phase oder stellt von sich aus Kontakt zu Anwendern her.3. das BSI-Grundschutzhandbuch tut. Hier laufen Anfragen zusammen und es wird die Funktion des Incident Managements mit Schnittstellen zu Problem-. Der Mitarbeiter am Service Desk ist nun gefragt weitere Schritte zur Behebung dieser Incidents einzuleiten und Ereignisdaten in einer Datenbank zu speichern. Im Gegensatz zu den nachfolgenden Servicemanagement-Prozessen in ITIL stellt der Service Desk keinen eigentlichen Prozess dar. Mittels Email. die zuvor bereits standardisiert wurden und nun direkt umgesetzt werden können. so dass Geschäftsleitung oder Kunden schnell und zuverlässig Informationen bereitgestellt werden können. S. Dazu werden in den folgenden Abschnitten die einzelnen Prozesse des Service Supports kurz erläutert und anschließend die Vorteile der wechselseitigen Beziehung aufgezeigt.und Hardware sein oder auch Meldungen zu Produktfehlern oder Servicestörungen. 9 Englischer Begriff für unvorhergesehenes Ereignis. Neustrukturierung der Geschäftsprozesse nach ITIL bieten. um Überschneidungen mit dem folgenden Kapitel zu vermeiden. S. Zwar sollen auch solche Aspekte angesprochen werden. werden sogenannte Incidents 9 aufgenommen und bearbeitet. Ziel dieses Kapitels ist es nicht.und Release Management etabliert.1 Service Desk Hat ein Anwender eine Anfrage oder treten Komplikationen in Bezug auf bestimmte Anwendungen oder Services auf. auf die in Kapitel 3.[Bmi06.6 ausführlicher eingegangen wird. wie IT-Security Management oder Informationssicherheit erläutert wurden. an die er gelangt. wo sich Chancen und Möglichkeiten des Zusammenwirkens von Security Management und Service Support im Zuge der Restrukturierung bzw. 3. der Fokus dieses Kapitels liegt jedoch eindeutig auf der Darstellung der prozessorientierten Maßnahmenplanung. Gemäß ITIL ist dies die Configuration Management Database (CMDB). Er ist der zentrale Anlaufpunkt einer IT-Organisation und soll eine professionelle Anwenderunterstützung garantieren. konkrete Sicherheitsmaßnahmen vorzustellen. ist der Service Desk die erste Station. Der zentrale Anlaufpunkt ist der Service Desk.90 ITIL und IT-Sicherheit Anfragen und Änderungen. wie es bspw.[Bmi06. Des Weiteren übernimmt der Service Desk Routineaufgaben des Change. Ferner soll explizit dargestellt werden.

die mit Ticket-Systemen arbeiten. ist das Incident Management als Teilbereich des Security Managements anzusehen. alle Anfragen und Vorfälle schnellstmöglich zu behandeln und potentielle Fehler zu beheben. welche ITIL mit sich bringt.oder Hardwareinstallationen. Da Störungen die Informationssicherheit beeinflussen können oder ein unerkannter Sicherheitsvorfall Störungen hervorrufen kann.2 Incident Management Nachdem eine Anfrage aufgenommen wurde. lässt sich in mehrere Arbeitsschritte untergliedern. ist es Ziel dieses Vorgangs. Jeder Incident wird dadurch einem Ticket zugewiesen und ist über eine Netzwerkverbindung jederzeit abrufbar. Der Service Desk ist aufgrund seiner Schnittstellenfunktion auch für sicherheitsrelevante Themen zuständig. ist es die Aufgabe des Incident Managements.Synergien zwischen Security Management und Service Support nutzen 91 weitergeleitet zu werden. 17] 10 Ein Patch ist eine Korrekturauslieferung oder Nachbesserung für Software aus Endanwendersicht. Patches10 oder Updates. Die Bearbeitung von Störungen. wie z. die zentral abgelegt und nur einen Zugriff zur selben Zeit zuließen. S. . um die IT-Spezialisten möglichst rasch zu alarmieren und Fehleinschätzungen vorzubeugen.3. [Bmi06. Durch Soft. Durch seine vielfältigen Anforderungen kann er allgemeine Aufgaben erfüllen und sogar spezifische Lösungen bereitstellen. sind dazu einige Softwarelösungen. 3. Auf dem Markt erhältlich. Der Service Desk ist somit ein Teil des Security Management und sollte Anforderungen wie hohe Erreichbarkeit und Reaktionsgeschwindigkeit gerecht werden. Die Mitarbeiter des Service Desk sind ein wichtiger Aspekt in diesem Prozess. So werden über Security Incidents Prozesse der ITSicherheit wie Passwortvergabe. da durch ihre Entscheidung Arbeitszeit und Aufwand gespart oder vergeudet wird. Bei entsprechender Umsetzung kann der Service Desk einen großen Beitrag zu der Incidentbearbeitung leisten. diese zu verwalten und eine Übersicht über den aktuellen Status aller Incidents zu gewährleisten. in diesem Fall Security Incidents. computergestützte Verfahren eingesetzt. Letztendlich ermöglicht ein funktionierender Service Desk sogar die Leistung des Security Management zumindest in Teilen messbar zu machen. Aussagen darüber zu machen. B. um die Behandlung einer Vielzahl von Datensätzen zu ermöglichen. Flächenstörungen) auszuarbeiten. In Verbindung mit der Leistungstransparenz. Im Gegensatz dazu werden heutzutage moderne. Zusammen mit dem für die Sicherheit zuständigem Management ist es ratsam Strategien zur Sensibilisierung der Mitarbeiter bei hoch sicherheitsrelevanten Vorfällen (z. können bestimmte Störungen schon vom Service Desk behoben werden und entlasten somit das Release Management. B. bspw. Um Auswirkungen auf die Geschäftsprozesse so gering wie möglich zu halten und Imageschäden zu vermeiden. um eine Sicherheitslücke zu schließen. Früher wurden dazu Bücher geführt. ermöglicht es die Erfassung von Security Incidents bspw. bei denen mehrere Benutzer gleichzeitig auf einen Incident zugreifen können. ob die Anzahl an Security Incidents rückläufig ist oder um wie viel Prozent diese zurückgegangen sind. bei dem je nach Qualität einer Störung eine oder mehrere Support-Stufen durchlaufen werden. ITIL liefert hierzu einen Prozessansatz. Veränderungen von Zugriffsrechten oder auch Benutzerkonten angesprochen und bearbeitet. Derartige Standardprozesse können direkt vom Service Desk durchgeführt oder aber an Experten weitergeleitet werden.

D. dass sensible Informationen weniger schnell an die Öffentlichkeit gelangen. Klassifizierung und Erstlösungsversuch. Es kann in der Praxis sinnvoll sein. Zum einen wäre da der Anwender (Kunde. sollte es dem Mitarbeiter des First-LevelSupport möglich sein. Dieser erste Schritt in der Bearbeitung der Störungen wird First-Level-Support genannt. die in der Vergangenheit aufgetreten sind. Diese Prioritätseinstufung dient nur als eine erste Orientierung und kann später durch genauere Analyse von Fachpersonal oder im Change Management korrigiert werden. welche Schadensauswirkung entstehen kann und wie dringend das Sicherheitsziel wieder hergestellt werden sollte. Ein weiterer Aspekt ist die Erkennung einer Störung durch ein System. kann er an dieser Stelle direkt behoben werden und es kommt zu keiner weiteren Bearbeitung. Die Prüfung des Störfalls beginnt mit der Recherche über bereits bekannte Störungen oder ähnliche Vorfälle. Auf der anderen Seite wird von einem Anwender erwartet. Ist dies der Fall. Die andere Möglichkeit ist eine zentrale Annahme aller Incidents. ob ein Vorfall sicherheitsrelevant ist oder nicht. werden diese Ereignisse von dem Service Desk erfasst und in der CMDB gespeichert. festzustellen. um der weiteren Lösungsfindung mehr Zeit . wird der damals benutzte Workaround vorgeschlagen oder eine entsprechende Eskalationsstrategie angewandt. Security Incidents getrennt von anderen Störungen an einer separaten Meldestelle aufzunehmen. eine Einschätzung gemäß ihrer Bedeutung für die Organisation zu tätigen. Wie oben bereits erwähnt. der die Security Policy verletzt und dessen Lösung in der Configuration Management Datenbank dokumentiert ist. Zulieferer. Vorteil dieser Maßnahme ist es. Grundsätzlich gilt es Aktionismus zu vermeiden. Der Workaround dient dazu. Das Erkennen von Störfällen kann auf verschiedenen. dem eine Unregelmäßigkeit bekannt wird und diese an den Service Desk heranträgt. Handelt es sich um ein Fehler. h. es wird ein Bearbeitungszeitraum zur Lösung des Problems eingeplant und eine erste Priorisierung vorgenommen. Netzwerke mit ihren Peripheriegeräten können über eine Software überwacht werden (Monitoring) und senden bei Überschreitung eines bestimmten kritischen Wertes eine Fehlermeldung. Über eine Risikoanalyse wird ermittelt. Mitarbeiter). Einflüsse auf Geschäfts. Anhand der vorher definierten Security Policy. Analysieren und Lösungsvorschlag.. dezentralen Wegen erfolgen. Durch eine Klassifizierung wird Status und Art der Störung eingeordnet und festgestellt.92 • Erkennen und erfassen von Incidents • Klassifizierung und Erstlösungsversuch • Analysieren und Lösungsvorschlag • Incident lösen • Überwachen und steuern • Abschließen des Incidents ITIL und IT-Sicherheit Erkennen und erfassen von Incidents. welche Sicherheitsziele betroffen sind.und Serviceprozesse so gering wie möglich zu halten.

sollte der Umgang mit sensiblen Informationen geklärt sein. Nach Lösung des Störfalls wird der Incident vom Service Desk abgeschlossen. Wurde ein Störfall erfolgreich gelöst. Dazu gehört die Kontrolle über korrekte Bearbeitung und Nutzung der vorgegebenen Support-Ebenen. Umgestaltung einer Netzwerkstruktur) gelöst werden kann. wird ein Request for Change 11 (RfC) beim Change Management eingereicht. Entwickelt sich eine Störung zu einem Notfall. Überwachen und steuern. Die Verantwortung liegt bei Vorfällen diesen Ausmaßes bei dem Notfallmanagement. Sofern ein Incident nur durch eine Änderungsmaßnahme (z. Sofern ein Standardproblem nicht schon im Vorfeld gelöst wurde. Komplettausfälle von Netzwerken oder auch Stromausfall sein. ähnlichen Incidents schneller behoben werden können. Die Forensiker konzentrieren sich auf genutzte Sicherheitslücken und Spurensicherung. ist eine ausführliche Dokumentation von großer Wichtigkeit. B. Eine explizite Betrachtung des Change Managements wird an einer anderen Stelle beschrieben. Zusätzlich wird der 11 Englischer Begriff für Änderungsanfrage . einen Notfall rechtzeitig zu erkennen und angemessen reagieren. Regelmäßig sind die Incidents zu Überprüfen. Durch eine strenge Authentisierung kann Missbrauch der Daten verhindert und die Integrität sichergestellt werden. während Mitarbeiter vom Service alle Energien zur Wiederherstellung betroffener Services einsetzen. damit nachfolgenden. diese einzusehen. Da eine Fülle von möglichen Anwendungs. Abschließen des Incidents. Ist ein Missbrauch jedoch nicht auszuschließen. Das Security Management sollte zu Beginn helfen. Auch in diesem Fall ist das Security Management gefragt. diese Ebenen der ITIL-Einführung zu strukturieren und aufgrund des fachlichen Wissens Verantwortlichkeiten verteilen. Da zur Bearbeitung der Störung vielfach externe Dienstleister oder Personen zu Rate gezogen werden. wie solche Daten übermittelt werden und welche Personen berechtigt sind. wird es von Fachkräften auf nächster Ebene behandelt. In den meisten Fällen der Security Incidents sind das IT-Spezialisten oder Systemadministratoren. Ist eine Problemlösung jedoch nicht bekannt und es kann keine schnelle Lösung gefunden werden. kann es zu Zielkonflikten zwischen forensischer Analyse und Servicemanagement kommen. sollte das Security Management das Incident Management darüber informieren. die auf zweiter oder dritter Ebene agieren. Falls Daten einem speziellen Schutz in Bezug auf die Informationssicherheit unterliegen. im Vorfeld einen Notfallplan auszuarbeiten. Notfälle können Flächenstörungen.und Konfigurationsproblemen denkbar ist.Synergien zwischen Security Management und Service Support nutzen 93 zu verschaffen. Incident lösen. sollte das Incident Management in der Lage sein. Die CMDB sollte um eine Handlungsvorschrift ergänzt werden. wie zum Beispiel Serverausfall. wird der Vorfall an eine nächste Support-Ebene weitergeleitet. Die Überwachung der Störungen ist Aufgabe des Service Desks. um die Wiederherstellung der Sicherheitsziele in der dafür vorgesehenen Zeit nicht zu gefährden. Vielmehr sollten absehbare oder schon bekannte Sicherheitslücken dokumentiert vorliegen. wird es praktisch kaum möglich sein dem Support zu jedem Vorfall eine entsprechende Handlungsvorschrift bereitzustellen.

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. S. Bspw. die nicht behoben werden können.94 ITIL und IT-Sicherheit Anwender über den Hergang informiert und es wird gegebenenfalls ein Feedback angefordert. auf die in den nächsten Absätzen eingegangen wird. kann das Incident Management ein Netzwerkfehler schnell beheben. Es können vom Incident Management auch Anfragen für spezielle Probleme eingehen. . Anschließend wird die Dokumentation auf Vollständigkeit geprüft. Durchlaufzeit. Während das Incident Management einen Fehler schnellstmöglich beseitigen möchte. die Ursache dafür zu finden bzw. Eine solche Datenauswertung ermöglicht es ferner über folgende Fragestellungen Auskunft zu geben: ([Bmi06.[Bsi05. zu beseitigen. Wenn bei der Bearbeitung einer Störung durch das Incident Management die Ursache nicht festgestellt werden kann. Auf diese Weise kann ein funktionierendes Problem Management die Anzahl von Incidents reduzieren und somit ein erheblicher Teil zur Zuverlässigkeit und Wirtschaftlichkeit eines IT-Services beitragen. S. dass sich Fehler wiederholen. versucht das Problem Management das Auftreten solcher zu vermeiden. Kurzbeschreibung und Effektivität der Untersuchung. • Antrag aus dem Incident Management • Das proaktive Problem Management Antrag aus dem Incident Management. Anhand dieser Daten ist eine Auswertung möglich. Das Problem Management wird aber möglicherweise eine Auswechslung der gesamten Switches beantragen. indem ein entsprechender Switch13 neu gestartet wird. Das Incident Management hat die CMDB zu pflegen und sollte nach Security Policy und Security Management über mehrere Aspekte Auskunft geben können. die sie zwar schnell beheben können. Dazu zählen beispielsweise Erfassungsdatum. um Präventivmaßnahmen durchzuführen oder in Zukunft schneller reagieren zu können. Dabei kann dies mitunter zu Interessenskonflikten führen. Hier macht sich der generelle Unterschied bemerkbar.3 Problem Management Die Aufgabe des Problem Managements ist die Forschung nach den Ursachen für Probleme12 Durch sogennante Ursachen-Wirkungsanalysen soll verhindert werden. die noch unbekannte Ursache für einen Störung. die mehrere Computer verbindet. wird aus dem Incident ein Problem und an das Problem Management weitergeleitet.Definition sind Probleme. was mehrere Stunden dauern 12 Nach ITIL. 18] 13 Ein Switch ist eine Netzwerkkomponente. sich aber nicht in der Lage sehen. Dabei muss es sich nicht immer zwangsläufig um Probleme handeln. Im Problem Management gibt es zwei unterschiedliche Verfahren.3.

[Bsi05. Die nachfolgende Abbildung verdeutlicht eine Problematik. Diese Frage sollte deshalb bereits bei der Entwicklung der internen Sicherheitsrichtlinien beantwortet und die Vorgehensweise standarisiert werden. sollte eine Überprüfung auf Schwachstellen in regelmäßigen Abständen mit Hilfe von Penetrationstests erfolgen. eine eigene Software oder bietet eine solche Kunden an14 . Das Security Management sollte aufgrund seiner speziellen Funktion somit bereits in die Analyse mit einbezogen werden.Synergien zwischen Security Management und Service Support nutzen 95 kann und somit auch das Netzwerk für diese Zeit abgeschaltet werden muss.) in ein System einzuloggen. ist schnell zu erkennen. Virus.15 Ergänzt man die Verfahrensweisen des proaktiven Problem Managements um diese Methode und optimiert diese für den eigenen Zweck. Durch die Integration des Security Management in den ITIL-Prozess Problem Management entstehen potenzielle Synergieeffekte. Da aber Lösungswege 14 Dabei 15 siehe kann dieses Verhältnis auch betriebsintern bestehen. Wird eine Schwachstelle gefunden. In diesem Fall ist die Informationssicherheit des Netzwerkes der Unternehmung gefährdet. Das proaktive Problem Management. Kapitel 3. wenn diese beseitigt ist. Über die dazugehörigen Updates sollten dann die Kunden informiert und ihnen zur Verfügung gestellt werden. Die Suche nach Schwachstellen mittels Security Audits ist eine der Maßnahmen des Security Managements. wann das Security Management in den Prozess des Problem Managements eingebunden werden soll. Durch sein Know-how kann das Security Management bei der Problem-Analyse und Lösungsentwicklung einen wesentlichen Beitrag zu besseren Ergebnissen leisten. Nicht jedem Incident kann zu Beginn eindeutig zugeordnet werden. mit der sich eigentlich primär das Change Management konfrontiert sieht. sollte umgehend eine Lösung gefunden und gegebenenfalls die Software geändert werden. Hat man z. Kurzfristig wird dadurch die Verfügbarkeit gestört. bevor sie auftreten.3 Ziele und Aufgaben des IT-Security Management . durch präventive Maßnahmen Fehler zu verhindern. B. dass die Schwachstelle erst dann an die Öffentlichkeit gelangt. Eine weitere Aufgabe des Problem Managements ist das proaktive Suchen nach Fehlern und Schwachstellen. den Versuch sich mit den Mitteln eines Eindringlings (Hacker. Ziel dabei ist es. ermöglicht dies Verletzungen von Sicherheitsrichtlinien frühzeitig zu erkennen und mögliche Ursachen für Fehler zu verhindern. Erfahrungsgemäß ist dabei die Analyse von Sicherheitslücken und deren Beseitigung eine große Stärke des Security Managements. sondern auf einem Angriff von außen (etwa durch einen Hacker oder Virus). Geht man aber weiter und führt sich vor Augen welche Zielsetzung das Problem Management verfolgt. In diesem Zusammenhang sollte darauf geachtet werden. um eine bestmögliche Effizienz zu erreichen. dass der oben beschrieben Netzwerkfehler nicht auf einem defekten Switch beruht. ob dieser Auswirkungen auf die Informationssicherheit hat oder nicht. etc. um damit die Synergieeffekte optimal auszunutzen und ein bestimmtes Sicherheitsniveau gewährleisten zu können. S. Unter einem Penetrationstest versteht man.2. Daher muss abgewogen werden. Es sei nun angenommen. dass auf lange Sicht die Verfügbarkeit und die Wahrscheinlichkeit auf Erreichung der SLA erhöht wird. 18] Durch die Verflechtung beider Prozesse und deren Aufgaben lässt sich eine deutliche Kompetenzsteigerung erreichen.

Aus diesem Grund hat das Problem Management großes Interesse daran. Durch dieses Zusammenspiel von Problem. Ziel ist . Die Mitarbeiter des Security Managements können schon bei der Entwicklung von Änderungsvorschlägen eingreifen und diese auf sicherheitstechnischen Aspekten überprüfen. 3.3: Auswirkungen von Änderungen auf die Informationssicherheit.96 ITIL und IT-Sicherheit für bestehende Probleme schon im Problem Management entwickelt werden und sie damit eine gewisse Vorarbeit für das Change Management leisten. Dies steht jedoch im Widerspruch zu den eigentlichen Zielsetzungen des Problem Managements (vor allem die Reduzierung der Incidents). Wird nun das Security Management zusätzlich in den Prozess der Lösungsentwicklung einbezogen. welches die Ursache oder Wirkung von Service-Beeinträchtigungen sein und die Informationssicherheit gefährden kann. Das Problem Management versucht die Ursachen hierfür zu ermitteln. Handelt es sich bei einer Sicherheitslücke nicht um einen dokumentierten Fehler. Häufig entstehen hieraus konkrete Änderungsvorschläge (RfC). diesen potenziellen Kreislauf gar nicht erst entstehen zu lassen.und Security Management kann eine höhere Effizienz bei Änderungen erreicht und somit auch Kosten gesenkt werden.3. Es kann ein potenzieller Kreislauf entstehen. liegt im Allgemeinen ein Problem vor. unternimmt Lösungsversuche oder schlägt Lösungswege vor. durch den permanent die Informationssicherheit gefährdet ist. kann im Change Management eine Reduzierung der abgelehnten RfCs erreicht werden. Diese Änderungen können Auswirkungen auf die Informationssicherheit haben und im schlimmsten Fall letztlich neue Sicherheitslücken verursachen. Änderungen Sicherheitslücken Informationssicherheit Fehler Probleme Abbildung 3. soll auf die möglichen Auswirkungen vorgenommener Änderungen auf die Informationssicherheit bereits an dieser Stelle eingegangen werden.4 Change Management Die Zuständigkeit des Change Managements erstreckt sich von der Erfassung über die Priorisierung bis hin zur Auswertung aller eingehenden RfCs.

die einen Nachweis über Nutzen und Kompatibilität mit anderen Systemen ermöglichen. um gemeinsam die gerade beschriebenen Aufgaben zu bewältigen. 19] In diesem Kontext vollzieht das Change Management geeignete Tests. um ein Ausgleich zwischen dem Termindruck und der Sicherheit zu erzielen. Das Security Management nach ITIL ist sowohl als Initiator. veränderte Eingriffe in Anwendungen.[Bsi05. dass durch Änderungen Sicherheitslücken entstehen. Verlaufen die Tests positiv. Änderungen vermieden werden. Infrastruktur.3. auf der anderen Seite stellt das Security Management geeignete Test. Auf diese Weise ist einerseits sichergestellt. Um Auswirkungen auf die Informationssicherheit und den Datenschutz zu vermeiden. Hierbei findet das Change Management in gleicher Weise wie in anderen Bereichen des IT-Betriebs Berücksichtigung. B.und Freigabeinstanz von Changes in den Change Management Prozess eingebunden. ein oder mehrere Mitarbeiter des Security Managements in das Änderungsgremium mit aufzunehmen. die keinen angemessenen Nutzen liefern. das Security Management herangezogen. die verhindern sollen. die Erfüllung einer Servicevereinbarung nicht gewährleistet ist. Häufig hat dies technische oder organisatorische RfCs zur Folge. Als Planungs. Ist dies der Fall. Im zweiten Schritt wird überprüft. Die zentrale Instanz des Change Managements ist das Change Advisory Board (CAB). nicht gewünscht sind oder mangels Durchführbarkeit wieder zurück genommen werden. die durch das Security Management im Laufe der Problem-Analyse angeordnet und an das Change Management weitergeleitet werden. S. 20] Als Initiator von Changes. Dokumentationen. S. wie das Security Management bei der Überprüfung und Abnahme von RfCs unterstützend mitwirken kann. Änderungen. 20] Hier müssen mit besonderer Vorsicht genaue Vorgaben definiert werden. ob die Informationssicherheit betroffen ist. wenn z. Realisierer sowie als Planungs. So werden Security Maßnahmen entwickelt und realisiert.und Abnahmeverfahren bereit. Letzteres ist möglich. Das Security Management hat konkrete Verantwortungen für Teile der IT-Infrastruktur. Wurde ein Incident als dringlich eingestuft. die die Informationssicherheit betreffen. Abbildung 3. so kann der Change freigegeben und ausgeführt werden. Störungen infolge von Änderungen sollen vermieden und die Effizienz der Änderung gesteigert werden. h. weil z. dass jeder RfC auf sicherheitsrelevante Merkmal überprüft wird. wird bei Incidents. B.[Bsi05. Als Realisierer von Changes. Wenn der . Schon im Service Desk werden Incidents bezüglich ihrer Dringlichkeit priorisiert. d. S.Synergien zwischen Security Management und Service Support nutzen 97 es dabei. Dieses wird vom Change Manager zusammengerufen. Diese sind meistens dringend und greifen teilweise tief in bestehende Funktionalitäten und Prozesse ein. so ist auch der dazu gehörige RfC in den meistens dringlich. Wie im Kapitel 3. wobei hier die Sicherheit nicht vernachlässigt werden darf.[Bsi05.3 (Problem Management) beschrieben. sollte das Security Management sowohl bei der Planung als auch bei der Freigabe von Änderungen mit eingebunden werden.4 veranschaulicht. Prozesse und Verfahren steuerbar und kontrollierbar zu machen. durchläuft der RfC ein verkürztes Verfahren. Besonders bei Sicherheitspatches besteht eine hohe Brisanz.und Freigabeinstanz. Sinnvoll ist es in diesem Zusammenhang.

anhand derer die Freigabe durch das Security Management erfolgt. S. RfC Auswirkungen auf die Informationssicherheit hat. ob diese ausreichend vor Fremdeingriffen geschützt sind. angemessene Rückfallverfahren bereit stehen. Können diese nicht eingehalten werden oder ist die Einhaltung der Verfügbarkeit. mit denen der ursprünglichen Zustand schnell wieder hergestellt werden kann. der Grundfunktionalität einer Software nach deren Fertigstellung oder Reparatur. Im dritten Schritt wird überprüft ob der Datenschutz betroffen ist.98 ITIL und IT-Sicherheit Request for Change Dringender Change ? Informationssicherheit betroffen ? Datenschutz betroffen ? Test der Informationssicherheit Smoke Test Abnahme Abbildung 3. Dabei muss ein RfC nicht zwangsläufig vom CAB abgelehnt werden. Der Smoke-Test ist eine oberflächliche Überprüfung bzgl. muss das Security Management Abnahmekriterien definieren.3. In der letzten Phase werden beim Rollout durch ausgiebige Tests nicht nur die Korrektheit einer bestimmten Funktion getestet. Wenn die RfCs positiv bezüglich der Sicherheitsziele getestet wurden.4: Abnahme von RfCs. die in Form eines sogenannten Smoke-Tests durchgeführt werden. wenn es vom Security Management abgelehnt wurde.3 (Problem Management) wurde schon erwähnt. Nachdem diese Schritte durchlaufen sind. Im Falle der Ablehnung ist eine Kompromisslösung durch das CAB zu finden. bei Änderungen der Zugriffsrechte oder bei Software zur Verwaltung der persönlichen Daten des gesamten Personals geprüft werden. dass bei der Planung der RfCs das Security Management einbezogen werden soll. Durch diese Einbindung sinkt die Wahrscheinlichkeit für die Entstehung neuer Sicherheitslücken und damit für die Ablehnung der RfCs enorm. Integrität oder Vertraulichkeit nicht gewährleistet. Im Falle des Scheiterns der RfCs bei diesen Tests. Insbesondere muss darauf geachtet werden. sondern auch die Erreichung und Einhaltung der Sicherheit. In vorherigen Kapitel 3. Quelle: [Bru06. um die Informationssicherheit zu gewährleisten. muss das Security Management diesen Change ablehnen. B. sollten. dass das CAB Schwerpunkte auf andere Aspekte. B. Bei einer schnelleren und . Diese werden auch bei dringenden Changes angewandt. Das liegt daran. 82]. das Kosten-Nutzen Verhältnis eines Change. Hierbei sollte z. legt. dass nicht neue Lücken oder Hintertüren in Software-Applikationen entstehen und die einmal erreichte Sicherheitsstufe nicht beeinträchtigt werden. wie z. können sie aus Sicht des Security Managers freigegeben werden. wird überprüft. ob die Sicherheitsziele des SLA berührt werden.

Die zentrale Aufgabe des Release Management in diesem Bezugsrahmen ist es.5 Release Management Während das Change Management der Initiator aller Änderungen innerhalb einer IT-Infrastruktur ist. S. So gab es in der Vergangenheit Fälle. dass bei der Einführung eines Release keine unerwünschten Nebeneffekte oder Fehler auftreten. (Beispiel ähnlich zu [Köh06. Geht man bspw.und Hardwareversionen bis hin zur organisatorischen und technischen Vorbereitung der Einführung einer Komponente.und Change Management früh eingebunden wird. sondern zu einem Paket.000 Euro an potentieller Arbeitsleistung verloren. 50 Euro/Stunde aus. 103]) Dieses Beispiel verdeutlich unter anderem. dass RfCs. Planungsphase. dass der Aufwand für das Testen und die Inbetriebnahme erheblich reduziert werden kann. Diese Aspekte zeigen die Chancen. von 500 Usern eines DV-Verfahrens mit einem Durchschnittsstundenlohn von ca. so gehen mit jeder Ausfallstunde 25. fälschlicherweise Sicherheitslücken aufstoßen. dass die Notwendigkeit besteht Sicherheitsüberlegungen in den Prozess des Release Managements mit einzubeziehen.“[Bsi05. wenn das Security Management in das Problem. der sogenannten Release Unit 16 gebündelt. ergibt sich während all dieser drei Phasen. S. Der wirtschaftliche Schaden kann in solchen Fällen schnell ein immenses Ausmaß annehmen. 20] Dabei werden die Konfigurationselemente üblicherweise nicht einzeln implementiert. 3. lässt sich dabei im Allgemeinen in drei Phasen einteilen: • Planungs.Synergien zwischen Security Management und Service Support nutzen 99 wahrscheinlicheren Freigabe der RfCs aus sicherheitstechnischen Aspekten kann zusätzlich die Verfügbarkeit im Unternehmen gesteigert werden. da dieses irrtümlicherweise unternehmenseigene Software als Virus erkannte und schließlich deaktivierte [Bsi07. S. mit Hilfe geeigneter Maßnahmen sicherzustellen.und Entwicklungsphase • Testphase • Planung und Autorisierung des Rollouts Die Möglichkeit Security Aspekte in das Release Management mit einfließen zu lassen. Die Einführung solcher Release Units hat den Vorteil. die ursprünglich nichts mit der Informationssicherheit zu tun haben. diese realisiert und die Verantwortung dafür trägt. Auf dieser ersten Stufe werden zunächst grundsätzlich Regeln hinsichtlich eines Release oder der Release Unit definiert und in der Release 16 Release: Englischer Begriff für Version . in denen Unternehmensnetzwerke durch das Update eines Anti-Virenprogramms lahm gelegt wurden. S. Dafür muss zwingend ein Mitarbeiter aus dem Security Management ein ständiges Mitglied im CAB sein. 90]. ausgelöst wird [Bru06. liefert das Release Management die „Verfahren von der Anforderungsbearbeitung über die Planung der Umsetzung. Test und Abnahme von Soft. welcher durch einen vom CAB freigegebenen RfC. Der Prozess des Release Managements. 3]. die sich bieten. Dieser soll verhindern.3.

das sogenannten Rollout 17 . in der Planungsphase definierten. 12] im Vorfeld eines Release. Der Rollout Plan 17 Englischer Begriff. Ausliefern und Ausführen von Soft. etwa bzgl.[Bsi05. der in Kapitel 3. in dem es Risiko. werden auf der zweiten Stufe die jeweiligen Releases vor ihrer Einführung diversen Tests sowie einer Qualitätsprüfung unterzogen.Software und Grundsätze Planung entwickeln zusammenstellen und Planung Verbreitung. Rollout-Planung Mit der Freigabe des Releases beginnt die letzte Phase des Release Management Prozess. oder Installation Training und konfigurieren Abnahme beauftragen Abbildung 3. sollte ebenfalls fest verankert werden. sofern dieses Sicherheitsrichtlinien verletzt. die während der Release Planung einzuhalten sind. die ein wesentlicher Bestandteil des Release Management Prozesses ist. Policy festgehalten. Verfügbarkeit und Integrität eingehalten werden. Das Security Management kann hierbei entwicklungsbegleitend und unterstützend tätig werden.Kommunikation. Verteilung Release. . der das Verteilen. Sicherheitskriterien verletzt und die Anforderungen an Stabilität. In der Release Policy.1 vorgestellten Hauptwerte der Informationssicherheit. S.und Sicherheitskriterien fixiert. diese eingespielt werden und nicht erst bis zum nächst größeren Update gewartet wird. Dieses standardisierte Vorgehen ermöglicht es. Ansonsten bleibt dem Security Management nur noch die „Rolle des Verhinderers“[Bsi05. Es liefert die entsprechenden Testverfahren. erteilt das Security Management die erforderliche Freigabe aus seinem Blickwinkel. Damit der reibungslose und funktionierende Ablauf des Systems nicht gestört wird. Sofern das Release die Anforderungen erfüllt.5: Phasen des Release Management Prozesses und Aufgaben.2. 21] Hierbei kann auf das Know-how des Security Management zurück gegriffen werden.100 ITIL und IT-Sicherheit Planungsphase Testphase Rollout-Phase ReleaseRelease Test Rollout. potenzielle Sicherheitslücken frühzeitig zu beseitigen.und Hardwarereleases beschreibt. dass durch das Release keine der. S. S. Dabei soll in einer möglichst „produktionsidentischen Testumgebung“[Bru06. 91] sichergestellt werden. Schließlich kann das Security Management noch bei der Planung lösungsspezifischer Releases mit einbezogen werden. Testphase. Das Security Management sollte schon in dieser frühen Phase wirksam werden und dem Release Management Vorgaben über bestimmte Sicherheitsanforderungen machen. dass sofern sicherheitsrelevante Patches verfügbar sind.

[Bru06. 84] Um bei der Vielzahl an CIs Verwechselungen auszuschließen. geliefert wird.“[Bru06. etwa ein Server oder Arbeitsplatz-PCs sowie einzelne Peripheriegeräte (Beamer. welches in diesem Kontext beachtet werden muss. d. Scanner. Archiviert und bereitgestellt. Eine Übersicht über alle Änderungen liefert dem Security Management die Grundlage für eine releaseübergreifende Risikobetrachtung. welche weiteren CIs unter Umständen ebenfalls von dem Vorfall betroffen sind. Durch ein Backout wird ein neues Release definiert. Die zentrale Aufgabe des Configuration Management besteht darin. bei einem bestimmten CI ein Incident oder Problem auf. wie etwa Problem. die bei der Implementierung des Releases durch das Change Management beachtet werden müssen. Ferner muss bei der Rollout Planung die Nachvollziehbarkeit bzw. 92] So sollte man bspw. Das entscheidende Kriterium. So wird bspw. Abschließend sei angemerkt. Drucker oder Tastatur) zu verstehen. Unter einem CI sind sowohl ganze IT-Systeme. 93] 19 „Ein Backout ist ein Verfahren. indem eine Übersicht über alle CIs. h.[Bru06. S.3. Von einer kooperativen Zusammenarbeit profitieren sowohl Release als auch Security Management. Das Configuration Management ist der zentrale Prozess innerhalb des Service Supports.6 Configuration Management Die Erfordernisse an die Datenverarbeitungsverfahren aus Sicht der Geschäftsprozesse eines Unternehmens haben in den letzten Jahrzehnten erheblich zugenommen.Synergien zwischen Security Management und Service Support nutzen 101 beinhaltet alle Regeln und Vorgaben. Dieser wird im Folgenden an Stelle des Begriffs Konfigurationselement verwendet. S. um nicht zusätzlich die Verfügbarkeit des Systems zu gefährden. die sogenannten Configuration Items 20 (CI) einer IT-Infrastruktur zu erfassen sowie deren Beziehungen zueinander darzustellen. die in einem Release zusammengefasst waren. Zusätzlich gehören auch Netzwerkkomponenten. Die CMDB liefert 18 „Ein Fallback ist die Wiederherstellung des vorherigen Releases. Auf SoftwareEbene etwa werden Sicherheitslösungen und -patches im Rahmen des Release Management Prozesses geplant und realisiert. risikobehaftete Releases zu unterschiedlichen Zeitpunkten zu implementieren. dass nicht nur das Release Management von der Berücksichtigung sicherheitsrelevanter Aspekte profitiert. ob ein Fallback 18 oder ein Backout 19 durchzuführen ist. Revisionsfähigkeit der Änderungen an der IT-Infrastruktur sichergestellt werden. sondern sich auch vorteilhafte Synergieeffekte für das Security Management ergeben. ist die Verfügbarkeit des Systems.oder Incident Management zugreifen können. wodurch alle Changes. Immer mehr Detailinformationen. die einzelnen Changes eines Release schrittweise rückgängig zu machen. deren Attribute sowie deren Beziehungen zueinander. Genau an diesem Punkte setzt das Configuration Management an. Tritt bspw. der Konfigurationselemente müssen erfasst. wie im Falle eines nicht erfolgreichen Rollouts zu verfahren ist. festgehalten. S. um abschätzen zu können. ist jedes CI grundsätzlich durch einen eindeutige Identifikationsnummer gekennzeichnet. 93] 20 Englischer Begriff für Konfigurationselement. Er schafft die Informationsgrundlage für die weiteren Prozesse. auf die ebenfalls andere Prozesse. rückgängig gemacht werden. 3.“[Bru06. etwa bzgl. S. wird diese Vielzahl an Information in der Configuration Management Database (CMDB). . darauf bedacht sein. so genügt ein Blick in die CMDB. kontrolliert und verifiziert werden. Datenträger sowie Dokumentationen dazu.

[Köh06. . die Abhängigkeiten zu anderen CIs erfasst. muss er anhand bestimmter. etc. Eine um diese Faktoren erweiterte CMDB liefert Transparenz über die sicherheitsrelevanten Abhängigkeiten der CIs.6: Erweiterte Attribute eines Configuration Item. spezielle Maßnahmen und Verfahren für CIs zu planen bzw. In der Planungsphase wird unter anderem das Design der CMDB festgelegt. Bevor ein CI in die CMDB aufgenommen wird.1 vorgestellten Dimensionen. S. Software. 22] Klassifikation. InformationsSicherheit Abbildung 3. Durch die Verzahnung mit den anderen Prozessen des Service Supports bietet das Configuration Management optimal Voraussetzungen. ermöglicht es Schwachstellen innerhalb des Configuration Management zu identifizieren und liefert die Basis für Ausfallanalysen. Kontrolle. Möglichkeiten dazu ergeben sich bereits und vor allem während der Configurations-Planung. 21 Die in Kapitel 3. Die Klassifizierung der CIs muss hierbei von den jeweiligen Prozessverantwortlichen vollzogen werden. die eine bestimme Klassifikation hinsichtlich der Informationssicherheit erhalten haben.[Bsi05. Dokumentation). um verschiedene Aspekte des Security Management darin zu integrieren. Zurechenbarkeit und Rechtsverbindlichkeit werden ebenfalls durch eine gut geführte Dokumentation innerhalb der CMDB unterstützt.als auch Configuration Management.). B.102 ITIL und IT-Sicherheit somit neben der Infrastrukturtransparenz eine Servicetransparenz.21 Standort Name und Beschreibung ID-Nummer Version Configuration Item Verantwortlichkeit Beziehung zu anderen CI´s Klassifikation bzgl. eröffnet dies Chancen und Möglichkeiten sowohl für Security. fehlerhaft. verschiedene Attribute. wie bereits erwähnt. 60] Zusätzlich werden. Verantwortlichkeit oder Version sowie einen Status (funktionsfähig. wie etwa Standort. Ergänzt man dieses bestehende Beziehungsgeflecht um die drei Hauptwerte der Informationssicherheit (Verfügbarkeit. Ferner wird es möglich. S. da nur diese die notwendigen Kenntnisse über die bereichsspezifischen Sicherheitsanforderungen haben.2. Integrität und Vertraulichkeit). Eine gut geführte und aktuelle CMDB kann sich innerhalb kurzer Zeit zu einem universellen Werkzeug auch aus Sicht des Security Management entwickeln. zu ergreifen. in der Designphase festgelegter Kriterien. Dabei erhält ein CI grundsätzlich eine bestimmte Kategorie (z. klassifiziert werden. Hardware. welches für ein funktionierendes Configuration Management von elementarer Bedeutung ist.

1 und 3. schon alleine im Hinblick auf die Beherrschbarkeit der stetig wachsenden Datenmenge eines Unternehmens. bspw. Klassifikation Absolut Hoch Mittel Niedrig Kriterium keine Ausfallzeiten gestattet maximale Ausfallzeit 30 Minuten maximale Ausfallzeit 4 Stunden maximale Ausfallzeit 2 Tage Tabelle 3.1: Klassifikation Vertraulichkeit. Vertraulichkeit und Integrität gilt.[Bru06. Weitere Synergieeffekte. Klassifikation Streng geheim Kriterium Zusammenhang mit strategischen Informationen. sondern dass überhaupt eine solche vollzogen wird. In Bezug auf die Klassifikation bleibt abschließend anzumerken. Aus diesem Grund findet deshalb in der Regel ein zweistufiges Klassifizierungssystem Anwendung. die durch Dritte eingesehen werden können. Vielmehr sollten überhaupt Risikoüberlegungen bzgl. die sich nach den jeweiligen Anforderungen des CIs richtet. da in diesem Kontext schwer zu definieren ist. S. Preislisten. dass es nicht erstrebenswert ist. Große Aufmerksamkeit bedarf es bei der Klassifikation der Integrität eines CIs.Synergien zwischen Security Management und Service Support nutzen 103 Die Einteilung in Hinblick auf Verfügbarkeit und Vertraulichkeit eines CI kann. Besprechungsnotizen. 88] Dabei wird zunächst für alle CIs eine Baseline Integrität festgelegt. Ebenso sprechen Praktikabilitätsgründe gegen die Einstufung eines jeden CIs. für die besondere Aufmerksamkeit in puncto Verfügbarkeit.B. aber nicht für diese bestimmt sind Vertraulich Eingeschränkt Tabelle 3. Eine davon sind so genannte Audits der CMDB . für alle CIs eine solche vorzunehmen. Betriebsgeheimnissen. Neben der vorgestellten Klassifizierung gibt es eine Reihe weiterer Möglichkeiten die Schnittstellen zwischen Security und Configuration Management zu nutzen. Quelle: [Bru06. z. Der aktuelle Grad an Integrität lässt sich ebenfalls schwer quantifizieren. wie in den Tabellen 3. Ein Anfang kann hierbei mit den CIs gemacht werden. da der Aufwand im Verhältnis zum Nutzen zu groß ist. Personaldaten Zusammenhang mit Informationen. S. Im Vordergrund sollte dabei nicht eine möglichst exakte Klassifizierung stehen.2: Mögliche Klassifikation Verfügbarkeit.2 dargestellt. wie viele falsche Daten eine Datenbank verkraftet oder wie viele Verbindungsfehler in einem Netzwerk auftreten dürfen. Rezepturen. Patenten und Kalkulationen Zusammenhang mit interne Informationen. 87]. vorgenommen werden. der Informationssicherheit in Form von Klassifizierung im Prozess des Configuration Management Berücksichtigung finden. eine bestimmte Anzahl tolerierter Verbindungsabbrüche oder die Anzahl fehlerhafter Datensätze und auf zweiter Stufe eine erweiterte Integrität.

und Systemdokumentationen nicht nur im Wiederholungsfall eine schnellere Installation. Darunter versteht man einen Soll-Ist-Vergleich zwischen dem dokumentierten/geplanten Bestand der CMDB und dem tatsächlichen Bild. Für viele ist der Begriff Security Management dabei gleichbedeutend mit dem Einsatz von Tools und Sicherheitslösungen zum Schutz vor potenziellen Bedrohungen. Ein Verlust der Verfügbarkeit. ist: Wer erhält hierauf Lesezugriffsrechte und wer darf den Datenbestand verändern? Die Notwendigkeit die Zugriffsrechte zu beschränken und zu kontrollieren. Mit Hilfe dieses standardisierten Vorgehens werden automatisch Gefahren reduziert. 3. Somit ist auch die Rechtsverbindlichkeit als eine weitere Dimension der Informationssicherheit sichergestellt. S.[Bru06. Die Verantwortung dieses sicher zu stellen tragen sowohl Security als auch Configuration Management.Infrastruktur liefert. 89] Je eher solche Hardwarekomponenten identifiziert werden. Darüber hinaus erleichtert ein funktionierendes Configuration Management die Analyse von Security Incidents.4 Fazit Die Auseinandersetzung mit dem Thema Informationssicherheit ist ein absolutes Muss für die Zukunftssicherung einer Unternehmung. finanziell) über die jeweiligen Geschäftsprozesse enthält. Integrität oder Vertraulichkeit dieser Daten kann mit erheblichen wirtschaftlichen Konsequenzen verbunden sein. Zudem ermöglichen ausführliche Installations.[Bsi07. sondern helfen auch bei der Ursachenforschung im Problemfall. dass die CMDB streng vertrauliche Informationen (physisch. können im Falle eines Hacker-Angriffs frühzeitig unbefugte Veränderungen am System identifiziert werden.104 ITIL und IT-Sicherheit in Bezug auf die Sicherheit. da in der CMDB die Historiendaten inklusive aller Changes revisionssicher gespeichert sind. 25] Eine ganz entscheidende Frage. Die Auswahl und Implementierung eines geeigneten Tools liegt dabei im Verantwortungsbereich des Security Managements. Eine andere Herangehensweise ist die Integration dieser Maßnahmen und Ideen in einen standardisierten. desto früher können diesbezüglich Sicherheitsmaßnahmen eingeleitet werden. So stellt ein unbekanntes. Ein funktionierendes IT-Security Management liefert hierzu einen wesentlichen Beitrag. Dazu wurden zu Beginn der vorliegenden Arbeit grundlegende Begrifflichkeiten von der Informationssicherheit bis hin zum Se- . die bspw. organisatorisch. Auf Hardwareebene steigt die Transparenz mit jedem Incident oder RfC. Vordergründiges Ziel dieser Arbeit war es. die Chancen und Möglichkeiten des Zusammenwirkens von IT-Security Management und den Prozessen des Service Supports darzustellen. ergibt sich aus der Tatsache. wie ihn das Rahmenwerk ITIL bietet. bspw. welches die IT. welche letztlich im Zusammenhang mit der CMDB geklärt werden muss. Durch diese regelmäßigen Scans/Audits und Abgleich mit der CMDB lässt sich mit relativ geringem Aufwand installierte. Jeder Change oder Incident führt dazu. da nur für bekannte CIs solche aufgegeben werden können. S. unautorisierte Software identifizieren. prozessorientierten Ansatz. Ferner sollte ein kurzer Überblick über das Thema ITSicherheit geliefert werden. dass noch nicht erfasste CIs in die CMDB aufgenommen werden. aktives Modem in einem Notebook eine erhebliche Sicherheitslücke dar. von nicht erkannten Verbindungen ausgehen.

Im dritten Kapitel. dass eine Wirtschaftlichkeitsbetrachtung nicht außer Acht gelassen werden darf.und Abnahmeverfahren. Aus Sicht des Security Managements liegt die Stärke dieses Ansatzes in der frühzeitigen Berücksichtigung der Sicherheitsaspekte und -anforderungen während aller Support Stufen sowie der ausführlichen Dokumentation von Sicherheitsvorfällen und deren Lösungen. bleibt abschließend anzumerken. die die Verknüpfung von Service Support und Security Management im Zuge der Neustrukturierung gemäß ITIL bietet. Hierzu sind die Einspareffekte.und Kritikalitätsüberlegungen von geeigneten Test. wie bspw. Mit Hilfe geeigneter Key Performace Indikatoren. den Kosten für die Implementierung gegenüber zu stellen. Der Service Support profitiert neben den Risiko. die Prozentzahl der zurückgegangenen Sicherheitsvorfälle und durch die gestiegene Transparenz und Messbarkeit der IT-Leistung dürfte diese Wirtschaftlichkeitsprüfung letztlich unproblematisch sein. die durch ein wirksameres und effizienteres Security Management entstehen.und Planungsphasen bieten. dem Hauptteil der Arbeit. .Synergien zwischen Security Management und Service Support nutzen 105 curity Management erläutert. dass das Security Management bereits bei der Implementierung der Service Support Prozesse einzubeziehen ist und sich die größten Potenziale während der Gestaltungs. wurden dann zunächst die Prozesse des Service Supports vorgestellt und anschließend die sich bietenden Synergieeffekte aufgezeigt. Im Rahmen dieser Analyse hat sich gezeigt. die das Security Management bereitstellt. Trotz dieser Möglichkeiten.

106 ITIL und IT-Sicherheit .

2006. 2007. Aspekte der Integration von Incident und Security Management. URL: http://www.bsi.pdf.de/IT-Sicherheit/ downloads/BMI-itil_und_informationssicherheit_v101. Walter: fIT for benefit .pdf. URL: www. URL: http://www.bsi.07] Bundesamt für Sicherheit in der Informationstechnik: Leitfaden IT-Sicherheit. 2006.de/gshb/Leitfaden/GS-Leitfaden. URL: www.bund.iznnet-kom.itil. 2. Springer Verlag.Literaturverzeichnis [Bmi06] Bundesministerium des Innern: ITIL und Informationssicherheit. Auflage 2007 [Vog02] Vogt.Service Design.08] [Bsi07] [Die04] [Iti07] [Köh06] Köhler. Berlin [OfG07] Office of Government Commerce: ITIL .07] [Bru06] [Bsi05] Brunnstein. [15. Vieweg Verlag. [18. [18.Auflage 2006 Bundesamt für Sicherheit in der Informationstechnik: ITIL und Informationssicherheit. 1. In: Informatik Spectrum August 2004 S.08] Dierstein.org: Das Portal für Informationen rund um ITIL und ISO20000. Jochen: ITIL Security Management realisieren. Auflage 2002 107 .der Begriff IT-Sicherheit.12.org/de.de/literat/studien/ITinf/itil. [09. Auflage. TSO. Rüdiger: Sicherheit in der Informationstechnik .pdf.: ITIL. 1.02. 343-353 ITIL. Perseo Consult. 2005. 1. Peter T.niedersachsen.IT Services kundenorientiert stuern und planen.01.12.

108 ITIL und IT-Sicherheit .

Im Grundlagenteil wird zunächst das Verständnis der Begriffe ITIL und Werkzeuge für diese Arbeit aufgeführt.1 Einleitung Der Übergang von einer technischorientierten zu einer dienstleistungsorientierten IT-Organisation hat in den letzten Jahren an Bedeutung gewonnen. ob softwareunterstützende Werkzeuge bei der Umsetzung und zur Effizienzsteigerung eingesetzt werden. Kathrin Stegmann 4.Kapitel 4 ITIL-unterstützende Werkzeuge Formulierung von Anforderungen entlang des Service Supports Sonja Bozionek. Interessant ist dann. ob unterstützende Werkzeuge verwendet werden sollen oder nicht. sind nur einige Gründe. Im Anschluss daran werden im Hauptteil die Funktionalitäten des Service Supports und die dazugehörigen spezifischen 109 . als auch die sich ergebenden Anforderungen mit den Funktionen von zwei ausgewählten Werkzeugen zu vergleichen.[Its07] Bei der Einführung von ITIL stellt sich unter anderem die Frage. sowohl Anforderungen an ein potentielles Werkzeug entlang des ITIL-Prozesses im Service Support herauszuarbeiten. die für eine verstärkte Standardisierung der IT sprechen. Gleichzeitig ist auch eine stärkere Serviceorientierung seitens der Unternehmen zu nennen. Linda Gerstenberger. Die Arbeit gliedert sich in einen Grundlagen. Grundsätzlich ist es nach ITIL freigestellt. Ziel dieser Arbeit ist es.[Nie07] Die Schaffung von standardisiertem Informationsfluss und das Bestreben gewonnene Informationen für eine optimalere (Kunden-)Nutzung in geregelte Formen zu bringen. Im Zusammenhang mit diesem Übergang ist auch der Begriff der IT Infrastructure Library (ITIL) in den letzten Jahren in Deutschland verstärkt im Fokus des Interesses.und einen Hauptteil sowie in ein Fazit. ob ein eingesetztes Werkzeug die Arbeit erleichtert und sie effizienter gestalten kann.

Quelle: Eigene Darstellung. in denen ein Rahmenwerk von IT-Service-Managementprozessen beschrieben wird.[Pfl05] Die folgende Abbildung gibt einen Überblick über die ITIL-Inhalte. An dieser Stelle schließt sich die Betrachtung der Werkzeuge an. zeigt die folgende Abbildung.110 ITIL-unterstützende Werkzeuge Anforderungen an die Werkzeuge näher betrachtet.1 Begriffsabgrenzungen ITIL In der heutigen Zeit wird es immer schwieriger. ITIL ist eine Sammlung von Büchern. wobei eine Unterscheidung in kommerzielle und open-source Werkzeuge vorgenommen wird. . Dieser Ansatz wird auch als IT Service-Management bezeichnet und wird durch den ITIL-Leitfaden unterstützt. ITIL hat sich im Laufe der Zeit als defacto Standard etabliert und ist mittlerweile weiträumig verbreitet. Für jedes Unternehmen ist es daher wichtig. Abbildung 4. ITIL ist somit kein Programm. wird versucht. In einem Fazit werden die wichtigsten Ergebnisse dieser Arbeit abschließend pointiert wiedergegeben. die Struktur innerhalb der IT bezüglich der Ausfallhäufigkeit oder der Verfügbarkeit zu optimieren. den Anforderungen einer ITInfrastruktur innerhalb von Unternehmen zu genügen und auf einem bestimmten Qualitätsniveau zu halten. die IT-Struktur an neue Anwenderbedürfnisse auszurichten und den neuen Anforderungen anzupassen.2.1: Überblick ITIL. Die Arbeit bezieht sich auf den Bereich des Service Supports. sondern fungiert als Richtlinie zur Strukturierung der eigenen IT-Abteilung im Unternehmen.2 4. Um diese Dienstleistung zu gewährleisten. Es existiert zu jedem Prozess ein Leitfaden sowie Empfehlungen zur Umsetzung. Welche Prozesse innerhalb dieses Bereichs stattfinden. 4.

unter einem Tool wird eine Software verstanden. die im Internet frei verfügbar sind und kommerzielle Angebote. Entlang dieser Prozesse werden im Kapitel 4. Aus der Vielzahl kommerzieller Produkte wird beispielhaft das Programm Remedy vorgestellt. Ein Ticket-System2 ist eine Verwaltungssoftware. Im Rahmen dieser Projektarbeit wird die Software Open Ticket Request System (OTRS) näher betrachtet. Der Supportleistende kann das Ticket öffnen. Wird eine bereits bekannte Anfrage an das System geschickt. . welche die Implementierung und Umsetzung von ITIL in den Unternehmen unterstützen.h.2: Überblick Service Support.[Här07] Die betrachteten Werkzeuge in dieser Arbeit basieren auf dem Ticket-System. Innerhalb dieser Software besteht die Möglichkeit. Dabei ist es unerheblich.[Bre07] Am Markt ist verschiedene Software erhältlich. Wesentlicher Bestandteil dieser Software ist das Ticket. Quelle: Eigene Darstellung. und sich vorab Informa1 Die Bezeichnungen "Werkzeug" und "Tool" werden in dieser Arbeit im weiteren Verlauf synonym verwendet. Die Auswahl von Tools gestaltet sich insofern als schwierig.3 die Anforderungen an ein Werkzeug herausgearbeitet. als dass in den ITIL-Büchern keine Bewertung der vorhandenen Tools vorgenommen wird und konkrete Aussagen ausbleiben.2. die die veränderte Situation im Unternehmen jetzt und in Zukunft unterstützt. Zu unterscheiden sind opensource Lösungen. diese Aufträge zu klassifizieren. zu bearbeiten oder sie weiterzuleiten. mit der mehrere Personen gleichzeitig Kundenanfragen und -aufträge verwalten können.Formulierung von Anforderungen entlang des Service Supports 111 Abbildung 4. erstellt das Programm automatisch eine Verknüpfung zu dem schon gespeicherten Vorgang.[Nie07] D. 2 Synonym wird die Bezeichnung Trouble-Ticket-System verwendet. 4. über welche Medienart die Anfrage im System eingeht.2 Werkzeuge Unter (ITIL)-Werkzeugen1 werden im Verlauf dieser Arbeit Computerprogramme verstanden.

4.3. Sobald Tätigkeiten gehäuft und wiederholt vorkommen. werden im Folgenden die einzelnen Prozesse von ITIL näher betrachtet. dem Problem Management. sowie dem Change Management. Es wird jedoch nicht nur ein Einblick in den jeweiligen Prozess gegeben.4 die Funktionen der Werkzeuge OTRS und Remedy darzustellen.3. Ursächlich für eine Störung und auch einen Service Request sind jeweils auftretende Anliegen.[Mar04] Durch eine Softwareunterstützung aber kann sich bei passendem Einsatz eine erhebliche Effizienzsteigerung ergeben.[Här07] Auf die genauere Ausgestaltung eines Ticket-Systems wird bei der Betrachtung von OTRS und Remedy näher eingegangen. sondern vielmehr ist an dieser Stelle von Bedeutung. welche wiederum zur Problemlösung verwendet werden können. welche Anforderungen sich jeweils für eine mögliche Softwareunterstützung durch ein eingesetztes Tool ergeben. Für die weitere Betrachtung werden zunächst die Begriffe Störungen und Service Requests definiert. Primäres Ziel ist es. dem Incident Management. um den Menschen zu entlasten und dabei die einzelnen Prozesse des Service Support funktionsfähig und zielführend abzubilden? Diese Anforderungen an ein Tool werden jeweils in den einzelnen Kapiteln herausgearbeitet. dem Release Management und dem Configuration Management. spricht man vom Schließen des Tickets. Prinzipiell besteht durchaus die Möglichkeit.1 Service Support und Anforderungen an die Werkzeuge Vorgehensweise Nachdem bisher ITIL und das Verständnis von Werkzeugen erläutert wurde. Dieses Kapitel gliedert sich somit in die einzelnen Prozesse des Service Support. da eine umfassendere Betrachtung im Rahmen dieser Arbeit aus zeitlichen Gründen nicht möglich ist. Doch was genau müsste eine ITIL-konforme Software können? Welche Fähigkeiten müsste sie haben. Der Fokus liegt hier ausschließlich auf dem Bereich des Service Support. ITIL fasst unter der Bezeichnung Incident Störungen und Service Requests zusammen.[Cla] Ist das Problem letztendlich gelöst. Die Möglichkeit zur Dokumentation der gesamten Daten wird auch Historiefunktion genannt. Aktivitäten durch Einsatz einer geeigneten Software zu automatisieren.3 4. die Grundsätze von ITIL im einfachsten Fall mit Papier und Bleistift umzusetzen. den IT-Service bei einem Incident wieder herzustellen und aufrecht zu erhalten. kann es sich lohnen." [Its07] Anfragen. um in Kapitel 4. 4.2 Incident Management mit Service Desk Das Incident Management bildet in Verbindung mit dem noch zu erläuternden Service Desk die Schnittstelle zwischen Anwender/ Kunden und dem Unternehmen. Unter einer Störung wird dabei "ein Ereignis [verstanden]. Es werden allgemeine Daten gespeichert. das nicht zum standardmäßigen Betrieb eines Service gehört und das tatsächlich oder potentiell eine Unterbrechung oder Minderung der Servicequalität verursacht. da ein größerer Informationsfluss schneller verarbeitet werden kann.112 ITIL-unterstützende Werkzeuge tionen zu dem vorliegenden Problem verschaffen. welche keine Störungen .

Ist der Help Desk zentral organisiert. Release Management und Configuration Management wichtige Informationen. für den Anwender zum gewünschten IT-Service. Es erfolgt häufig eine Gliederung in verschiedene Ebenen oder Bearbeitungsstufen. Bei der Bearbeitung der Störung unterscheidet man zwischen verschiedenen Leveln.[Fis06] Synonym zum Service Desk wird auch die Bezeichnung Help Desk verwendet. Zum einen als zentrale Einheit. Dies gilt nicht nur für das Incident Management. dass der Kunde nur einen SPOC als Kon3 Darunter wird der Service zur Unterstützung oder auch zur Hilfe von Anwendern von Hard. Change Management. also ob es sich um eine Anfrage eines Kunden im Sinne einer Änderung (Request for Change) handelt. sondern auch den Service Support-Prozessen Problem Management. Noch nicht abgeschlossene Vorgänge werden permanent überwacht und deren weiterer Verlauf verfolgt. Eine zentrale Stellung hat in diesem Bereich der bereits erwähnte Service Desk. welcher nun im Folgenden betrachtet wird. und den Abschluss bildet dann die Wiederherstellung des Service. werden die Anliegen über einen SPOC koordiniert und bearbeitet.h. Der Service Desk ist also in erster Linie die Schnittstelle für den Anwender. Kann das Problem auch an dieser Stelle nicht gelöst werden. er dient als Kontaktpunkt für den Kunden bzw. Es gibt unterschiedliche Möglichkeiten einen Help Desk zu organisieren. d. Diese Kommunikationsstelle wird auch als Single Point of Contact (SPOC) bezeichnet. wird er in dieser Arbeit innerhalb dieses Kapitels betrachtet. zum anderen als dezentrale Einheit.und Software verstanden. . dass es eine klare Abgrenzung der Kompetenzen geben muss. Außerdem liefert er nicht nur dem Incident Management. Hier wird deutlich. wenn es nicht sofort erledigt werden kann. um bei Bedarf jederzeit darauf zurückgreifen zu können. Jeder dieser Vorgänge wird umfangreich dokumentiert und gespeichert. die Kunden über den Verlauf des Anliegens zu benachrichtigen.Formulierung von Anforderungen entlang des Service Supports 113 im eigentlichen Sinne sind. Im weiteren Verlauf wird das Anliegen konkretisiert. in dem sich Experten damit befassen. werden unter dem Begriff Service Requests zusammengefasst. Diese werden durch den Service Desk bearbeitet und abgeschlossen. egal ob es sich um ein Incident oder um ein Request for Change (RFC) handelt.3 Zu den allgemeinen Aufgaben des Service Desk zählen im Wesentlichen die Entgegennahme der Anliegen des Kunden. wird es an das Third-Level weitergegeben. Kompliziertere oder umfassendere Anliegen werden vom Service Desk weitegeleitet und dort durch Fachkräfte oder Teams im Rahmen des Second-LevelSupports gelöst.[Its07] Service Desk Da der Service Desk nach ITIL kein Prozess sondern eine Funktion ist und damit eine Aufgabe erfüllt. Bezeichnet wird das als Multi-Level-Support-Modell. Vorteilig ist hier. Einfache Probleme oder Anfragen können oftmals direkt gelöst werden und werden als First-Level-Support bezeichnet. Die Aufnahme einer Störung im Service Desk ist dabei als Ausgangspunkt für das Incident Mangement zu nennen. oder ob es sich um eine Störung (Incident) handelt. Es besteht auch die Möglichkeit. Darunter fallen unter anderem Statusnachfragen und Fragen zur Handhabung. dessen grobe Einschätzung im Service Desk stattfindet. sondern auch für die Organisation aller weiteren Prozesse.

Dabei soll stets die Frage im Hintergrund stehen: An welchen Stellen ist eine Unterstützung durch ein Software-Tool besonders sinnvoll? Und welche Aufgaben müsste dieses Tool im Einzelnen übernehmen? Hierbei ist anzumerken. der innerhalb der Service Desk abläuft. Für dieses Wissen benötigen die Mitarbeiter weitere und permanente Schulungen. der innerhalb des Service Desks abläuft. kontaktieren die Kollegen aus dem First-Level-Support öfter die Kollegen aus den anderen Supports. welcher auch als virtueller Ansatz bezeichnet wird. Name. im Einzelnen durchgegangen. Dokumentation der Anliegen sind im Vorfeld grundsätzliche Entscheidungen zu treffen. Es muss also entschieden werden. Eine Lösungsmöglichkeit könnte der zentralisierte dezentrale Ansatz. Er muss sich nicht verschiedene Kontaktadressen merken. wird der Prozess. auf die anderen Prozesse verwiesen wird. zentral und geregelt vorzugehen. Es stellt sich die Frage nach der Art der Dokumentation. dass die Support-Mitarbeiter ein breiteres und umfassenderes Wissen für die verschiedenen Anfragen benötigen. so dass keine Abhängigkeit von der willkürlichen Arbeitsweise eines Service Desk-Mitarbeiters besteht. Uhrzeit der Kontaktaufnahme relevant. Nachteilig bei dieser Variante ist. Bei einem dezentralen oder lokalen Help Desk gibt es einen Service-Support für verschiedene Kundengruppen oder verschiedene Produktgruppen. Kann ein Mitarbeiter ein Anliegen nicht selber bearbeiten. Bre07] Um im Folgenden aus den Aufgaben und Zielen des Service Desk und damit auch des Incident Managements Anforderungen an mögliche Software-Tools abzuleiten. weil der Kunde länger auf seine Antwort warten muss. Kundennummer und Datum inkl. eng mit anderen Abläufen verknüpft ist. Für die Erfassung von Anliegen ist es ratsam.a.[Els06] Diese werden im Hinblick auf die obigen Fragen betrachtet: Anliegen entgegennehmen und registrieren: Die einzelnen Anliegen. dass der Prozess. so dass es zu einzelnen Überschneidungen kommt und ggf. Problematisch kann sich hier die nicht einheitliche Datenbank erweisen.114 ITIL-unterstützende Werkzeuge taktpunkt hat. können in verschiedener Form vorliegen. Der Ablauf innerhalb des Service Desks gliedert sich in verschiedene Punkte. Es lässt sich somit festhalten. ohne dass es in einer Datei gespeichert wird. Für die Zuweisung sind allgemeine Daten zum Kunden. die im Service Desk als erste Anlaufstelle eingehen. Für eine sinnvolle Erfassung bzw. Eine klare Grenze zwischen den Bereichen kann nicht immer gezogen werden. Ist dieses Wissen nicht vorhanden. um den Kunden kompetent zur Seite zu stehen. wird es an den zuständigen Help Desk weitergeleitet. Adresse. Hier erhalten die Kunden meist schnellere Hilfe als im zentralisierten Fall. Hier wären Anfragen in Form von E-Mail oder Telefon denkbar. welche Daten von Relevanz für die effiziente Be. sein. First-Level-Support. sondern kann seine Anliegen einer Stelle zutragen. Des Weiteren kommt es so zu einer Überlastung in den anderen Supporteinheiten. [Els06.und Verarbeitung sind. also u. Mehrere Supporter arbeiten an einem Problem. also wie die Daten erfasst werden sollen. wobei es zu einer Verzögerung gegenüber dem Kunden kommen kann. Des Weiteren müssen natürlich die spezifischen Gegebenheiten des aktuellen Anliegens erfasst werden. also nur eine Kontaktstelle. Hinter dieser verbergen sich jedoch dezentral weitere Service-Desk Supports. haben dadurch aber auch mehrere Kontaktstellen. . Hier existiert aus Sicht des Kunden nur ein Help Desk.

Je größer ein Unternehmen jedoch ist oder je mehr Störungsfälle auftreten. so muss der Mitarbeiter weitere Schritte einleiten.Formulierung von Anforderungen entlang des Service Supports 115 dass die Mitarbeiter einheitlich vorgehen müssen. sogar schon bekannt ist. sollte er für eine weitere Unterstützung des Kunden sorgen. oder ob das Problem evtl. Dadurch kann nicht nur Zeit gespart werden. der aufgrund der Eingaben des Mitarbeiters auch eine Klassifizierung erleichtert. wie bei allen Interaktionen zwischen den einzelnen Prozessen. die sich im Unternehmen wiederfinden. So ist es für den Mitarbeiter zeitsparend. kann eine Art Bewertungsbogen generiert werden. per Schlagwortsuche nach vorherigen Störungsfällen zu suchen. Liegt eine Störung vor. wenn das manuelle Suchen in langen Archivlisten entfällt und ein Tool ihm die Möglichkeit bietet. sondern handelt es sich um eine Anfrage für eine Änderung. . muss er eine erste Einordnung des Anliegens vornehmen. die Anliegen der Kunden zu identifizieren. Dies ist natürlich stets verbunden mit den jeweiligen spezifischen Gegebenheiten. Liegt bei dem Kunden keine Störung vor. er selbst jedoch nicht lösen kann. Wichtig ist hier. oder gibt es eine unbekannte Störung. Der weitere Ablauf in diesem Fall wird somit bei der Behandlung des Change Managements wieder aufgegriffen. die nicht nur von der Entscheidung des Mitarbeiters abhängt. dass der Mitarbeiter auch alle relevanten Informationen des Kunden strukturiert erfasst. Liegt jedoch eine akute Störung beim Kunden vor. Dazu muss er herausfinden. um die Störung möglichst schnell weiter zu klassifizieren und bestenfalls sogar gleich zu beheben. umso schwerer wird es sich vorzustellen. Im Gegensatz zu einer einfachen Niederschrift des Problems kann mit Hilfe der Datenbank strukturiert vorgegangen werden. sondern es ist zudem noch gewährleistet. Handelt es sich jedoch um eine bekannte Störung. Klassifizierung des Anliegens: Sobald der Mitarbeiter alle relevanten Daten des Vorgangs aufgenommen hat. Hierbei ist es ein Vorteil für den Mitarbeiter. entscheidet sich sein weiteres Vorgehen. dass der Mitarbeiter dies ohne technische Unterstützung leisten kann. so dass eine mehrmalige Registrierung eines Anliegens ausgeschlossen werden kann. Dies kann in kleinen Unternehmen oder in einem überschaubaren Umfeld natürlich eine selbst erstellte Liste oder einfach das Gedächtnis eines Mitarbeiters sein. Es sollte möglich sein. dass eine gute und problemfreie Kommunikation erfolgt. zum Problem Management. zu dessen Lösung der Service Desk Mitarbeiter alleine in der Lage ist. Auch die Behandlung dieser Fälle wird an entsprechender Stelle wieder aufgegriffen. welche im Service Desk eines Computerlieferanten auftreten natürlich andere. um welche Art von Störung es sich handelt. So ist es für ihn an dieser Stelle hilfreich. wenn er auf ein gutes Archiv vergangener Fälle zurückgreifen kann. wenn er die einzelnen Daten in einer bereits fertigen Maske in die dafür vorgesehenen Felder eintragen kann. dass eine strukturierte Erfassung des Anliegens möglich ist. leitet der Mitarbeiter des Service Desks die Daten zum Change Management weiter. Das Tool soll den Mitarbeiter des Service Desk dahingehend unterstützten. Um eine Klassifizierung vorzunehmen. Sobald der Mitarbeiter die Störung an dieser Stelle klassifiziert hat. Die Dokumentation der Anliegen in einer Datenbank ist eine sinnvolle Vorgehensweise. erfolgt eine Weiterleitung im Incident bzw. als die bei einem Telekommunikationsunternehmen. die zwar bekannt ist. So sind die Anliegen.

Da sie ein größeres Fachwissen besitzen als die Service-Desk Mitarbeiter. Die Anforderungen an ein eingesetztes Tool sind ähnlich zu denen des Service Desk. der Mitarbeiter im Service Desk das Anliegen nicht lösen kann. So gilt es auch an dieser Stelle Zeit zu sparen und die Suche nach einer Lösung durch den Einsatz eines Software-Tools zu beschleunigen. Hat der Mitarbeiter eine Lösung gefunden. Auch dies setzt das Vorhandensein und die kontinuierliche Pflege eines guten und vollständigen Archivs voraus. dessen oberste Priorität die Wiederherstellung des Services ist. da eine schnellstmögliche Wiederherstellung des Service das oberste Ziel des Service Desk ist. dies nützt jedoch nichts. Third-. Dort beschäftigen sich spezialisiertere Support-Teams. d.h.116 ITIL-unterstützende Werkzeuge Bearbeitung von Störungen: Nachdem die Störung klassifiziert wurde und bekannt ist. wenn der Mitarbeiter auf eine gut gepflegte Datenbank zugreifen kann. Second-. so erfolgt eine Weiterleitung an den Third-Level-Support. Ist auch hier der Abschluss nicht möglich. findet ein Abschluss der Störung statt. Ggf. die Datenbank noch vielfältiger zu nutzen.[Its07] Analyse und Diagnose: In diesem Bereich beschäftigen sich die Experten mit der weiteren Analyse. bis die Störung abgeschlossen wird. An dieser Stelle knüpft die Aufgabe . Abschluss oder Weiterleitung: Sobald eine Lösung gefunden wurde. erfolgt nun die Weiterleitung an den Second-LevelSupport.3. so dass er für spätere Anliegen auch als Recherche zur Verfügung steht. wenn sie nicht durch die Mitarbeiter ständig gepflegt und aktualisiert wird. 4. So ist es sinnvoll. kann dem Kunden geholfen werden und eine schnelle Wiederherstellung des Service erfolgen. erfolgt eine Weiterleitung an das Problem Management. Dieser muss natürlich auch in der Datenbank dokumentiert werden. Dieser besteht aus Spezialisten-Teams. Da bisher keine sofortige Lösung der Störung vorhanden ist. Falls das Problem innerhalb des First-Level-Supports nicht abgeschlossen werden kann. Ein Tool kann die Suche innerhalb dieser Daten vereinfachen. so wird es an den Second-Level-Support weitergeleitet. Nur durch die korrekte und vollständige Erfassung des Vorgangs durch den Mitarbeiter können für zukünftig auftretende Probleme zeitnah Lösungen gefunden werden. gilt es nun eine Lösung zu finden und die Störung zu beheben. findet hier eine intensivere Suche statt. Dieser Vorgang wird auf N-Leveln wiederholt. weiter mit dem Problem. wenn bei der vorherigen Suche nach einer Störung auch gleich eine oder mehrere mögliche Lösungsvorschläge dazu vermerkt sind. Abschluss & Speicherung des Lösungsweges in der Datenbank: Ist der Service wieder hergestellt. die sich analog zum Ablauf im Second-Level-Support mit dem Anliegen befassen.3 Problem Management Vorangehend wurde das Incident Management betrachtet. und N-Level-Support. dessen Ziel die Diagnose der Störung ist. Bei dieser Tätigkeit ist es möglich. die nach Fachbereichen gegliedert sind. Wie zuvor erläutert spart es viel Zeit. muss der Vorgang abgeschlossen und das Problem mit der Lösung in einer Datenbank vermerkt werden.

Man . wie Hardware-Fehler. Während das reaktive Problem Management nach Ursachen bereits eingetretener Störungen sucht und Verbesserungsvorschlägen macht. so dass durchaus zeitgleich verschiedene Experten einzubinden sind. Die Lösung dieser Probleme ist vielfach kompliziert und aufwendig. Die Auswirkungen dieses Problems sollen minimiert und ein Lösungsweg zur endgültigen Beseitigung der Störung erarbeitet werden. Die fehlerhafte Komponente ist identifiziert. die einer Störung zugrunde liegen. Außerdem sollen hier durch vorausschauendes Handeln Probleme und längerfristige IT-Systemunterbrechungen vermieden werden. die Error-Control und das Proactive Problem Management. Die Tätigkeitsfelder der Problem. Ist die Ursache gefunden liegt nun kein Problem mehr vor. Els06] Mit dem Problem Management werden verschiedene Ziele verfolgt.und Error-Control sind verknüpft. meist nur sehr selten festgestellt. In ITIL wird das Problem Management in drei Subprozesse unterteilt. Dies ist zum einen die Eliminierung der Ursachen der auftretenden Probleme und zum anderen. Dort werden die Ursachen.Formulierung von Anforderungen entlang des Service Supports 117 des Problem Managements an und bildet somit eine Art zweite Ebene des Incident Managements. Sobald für einen Fall keine Ursache festgestellt werden kann. Um diese komplexen Vorgänge erfassen zu können. Daran anschließend erfolgen die Untersuchung des Problems und dessen Auswirkungen auf den Service. Gegebenenfalls werden durch das Problem Management notwendige RFCs in der IT-Infrastruktur eingeleitet.[Els06] Problem-Control. bekommt ein Incident die Bezeichnung Problem. Die Problem-Control befasst sich mit der Problembearbeitung.[Els06] Klassifizierung und Kategorisierung des Problems: In dieser ersten Stufe treffen die Probleme ein. klassifiziert und abgespeichert. die durch das Incident Management von einer Störung zu einem Problem deklariert und weitergeleitet worden sind. Für diese Vorkommnisse können unterschiedliche Ursachen vorliegen. die eigentliche Ursache für das Auftreten von Störungen zu ermitteln. Wie die Abläufe der einzelnen Prozesse des Problem Managements nun genau aussehen und welche Anforderungen sich an ein Software Tool dadurch ergeben. Außerdem sollte das Problem Management versuchen bereits im Vorfeld. So kann ein bestimmter Abbruch durch ein Aufeinanderfolgen bestimmter Fehlerquellen herbeigeführt werden. So ist es Aufgabe des Problem Managements. Für eine genauere Analyse wird der Prozess der Problem-Control vereinfacht dargestellt. ähnlich wie beim Incident Management. Soweit möglich sollen hier die Ursachen gefunden werden. Netzwerkfehler oder Betriebssystemabstürze. bedarf es anderer Prozessverläufe als beim Incident Management. soll nun im Einzelnen herausgearbeitet werden.[Fis06. Beispiele in der IT gibt es viele. versucht das proaktive Problem Management Schwachstellen aufzuspüren und Störungen im Vorfeld zu verhindern. Diese umfassen sowohl reaktive als auch proaktive Aktivitäten. da unter anderem ein Problem durchaus auf mehrere Incidents zurückgeführt werden kann und sie wiederholt auftreten. dessen Ursache bekannt ist. sondern ein Known Error. eine Aufrechterhaltung der ITDienstleistungen. das Problem ist jedoch noch nicht behoben. In dieser ersten Phase des Problem Managements werden die vom Service Desk und Incident Management weitergeleiteten Probleme beschrieben. das Auftreten von Störungen durch vorbeugende Maßnahmen zu minimieren. die Problem Control. Als Known Error wird dann ein Problem (oder Incident) bezeichnet. also proaktiv.

welche Auswirkungen es auf geschäftliche Abläufe geben kann. welche Priorität es hat und wie der aktuelle Status des vorliegenden Problems lautet. z. mit dem die eingegebenen Informationen zu jeglichen Vorgängen prozessübergreifend eingesehen und verwendet werden können. wie eigentlich überall. Analyse und Diagnose des Problems: Nun erfolgt eine Analyse der für das Problem zuständigen Experten. um das Problem immer weiter einzukreisen. müssen die Daten dem für das Problem zuständigen Experten zugewiesen werden.118 ITIL-unterstützende Werkzeuge spricht von Problemen. Abschluss des Problems oder Überleitung zur Error Control: Ist das Problem identifiziert. dass sie in unterschiedliche Gruppen unterteilt werden. Dieses Vorgehen kann ein Tool insofern erleichtern. Somit wird dem Mitarbeiter einerseits die Zeit erspart. Diese Arbeit kann ein Tool erleichtern. Zuweisung zum Problem-Management Experten: Bevor die genaue Untersuchung und eine zeitnahe Lösung des Problems angestrebt werden kann. Auch hier ist ein Tool hilfreich. dass außerdem eine gute und ständige Kommunikation zwischen den einzelnen Prozessen stattfindet. erfolgt ein Abschluss in der Problem Control. die übrigen Mitarbeiter eigenhän- . indem es durch eine fertige Maske dem Mitarbeiter die Eingabe der Daten erleichtert und außerdem dafür sorgt. indem es automatisch Rückmeldung über die identifizierten Probleme und den Problemlösungsfortschritt zu den anderen Prozessen gibt. Die Untersuchung und die Diagnose des Problems kann ein langwieriger Prozess sein.oder ManagementProzessen geliefert. wobei es hilfreich ist. B. sowohl den Verlauf eines Problems zu dokumentieren als auch die Interaktion mit den anderen Prozessen ausreichend abzubilden. Bei der Identifikation müssen die Daten. welche Ursache einem Problem zugrunde liegt. die zu einem Problem gehören. wenn mit einem wiederholten Auftreten gerechnet wird. welche Dringlichkeit dem Problem zugesprochen wird. Das Problem wird beschrieben und erfasst. Es muss erfasst werden zu welcher Kategorie sie gehören. indem es nach der Klassifizierung des Problems die für das Problem verantwortliche Person kennt.[Its07] Auch zur Aufnahme dieser Daten kann ein Tool eine strukturierte Vorgehensweise ermöglichen und unterstützen. per E-Mail automatisch über das Problem inklusive aller darüber vorhandenen Daten informiert werden. Dazu werden wiederholt Tests durchgeführt. eine Verknüpfungen zu den zuständigen Problemlösern bereitstellt und diese Experten. Auch hier kann ein eingesetztes Tool helfen. erfasst und in eine Datenbank eingestellt werden. Wichtig ist hier. die Daten strukturiert und vollständig zu erfassen. Hierbei findet ständiger Kontakt mit den anderen Prozessen statt. ähnlich wie bei einer Störung. dass auch die anderen Prozesse über den aktuellen Stand und die Identifizierung des Problems informiert werden. Die Lösung des vorliegenden Problems erfolgt dann in der sich anschließenden Error-Control. die Daten der im Vorfeld aufgenommenen Störung vorliegen zu haben. Notwendige Informationen zur Untersuchung des Problems werden also von und zu den anderen ITIL. bei dem versucht wird herauszufinden. Wichtig ist zu diesem Zeitpunkt. Des Weiteren müssen die Probleme insofern klassifiziert werden. dass die Daten auch von anderen Mitarbeitern schnell wiedergefunden werden können. Hier müsste ein Tool in der Lage sein.

[Els06] Identifizierung des Fehlers : Für die Known Errors. dass der bekannte Fehler weiter auftreten kann. Auch hier wird der dort stattfindende Prozess vereinfacht dargestellt. Alle Lösungsaktivitäten. mit einer Änderungsanforderung des Problem Managements an das Change Management. Abschließend müssen die anderen Prozesse über die Lösung informiert werden. damit auch im Nachhinein nachvollzogen werden kann. Der Fortschritt des Lösungswegs der bereits bekannten Fehler wird weiter überwacht. Dazu werden eine Reihe von Komponenten. Somit kann sichergestellt werden.Formulierung von Anforderungen entlang des Service Supports 119 dig zu informieren und andererseits auch sichergestellt. die er vollzieht. dass der Mitarbeiter auf bereits vorhandenes Lösungswissen einer Datenbank zugreifen kann. Datensammlungen und Programmen benötigt. Auch hier muss er mit Unterstützung eines Tools in der Lage sein. sind die Lösungswege bereits bekannt und können aus einer gut gepflegten Datenbank entnommen werden. auf die notwendigen Informationen der anderen Prozesse zugreifen zu können. dass die Lösung umfassend dokumentiert wird. Für die Ermittlung neuer Fehler sollten dem Mitarbeiter mehrere Hilfsmitteln zur Fehlersuche zur Verfügung stehen. Auch hier gilt es nochmals zu . für das Incident Management besonders wichtig. müssen von ihm dabei natürlich auch festgehalten werden. Ermittlung eines Lösungswegs: Für die ermittelten Fehler müssen nun neu initiierte Lösungswege gefunden werden. Damit soll verhindert werden. ist es wichtig. wird das Problem zu einem Fehler und die Fehlerbehandlung nimmt ihre Arbeit auf.a. da somit eine schnelle Verwendung der neuen Lösungen dort gewährleistet ist. auch zu keiner Lösung führten. Bei der Error-Control erfolgt nun eine Fehlerbearbeitung. die an dieser Stelle eintreffen. Error-Control. welches ihm bei der Ermittlung einer neuen Lösung helfen kann. Eine automatische Benachrichtigung an die betroffenen Anwendergruppen durch ein eingesetztes Tool erleichtert und beschleunigt auch hier die Arbeit. dass eine Lösung nochmals neu erarbeitet werden muss. da er schnell behoben werden kann und eine endgültige Beseitigung zu zeit. in dem die Ursache des Problems festgestellt wurde. dass niemand diese Informationen verspätet oder gar nicht erhält. Dies ist u. Diese führt bestenfalls zu einer Beseitigung des Fehlers. Die Auswirkungen der gefundenen Lösung müssen weiter beobachtet werden. welche Lösungsvorschläge ggf. ggf. Im Rahmen der Error-Control werden Lösungswege neu ermittelter Probleme erarbeitet und im Bedarfsfall ein RFC an das Change Management gestellt. Für die Known Errors sind die Ursachen und die Lösungsaktivitäten bereits bekannt und können eingeleitet werden. dass auch die Lösungen in Zukunft auftretender Probleme schnell in einer Datenbank gefunden werden können. weil sie vorher nicht vollständig dokumentiert wurde und somit viel Zeit kostet.oder kostenintensiv wäre. Eine Lösung kann auch so aussehen. In dem Augenblick. um in der Zukunft Zeit zu sparen.[Its07] Dokumentation der gefundenen Lösung: Wie auch immer die vorher getroffene Lösung aussieht. Nach der Lösungssuche wird dann eine optimale Lösung bestimmt. also einem RFC. Hierbei ist es notwendig. Systemen.

120

ITIL-unterstützende Werkzeuge betonen, dass eine stetige Kommunikation der einzelnen Prozesse für einen erfolgreichen Abschluss zwingend notwendig ist.

Proactive Problem Management. Das Proactive Problem Management behandelt die frühzeitige Identifikation eines Problems oder allgemein die Erkennung von Schwächen in der Infrastruktur durch Trendanalysen. Somit ist es kein Prozess im eigentlichen Sinn. Es sollen Vorkehrungen getroffen werden, um ein Problem bestenfalls gar nicht erst entstehen zu lassen. Dazu können bereits aufgetretene Störungen und deren Lösungen analysiert werden, um mögliche Probleme schon im Vorfeld zu erkennen. Das Proactive Problem Management erfüllt folgende Aufgaben ([Els06]): Erstellung von Trendanalysen: Zur Einführung des Problem Managements wird es überwiegend reaktiv sein, allerdings sollte eine Entwicklung hinsichtlich proaktiver Mechanismen erfolgen. Eine Aufgabe darin ist die Erstellung von Trendanalysen. Hierbei könnte ein Tool insofern hilfreich sein, als dass es bereits eine Funktion enthält, um eine Trendanalyse der einzelnen Tickets zu erstellen, d.h. Themen und Vorfälle, die wiederholt auftreten, sollten angezeigt werden und eine Auswertung der Daten somit erleichtert werden. Somit können Komponenten, die anfällig sind, oder bei denen eine Überlastung droht, genauer beobachtet werden. Genauso wird versucht, Störungen, die in einem Bereich auftreten, bereits im Vorfeld in anderen Bereichen zu verhindern. Weiterleitung von Auswertungen an das IT-Management: Die Analysen und Auswertungen sind natürlich nur dann nutzbar, wenn die Informationen auch allen anderen bereitgestellt werden. Genau wie die Lösungen eines Problems müssen auch die im Vorfeld ermittelten Schwächen an die anderen Prozesse weitergeleitet werden. Die Aufgabe eines Tools könnte es hierbei sein, sobald an einer Stelle eine Schwäche identifiziert wurde, die Informationen automatisch an die betroffene Stelle weiterzuleiten und zu informieren, ohne dass dies viel Zeit und Aufwand in Anspruch nimmt.

4.3.4

Change Management

Wie bereits im Kapitel 4.3.2. erwähnt, nehmen die Mitarbeiter des Service-Desk zunächst alle Anliegen entgegen. Diese werden aufgenommen, und strukturiert in einer Datenbank erfasst. Wenn sich bei der Kategorisierung nun herausstellt, dass es sich um einen RFC handelt, wird es an das Change Management weitergeleitet. In diesem Abschnitt geht es nun um die Aufgaben, Funktionen und Ziele des Change Managements. Die Erfahrung hat gezeigt, dass Probleme und Störungen häufig auf Änderungen zurückzuführen sind. Ursache dieser Probleme sind oftmals überstürzte und wenig durchdachte Änderungen, oder unzureichende Planungen im Vorfeld.[Its07] Das Change Management soll nun gewährleisten, dass die oben genannten beantragten Änderungsanforderungen in Form von RFCs geplant und kontrolliert ablaufen. Hierbei ist darauf zu achten, dass änderungsbedingte Störungen zu vermeiden oder wenigstens zu minimieren sind.[Fis06] Voraussetzung für Änderungen ist jedoch, dass diese im Vorfeld genau überprüft und kontrolliert werden, ob die Changes ohne weitere Rücksprache durchgeführt werden können. [Bre07] Die RFCs können im Wesentlichen in drei Bereiche aufgeteilt werden ([Its07]):

Formulierung von Anforderungen entlang des Service Supports

121

Neuerungen und Verbesserungen: Diese beinhalten neue Methoden und Konzepte, sowie technische Verbesserungen. Dadurch können neue strukturelle Fehler und Probleme entstehen, die vorher in dieser Art und Weise nicht bekannt waren. Änderungen: Änderungswünsche können sich auf Soft- und Hardwareänderungen beziehen oder auch auf Betriebssysteme. Aber auch Modernisierungen oder der Austausch von Kabeln und/oder Hardware gehört in diesen Bereich. Korrekturen: Diese sollen die strukturellen Fehler und Probleme beheben. Im weiteren Verlauf wird auf diese Unterteilung nicht weiter eingegangen, und zur Vereinfachung wird der Ausdruck Änderungen oder Change für alle Anliegen verwendet. All diese Änderungen sind mit einem gewissen Risiko behaftet und können zu einem Ausfall der Service-Leistungen führen. Es muss jedoch nicht nur darauf geachtet werden, dass die Änderungen schnell und ohne Komplikationen durchgeführt werden, ebenso wichtig ist es auch, dass das System hinterher konsistent und ohne Fehler und Probleme funktioniert. Aus diesem Grund muss eine Änderung geplant werden, und kann nicht ad hoc durchgeführt werden. Es ist auch darauf zu achten, ob nur ein Mitarbeiter betroffen ist, oder die ganze Belegschaft eines Unternehmens. Diese Faktoren zu berücksichtigen ist die Hauptaufgabe des Change Managements. Zusätzlich zu beachten ist, dass Soft- und Hardware selten kostenlos zur Verfügung gestellt werden. Es ist daher nicht ohne weiteres möglich, ohne Lizenzprüfung die Programme zur Probe zu installieren. Auch die Bevorratung der benötigten wichtigsten Ersatzteile ist Aufgabe dieses Supports. Zusammengefasst lässt sich sagen, dass sich die Aufgaben aus einem Zeitmanagement und aus vorbereitenden Aufgaben zur Implementierung von Änderungen zusammensetzen. Nicht zu vergessen ist die permanente schrittweise und aktuelle Dokumentation aller Handlungen von jedem Mitarbeiter. Nur durch diese sorgfältige Vorgehensweise wird eine effiziente und kostengünstigere Arbeitsweise auf Dauer gewährleistet.[Els06] Um nun auch hier aus den Aufgaben und Zielen des Change Manangement Anforderungen an mögliche Software-Tools abzuleiten, wird auch hier der Prozess, der innerhalb des Change Managements abläuft, im Einzelnen durchgegangen. [Els06] In einem ersten Schritt wurden die Daten im Service Desk als Change deklariert und dann an das Change Management weitergeleitet. Erfassung des RFC, Kontrolle und Speicherung in der Datenbank: Wichtig ist vor allem die korrekte Erfassung der Änderung in Form eines RFCs. Hier decken sich die Anforderungen an ein Tool mit den Anforderungen aus dem Service Desk. Hier wäre es demnach auch wieder von Vorteil, wenn für diese Erfassung eine vorgegebene Maske existiert, so dass die wichtigen und wesentlichen Elemente erfasst werden müssen, um überhaupt im Programm weiterzuarbeiten. Wichtige Informationen können eine Identifikationsnummer, der Auslöser des Changes, eine Begründung für die beantragte Änderung, Datum der Beantragung und Datum der geplanten Durchführung sein. Dieses Verfahren schützt den Benutzer vor der Gefahr, wichtige Daten bei der Eingabe zu übersehen. Im weiteren Verlauf muss noch geklärt werden, ob der Antragsteller auch

122

ITIL-unterstützende Werkzeuge berechtigt ist, diesen Änderungswunsch anzubringen. Ist das nicht der Fall, wird das RFC sofort abgelehnt. Wünschenswert wäre an dieser Stelle, wenn das Programm diese Kontrolle automatisch durchführt, indem sie den Antragsteller mit den hinterlegten berechtigten Personen abgleicht und bei entsprechendem Verstoß automatisch eine E-Mail verschickt, dass diesem Änderungswunsch nicht weiter nachgegangen werden kann. Dieser wird mit der entsprechenden Begründung versehen. [Its07] Nach der Erfassung erfolgt eine Kontrolle auf eventuelle Doppelerfassung oder auch auf nicht durchführbare RFCs. Diese Änderungen sollten dann automatisch mit einer entsprechenden Begründung abgewiesen werden. Zudem werden dann auch nach der Akzeptanz des RFCs weitere Informationen hinzugefügt, wie z.B. die Beurteilung der Auswirkungen. Das geplante Datum zur Umsetzung und auch der aktuelle Bearbeitungsstatus sollte angezeigt werden. Im weiteren Verlauf wird eine Prioritätsstufe bzw. eine Kategorisierung vorgenommen. Unter Priorität wird die Dringlichkeit des Changes verstanden. Die Kategorie bestimmt sich aus der Grundlage und den Auswirkungen der Änderungen. Nach ITIL werden die Prioritäten in vier Bereiche eingeteilt. Es reicht von der höchsten, über die hohe und normale Priorität bis zur niedrigen Priorität. Die Kategorien werden eingeteilt in geringfügige, erhebliche und weitreichende Folgen. Auch hier wäre es angenehmer, wenn das Programm schon einen Vorschlag für die Kategorie bzw. Priorität macht. Dieser Vorschlag könnte auf vorhandenen RFCs aufbauen, bei denen es zum Beispiel um eine ähnliche Angelegenheit geht, oder auch um eine gleiche Dringlichkeit.

Erstellung von Zeit-/Installationsplänen und deren Implementierung: Nachdem das RFC genehmigt wurde, muss nun bedacht werden, wie umfangreich diese Änderung ist, um daraus Rückschlüsse auf die benötigte Mitarbeiteranzahl und auf die benötigten Arbeitsstundenzahlen zu ziehen. In diesem Punkt arbeitet das Change Management eng mit dem Release Management zusammen, denn dieses ist dafür verantwortlich, dass genügend Ressourcen zur Verfügung gestellt werden. Von Vorteil ist es hier auch, wenn das Change Management im permanenten Kontakt zu den anderen laufenden Projekten steht, um sich auch hier immer wieder über den aktuellen Stand zu informieren. Ein weiterer Punkt ist das Erstellen eines Backout-Verfahrens. Dieses bietet die Möglichkeit, die Änderung wieder rückgängig zu machen, wenn diese nicht das erwünschte Ergebnis liefert. Das Change Management darf ein RFC nicht ohne Backout-Verfahren genehmigen. Auch hier ist es von Vorteil, wenn das Programm einen Hinweis gibt, wenn kein Backout-Verfahren verzeichnet ist, damit es nicht zu Schwierigkeiten nach einer unzulässigen Genehmigung kommt. Freigabe der Änderung, Evaluierung und Abschluss: Nach der Freigabe durch das Change Management sollte eine Evaluierung durchgeführt werden. Dabei ist allerdings zu beachten, dass standardisierte Änderungen nicht jedes Mal evaluiert werden müssen, bzw. dies in abgeschwächter Form erfolgen kann. Wünschenswert wäre hier ein Evaluierungsprogramm, in dem man gewisse Kriterien ausfüllen muss, so dass eine Vergleichs-

Formulierung von Anforderungen entlang des Service Supports

123

möglichkeit entsteht. Letztendlich liegt es im Verantwortungsbereich des Change Managements, die Änderung einzuführen und auch zu überwachen. Voraussetzung hierfür ist eine detaillierte Dokumentation und permanente Aktualisierung. Hilfreich ist somit eine Evaluierung in Form eines geeigneten, selbstentwickelten Fragebogens, der es ermöglicht, standardisiert vorzugehen.

4.3.5

Release Management

Die umfassende Planung und Durchführung von Hard- und Softwareeinführungen findet im Release Management seine Umsetzung. Das Hauptaugenmerk des Release Managements liegt auf der Stabilhaltung der IT-Infrastruktur.[Bre07] Unter einem Release wird eine „Reihe neuer oder geänderter KonfigurationsElemente 4 , die zusammenhängend getestet und in die Produktionsumgebung überführt werden“ [Its07] verstanden. Ein Release kann dabei ein vorhandenes CI ersetzen oder aber neu sein.[Els06] Releases werden unterteilt in MajorReleases, welche erhebliche Änderungen bzw. Erweiterungen der Funktionalität zur Folge haben, in Minor-Releases, welche geringfügige Änderungen bewirken, und in Emergency Fixes, welche vorübergehend kurzfristige Änderungen vornehmen.[Its07] Es werden drei Release Arten Full-, Delta- und PackageRelease differenziert.5 Die Dokumentation der Releases erfolgt innerhalb der Definitive Software Library (DSL) und dem Definite Hardware Store (DHS). In der DSL werden alle freigegebenen Software Releases, die Masterkopien der Software, und deren zugehörige Dokumente aufgeführt. Sie sollte von den im Folgenden noch zu erläuternden Prozessen des Release Managements losgelöst sein. Im DHS sind alle Hardware Ersatzteile enthalten. Diese beiden Datenbanken stehen in Verbindung zur Configuration Management Database (CMDB), welche den Prozess von der Planung bis zur Umsetzung dokumentiert und im Configuration Management erläutert wird.[Its07] Bezüglich der Erfassung innerhalb der Datenbanken muss man sich dann neben der Identifikationsnummer für verschiedene Datenfelder entscheiden, nach denen die Inhalte der Datenbanken aufgeführt werden sollen. Zu beachten ist, dass eine eindeutige Identifikation möglich wird. So kann zwischen Releases schon durch die Anordnung der Versionsnummer unterschieden werden.6 Außerdem gilt auch im Hinblick auf die Verwendung eines Tools, dass grundsätzliche Entscheidungen für die Arbeit mit den Datenbanken getroffen werden sollten. Da stets verschiedene Personen mit diesen Datenbanken arbeiten, ist ein standardisiertes Vorgehen auch für die spätere Verwendung und Anbindung an weitere Prozesse von Nutzen. Ein einheitliches Vorgehen erleichtert im weiteren Verlauf auch den Zugriff auf die vorhandenen Informationen. Darunter fällt neben Art der Darstellung auch die Pflege der Daten, d.h. dass sie sich stets auf dem neusten Stand befinden. Eine fortlaufende Kontrolle der Datenbanken ist somit zu empfehlen, sie stehen auch im fortwährenden Austausch mit den Aktivitäten, welche im Release Prozess angesiedelt
4 Konfigurations Elemente bzw. Configuration Items werden im weiteren Verlauf der Arbeit mit dem Akronym CI abgekürzt. 5 Ein Full-Release bezeichnet dabei einen kompletten Austausch eines Releases, während bei einem Delta-Release Changes an einem einzigen Release vorgenommen werden. Ein PackageRelease wiederum ist der Austausch zusammenhängender CIs.[Els06] 6 Beispiel: Version 1.0 für ein Major Release, Version 1.1 für ein Minor Release und Version 1.1.1 für einen Emergency Fix.

Zwar sind einige der Aktivitäten variierbar. Entwicklungsumgebung. In der Entwicklungsumgebung findet der Release Build statt. Es kann daher nur Ziel bei der weiteren Betrachtung sein. dass die einzelnen Releases bereits nach bestimmten Kriterien gekennzeichnet werden. ein standardisiertes Verfahren zu entwickeln. Einzeltests. welche von den involvierten Mitarbeitern ausgefüllt werden müssen und an die entsprechenden Stellen weitergeleitet werden. also die Erarbeitung der Release-Richtlinien. Für eine Kontrolle und Überwachung des Transports . so dass die Identifikation jedes Release eindeutig möglich ist. Dem Release Management obliegt die Überwachung der Verteilung bis hin zur Installation und Übergabe von Software und Hardware an den Nutzer. den aktuellen Entwicklungsstand besser nachvollziehen zu können. Für die Roll-Out-Planung ist der bis hierhin erstelle Release-Plan der Ausgangspunkt. Die Bearbeitung der Releases ist in jedem Unternehmen sehr spezifisch. Die Aktivitäten des Release Managements sind in die Bereiche Entwicklungsumgebung. Dies beinhaltet die Planung und Festlegung der Versionsgrundsätze.[Its07] Überwachte Testumgebung. Denkbar sind für ein derartiges Vorgehen prozessbezogene Checklisten. überwachte Testumgebung und Produktionsumgebung unterteilt. welcher jetzt um die Implementierungspläne erweitert wird.124 ITIL-unterstützende Werkzeuge sind.[Els06] Im Folgenden wird näher auf die Bereiche und die darin angesiedelten Prozesse eingegangen. die ähnlich seiner späteren ist. und die Erfassung der Testdaten muss für eine spätere Auswertung erfolgen. am besten in einer Umgebung. so dass diesem Bereich ein hohes Maß an Aufmerksamkeit zukommen sollte. so dass ein Release-Plan erstellt wird. ein Aktionsplan erstellt und die Vorbereitung für die Kommunikation getroffen werden. aber im Sinne einer strukturierten Planung sollte ein einheitliches Vorgehen angestrebt werden.[Els06] Für die Abnahme eines Releases muss dieses vorher ausführlich getestet werden. Tests auf Anwenderfreundlichkeit. Produktionsumgebung. Jetzt muss ein genauer Zeitplan für das Roll-Out entworfen. die Planung des Roll-Out sowie die Kommunikationsvorbereitung und Schulung angesiedelt. Die Tests erstrecken sich über Installationstests. Aufbau und die Formierung des Releases vorgenommen. welches dann für einen einheitlichen Ablauf steht. Im Bereich der überwachten Testumgebung ist die Versionsprüfung und Abnahme des Realeses. Bei der notwendigen Vielfältigkeit dieses Tests ist auch hier eine vorherige einheitliche Planung anzuraten. Es muss darauf geachtet werden. Change und Problem Management sind die konkreten Anforderungen an ein Tool innerhalb dieser Aktivitäten kaum zu formulieren. Neben den Kunden müssen natürlich auch die Mitarbeiter des Service Desk als erste Schnittstelle zum Kunden über die Änderungen informiert werden. Empfehlenswert ist es hier. Weiterhin wird der grundlegende Entwurf. und einem die Möglichkeit gibt. [Its07] Im Gegensatz zum Incident. Unzureichendes Testen gilt als die häufigste Ursache bei nicht erfolgreichen Änderungen.[Its07] In dem Bereich der Kommunikationsvorbereitung und Schulung soll die Information der beteiligten Personen vorgenommen werden. auf grundsätzliche Anregungen einzugehen.

Dies erfolgt. Außerdem werden durch das Vorhandensein des Configuration Managements alle anderen Prozesse unterstützt. Diese Informationen sollen dabei stets auf dem aktuellen Stand gehalten werden. sondern eher aufzeigt. um Veränderungen innerhalb der IT-Infrastruktur korrekt zu erfassen. sowie die Beziehungen zu denen es mit anderen CIs steht. Auch das im anschließenden Kapitel betrachtete Configuration Management ist für eine erfolgreiche Einführung ein wichtiger Kooperationspartner für das Release Management. Dafür identifiziert.Formulierung von Anforderungen entlang des Service Supports 125 und der Auslieferung ist eine Dokumentation wünschenswert. Dies könnte zum Beispiel über einen Statusbericht geschehen. in der beispielsweise Status-Berichte oder auch Auslieferungsbelege aufgenommen werden. nur durch eine angemessene Zeitspanne zu lösen sind. indem es die Attribute. kann ein Tool hier helfen. an den entsprechenden Stellen daran zu erinnern. Damit dies möglich ist.3. Damit diese Interaktion auch durchgeführt wird. die mit Hilfe von Inventarisierungsprogrammen aktualisiert werden. Die CMDB ist vorstellbar als große Kartei.[Its07] .[Its07] Bei der Betrachtung der Aktivitäten wird vor allem die notwendige und ständige Interaktion zwischen den verschiedenen angesprochenen Bereichen deutlich. die zu einem CI gehören. Und zwar insofern. dass von der Planung bis zum Roll-Out ein entsprechendes Zeitfenster zur Verfügung steht. An dieser Stelle ist es ratsam. So steht das Release Management in enger Verbindung zum bereits angesprochenen Change Management. dass sie nicht nur Informationen über die momentan aktiven Hard. Die CMDB unterscheidet sich von Datenbanken. wären Formulare. und dass es nur durch autorisiertes Personal durchgeführt wird. wie die Infrastruktur aussehen müsste. Ziel dabei ist es. 4. Dazu werden für die Informationsbeschaffung Hardund Software Datenbanken und Softwarepakete genutzt. Die Vorteile des Configuration Managements liegen darin. welcher dem Kunden in regelmäßigen Abständen zukommt. überwacht und kontrolliert das Configuration Management die CIs und ihre Versionen. dass die Auswirkungen von Changes vollständig sichtbar werden. Alle weiteren ITIL-Prozesse nutzen diese Daten für ihre Zwecke und sind von seinen Leistungen abhängig. dass die Vielzahl an Prozessen. Bei der Installation wiederum ist ein einheitliches Vorgehen zu beachten. Das IT-Management benutzt diese Daten für Berichtsund Entscheidungsaktivitäten. die für eine CMDB denkbar ist. nicht autorisierte CIs oder illegale Software-Kopien identifiziert werden können und sinnvolle Analysedaten geliefert werden. welche im Release Management ablaufen. muss darauf geachtet werden. wenn alle Regeln inklusive der Dokumentationen beachtet werden. so dass er nachvollziehen kann.6 Configuration Management Das Configuration Management ist zuständig für die IT-Infrastruktur. in der CMDB abspeichert. alle IT-Komponenten zu dokumentieren und gesicherte Informationen über die IT-Infrastruktur allen anderen Prozessen jederzeit zur Verfügung zu stellen. in welchem Stadium sich die Entwicklung gerade befindet und wann er mit einer Installation rechnen kann. Grundsätzlich ist anzumerken. in dem sämtliche IT-Betriebsmittel registriert sind und die Beziehungen zwischen den einzelnen Karten festgehalten werden. den Kunden einzubeziehen und zu informieren. Die einfachste Form.und Softwareprodukte liefert.

Es sollte jedoch keine automatischen Aktualisierungen vornehmen. wie erwähnt.und Release. Obwohl die Daten aus dem Incident-. Für die Verwaltung sollten die Attribute und Klassen eines CIs bereits implementiert sein. Verifizierung und Audits. Problems und Changes ausgewiesen werden können. autorisiert. vollständig und richtig in der CMDB erfasst worden sind. Die Aktivitäten des Configuration Managements umfassen im Einzelnen: [Its07] Planung. Zur Verifizierung der Audits könnte ein Audit Tool z. sollte das Tool in der Lage sein. sollte dennoch eine Verknüpfung zum Change. Eine erste wichtige Anforderung ist. die genaue Detaillierung und Priorisierung festgelegt.und Change Management eigentlich nicht Bestandteil der CMDB sind. Da. geänderte Konfigurationen automatisch zu erfassen und zu kontrollieren. ob die Daten in der CMDB noch mit der aktuellen Situation übereinstimmen. dass Änderungen und Erweiterungen innerhalb des Configuration Managements nicht behindert werden.B. Im Rahmen der Planung des Aufbaus eines Configuration Managements wird dessen Zweck und Umfang bzw. die Prozesse innerhalb des Configuration Managements oftmals parallel ablaufen. sowie die Erfassung von Varianten geregelt werden.Management vorhanden sein. Kontrolle. die durch das Change Management erfolgt sind. Problem. Identifikation. da diese Unstimmigkeiten auf eine Umgehung des Change Managements hindeuten und weiter untersucht werden müssen. Das Tool sollte so ausgewählt werden. mit deren Hilfe die CIs inklusive deren Attribute verwaltet werden können. Um die Aktualität der CMDB zu gewährleisten. dass für den Aufbau eines Configuration Managements in einem eingesetzten Tool bereits eine integrierte CMDB vorhanden ist. dass Änderungen. Unter die Identifikations-Phase fallen die Bestimmung und Pflege der Bezeichnungen und auch der Versionsnummern der einzelnen Komponenten. werden die Anforderungen allgemein formuliert und nicht spezifisch in die einzelnen Prozessabschnitte untergliedert. sowie deren Beziehungen.[Its07] . damit alle zugehörigen Incidents. die Namenskonventionen festgelegt. automatisch Arbeitsplatz-PCs durchforsten. sondern die einzelnen Aktivitäten laufen vielmehr parallel ab. Statusüberwachung.126 ITIL-unterstützende Werkzeuge Der Ablauf innerhalb des Configuration Managements wird nicht immer strikt eingehalten. Dazu muss die Beschreibungstiefe der überwachten CIs definiert. außerdem werden Auswertungen über aktuelle und veraltete CIs erstellt. Es erfolgt eine Überprüfung. Hier erfolgt eine Pflege der Daten indem sichergestellt wird. um Unstimmigkeiten aufzudecken. Innerhalb der Statusüberwachung wird die Lebensdauer einer Komponente verfolgt.

Formulierung von Anforderungen entlang des Service Supports 127 4. Das Ticket beinhaltet alle Informationen zu einem bestimmten Kunden oder zu einem konkreten Problem. welche die Anbieter dieser Software auf ihrer Homepage und in den entsprechenden Handbüchern zur Verfügung stellen. Incident Management mit Service Desk. Anliegen entgegennehmen und registrieren: Aufgrund des TicketSystems wird das Erfassen der Daten vereinfacht. Aufgrund der Datenmengen. Bmc08] 4. Auch die erwünschte Kategorienbildung ist möglich. Denn hier können die Anfragen wie bereits erläutert miteinander in Zusammenhang gebracht werden. OTRS ist lizenzfrei im Internet als Download erhältlich. und diese mit zusätzlicher Information in einer separaten Mail auszustatten. Damit eine Software als open-source bezeichnet werden darf.1 Betrachtung ausgewählter ITIL-Werkzeuge Vorgehensweise Nachdem in dem vorherigen Kapitel Anforderungen an ein Werkzeug formuliert wurden. Es ist einfach und schnell im Unternehmen zu implementieren. Dadurch fallen keine Kosten für Lizenzgebühren an. Die Gefahr der doppelten Bearbeitung wird reduziert bzw. sowie beliebig oft kopierbar und nutzbar sein. die dann je nach Dringlichkeit abgearbeitet werden können.[Nie07] OTRS basiert auf dem oben dargstellten Ticket-System. Für jede Störung . Zudem bietet die Software Schnittstellen zu vielen Betriebssystemen wie Windows oder Linux. Zum einen muss die Software in einer lesbaren und verständlichen Form vorliegen. ist so ein Ticket-System sinnvoller als reine E-Mailkorrespondenz. Es besteht auch die Möglichkeit Tickets an Kollegen weiterzuleiten. Zum anderen muss die Software verändert werden können und auch in der geänderten Form weiter verbreitet werden dürfen.4 4.4. kann es nicht Ziel dieser Arbeit sein.[Otr08. muss sie verschiedene Eigenschaften erfüllen. die in einem Unternehmen eingehen. Da es unzählige verschiedene Werkzeuge gibt. Vielmehr werden exemplarisch zwei verschiedene Werkzeuge näher betrachtet. und kann jederzeit wieder aufgerufen werden. werden die Funktionen der Werkzeuge aufgeführt und exemplarisch mit den vorher herausgearbeiteten Anforderungen in Bezug gesetzt. stellt sich die Frage. der General Public License.4. Zudem können unterschiedliche Zugriffsrechte definiert werden. Jedes noch so kleine Detail wird dokumentiert. Dies ist zum einen das open-source Werkzeug OTRS und zum anderen das kommerzielle Werkzeug Remedy. inwiefern die am Markt vorhandenen Werkzeuge diese Anforderungen auch erfüllen können. Außerdem können Tickets nach Prioritäten geordnet werden. ob OTRS den oben genannten Anforderungen genügen kann.2 Das Open Source-Werkzeug OTRS OTRS gilt als der bekannteste Vertreter aus dem open-source Bereich und unterliegt der GNU. minimiert. Basierend auf den Daten. Für das Incident Management mit dem Service Desk wird nun die weitere Betrachtung anhand der einzelnen Phasen innerhalb des Prozesses vorgenommen.[Här07] Im weiteren Verlauf soll nun herausgearbeitet werden. in die das Incident Management bereits oben untergliedert wurde. einen Vergleich aller vorhandenen Werkzeuge vorzunehmen.

Aus den eingegangenen E-Mails wird automatisch ein Ticket erstellt. Quelle: http://otrs. Des Weiteren können sich die Kunden auch über den aktuellen Bearbeitungsstand ihrer eigenen Tickets informieren und auch weitere Anmerkungen eingeben. Zudem bietet OTRS die Möglichkeit.png. Den Supportern7 steht für die telefonische Entgegennahme eine Telefon-Maske zur Verfügung. der Supporter muss die Daten nicht aus der E-Mail heraus in ein Ticket übertragen.3: Kundensicht OTRS. dass die Kunden über eine entsprechende Maske im Programm Incidents und Changes selbstständig erfassen können und via E-Mail an die Supporter schicken. h. dass mehrere Mitarbeiter zeitgleich an einem Ticket arbeiten. Es ist zu erkennen. Natürlich können die Supporter auch jederzeit den aktuellen Bearbeitungsstand an die Kunden weitergeben. . in der alle wesentlichen und relevanten Daten strukturiert eingegeben werden können. Diese Daten werden gespeichert und sind für alle anderen Mitarbeiter zu jeder Zeit ersichtlich. 7 Die Service-Desk Mitarbeiter werden in OTRS als Supporter bezeichnet. Die Daten dieser E-Mail werden dann automatisch in ein Ticket übertragen.128 ITIL-unterstützende Werkzeuge oder für jede Änderung wird ein eigenes Ticket angelegt. oder ein Supporter an mehreren Tickets gleichzeitig.0/customer-newTicket. Dieses erfolgt über eine E-Mail in einer vorgegebenen Maske. D. Es ist auch nicht relevant.org/images/ screen-2. ob die Daten per Telefon oder per Mail eingehen. Diese Vorgehensweise ist in der folgenden Abbildung dargestellt: Abbildung 4. dass der Kunde sich nach dem Einloggen in dem Programm selbständig über OTRS ein Ticket erstellen kann. Es besteht natürlich auch die Möglichkeit.

die hier jedoch nicht näher betrachtet werden sollen. Aus der Abbildung ist ersichtlich. Abbildung 4. In dem weißen darunterliegenden Bereich befinden sich verschiedene Icons zur Bearbeitung der Tickets. Nachdem die Klassifizierung erfolgt ist. bei einem Telefongespräch schon während der Datenaufnahme erfolgen. wird das weitere Vorgehen beeinflusst.Formulierung von Anforderungen entlang des Service Supports 129 sondern dies geschieht automatisch. Ebenso werden hier neu eingegangene E-Mails angezeigt. wird das Anliegen entweder sofort vom Supporter bearbeitet und abgeschlossen. Dieser Vorgang wird z. Je nachdem ob es sich um ein Incident oder um einen Change handelt.org/images/ screen-2.png. B. wie der Name des Supporters.0/queue. In dem darunterliegenden weißen Bereich werden die Inhalte zu . Ebenso hat der Kunde über diese Funktion die Möglichkeit sich über den Bearbeitungsstand seiner bereits vorhandenen Tickets zu informieren. wie die Benutzeroberfläche für den Supporter von OTRS aussieht. das Datum und die Uhrzeit angezeigt. Klassifizierung des Anliegens: Nach der Datenerfassung werden die Anliegen klassifiziert. um den weiteren Verlauf des Telefonats zu beurteilen. Des Weiteren stehen dem Kunden noch weitere Anwendungen zur Verfügung. Quelle: http://otrs. Change Management. In dem oberen schwarzen Balken werden allgemeine Daten.4: Benutzeroberfläche OTRS. oder er leitet das Anliegen weiter an das Incident bzw. In der folgenden Abbildung ist zu erkennen. dass diese in verschiedene Bereiche gegliedert ist. Durch die verbesserten Kommunikationsmöglichkeiten können Prozesse wie Incidents oder Changes schneller und effizienter weitergeleitet werden.

um zu überprüfen. leichtere. die innerhalb der Problem-Control. Hier werden die einzelnen Phasen. ohne dass ein Mitarbeiter sich dieser E-Mail widmet. Diese werden wieder als Ticket innerhalb des Systems weitergeleitet. kann OTRS durch eine Schlagwortsuche eingehende E-Mails durchsuchen. Es besteht die Möglichkeit. zu dem Ticket dargestellt. Es wird in der Datenbank abgelegt. Die hier . dass vorformulierte E-Mails automatisch auf eine bestimmte Anfrage hin versendet werden. Bei Bedarf muss dann ein neues Ticket angelegt werden. sich mit wesentlichen und schwierigeren Anliegen zu befassen und auch schneller und konkreter auf Kundenwünsche einzugehen. ob der Fehler behoben oder ein Änderungswunsch umgesetzt wurde. Was genau ein Standard-Anliegen ausmacht kann innerhalb der Software definiert werden.130 ITIL-unterstützende Werkzeuge dem aktuell geöffneten Ticket angezeigt. Interessant ist diese Funktion zum Beispiel nach einem Update. gehen im Problem Management die Störungen ein. der Error Control und des Proactive Problem Managements ablaufen. wie die Historiefunktion. Diese Vereinfachung kann für alle bekannten und leicht korrigierbaren Incidents Anwendung finden. Dadurch ist es den Mitarbeitern im Service Desk möglich. Wenn diese Daten hinterlegt sind. und kann jederzeit wieder gelesen werden. Dadurch gerät kein Ticket in Vergessenheit. Im Folgenden werden die oben formulierten Anforderungen an ein Tool im Rahmen des Problem Managements mit den angebotenen Funktionen von OTRS verglichen. Des Weiteren erfolgt eine kundenfreundlichere Abwicklung. und dann entsprechend der Vorgabe einem Ticket oder einer Störung zuordnen. zusammengefasst betrachtet. weil die Wartezeiten sich nicht so lange hinziehen. häufig auftretende Störungen schneller und kundenfreundlicher zu bearbeiten. die Mitarbeiterzufriedenheit steigt. Kann ein Incident oder ein Änderungswunsch nicht sofort erledigt werden. welches mit dem bestehenden dann verknüpft werden kann. Des Weiteren gibt es die Möglichkeit. Viele Anliegen können schon vorab vom First-Level-Support geklärt werden. Wie bereits beschrieben. Diese Vereinfachung ist nur bei Standard-Anliegen möglich. Dadurch wird eine Entlastung der Mitarbeiter hervorgerufen. Auf der rechten Seite der Maske befinden sich weitere Angaben zu dem Ticket. jedoch nicht separat. Im unteren Bereich der Maske werden Funktionen. um Überschneidungen zu vermeiden. sondern. Problem Management. Bearbeitung von Störungen: Durch die gespeicherte. und es benötigt keine Rücksprache mit den anderen Levels. für die das Incident Management keine Ursache feststellen konnte und die somit als Problem klassifiziert werden. Abschluss und Speicherung des Lösungsweges in der Datenbank: Nachdem die Störung behoben ist. Tickets zu einem bestimmten Event wieder aufzurufen. Dieser Automatisierungsvorgang entlastet die Mitarbeiter und ermöglicht es den Supportern. gibt es bei OTRS auch eine Wiedervorlagemöglichkeit. Eine weitere Bearbeitung des Tickets ist dann jedoch nicht mehr möglich. integrierte Datenbank können alle Supporter auf das gespeicherte Wissen zugreifen. Unter anderem die Priorität und der Bearbeitungsstatus. wird das Ticket geschlossen.

Hardware. Für eine tiefgehende Analyse der Probleme oder Fehler bietet OTRS die Möglichkeit. als auch aus allen weiteren ITIL-Prozessen. nämlich Computer. Bei OTRS ist mit dem Vorhandensein einer integrierten CMDB die Möglichkeit gegeben. die im Rahmen der Statusüberwachung bei Problem-Diagnosen oder geplanten Changes hilfreich sein können. Dabei werden alle relevanten Informationen zur Verfügung gestellt. sowie bei der Klassifizierung von Problemen. die Möglichkeit Ticket-Trendanalysen durchführen zu können. wodurch die Probleme an die entsprechenden Experten weitergeleitet werden. dass die RFCs über den in OTRS vorhandenen Service Desk erfasst werden können. automatische Benachrichtigung über den Problemlösungsfortschritt an die betroffenen Anwender. Dabei ist es bei OTRS möglich. Auch Änderungen der Attribute der CIs können vorgenommen werden. a. das Configuration Management umzusetzen. Problem und Change Management be- . Die Priorisierung dient hier als Grundlage der Ressourcenzuteilung. Mit Hilfe der CMDB können die CIs. um Zeit zu sparen und eine vollständige Übermittlung der Informationen zu gewährleisten. Die Lösungsentwicklung kann jederzeit von allen anderen Anwendern angeschaut werden und alle können jederzeit an dem Problem arbeiten. Des Weiteren beinhaltet das OTRS-Tool eine gezielte. dass ein Tool in der Lage sein sollte.Formulierung von Anforderungen entlang des Service Supports 131 eingegangenen Probleme lassen sich nicht so einfach klären oder beseitigen. Somit lässt sich ermitteln. Change Management. Diese können durch ein chronologisches Life-Cycle-Management für die CIs verwaltet werden. Darin sind alle aktuellen und historischen Problemlösungen dokumentiert und können somit zur Klärung des Problems beitragen. Netze zuzuordnen. Configuration Management. Außerdem bietet OTRS eine Möglichkeit zum Management der historischen. Anzumerken ist.Prozesse können integriert werden. aktuellen und zukünftigen CI-Status. womit eine Verknüpfung zum Incident. Um proaktiv Störungen im Vorfeld verhindern zu können. oder führen zu dauerhaften Ausfällen. sowohl aus dem Bereich des Problem Management. Software. der RFCs wird jedoch von OTRS nicht unterstützt. Die anderen ITIL. Auch hier bietet OTRS noch nicht die Möglichkeit das Release Management umzusetzen. Die weitere Vorgehensweise bzgl. bietet OTRS u. Des Weiteren kann durch den Einsatz von OTRS die IT-Infrastruktur virtualisiert abgebildet werden. Mit Hilfe von OTRS kann die Anforderung umgesetzt werden. ob ein ähnliches Problem bereits bekannt ist und ob dafür schon eine Lösung gefunden wurde. OTRS bietet zurzeit noch nicht die Möglichkeit das Change Management zu implementieren. Release Management. ständig auf vorhandenes Lösungswissen in der Wissensdatenbank zugreifen zu können. OTRS bietet durchgängige Unterstützung bei der Problemidentifizierung und -erfassung. Alle Konfigurationsänderungen an CMDB-Daten werden durch das OTRS-Tool protokolliert. um von den Trends innerhalb der Tickets auf mögliche Schwachstellen schließen zu können. sowie ihre gegenseitigen Beziehungen und Abhängigkeiten erfasst und verwaltet werden. die Daten strukturiert erfassen zu können. die CIs den verschiedenen Klassen.

4. die von BMC Software Inc. welche in diesem Werkzeug implementiert ist. dass es nur einige der von ITIL genannten Prozesse aus dem Bereich Service Support abbildet. erfüllt. Der Aufbau und der vorgegebene Ablauf von OTRS bieten die Möglichkeit der Verknüpfung der einzelnen Bereiche. wird es in dieser Arbeit nicht weiter betrachtet 8 Die Firma hat ihren Hauptsitz in Houston. so dass eine prozessübergreifende Kommunikation und ein permanenter Datenzugriff ermöglicht wird. das Incident Management sowie das Problem Management umfasst • Remedy Asset Management. Anzumerken ist in diesem Zusammenhang. Es besteht aus den vier folgenden Modulen. so dass für diese keine Informationen auf der Homepage bereitgestellt werden und eine Überprüfung der aufgestellten Anforderungen nicht durchgeführt werden konnte. Die beiden Prozesse Change und Release Management werden gar nicht unterstützt. da aber dieses Modul nicht Bestandteil der Prozesse des Service Supports ist. Die Beschreibung der Funktionen erfolgt jedoch nicht zu konkret. Abschließend lässt sich zu OTRS festhalten. die flexibel miteinander kombiniert werden können: • Remedy Help Desk. Remedy bietet eine Lösung an.8 entwickelt wurde und seitdem von dem Unternehmen vertrieben wird. Da OTRS auf einem Ticket-System basiert. Dazu offeriert Remedy das Baukastensystem Remedy IT Service Management. sowie zahlreiche Tochterfirmen weltweit. welches das Configuration Management in das Remedy IT Service Management implementiert • Remedy Change Management. So werden die Vorteile von Remedy besonders herausgestellt. werden die grundlegenden Anforderungen. deckt es hauptsächlich die Prozesse des Incident Managements in Verbindung mit dem Service Desk sowie das Problem Management ab. Aus diesem Grund werden auch hier die meisten im Rahmen dieser Projektarbeit genannten Anforderungen beachtet. dass die Informationspolitik eines kommerziellen Tools eine andere als bei einem Opensource Tool ist. .132 ITIL-unterstützende Werkzeuge steht und damit alle zugehörigen Incidents. der den Service Desk. Problems und Changes mit einbezogen werden können. wie die strukturierte Erfassung und Verwaltung der Daten. Für die weitere Betrachtung werden hauptsächlich die Informationen von der Webseite des Unternehmens verwendet.3 Das kommerzielle Werkzeug Remedy Remedy ist eine kommerzielle Software.4. Die Grundanforderungen für die Umsetzung des Configuration Managements ist das Vorhandensein einer integrierten CMDB. Das Configuration Management wird durch die Software wiederum abgedeckt. mit dem der ITIL-Prozess des Change Managements unterstützt wird • Remedy Service Level Agreements. Durch die übersichtliche Oberfläche von OTRS. Texas. die individuell auf das jeweilige Unternehmen abgestimmt wird. wie es bei frei zugänglichen open-source Lösungen eher vorzufinden ist. Zusammenfassung.

B.Formulierung von Anforderungen entlang des Service Supports 133 Diese Bausteine sind unabhängig voneinander. der Priorität. durch das die Probleme nun weiter beschrieben und klassifiziert werden können. welche allgemeine Lösungen und auch Lösungen für bereits bekannte Fehler zur Bearbeitung der Anliegen zur Verfügung stellt. den Ablauf innerhalb der einzelnen Prozesse detailliert zu betrachten. Auch bei diesem Werkzeug wird nun untersucht. Des Weiteren ist für das Problem Management ein separates Klassifikationssystem enthalten.und Produktivitätssteigerung des Services Supports. das Anliegen über verschiedene Kommunikationsmöglichkeiten (z. Wird keine Lösung gefunden. ist das Programm in der . ist es möglich. welche sowohl Mitarbeiter des Unternehmens hinsichtlich einer Effizienz. die nach den Informationen der Homepage. Um im Folgenden die einem Problem zugrunde liegenden Ursachen ausfindig zu machen. so stehen sie dann miteinander in Beziehung und sind damit verknüpft. durch die automatisierte Weiterleitung der Tickets an die relevanten Support-Bereiche zeigt. Da in diesem Modul ebenfalls die Umsetzung des Incident Managements enthalten ist wird sichergestellt. diese dann an den Kunden weitergeben. als Pluspunkte für dieses Tool zu sehen sind. Die Mitarbeiter können diese integrierte Datenbank durchsuchen und falls eine Lösung vorhanden ist. so dass die einzelnen Prozesse insgesamt betrachtet werden. Mit dem Remedy Help Desk wird die Schnittstelle zur Kommunikation zwischen Kunden und Unternehmen geboten. So bietet das Tool von Remedy entlang des Ablaufs verschiedene Möglichkeiten.a. Der Kunde kann bspw. Wenn sie von einem Unternehmen eingesetzt werden. die Dringlichkeit. der sich u. Des Weiteren wird die Datenbank angeführt. Problem Management. Diese Klassifikation ist wichtig. Der Remedy Help Desk ist an dem bereits angesprochen Prozessablauf des Incident Managements ausgerichtet. Weitere Informationen zum Remedy Help Desk liefert auch die Betrachtung des Problem Managements. Ausgangspunkt ist die Aufnahme der Service Requests. E-Mail. Der Mitarbeiter des Remedy Help Desk wird dahingehend unterstützt. dass das Problem Management auf die zuvor im Incident Management aufgenommenen Daten zugreifen kann. dass eine automatische Weiterleitung des Tickets an den zuständigen Support-Bereich erfolgt. der Abgrenzung und der Reichweite des Incidents an. Aufgrund der angesprochenen Informationsproblematik ist es im weiteren Verlauf nicht möglich. die Aufnahme und Klassifizierung des Anliegens. erfolgt eine Weiterleitung an Spezialisten. Incident Management mit Service Desk. um die Auswirkungen. Vor allem die angesprochene Automatisierung und die Vereinfachung der Support-Prozesse sind Eigenschaften. Für den ersten Schritt. Telefon) aufzunehmen und ein Ticket zu erzeugen. Das Incident Management ist in Verbindung mit dem Service Desk innerhalb dem Remedy Help Desk angesiedelt. Die Umsetzng des Problem Managements erfolgt bei Remedy auch innerhalb des Moduls Remedy Help Desk. Grundsätzlich wird dabei ein hoher Automatisierungsgrad betont. als auch die Kunden unterstützen sollen. Remedy bietet ein System für die Klassifizierung bzgl. inwiefern die Software Remedy den aufgestellten Forderungen genügen kann. den Status „seines“ Requests abfragen und kann sich so über den Status quo der Bearbeitung informieren. die Priorität und den Status des vorliegenden Problems zu erfassen.

Evaluierung und Abschluss: Die Software bietet zudem Kontrollmöglichkeiten bezogen auf die Auswirkungen. Der Vorteil ist hier das Vorhandensein einer CMDB. die Ressourcen sowie die Risiken. Gleichzeitig werden Audits erstellt. Erstellung von Zeit-/Installationsplänen und deren Implementierung: Im Rahmen der Implementierung muss bedacht werden. ist es möglich den Analyseprozess neuer Probleme weiter zu unterstützen. des Genehmigungsverfahrens. die einen Überblick über die vorhandenen CIs gibt und somit als Hilfsmittel bei der Fehlersuche eingesetzt werden kann. Ein Restrisiko bleibt stets vorhanden. werden benachrichtigt und können sich somit darauf einstellen. Change Management. die Kosten. dass eine Klassifizierung hinsichtlich der Akzeptanz. Hierfür bietet diese Software grundlegend die Möglichkeit jederzeit mit anderen Abteilungen in Kontakt zu treten und gemeinsam über die Ziele. kann mit Remedy dieses Szenario durchgespielt werden. dass ein vorhandenes Backout-Verfahren vor der Implementierung zugrunde liegen muss. sodass es hier möglich ist. Freigabe der Änderung. der Erfassung sowie der Speicherung vorgenommen wird. eine detailliertere Vorgehensweise vorzunehmen. Dadurch können die Gefahren wie die eines Ausfalls oder sonstige Unannehmlichkeiten minimiert werden. Im Folgenden sollen die genannten Forderungen im Einzelnen durchgegangen werden: Erfassung des RFCs. Um jedoch schon im Vorfeld das Risiko einer negativen Auswirkung gering zu halten. Remedy Change Management unterstützt die Arbeit dahingehend. B. Das Ergebnis kann wiederum als Grundlage für weitere Änderungen verwendet werden. Kunden. Remedy Change . ist somit auch für die notwendige Kommunikation und Zusammenarbeit zwischen den Prozessen gesorgt. das aufgenommene Problem automatisch auf Übereinstimmungen mit bereits vorhandenen Incidents. Dieses gilt es jedoch zu minimieren. Remedy IT Service Management bietet für diesen Bereich eine Unterstützung an. um alle betroffenen Anwendergruppen über den aktuellen Stand informieren zu können. die durch diese Änderung betroffen sind. Außerdem ist diese Dokumentation hilfreich. Die Probleme werden mit Hilfe des Programms über die verschiedenen Stufen innerhalb des Problem Management Prozesses verfolgt und überwacht.134 ITIL-unterstützende Werkzeuge Lage. Für das Modul Remedy Change Management wird genügend Information geboten. Das Ticket kann durch das ganze System hindurch verfolgt werden und jederzeit aufgerufen und weiterbearbeitet werden. um auch die anderen Prozesse über den aktuellen Stand und über die Lösungen der Probleme zu informieren. Aus diesem Grund ist eine genannte Anforderung an das Werkzeug. dass die Auswirkungen einer Änderung oftmals nicht vollständig vorhersehbar sind. Da eine Anbindung an die anderen Prozesse durch den kombinierten Einsatz z. die Gültigkeit sowie die Auswirkungen einer Änderung zu kommunizieren. Da alle Schritte dokumentiert werden. der Module Remedy Asset Management und Remedy Change Management durch Remedy möglich ist. Problemen und Known-Errors zu überprüfen. Zudem bietet es einen Automatismus bzgl. Diese Möglichkeit bietet Remedy Change Management. Kontrolle und Speicherung in der Datenbank: Eine erste Anforderung war die ordnungsgemäße Erfassung der Tickets.

können die CIs während ihrer gesamten Dauer innerhalb des Unternehmens verfolgt und überwacht werden. welches im Remedy Asset Management enthalten ist. Für Remedy lässt sich festhalten. Remedy hebt nicht explizit eine Umsetzung des Release Managements hervor. So ist darin auch eine Erstellung von Zeitplänen für die Wartung und Prüfungen möglich. Im Rahmen der Funktion des Lifecycle Asset Management. Hierbei kann aus vorgegebenen Standardkonfigurationen gewählt werden. Auf eine Umsetzung des Release Managements wird nicht näher eingegangen. Configuration Management. so dass hier keine Überprüfung von Anforderungen möglich war. um die Quellen verschiedener Probleme möglichst schnell ausfindig zu machen. Durch das Modul Remedy Change Management erfolgt eine Umsetzung des Change Managements. wodurch die aufgestellten Anforderungen nach einer organisierten Erfassung und Verarbeitung der Daten umgesetzt werden. dass mehrere der von ITIL genannten Prozesse im Service Support umsetzt werden. um einen Ausfall der Komponenten im Vorfeld zu verhindern. Auch die genannten Anforderungen an das Configuration Management werden weitestgehend durch das Modul Remedy Asset Management umgesetzt. Zusammenfassung.9 Als Ausgangspunkt für die Umsetzung des Configuration Managements verfügt Remedy über eine integrierte CMDB. Release Management. Die oben erarbeiteten Anforderungen für diesen Prozess werden dabei im Wesentlichen umgesetzt. sondern stellt auch die Software für die anschließende Evaluierung zur Verfügung. enthält Remedy zusätzlich die Möglichkeit Autoritätsüberprüfungen oder Namensübereinstimmungen durchzuführen. Um die Sicherheit und Vollständigkeit der Daten zu gewährleisten. Darin werden alle CIs sowie deren Beziehungen gespeichert. als Beispiel sei das in diesem Werkzeug vorhandene Backout-Verfahren erwähnt. kann jederzeit der Bestand prozessübergreifend geprüft und Bedarfsmeldungen an die anderen Prozesse geben werden. damit die vorgegebenen Konfigurationen auch eingehalten werden. Der Zugriff darauf ist prozessübergreifend möglich. Das Configuration Management wird durch das Remedy Asset Management unterstützt.Formulierung von Anforderungen entlang des Service Supports 135 Management bietet zudem nicht nur die Möglichkeit zur Ablaufplanung und Aufgabenzuweisung.und Hardware zu erneuern und damit Unstimmigkeiten zwischen der Datenbank und den tatsächlichen CIs aufzufinden. Nach erfolgter Genehmigung wird die Bestellung durch das Programm automatisch generiert. veraltete Soft. Dies behandelt die Verwaltung der Assets (IT-Anlagegüter). Auch der Remedy Help Desk basiert auf einem Ticket-System. Durch diese Überwachung der einzelnen CIs ist es möglich. 9 Für die Assets wurde bisher die Bezeichnung CIs verwendet . Durch eine Verknüpfung mit den Modulen Remedy Help Desk und dem Remedy Change Management. Des Weiteren besteht mit Remedy die Möglichkeit für verschiedene Personen oder Abteilungen Standardkonfigurationen zu definieren. So umfasst der Remedy Help Desk das Incident Management in Verbindung mit dem Service Desk und das Problem Management.

So gilt auch hier: „a fool with a tool is still a fool“. Dennoch kann der Einsatz eines Tools zur Effizienzsteigerung und damit auch zu Zeiteinsparungen führen. im einfachsten Fall sogar mit Papier und Bleistift. Damit stellte sich die Frage. Anhand dieser beiden ließ sich exemplarisch aufzeigen. wenn die Menschen sie auch benutzen und bspw. h. dass es innerhalb von ITIL freigestellt ist. So ist die Nutzung einer noch so strukturierten Datenbank nur dann erfolgreich. . dass verschiedene Punkte wiederholt auftreten. dass die Programme einige Prozesse bereits umsetzen und somit den aufgestellten Anforderungen teilweise genügen. die Aktualisierung der Datenbanken nicht vernachlässigen. der Erfolg ist aber natürlich zum Großteil von der Fähigkeit des Menschen abhängig. was ITIL-unterstützende Werkzeuge leisten sollten. Die Betrachtung von Anforderungen innerhalb der Prozesse im Service Support hat aufgezeigt.5 Fazit Abschließend lässt sich sagen. Anforderungen an ein ITIL-unterstützendes Werkzeug herauszuarbeiten. Im Rahmen dieser Arbeit war es das Ziel. dass allein der Einsatz eines Tools bereits zu einer erfolgreichen ITIL-Umsetzung führt.4 näher betrachtet wurden.136 ITIL-unterstützende Werkzeuge 4. Diese lassen sich folgendermaßen zusammenfassen: • Möglichkeit zur strukturierten Erfassung von Daten • Verwaltung der Daten innerhalb von entsprechenden Datenbanken • Permanenter Informationszugriff für die Anwendergruppen • Erleichterung der prozessübergreifenden Kommunikation und Information Am Markt gibt es verschiedene Werkzeuge von denen OTRS und Remedy in Kapitel 4. Die Werkzeuge können unterstützend wirken. D. Die Grundsätze von ITIL sind auch mit jeglichen Mitteln umsetzbar. es ist ein Irrtum zu glauben. ob unterstützende Werkzeuge verwendet werden sollen oder nicht.

: Taking a page from ITIL’s best practices. 2. M. Elsässer.07. URL: http://www. 137 . K.01. URL: http://www.08.07. Auflage.07.: Werkzeugunterstützung für ITIL-orientiertes Dienstmanagement: Ein modellbasierter Ansatz.12.07. D. 2006. [Cla] [Els06] [Fis06] [Här07] [Its07] [Mar04] Margulius. Fischlin.infoworld. Zaltbommel 2007.: Beispielhafte Evaluierung der Anpassbarkeit von OTRS an Prozesse im IT Service Management am LRZ. M. Auflage. und Lizenzgeber.pdf. Clauss.: Leitfaden ITIL-Service Desk. R. DFN Tagungsband 2006.org/pub/Fopras/clau06/PDF-Version/clau06.01. Fraunhofer Institut für Informations.mnm-team. URL: http://edoc. Ludwig-Maximilians-Universität München. itSMF-NL: Foundations in IT Service Management.12. Datum der Abfrage:04.: Konzeption und Unterstützung der technischen Unterstützung eines zentralen IT-Service-Desk mit OTRS an der TUM. C.pdf. Datum der Abfrage: 18. Datum der Abfrage: 06. Verlag Dr. Datum der Abfrage: 18.L.org/pub/Diplomarbeiten/haer07/ PDF-Version/haer07. 1. mnm-team. Saarbrücken 2007. Van Haren Publishing.08.: ITIL Einführung und Umsetzen: Leitfaden für effizientes IT-Management durch Prozessorientierung. Basierend auf ITIL.pdf. Müller e.de/conferences/dfn2006/ fischlin-roger-105/PDF/fischlin. Diplomarbeit am Institut für Informatik 26. URL: http://www.com/article/04/09/24/39FEitil_1.: Service Management-Lösungen für KMU. [Nie07] Niestermann. ITIL-unterstützende Service Management Tools. Härtl. Seite 95-104. M. Hanser Verlag. Fortgeschrittenenpraktikum am Institut für Informatik.Literaturverzeichnis [Bre07] Brenner. W.und Datenverarbeitung.hu-berlin. Dissertation München 2007. Network Operation Center NOC.html. Ludwig-Maximilians-Universität München.

bmc. Ludwig-Maximilians-Universität München. URL: http://www. [Pfl05] [Bmc08] BMC Software Inc.com/de. Support und Training rund um OTRS.Remedy Service Management is now on BMC. Datum der Abfrage: 03.: Evaluierung von Werkzeugen zur Unterstützung der ITIL Service Management Prozesse. Pfleger.01.lmu.nm. Datum der Abfrage: 26. .08. .otrs. URL: http://www. B.ifi. URL: http://www. Diplomarbeit am Institut für Informatik.138 [Otr08] ITIL-unterstützende Werkzeuge OTRS AG .02.02. Datum der Abfrage: 04.08.com/remedy/.08.com.Consulting.de/pub/Diplomarbeiten/pfle05/ PDF-Version/pfle05. Software Development.pdf.