Kitabı oku: «Handbuch IT-Outsourcing», sayfa 42

b) Incident-Management

822

Ein Incident-Management dient nach der Vorstellung von ITIL V3 (2011) der schnellstmöglichen Wiederherstellung des normalen Servicebetriebs bei minimaler Störung des Geschäftsbetriebs, dabei muss das bestmögliche Niveau der Verfügbarkeit und des Service aufrechterhalten werden.[408] Dabei ist eine Störung (Incident) ein Ereignis, das nicht zum standardmäßigen Betrieb eines Service gehört und das tatsächlich oder potenziell eine Unterbrechung oder eine Minderung der Service-Qualität verursacht. Die Auslagerung, sprich das Outsourcing eines Incident-Managements im Zusammenhang mit Service-Level-Agreements, kann sehr vielversprechend sein, da der Service bzw. die unterstützten Geschäftsprozesse nach einer in den Service-Level bestimmten Zeit wieder unterstützt werden kann. Ist die Fehlerbehebung[409] nicht innerhalb der im Service-Level bestimmten Zeit erfolgt, kann der dadurch entstandene Schaden durch Pönalzahlungen oder durch Schadensersatz aufgefangen werden. Somit wären die Gefahren für den Kunden entsprechend vorsehbar und gering zu halten.

823

Der Prozess eines Incident-Managements nach ITIL V3 (2011) läuft wie folgt ab: Dabei wird entweder vom Service Desk, aus dem RZ-Betrieb, aus dem Netzbetrieb (LAN/WAN) aus der Organisation oder aus anderen Quellen die Meldung eines Incidents (Fehler) erzeugt. Diese Incident-Meldung wird zunächst „erkannt und dokumentiert“ und danach im Ticketsystem „klassifiziert.“ Handelt es sich dabei um einen bekannten Fehler so wird dieser im Wege der Soforthilfe behoben. Ist eine sofortige Behebung nicht möglich, wird in einem Service Request entschieden, ob eine Diagnose des Fehlers vorgenommen wird, um den Fehler zu lösen und das System wiederherzustellen oder ob der Fehler in einem Prozess Service Request geschlossen werden kann. Ist eine Lösung und Wiederherstellung nicht möglich, muss der Fehler im Wege des Change-Managements behoben werden. Dies könnte z.B. dann der Fall sein, wenn ein Patch eingespielt wird und dieser Patch mit Fehlern behaftet ist, welche erst durch ein neues bzw. anderes Patch behoben werden können (Change-Management).

824

Die Diagnose-Informationen über den Incident werden in einer Datenbank gesammelt, welche auch dem Problem-Management hilft, die Ursachen der Fehler zu finden. Die benötigen Informationen die das Incident-Management über Ownership, Verfolgung, Auswertung und Information benötigt, werden aus der Configuration Management DataBase (CMDB)[410] bezogen, welche entsprechend vom Kunden bzw. bei einem Auslagern des Configuration-Managements vom Provider gepflegt werden muss.

825

Mitarbeiter verschiedener Funktionen werden Support-Teams zugeteilt, die für die Störungsbeseitigung zuständig sind (siehe Abbildung 47). Diese Teams werden aufgrund ihrer Kenntnisse und Fähigkeiten gebildet, und in First-, Second-, Third-Level-Support eingestuft. Die zur Störungsbeseitigung benötigten Mitarbeiter der Support-Teams werden durch die funktionale Eskalation hinzugezogen.

826

Der First-Level-Support wird meist aus den Reihen des Service Desks (siehe dort) gestellt, wobei der Second-Level-Support Administration, Netzwerk-Management, TK-Management, Server-Management und die zentrale Datenverarbeitung umfasst. Entwickler und IT-Architekten stellen den Third-Level-Support, gefolgt von den Dienstleistern und Produktspezialisten des Fourth-Level-Support. Weitere Support-Teams (n-Level-Support) können je nach organisatorischen Erfordernissen gebildet werden.[411]

c) Problem-Management

827

