ITIL einführen und umsetzen -...

ITIL einführen und umsetzen

Wolfgang Elsässer

Leitfaden für effizientes IT-Management durch Prozessorientierung

ISBN 3-446-22947-7

Leseprobe

Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-22947-7 sowie im Buchhandel

4 Die ITIL-Disziplinen des

Service-Support

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öffent-lichungen des itSMF und der ITIL-Gremien zusammengestellt und um Praxishinweise er-gänzt.

4.1 Incident-Management mit Service-Desk

4.1.1 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 Organisa-tion 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 entspre-chenden Stellen und Experten weitergeleitet werden. Auch die IT-Mitarbeiter nutzen die Möglichkeiten und das Wissen der Helpdesk-Gruppe. Zumeist werden verschiedene Bear-beitungsstufen 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 Fach-krä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.).

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 ver-

schiedene 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 An-wender 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-Re-quest 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 Ur-sache des Problems erkannt und die passende Lösung hierzu erarbeitet wurde. Diese Ab-grenzungen 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.

4.1.2 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öri-

gen 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).


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.

4.1.3 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 da-mit zusammenhängenden Verwaltungssoftware. Incidents und Probleme werden sowohl im Incident- als auch Problem-Management erfasst und bearbeitet.

4.1.4 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äftspro-zesse und die vereinbarten Serviceleistungen möglichst schnell und sicher wiederaufge-nommen werden können. Nicht zu vergessen sind auch die Kunden- und Mitarbeiterzu-friedenheit und die damit zusammenhängenden Beziehungen.

4.1.5 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 aufrecht-erhalten 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-

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 Be-achtung 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-Ma-nagement 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.

4.1.6 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 initi-

iert 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

4.1.7 Zur Einführung

Natürlich muss im Incident-Management-Prozess auch ein verantwortlicher Manager ein-gesetzt 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äß


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-Pro-zesstypen beteiligt sind.

4.1.8 Schnittstellen und Hinweise

Das Incident-Management unterhält Interfaces zu weiteren ITIL-Hauptprozessen und da-von abgeleiteten Verfahren, sofern diese existieren und implementiert sind. Insbesondere sind dies:

Problem-Management: Können Incidents nicht unmittelbar beseitigt werden, so wer-den 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 Geneh-migungsverfahren 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.

4.2 Problem-Management ____________________________________________________ 53

4.2 Problem-Management

4.2.1 Allgemeines

Man kann das Problem-Management als zweite Ebene des Incident-Management bezeich-nen. 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 sel-ten 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ück-führbar sein. Das Aufspüren des Grundes oder der Gründe ist zumeist aufwendig. Nur sel-ten wird man sofort einen direkten Zusammenhang zwischen Ursache und Auswirkung feststellen. Ausnahmen sind Fälle, die in gleicher oder ähnlicher Form schon einmal aufge-taucht 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 im-mer 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 Vorder-grund steht die Entdeckung der Ursache(n). Manchmal hat man den Fall, dass ein be-stimmter Abbruch durch eine Kette von Fehlerquellen verursacht ist. Hier greifen nun an-dere Prozessverläufe als beim Incident-Management. Problem-Management-Mitarbeiter müssen zum einen über eine hohe Qualifikation verfügen und zum Zweiten andere Hilfs-mittel 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 Un-ternehmen 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 Herstel-ler und die spezifischen Leistungsdaten sind oft wertvolle Quellen.

4.2.2 Beispiele

In der IT-Praxis gibt es sicherlich viele bekannte Fälle und Beispiele. Wohl jeder Mitarbei-ter, 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


möglicherweise zu involvieren sind. Manchmal müssen mehrere Experten zeitgleich betei-ligt werden.

Datenbankfehler: Anwender aus unterschiedlichen Fachbereichen melden voneinan-der unabhängig, dass die Daten in einer Datenbank fehlerhaft sind. Es muss nun festge-stellt 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 ab-hängt. Anwendungsprogrammfehler: Bestimmte Anwendungen stellen dieselbe Fehlermel-

dung des Systems mehrfach fest. Hierbei kann ein Analyst das fehlerhafte Programm ausfindig machen. Handelt es sich um einen „Data Check“ (z.B. Sonderzeichen in Re-chenfeldern), 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 ein-greifen. 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 An-wendungen 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 Datensicherun-gen vollständig und regelmäßig gemacht wurden. Oft sind auch eventuelle Anschaf-fungen 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 fin-den. Es kann auch ein Treiberproblem sein. Viele weitere Gründe können bei Netz-problemen 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 Di-rectory. Manchmal wird auch schlicht und einfach das Passwort vergessen, dann kann der Administrator oder die Hotline des Service-Desks weiterhelfen. Die Sicherheitsver-letzungen 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 (Third- oder Fourth-Level-Support). Hierbei hilft das Incident-Management, um dem Anwen-der das möglichst schnelle Weiterarbeiten zu ermöglichen. Die Ursachen für den Ab-sturz wird das Problem-Management suchen und dafür eine mehr oder weniger größere Zeitspanne einkalkulieren müssen.


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ön-nen die Wiederherstellungsarbeiten Tage dauern. In solchen Fällen können durchaus al-le 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 meis-ten 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 zusam-menarbeiten müssen und eine permanente Kommunikation pflegen.


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 Daten-bank eingestellt. Die genaue Beschreibung des Problems und dessen Klassifizierung sowie die Feststellung der Bearbeitungspriorität werden abgespeichert. Sodann erfolgt die detail-lierte Untersuchung des Problems und dessen Auswirkungen auf die Anwendungen und ganz besonders auf die Services. Soweit zu diesem Zeitpunkt möglich, wird Ursachenfor-schung betrieben. Es gibt Probleme, bei denen gerade die Quellen der Störungen nicht ein-fach 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-


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 Hard- oder Software führen muss.

