IT-Service Management mit ITIL (Teil I): Service Support

ITIL − Eine Oase in der Servicewüste

Der Begriff "ITIL" ist zum Trendwort in der IT-Welt geworden. Wir erläutern, was sich hinter diesen vier Buchstaben verbirgt und welchen Nutzen Sie aus ITIL bei der Optimierung von IT-Dienstleistungen und IT-Infrastrukturen ziehen können. Im vorliegenden ersten Teil stellen wir die Prozesse im Operativen Bereich der IT-Dienstleistungen, genannt Service Support, vor.

Was ist ITIL?

Fangen wir damit an, was ITIL NICHT ist: ITIL ist kein Standard, ITIL ist kein Dogma und ITIL ist mit Sicherheit kein Patentrezept. ITIL steht für "IT-Infrastructure Library" und ist eine Sammlung von sieben Büchern, die in der Praxis als Rahmenwerk für Prozesse in der IT gelten.

In den späten 80er Jahren wurden in Großbritannien die ersten ITIL-Richtlinien von der "Central Computer and Telecommunications Agency" (CCTA), dem heutigen "Office of Government Commerce" (OCG) veröffentlicht. Im Laufe der Zeit wurden von Lieferanten, Beratern und IT-Anwendern immer mehr und sogar sehr detaillierte Ratschläge und Vorschläge entwickelt und in über 40 Büchern dokumentiert.

Nach einer größeren Revision in den Jahren 2000/2001, die eine Bündelung und Aktualisierung der Materialien, das Entfernen von Redundanzen und eine bessere Navigation beinhaltete, sind diese sieben Bücher entstanden. Die heute vorliegenden "ITIL Best Practice"-Empfehlungen stellen eine in der Praxis bewährte Methodensammlung zur systematischen, praktischen und kundenorientierten Umsetzung von IT-Service Prozessen und für die Optimierung der IT-Infrastruktur dar. Sie umfassen sowohl die Unternehmenssicht als auch die Technologiesicht. Abbildung 1 zeigt die Rahmenstruktur der ITIL-Publikationen.

Abb. 1: Die Rahmenstruktur der ITIL-Publikationen. (Quelle: www.itil.org)

Service in der Praxis

Viele Unternehmen verfügen über eine Hotline, einen User Help Desk und auch über Strukturen im Bereich Problem- und Change-Management. Natürlich verfügen alle diese Unternehmen auch über irgendwelche Serviceprozesse.

Aber wie ist die Qualität? Sind die Anwender zufrieden? Sind die Kunden zufrieden? Ist es vertretbar, dass Sachbearbeiter längere Zeit nicht arbeiten können, weil ein Fehler im Netzwerk nicht behoben oder ein defekter PC nicht repariert wird? Oder dass die Projektteams ihre Arbeit nicht aufnehmen, weil noch keine Accounts eingerichtet wurden? Dass man tagelang auf eine E-Mail-Adresse wartet?

Wenn man sich die Kosten für solche Ausfallzeiten anschaut, ist das sicher nicht akzeptabel! Viele dieser Vorfälle hätten vermieden werden können, wenn man sich bei der Prozessdefinition des IT-Service Managements aus dem ITIL-Methodensammlung bedient hätte.

Die ITIL-Prozesse sind in zwei Gruppen unterteilt:

1. Operativer Bereich der Unterstützung von IT-Dienstleistungen, genannt "Service Support"
2. Taktischer Bereich der Planung und Steuerung von IT-Dienstleistungen, genannt "Service Delivery".

Abbildung 2 zeigt einen Überblick über die ITIL-Prozesse.

Abb. 2: Überblick über die gesamten ITIL-Prozesse. (Quelle: www.itil.org)

Service Support

Die Service Support Prozesse betreffen den Umgang mit dem Anwender/Kunden und die Maßnahmen, mit denen dieser Umgang so gut wie irgend möglich gestaltet wird. Sie stellen sicher, dass alle Fragen, Beschwerden, Anforderungen und Service-Nachfragen optimal bearbeitet werden.

