Konfigurationsmanagement ist eine der zentralen Disziplinen im IT-Service-Management (ITSM). Hier wird der Grundstein für eine sichere und wirtschaftliche Service-Steuerung gelegt. Kaum ein anderer ITSM-Prozess beeinflusst so viele Abhängigkeiten und zieht sich gleichermassen durch die letzten Winkel der IT-Organisation. Konfigurationsdaten werden nahezu überall in der IT benötigt und erzeugt und alle reden mit. Best Practices wie ITIL und die wichtigsten IT-Standards stellen hohe Anforderungen. Die Umsetzungsprojekte für Configuration Management weisen im Vergleich mit anderen Prozessen eine recht hohe Floprate auf.

Vom Bestandsmanagement zum Konfigurationsmanagement

In der Planung und Steuerung von Unternehmen ist integrierte Datenhaltung seit vielen Jahren mehr oder weniger Standard. Das Enterprise Resource Planning (ERP) hat den Wildwuchs der zahlreichen Insellösungen in den Unternehmensprozessen deutlich reduziert. Die Notwendigkeit, Unternehmensprozesse aufeinander abzustimmen und auf den Kunden auszurichten, hat diese Entwicklung getrieben. Obwohl die Verfahren im Betrieb von Anwendungen und Systemen selten individuell sind, hat die IT diesen Weg noch vor sich. Von integrierter Datenhaltung und gesteuerter Datenqualität sind die IT-Organisationen noch ein ganzes Stück entfernt. Die ITIL-Best-Practices bahnen hierfür den Weg. Diesen in den richtigen Schritten zu gehen, nimmt einem aber niemand ab. Um welche Ressourcen geht es in der IT? Im Minimum geht es zunächst einmal um die Bestände an IT-Betriebsmitteln. Das IT-Bestandsmanagement wurde bislang als Inventory und Asset Management sichergestellt. Unter Inventory Management werden die Verfahren zur Ermittlung und Verwaltung der Bestände an IT-Betriebsmitteln zusammengefasst. Hierzu werden überwiegend auch technische Merkmale von Komponenten mitgepflegt. Das Asset Management verwaltet die Betriebsmittel eher aus betriebswirtschaftlicher Sicht. Hier spielen eher Werte und Kosten eine Rolle. Dies betrifft also vor allem werthaltige Betriebsmittel – insbesondere Hardwarekomponenten und Softwarelizenzen, aber auch für die Entwicklung der IT-Kosten wesentliche Komponenten. In diesem Zusammenhang werden überwiegend auch Wartungsvereinbarungen für IT-Komponenten mitbetrachtet. Mit diesen traditionellen Verfahren allein lassen sich die Governance-Ziele service-orientierter IT-Organisationen nicht mehr erfüllen.

Dies hat mehrere wesentliche Gründe:
1.    Modularisierung: Mit der laufenden Standardisierung und Schichtentrennung werden zunehmend Plattformstrategien in der IT-Architektur umgesetzt. Damit nehmen die Abhängigkeiten in der IT-Infrastruktur zu. Wer die Qualität von IT-Services sichern will, muß diese Abhängigkeiten kennen und berücksichtigen.

2.    Dynamisierung: Dieser Trend beschleunigt sich derzeit noch durch Virtualisierungs- und Dienste-Konzepte im Anwendungsbetrieb. Dies betrifft einerseits den zunehmenden Betrieb logischer Serverumgebungen auf physikalischen Komponenten. Andererseits treiben auch service-orientierte Softwarearchitekturen (SOA) die Komplexität in den Abhängigkeiten der IT-Komponenten. Diese Abhängigkeiten sind mitunter nicht mehr statisch sichtbar und verändern sich dynamisch.