Bei Known-Errors sollte die verursachende Komponente im Problem-Management gefun-den 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 wie-der. Der Unterschied zu ITIL liegt darin, dass man hier mehrere Subprozesse bzw. Mana-gementsysteme 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 Entste-hen von Problemen schon im Vorfeld erkannt werden. Ein typisches Beispiel hierfür ist das Feststellen von sich abzeichnenden Transfer-Engpässen durch Messungen in Netz-werksegmenten. Ein hohes Datenaufkommen kann darauf hindeuten, dass ein Zusammen-bruch eines Teilnetzes bevorsteht. Langzeitmonitoring mithilfe so genannter Agents in den aktiven Netzkomponenten ist eine Aufgabe des Administrators.

4.2.4 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


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 ge-samte Unternehmen betroffen ist.


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 Erfolgs-kriterien 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 ge-testet worden sind. Dann erfolgt eine entsprechende Rückmeldung der dort beteiligten wei-teren Prozesse. Der spezifische Fehler muss aber eindeutig identifiziert worden sein, damit er nach den Veränderungen nicht mehr auftritt.

4.2.6 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;


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.



Für die erfolgreiche Realisierung des Problem-Managements sind eine Reihe von Maßnah-men 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 er-

mö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.


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


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

4.3.1 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 ausge-tauscht 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 Unterbrechun-gen 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 Resul-tat 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 er-hältlich, von Ausnahmen einmal abgesehen. Wenn also zum Beispiel ein Tool zur Probe aus eventuell unbekannter Quelle installiert und verwendet wird, riskiert man unvorher-sehbare Abbrüche oder andere Schäden. Daraus ergibt sich zwangsläufig, dass solche Ak-tionen zentral überwacht und gesteuert werden müssen. Genau dies ist eine der Hauptauf-gaben des Change-Managements.

4.3 Change-Management ____________________________________________________ 61

Betriebsunterbrechungen können einzelne Anwender, Abteilungsteams oder die gesamte Belegschaft des Unternehmens betreffen. Wenn die Workstation eines Anwenders ausge-tauscht 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 Chan-ges 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-Sub-systemen 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 Unterneh-mensstandards 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 umfas-sende Veränderungen zu beraten. Diese Gruppe sollte aus verschiedenen Fachleuten der betroffenen Bereichen bestehen. Change: Alle Changes oder Veränderungen bestehen aus Konfigurationen, Installatio-

nen, Hinzufügungen und Entfernungen von CIs.


Change-Manager: die Person, die für Durchführung aller genehmigten Changes ver-antwortlich ist. EC (Emergency Committee): Teil des CAB, welcher bei eiligen Veränderungen die ent-

sprechenden Entscheidungen trifft. FSC (Forward Schedule of Change): Zeitpläne für Implementationen und Installatio-

nen von autorisierten Changes. RfC: ein Antrag für bestimmte Veränderungen, der genehmigt werden muss.

4.3.2 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 beziehungswei-se Risiken.



Aus den genannten Beispielen ergeben sich die wichtigsten Aufgaben für das Change-Ma-nagement:

Änderungsanforderungen müssen überprüft werden. Beschaffungen werden über den Einkauf angestoßen, nachdem sie genehmigt wurden. Die Ersatzteilbevorratung wird zentral verwaltet. Implementierungen aller Art werden gesteuert und überwacht. Die Informationsflüsse für die Mitarbeiter sollten optimiert werden. Die Inventarlisten werden aktualisiert. Kosten für Veränderungen werden festgehalten. Die Verwaltung der unternehmensweiten Lizenzierungen ist erforderlich. Das Patch-Management von Software-Updates, z.B. mit SUS (Software Update Ser-

vice) dient der einheitlichen Aktualisierung von Betriebssystem-Veränderungen. Aufgrund von RFCs (Request for Changes) werden die notwendigen Changes initiiert Das technische Personal muss fallweise eingreifen. Das regelmäßige Update von Viren-Scannern dient der Sicherheit im Netzwerk. In bestimmten Fällen sind Wartungsverträge notwendig. Zeitpläne für Umstellungen sind aufzustellen.

4.3.4 Ziele

Die wichtigsten Zielsetzungen beim Change-Management sind die folgenden:

Änderungen bei den Geschäftsprozessen müssen schnell durchgeführt werden. Die Auswirkungen von Changes auf die Dienstleistungen müssen transparent sein. Die Geschäftsprozesse müssen innerhalb der IT flexibel realisiert werden. Jede Implementierung muss verwaltet werden. Die Kosten der IT und der Infrastruktur dürfen sich nicht unnötig ausweiten. Die IT-Services für Kunden und Anwender müssen aufrecht erhalten bleiben. Das Marktgeschehen muss im Unternehmen und in der IT angepasst werden können. Risiken aller Art sollten im Vorfeld der Änderungen abgeschätzt werden können. Neue Technologien müssen sicher und schnell eingeführt werden können. Tests sind in vielen Fällen durchzuführen, um weitere Probleme zu vermeiden. Keine Art von Veränderungen darf zu Folgefehlern und damit Unterbrechungen füh-

ren.


Aufgrund von Arbeitsüberlastung bei den IT-Experten kann es durchaus vorkommen, dass diese manche Änderungen ablehnen oder zu ignorieren versuchen. Diese Verhaltensweisen sind nicht akzeptabel, da sie die Leistungsfähigkeit der IT früher oder später beeinflussen können.


RfCs werden entweder vornehmlich durch das Problem-Management erstellt, in bestimm-ten Fällen auch durch das Incident-Management. Die nachfolgenden Genehmigungsverfah-ren sind je nach Fall unterschiedlich und werden durch verschiedene Entscheider durchge-führt. Ein Betriebssystemumstellung wird in aller Regel vom CIO genehmigt, ein Aus-tausch eines Einzelcomputers für die Anwender kann vom jeweiligen Abteilungsleiter ver-anlasst werden. Es ist ganz klar, dass hier häufig auch der Service-Desk als Initiator auf-tritt. Das CAB besteht üblicherweise aus Entscheidern der Bereiche:

