ITIL einführen und umsetzen

Transkript

1 ITIL einführen und umsetzen Wolfgang Elsässer Leitfaden für effizientes IT-Management durch Prozessorientierung ISBN Vorwort Weitere Informationen oder Bestellungen unter sowie im Buchhandel

2 Vorwort Das IT-Management steht heutzutage in den meisten Unternehmen vor dem Problem, die Effizienz der IT-Abteilung steigern zu müssen und dies bei gleichbleibendem oder gar sinkendem Budget. Der Manager der Informationstechnologie, häufig auch CIO (Chief Executive Officer) genannt, muss sich Gedanken darüber machen, auf welche Art und Weise die Leistungsfähigkeit der Unternehmens-IT verbessert werden kann. Kaum ein Unternehmen kann noch auf die Dienstleistungen der IT verzichten. Die Abhängigkeit von den Ergebnissen wird ständig größer und diese wiederum beeinflussen den Geschäftserfolg. Es gibt nun eine Reihe von Möglichkeiten, diese Anforderungen in der Praxis umzusetzen. In diesem Zusammenhang wird immer häufiger ITIL (Information Technology Infrastructure Library) 1 als wirksames Hilfsmittel für die Optimierung der Managementmethoden genannt. Zunächst kann festgestellt werden, dass bei ITIL der Servicegedanke und die Geschäftsprozesse im Fokus stehen. Das IT-Management besteht letztlich aus mehreren Subsystemen, welche von ITIL unterstützt werden. Somit ist es für das Unternehmen von Vorteil, sich mit diesem Thema näher auseinander zu setzen. Das Buch hat sich zur Aufgabe gestellt, alle interessierten und betroffenen Mitarbeiter im Unternehmen mit der Thematik vertraut zu machen. Es ist kein Lehrbuch über Managementtechniken, sondern soll die Möglichkeiten der ITIL vor allem für die praktische Umsetzung aufzeigen. Beantwortet werden typische Fragen wie die folgenden: Was ist ITIL? Woraus besteht es? Wie werden die Subsysteme realisiert? Auf welche Weise werden sie integriert? Was muss bei der Realisierung beachtet werden? Welche Personen oder Gruppen sind betroffen? Wie wird ein ITIL-Projekt durchgeführt? Welche Softwareunterstützung kann erwartet werden? Wo kann zusätzliche Hilfestellung gefunden werden? Bei der Darstellung der einzelnen Managementaufgaben bzw. der ITIL-Disziplinen sind in den verschiedenen Kapiteln durchaus beabsichtigte Redundanzen vorhanden. Diese ergeben sich aus den unterschiedlichen Sichtweisen der Themengruppen. 1 ITIL ist eine geschützte Marke der britischen Regierung. (ITIL is a Registered Trade Mark, and a Community Trade Mark of the Government Commerce and is Registered in the U.S. Patent and Trademark Office)

3 XIV Vorwort Das Werk soll als Leitfaden dienen, um die komplexe und nicht ganz triviale Thematik vor allem unter Praxisaspekten leichter zu verstehen. In erster Linie wendet es sich an die Verantwortlichen, die sich mit ITIL auseinandersetzen müssen. Doch auch die Mitarbeiter sollten für ihre Tätigkeiten hieraus Nutzen ziehen können. Dass dies gelingen möge, wünschen Autor und Verlag. Zum Schluss möchte ich noch meinen besonderen Dank an folgende Personen aussprechen: Frau Margarete Metzger für die permanente Unterstützung bei der Gestaltung, Frau Irene Weilhart für die tatkräftige Hilfe auf der technischen Ebene und Frau Sonja Orlova für die Erstellung der Grafiken. Wolfgang Elsässer

4 ITIL einführen und umsetzen Wolfgang Elsässer Leitfaden für effizientes IT-Management durch Prozessorientierung ISBN Leseprobe Weitere Informationen oder Bestellungen unter sowie im Buchhandel

5 4 Die ITIL-Disziplinen des Service-Support

6 48 4 Die ITIL-Disziplinen des Service-Support 4 Die ITIL-Disziplinen des Service-Support Dieses Kapitel beschreibt die fünf Bereiche oder besser gesagt ITIL-Prozesse des ITIL- Modells Service-Support: Incident-Management mit Service-Desk Problem-Management Change-Management Configuration-Management Release-Management Jeder dieser Prozesse ist in sich abgeschlossen und bildet eine logische Einheit. Sie haben jedoch untereinander Schnittstellen und Relationen sowie Verbindungen zu den weiteren ITIL-Prozessgruppen und IT-Submanagement-Disziplinen. Diese Prozesse definieren die alltäglichen Funktionalitäten und Aufgaben des IT-Betriebes. Die Beschreibungen in diesem und im nächsten Kapitel sind auf der Basis von Veröffentlichungen des itsmf und der ITIL-Gremien zusammengestellt und um Praxishinweise ergänzt. 4.1 Incident-Management mit Service-Desk Allgemeines Der Service-Desk Bei ITIL nimmt der Service-Desk eine wichtige und zentrale Stellung ein. In den meisten Unternehmen findet sich die früher als Benutzerservice oder Helpdesk benannte Organisation als Kommunikationsstelle zwischen der Informationstechnologie und den Benutzern oder Kunden. Der Service-Desk selbst ist also kein ITIL-Prozess, sondern die Schaltstelle für die meisten ITIL-Prozesse. In erster Linie ist der Service-Desk als Ansprechpartner für verschiedene Belange, Probleme und Anfragen seitens der Anwender/Nutzer zu sehen. Die Anfragen bzw. die Meldungen von Störungen aller Art bei der IT-orientierten täglichen Arbeit müssen entgegengenommen, klassifiziert und dokumentiert sowie an die entsprechenden Stellen und Experten weitergeleitet werden. Auch die IT-Mitarbeiter nutzen die Möglichkeiten und das Wissen der Helpdesk-Gruppe. Zumeist werden verschiedene Bearbeitungsstufen oder auch Eskalationsebenen unterschieden: 1. First Level für sofortige Lösungen durch das Call Center; 2. Second Level für komplexere und schwierigere Lösungen durch Teams oder Fachkräfte; 3. Third Level für das Einschalten von Experten bei spezifischen Problemen; 4. gegebenenfalls der Fourth Level für die Vergabe von Lösungsaufträgen an externe Stellen (Wartung, Garantiefälle etc.).