Häufig wird in der Praxis außerhalb von ITIL V3 (2011) das Incident- und das Problem-Management als ein Auslagerungsbereich gesehen, weil es hierbei um die Behebung von Fehlern geht.[412] Der ITIL V3 (2011)-Quasi-Standard differenziert aber deutlich zwischen Incident- und Problem-Management. Danach minimiert das Problem-Management die durch Fehler in der Infrastruktur verursachten Störungen und Probleme, die Auswirkungen auf den Geschäftsbetrieb haben, und verhindert proaktiv das Auftreten von Störungen, Problemen und Fehlern.[413] Danach unterscheiden sich die Prozesse des Incident- und Problem-Managements in ihrer Aufgabenstellung. Das Incident-Management hat die Aufgabe, den Service so schnell wie möglich wieder für den geschäftlichen Benutzer verfügbar zu machen. Das Problem-Management hat dagegen die Aufgabe, die Ursachen zu ermitteln, die einer Störung zugrunde liegen, und anschließend Wege zur Behebung und Vorbeugung zu finden.[414] Ist ein Kunde an der tatsächlichen Verbesserung des Service-Managements interessiert, sollte er die Auslagerungsbereiche (Outsourcing-Tasks) Incident- und Problem-Management nur gemeinsam auslagern. Sollte er lediglich den Bereich (Task) Incident-Management auslagern und dies auch pro Vorfall (Störung) vergüten, so könnte dies sehr schnell zu einer Kostenerhöhung führen, da der Provider gar nicht an der Verbesserung des Service-Managements und des entsprechenden IT-Prozesses interessiert ist, da er pro Vorfall (Störung) vergütet wird.

828

Der Prozess eines Problem-Managements nach den Anforderungen der ITIL V3 (2011) läuft wie folgt ab: Zunächst taucht ein einzelner Incident (Fehler) in der IT-Infrastruktur des Kunden auf. In der Klassifizierung des Incident stellt sich heraus, dass dieser Fehler möglicherweise auch bei anderen Usern auftauchen könnte. Somit wird aus dem Incident ein Problem, welches im Wege des Problem-Managements behoben werden muss. Dies sollte natürlich proaktiv erfolgen, um weitere Incidents und damit Ausfälle zu meiden. Kann der Fehler nicht im Wege des Problem-Managements behoben werden, so muss das Problem-Management einen Prozess in Richtung des Change-Managements anstoßen, um das Problem durch einen Request for Change (RFC)[415] zu lösen. Dies kann im Einzelfall zum Austausch ganzer Software-Applikationen bzw. Hardwareeinheiten führen.

829

Das Auslagern des Problem-Managements nach ITIL V3 (2011) sollte immer in Zusammenhang mit dem Incident-Management erfolgen, da nur durch enge Verbindung zwischen Problem- und Incident-Management entsprechende Synergien (vor allem proaktiv) erschlossen werden können, die die Total Cost of Ownership (TCO) tatsächlich sinken lassen.

d) Configuration-Management

830

Der Auslagerungsbereich (Outsourcing-Task) des Configuration-Managements stellt nach ITIL V3 (2011) ein logisches Modell der IT-Infrastruktur zur Verfügung – dies geschieht durch das Identifizieren, Kontrollieren, Pflegen und Verifizieren der Versionen aller existierenden Konfigurationselemente.[416] Ziel ist es hierbei alle IT-Komponenten zur Unterstützung andere Service-Management-Prozesse zur Verfügung zu stellen, um eine solide Basis für das Incident-, Problem-, Change- und Release-Management zu schaffen. Des Weiteren um die Dokumentation auf Übereinstimmung mit der Infrastruktur zu überprüfen und Abweichungen zu korrigieren. Das Configuration-Management nach ITIL V3 (2011) besteht dabei aus fünf grundlegenden Aktivitäten:

–	Planung
–	Identifizierung (Identification)
–	Kontrolle (Control)
–	Statusnachweis (Status Accounting)
–	Verifizierung und Audit (Verification and Audit)