Anwendungsabteilungen (Leiter) CIO (Chief Information Officer) Incident-Management IT-Experten (Analysten, Organisatoren) ein oder mehrere Kundenmitarbeiter (bei Bedarf) Problem-Management Release-Management Service-Desk Service-Level-Management

4.3.6 Der Prozess

Der Ablauf

Erstellung und Weitergabe des RfC an das Configuration-Management Erfassung des RfC und Abspeicherung in der CMDB Genehmigungsverfahren endet positiv oder negativ Einspeicherung in die CMDB durch das Configuration-Management, hierdurch entste-

hen die CIs Zusatzinformationen über Kosten aus dem Financial-Management ermitteln Aufstellen eines FSC als Planungsgrundlage für die Implementierung Ressourcen-Planung für die Veränderungsaktionen Aktivierung des Configuration-Managements Aktivierung des Release-Managements Klassifizierung der RfC-Art und der Dringlichkeitsstufen Entwicklungsarbeiten durchführen, falls notwendig Die dazugehörigen Testaufgaben abwickeln Prüfen der Auswirkungen auf die Anwendungen Erstellen eines PIR (Post Implementation Review) Freigabe Einführung CI-Abschluss Meldung an alle Beteiligten


Die RfC-Kategorien, die Auswirkungen und die Priorisierung von Änderungen

Effect low: Wenig Auswirkungen auf die IT-Dienstleistungen (ohne CAB), wenig Aufwand. Beispiel: Austausch eines lokalen Tintenstrahldruckers bei einem Anwender gegen ein preisgünstigeres Gerät. Effect middle: Mittlere Auswirkungen und erhöhter Aufwand (mit CAB).

Beispiel: Umstellung von Windows 2000-Clients gegen Windows XP-Clients. Effect high: Hohe Auswirkungen und sehr hoher Aufwand (Top-Management, CIO

und CAB). Beispiel: Austausch einer SAP R/2-Anwendung gegen eine R/3-Version. Priority immediate: Umgehende Veränderung erforderlich.

Beispiel: Defekte Festplatte bei einem Server. Priority high: Schnellstmögliche Änderungen notwendig.

Beispiel: Defekte Festplatte bei einer Workstation. Priority middle: Änderung ist notwendig, aber nicht dringend.

Beispiel: Ein Programm bricht bei einer Druckerroutine ab, die Daten am Bildschirm sind jedoch korrekt. Priority low: Änderung ist unbedeutend, aber wünschenswert.

Beispiel: Umstellung bei einem Anwender, Word 97 sollte gegen Word 2000 ausge-tauscht werden.

Es ist zu empfehlen, die Untergliederungen für die Praxis noch zu erweitern. Je detaillierter die RfC mit Prioritätsnummer und Auswirkungsgrad erfolgt, desto effizienter kann die Re-alisierung erfolgen. Anstatt „Niedrig, Mittel und Hoch“ kann man zum Beispiel auch Ab-stufungen von 01 bis 10 vornehmen, was jedes Unternehmen für sich entscheiden kann.


Weitere Tipps und wichtige Funktionalitäten zur Realisierung von Changes können noch genannt werden:

Entwickeln Sie Akzeptanzstrategien für die betroffenen Mitarbeiter, um die Notwen-digkeit einer Änderung darzulegen. Sorgen Sie für ein gutes Berichtswesen in Richtung CIO und Top-Management. Legen Sie fest, dass die Dokumentation aller Changes (CI, CMDB) durchgeführt

wird. Lassen Sie nur genehmigte und autorisierte Veränderungen zu. Pflegen Sie eine ständige Kommunikation mit den Anwendern oder Kunden. Kostenreduktion sollte erreicht werden bei umfassenden Changes. Erarbeiten Sie Notfallprozeduren und -Pläne, um bei dringenden Änderungen schnel-

ler zu reagieren. Die optimale Relation zwischen Stabilität und Flexibilität sollte gefunden werden. Reduzieren Sie Risiken, indem Sie Standardisierungsdefinitionen für Beschaffungen

ausarbeiten. Wo immer möglich, standardisierte Verfahren einsetzen.


Lassen Sie Statistiken über die jeweils durchgeführten Aktionen erstellen (Anzahl, Zeitdauer, RfCs, Störungsbehebungen, Ressourcenverbrauch etc.). Sorgen Sie für transparente Abläufe und Prozesse.


Die wichtigsten Schnittstellen sind die folgenden Systeme und Prozesse:

IT-Management Systemadministrator Netzwerkverwaltung Rechenzentrum (Mainframe-Anwendungen) Telekommunikations-Verantwortliche Risiko-Management Security-Management Technisches Personal alle betroffenen Fachbereichsleiter Service-Desk IT-Entwicklungsgruppen Einkaufsabteilung Transport- und Umzugsmitarbeiter fallweise der Betriebsrat sowie juristische Mitarbeiter Configuration-Management Incident-Management Problem-Management Release-Management Capacity-Management Financial-Management Operations-Management Availability-Management Continuity-Management Service-Level-Management

Man kann abschließend feststellen, dass das Change-Management prinzipiell für praktisch alle Bereiche und Organisationseinheiten zuständig ist. Es liegt nun einmal in der Natur der Sache, dass Veränderungen in jeder Form mehr oder weniger Unterbrechungen nach sich ziehen. Diese wiederum müssen so kurz wie irgend möglich gehalten werden. Das Change-Management ist also sehr wichtig und übernimmt je nach Fall viele Funktionen zugleich.

Tipp: Die Leitung des CAB sollte stets durch das Change-Management erfolgen.

4.4 Configuration-Management _______________________________________________ 67

4.4 Configuration-Management

4.4.1 Allgemeines