7 4.1 Incident-Management mit Service-Desk 49 Der Service-Desk kann organisatorisch in drei Formen realisiert werden. Unter anderem hängt dies von der Aufgabenstellung und der Firmenorganisation ab. Zentral: eine SPOF-Einrichtung (Single Point of Failure) als einziger Ansprechpartner mit eventuell angeschlossenem Call-Center. Dezentral bzw. lokal: bei verschiedenen Standorten oder Filialunternehmen gibt es für jede Lokation einen eigenen Service-Desk. Virtuell: als logische Lösung, wobei die zentralen und verteilten Help-Desks über verschiedene Kommunikationswege mit den Anwendern/Kunden kontaktieren. Es sollte stets nur ein einziger Ansprechpartner für den Erstkontakt der Anwender mit dem Service-Desk aktiv sein. Hinweis: Die Begriffe Kunden und Anwender werden bei modernen Organisationen zunehmend als eine Einheit betrachtet. Kunden sind externe Partnermitarbeiter und Anwender sind die internen Mitarbeiter. Beide arbeiten am System und haben somit dieselben Problemstellungen bezüglich Support. Das Incident-Management und der Service-Desk Beim Thema Incident-Management müssen wir erst einmal einige wichtige ITIL-Termini erläutern. Unter dem Begriff Incident versteht man bei ITIL sowohl Störungen als auch Service-Requests. Störungen sind Vorkommnisse, welche den laufenden Betrieb der IT und der damit verbundenen Services beeinträchtigen oder verhindern. Als Service-Request bezeichnet man Benutzeranfragen, welche nicht als Störungen betrachtet werden. Ein Workaround liegt vor, wenn man bereits eine kurzfristige Lösungsmethode für eine bestimmte Störung vorliegen hat. Ein Problem definiert eine noch nicht bekannte Ursache für eine Unterbrechung bzw. Störung. Der Known-Error ist dann gegeben, wenn die Ursache des Problems erkannt und die passende Lösung hierzu erarbeitet wurde. Diese Abgrenzungen führen zu unterschiedlichen Aktionen sowohl seitens des Service-Desk als auch des Problemmanagements. Incident-Management wird üblicherweise durch den Benutzerservice, den Helpdesk oder fallweise das Call-Center durchgeführt. Das Incident- Management sorgt für eine schnelle Beseitigung einer Störung, um die IT-Services wieder zu aktivieren Beispiele Störung: Eine Workstation fällt komplett aus oder der Zugriff auf eine Datenbank ist nicht möglich, in beiden Fällen werden Aktionen des Service-Desk notwendig. Service-Request: Ein neuer Mitarbeiter benötigt eine Workstation und die dazugehörigen Zugangs- und Zugriffsberechtigungen. Diese Meldung an den Service-Desk wird allgemein vom Netzwerkadministrator initiiert und führt dort zu weiteren Aktionen. Workaround: Ein Anwender kann auf seinem lokalen Drucker nichts mehr drucken. Als Sofortlösung kann ein Umrouten zu dem Drucker eines Kollegen der Abteilung durchgeführt werden (Ad hoc-lösung).

8 50 4 Die ITIL-Disziplinen des Service-Support Problem: Der genannte Lokaldrucker wird geprüft und die Störungsursache ermittelt, eine Reparatur wird fällig oder ein Austausch notwendig. Hierbei treten dann weitere Management-Subsysteme in Aktion (Langfristige Lösung). Known-Error: Ein Softwarefehler im Netzbetriebssystem taucht auf, und es müssen Patches durchgeführt werden. Dies kann viele Mitarbeiter betreffen und das Problem wird mit hoher Priorität versehen Aufgaben und Funktionen Aus den obigen Ausführungen ist klar ersichtlich, dass das Incident-Management und der Service-Desk unmittelbar zusammengehören. Die Aufgaben beider Einrichtungen sind recht vielfältig, hier in Kurzform die wichtigsten davon: Ansprechpartner für die Kunden/Anwender Entgegennahme von Anfragen und Meldungen Bearbeitung der Anfragen und Meldungen und Speicherung in eine Datenbank Klassifizierung und Priorisierung der Störungsmeldung Schnelle Hilfe und Wiederherstellung der Dienste einleiten Kommunikation mit weiteren ITIL-Prozessen (siehe 4.1.8) Geschäftsprozessunterstützung während der Dauer einer Störung Verfolgung und Beendigung mit Lösungsmeldung Ein Trouble-Ticket-System (Software und Datenbank) hilft hier bei späteren, gleichen oder ähnlich gelagerten Fällen zur schnelleren Lösungsfindung Ein Trouble-Ticket-System ist eine Kombination aus einer Problemdatenbank und der damit zusammenhängenden Verwaltungssoftware. Incidents und Probleme werden sowohl im Incident- als auch Problem-Management erfasst und bearbeitet Ziele Die schnelle und effiziente Bearbeitung und die Störungsbeseitigung sind die wichtigsten Ziele des Incident-Managements und des Service-Desks. Zudem müssen die Geschäftsprozesse und die vereinbarten Serviceleistungen möglichst schnell und sicher wiederaufgenommen werden können. Nicht zu vergessen sind auch die Kunden- und Mitarbeiterzufriedenheit und die damit zusammenhängenden Beziehungen Praxishinweise und Auswirkungen Der Service-Desk hat als Mittler zwischen IT und Anwender eine ganz zentrale Funktion. Durch effizientes Bearbeiten und Lösen von Incidents werden Geschäftsprozesse aufrechterhalten und die Kundenzufriedenheit erhöht. Außerdem muss bei allen Vorfällen beachtet werden, dass keine wichtigen Termine überschritten werden, da sonst auch juristische Konsequenzen auftauchen können. In den meisten Fällen muss man zumindest höhere Kosten in Kauf nehmen. Hierbei spielt unter anderem der angesprochene Dringlichkeits-