Zu diesem Bereich gehören die Funktion "Service Desk" als Teil des Incident Managements sowie die folgenden Prozesse:

• Incident Management
• Problem Management
• Change Management
• Release Management
• Configuration Management

Service Desk

Kennen Sie das? Anruf, schöne Musik, Standardfragen, aber keine Hilfe? Die erste Aufgabe eines gut organisierten Service Desks ist laut ITIL, möglichst rasch Hilfe zu leisten und wenn das nicht möglich ist, an das Incident-Management weiterzuleiten.

Das darf aber nicht damit verwechselt werden, dass ein Service Desk ein hilfloses Call-Center sein darf, im Gegenteil.

Der Service Desk ist eine Funktion innerhalb des Incident Managements. Er ist die klar definierte Schnittstelle "Single Point of Contact" zwischen den Anwendern, Kunden und der IT-Organisation sowie zu weiteren ITService Prozessen. können.

Seine Aufgabe ist es, sämtliche Anfragen, Beschwerden und Störungen anzunehmen, zu dokumentieren und zum Teil selbst zu bearbeiten. Wenn das nicht möglich ist, leitet er jede Anfrage in die richtige Richtung weiter.

Besonders wichtig ist die Behandlung von Störungen. Eine Störung oder Incident im Sinne von ITIL ist jedes Ereignis, das eine Service- Unterbrechung oder eine Verschlechterung des Services zur Folge hat. Hier nimmt der Service Desk eine erste Einschätzung vor und versucht, den Incident selbst zu beheben (1st Level Support).

Zunächst wird in der "Known Error Database" geprüft, ob der Incident bereits bekannt ist (siehe Abschnitt "Problem Management") und ob bereits Umgehungsmöglichkeiten (Workarounds) oder Lösungen existieren, die wirksam eingesetzt werden können.

Wenn das alles nicht möglich ist, leitet der Service Desk den Incident weiter zum 2nd Level Support. Außerdem überwacht er die gemeldeten Incidents und löst gegebenenfalls den Eskalationsprozess aus.

Als "Single Point of Contact" hält er den Kontakt zu Anwendern und Kunden, um diese ständig über ihre Anfragen auf dem Laufenden zu halten. Weiterhin erstellt er wichtige Informationen für das Management, wie z. B. eine Störungsstatistik.

Incident Management

Projektmanagement Wenn eine Störung nicht durch schnelle "erste Hilfe" durch den Service Desk behoben werden kann, wird sie an das Incident Management weitergeleitet. Ziel des Incident Managements ist die schnellstmögliche Wiederherstellung eines störungsfreien Services innerhalb der mit dem Kunden/Anwender vereinbarten Zeit.

Die Grundlage dafür liefern die sogenannten Service Level Agreements (SLA), die wir im 2. Teil dieses Artikels in einer der nächsten ORDIX News im Abschnitt "Service Level Management" vorstellen werden. Im 2nd Level Support folgt eine genauere Klassifizierung des Incidents.

Man begutachtet, inwieweit der gemeldete Incident die Arbeit der Anwender/Kunden beeinträchtigt. Daraufhin werden weitere Hilfsmaßnahmen eingeleitet, z. B. neue Workarounds geschaffen.

Wenn auf diese Weise nicht geholfen werden kann, wird gegebenenfalls auch Hilfe vom Hersteller oder Lieferanten in Anspruch genommen (3rd Level Support). Im Erfolgsfall wird der Incident dann dem Service Desk als behoben gemeldet, ansonsten wird dies ein Fall für das Problem Management.

Problem Management

Leider geht das nicht immer so reibungslos. Der Incident wird im wahrsten Sinne des Wortes zum Problem. Ein Problem im Sinne von ITIL ist die unbekannte Ursache einer oder mehrerer Incidents. Meist wird ein Incident zum Problem erklärt, wenn er

• häufig auftritt,
• die Arbeit der Anwender/Kunden stark beeinträchtigt,
• die vereinbarten SLAs gefährdet,
• und/oder das Incident Management keinen zufriedenstellenden Workaround findet.