Die vierte Phase oder Gruppe von ITIL-Service-Support ist vor allem zuständig für die IT-Infrastruktur. Das Management der Konfigurationen im Unternehmen nutzt Datenbanken und Softwarepakete, um alle notwendigen Informationen über den Bestand der Hard- und Software zu verwalten. Diese Datensammlungen müssen vor allen Dingen stets auf einem aktuellen Stand und konsistenten Zustand sein. Diese Datenbanken sind die schon mehr-fach erwähnten CMDBs. Alle weiteren ITIL-Prozesse nutzen diese Daten für ihre spezifi-schen Zwecke. Auch das IT-Management wird die Informationen für Berichts- und Ent-scheidungsaktivitäten nutzen.

Innerhalb des Configuration-Management werden die Daten der Vermögenswerte erfasst und überprüft. In den Datenbanken befinden sich zusätzlich die wichtigsten technischen Informationen und Leistungsdaten. Bei allen durchzuführenden Veränderungen müssen diese Daten aktualisiert werden. In jedem Unternehmen wird man Asset- oder Inventarisie-rungs-Systeme vorfinden, was schon durch die Finanzbehörden vorgeschrieben wird. Im Einzelfall sollte geprüft werden, inwieweit man diese vorhandenen Datenbanken im Con-figuration-Management verwenden kann.

Neben den technologischen und finanziellen Aspekten gibt es hier auch wichtige Informa-tionen über Relationen aller Art und die jeweiligen Beziehungen zu den angebotenen IT-Services. Es muss möglich sein, bei einer Veränderung bestimmter Komponenten auch die Auswirkungen auf bestimmte Geschäftsprozesse beziehungsweise auf die Dienstleistungen zu erhalten. Die Datensätze in den Datenbanken werden bei ITIL als Configuration Item (CI) bezeichnet. Fragen zur Kompatibilität oder zu möglichen Diskrepanzen hierbei sollten schnell beantwortet werden können. Zudem wird man noch weitere Daten vorhalten, wel-che die Standorte von Komponenten definieren. Bei Umzügen innerhalb des Unterneh-mens sind hierbei nämlich auch Änderungen erforderlich. Weitere Informationen geben Auskunft nicht nur über den Anschaffungswert, sondern auch den jeweiligen Zeitwert im Rahmen von Abschreibungen.

Da auch Programme und Softwaresysteme zu den Configuration Items zu rechnen sind, werden in den Datenbanken auch die Abläufe beschrieben, die Programmdokumentationen abspeichern und Verbindungen bzw. Schnittstellen zu weiteren Subsystemen definiert. Solche Dokumentationen sind in jeder vernünftigen IT ohnehin vorhanden und lassen sich ebenfalls per Verknüpfung mit der CMDB koppeln. Hier geht es vor allem darum, mögli-che Auswirkungen auf Systeme, Abläufe und Geschäftsprozesse zu erkennen, falls Ände-rungen anstehen. Fragen wie „Welches Programm wird durch welche Anwendung be-nutzt?“ tauchen dann auf, wenn besagtes Programm verändert oder ersetzt werden muss. Auch Hardware- und Netzkomponenten sowie die Netzstrukturen sind für den Administra-tor von großem Interesse. „Wo befindet sich was in welcher Ausführung und in welchem Zustand?“ ist für viele Auswertungen und Entscheidungsbildungen bei Investitionen und Changes von großer Bedeutung. Die Definitionen der Relationen innerhalb der CMDB


wird von ITIL nicht vorgegeben, hier hat man also freie Hand und kann die Item-Be-ziehungen nach Belieben aufbauen.

Configuration Items und ihre Charakteristika

Grundsätzlich sind mit Configuration Items alle Komponenten gemeint, die man für die IT-Dienstleistungen benötigt. Sie werden alle in der CMDB eingetragen. Jeder Datenbank-eintrag erhält einen identifizierenden Suchschlüssel (Item Key) und Kategorisierungsanga-ben. Ansonsten sollten dort alle notwendigen Datenfelder vorhanden sein. Mehr dazu in Kapitel 6. Wichtig sind vor allem jene Informationen, die die Relationen zu den Diensten ermöglichen. „Welcher IT-Service setzt welche Komponenten (CIs) voraus?“ – diese Fra-ge muss das Configuration-Management stets aktuell beantworten können. Bei der Daten-modellierung muss man sehr umsichtig vorgehen, damit wirklich alle später benötigten In-formationen vorhanden sind.

4.4.2 Beispiele

Die eingerückten Zeilen sind ausnahmslos CIs, die anderen Begriffe definieren die Katego-rien.

Software Betriebssystem Anwendungsprogramm (Eigenbau) Anwendungsprogramm (Kauf- oder Mietsoftware) Utility oder Tool TK-Software Treiber Middleware Firmware E-Mails

Hardware Mainframe Workstation Server Router Netzkabel sonstige Netzkomponenten Drucker (Leistungsklassen) Bandlaufwerke (Kapazitäten) NICs (Network Interface Card) Motherboards Prozessoren Festplatten Notebooks/Laptops


Palmtops/Organizer WLAN-Komponenten (Wireless LAN)

Dokumentationen Systeme Anwendungen Programme Abläufe (Prozesse) Applikationen Technische Beschreibungen Bedienungsanleitungen

Datensammlungen Datenbanken (evtl. nach DB-Typen) Einzeldateien (nach Entstehungsort) Stammdaten (nach Anwendungen) Bewegungsdaten (auch nach Anwendungen) Sicherungsdaten (nach Server) Grafiken Texte

Nicht direkt der IT zuzuordnende Komponenten Mobiliar Materialien Ersatzteile Fachliteratur

Hier sind lediglich Beispiele aufgeführt, wie man eine umfangreiche Datensammlung sinn-voll untergliedern kann. Je detaillierter die Klassifizierungen vorgenommen werden, desto aussagefähiger sind spätere Auswertungen oder Reports. Hierin haben die IT-Experten je-doch in aller Regel genügend Praxis und Erfahrung, vor allem die Organisatoren und Ana-lysten sind hier gefragt. Diese Arbeiten dürfen nicht unterschätzt werden, sie können sehr umfangreich sein. Der Detaillierungsgrad ist hierbei wichtig.