9 4.1 Incident-Management mit Service-Desk 51 grad der Lösungsbearbeitung eine wichtige Rolle. Dieser sollte direkt mit dem Anwender oder Kunden abgestimmt werden, da dort die eventuellen Folgen besser bekannt sind und eingeschätzt werden können. Priorisierungen dienen dem Second-Level-Support zur Beachtung der Abfolge bei der Störungsbearbeitung. Keinesfalls sollten mehrere Mitarbeiter zugleich an ein und demselben Problem arbeiten. Ausnahmen sind Probleme, die durch ein Team gemeinsam gelöst werden müssen. Im Übrigen gibt es zwei Eskalationsformen: die funktionale Eskalation bei der Inanspruchnahme von Experten, welche dem Incident-Management zugeordnet sind, und die hierarchische Eskalation, wenn weitere Management- Ebenen einbezogen werden müssen. Letzteres ist zum Beispiel immer dann der Fall, wenn die Störung zu Changes führt Der Prozess Der Incident-Management-Prozess beginnt mit der Entgegennahme der Meldungen und wird durch die Wiederherstellung der Dienste abgeschlossen. Im Einzelnen müssen die folgenden Schritte durchlaufen werden: Störung entgegennehmen und registrieren Klassifizierung nach Kategorien der IT (Netze, Hardware, Software etc.) Prüfung auf Auswirkungen, Dringlichkeitsgrad und Definition der Priorität Beachtung der SLA-Bedingungen Feststellung von möglichen Gefahren oder Konsequenzen Erste Unterstützung des Anrufers Falls ein Service-Request vorliegt, muss das Verfahren zur Service-Anforderung initiiert werden Prüfen, ob die Störung bereits bekannt ist Prüfen, ob ein Workaround möglich ist In beiden Fällen wird die Störung umgehend beseitigt Bei nicht bekannter Ursache wird analysiert und diagnostiziert Bei Behebung erfolgt eine Mitteilung an die betroffenen Personenkreise Abschluss und Speicherung des Lösungsweges in der Datenbank Zur Einführung Natürlich muss im Incident-Management-Prozess auch ein verantwortlicher Manager eingesetzt werden. Dieser ist für die Überwachung der Prozesse und der Ergebnisse zuständig. Die Leistungsfähigkeit der gesamten IT muss sich erhöhen, die Kunden und Anwender werden optimal betreut und Mitarbeiter können effektiver eingesetzt werden. Existiert das Incident-Management nicht, so bedeutet dies Unterbrechungen von IT-Diensten, und es können größere Schäden nachfolgen. Ein wichtiger Hinweis in diesem Zusammenhang sollte noch gegeben werden: Man muss zwar dem Anwender die Möglichkeit bieten, in bestimmten Fällen die Störung selbst zu beseitigen. Doch dabei besteht immer die Gefahr, dass manche Aktionen nicht sachgemäß

10 52 4 Die ITIL-Disziplinen des Service-Support durchgeführt werden. In so genannten FAQ-Listen werden häufig gestellte Fragen und die dazu gehörigen Antworten abgespeichert. Dort kann man die Fälle eintragen, in denen ein Endanwender die Lösung einer Störung selbst veranlassen kann. Auch anstehende Wartungsarbeiten können zu Störungen führen. Deshalb ist ein optimales Meldesystem in Richtung Anwender/Kunden sinnvoll. Dasselbe gilt für geplante Rollouts wie zum Beispiel eine unternehmensweite Umstellung des Netzwerkbetriebssystems oder die Installation und Einführung von SAP R/3. Die regelmäßige Information der Anwender/ Kunden ist eigentlich eine Aufgabe des Service-Desk, wobei oft mehrere der ITIL-Prozesstypen beteiligt sind Schnittstellen und Hinweise Das Incident-Management unterhält Interfaces zu weiteren ITIL-Hauptprozessen und davon abgeleiteten Verfahren, sofern diese existieren und implementiert sind. Insbesondere sind dies: Problem-Management: Können Incidents nicht unmittelbar beseitigt werden, so werden sie dem Problem-Management übergeben. Die Meldung der Problemlösung erfolgt anschließend in der Gegenrichtung. Change-Management: Dieses tritt in Aktion, wenn Änderungen notwendig werden. Dies kann ein neues Hardwaregerät oder die Installation eines Software-Updates sein. Ausgelöst wird dieser Prozess durch einen RFC (Request For Change), der ein Genehmigungsverfahren nach sich zieht. Configuration-Management: Hier werden die Änderungsinformationen in der CMDB (Configuration-Management Data Base) abgelegt. Alle IT-Komponenten, die bei ITIL als CI (Configuration Item) bezeichnet werden, müssen dort verzeichnet sein. Release-Management: Bei globalen Änderungen muss auch dieser Prozess angestoßen werden, um die Releases zu aktualisieren. Dies kann sich auf das Patch-Management auswirken, sofern Software- und Security-Updates notwendig sind. Service-Level-Management: Dieses muss informiert werden, wenn sich aufgrund der Veränderung Auswirkungen auf die SLAs ergeben. Service-Anforderungsverfahren bei Existenz eines Service-Requests. Das Verfahren wird vordefiniert und läuft nach einem festen Schema ab. Die wichtigsten Funktionen der einzelnen ITIL-Management-Untergruppen finden sich bei den jeweiligen Beschreibungen (dieses Kapitel und Kapitel 5). Ebenso sei auf die Grafik im Unterkapitel 9 beim Fallbeispiel 1 verwiesen. Dort findet man weitere Informationen über Zusammenhänge, Verbindungen und Relationen der einzelnen Subsysteme.