Ziel des Problem Managements ist es, die Ursache eines Problems zu finden und zu vermeiden, dass dieses wieder auftritt. Das Problem Management arbeitet eng mit dem Incident Management zusammen.

Die Probleme sowie praktikable Workarounds werden in der "Known Error Database" dokumentiert. Das Problem Management forscht nach der Fehlerursache und prüft, ob es bereits Workarounds gibt.

Manchmal werden bestehende Workarounds verbessert oder für das spezifische Problem angepasst. Wenn das nicht möglich ist, wird ein neuer Lösungsansatz entwickelt. Das Problem ist nun zum bekannten Fehler "Known Error" geworden.

Je nachdem wie sehr die Behebung eines Problems die Arbeit der Anwender/Kunden beeinträchtigt, erstellt das Problem Management einen Änderungsantrag "Request for Change" an das Change Management (siehe Abschnitt "Change Management").

Sollte dem Antrag stattgegeben werden und die gewünschte Änderung durchgeführt werden, führt das Problem Management anschließend ein Review durch (PIR: Post Implementation Review). Wird dabei festgestellt, dass der Service wieder hergestellt ist, wird auch das Problem abgeschlossen und somit auch der anfängliche Incident. Weiterhin trägt das Problem Management durch proaktive Untersuchungen und Analysen vorhandener Probleme maßgeblich zur Verringerung des Aufkommens von Incidents bei.

Configuration Management

Ohne detaillierte Informationen über Hardware, Software usw. wären die zuvor genannten Leistungen gar nicht möglich. Aus diesem Grunde ist das Ziel des Configuration Managements die Dokumentation aller servicerelevanten Elemente (CI = Configuration Item) und deren Beziehung zueinander.

Ein CI ist eine Komponente der IT-Infrastruktur, die zur Erbringung der Services erforderlich ist, wie z. B. Server, Drucker und SLAs. Die Erfassung der Beziehungen der CIs, z. B. Kunde ABC nutzt den Drucker XYZ über SLA 4711, ist der wesentliche Unterschied zu einem normalen Asset Management.

Das Configuration Manager sorgt dafür, dass alle Informationen zu den CIs sorgfältig aufgenommen und gepflegt werden. Es stellt eine wichtige Informationsquelle für die anderen Service Prozesse dar, insbesondere für Problem, Release und Change Management.

Das Configuration Managements ist die Configuration Management Database (CMDB), in der alle relevanten Informationen, z. B. Typ, Kategorie und Beziehungen gespeichert werden. Beim Aufsetzen der CMDB sollte der Detaillierungsgrad genau festgelegt werden.

Eine zu tiefe Detaillierung führt zu Unübersichtlichkeit, eine zu schwache ist zu oberflächlich und liefert nicht die gewünschten Informationen. So kann in Zusammenarbeit mit dem Change- und Release Management "Wildwuchs" im Hardwarebereich sowie die Nutzung unautorisierter Software vermieden werden. Weiterhin liefert das Configuration Management wertvolle Informationen und Entscheidungshilfen für das Management.

Change Management

Ziel des Change Managements ist der Einsatz von standardisierten Methoden und Verfahren für eine effiziente und prompte Handhabung aller Änderungen. ITIL versteht unter einem Change das Hinzufügen, ändern oder Beseitigen eines Configuration Items.

Änderungen können aus unterschiedlichen Gründen erforderlich werden, sei es durch Gesetzesänderungen, durch Anforderungen aus dem Problem Management, durch die Geschäftsleitung usw. Ein Request for Change (RfC) im Sinne von ITIL ist ein Antrag auf die Durchführung einer Änderung an einem CI.

Das Change Management schätzt die Auswirkungen ab, die der Change mit sich bringen könnte. Ebenso werden die Kosten, der Nutzen, die Risiken, sowie die Vor- und Nachteile ermittelt. Das Change Management unterstützt auch bei der Formulierung der Begründung für die Änderung. Nach Annahme und Dokumentation des RfC wird die Priorität festgelegt. Die RfCs werden in der Regel kategorisiert nach

