ITIL - Incident- & Problem Management - cs.fau.de · ITIL-Incident- & Problem Management 2 5...

Rheinisch-Westfalische Technische Hochschule AachenLehrstuhl fur Informatik IV - Lehr- und Forschungsgebiet zuverlassige

verteilte Systeme

Seminar Verlasslichkeit und Prozessunterstutzung im Healthcare-Bereich,SS 2005

ITIL - Incident- & ProblemManagement

Christian Mertens

5. September 2005

ITIL-Incident- & Problem Management 1

Inhaltsverzeichnis

1 Einleitung 31.1 Grundbegriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Was ist ITIL? . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Vorteile und Nachteile von ITIL . . . . . . . . . . . . . . . . . 8

2 Incident Management 102.1 Was ist das Incident Management? . . . . . . . . . . . . . . . 102.2 Aufgaben des Incident Managements . . . . . . . . . . . . . . 11

2.2.1 Incident Annahme und Aufzeichnung . . . . . . . . . . 112.2.2 Klassifikation und erste Unterstutzung . . . . . . . . . 112.2.3 Untersuchung und Diagnose . . . . . . . . . . . . . . . 122.2.4 Losung und Wiederherstellung . . . . . . . . . . . . . . 132.2.5 Incident Abschluss . . . . . . . . . . . . . . . . . . . . 132.2.6 Incident Ownership, Monitoring, Tracking und

Kommunikation . . . . . . . . . . . . . . . . . . . . . . 142.3 Rollen im Incident Managent . . . . . . . . . . . . . . . . . . 14

2.3.1 Incident Manager . . . . . . . . . . . . . . . . . . . . . 142.3.2 Incident Support Personal . . . . . . . . . . . . . . . . 15

2.4 Kennzahlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Problem Management 173.1 Was ist das Problem Managements? . . . . . . . . . . . . . . . 173.2 Problem-Kontrolle . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1 Problem Identifizierung und Registrierung . . . . . . . 173.2.2 Klassifizierung bzw. Einordnen des erkannten Problems 183.2.3 Untersuchung und Diagnose . . . . . . . . . . . . . . . 19

3.3 Fehler-Kontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3.1 Fehler-Identifikation und Aufzeichnung . . . . . . . . . 193.3.2 Fehler-Bewertung . . . . . . . . . . . . . . . . . . . . . 203.3.3 Aufzeichnung der Fehlerbeseitigung . . . . . . . . . . . 203.3.4 Fehler-Abschluss . . . . . . . . . . . . . . . . . . . . . 213.3.5 Uberwachung . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Proaktives Problem Managements . . . . . . . . . . . . . . . . 213.4.1 Trendanalyse . . . . . . . . . . . . . . . . . . . . . . . 213.4.2 Vorbeugende Maßnahmen . . . . . . . . . . . . . . . . 22

3.5 Problem Manager . . . . . . . . . . . . . . . . . . . . . . . . . 233.6 Kennzahlen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Zusammenfassung 25

Christian Mertens, Seminar Verlasslichkeit und Prozessunterstutzung imHealthcare-Bereich, SS 2005


5 Literatur 26



1 Einleitung

Aufgrund der immer weiter steigenden IT-Kosten sind die Unternehmengezwungen Einsparungen vorzunehmen. Da der Hauptteil der IT-Kosten,laut Marktanalysten ca. 70 bis 80 Prozent, durch den Betrieb der IT-Systemeentsteht, muss man sich genau uberlegen, wie man die Kosten in dem Bereichdes IT-Service-Management senken kann wodurch mehr Geld fur neue IT-Projekte zur Verfugung steht.[4]

Zu diesem Zweck fuhren Unternehmen die Prozess-Methode ITIL(Information Technology Infrastructure Library) ein, welche in den folgendenAbschnitten der Einleitung allgemein beschrieben wird. Das zweite Kapitelbeschaftigt sich genauer mit dem Kernprozess Incident Management undseinen Aufgaben und Zielen und das dritte Kapitel geht detailliert auf dasProblem Management des ITIL-Regelwerkes ein. In der Zusammenfassungwerden die wichtigsten Kernaussagen nochmal kurz rekapituliert underlautert. Das Ziel dieser Arbeit ist es zu verstehen, warum ITILeine Trennung zwischen dem Incident Management und dem ProblemManagement vornimmt und wo genau die Unterschiede vorliegen.

1.1 Grundbegriffe

An dieser Stelle sollen ein paar wichtige Grundbegriffe fur dieses Themaeingefuhrt werden:

Incident: laut ITIL [OGC, 2004]:”Eine Storung (Incident) ist ein

Ereignis, das nicht zum standardmaßigen Betrieb eines Service gehort unddas tatsachlich oder potenziell eine Unterbrechung des Service oder eineMinderung der vereinbarten Qualitat verursacht.“Beispiele fur Incidents sind:

• Service Requests, z.B. Passwort zurucksetzen

• Applikationen, z.B. eine notwendige Anwendung kann nicht gestartetwerden

• Hardware, z.B. Drucker druckt nicht

Workaround: unter einem Workaround versteht man eine

”Umgehungslosung“. Es existiert also keine langfristige Losung, sondern eine

schnelle Beseitigung der Storung, wobei die Ursache nicht festgestellt wird.

Problem: unbekannte oder undokumentierte zugrunde liegende Ursachefur einen oder mehrere Incidents



Bekannter Fehler (Known Error): die Ursache fur das Problemist bekannt und ein Workaround existiert, aber die Losung ist noch unbekannt

Configuration Item (CI): Komponenten einer IT-Infrastruktur

Configuration Management Data Base (CMDB): CMDB,innerhalb der ITIL-Richtlinien ein Begriff fur eine Datenbank (oderSammlung von Datenbanken), die Informationen uber die verwendetenHardware- und Software-Komponenten, die Anwender, Systemsettings undKonfigurationsdaten (CIs) bereithalt.

Change: Unter einem Change versteht man jede Anderung an der IT-Infrastruktur eines Unternehmens

1.2 Was ist ITIL?

Die ITIL ist ein”Best practice“-Regelwerk fur IT-Service-Management,

welches in den 80er Jahren von der Central Communication andTelecommunication Agency (CCTA) entwickelt wurde und seit dem Jahr2001 durch das

”Office of Government Commerce“ (OGC, entstanden aus

der CCTA und zentrale Beratungsstelle fur Informatik in Großbritannien)vertrieben und vermarktet wird. ITIL ist in der heutigen Zeit der de-factoStandard im IT-Service-Management (ITSM), da auf der einen Seite ITILeine offentlich zugangliche, herstellerunabhangige