11 4.2 Problem-Management Problem-Management Allgemeines Man kann das Problem-Management als zweite Ebene des Incident-Management bezeichnen. Hier besteht die vorrangige Aufgabe darin, die Wiederaufnahme der Services schnellstmöglich zu sichern. Die Gründe für die Störungen werden hier nicht oder nur selten festgestellt. In dem Moment, wo für einen Fall keine Ursache festgestellt werden kann, wird ein Incident zum Problem. Ein Problem kann durchaus auf mehrere Incidents zurückführbar sein. Das Aufspüren des Grundes oder der Gründe ist zumeist aufwendig. Nur selten wird man sofort einen direkten Zusammenhang zwischen Ursache und Auswirkung feststellen. Ausnahmen sind Fälle, die in gleicher oder ähnlicher Form schon einmal aufgetaucht sind. Die Schwierigkeit bei Störungen und Unterbrechungen liegt jedenfalls grundsätzlich darin, dass sie wiederholt auftreten können. Wenn das System in einer bestimmten Situation immer mit derselben Meldung reagiert oder die Anrufe der Anwender gleich lauten, kann man klar darauf schließen, dass es noch nicht beseitigte Problemquellen geben muss. Bei früheren Helpdesk-Organisationen ist dies die Überleitung vom First-Level-Support zum Second- oder Third-Level-Support zu anderen Personenkreisen bzw. IT-Experten. Auch wenn ITIL eingeführt ist, wird dies noch der Fall sein, doch wird hier das Problem- Management aktiviert. Dieses muss die Störungen und Fehler beseitigen, doch im Vordergrund steht die Entdeckung der Ursache(n). Manchmal hat man den Fall, dass ein bestimmter Abbruch durch eine Kette von Fehlerquellen verursacht ist. Hier greifen nun andere Prozessverläufe als beim Incident-Management. Problem-Management-Mitarbeiter müssen zum einen über eine hohe Qualifikation verfügen und zum Zweiten andere Hilfsmittel zur Fehlersuche verwenden. Diese Hilfen können aus einer Reihe von Komponenten, Systemen, Datensammlungen und Programmen bestehen. Die notwendigen Informationen werden also von und zu anderen ITIL- oder Management-Prozessen geliefert. Vielfach werden auch verschiedene im Unternehmen vorhandene Anwendungssysteme und deren Datenbanken herangezogen. Die Möglichkeiten sind natürlich sehr unterschiedlich und hängen vom jeweiligen Fall ab. Die Informationen für Probleme als Prozess-Input können den Inventurdatenbanken bzw. den weiteren Prozessen entnommen werden. Die Dokumentationen der jeweiligen Hersteller und die spezifischen Leistungsdaten sind oft wertvolle Quellen Beispiele In der IT-Praxis gibt es sicherlich viele bekannte Fälle und Beispiele. Wohl jeder Mitarbeiter, der in IT-Umgebungen arbeitet, weiß darüber zu berichten. Einige wenige können wir hier aufführen. Die Beispiele werden etwas ausführlicher behandelt, damit man erkennt, dass unterschiedliche Ursachen vorliegen und somit auch verschiedene Personengruppen

12 54 4 Die ITIL-Disziplinen des Service-Support möglicherweise zu involvieren sind. Manchmal müssen mehrere Experten zeitgleich beteiligt werden. Datenbankfehler: Anwender aus unterschiedlichen Fachbereichen melden voneinander unabhängig, dass die Daten in einer Datenbank fehlerhaft sind. Es muss nun festgestellt werden, welche Datenbank falsche Informationen liefert. Gründe hierfür können im DB-Softwaremanagementsystem des Herstellers liegen, oder die Datenbank wurde inkonsistent aufgebaut. Man wird Analysten und Programmierer mit der Problemsuche beauftragen müssen. Es können unter Umständen viele Anwender/Kunden betroffen sein, was wiederum von den verwendeten Anwendungssystemen und Programmen abhängt. Anwendungsprogrammfehler: Bestimmte Anwendungen stellen dieselbe Fehlermeldung des Systems mehrfach fest. Hierbei kann ein Analyst das fehlerhafte Programm ausfindig machen. Handelt es sich um einen Data Check (z.b. Sonderzeichen in Rechenfeldern), muss der Programmierer die Stelle im Programm finden, die zum Absturz führt. Bei Programmen Marke Eigenbau ist dies selten ein Problem, da der Quellcode vorhanden ist. Bei Fremdsoftware muss hingegen oft die Hotline des Herstellers eingreifen. Hardware-Fehler: Wenn es sich um eine defekte Server-Festplatte handelt, liegt ein Notfall höchster Priorität vor. Zum einen sind hierbei oft sehr viele verschiedene Anwendungen betroffen und zum Zweiten muss die Festplatte ausgetauscht werden. Hier greifen weitere im Unternehmen vorhandene Abläufe: Backup und Recovery. Zudem wird der Systemadministrator aktiv und man kann nur hoffen, dass die Datensicherungen vollständig und regelmäßig gemacht wurden. Oft sind auch eventuelle Anschaffungen notwendig, sofern man keine Reserverechner vorrätig hat. Netzwerkfehler: Wenn gemeldet wird, dass ein bestimmtes Subnetz nicht im Zugriff steht, wird der Netzwerkverwalter als Erstes eingreifen. Unter Umständen müssen Messgeräte oder Netzanalysatoren eingesetzt werden, um einen Verkabelungs- oder Routerfehler aufzuspüren. Hier sind die Gründe oft nicht einfach oder schnell zu finden. Es kann auch ein Treiberproblem sein. Viele weitere Gründe können bei Netzproblemen die Ursachen sein. Sicherheitsfehler: Anwender können sich nicht mehr anmelden. Der Grund kann in einer mangelhaften Konfiguration liegen, oder man hat Probleme mit dem Active Directory. Manchmal wird auch schlicht und einfach das Passwort vergessen, dann kann der Administrator oder die Hotline des Service-Desks weiterhelfen. Die Sicherheitsverletzungen können natürlich ebenfalls verschiedene Ursachen haben. Betriebssystemabstürze: Diese sind besonders gefürchtet, da hierbei nicht nur der hausinterne Experte eingreifen muss. Oft ist Hilfe vom Hersteller notwendig (Thirdoder Fourth-Level-Support). Hierbei hilft das Incident-Management, um dem Anwender das möglichst schnelle Weiterarbeiten zu ermöglichen. Die Ursachen für den Absturz wird das Problem-Management suchen und dafür eine mehr oder weniger größere Zeitspanne einkalkulieren müssen.