Die wichtigsten Anforderungen an das Configuration-Management sind:

Auswertungen zur Verfügung stellen CMDB-Aufbau Datenbankadministration und Strukturierung Datenmodellierung eines CI-Aufbaus Identifizierung eines CI Interfaces zu weiteren Systemen der IT bzw. ITIL-Prozessen Kategorisierung der CIs und der CI-Gruppen Komponenten erfassen und einspeichern Management-Informationen für die weiteren ITIL-Disziplinen bereitstellen


Relationen bilden, hier sind Verknüpfungsdaten notwendig Sicherstellen, dass nur autorisierte und genehmigte Komponenten verwendet werden Statusfelder für Zustände, Benutzungszwecke oder Bearbeitungsstand festlegen Technische Daten und Leistungsdaten erfassen, soweit sinnvoll Verantwortlicher für ein CI muss gespeichert werden Versionierung der CIs nach Alter, Release oder anderen Gesichtspunkten Wert des CI in Euro bestimmen (Beschaffungs- und Zeitwerte) Zugriffs- und Zugangssicherung zu den Datenbanken

Gerade der zuletzt genannte Punkt sollte über das Change-Management abgesichert sein.

4.4.4 Ziele

Folgende Ziele werden mit der Realisierung des Configuration-Managements erreicht oder angestrebt:

Changes sollen beschleunigt werden können; Entdeckung nicht benötigter Komponenten; Vermeidung der Installation nicht zugelassener Softwarepakete; die Kopplung mit dem Inventarisierungssystem erhöht die Aktualität und die Konsis-

tenz; die Investitionssicherheit wird größer; das Erreichen eines hohen Kontrollgrades über die IT-Infrastruktur und deren Kompo-

nenten; eine Kostenreduktion sollte erreicht werden können durch Eliminierung unnötiger Kom-

ponenten; die Erhöhung der Kostentransparenz kann erreicht werden; das Lizenzmanagement wird integriert und hilft Kosten sparen; das Patch-Management lässt sich automatisieren und dient der Erhöhung der System-

sicherheit; Planungen für Veränderungen und der IT-Infrastruktur-Ausbau werden vereinfacht; die Minderung von Risiken und Störungen sollte erreicht werden; Auswirkungen auf Services müssen feststellbar werden; Verminderung von Sicherheitsverletzungen; der Standardisierungsgrad wird deutlich verbessert; die TCO-Aspekte werden transparenter; Verminderung von Wartungskosten.

Die ITIL-Prozesse Availability-Management, Capacity-Management und Continuity-Ma-nagement können mit den Informationen des Configuration-Managements optimal versorgt werden. Hier sind letztlich auch strategische Ziele und Aufgaben zu berücksichtigen.



Die Bedeutung und der Nutzwert dieses Prozesses sollten gegenüber den Anwendern be-sonders herausgehoben werden. Viele Informationen vom Change-Management können Anwender häufig übernehmen. Es gibt Möglichkeiten, hierbei das automatische Anlegen von Datenbank-Sätzen (CIs) durchzuführen. Man sollte jedoch nicht eine einzige CMDB errichten, sondern mehrere weitere Datenbanken mit dieser verknüpfen. Geeignete Soft-ware sollte zusätzlich beschafft und verwendet werden, um die Abläufe zu beschleunigen. Das notwendige Personal findet man teils in der IT selbst oder aber im Service-Desk. Querverbindungen zu weiteren IT-Anwendungen sollten geprüft werden. Oftmals sind be-reits Anwendungssysteme vorhanden, welche bestimmte benötigte Daten liefern können. Das manuelle Erfassen ist stets zeitaufwändig und kann zusätzliche Fehler produzieren.

Tipp: Keine Aktionen im Configuration-Management zulassen, ohne das Change-Manage-ment einzuschalten.

4.4.6 Der Prozess

Initiiert wird der Configuration-Management-Prozess allgemein durch das Change-Mana-gement, welches auch bereits vorhandene Daten liefert. Die meisten Changes ziehen die folgenden, zwingenden Konfigurationsaktivitäten nach sich:

Strategieplanung des kompletten Prozesses Zielsetzungen definieren Beschaffung von ergänzenden Informationen, z.B. aus der Asset-Datenbank Ressourcenwahl und Utility-Installationen Interfaces zu den anderen ITIL-Prozessen aktivieren Datenmodellierung und Datenbank-Definitionen CIs erfassen und abspeichern Kontrollläufe quer durch die Datenbank und Auswertungen erstellen Statuskontrollen aller CIs Ergebnis 1: stets aktuelle CMDB-Datensammlung Ergebnis 2: Management-Reporting an verschiedene Personenkreise Ergebnis 3: Informationsweiterleitung an weitere ITIL-Prozessgruppen


Für die Einführung des Configuration-Managements wird man vor allem in der Einrich-tungsphase ein Projekt einrichten, zumindest ist dies zweckmäßig. Der Aufbau der Daten-banken ist durchaus aufwändig und die Unterstützung durch Software sollte zusätzlich ge-geben sein. Die CMDB wird häufig in mehreren sich wiederholenden Schritten aufgebaut, damit der Grad der Detaillierung zunehmend verbessert wird. Man wird hier auch die Un-terstützung des Service-Desk und einiger IT-Experten anfordern müssen, um die Daten-banken sinnvoll und vernünftig aufzubauen.


Vielfach findet man bereits installierte Systemmananagement-Softwarepakete, die Schnitt-stellen zu ITIL bieten. Überprüfen Sie unbedingt, welche bereits existierenden Daten-sammlungen des Unternehmens genutzt werden können. Doppelte Datenhaltung führt zu Inkonsistenzen und sollte vermieden werden.