”Bibliothek“ und deshalb

auch lizenzfrei ist. Auf der anderen Seite bietet ITIL den Unternehmen ein

”Best Practice“-Regelwerk, in dem nur beschrieben wird, was getan werden

muss, um die einzelnen Prozesse zu implementieren, aber nie gesagt wird,wie dieses in der Praxis genau zu tun ist. Dadurch besteht ein großer Vorteil,weil es so in allen Bereichen speziell auf die eigenen Bedurfnisse angepasstund umgesetzt werden kann.

Das komplette Regelwerk besteht aus der Funktion des Service Desk,sowie insgesamt 10 Kernprozessen, welche sich in zwei Gruppen mit jeweilsfunf Prozessen unterteilen lassen, namlich dem Service Support Set (IncidentManagement, Problem Management, Configuration Management, ReleaseManagement, Change Management) und dem Service Delivery Set (ServiceLevel Management, Financial Management, Continuity Management,Availability Management, Capacity Management). Der Service Supportist dabei fur den operativen Betrieb zustandig, es gewahrleistet also denstorungsfreien IT-Betrieb und der Service Delivery ist fur die strategischenProzesse des ITSM verantwortlich. Im folgenden Abschnitt werden dieeinzelnen Prozesse beginnend mit denen des Service Support Sets, kurz



eingefuhrt und beschrieben.Das Incident Management besitzt die Aufgabe alle dem Service

Desk gemeldeten Storungen (Incidents) aufzuzeichnen und zu versuchendiese schnellstmoglich zu beheben, um einen storungsfreien IT-Betrieb zugewahrleisten. Zu diesem Zweck wird eine Klassifizierung und Priorisierungder Storungen, bezuglich der Auswirkungen auf den Geschaftsbetrieb,vorgenommen. Die Incidents werden in der CMDB gespeichert und sind somitjederzeit abrufbar. Das Incident Management hat starke Verbindungen zuden Prozessen Problem und Change-Management.

Im Gegensatz zum Incident Management hat das Problem Managementden Zweck die Ursachen fur gemeldete Storungen zu identifizieren. Dazuwerden die Problems im ersten Schritt wiederum in Klassen aufgeteilt unddanach priorisiert. Hat man die Ursache eines Problems entdeckt, so wirdman beim Change Management einen Change beantragen. Die gefundenenund gelosten Probleme werden ebenfalls in der CMDB gespeichert.

Das Configuration Management ist Bestandteil des Service SupportSets und dient dazu alle Komponenten (CIs), ihre Schnittstellen und dieBeziehung zu anderen Komponenten zu ermitteln, zu beschreiben und zuuberprufen, ob sich diese Informationen noch auf dem aktuellen Standbefinden. Um diese Menge an Daten sinnvoll zu verwalten und abrufen zukonnen, dient die CMDB als Grundlage. Desweiteren ist die CMDB Basis furdie Arbeit anderer Service-Prozesse, wie zum Beispiel fur das Incident undChange Management, wichtig.

Die Aufgabe des Change Managements ist das Entgegennehmenund Aufzeichnen von Anderungsantragen (Request for Change (RfC)),welche eine oder mehrere Systemkomponenten umfassen und von derKundenorganisation, vom Problem Management oder aus anderen Prozessenbeantragt worden sind. Die RfCs werden daraufhin klassifiziert undbekommen eine Prioritat zugewiesen, damit eine kontrollierte Durchfuhrungder Anderungen gewahrleistet ist. Daruber hinaus ist das ChangeManagement fur die Planung, die Koordination und die Auswertung derbeantragten Anderungen zustandig.

Das Release Management hat das Ziel RfCs zu planen, zu erstellen,zu testen, zu implementieren (Roll Out) sowie verschiedene Versionsstandezu verwalten. Daruber hinaus ist es verantwortlich fur die Sicherheit derSystemintegritat, also fur die Erstellung von Roll-Back und Back-Out-Verfahren. Dieser Prozess arbeitet eng mit den Prozessen Configuration undChange-Management zusammen.

Die nachsten funf vorgestellten Prozesse gehoren zum Service DeliverySet.

Das Service Level Management (SLM) ist verantwortlich mit dem



Kunden sinnvolle Vereinbarungen (Service Level Agreements (SLAs)) uberdie IT-Services zu treffen und diese dann auch umzusetzen. Um dieseAufgabe wahrzunehmen muss das SLM die Bedurfnisse der Kunden, dieMoglichkeiten, sowie den finanziellen Spielraum des Unternehmens kennen.Zu den weiteren Aufgaben des Service Level Managements zahlt dieErstellung eines Service Katalogs, in dem alle Services enthalten sind, dievon der jeweiligen IT-Organisation erbracht werden konnen. Ein weiteresAufgabengebiet besteht in der Uberwachung der erbrachten Leistungen,sowie der Optimierung der Services und der Uberprufung der festgelegtenZiele.

Im Financial Management ist die betriebswirtschaftliche Komponente desITIL-Rahmenwerks angesiedelt. In diesem Bereich geht es um Fragen desAccounting, also der Ermittlung fur die Kosten einer Serviceerbringung, desBudgeting, also der Verwaltung des Budgets der IT-Organisation, sowie umFragen des Charging, womit die Verrechnung der Kosten an die Kundengemeint ist. Ziel dieses Kernprozesses ist die kosteneffiziente Verwaltung dervorhandenen IT-Ressourcen, sowie die Ermittlung der Ausgaben fur die ITund die Zuordnung der Kosten auf die einzelnen erbrachten Services.

Das Availability Management plant und steuert die Verfugbarkeit vonIT-Services und seiner Ressourcen. In diesem Zusammenhang werdenFaktoren wie die Moglichkeit der Auslagerung, Wartung und Wartbarkeit,Verlasslichkeit und Ausfallsicherheit von Komponenten der IT-Infrastrukturberucksichtigt. Zu den weiteren Aufgaben zahlt auch die Erstellungund Einhaltung von Backup- und Recovery-Planen bzw. Erstellung vonverfugbarkeitserhohenden proaktiven Maßnahmen.

Das Capacity Management ist zustandig fur die Planung, Uberwachungund die kostenoptimierte und zeitgerechte Bereitstellung von Ressourcen oderInfrastrukturkomponenten, die zur Erfullung der heutigen und zukunftigenGeschaftsanforderungen notwendig sind. Um diese Zielsetzung zu erfullen,setzt man Analysen ein aus denen man Prognosen uber den weiterenRessourcenverbrauch bestimmen kann. Somit ist das Capacity Managementein wichtiges Werkzeug, um das Risiko von Kapazitatsengpassen zuverkleinern und auch den effektiven Gebrauch bestehender Ressourcen zuverbessern.