3.    Geschäftsausrichtung: Mit der Forderung nach Business-IT-Alignment hat sich die IT konsequent an den Geschäftsanforderungen des Unternehmens auszurichten. Hierfür ist entscheidend, neben den Abhängigkeiten in der Infrastruktur auch die Zusammenhänge von Geschäftsanforderungen, Service-Nutzung und Service-Inhalt zu kennen. Hierfür muß der Blick über den Tellerrand der Technologie hin zum Kunden, seine Geschäftsprozesse und die Einbindung in Wertschöpfungsketten erweitert werden. Hier geht es also zunehmend um logische Konfigurationselemente, die nicht mehr im Blickfeld der Inventarisierung sind.

4.    Service-Orientierung: Mit zunehmender Planung und Steuerung von Änderungen in der IT genügt es nicht mehr, den IST-Zustand zu ermitteln und zu dokumentieren. Verschiedene Service-Managementverfahren planen und dokumentieren vielmehr den Soll-Zustand. So ist  nicht jede Komponente und deren aktuelle Konfiguration wirklich gewollt. Den Soll-Zustand zu kennen ist beispielsweise wesentlich, um die Wiederherstellung von IT-Services im Notfall sicherzustellen, Konfigurationsstandards – etwa für gehärtete Systeme – überprüfen zu können oder die richtigen Entscheidungen über Nachlizenzierung oder Deinstallation bei festgestellter Unterlizenzierung von Softwarekomponenten treffen zu können.

Mit der Etablierung des Change Managements verlagern sich also die Anforderungen an die Dokumentation vom Ist-Zustand zum Soll-Zustand. Hieraus lassen sich zwei Anforderungen ableiten, die über Inventory und Asset Management hinausgehen:

A)    Informationen über die Abhängigkeiten und Konfigurationszusammenhänge zwischen IT-Komponenten müssen zusätzlich bereitgestellt werden.

B)    Neben den Informationen über den aktuellen Zustand der Komponenten ist vor allem auch der Soll-Zustand gemäß Konfigurationsanforderungen zu dokumentieren. Während ersteres zumindest für physikalische Komponenten überwiegend über Discovery-Verfahren ermittelbar ist, kann zweiteres nur über ein organisiertes Change Management sichergestellt werden.

Die ITIL-Best-Practices berücksichtigen dies, indem sie Change und Configuration Management als die zentralen Control-Prozesse im Sinne der Steuerung von IT-Änderungen ins Zentrum des ITSM-Prozessmodells stellen. Configuration Management liefert für nahezu alle ITSM-Prozesse die wesentliche Informationsgrundlage. Der Blickwinkel geht hier über Informationen über die Konfiguration von Systemressourcen hinaus und berücksichtigt auch die Service-Konfiguration. Es ist also nicht übertrieben, wenn man Configuration Management als eine zentrale Grundlage des Service-Managements versteht. Wenn Service Level Management das Herz der Service-Steuerung darstellt, so liefert Configuration Management das Rückgrat mit zentralem Nervensystem.
Configuration Management stellt sicher, dass

»    die service-relevanten Komponenten bekannt und identifizierbar sind,

»    deren wesentliche Eigenschaften korrekt dokumentiert sind

»    und diese den Service-Anforderungen entsprechen

Configuration Management ersetzt weder Invenory noch Asset Management. Verfahren zur Inventarisierung werden weiterhin benötigt, um regelmäßig den tatsächlichen Zustand der IT-Komponenten zu ermitteln, der zusätzlich auch in diversen Betriebsprozessen benötigt wird. Das Asset Management kann Konfigurationszusammenhänge nutzen und diese um betriebswirtschaftliche Sichten erweitern.

Chancen und Risiken