13 4.2 Problem-Management 55 Virenprobleme: Hierbei müssen erst mal die Schäden aufgespürt werden, denn man kann kaum vorhersagen, wie die Schädlinge sich ausgewirkt haben. Je nach Fall können die Wiederherstellungsarbeiten Tage dauern. In solchen Fällen können durchaus alle Mitarbeiter im Unternehmen betroffen sein. Als Folgeaktionen sind in der Regel Software-Updates (Patches) von der Hersteller-Problemdatenbank abzurufen. Falls im Angebot vom Hersteller ein neues Service-Pack zu finden ist, muss dieses in den meisten Fällen auch heruntergeladen und installiert werden. Alle diese Fälle müssen vom Problem-Management übernommen und abgehandelt werden. Die Liste ließe sich beliebig fortsetzen. Vom einfach zu findenden Fehler bis zu extrem komplexen Aktivitäten gibt es hier in der Praxis jede Abstufung. Die Aufrechterhaltung der SLA-Grundsätze ist dabei oft genug nicht mehr möglich. Bei der Fehlereinkreisung sind unter Umständen auch alle vier Eskalationsstufen beteiligt, was das Ganze natürlich nicht einfacher macht. Fehler und Probleme sind generell auch Störungen. Deshalb werden die Prozessdisziplinen Incident- und Problem-Management in der Realität sehr eng zusammenarbeiten müssen und eine permanente Kommunikation pflegen Aufgaben und Funktionen Man unterscheidet bei ITIL drei Problem-Management-Subprozesse: Problem-Control, also die Problembearbeitung; Error-Control, also die Fehlerbearbeitung, und das proaktive Problem-Management, womit das Vermeiden von Problemen verschiedener Art gemeint ist. Problem-Control Die Problembearbeitung als solche stellt quasi die erste Phase jeder Aktion des Problem- Managements dar. Hier werden zunächst die Incidents ausgeschieden, was fast immer im Service-Desk auf der Stufe 1 stattfindet. Störungen aus dem Incident-Management werden zwar weiterhin von dort überwacht, doch werden die Probleme selbst zum Problem- Control geleitet und erst einmal in das Trouble-Ticket-System und die zugehörige Datenbank eingestellt. Die genaue Beschreibung des Problems und dessen Klassifizierung sowie die Feststellung der Bearbeitungspriorität werden abgespeichert. Sodann erfolgt die detaillierte Untersuchung des Problems und dessen Auswirkungen auf die Anwendungen und ganz besonders auf die Services. Soweit zu diesem Zeitpunkt möglich, wird Ursachenforschung betrieben. Es gibt Probleme, bei denen gerade die Quellen der Störungen nicht einfach oder schnell aufzufinden sind. Oft stellt man mehrere Ursachen zugleich fest. Error-Control Bekannte Fehler sind solche, die bereits früher schon einmal aufgetaucht sind, ITIL nennt diese Known-Error. Da hier die Ursachen bereits geklärt sind, sind auch die notwendigen Lösungsaktivitäten bekannt. Diese Daten und Informationen finden sich in der Trouble- Ticket-Datenbasis wieder und können dort abgerufen werden. Die Lösung des neu ermit-