Beim Continuity Management handelt es sich um einen Prozess, der furdie Sicherstellung des IT-Betriebs in Not- oder Ausnahmesituationenverantwortlich ist. Dazu zahlt, dass bei einem Ausfall ausreichendErsatzkomponenten zur Verfugung stehen und das Notfall- und Ausweich-Konzepte vorhanden sind. Zu diesem Zweck ist eine gut ausgebauteSıcherheitsarchitektur notwendig. Weiterhin erstellt das ContinuityManagement Analysen und Vorgehensweisen, wie Ausfalle vermieden,



oder eventuelle Produktionsausfalle wieder aufgeholt werden konnen.Die Funktion Service Desk nimmt eine besondere Rolle im ITIL-

Regelwerk ein, denn sie ist selbst kein Prozess, sondern eine Funktion andem mehrere Prozesse beteiligt sind. Beim Service Desk wird das Konzepteines

”Single Point of Contact“ (SPOC) eingesetzt, wodurch gewahrleistet

werden soll, dass es genau eine zentrale Schnittstelle zwischen dem Kundenund dem Unternehmen gibt. Dieses Konzept hat den Vorteil, dass alleStorungen, Anfragen, Verbesserungswunsche und Anregungen zentral erfasstwerden und dementsprechend bearbeitet oder weitergeleitet werden konnen.Deshalb sollte vermieden werden, dass ein Kunde bei einer Storung seinenbekannten Spezialisten anruft und diesen nach einer Losung fragt, weildadurch der optimale Weg, namlich der uber den Service Desk verletztwurde und Statistiken uber gemeldete Storungen aussagelos werden wurden.Desweiteren kann es aufgrund dessen auch zu Doppellosungen kommen,wodurch dem Betrieb wiederum Kosten entstehen wurden.

Die Hauptaufgabe des Service Desks ist die Entgegennahme vonStorungen und Kundenwunschen, welche z.B. per Telefon, Fax, e-mail, usw.eintreffen. Dazu wird im Idealfall ein Werkzeug eingesetzt, welches ITIL-konform ist. Bei der Annahme der Storungen sollte von den Mitarbeiterndes Service Desk wichtige Daten, wie z.B. Name, Datum, Symptome, usw.aufgenommen werden. Der Service Desk stellt im ITIL-Regelwerk den

”first-

line-support“ dar. Dies bedeutet, dass der Service Desk seinen Kundenversucht eine schnelle Hilfe zu geben. Dabei sollte nach [2] versucht werden,eine Erstlosungsrate von 80% zu erreichen. Dies ist moglich, in dem man demService Desk eine entsprechend große und umfangreiche Losungdatenbankzur Verfugung stellt, mit den bis zu diesem Zeitpunkt gefundenen Losungenund Umgehungslosungen (Workarounds).

Weitere Aufgaben des Service Desks sind den Kunden auf denaktuellen Stand ihrer Anfragen zu halten, z.B. falls ein neuer MitarbeiterZugangsberechtigungen fur eine Workstation benotigt, wird er sich beimService Desk melden und dieser wird ihm dann spater auch dieentsprechenden Accounts zukommen lassen.

Im ITIL-Regelwerk ist es auch vorgesehn, dass es”hinter“ dem first-

line-support, also dem Service, noch weitere support-lines gibt und zwarmindestens den second-line-support, welcher in den meisten Fallen vomProblem Management gebildet wird und den third-line-support, welcher ausSpezialisten-Gruppen besteht. Die Koordination dieser Gruppen ubernimmtebenfalls der Service Desk, weil Storungen auftreten konnen, die nicht vonden Mitarbeitern im Service Desk gelost werden konnen. Deshalb leitet derService Desk diese Storungen weiter an die secondund third-line-support-Gruppen.



Die letzte wichtige Aufgabe, die der Service Desk ubernimmt, ist dieInformation seiner Kunden bei z.B. Systemanderungen, Wartungsarbeiten,usw. . Dadurch wird gewahrleistet, dass die Kunden schon im vorhineinwissen, dass sie zu diesem Zeitpunkt nicht arbeiten konnen und nicht denService Desk kontaktieren, weil sie eine Storung vermuten.

1.3 Vorteile und Nachteile von ITIL

Nachdem der Aufbau der Library nun beschrieben ist, werden nun dieVorteile und Schwachstellen von ITIL kurz erlautert dargestellt.

Ein Vorteil besteht darin, dass ITIL ein”Best Practice“-Regelwerk

ist, weil die Prozesse in dieser Library sich uber Jahre als effektivund effizient herausgestellt haben und diese in ITIL nun gesammelt zurVerfugung gestellt wurden. Da die Prozesse wie ein Algorithmus als Vorlagegenommen werden konnen, konnen die darin beschriebenen Ablaufe ingleicher Qualitat wieder erbracht werden oder aber auch ruckgangig gemachtwerden. Aufgrund dieser standardisierten und automatisierten IT-Prozesselassen sich kostengunstigere IT-Services erstellen. Desweiteren ist auch dieZeit von ad-hoc Losungen im ITSM vorbei, da man genau beschriebenenAblaufen zu folgen hat.[4]

Weitere Vorteile sind[6]:

• ITIL beschreibt, welche Prozesse notwendig sind, um ein erfogreichesITSM durchzufuhren

• ITIL bietet eine Grundlage fur die wirtschaftliche und zweckmaßigeErbringung von IT-Servicedienstleistungen

• ITIL ist eine Beschreibung von Prozessen und Verfahren, die Raumlasst fur individuelle Implementation innerhalb einer Firma

• Mit ITIL profitiert man von den langjahrigen Erfahrungen von Nutzernmit großem IT-Anteil

• ITIL ermoglicht eine hohe Transparenz, Bewertbarkeit und somitPlanbarkeit eines ITSM

• ITIL stellt einen Standard im ITSM dar, an dem sich alle je nach Bedarforientieren konnen

• ITIL gibt die Moglichhkeit seine IT-Dienstleistungen zu bundeln undzu konzentrieren



• ITIL ermoglicht durch Einfuhren von Kennzahlen eine Beurteilung, wieeffizient die eingesetzten IT-Verfahren sind und ob diese uber einengewissen Zeitraum betrachtet effektiver gestaltet werden konnen.

Schwachpunkte von ITIL sind folgende[6]:

• ITIL beschreibt nicht, wie ein neues IT-Verfahren in eine Firmaeingefuhrt (Rollout) wird

• ITIL ist eine Beschreibung der wesentlichen IT-Servicefunktionalitaten.ITIL beschreibt aber nicht, wie eine Firma oder eine offentlicheInstitution diese IT-Servicefunktionalitaten implementieren kann. Diesist abhangig von den jeweiligen vorliegenden Gegebenheiten und bedarfeines guten Uberblicks uber viele Einzelheiten des taglichen IT-Servicegeschaftes.



2 Incident Management

2.1 Was ist das Incident Management?

Das Incident Management ist ein Kernprozess des ITIL-Rahmenwerks,genauer des Service-Supports-Sets. Die Ziele des Incident Managements sind:

• schnellstmogliche Wiederherstellung des”normalen“ storungsfreien

Betriebs

• Minimierung der Einflusse der Storungen auf die Geschaftsoperationen

Im folgenden werden die angefuhrten Punkte detaillierter erlautert.Die Hauptzielsetzung des Incident Managements ist es, seinen Kunden,die beim Service Desk eine Storung gemeldet haben, so schnell wiemoglich zu helfen. Man sucht dabei nicht nach der Ursache der Storung,sondern versucht mit Hilfe einer Wissensdatenbank, in der zu vielenIncidents Losungen oder Workarounds zur Verfugung stehen, demKunden zu helfen. Durch diese schnelle Hilfe soll erstens eine hoheAnwenderzufriedenheit erzielt werden, und zweitens die Kosten, die fur eineFirma durch die Storung entstehen, so klein wie moglich gehalten werden.

Beispiele[3]:

• Storung: Eine Workstation fallt komplett aus oder der Zugriff auf eineDatenbank ist nicht moglich. In beiden Fallen werden Aktionen desService Desks notwendig.

• Service Request: Ein neuer Mitarbeiter benotigt eine Workstationund die dazugehorigen Zugangs- und Zugriffsberechtigungen. DieseAnfrage wird vom Service Desk als Service Request behandelt, da dieInfrastruktur nicht verandert werden muss.

• Workaround: Ein Anwender kann auf seinem lokalen Drucker nichtmehr drucken. Als Sofortlosung kann ein Umrouten zu dem Druckereines Kollegen der Abteilung durchgefuhrt werden (Ad hoc-Losung).

Eine weitere Aufgabe des Incident Managements ist, dass Vereinbarungen(Service Level Agreements, kurz SLAs) die vertraglich zwischen dem Kundenund dem Incident Management getroffen worden sind, eingehalten werden.Unter einer Vereinbarung versteht man in diesem Zusammenhang eindeutigfestgelegte Grenzen nach welcher Zeit ein beeintrachtigter Service wiederfunktionieren muss.



Damit diese Ziele erreicht werden, gibt es einen fest vorgegebenenWorkflow, der beschreibt welche Verfahren man im Incident Managementeinsetzen sollte. Diese werden in dem nun folgenden Abschnitt detailliertbeschrieben.

2.2 Aufgaben des Incident Managements

2.2.1 Incident Annahme und Aufzeichnung

Als erster Schritt im Incident Management steht die Aufzeichnung allerbeim Service Desk gemeldeten Storungen. Dazu sollte man im Idealfallein entsprechendes Software-Werkzeug verwenden, welches vorgefertigteIncident-Erfassungs-Formulare verwendet. In diesen werden dann z.B. derName des Kunden, die Uhrzeit, die Symptome der Storung, usw. festgehalten.Diese erzeugten Datensatze wiederum werden in einer Incident ManagementDatenbank, welche ein Teil der CMDB ist, gespeichert.

Fruher mussten alle Storungen noch manuell, also von einem Service DeskMitarbeiter, in das System eingegeben werden. In der heutigen Zeit ist esebenso moglich den Kunden selber die Moglichleit zu geben ihre Storungendirekt in das System zu schreiben. Dabei muss allerdings sichergestelltsein, dass diese Storungsmeldungen trotzdem die Incident ManagementDatenbank errreichen und dass der Service Desk die Kontrolle uber dasIncident monitoring behalt.

Weitere Aufgaben in diesem Bereich sind die Koordination der secondund third-line-support-Gruppen, falls der Service Desk es mit seinen Kraftenund Kenntnissen nicht schafft die Storung zu beseitigen. In ITIL wird diesals funktionale Eskalation bezeichnet. In der Regel handelt es sich hier umdie Weitergabe an Support Gruppen, wie z.B. den On Site Support.[2]

2.2.2 Klassifikation und erste Unterstutzung

Nachdem der Incident im vorherigen Schritt aufgezeichnet wurde, wird imzweiten Schritt mit Hilfe dieser Details und der CMDB eine Klassifizierungvorgenommen. Diese hat die Aufgabe den Grund fur die Storung zu findenund somit auch eine schnelle Losung herbei zu fuhren. Dabei kann mandavon ausgehen, dass der großte Anteil der gemeldeten Storungen schonbekannt ist und schon Losungswege dafur existieren. Um die entsprechendenLosungen zu finden, nehmen die Mitarbeiter im Service Desk einen Abgleichmit der Problem und Known Error Datenbank vor und entscheiden danach,welche weiteren Aktionen durchgefuhrt werden sollen. Falls bei dem Abgleichfestgestellt wird das diese Storung schon ofters aufgetreten ist oder ein



Problem darstellt, so wird eine entsprechende Meldung an das ProblemManagement weitergeleitet, welches fur eine endgultige Beseitigung diesesIncidents dann zustandig ist.

Außerdem wird in diesem Schritt jedem Incident eine Prioritat zugeteilt,welche sich aus mehreren Faktoren zusammensetzt. Folgende Faktorenspielen bei der Priorisierung eine entscheidene Rolle:

• die Auswirkung auf den Geschaftsbetrieb, gemessen z.B. an der Anzahlbetroffener Kunden

• die Dringlichkeit fur den Geschaftsbetrieb, z.B. wie lange ein Servicemaximal

”down“ sein darf, bis eine Vereinbarung verletzt wird

• die Große und die Komplexitat der Storung

• die zur Verfugung stehenden Ressourcen, z.B. Mitarbeiter.

Falls dem Kunden nun eine fur ihn zufriedenstellende Losung derStorung erbracht worden ist, wird dieser Incident geschlossen (siehe IncidentAbschluss). Anderenfalls wird der Incident einer Support-Gruppe uberstelltund zum nachsten Schritt ubergegangen, namlich der Untersuchung undDiagnose des Incidents.