• gering (minor): Die Auswirkungen des Change sind eher gering und man braucht wenig Ressourcen zur Umsetzung.
• bedeutend (significant): Die Auswirkungen sind deutlich größer und man braucht mehr Ressourcen zur Umsetzung.
• erheblich (major): Die Auswirkungen des Change sind weitreichend und man braucht entsprechend viele Ressourcen zur Umsetzung.

Nach der Klassifizierung entscheidet der Change Manager bei Minor Changes über die weitere Vorgehensweise und berichtet an das Change Advisory Board (CAB). Inwieweit er das darf, wird bei der Implementierung des Change Managements definiert.

Significant Changes werden an einen Entscheidungsausschuss, das CAB, weiter gegeben. Major Changes werden außerdem noch der Geschäftsleitung zur Genehmigung vorgelegt. Nach dem Genehmigungsprozess verwaltet und koordiniert das Change Management die Durchführung der Änderung und der Implementierung.

Besonders dringende Changes ("Hotfixes") können innerhalb eines gesonderten Prozesses durch das CAB/EC (Emergency Comitee des Change Advisory Boards) schnell genehmigt werden. Weiterhin stellt das Change Management relevante Informationen und Berichte über die Änderung zur Verfügung.

Nach Erfolgsmeldung durch das Problem Management wird der RfC geschlossen. Das Change Management arbeitet sehr eng mit dem Problem und Release Management zusammen.

Release Management

Wenn Hardware, Software oder auch geänderte Hard- oder Software eingeführt werden sollen, kommt das Release Management ins Spiel. In Zusammenarbeit mit dem Change und Configuration Management hat es den Überblick über alle Änderungen an den IT-Services und CIs. So kann sicher gestellt werden, dass alle Aspekte einer Änderung − ob technisch oder nicht-technisch − berücksichtigt werden.

Ein Release im Sinne von ITIL ist die Sammlung von neuen und/oder geänderten CIs, die getestet und zusammen in die Produktivumgebung eingeführt werden. Die wesentlichen Aufgaben sind

• Planung, Überwachung und Dokumentation dieser Einführungen
• Sicherstellen, dass neue Software intensiv und ausreichend getestet wird
• Abstimmung mit dem Change Management über die Inhalte der neuen Releases
• Sicherstellen der Dokumentation aller Änderungen in der CMDB

Eine weitere wichtige Aufgabe ist auch die Verwaltung der Definite Software Library (DSL), in der alle autorisierten Versionen der eingesetzten Software, egal ob Eigenentwicklungen oder zugekaufte Software, gespeichert werden.

Die DSL kann auch als Basis für eine Softwareverteilung im Unternehmen genutzt werden. Durch die DSL entsteht Transparenz über den Softwarebestand. Die Nutzung unautorisierter Software kann auf diese Weise vermieden werden.

Auch die Pflege des Definitive Hardware Store gehört zu den Aufgaben des Release Managements. Dieser beinhaltet die definierte und autorisierte Ersatz-Hardware, die ebenso wie die Produktiv-Hardware regelmäßig gewartet werden soll.

Abb. 3: ORDIX Leistungen im ITIL-Umfeld.

ORDIX kann helfen!

Natürlich ist es mit der Zurverfügungstellung von ITIL-Prozessen und -Methoden alleine nicht getan. Die Einführung neuer Strukturen und Prozesse bringt Veränderungen mit sich. Und Veränderungen erzeugen immer auch Unsicherheit oder gar Angst bis hin zu bewusstem oder Unbewusstem Widerstand. Daher muss im Vorfeld Akzeptanz und Klarheit für die neuen Strukturen und Prozesse geschaffen werden. Wir haben die Erfahrung bereits in vielen Projekten gemacht, dass es sich lohnt, fü die Akzeptanz Zeit und Aufwand zu investieren.

In Teil II des Artikels stellen wir die taktischen Prozesse der Service Delivery vor.

Christiane Westerhoff und Rainer Restat (info@ordix.de).