14 56 4 Die ITIL-Disziplinen des Service-Support telten Problems wird initiiert und an die entsprechende Stelle bzw. das Management- Subsystem delegiert. Zugleich können die so genannten RfCs (Request for Change) an das Change-Management weitergeleitet werden, falls das Problem zu Änderungen an Hardoder Software führen muss. Bei Known-Errors sollte die verursachende Komponente im Problem-Management gefunden werden. Solche IT-Komponenten werden als CI (Configuration Item) in der CMDB abgespeichert und können von dort fallweise abgerufen werden. Meistens führen bekannte Fehler zu Änderungsaktivitäten, diese werden als Vorschläge weitergeleitet. Proaktives Problem-Management Die ersten beiden Schritte findet man im Prinzip auch bereits in etablierten Helpdesks wieder. Der Unterschied zu ITIL liegt darin, dass man hier mehrere Subprozesse bzw. Managementsysteme einschaltet. Eine wichtige Aufgabe des Problem-Managements besteht nun darin, Vorkehrungen zu treffen, um ein Problem im Idealfalle gar nicht erst entstehen zu lassen. Hierzu werden die früheren Lösungen analysiert, und aus Trends kann das Entstehen von Problemen schon im Vorfeld erkannt werden. Ein typisches Beispiel hierfür ist das Feststellen von sich abzeichnenden Transfer-Engpässen durch Messungen in Netzwerksegmenten. Ein hohes Datenaufkommen kann darauf hindeuten, dass ein Zusammenbruch eines Teilnetzes bevorsteht. Langzeitmonitoring mithilfe so genannter Agents in den aktiven Netzkomponenten ist eine Aufgabe des Administrators Ziele Die wichtigsten Zielsetzungen ergeben sich eigentlich aus den Aufgabenstellungen: optimale und schnelle Ursachenforschung bei allen Störungen, Unterbrechungen oder sonstigen Problemen die Elimination der Ursachen die Aufrechterhaltung der IT-Dienstleistungen die Vermeidung von längerfristigen IT-Systemunterbrechungen die Reduzierung der Auswirkungen und Schadensbegrenzung das Vermeiden von Problemen durch vorausschauendes Handeln das Einleiten von notwendigen Changes in der IT-Infrastruktur Praxishinweise und Auswirkungen In der Praxis ist es sehr vorteilhaft, wenn die Kommunikation zwischen allen Beteiligten gut funktioniert. Hierbei können zumeist bereits vorhandene IT-Applikationen und TK- Einrichtungen gute Dienste leisten. Zudem ist es oft notwendig, alle Bereichsleiter und fallweise auch das Top-Management rechtzeitig über bestimmte Situationen und Vorhaben zu informieren. Das gilt in all jenen Fällen, wo von notwendigen Veränderungen das gesamte Unternehmen betroffen ist.

15 4.2 Problem-Management 57 Insgesamt sollten die folgenden Ergebnisse erzielt werden: Die Anwenderproduktivität kann gesteigert werden. Der Service-Desk sollte entlastet werden. Die Services der IT müssen schnell und sicher aufrechterhalten werden. Die Verfügbarkeit der Systeme soll erhöht werden. Die Qualität der Ergebnisse soll verbessert werden. Die Einhaltung der SLAs bei allen Services muss gewährleistet sein. Kunden- und Anwenderzufriedenheit sollten verbessert werden können. Das Image der IT-Welt kann sich verbessern. Die Service-Mitarbeiter sollen einen höheren Leistungsgrad erreichen. Der First-Level-Support sollte eine höhere Lösungsquote erreichen. Kostenreduktion wird beim Service-Desk und der IT-Realisierung angestrebt. Das laufende Pflegen einer Know-how-Datenbank als Expertensystem hilft, diese Erfolgskriterien zu erreichen. Andere Prozesse und Fachbereiche sollten hieraus Wissen beziehen können und Zugriff darauf erhalten. Die Prozesse des Problem-Managements sind erst dann abgeschlossen, wenn die Changes bei einem Problem installiert, konfiguriert und getestet worden sind. Dann erfolgt eine entsprechende Rückmeldung der dort beteiligten weiteren Prozesse. Der spezifische Fehler muss aber eindeutig identifiziert worden sein, damit er nach den Veränderungen nicht mehr auftritt Der Prozess Aufgrund der Dreiteilung der Aufgaben wird man auch drei Unterprozesse vorfinden bzw. realisieren. Die wichtigsten Ablaufphasen der Prozesstypen sind die folgenden: Problem-Control-Prozess Erkennung und Fixierung des Problems (zumeist im Incident-Management): Gemeldete Störungen werden zum Problem umgeformt, und zwar normalerweise durch den Service-Desk-Mitarbeiter; Probleme sind es dann, wenn ein erneutes Auftreten erwartet wird; Service-Level-Probleme sind mit höchster Priorität zu bearbeiten. Klassifizierung bzw. Kategorisierung: Einteilung in Eskalationsgruppen Vorbereitung der Weiterleitung zu den jeweiligen Problemlösern, also Experten; Bereitstellung aller zur Lösung notwendigen Daten und Ressourcen; Feststellung von möglichen Auswirkungen; Festlegung der Priorisierung; Fortführen des Bearbeitungsstatus. Zuweisung zum Problem-Management-Team: Abhängig vom vorhergehenden Schritt wird das Problem an die hierfür zuständige Stelle weitergeleitet, die dann die Verantwortung übernimmt; Erfassung und Lösungsvorbereitung;

16 58 4 Die ITIL-Disziplinen des Service-Support Bereitstellung notwendiger Informationen aus diversen Quellen. Analyse und Diagnose: Tests werden durchgeführt, um das Problem nochmals zu provozieren; Abläufe und Testhilfen werden verwendet, soweit erforderlich; die Ursache(n) werden ermittelt; durch Ausschlussverfahren wird das Problem eingekreist ; die Rückmeldungen an die anderen Bereiche erfolgen; das Problem wird abgeschlossen, Ausnahme siehe nächster Schritt. Fallweise Überleitung zum Error-Control-Unterprozess: Eine Überleitung erfolgt nur, wenn es sich um einen Known-Error handelt. Error-Control-Prozess Identifizierung des Fehlers; Initiierung eines Workaround; Lösungswege und -möglichkeiten ermitteln und definieren; Weiterleitung des Problems an das dafür zuständige Team oder den Mitarbeiter; Dokumentation der gefundenen Lösung: Hier kann ein RfC entstehen, falls das Change-Management involviert wird; falls Ja: einschalten des Change-Managements zur Einleitung der Veränderung; Tests werden durchgeführt. Rückmeldung an alle beteiligten Stellen; Problemabschluss. Proaktives Problem-Management Einsatz von Trendanalyse-Systemen; Langzeitmonitoring aktivieren; Finden von echten Schwachstellen; Suchen von möglichen Schwachstellen; Auswertungen an das IT-Management weiterleiten. Dort werden dann fallweise Entscheidungen getroffen, um entsprechende vorbeugende Maßnahmen einzuleiten. Dazu zwei Beispiele: Beispiel 1: Ein Router wird identifiziert, der falsche Datenpakete weiterleitet. Davon sind bestimmte Workstations betroffen. Diese werden vorübergehend stillgelegt, und der Router wird ausgetauscht, bevor das System zusammenbricht. Beispiel 2: Zu Spitzenzeiten werden von Benutzern längere Antwortzeiten gemeldet. Die Ursache liegt im erhöhten Dateitransfer durchs Netz. Als Maßnahme kann dann die Verlegung der Datensicherung auf die Nachtstunden angeordnet werden.