2.2.3 Untersuchung und Diagnose

Mit den aktualisierten Incident Details aus den vorherigen Arbeitsschrittenwird nun eine Analyse durchgefuhrt, welche als Ziel eine Losung desIncidents oder einen Workaround hat. Der Anwender soll dadurch in die Lageversetzt werden, seine Arbeit auch mit kurzfristig verschlechterten Servicesfortzusetzen.

Bei der Untersuchung der Incidents kann es auch passieren, dass dieFachkenntnisse der Support-Gruppen nicht ausreichen, um den Incidentzu losen. Deshalb werden in diesen Fallen externe Support-Gruppenhinzugezogen, namlich z.B. Spezialisten der Hersteller.

Weiterhin sollte jede Support-Gruppe, der ein Incident zugewiesen wordenist, folgende Aktivitaten durchfuhren:

• bei Zuweisung: Datum und Uhrzeit speichern, um dem Kunden via desService Desks, uber den Fortschritt seines Incident berichten konnen

• Service Desk bei gefundenem Workaround sofort unterrichten, fallsmoglich



• wenn notwendig, den Service Desk anweisen die Prioritat des Incidentsneu zu evaluieren

• Dokumentation aller gefundenen Informationen, wie z.B. die Losungdes Incidents, die verwendete Zeit, usw.

• Incident zur Schließung dem Service Desk zuruck ubertragen

2.2.4 Losung und Wiederherstellung

Nachdem man nun in allen vorherigen Schritten Losungsschritte durchgefuhrtund beauftragt hat, laufen diese jetzt in diesem Bereich zusammen und manversucht eine Losung oder Beseitigung der Storung durchzufuhren. Dabeikann man zwischen den folgenden drei Losungsarten unterscheiden:

• Workaround: In den vorherigen Arbeitsschritten ist eineUmgehungslosung erarbeitet worden, welche haufig noch von denjeweiligen Support-Teams umgesetzt wird. Es ist also nicht dieUrsache des Incidents gefunden worden, aber der Kunde kann seineArbeit innerhalb

”kurzer“ Zeit wieder aufnehmen.

• Losung: Es ist eine endgultige Losung fur die Storung ermitteltworden nun umgesetzt wird. Dabei wird es sich um schnelle undunburokratische Losungen handeln, wie z.B. Passwort zurucksetzen,Druckerpapier oder Toner nachfullen.

• Antwort auf einen Request for Change: Man erhalt eine Ruckmeldunguber den beim Change Management beantragten Request for Change.Dies kann entweder eine Bestatigung oder eine Ablehnung enthalten.

Desweiteren kann es neben den oben aufgefuhrten Losungen auch zueiner Wiederherstellung kommen, falls z.B. ein Server-Backup zuruckgespieltwerden muss, weil eine Festplatte ausgefallen ist.

2.2.5 Incident Abschluss

Als letzten Schritt nimmt man einen formellen Abschluss des Incidents vor.Darunter versteht man, dass dem Anwender eine Bestatigung der Losungbzw. Beseitigung seines Incidents geschickt wird und dieser dann geschlossenwird. Vor dem Schließen sollte der Service Desk allerdings sichergestellthaben, dass:

• alle zur Beseitigung der Storung notwendigen Details prazisedokumentiert wurden



• eine vollstandige und akkurate Klassifizierung der Ursache vorhandenist

• die Losung vom Kunden akzeptiert wird, mundlich oder besserschriftlich, z.B. per E-Mail

• alle weiteren Details bezuglich des Incidents erfasst wurden, wie z.B.Anwenderzufriedenheit, Bearbeitungsaufwand fur den Incident, Zeitund Datum des Abschlusses der Storung

2.2.6 Incident Ownership, Monitoring, Tracking undKommunikation

Dieser Subprozess fasst alle Aktivitaten zusammen, die parallel zu denvorherigen Schritten ablaufen. Darunter fallt die standige Benachrichtigungdes Kunden uber den Status seines gemeldeten Incidents, sowie auchdie Uberwachung und die Eskalation von Incidents. Bei der Eskalationvon Incidents unterscheidet man zwischen zwei verschiedenen Arten: derfunktionalen und der hierarchischen Eskalation.

Eine funktionale Eskalation bedeutet, dass man die Storung an eineandere Support-Gruppe, also second oder third line-support, weiterleitet.Dieses kann aufgrund von fehlenden Fachkenntnissen geschehen oder aberweil die Storung schon zu lange in dieser Abteilung

”liegt“. Man will

dadurch sicherstellen, dass ein Incident nicht fur eine lange Zeit unbearbeitetoder ungelost bleibt oder dass man ihn vielleicht

”vergisst“. Bei einer

hierarchischen Eskalation wird das entsprechende Management kontaktiert,weil die festgelegten Service-Vereinbarungen (SLAs) nicht eingehalten werdenkonnen oder schon gebrochen worden sind.

Desweiteren werden in diesem Bereich Management-Reports verfasst,welche dem Management als Grundlage zur Beurteilung des IncidentManagements dienen.

2.3 Rollen im Incident Managent

Im folgenden Abschnitt werden die einzelnen Rollen im Incident Managementvorgestellt.

2.3.1 Incident Manager

Der Incident Manager ist verantwortlich, dass das Incident Managementim Unternehmen umgesetzt, sowie auch entsprechend weiterentwickeltwird, damit schon am Service Desk (First-line-support) der Großteil



der gemeldeten Incidents bearbeitet werden kann. Weiterhin soll er dieEffizienz und die Effektivitat erhohen, indem er die Kennzahlen desIncident Managements in regelmaßigen Abstanden neu ermittelt, worauf imAbschnitt 2.4 Kennzahlen genauer eingegangen wird. Desweiteren stellt erdie relevanten Informationen fur die Geschaftsleitung zusammen und legtbei dieser Rechenschaft ab. Zu den weiteren Aufgaben zahlen die Zuordnungseiner Experten auf die entsprechenden Incidents und die Fahigkeit diePrioritat und die Schwere einer Storung zu erkennen und dementsprechendzu handeln.

In vielen Organisationen ist der Incident Manager und der Service DeskLeiter dieselbe Person.

2.3.2 Incident Support Personal