Eine wirtschaftliche und auf die Geschäftsanforderungen ausgerichtete IT benötigt vor allem interne Transparenz. Kunden, Services, IT-Leistungen, Systeme und deren Komponenten zu kennen und aufeinander abzustimmen, ist die wesentliche Herausforderung in der ITSM-Einführung. Die Anforderungen sind vergleichbar mit der Produktentwicklung sowie Planung und Steuerung der Leistungsprozesse im Kerngeschäft des Unternehmens. Service-Management ist das Instrument für die taktische und operative IT-Steuerung. Dies schließt auch das Business Alignment und die Steuerung externer Service-Partner mit ein. Configuration Management liefert die hierfür benötigten Informationen, organisiert die Umsetzung entsprechender Anforderungen, sorgt für wirtschaftliche Datenpflege und Konsolidierung der Toollandschaft, kontrolliert die Qualität der Konfigurationsdaten und macht die Qualität des Change Managements messbar. Effizienzsteigerungen sind vor allem in der Abwicklung der Prozesse im Support und Delivery Management sowie in den IT-Projekten zu erwarten. Gleichzeitig werden die meist unsichtbaren Aufwände für Datenpflege, -bereinigung, -beschaffung, -integration und -aufbereitung sowie die Kosten der meist gewachsenen Toollandschaft beeinflußt. Die Schließung von Informationslücken und das Datenqualitätsmanagement wirken sich zudem auf die Qualität der Leistungen im Betrieb und in der Service-Steuerung aus. Die Risiken liegen vor allem in der erfolgreichen Umsetzung des Prozesses. Darauf wird später näher eingegangen.

Herausforderung und die Anforderungen an das Configuration Management

Änderungen in Anforderungen, Services und Ressourcen bestimmen das Tagesgeschäft der IT. Trotz dieser Änderungen aktuelle und korrekte Konfigurationsdaten sicherzustellen, ist die entscheidende Herausforderung für den Configuration Manager. Aber ohne diese Verantwortung lässt sich die Konsistenz dieser Informationen kaum sicherstellen. Er führt die dezentral gesponnenen Fäden zusammen und bündelt das Wissen über Datenhaltung, Nutzung, Qualität und Tooleinsatz. So kann er die Effektivität und Effizienz im Umgang mit den Informationen beeinflussen. Was er benötigt, um dies zu erreichen, geben bereits ein ganze Reihe von Standards vor.
Die Implementation sollte sich an den Anforderungen orientieren, die der internationale Standard ISO 20000 für IT-Service Management definiert. Daneben liefert ISO 10007 branchenneutrale Anforderungen an ein Configuration Management. ISO 15504 liefert ein Reifegradmodell für Softwareentwicklungsprozesse, in dem auch die spezifischen Anforderungen an das Software Configuration Management definiert werden. EIA-649 ersetzt als US National Consensus Standard for Configuration Management die früheren Militärstandards (MIL-STD-973) durch industrielle Best Practices und liefert konkretere Anforderungen an die Umsetzung der Configuration Management-Verfahren. COBIT (Control Objectives for Information and related Technology) liefert mit dem IT-Governance-Framework auch Kontrollziele für das Configuration Management. An diesen orientiert sich u.a. die IT-Revision, wenn die Wirksamkeit geprüft wird. CMMI (Capability Maturity Model) liefert ein Reifegradmodell, das ursprünglich für die Softwareentwicklung entwickelt wurde und heute in verschiedenen Bereichen zur Bewertung des Prozessmanagements eingesetzt wird. Dieses kann auch als Grundlage für ein regelmäßiges Self Assessment der Configuration Management-Prozessreife eingesetzt werden.

Verfahren im Configuration Management