17 4.2 Problem-Management Zur Einführung Für die erfolgreiche Realisierung des Problem-Managements sind eine Reihe von Maßnahmen notwendig: Klare Definition der Aufgaben und Ziele des individuellen Problem-Managements. Gemeinsam mit den Anwendern müssen die SLAs diskutiert und zusammengestellt werden. Die Prozessabläufe werden festgelegt. Notfallpläne müssen aufgestellt werden, zum Beispiel für Rollback-Maßnahmen. Die notwendige IT-Infrastruktur für Änderungen wird bereitgestellt. Das notwendige Personal für das Problem-Management wird aufgestellt und mit dem Service-Desk abgestimmt. Alle notwendigen Kommunikationswege zwischen dem Problem-Management und den Anwendern/Kunden und den anderen ITIL-Bereichen einrichten oder optimieren. Die klare Trennung von Incidents und Problemen durch entsprechende Richtlinien ermöglichen. Verantwortlichkeiten und Zuständigkeiten festlegen (Personen, Funktionen). Schnittstellen zu den anderen Management-Arten und IT-Bereichen definieren. Zeitrahmen für Lösungsfindungen fixieren (SLAs: minimal, maximal). Die Eskalationsstufen festlegen: dies ergibt sich aus den SLA-Definitionen. Externe Hilfen für Sonderfälle (Wartung etc.) vorsehen, falls erforderlich. Incident- und Problem-Mitarbeiter sollten jeweils andere Personen sein. Softwarelösungen, Programme und Datenbanken zur Verfügung stellen, soweit sie nicht bereits vorhanden sind. Schulung der Service-Desk-Mitarbeiter. In der Praxis sind diese Aufgaben nach Bedarf sicherlich weiter zu detaillieren Schnittstellen und Hinweise Für das Problem-Management gibt es etliche Interfaces zu anderen Prozessgruppen oder IT-Funktionen: zum IT-Management zum Netzwerk- oder Systemadministrator zum Benutzergruppen-Manager zum Helpdesk, Benutzerservice oder Service-Desk zum technischen Mitarbeiter zum Incident-Management zum Availability-Management zum Capacity-Management zum Change-Management zum Configuration-Management zum Operations-Management

18 60 4 Die ITIL-Disziplinen des Service-Support Der Lebenszyklus einer Störung umfasst die Schritte: Auftreten eines Incident Gegebenenfalls einen Workaround ermitteln Weiterleitung zum Problem-Management Ursachen ermitteln bei Known-Error: Error-Control-Prozess einleiten RfC erstellen und weiterleiten Änderung initiieren Änderung durchführen Incident-Management informieren Ende der Störung durch Fehlerbehebungsmeldung Dies sind in groben Zügen die Merkmale der ITIL-Prozessgruppe Problem-Management. Die enge Zusammenarbeit mit dem ITIL-Incident-Management wurde bereits aufgeführt. Beide Prozesstypen setzen die Existenz eines gut funktionierenden Service-Desk voraus. Diese Gruppe wird in erster Linie für die Abwicklung der beiden ITIL-Prozesse zuständig sein. 4.3 Change-Management Allgemeines Die dritte Stufe im ITSM-Aufbau besteht in der sinnvollen Verwaltung von Installationen und Änderungen aller Art. Das betrifft jede Art von Software, also Betriebssysteme, Tools, Utilities und Anwendungsprogramme und auch die Hardware, die von Zeit zu Zeit ausgetauscht wird, sei es komplett oder lediglich bei Einzelgeräten. Zu den Changes zählen auch Updates von Verkabelungen und die Modernisierung von Netzwerken beziehungsweise Teilen davon. Änderungen bei der IT-Infrastruktur verursachen erst einmal Unterbrechungen im laufenden Betrieb und damit auch bei den IT-Dienstleistungen. Außerdem sind Änderungen grundsätzlich mit gewissen Risiken behaftet. Häufig müssen IT-Komponenten aufgrund von vorhergegangenen Fehlern ausgetauscht werden. Letztlich sind diese Fehler oder Unterbrechungen schnell und sicher zu beheben, damit der normale IT-Betrieb weiter funktionieren kann. In manchen IT-Umgebungen war es üblich, solche Änderungsmaßnahmen im Ad-hoc-Verfahren durchzuführen. Das Resultat war dabei häufig, dass das System anschließend nicht mehr konsistent war und damit die Abläufe behindert hat. Außerdem ist Hard- und Software in aller Regel nicht gratis erhältlich, von Ausnahmen einmal abgesehen. Wenn also zum Beispiel ein Tool zur Probe aus eventuell unbekannter Quelle installiert und verwendet wird, riskiert man unvorhersehbare Abbrüche oder andere Schäden. Daraus ergibt sich zwangsläufig, dass solche Aktionen zentral überwacht und gesteuert werden müssen. Genau dies ist eine der Hauptaufgaben des Change-Managements.