831

Alle Information über Details und wechselseitige Beziehungen zwischen Konfigurationselementen (Configuration Items; CIs) sollten nach ITIL V3 (2011) an einer einzigen Stelle zusammengeführt werden: in einer Konfigurations-Datenbank (Configuration-Management Database, CMDB).[417] Auf deren zentralen Speicher für Information wird aus allen Prozessen des Service-Managements zugegriffen; sie ist damit ein wichtiges Instrument von Konsistenz zwischen den IT-Prozessen.[418] Aufgabe des Providers ist es, bei der Auslagerung dieses Bereichs (Tasks) diese Datenbank mit den entsprechenden CIs (CI = Configuration Items) zu pflegen, zu warten und entsprechende Neueinträge vorzunehmen oder CIs aus dem System zu nehmen.

e) Change-Management

832

Sieht man das Change-Management nicht als sporadischen Vorgang an, sondern als ständigen Prozess zur Verbesserung des IT-Service-Managements, so kann es eine erhebliche Bedeutung beim Outsourcing haben.[419] Nach ITIL V3 (2011) stellt das Change-Management sicher,[420] dass standardisierte Methoden und Verfahren für eine effiziente und prompte Handhabung aller Änderungen verwendet werden, damit die Auswirkung von änderungsbedingten Störungen für den Service minimiert werden.[421] Ob das Change-Management tatsächlich als eigenständiger Auslagerungsbereich i.S. e. Outsourcing angesehen werden kann, ist fraglich, vielmehr könnte es auch Teil anderer ITIL V3 (2011)-Auslagerungsbereiche sein. Das Change-Management könnte aber auch sinnvollerweise zu den Bereichen gehören, die im Rahmen eines Vendor-Managements beim Kunden verbleiben sollten, um somit eine bessere Steuerung des Providers zu gewährleisten. Dabei würde das nach dem ITIL V3 (2011) geforderte Change-Advisory-Board (Änderungsbeirat; CAB) über Request for Change (RFC‘s) beraten und unter dem Blickwinkel der geschäftlichen Anforderung Empfehlungen darüber abgeben, ob die z.B. vom Provider vorgeschlagenen Änderungen akzeptiert und implementiert oder abgelehnt werden sollten.[422] Bei der Auswahl des CAB sollte immer darauf geachtet werden, dass alle Änderungsvorschläge sowohl geschäftlicher als auch aus technischer Sicht kompetent sind, denn nicht unbedingt jeder Release-Wechsel führt automatisch zur Performance-Verbesserung oder zur Kostenreduzierung.

Abb. 47:

Change-Managements bei Incidents

[Bild vergrößern]

833

Die Abbildung 47 zeigt die Verantwortlichkeit des Change-Managements bei Incidents, die vom Service Desk gemeldet werden.

f) Release-Management

834

Das Release-Management hat einen ganzheitlichen Blick auf Änderungen an IT-Services und stellt sicher, dass alle Aspekte eines Releases – sowohl technische als auch nicht-technisch –gemeinsam betrachtet werden.[423] Das Release-Management sollte dabei eingesetzt werden für:

–	umfangreiche oder kritische Hardware-Einführungen
–	größere Software-Einführungen
–	das Bündeln von mehreren, aufeinander bezogene Änderungen

835

Durch die enge Verknüpfung des Release-Managements mit dem Change-Management stellt sich auch hier die Frage, ob das Release-Management nicht i.S. e. Vendor-Managements beim Kunden verbleiben sollte, um auch somit eine bessere Steuerung des Providers beim Release-Wechsel zu haben.

g) Service-Level-Management

836