Die wichtigsten Schnittstellen sind die folgenden Systeme und Prozesse:

CIO Service-Desk Asset- oder Inventarisierungssysteme IT-Anwendungen verschiedener Ausprägung IT-Entwicklungsabteilung Anwendergruppen bzw. Fachbereiche Change-Management Availability-Management Capacity-Management Continuity-Management Problem-Management Incident-Management Release-Management Operations-Management

Das Configuration-Management befindet sich logisch betrachtet zwischen dem Change- und dem Release-Management. Es ist zu empfehlen, diesen Prozess möglichst frühzeitig im Unternehmen einzuführen. Dies gilt zumindest für den Aufbau der notwendigen Daten-banken und die Auswahl der Programme. Bei einer eigenen Entwicklungsabteilung werden die Programme oft im Hause selbst hergestellt.

4.5 Release-Management

4.5.1 Allgemeines

Das Release-Management ist in erster Linie dafür zuständig, die CIs für die Anwendungen produktionsreif zu gestalten. Programme und Prozesse befinden sich zu diesem Zeitpunkt noch in der Testumgebung und werden dort erst einmal ausgiebig geprüft. Der Begriff Re-lease wird im Allgemeinen vor allem für neue Versionen von Softwarepaketen benutzt. Betriebssysteme und Applikationssysteme sind die bekannten Beispiele hierfür. Im Sinne von ITIL wird jede Art von Configuration Item als Release bezeichnet, welches ein vor-handenes älteres CI ersetzt oder ganz neu hinzukommt. Zu den Releases zählen also auch Hardwarekomponenten aller Art.

4.5 Release-Management ____________________________________________________ 73

Die Produktionsumgebung ist derjenige Bereich der IT, in dem sich die Benutzer später bewegen. Es ist eine sehr wichtige Voraussetzung für ein unterbrechungsfreies Arbeiten, dass alle hierfür benutzten Komponenten einwandfrei funktionieren müssen. Der Übergang vom Teststatus zum Produktionsstatus ist bei der Informationstechnologie eine regelmäßig wiederkehrende Funktion. Die Haupttätigkeiten bestehen aus der Implementierung, der In-stallation und der endgültigen Konfiguration im Sinne der Anwendungen.

Die produktive Umgebung der IT stellt einen isolierten Bereich dar, welcher nicht ohne weiteres von jedermann verändert werden darf. Programme, Systeme und Geräte unterlie-gen hierbei einem spezifischen Schutzmechanismus. Die Realisierung des Release-Managements kann durchaus mit einem Projekt verglichen werden. Rollouts von größeren Installationsvorhaben sind zeitlich begrenzt und mit einem klaren Ziel versehen. Die Um-setzung der Testumgebungen in die Produktionsumgebungen verläuft in einer gut organi-sierten IT-Umgebung nach einem vorbestimmten Schema und nutzt Jobnetze sowie vorge-fertigte IT-Prozeduren.

Einen unternehmensweiten Hardware-Austausch registrieren die Anwender in der Regel kaum oder gar nicht. Ausnahmen sind Release-Aktionen im Bereich der Client-Work-stations. Voll ausgerüstete und schnelle Rechner sind häufig nicht an jedem Arbeitsplatz vonnöten. Man wird versuchen, hierbei möglichst gleichartige Computer einzusetzen, was den Verwaltungs- und Wartungsaufwand reduziert. Ein Praxisbeispiel sind die so genann-ten Thin-Clients als abgerüstete PCs für die Fachabteilungen. Hochleistungsfähige Work-stations sind im CAD-CAM-Umfeld und in industriellen Produktionsumgebungen jedoch sinnvoll.

Einige Begriffe und Komponenten des Release-Managements

Auch bei dieser ITIL-Disziplin werden bestimmte spezifische Termini verwendet. Die wichtigsten sind:

DHS (Definitive Hardware Storage): eine Datenbank für die Speicherung der Informa-tionen aller Hardware-Komponenten der Systeme; DSL (Definitive Software Library): eine oder mehrere Bibliotheks-Datenbanken im

System, in welchen die freigegebenen Produktionsprogramme und Prozeduren vor-gehalten werden; Release Number: identifiziert ein bestimmtes Release. Release-Typen: beschreiben den Umfang der Releases. Delta: Changes an einem einzigen Release; Full: kompletter Austausch eines Release; Package: Release mit mehreren CIs, die zusammenhängend zu betrachten sind. Release Unit: definiert den Teil der IT-Infrastruktur, welcher im Zusammenhang mit

mehreren Changes steht. Hierbei erfolgt die Zuordnung zu Umgebungen wie Testum-gebung, Produktionsumgebung, Archivierung oder auch die Software-Entwicklung. Release-Varianten: definieren alle notwendigen Informationen für Änderungen an ei-

ner IT-Dienstleistung oder an der IT-Infrastruktur. Releases, welche für den Austausch vorhanden sind, ersetzen grundsätzlich deren ältere Versionen. Dabei können auch Re-


lease-Nummern zur Versionierung benutzt werden. Releases können oft auch in mehre-ren Varianten zugleich auftreten. Emergency Releases: dienen einer schnellen Beseitigung von Störungen, welche sich

stark auf den Praxisbetrieb auswirken und IT-Services behindern. Major Releases: bedeutende Änderungen an der Hard- oder Software, welche oftmals

mit neuen oder angepassten Funktionalitäten für IT-Abläufe einhergehen. Diese betref-fen zumeist ganze Fachabteilungen oder auch das Gesamtunternehmen. Medium Releases: lokal begrenzte Änderungen, die zumeist Teams oder Gruppen be-

treffen. Minor Releases: Einzelaktionen für kurzfristige und kleinere Veränderungen.

Hinweis: Die CMDB ist hierbei in jedem Falle auch involviert und muss mit den notwen-digen Updates versehen werden.

4.5.2 Beispiele