19 4.3 Change-Management 61 Betriebsunterbrechungen können einzelne Anwender, Abteilungsteams oder die gesamte Belegschaft des Unternehmens betreffen. Wenn die Workstation eines Anwenders ausgetauscht werden muss, so ist zunächst einmal nur genau dieser Mitarbeiter für eine relativ kurze Zeit betroffen. Fällt ein Hub oder ein Konzentrator aus, so sind all jene betroffen, die dort angeschlossen sind. Führt man ein neues Betriebssystem ein, so kann während dieser Zeit kein Mitarbeiter im Unternehmen die IT-Dienste in Anspruch nehmen. Also muss auch der Zeitpunkt des Austausches beachtet werden. Das bekannte Beispiel des Microsoft-Netzbetriebssystems Windows NT ist den meisten CIOs und IT-Mitarbeitern bekannt. Diese Software ist immer noch verbreitet im Einsatz, obwohl der Hersteller offiziell keine Unterstützung hierfür mehr anbietet. Die Umstellung auf Windows 2000 oder Server 2003 geschieht allgemein im so genannten Big Bang - Verfahren. Das bedeutet: Niemand kann während dieser Aktion am System arbeiten. Also wird der IT-Manager anordnen, dass die Aktualisierung am Wochenende stattfinden soll. Dagegen sollte der Tausch eines fehlerhaften PCs relativ schnell erfolgen können. Somit kann die Feststellung getroffen werden, dass auch die Zeitsteuerung eine der Aufgaben des Change-Managements ist. Auch als Folge von Veränderungen bei Geschäftsprozessen können Änderungen an den IT-Abläufen respektive bei den Applikationssystemen erforderlich werden. Zu den Changes im engeren Sinne gehören also auch Software-Installationen jeder Art. Man denke hier an die Einführung von SAP R/3 oder an die Modernisierung von Anwendungs-Subsystemen aller Art. Hierbei sind wiederum viele Mitarbeiter zugleich betroffen. Also muss das Change-Management auch Vorbereitungsaufgaben für Umstellungen durchführen. Ob das neue Gerät oder Programm anschließend auch korrekt funktioniert, muss erst mal bewiesen sein. Hier greifen natürlich die verschiedensten Probeläufe und Tests. Jedenfalls muss hierbei auch das Risiko-Management involviert werden. Einen weiteren bedeutenden Faktor stellt in diesem Zusammenhang auch das Sicherheitsmanagement dar. Die ITIL-Prozessgruppe Change-Management muss in jedem Falle alle notwendigen Veränderungen bei den IT-Komponenten steuern und verwalten. Die Spannweite reicht von einer einfachen Einzelaktion bis hin zu unternehmensweiten Vorhaben. Das Change- Management muss also sehr variabel reagieren können, um jeder Anforderung in dieser Hinsicht gerecht zu werden. Angestrebt wird auch, die Zahl der Changes zu reduzieren, indem eine vernünftige Koordination derselben stattfindet. Die Definition von Unternehmensstandards dient in erster Linie den abgestimmten und sinnvollen Investitionsvorhaben und der Kostenkontrolle. ITIL-Definitionen im Change-Management Einige wichtige Begriffe sind: CAB (Change Advisory Board): Gremium im Unternehmen, um wichtige und umfassende Veränderungen zu beraten. Diese Gruppe sollte aus verschiedenen Fachleuten der betroffenen Bereichen bestehen. Change: Alle Changes oder Veränderungen bestehen aus Konfigurationen, Installationen, Hinzufügungen und Entfernungen von CIs.

20 62 4 Die ITIL-Disziplinen des Service-Support Change-Manager: die Person, die für Durchführung aller genehmigten Changes verantwortlich ist. EC (Emergency Committee): Teil des CAB, welcher bei eiligen Veränderungen die entsprechenden Entscheidungen trifft. FSC (Forward Schedule of Change): Zeitpläne für Implementationen und Installationen von autorisierten Changes. RfC: ein Antrag für bestimmte Veränderungen, der genehmigt werden muss Beispiele Typische Beispiele für Changes in der IT-Umgebung sind: Netzwerkbetriebssystem-Umstellungen Austausch von einzelnen Computern im Netz Austausch von Netzwerkkomponenten Installation einer neuen Verkabelungstechnologie Inbetriebnahme von neuen Anwendungen Segmentierung eines Netzwerkes Umzüge innerhalb des Unternehmens verursachen diverse Changes Kaufsoftware wird installiert und freigegeben Implementierung von geänderten Softwarepaketen Installationen von neuen Druckern und damit neuer Treibersoftware fehlerhafte Programme werden ersetzt neue Tools für das Intranet werden installiert ein SAN wird eingerichtet ein Metadirectory wird unternehmensweit eingerichtet neue Backup-Geräte und die dazugehörige Software werden eingeführt VoIP wird realisiert (Netzwerkkonvergenz) Internetzugänge werden gezielt installiert eine defekte Festplatte muss ausgetauscht werden Systemkonfigurationen werden unternehmensweit notwendig selbst die Realisierung von ITIL und ITSM verursacht Unterbrechungen Passwörter neu vergeben oder alte verändern oder zurücksetzen bei Bedarf ein Motherboard wird ausgetauscht die neueste Version von Microsoft-Office wird auf den Server geladen ein lokaler Drucker wird beim CIO installiert ein Farbdrucker wird für die Benutzung durch das Management installiert Die Liste ließe sich beliebig erweitern. Generell ist alles austauschbar, was sich in der IT- Landschaft befindet. Die Unterschiede für die Benutzer liegen eben in der Zeitdauer der Unterbrechung und im Umfang. Der Aufwand von Changes ist sehr unterschiedlich zu bewerten, dasselbe gilt für Prioritäten und mögliche spätere Auswirkungen beziehungsweise Risiken.