Beim Auslagerungsbereich (Task) des Service-Level-Managements handelt sich im Wesentlichen um einen Prozess, der sich auf alle (oder die meisten) Auslagerungsbereiche (Tasks) auswirkt bzw. andere Auslagerungsbereiche unterstützt. Dabei stellt das Service-Level-Management (SLM) sicher, dass die Service-Ziele in Service-Level-Agreements (Leistungsverträgen)[424] dokumentiert werden; außerdem überprüft und überwacht es den tatsächlichen erbrachten Service auf Einhaltung der entsprechenden SLA-Zielvorgaben. Das Service-Level-Management (SLM) sollte unter Einhaltung der herrschenden Kosten-Beschränkungen darüber hinaus nach ITIL V3 (2011) proaktiv die Verbesserung aller Service-Level anstreben.[425] Hierbei können entsprechende Service-Level bzw. Service-Level-Agreements auf drei verschiedenen Layern (Schichten) festgelegt werden, und zwar auf dem:

–	Layer der Geschäftsprozesse
–	Layer der IT-Prozesse
–	Layer der IT-Technologie/-Infrastruktur

aa) Der SLM-Prozess

837

Das Service-Level-Management (SLM) sollte immer ein gemeinsames Thema von Kunden und Provider sein. Der Kunde hat zudem mit einem gut funktionierenden Service-Level-Management (SLM) die Möglichkeit i.S. eines Vendor-Managements den Provider zu monitoren (i.S.v. überwachen) und zu steuern. Des Weiteren können durch das Service-Level-Management (SLM) die Beziehung zwischen Kunden und Provider gemeinsam positiv weiterentwickelt werden.[426]

bb) Beziehungen zu anderen ITIL V3 (2011)-Prozessen

838

Die Prozesse und Funktionen des Service-Managements zielen letztlich auf die Erbringung qualitativ hochwertiger IT-Services für den Kunden und dessen Geschäftsprozesse. Außer der Funktionsfähigkeit der Prozesse in diesem Sinne sind einige Punkte für das Service-Level-Management besonders wichtig.

(1) Beziehung zum Service Desk

839

Beim Service Desk handelt es sich nach ITIL V3 (2011) um keinen Prozess, sondern um eine Funktion.[427] Die Funktion des Service Desks und des Service-Level-Managements ist dabei sehr wichtig. Als direkter Zugang des Anwenders des Kunden sorgt das Service Desk des Providers für eine Kanalisierung aller Anwenderanfragen. Dabei werden alle Anfragen und Beschwerden vom Service Desk aufgenommen und als Information dem Service-Level-Management zur Verfügung gestellt, um daraus Schlussfolgerungen zu ziehen, um den Service für den Kunden zu verbessern.

(2) Beziehung zum Incident-Management

840

Die zentrale Aufgabe des Incident-Managements ist es, bei Störungen für eine schnelle Wiederherstellung der Services zu sorgen. Dies hat für verschiedene Indikatoren der Service-Levels, z.B. den der Verfügbarkeit, direkte Auswirkungen. Für das Service-Level-Management des Providers sind die Informationen, wann welche Services wie häufig ausgefallen sind, wichtig, um die Qualität des Services zielgerichtet im Rahmen des Service-Quality-Plans für den Kunden zu verbessern.[428]

(3) Beziehung zum Configuration-Management

841

Auch SLA sind als Konfigurationselement (Configuration Item – CI) in der CMDB[429] erfasst. Durch die Relationen in der CMDB können die relevanten SLAs zu einem anderen CI schnell festgestellt werden. Das Configuration-Management des Providers sorgt so für einen schnellen Informationsfluss und somit indirekt für die Beachtung und Einhaltung der SLAs[430] zwischen Kunden und Provider.

(4) Beziehung zum Availability-Management

842

Das Availability-Management ist nach ITIL V3 (2011) für die Realisierung und Optimierung der Verfügbarkeit der Services zuständig.[431] Dabei kann sich die Verfügbarkeit sowohl auf die IT-Prozesse als auch auf die IT-Infrastruktur (Hard- und Software) beziehen. Die Verfügbarkeit ist einer der am häufigsten verwendeten Service-Levels. Das Availability-Management kann gerade dem Provider helfen, die vereinbarten Service-Levels zwischen den Kunden und dem Provider zu halten und für geplante Services zu berechnen und bei realisierten Services zu quantifizieren.

