Betriebsinformatik-Projekt. ITIL und die IT-Wirklichkeit

Transkript

1 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

2

3 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 Management- Funktionen 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 4

5 Inhaltsverzeichnis 1 ITIL-Wirklichkeit an der Universität Bielefeld Einleitung Service Support Service Desk Incident Management Problem Management Change Management Release Management Configuration Management Untersuchung des IT-Managements in der Universität Bielefeld Fakultät für Wirtschaftswissenschaften Fakultät für Rechtswissenschaft Kritik und Empfehlung Fazit Fragebogen ITIL-Zertifizierung nach ISO/IEC Einleitung Der Standard ISO/IEC Entwicklung Beziehung zu ITIL Struktur Anforderungen an ein Management-System Planung und Implementierung des Service Managements Anforderungen an Service-Management-Prozesse Die Zertifizierung Entscheidungsfindung Prozessumsetzung Fragenkatalog zur Prozessumsetzung Zertifizierungsprozess Beurteilung der Zertifizierung Fazit ITIL und IT-Sicherheit Einleitung Grundlagen des IT-Security Management Informationssicherheit Gesetzesanforderungen, Vorschriften und Standards

6 6 INHALTSVERZEICHNIS Ziele und Aufgaben des IT-Security Management Einordnung von Informationssicherheit und Security Management in ITIL Security Management mit ITIL auf operativer Ebene Service Desk Incident Management Problem Management Change Management Release Management Configuration Management Fazit ITIL-unterstützende Werkzeuge Einleitung Begriffsabgrenzungen ITIL Werkzeuge Service Support und Anforderungen an die Werkzeuge Vorgehensweise Incident Management mit Service Desk Problem Management Change Management Release Management Configuration Management Betrachtung ausgewählter ITIL-Werkzeuge Vorgehensweise Das Open Source-Werkzeug OTRS Das kommerzielle Werkzeug Remedy Fazit

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

8 8 INHALTSVERZEICHNIS

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

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

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

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

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

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

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

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

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

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

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

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