Neben dem Manager gibt es das Incident Support Personal, welches dieStorungen im Service Desk annimmt und bearbeitet. Das Support-Personalsollte bestimmte Fahigkeiten, namlich Fingerspitzengefuhl im Umgang mitverargerten Kunden, und naturlich technische Grundkenntnisse haben. Esist wichtig gut mit Menschen kommunizieren zu konnen, also diese auchfreundlich und ruhig zu behandeln, damit man alle relevanten Informationenzur Behebung von Incidents von dem Anwender erhalt und diesem dannauch schnell geholfen werden kann. Dieses geschieht dann am schnellstenper Remote Support oder aber direkt am Arbeistplatz des Kunden.Da die Arbeit im Service Desk sehr anstrengend sein kann, wird manwahrscheinlich Schichtbetrieb eingefuhren. Aufgrund dessen ist es essentielleine geeignete Ticketing-Software bzw. ITIL-konforme Software einzusetzen,damit Kollegen Informationen uber fruhere Incidents oder Workaroundseinsehen konnen.

Der angenehmste Teil des First-Line-Supports besteht in derBenachrichtigung der Kunden uber die Beseitigung seiner gemeldetenStorung.

2.4 Kennzahlen

Hier soll kurz auf wichtige Kennzahlen des Incidents Managementseingegangen werden, die dazu dienen diesen Prozess zu bewerten undanschließend auch zu beurteilen, um eventuell Verbesserungen vorzunehmen.Diese Kennzahlen sollten regelmaßig ermittelt werden, damit man dieSchwachpunkte moglichst fruh erkennt und entgegensteuern kann.

Folgende Kennzahlen sollten im Incident Management erfasst werden:

• Anzahl der gemeldeten Storungen, aufgeschlusselt nach Prioritat



• Durchschnittliche Reaktionszeit sowie Zeitdauer bei derStorungsbehebung

• Durchschnittliche Kosten des Incident Managements

• Anzahl der am Telefon oder per Remote-Zugriff losbaren Probleme(keine Fehlerbehebung vor Ort moglich)

• Anzahl von Storungem, die durch den First-Line-Support gelost werdenkonnten

• Anzahl von Storungen, deren Randparameter gegen eine definierteVereinbarung verstossen



3 Problem Management

3.1 Was ist das Problem Managements?

Das Problem Management ist der Prozess der am starksten mit dem IncidentManagement verzahnt ist, denn im Problem Management wird im Gegensatzzum Incident Management Ursachenforschung betrieben. Außerdem besitztdas Problem Management nicht nur reaktive Eigenschaften, sondern versuchtauch proaktiv das Auftreten von Storungen zu verhindern.

Folgende Ziele stehen im Mittelpunkt des Problem Managements[3]:

• optimale und schnelle Ursachenforschung bei allen Storungen,Unterbrechungen oder sonstigen Problemen

• die Elimination der Ursachen

• die Aufrechterhaltung der IT-Dienstleistungen

• die Vermeidung von langerfristigen IT-Systemunterbrechungen

• die Reduzierung der Auswirkungen und Schadensbegrenzung

• das Vermeiden von Problemen durch vorausschauendes Handeln

• das Einleiten von notwendigen Changes in der IT-Infrastruktur

In den folgenden drei Abschnitten wird detailliert auf die beidenSubprozesse Problem- und Fehler-Kontrolle, sowie auf die proaktivenMaßnahmen, eingegangen.

3.2 Problem-Kontrolle

”Die Problem-Kontrolle hat die Aufgabe, das Problem zu analysieren,

zu verstehen und in einen bekannten Fehler zu uberfuhren“ [2]. Dieserwiederum wird dann in die Known Error Datenbank (CMDB) eingegebenund steht somit dem Service Desk zur schnellen Bearbeitung von Incidentszur Verfugung. Der genaue Ablauf ist in Abbildung 1 zu sehen.

3.2.1 Problem Identifizierung und Registrierung

Im ersten Arbeitsschritt der Problem-Kontrolle werden die verfugbarenIncident Details aus dem Incident Management und Details aus der CMDBzusammengetragen und begutachtet. Aus diesen Daten wird ein Problem-Datensatz erstellt und in der CMDB hinterlegt, der sich kaum von einem



� ��

��

� ��

� ��

� ��

� ��

��

Abbildung 1: Aufgaben der Problem Kontrolle

Incident-Datensatz unterscheidet. Wichtig ist, dass darauf geachtet wird,dass alle Probleme erfasst werden und dass man Problem-Datensatze ihrenzugehorigen Incidents zuweist.

3.2.2 Klassifizierung bzw. Einordnen des erkannten Problems

Nachdem im vorherigen Schritt das Problem identifiziert und aufgezeichnetwurde, will man den Aufwand abschatzen konnen, der zur Losung desProblems notig ware. In diesem Zusammenhang spielen auch die getroffenen

”Vereinbarungen“ (SLAs) mit dem Kunden eine entscheidene Rolle, da

man seine Aktivitaten danach ausrichten muss. Dieser Prozess wird alsKlassifizierung bezeichnet. In der Praxis wird es nicht oft vorkommen, dassman Probleme verfolgt, denen nur ein einzelner Incident zugeordnet werdenkann, da es kosteneffizienter ist, schwerwiegendere Probleme zu losen.

Bei der Klassifizierung wird als erster Schritt das Problem einer Kategorie,wie z.B. Hardware, Software, Netzwerk, Datenbank, usw. zugewiesen. Danachversucht man eine Prioritat zu ermitteln, in dem man sich zwei Fragen stellt:

1. Wie schnell muss das Problem beseitigt werden? (Dringlichkeit)

2. Welche Auswirkung hat das Problem auf die Geschaftsprozesse?(Auswirkung)

Aus diesen beiden Komponenten setzt sich die Prioritat zusammen, welchebestimmt in welcher Reihenfolge und mit welchem Aufwand an Ressourcenein Problem bearbeitet wird.



”Die Klassifizierung ist nicht statisch, sondern kann im Laufe des

Lebenszyklus eines Problems geandert werden. Wenn zum Beispiel einWorkaround oder eine schnelle Losung vorhanden ist, kann die Dringlichkeiteines Problems herabgesetzt werden und das Auftreten weiterer gleichartigerStorungen kann die Auswirkungen eines Problems verschlimmern.“[7]

3.2.3 Untersuchung und Diagnose

Dieser Prozess des Problem Managements hat die gleichen Aufgaben wieder Prozess

”Untersuchung und Diagnose“ des Incident Managements.

Allerdings verfolgen beide Prozesse ein gegensatzliches Ziel, da das IncidentManagement auf die schnelle Wiederherstellung des storungsfreien Betriebszielt und das Problem Management Ursachenforschung betreibt, um dasweitere Auftreten von Incidents zu verhindern.