In der Konfigurationsplanung wird definiert, welche Elemente (Configuration Items, CI) der Kontrolle des Configuration Managements unterzogen werden und welche Rahmenbedingungen in der Configuration Management-Policy zu regeln sind. Hier werden zudem die Anforderungen an die CMDB gemanagt und die Massnahmen zur Entwicklung der Configuration Management-Verfahren geplant. Das Verfahren sollte auch die Wirksamkeitskontrolle und das laufende Prozessmanagement berücksichtigen. »    Die Identifizierung dient vor allem der Konkretisierung des CMDB-Modells. Hierzu werden die wesentlichen Konfigurationsinformationen je CI-Kategorie bestimmt und die Konfigurationsstrukturen ermittelt. Das Verfahren stellt auch sicher, dass die benötigten Konventionen für die Datenpflege abgestimmt sind. Dies betrifft etwa geregelte Namens-, Standort- und Versionsmodelle.»    Die Statusüberwachung stellt sicher, dass die laufende Pflege der Konfigurationsdaten organisiert wird, der Zugriff auf die CI-Informationen im benötigten Maße und geeigneter Form gewährleistet ist, der Zugriff entsprechend Sicherheitsanforderungen restriktiv geregelt ist und Änderungen an CI-Informationen verfolgbar sind. »    Konfigurationsaudits werden eingeführt, um Abweichungen der CI-Daten vom aktuellen IST-Zustand zu ermitteln und entsprechende Korrekturmassnahmen einzuleiten. Bei nachlässiger Datenpflege in korrekt durchgeführten Changes wird dies zur Nachdokumentation führen. Bei verdeckten und unautorisierten Changes wird dies zur Korrektur der Konfiguration entsprechend Soll-Zustand führen. Der Umfang solcher Abweichungen macht die Wirksamkeit des Change Managements transparent. Die Audits werden hierzu Daten aus Inventarisierungs- bzw. Discovery-Werkzeugen nutzen, wo dies möglich ist. Ansonsten wird der Zustand strichprobenartig ermittelt.»    Die Konfigurationskontrolle greift direkt im Change Management. Während die Audits reaktiv wirken, greift die Kontrolle hier proaktiv, um die Anforderungen an die Dokumentation der Konfigurationsdaten bereits im Änderungsprozess sicherzustellen und Changes zu erkennen, die nicht den Konfigurationsstandards entsprechen, wo solche definiert sind. Ein effizientes Configuration Management wird dieses Verfahren differenziert einsetzen. Sinnvoll ist es besonders für service-kritische CI mit Datenqualitätsproblemen. Wenn die Anforderungen überwiegend klar sind, warum scheitern dann so häufig die Implementationsprojekte? Zunächst muß man feststellen, dass die Prozessempfehlungen lediglich Ziele und grobe Umsetzungsmuster liefern. Für Umfang und Vorgehen in der Einführung wie auch für die geeigneten organisatorischen und technischen Lösungen wird man vergeblich nach pauschalen Empfehlungen suchen, wenn auch die hierfür wesentlichen Entscheidungskriterien gut übertragbar sind. Auf dem Weg liegen eine ganze Reihe Stolpersteine. Die in dem Kasten „Die häufigsten Umsetzungsfehler“ beschriebenen sollte man zumindest kennen.

Fazit

Hinsichtlich Abhängigkeiten und Auswirkungen in der IT-Organisation liefert das Configuration Management eine besondere Komplexität im Vergleich zu anderen ITSM-Prozessen. Dies erklärt das häufige Scheitern solcher Vorhaben. Schliesslich sind die bestehenden Strukturen über Jahre gewachsen, die Abhängigkeiten zunächst nicht transparent und die Betriebsverfahren selten standardisiert und dokumentiert. Die Umsetzungsprobleme im Projekt können aber i.d.R. schnell sichtbar gemacht und behandelt werden. Wenn die Implementation schleppend läuft, empfiehlt sich ein Projekt-Review, das schon mit geringem Aufwand den Handlungsbedarf sichtbar macht. Mit dem Wissen um die besonderen Umsetzungsrisiken und notwendige Voraussetzungen lässt sich aber auch bereits vor dem Projektstart die Erfolgschance spürbar beeinflussen. Wenn Sie Configuration Management organisieren, dann denken Sie in jedem Fall zunächst produkt- und herstellerunabhängig und stellen Sie die zu lösenden Probleme und die Einführung der Organisation in den Mittelpunkt.

Torsten Heinrich