(5) Beziehung zum Capacity-Management

843

Das Capacity-Management beschäftigt sich mit dem Management der Kapazität aller für die IT-Services benötigten IT-Infrastruktur-Komponenten.[432] Zu diesem Zweck wird ein Capacity-Plan gepflegt, der Informationen über die aktuelle Zusammensetzung der Infrastruktur sowie Planungen für die Zukunft enthält. Inwieweit diese Planung allein vom Kunden vorgenommen wird oder gemeinsam, sollte entsprechend vertraglich geregelt sein. Da das Capacity-Management Informationen, welche Kapazitäten für die Erstellung welcher Services verwendet wurden, dem Service-Level-Management liefert, sollte eine sinnvolle Aufgabenverteilung zwischen Kunden und Provider im Vorfeld erfolgen. Das Service-Level-Management liefert dem Capacity-Management Informationen über die aktuellen und künftigen Services.[433] Diese Informationen sind für eine genaue Kapazitätsplanung unerlässlich und sollte in den entsprechenden Lenkungsausschüssen zwischen den Outsourcing-Partnern besprochen werden.

(6) Beziehung zum Change-Management

844

Im SLA zwischen den Outsourcing-Partnern kann festgehalten werden, welche Änderungen die Kundenorganisation einreichen kann und welche Vereinbarungen bezüglich der Abwicklung dieser Änderungen eingehalten werden sollen (wo werden Änderungen eingereicht, Zeitbedarf, Kosten, Informationen an die Organisation). Zudem kann eine Änderung Folgen für die vereinbarten Service-Levels haben. Die erforderlichen Änderungen eines Services und des zugehörigen SLAs werden vom Change-Management veranlasst. Letztlich ist, da jeder SLA auch ein CI ist, jede Änderung bzw. das Hinzufügen eines SLAs unter die Kontrolle des Change-Managements zu stellen.[434]

(7) Beziehung zum IT-Service-Continuity-Management

845

Aufgabe des IT-Service-Continuity-Managements des Providers ist die schnelle Wiederherstellung des IT-Services nach Notfällen sowie die Überwachung der Maßnahmen und zugehörigen Verfahren.[435] Die diesbezüglichen Vereinbarungen mit dem Kunden werden neben den gewünschten Maßnahmen und den damit verbundenen Kosten im SLA festgehalten. Insbesondere bei der Verhandlung von Absicherungsverträgen müssen die Kontinuitätspläne der eigenen IT-Organisation und die des externen Dienstleisters aufeinander abgestimmt werden.[436]

(8) Beziehung zum Security-Management

846

Sicherheitsaspekte wie die Vertraulichkeit und Datenintegrität sind wesentlich zur Beschreibung eines Services und finden daher Niederschlag in den SLAs zwischen den Outsourcing-Partnern. Das Security-Management übernimmt die Realisierung und Überwachung der Sicherheitsvereinbarungen und lässt dem Service-Level-Management diesbezüglich Berichte zukommen.[437]

(9) Beziehung zum Financial-Management

847

Das Financial-Management stellt dem Service-Level-Management im Rahmen der Kostenrechnung Informationen über die Kosten zur Verfügung, die bei der Realisierung eines Services verursacht wurden, und kann so eine Kalkulationsgrundlage für das gesamte Outsourcing-Projekt sein. Ebenso können aber die erwarteten Kosten für einen geplanten Service berechnet werden und Basis für die Erweiterung des Outsourcing-Projektes durch die Auslagerung weiterer Auslagerungsbereiche (Task) sein. Diese Information ist bei der Verhandlung der SLAs von entscheidender Bedeutung.

848

Das SLA enthält auch Vereinbarungen über die eventuelle Weiterberechnung der Kosten an den Kunden, die der IT-Organisation im Zusammenhang mit den erbrachten Services entstehen. Das Financial-Management kann mögliche Optionen der Leistungsverrechnung wie Pauschalpreise oder leistungsabhängige Preise berechnen und dem Service-Level-Management vorschlagen.[438]