Die Untersuchung und die Diagnose sind ein iterativer Vorgang, bei demExpertengruppen als Hilfe hinzugezogen werden. Man versucht dabei mitjeder Wiederholung der Losung des Problems naher zu kommen. Bei denWiederholungen wird man sich hauptsachlich darauf konzentrieren mit Hilfevon verschiedenen Umgebungen das Problem zu reproduzieren und danacheinen Workaround zu erarbeiten.

3.3 Fehler-Kontrolle

Nachdem man die Ursache fur das Problem im vorherigen Prozess, derProblem-Kontrolle, identifiziert hat, wird nun versucht eine endgultigeLosung fur das Problem herbeizufuhren, indem die bekannten Fehler gelostwerden. Dabei unterliegt es der Geschaftsleitung zu entscheiden, ob wirklichjedes Problem gelost werden soll oder ob man sich nur auf die besondersschwerwiegenden Probleme konzentriert. Der gesamte Ablauf der Fehler-Kontrolle ist in Abbildung 2 dargestellt.

3.3.1 Fehler-Identifikation und Aufzeichnung

Ein Fehler liegt vor, falls ein fehlerhaftes Configuration Item (CI) gefundenwurde. Der Status

”bekannter Fehler“ wird vergeben, wenn man auch die

Ursache fur das Fehlverhalten des CI kennt und eine Umgehungslosunggefunden worden ist. Zu diesem Zeitpunkt beginnt die Fehler-Kontrolle mitihrer Arbeit und erfasst zuerst alle relevanten Daten, um den

”bekannten

Fehler“ endgultig zu beseitigen.



� ��

� ��

��

��

��

��

� ��

� ��

��

Abbildung 2: Aufagen der Fehler-Kontrolle

3.3.2 Fehler-Bewertung

Nachdem die Fehler erfasst worden sind, wird wie auch im IncidentManagement und der Problem-Kontrolle der Fehler bewertet. Dabeiwird abermals auf die Kriterien Dringlichkeit und Auswirkung auf denGeschaftsbetrieb zuruckgegriffen und aus diesen dann eine Prioritaterrechnet. Dieser Vorgang wird unter Zuhilfennahme von Spezialistendurchgefuhrt.

Außerdem werden bei der Fehler-Bewertung mogliche Losungswege und-moglichkeiten ermittelt und definiert um dann dem jeweiligen Mitarbeiteroder Team zugeordnet zu werden.

3.3.3 Aufzeichnung der Fehlerbeseitigung

In diesem Arbeitsschritt werden die zuvor ermittelten Losungswegedokumentiert,wobei es wichtig ist, dass man alle bereits gefundenenLosungsmoglichkeiten zur Beseitigung eines

”bekannten Fehlers“ der CMDB,

genauer der”Known Error Datenbank“, hinzufugt, damit dem Incident

Management diese Hilfen bei der ersten Unterstutzung zur Verfugung stehnund das Problem Management diese bei anderen Problemen wiederverwendenkann.



Desweiteren werden falls notwendig”Requests for Change“ in diesem

Bereich in Auftrag gegeben, welche im Change Management genauerbetrachtet werden. Falls das Change Management entscheidet diesen RfCdurchzufuhren, so wird nach dessen Umsetzung ein

”Post Implementation

Review“ (PIR) stattfinden. Dabei werden Tests durchgefuhrt und manevaluiert die gefundene Losung mit dem Kunden. Wenn der Kunde mit derLosung einverstanden ist, kann man das Problem abschließen.

3.3.4 Fehler-Abschluss

Unter dem Fehler-Abschluss versteht man den formellen Abschluss desbearbeitenden Falles. Dazu zahlt, dass der Status des Problems in der CMDBauf

”gelost“ gesetzt wird und alle beteiligten Stellen eine Ruckmeldung

erhalten, damit z.B. das Incident Management alle mit diesem Problemverbundenen Storungen ebenfalls schließen kann.

3.3.5 Uberwachung

Der Prozess Uberwachung findet begleitend zu den restlichen Prozessen derFehler-Kontrolle statt. Zu den Tatigkeiten in diesem Bereich zahlen standigeStatuskontrolle der Problem- und Fehlerbeseitigung, damit im

”schlimmsten

Fall“ das Management schnell kontaktiert werden kann und entsprechendeEskalationen stattfinden.

3.4 Proaktives Problem Managements

Nachdem in den vorhergehenden beiden Unterkapiteln detailliert auf diereaktiven Eigenschaften des Problem Managements eingangen wurde, wirdim Folgenden die proaktive Seite erlautert. In diesem Bereich versucht manschon zukunftig auftretende Storungen zu erkennen und zu beseitigen. Zudiesem Zweck betrachtet man Komponenten genauer, die anfallig sind oderbei denen eine Uberlastung droht.

3.4.1 Trendanalyse

Ein Werkzeug um proaktiv gegen Incidents vorzugehen ist ein Trendanalyse-System einzusetzen. Dabei ist das Ziel

”schwache“ Komponenten in der

IT-Infrastruktur zu identifizieren und in einem zweiten Schritt (sieheVorbeugende Maßnahmen) gegen diese Schwachstellen vorzugehen. DieTrendanalyse dient der Identifikation von [2]:



• erkennbaren Trends (z.B. von wahrend Changes, eingebauterProblemtypen)

• Fehlern bestimmten Typs

• wiederkehrenden Storungen eines bestimmten Typs oder Fehlern beibestimmten einzelnen Infrastruktur-Elementen

• Schulungsbedarf der IT-Anwender oder besserer Dokumentation

Bei der Durchfuhrung der Trendanalyse wird das Problem Managementnach Verhaltensmustern innerhalb der aufgetretenen und behobenen Fehlersuchen, die auf eine eindeutige Fehlerursache schliessen lassen. Zu diesemZweck analysieren die Mitarbeiter des proaktiven Problem Managements dieverfassten Management-Reports, lesen Literatur, die bei der Analyse helfenkonnte, besuchen Konferenzen oder befragen ihre Mitarbeiter. Außerdemkann es in manchen Fallen hilfreich sein, sich mit Herstellern von dereingesetzten Software/Hardware zu beraten.

Ein Beispiel fur die Vorbeugung eines Fehlers ware: Wenn in einerFirma mehrere Router des gleichen Typs sukzessive mit dem gleichen Fehlerausfallen, so kann man mit großer Wahrscheinlichkeit davon ausgehen, dassauch die restlichen eingesetzten Router dieses Typs in nachster Zeit ausfallenwerden. Deshalb sollte man diese dann schon fruhzeitig austauschen.

