WENDIA ITSM EXPERT TALK Zen und die Kunst, IT Konfigurationsmanagement umzusetzen: Praktische Anleitung für eine ingenieurmäßige Vorgehensweise ACHIM GRINDLER
Praktische Anleitung für eine ingenieurmäßige Vorgehensweise Zen und die Kunst, IT Konfigurationsmanagement umzusetzen Configuration und Service Asset Management gehört im IT Service Management nach ITIL zu den Kern- und Königsdisziplinen. Die Komplexität des Themas mit seinen umfangreichen Ausbau- und Erweiterungsmöglichkeiten stellt IT-Organisationen häufig vor große Herausforderungen. Wie packt man den Aufbau der CMDB und die Umsetzung von Prozessen am Besten an? Wie können IT Manager beim Thema Configuration Management von den klassischen Ingenieursdisziplinen profitieren? Und was hat die Kunst ein Motorrad zu warten mit IT Service Management zu tun? Achim Grindler, stv. Abteilungsleiter am Steinbuch Centre for Computing des Karlsruher Instituts für Technologie (KIT), zeigt im Wendia ITSM Expert Talk Paper eine neue Perspektive auf, die bei der Einführung von Configuration und Service Asset Management wertvolle Unterstützung bietet. Dabei wird deutlich, wie ein ingenieurmäßiges Vorgehen den Umgang mit den großen Herausforderungen des Themas wesentlich vereinfacht. Komplexität eines Configuration Management Systems Service Asset and Configuration Management (SACM) hat das Ziel gesicherte und aktuelle Informationen über die zur Leistungserstellung verwendeten Konfigurationselemente zur Verfügung zu stellen [1]. Eine Configuration Management Database (CMDB) oder neuerdings ein Configuration Manangement System (CMS) ist für diese Aufgabe essentiell. ITIL V3 entwickelt für das CMS eine komplexe Softwarearchitektur, aufgeteilt in vier Ebenen (Daten- und Informationsquellen und Werkzeuge, Informationsintegrationsschicht, Wissensverarbeitungsschicht und Präsentationsschicht). Im Herzen dieser Architektur steht die integrierte CMDB mit dem darin abgebildeten Service Modell [2]. Diese Architekturgrafik zeigt, wie umfangreich das Thema SACM gestaltet und ausgebaut werden kann, um alle ITIL-Verfahren zu adressieren. Je nach Anforderung der IT-Organisationen werden zur Umsetzung Projekte von zwei bis drei Jahren Laufzeit aufgesetzt Ausgang ungewiss, da meist mitten in der Umsetzungsphase das Datenmodell oder Werkzeuge und Schnittstellen neu bewertet und diskutiert werden.
Herausforderungen bei der Umsetzung Die großen Herausforderungen bei der Umsetzung von Konfigurationsmanagement im IT Service Management werden deutlich, wenn man versucht folgende Fragen zu beantworten: Welche IT-Prozesse sollen durch das Configuration und Asset Management unterstützt werden? Welche Daten (Stamm- und Detaildaten) müssen von wem in welcher Form gespeichert und kontrolliert werden, um diese IT- Prozesse zu unterstützen? Wie wird ein Configuration Management Prozess gestaltet, der im Zusammenspiel mit den anderen IT-Verfahren auch gelebt werden kann also effektiv und effizient ist? Dafür gibt es leider kein Patentrezept. Im Gegenteil, mit komplexer werdenden IT-Landschaften (verteilte, heterogene Systeme und Anwendungen, virtualisierte Hardware, Software, Speicher und Netzwerke) wird auch das klassische Konfigurationsmanagement aufwändiger und es wird schwieriger das angestrebte Ziel (s.o.) zu erreichen. Von der Produktdokumentation her denken Wie kann hier ein ingenieurmäßiges Vorgehen weiterhelfen? Bei der Entwicklung, Bau, Test, Vertrieb und beim Kundendienst eines Produktes fließen in aller Regel wichtige Dokumentationen zur Beschreibung dessen Konfiguration zusammen. Die Service- Handbücher (Service Manuals) von z.b. HiFi-Geräten oder auch Motorrädern, sind umfangreiche Konfigurationsbeschreibungen. (das ist die Sicht des Dienstleisters auf die Konfiguration). Der Käufer des Produkts bekommt eine ausführliche und verständliche Bedienungsanleitung zur Hand (entspricht der Kundensicht auf die Konfiguration). Ich wage die Behauptung: Gute Konfigurationsbeschreibungen unterstützten bestmöglich die Produkt- und Service-Prozesse. Sie sind essentiell für das Erbringen der Leistungen im gesamten Produkt-/Service-Life-Cycle. Mit anderen Worten: Schlechte, d.h. unvollständige und nicht aktuelle Konfigurationsbeschreibungen sind häufig die Ursache für eine verminderte Servicequalität innerhalb der verschiedenen Produkt-/Service-Life-Cycle Phasen.
Ein praktisches Beispiel: Service-Handbuch eines HiFi-Verstärkers Vor mir liegt das Service-Handbuch für einen HiFi-Verstärker. Die Informationen sind unterteilt in die Abschnitte: Funktionsbeschreibung, Demontage und Austausch, Elektrischer Abgleich, Verpacken, Schaltungs- und Print-Diagramme, Explosionszeichnungen, Teilelisten / Hersteller, Technische Daten, etc. Jeder Abschnitt dieser Konfigurationsbeschreibung ermöglicht die Abwicklung eines internen Service-Prozesses: Abschnitt Technische Beschreibung, Funktionsdiagramme Demontage und Austausch Elektrischer Abgleich Technische Daten Verpacken Schaltungs- und Print-Diagramme Explosionszeichnungen Teileliste / Hersteller Service-Prozess Wissen über Gesamtprodukt / Service und Zusammenhänge der Komponenten Reparatur / Änderung Geräte Wartung Endabnahme sicherer Versand und Inbetriebnahme Fehlersuche, Reparatur Produktion, Reparatur Produktion, Beschaffung, Reparatur Der Mehrwert dieser Konfigurationsbeschreibung kann im Service-/Prozesskontext so formuliert werden: Diese Konfigurationsbeschreibung ermöglicht es, u.a. dass: Fehler in akzeptabler Zeit gefunden und behoben, Wartungsarbeiten korrekt und nachhaltig durchgeführt, und die richtigen Ersatzteile bei den Herstellern bestellt werden können. Abb. 1: Auszug aus dem Service Manual eines HiFi-Verstärkers
Einfache Zusammenstellung von Konfigurationsbeschreibungen für die IT Wenn eine IT-Organisation die Dokumente (Papier, Excel-Listen, Datenbanken, Web, Wiki,...), die für die Leistungserstellung benötigt werden, sichtet, aktualisiert, fehlende ergänzt und dann in Beziehung zueinander stellt, entsteht daraus auch ohne neue, komplexe Tools eine gute Konfigurationsbeschreibung von IT- Serviceleistungen. Die Beziehungen und Verweise sollten später in einem Tool re- cherchierbar auf Basis einer Datenbank gehalten werden. Für die Beschreibung von Konfigurationselementen, die in die Datenbank aufgenommen werden, sollten Stammdaten definiert werden, ohne die die gelebten oder zu noch etablierenden Prozesse nicht effizient funktionieren. Eine Präsentationsschicht kann z.b. auch in einem schon vorhandenen Content Management oder Wiki System abgebildet werden. Prozesse, Dokumentation, Service-Modell Will ein IT-Servicebetreiber sein Produkt (seinen IT-Service) nach diesem Beispiel beschreiben, ist es zunächst wichtig zu beantworten, mit welcher Beschreibung welcher Prozess unterstützt wird oder werden soll. Dies führt dazu, dass der von ITIL V3 propagierte Service Life Cycle an Bedeutung gewinnt und zu jeder Life Cycle Phase dedizierte Dokumente und Daten erstellt bzw. in Beziehung gesetzt werden. Wie wird ein neuer IT-Service in der Organisation eingeführt? Wie wird ein IT-Service gewartet und betrieben? Aus welchen Komponenten und Services besteht der IT-Service und wie stehen diese in Beziehung untereinander? Wie werden Komponenten für einen IT-Service bestellt und konfiguriert? Wie wird der IT-Service vertrieben? Wie werden Anwender bei der Nutzung des IT-Services unterstützt? Dies sind nur einige Fragen, die, wenn sie beantwortet werden, zu einem Betriebs- und Servicekonzept führen, das dann in den Betriebs- und Service-Handbüchern konkretisiert werden kann.
Aufbau einer CMDB Und wie kann nun eine Integrierte CMDB aufgebaut werden? Alle zur Leistungserstellung genutzten Komponenten werden mit ihren Stammdaten über einen Configuration Management Prozess in die Datenbank gebracht (korrespondierend mit der Teileliste des Gerätes) und danach mit dem aus den verschiedenen Dokumenten gebundenen Service-Handbuch in Beziehung gesetzt. Das Service-Handbuch selbst wird wiederum mit den Service-Anleitungen und den Service-Spezifika (Service Level) in Beziehung gesetzt und die Service Spezifika (ggf. unterschiedlichster Ausprägung) werden schließlich mit den Kunden in Beziehung gesetzt. Die Instanzen eines angeforderten IT-Service werden mit den Anwendern, die Betriebs-Handbücher mit den produktiven Komponenten und Systemen verknüpft. Blaupausen für Servicemodelle, die diesen Anforderungen genügen, liegen vor und können an die jeweiligen Bedürfnisse angepasst werden (z.b. [3]). Eine Herausforderung, gerade auch für die Toolhersteller, ist die Implementierung von Regeln (Policies) zur Pflege und zum Aufbau einer strukturierten CMDB [4]. Ein praktikables Service-Datenmodell ist auch in der Service Management Toolsuite POB G6 von Wendia umgesetzt. CMDB als Wissensdatenbank Service Knowledge Beim Bau eines HiFi-Gerätes ist z.b. die Teileliste essentiell. Beim Aufbau eines IT-Services, sind dies die zum Betrieb notwendigen Server und Systeme. Wie müssen die Teile auf der Platine bestückt werden? Korrespondiert mit der Frage: Welche Software wird wie auf welchem System installiert und konfiguriert? Wie wird das Gerät elektrisch abgeglichen? Bedeutet im IT-Kontext: Wie wird das Gesamtsystem in Betrieb genommen und überprüft, ob die Lösung den Kundenanforderungen entspricht? Hat man am Ende des Projekts gute Konfigurationsbeschreibungen im vorgeschlagenen Sinn zusammengestellt, entsteht eine Service Knowledge Datenbank durch geschicktes Zusammenklicken der verwendeten Elemente (Software, Hardware, Zuständigkeiten, Services, Servicebausteine) und verlinken mit dem jeweiligen Service-Handbuch.
Wissen veraltet im Sekundentakt "Eine Installation (oder eine Service-Konfiguration) kann nur bewirtschaftet werden, wenn man genau weiß, aus welchen Einzelteilen sie besteht. Besonders wichtig ist dieses Wissen, wenn einige dieser Einzelteile für das korrekte Funktionieren des Systems und damit für den täglichen Geschäftsablauf lebenswichtig sind [1]. Das gilt für ein Motorrad oder ein HiFi-Gerät genauso wie für einen IT-Service. Wenn wir komplexe Systeme in kleinere weniger komplizierte Teile und Funktionen zerlegen, erschließt sich das notwendige Wissen über das Gesamtsystem. Abb. 2 zeigt eine Struktur, die auf technische Systeme anwendbar ist [6]. Abb. 2: Strukturierung eines Systems in Funktionen und Teile Für viele IT-Prozesse ist es wichtig die Funktion(en) eines Services aus Anwendersicht zu kennen und im Fehler- oder Änderungsfall IMAP-Zugang Web-Zugang E-Mail senden E-Mail E-Mail empfangen Mobile Synchronisation Verschlüsselung / Signatur SPAM-Filter genau benennen zu können. Nachfolgende Tabelle macht dies deutlich. HiFi-Verstärker Rechter Kanal / Linker Kanal Leistungsanzeige rechts, links Leistungsbegrenzer Klangregelung Lautstärkeregelung Balanceregelung zusätzlicher Lautsprecherausgang
Nutzen und Vorteil des durch die CMDB generierten Wissens Wenn in der CMDB die Services zusätzlich mit Funktionsblöcken abgebildet werden und diesen Funktionsblöcken dann dafür benötigte Teile (Sub-Services, Komponenten) zugeordnet werden (wie in dem Blockdiagramm im Service-Manual des HiFi-Gerätes), erreicht man eine detaillierte Anwendersicht. Wenn Funktionen Wichtigkeiten oder Service-Level zugeordnet bekommen, kann man Incidents besser priorisieren, Verfügbarkeiten besser auswerten und Auswirkungen bei Änderungen besser abschätzen. Wissen, das aus den zusammengestellten Daten und Informationen resultiert, nutzt allen Beteiligten: Anwender greifen auf die richtige Anleitung zu, Administratoren nutzen die offiziellen Wartungsfenster, Entwickler die aktuellen Software- Bibliotheken, Change Manager erstellen Impact-Analysen und kontaktieren Betreiber, Serviceverantwortliche definieren Service- Klassen und Kundenbeziehungen, das Service Desk recherchiert zu den häufig gestellten Fragen... Prozesse aus den Ingenieursdisziplinen und ihr gewinnbringender Einsatz im ITSM Fazit: Gute Konfigurationsbeschreibungen sind auch diejenigen, aus denen man etwas genau wissen kann. Deshalb sollte unbedingt ein Änderungsmanagement betrieben werden. Sehr schnell veränderliche Daten an einer Vielzahl von Objekten, sollten automatisiert eingesammelt werden. Während Service- Beziehungen nur bedingt automatisiert gepflegt werden können. Hier ist oftmals ein redaktioneller Prozess sinnvoll und notwendig. In der industriellen Entwicklung und Fertigung steht am Ende einer Phase (Entwicklung, Test, Prototyp, Produktreife, Vermarktung) ein Qualitätsmanagementprozess und sammelt über Checklisten gesteuert, für die Abnahme wichtige Dokumente ein. Vielleicht ist es ein gewinnbringender Ansatz, auch für das IT Service Management von den Ingenieursdisziplinen und der Kunst der Motorradwartung [5] zu lernen?
& BUCHTIPP Zen und die Kunst ein Motorrad zu warten 1974 hat Robert M. Pirsig ein wunderbares Service-Management Buch geschrieben. Ich empfehle es jedem IT-Manager, der in das Thema Qualität tiefer eintauchen möchte. Der Autor beleuchtet viele Aspekte des Qualitätsbegriffs und zeigt diese dem Leser auf unterhaltsame Weise anhand der Motorradwartung. Einige Erkenntnisse aus dem Buch lassen sich direkt auf das IT Service Management übertragen. Erfolg entsteht, wenn man Sinn für Qualität hat [S. 294] Verständnis / Wissen über das Gesamtsystem wichtig [S. 102] eine Strukturierung dieses Systems ist enorm hilfreich [S. 100] für erfolgreiche Wartungen benötigt man Mut und Begeisterung [S. 313, 314] durch welche Arten von Entmutigungen Wartungsaktionen scheitern [S. 316-321] Der Wert guter Werkzeuge [S. 335] In meinem Musikregal steht heute noch der HiFi-Verstärker, dessen Service-Manual mich inspirierte einen anderen Ansatz für die IT-Dokumentation zu denken. Das Gerät wurde 1974 gebaut und betreibt immer noch die Lautsprecher in unserem Wohnzimmer. Ob sich noch eine Werkstatt finden lässt, die das Gerät bei einem Defekt reparieren kann? Nicht nötig! Ich habe ja das Service-Manual.
ÜBER DEN AUTOR Achim Grindler ist stellvertretender Abteilungsleiter der Abteilung IT-Security und Service-Management (ISM) am Steinbuch Centre for Computing des KIT. Seine Tätigkeitsschwerpunkte sind Kundenorientierung, Verbesserung und Standardisierung bestehender Arbeitsabläufe sowie die konsequente Unterstützung der SCC-Abteilungen bei den geplanten Veränderungsprozessen und die Konzeption, Bereitstellung und Schulung von ITSM-Werkzeugen. Er diplomierte an der "Hochschule Karlsruhe - Technik und Wirtschaft" im Fach Nachrichtentechnik und ist seit 1994 am KIT angestellt. Bis 2001 war er im In- und Ausland als Elektronik- und Softwareentwickler sowie als Inbetriebnahme-Ingenieur an Großforschungsprojekten beteiligt. Von 2002 bis 2007 leitete er für die zentralen Bürokommunikations- und Desktopdienste des Großforschungsbereichs, das Team "Systemsoftware und -hardware". Quellenangaben: [1] Walter Vogt, fit for benefit IT Services kundenorientiert planen und steuern, 2002, S. 56, Verlag: Perseo Consult AG [2] OGC, ITIL - Service Transition, 2007, S. 68, Verlag: TSO (The Stationery Office) [3] Simone Rudolph et al, Struktur von IT-Servicekatalogen: Ein praxisorientierter Gestaltungsvorschlag für die Dokumentation des IT-Leistungsangebots, MKWI 08 [4] Lothar Buhl, FCS Consulting, Abbildung von Services in der CMDB, Vortrag auf der PUG 2014 [5] Robert M. Pirsig, Zen und die Kunst ein Motorrad zu warten, 1974, S. 100-102, Verlag: Fischer Taschenbuch
MAKING SERVICE MANAGEMENT HAPPEN Garmischerstraße 4 80339 München Phone +49 89 54052 214 WENDIA GMBH DEUTSCHLAND Email: wendia@wendia.de Web: www.wendia.de Königstraße 26 70173 Stuttgart Phone +49 711 18567 412 WENDIA GMBH DEUTSCHLAND Email: wendia@wendia.de Web: www.wendia.de Baarerstraße 94 6300 Zug Phone +41 41 560 77 04 WENDIA AG SCHWEIZ Email: info@wendia.ch Web: www.wendia.ch