Einige wenige Beispiele können die Unterschiede der Release-Varianten aufzeigen:

Emergency Release: Ein Programmfehler wurde entdeckt und muss umgehend beseitigt werden, da ansonsten die Abläufe und Services behindert werden. Major Release: Ein neues Applikationssystem, zum Beispiel eine E-Business-Anwen-

dung via Internet, wird eingeführt. Hier sind Aktionen notwendig, welche sich auf das Gesamtunternehmen auswirken. Medium Release: Bei einem Arbeitsteam wird ein Konzentrator ausgetauscht, an dem

einige wenige Workstations der Anwender angeschlossen sind. Minor Release: Bei einem einzelnen Anwender muss eine Festplatte ersetzt werden.


Die wesentlichen Anforderungen an das Release-Management sind:

Die Abspeicherung aller Softwarepakete in Form von Runtime-Modulen, also lauffähi-ger IT-Prozesse. Dies gilt sowohl für Kaufsoftware als auch für Eigenentwicklungen; Die Installation von Jobs und Jobnetzen, welche praktisch die Geschäftsprozesse un-

terstützen sollen; Die Auswertung von Tests sowohl für Hardware als auch für Software; Die Durchführung von Freigabeprozeduren nach einem festen Schema; Die Softwaredistribution, die im Unternehmen lokal und an entfernten Standorten glei-

chermaßen und weitgehend automatisch erfolgt; Der Anschluss autorisierter Benutzer an die Softwaresysteme und die Bereitstellung

der notwendigen Dateien und Datenbanken für die Applikationen; Auch in der Produktionsumgebung müssen die Systeme nochmals eine schematisierte

Testprozedur durchlaufen, nun aber unter realistischen Einsatzbedingungen; Als gewünschter Nebeneffekt werden nicht lizenzierte Programme identifiziert und eli-

miniert. Diese Aktion steuert in der Praxis bereits das Change-Management;


Die Einführung der Anwender in die Systeme ist ebenfalls wichtig, damit sie problem-los damit arbeiten können. Dies können der Benutzerservice oder der hierfür abges-tellte IT-Entwickler durchführen.

4.5.4 Ziele

Ergebnisse und Ziele des Release-Managements:

Als Erstes sollten alle betroffenen Mitarbeiter über die entsprechenden und geplanten Aktionen informiert werden; Es darf nur komplett ausgetestete Software in die Produktionsumgebung gelangen; Es muss sichergestellt sein, dass nur zugelassene und legale Software eingesetzt wird; Die Hardware-Komponenten müssen dem zuvor festgelegten Unternehmensstandard

entsprechen; Die enge Zusammenarbeit mit dem Change- und Configuration-Management muss ge-

währleistet sein; Die CMDB muss den aktuellen und korrekten Stand der IT-Infrastruktur darstellen; Die Umstellungsarbeiten und Implementierungen müssen schnell, sicher und benutzer-

gerecht durchgeführt werden; Zeitplanungen für Einzelaktionen und komplette Installationen (Big Bang) müssen stän-

dig erarbeitet und überwacht werden; Die Produktionsumgebung ist besonders schutzwürdig, hier greifen die Vorgaben des

Security-Managements; Das Hauptziel ist letztlich, dass die geforderten IT-Services anschließend auch fehler-

los und nach SLA-Bedingungen erbracht werden können.


Die permanente Unterstützung der Anwender durch den Service-Desk ist nicht nur wäh-rend der Release-Aktionen notwendig, auch die spätere Unterstützung der Kunden und Benutzer durch die Mitarbeiter des Benutzerservice oder Helpdesk ist unabdingbar. Wer-den fehlerhafte Komponenten oder nicht einwandfrei funktionierende Anwendungen ent-deckt, sind auf jeden Fall Eingriffe notwendig. Im Mittelpunkt stehen schließlich die Ser-vices für die Benutzer. Viele Release-Wechsel darf man auch nicht unterschätzen. Der Ar-beits- und Zeitaufwand kann oftmals erheblich sein.

4.5.6 Der Prozess

Allgemein sind beim Release-Management drei Umgebungsvarianten im Spiel:

die Entwicklungsumgebung, falls vorhanden und notwendig, die Testumgebung und die Produktionsumgebung.


Prozessschritte

Vorarbeiten: Das Release-Management erstellt Regelwerke und Durchführungsrichtlinien für die

Release-Prozesse. Die Bereitstellung der Releases wird geplant und vorbereitet. Die Beteiligten werden informiert (Entwicklungsabteilung, Technikergruppe). Die Vorgehensweisen bei Full-, Package- oder Delta-Releases werden in jedem

Einzelfall geregelt. Voneinander abhängige Releases werden definiert und die Relationen beschrieben. Die Life Cycles werden festgelegt, soweit es notwendig und möglich ist. Die Feststellung treffen, welche SLA betroffen sind. Alle betroffenen IT-Dienstleistungen müssen berücksichtigt werden. Die notwendigen Arbeitsgruppen werden definiert und Mitarbeiter eingeplant. Die Zeitpläne werden aufgestellt und die Termine festgelegt. Test- und Abnahmemodalitäten werden fixiert und detailliert beschrieben. Die Datenbanken müssen möglichst zeitnah aktualisiert werden.

Design und Realisierungsvorbereitung: Die Releaseentwürfe werden zusammengestellt. Bei Programmen und Prozessen müssen die Abläufe und die Funktionen erstellt

werden. Die Entwicklungsverfahren werden durch die IT zur Verfügung gestellt. Rollout-Prozesse werden zur Verfügung gestellt und unter Standardbedingungen

vorbereitet. Rollback-Verfahren werden definiert, falls ein Release wider Erwarten nicht funkti-

onieren sollte. Hardware wird bei Bedarf zur Beschaffung angefordert bzw. mit dem Change-Ma-

nagement abgestimmt.