Die Anwendung von Trend-Analysen macht alllerdings nur dann Sinn,wenn dem Problem Management auch ausreichend historische Daten zurVerfugung stehen, da die Aussagekraft dieses Verfahrens ansonsten sehrbegrenzt ist.

3.4.2 Vorbeugende Maßnahmen

Nachdem man eine Trendanalyse durchgefuhrt hat und man nun die

”Schwachstellen“ seines Unternehmens bzw. IT-Infrastruktur kennt, sollte

man sich mit der Beseitigung dieser beschaftigen. Dabei spielt es allerdingsauch eine wichtige Rolle, ob diese Fehlerquellen bei einem Ausfall uberhaupteinen großen Einfluss auf den Geschaftsbetrieb hatten. Aufgrund dessen wirdin ITIL das Konzept eines

”pain factors“ vorgeschlagen. Dabei wird jeder

Incident-Kategorie ein”pain value“ zugeordnet, welcher sich mit einer Formel

berechnen lasst, in die folgende Großen mit einfliessen:

• die Gesamtanzahl an Incidents

• die Anzahl Mitarbeiter, die von der Storung betroffen sind



• die Dauer und die dafur anfallenden Kosten fur die Losung einesIncidents

• die Kosten fur das Unternehmen.

Durch den Einsatz dieses Konzeptes wird vermieden, dass sich dasProblem und Incident Management mit Fehlern auseinandersetzt, dienormalerweise keinen großeren Einfluss auf den Geschaftsbetrieb hatten.Nachdem man nun die wichtigen Problemfelder erkannt hat, sollte dasProblem Management entsprechende Aktionen durchfuhren. Dazu zahlt z.B.:

• einen RfC einzuleiten

• das Service-Support-Personal besser zu schulen

• Schulung der Kunden

3.5 Problem Manager

Der Problem Manager besitzt die Aufgabe den Prozess Problem Managementim Unternehmen einzufuhren und diesen auch stetig weiter zu entwickeln.Er muss die Effizienz und die Effektivitat der Problem- und Fehler-Kontrolle beurteilen und gegebenenfalls Anderungen vornehmen und erist verantwortlich fur die Beschaffung und Einteilung der vorhandenenRessourcen auf die einzelnen Problems. Desweiteren muss er Management-Berichte verfassen und diese auch zur proaktiven Vermeidung von Storungenund Problemen nutzen. Zu seinen weiteren Aufgaben gehoren die Beurteilungdes proaktiven Problem Managements, sowie auch die Durchfuhrung bzw.Begleitung von Problem Reviews.

3.6 Kennzahlen

In diesem Abschnitt sollen kurz die verwendeten Kennzahlen im ProblemManagement eingefuhrt werden. Diese sollte man in regelmaßigen Abstandenerheben, damit das Management sieht, wo es noch zu Verbesserungenkommen muss und in welchen Bereichen man seine gesetzten Ziele schonerreicht hat.

Folgende Kennzahlen sollte man im Problem Management ermitteln [6]:

• Proaktiv gefundene Fehlerursachen

• Kosten



• Anzahl der erfolgreich eingeleiteten RfCs und durchgefuhrtenAnderungen

• Noch offene, aber bekannte Fehler

• Geloste und dokumentierte Fehler

• Fehler, die einer speziellen Problemursachen zugeordnet werdenkonnen, bevor diese Ursache beseitigt wurde

• Anzahl von Auftragen an externe Vertragspartner zur Beseitigung vonProblemfeldern

• Anzahl an Fehlerursachen, die Garantiefalle sind



4 Zusammenfassung

Das Incident und das Problem Management sind zwei sehr wichtige Kern-Prozesse des ITIL-Regelwerks, da sie die Grundlage fur eine effizienteund effektive Fehlerbeseitigung darstellen. Deshalb sollte man diese beidenProzesse auch als Erstes bei einer Umsetzung von ITIL im Unternehmen,implementieren.

Die wichtigsten Aufgaben und Ziele der beiden Prozesse sollen an dieserStelle nochmal kurz gegeneinander abgegrenzt werden, damit der Unterschieddeutlich wird. Das Incident Management hat die Aufgabe dem Kunden, derseine Storung beim Service Desk meldet, so schnell wie moglich zu helfen. Zudiesem Zweck greift das Support-Personal auf eine Datenbank, namlich derKnown Error Datenbank, in der CMDB zuruck. In dieser stehen alle bishererstellten und dokumenterten Workarounds des Problem Managements.

Das Problem Management hingegen hat im Gegensatz zum IncidentManagement nicht die Aufgabe dem Kunden schnell zu helfen, sondern sollsich auf die Ursachenforschung fur die gemeldeten Incidents machen, damitdiese in Zukunkt nie mehr auftreten. Dabei kann es auch zu Konflikten mitdem Incident Management kommen, welche dann vom Management beseitigtwerden mussen. Desweiteren wird das Problem Management fur die proaktiveFehersuche in der Firma eingesetzt bei der z.B. die IT-Infrastruktur aufSchwachstellen hin untersucht wird, um zukunftigen Fehlern vorzubeugen.Dieses Verfahren wird allerdings nur bei wichtigen IT-Komponenten desUnternehmens eingesetzt, bei denen ein Ausfall zu hohen Kosten fuhrenwurde.



5 Literatur

Literatur

[1] Office of Government Commerce (OGC). Service Support. pages 1-120, 2000.

[2] Frank Victor, Holger Gunther. Optimiertes IT-Management mitITIL. Vieweg, 2005.

[3] Wolfang Elsasser. ITIL einfuhren und umsetzen: Leitfaden fureffizientes IT-Management durch Prozessorientierung. Hanser, 2005.

[4] Hubert Staudt, Materna GmbH, Dortmund. ITIL vereinheitlichtIT-Service-Prozesse. Information Management and Consulting,Germany, vol. 18, no. 4, pages 63-67.

[5] Hans-Heinz Wisotzky, Materna GmbH, Dortmund.Einfuhrungskonzepte fur ITIL (IT Infrastructure Library).Information Management and Consulting, Germany, vol. 19,no. 1, pages 7-9.

[6] Peter T. Kohler ITIL Das IT-Servicemanagement Framework.Springer, 2005.

[7] IT Service Management - Eine Einfuhrung basierend auf ITIL.itSMF, 2004.


ITIL - Incident- & Problem Management - cs.fau.de · ITIL-Incident- & Problem Management 2 5...

Documents

Transcript of ITIL - Incident- & Problem Management - cs.fau.de · ITIL-Incident- & Problem Management 2 5...