Tests und Abnahmen: Einzeltests bei Programmen werden durchgeführt. Geräte werden durch Messungen oder Funktionsprüfung getestet. Testumgebungen bei Software sind mit Testdaten zu bestücken. Die Umgebungen sollten mit der Produktionsumgebung identisch sein oder aber

sehr ähnlich. Testhilfen werden zur Verfügung gestellt und fallweise auch die Benutzer einbezo-

gen. Genormte Testprozeduren werden verwendet und die Ergebnisse dokumentiert. Die Installationen werden vorbereitet. Abnahmemodalitäten werden zusammengestellt und die Anwender einbezogen. Eine Notfallplanung und geeignete Maßnahmen werden initiiert. Informationen über diese Phase müssen zum Change-Management weitergeleitet

werden.


Einführungsplanung: Die Releasepläne werden um die Implementierungspläne ergänzt. Zeitpläne für die Umstellungsphasen mit den Ergebnissen werden aufgestellt und

relativiert. Personal und Ressourcen für Installationen werden zur Verfügung gestellt. Bereits vorhandene Dokumentationen werden verteilt oder zugänglich gemacht. Eine Aufstellung aller betroffenen Abteilungen und Personenkreise muss durchge-

führt werden.

Anwendervorbereitung: Die betroffenen Anwender werden über die Zeitpläne informiert. Eventuell notwendige Schulungsmaßnahmen werden gestartet. Die Kommunikationswege der Informationen werden fallweise aktualisiert. Die Daten für die späteren Anwendungen werden angepasst und zur Verfügung ge-

stellt. Testergebnisse sollten durch die Anwender als Testziele vorbereitet werden. Hinweis: Diese Schritte können auch schon vor dem Prozessstart durchgeführt wer-

den. Das ist auch häufig sinnvoll, da die Anwender und der Service-Desk oft die ei-gentlichen Auslöser von Changes und Releases sind und Aktionen schon im Vor-feld abgestimmt sein müssen.

Rollout: Geräte werden zum Aufstellungsort transportiert. Programme und Anwendungen werden durch die einheitlichen Verfahren in die Pro-

duktivbibliotheken gestellt. Installationen werden durchgeführt (einzeln oder im „Big Bang“-Verfahren). Die noch notwendigen Konfigurationen an Geräten müssen erledigt werden. Die Anwender werden eingearbeitet und müssen die Funktionalitäten überprüfen. Die Anwender werden eine gewisse Zeit direkt betreut, später übernehmen die Ser-

vice-Desk-Mitarbeiter diese Aufgaben.

Die Abläufe sind oft variierbar, je nach Umfang oder Art des Releases. Bei Software-In-stallationen gelten teilweise andere Bedingungen als bei Hardware-Releases. Eine Entwick-lungsumgebung gibt es nicht unbedingt in jedem Unternehmen, dort wird dann Kauf- oder Mietsoftware verwendet. Doch auch hierbei sollten die Prozesse des ITIL-Service-Supports aktiviert werden.


Die DHS-Datenbank für die Hardwarekomponenten kann die folgenden Datenfelder und Release-Gruppen beinhalten:

Ausgabegeräte: Grafikkarten, Bildschirm, Drucker, Leistungsdaten Computer: Mainframe, Midrange, PC, Server, Workstation, Leistungskennungen CPU: Typ, Performance, Leistungsdaten


Eingabegeräte: Maus, Scanner, Tastatur, Leistungsdaten Hauptspeicher: RAM, DRAM, SDRAM, Leistungsdaten Motherboards: Leistungsdaten, Bestückung Netzwerkkarten (NIC): Netzwerktyp, Rechnertyp Netzwerkkomponenten: Router, Hub, Konzentrator, Kabel, Brücke mit Leistungsdaten Prozessoren: Leistungsdaten, Typ, Einzel- oder Mehrfachprozessor Speicher: Festplatten, Disketten, CD-ROMs, Bänder, weitere Medien, Leistungsdaten USV: Leistungsdaten, Typ, Einsatzort

Natürlich sind noch viele weitere Datenfelder bestückt, was je nach Unternehmen indivi-duell durchzuführen ist.

Informationen über die Softwaresysteme werden in ähnlicher Form in der Datenbank DSL abgelegt. Als Datenquellen können die Softwarebibliotheken der IT verwendet und um die Angaben über die Verwendung ergänzt werden.

Major Releases betreffen oft alle Mitarbeiter des Unternehmens. Die Beispiele Netzwerk-betriebssystem und die Anwendungssubsysteme sind allgemein bekannt. Für die Software-verteilung verwendet man entsprechende Tools, welche mit den Systemverwaltungs-Paketen verbunden sind. Oft sind diese Funktionen auch bereits in der vorhandenen Mana-gement-Software enthalten.


Das Release-Management benötigt Schnittstellen zu:

Top-Management Anwendergruppen und Bereichsleiter CIO Service-Desk IT-Entwicklungsabteilung (bei Bedarf) Technikergruppen (bei Bedarf) Change-Management Configuration-Management

Umfassende Aktionen oder auch nur kleine Änderungen an einem Programm durchlaufen stets dieselben Prozeduren des Support-Managements. Diese Gruppe betrifft alle Störun-gen, Probleme, Unterbrechungen und Fehler bei den IT-Infrastruktur-Komponenten. Der Service-Desk wird hierbei fast immer beteiligt, da zumeist die Anwender und somit die Dienstleistungen betroffen sind.

Hinweis: Die Entwicklungsabteilung kann vielfach auch Changes und Releases anstoßen. Als Beispiel seien Programmfehler genannt, die ein Entwickler während der Programmdo-kumentation entdeckt. Fehlende oder falsche Funktionen können somit auch durch diese Personengruppe zu schnellen und wichtigen Veränderungen führen und die ITIL-Prozesse in Gang bringen.

Date post:	07-Aug-2019
Category:	Documents
Upload:	vubao
View:	244 times
Download:	0 times

ITIL einführen und umsetzen -...

Documents