Erfolgsfaktoren für BSM

Business-Service-Management ist in ITILv3 (IT Infrastructure Library Version 3) definiert als „ the ongoing practice of governing, monitoring, and reporting on IT and the business service it impacts“ (die laufende Ausübung der Steuerung, Überwachung und des Reportings von IT und des Geschäfts-Services, den sie beeinflusst). Damit geht die im Mai 2007 veröffentlichte Version deutlich über die Best Practices von ITILv2 hinaus, die die operativen IT-Service-Management-Prozesse beschreiben und damit in der IT-Welt verhaftet bleiben.
BSM-Wegbereiter ITIL
Der Perspektivwechsel hin zu einem Monitoring aus der Geschäftsprozesssicht ist das wesentlich Neue, das ITILv3 über das so genannte „Service-Lifecycle-Management“ adressiert. Die Autoren des Rahmenwerks rücken damit die Phasen im Lebenszyklus eines Services in den Mittelpunkt. Ein IT-Service wird nun als Vermögenswert (Asset) betrachtet. Dabei unterscheidet ITIL die Nützlichkeit eines Services (Utility) von der erforderlichen Qualität und Zuverlässigkeit (Warranty). Erst die Kombination beider Aspekte bringt den erforderlichen Mehrwert.
Die Trennung der Prozesse nach einzelnen Funktionen war in der praktischen Umsetzung nicht immer hilfreich, da die Wechselwirkungen unterschiedlicher Themen zu wenig Berücksichtigung fanden. Doch der integrative Ansatz entlang einzelner Prozesse bietet nun einen ganzheitlichen Blick und überwindet vorhandene Silo-strukturen – zumindest theoretisch. Denn die Praxis in den Unternehmen hält derzeit noch nicht Schritt: Zwar hat ein Großteil der Firmen inzwischen das Prozess-Framework von ITILv2 zumindest punktuell umgesetzt, aber die Durchdringung von ITILv3 verläuft schleppend. Erst gut 20 Prozent beschäftigen sich derzeit mit diesem Thema.
CMDB als Wissenszentrum für BSM
Im Mittelpunkt aller BSM-Initiativen steht in der Regel eine Strategie für das Konfiguratons-Management mit dem Ziel, Informationsinseln zusammenzuführen und alle benötigten Service-Strukturen und -Komponenten in einer oder mehreren CMDBs (Configuration Management Database) abzubilden. Da es in der Regel verschiedene Datenpools gibt, zum Beispiel für die Netzinfrastruktur, die Server-Landschaft oder SAN (Storage Aerea Network), ist es ein pragmatischer Ansatz, mit einem CMDB-Metadatenmodell zu arbeiten. Dieses kann auch eine proprietäre CMDB enthalten. Eine BSM-Lösung sollte in einem Federated-CMDB-Ansatz vielfache Quellen zusammenfassen und übergreifende Beziehungen darstellen können.
Neben den Daten zu IT-Komponenten und ihren Verbindungen birgt die CMDB idealerweise das komplette Know-how der IT, also auch Erfahrungsberichte, Skills, Verträge, Known Errors, Dokumente zum Anwenderverhalten etc. Allerdings sollten Verantwortliche nur so viel CMDB planen, wie für ihr BSM-Projekt auch nötig ist. Andernfalls besteht die Gefahr, sich in Details zu verlieren, die ohne großen Aufwand nicht mehr zu bewältigen sind. Denn Voraussetzung für den erfolgreichen Einsatz ist eine hohe Aktualität und Vollständigkeit der Daten.
Konzentriert man sich auf eine erste Teilaufgabe, kann das Erfassen von IT-Services und -Komponenten zunächst in einem überschaubaren Bereich, also zum Beispiel für einen bestimmten Kunden, einen Standort oder auch hardwarebezogen erfolgen. In der Praxis hat es sich jedoch bewährt, zunächst einen ausgewählten Geschäftsprozess abzubilden und nach einer Analyse alle hierfür relevanten Services wie Server, Netzwerke, Leitungen und Endgeräte in ihren Wechselwirkungen zu erfassen. Alle Informationen, die diesen Service direkt beschreiben und bei einem Ausfall Auswirkungen auf den Betrieb haben, werden so dokumentiert. Der Geschäftsprozess sollte auch eine gewisse Außenwirkung haben, sodass die IT Quick Wins vermarkten kann.
Eine CMDB allein bringt keinen Mehrwert, beeinflusst aber durch ihre Querschnittsfunktion alle anderen BSM-Themen. Sie ist die Grundlage aller Service-Management-Prozesse und wird aus diesen auch gepflegt. Erst mit der Unterstützung durch integrierte Prozesse wie beispielsweise Change, Release- oder Software-Asset-Management (Lizenz-Management) entsteht auf der Basis aktueller Daten die notwendige Effizienz und Effektivität.
Automatisches Dependency Mapping
Oft beinhaltet eine CMDB über 100.000 Configuration Items, manchmal ein Mehrfaches davon. Die Komplexität der IT-Infrastruktur in größeren Unternehmen hat stark zugenommen, ebenso die Häufigkeit von Change Incidents. Dies stellt hohe Anforderungen an die Qualität und Aktualität der Daten. Eingelesene technische Informationen allein bringen in der Praxis keinen Mehrwert. Mit einer gut gepflegten CMDB hingegen lassen sich Schwachstellen einer Komponente und ihre Auswirkungen auf betroffene Anwendungen, Geschäftsprozesse und Kunden darstellen. Verantwortliche können damit antizipieren, welche Risiken zum Beispiel eine geplante Konfigurationsänderung birgt.
Eine manuelle Pflege solcher Datenvolumina ist nicht sinnvoll realisierbar. Allein für das Update einer bereits gefüllten CMDB inklusive dynamisch angepasster Verknüpfungen sind erfahrungsgemäß 250 bis 500 Stunden zu veranschlagen. Werkzeuge für Automatic Dependency Mapping benötigen dafür nur wenige Minuten und verkürzen so den Aufwand für die Datenpflege um bis zu 99 Prozent.
Die Überführung der Daten in die CMDB erfolgt dabei durch einen dedizierten Pflegeprozess. Ab einer kritischen Datenmenge lassen sich Lücken innerhalb der CMDB nur durch eine automatische Lieferung von Echtzeitdaten schließen, um die End-to-End-(E2E-)Darstellung der Zusammenhänge von den einzelnen Komponente über die Anwendungen bis zum Geschäftsprozess umzusetzen.
Eine lückenlose Überwachung geschäftskritischer Prozesse hinsichtlich Verfügbarkeit, Antwortzeiten etc. umfasst zunächst das Monitoring sämtlicher technischen Komponenten aus Sicht der IT. Typische Metriken und Key Performance Indicators (KPIs) sind zum Beispiel:
systemspezifische Informationen wie CPU-Auslastung, Speicherbelegung etc.,
prozessspezifische Informationen wie zum Beispiel Prozessverfügbarkeit sowie
applikationsspezifische Informationen wie Antwortzeiten, Durchsatz etc.
Verantwortliche müssen allerdings nicht nur Segment- oder Server-Auslastungen, Rahmengrößen oder Ping-Antwortzeiten kennen, sondern auch die Situation des Nutzers berücksichtigen. Die Überwachung dieser Zusammenhänge wird als E2E-Monitoring im Sinne des Anwenders verstanden. Denn zwischen dem zur Verfügung gestellten Service und der Kundenerfahrung bei dessen Nutzung liegt oft ein weiter Weg.
Anwender haben in der Praxis oft mit Problemen zu kämpfen, selbst wenn die Informationen über das Systemverhalten und den Ressourcenverbrauch keine kritische Situation erkennen lassen. Zum Beispiel ist der angeforderte Online-Dienst nicht sofort verfügbar, eine Ressource kann nicht gefunden werden, ein Download dauert extrem lange oder bricht ab. Bei Applikationen, die im Outsourcing betrieben werden, ist es sowohl für den Betreiber als auch für den Auftraggeber sehr wichtig zu verifizieren, ob die in SLAs (Service Level Agreements) vereinbarten Betriebs- und Antwortzeiten eingehalten werden. E2E-Monitoring ist vor allem für IT-Provider ein unverzichtbares Werkzeug zur laufenden Überwachung und Analyse der Qualität bereitgestellter Services.
Überwachung der Service-Kette
Dies erfordert, für die komplette Service-Kette vom Server bis zur Kundenapplikation Messpunkte, Schwellenwerte und Eskalationsbeschrei-bungen zu definieren, an denen sich die vereinbarten SLAs orientieren. Standardisierte Messmethoden gewährleisten dabei die Wiederholbarkeit von Messungen zu gleichen Bedingungen, um realistische Aussagen zu Qualitätsverbesserungen treffen zu können. Die Unterstützung der eingesetzten Werkzeuge zur raschen Lokalisierung eines Problems verlangt Funktionen wie beispielsweise Root Cause Analysis (Fehlerermittlung), Impact Analysis (Auswirkungsanalyse) oder Drill-down. Letzteres erlaubt dem Administrator den direkten Durchgriff vom betroffenen Business-Service über Teiltransaktionen bis hin zu einzelnen Komponenten.
Um IT-Services bedarfsgerecht und effizient zu erbringen, bedarf es einer systematischen Strukturierung des IT-Leistungsangebotes. Aufbau und Pflege eines standardisierten Service-Katalogs gestalten sich allerdings in der Praxis sehr schwierig. Entscheidend ist, dass die Services gemeinsam mit dem Kunden und aus Kundensicht beschrieben sind. Vor allem für die Nutzer ist der IT-Service-Katalog ein ideales Instrument.
Die Umformung der oft über 300 verschiedenen technischen Leistungsarten in Geschäftsprodukte ist der komplexeste Schritt. Es gilt, eine Vielzahl von Ressourcen und Leistungen zu berücksichtigen und über eine Maßeinheit, beispielsweise einen Standard-Office-Arbeitsplatz, zu verrechnen. Die Beschreibung eines entsprechenden IT-Services enthält differenziert die enthaltenen Leistungen, die Verrechnungseinheit und den Preis pro Einheit, technische Voraussetzungen (zum Beispiel bestimmte Hardware) und Bedingungen (zum Beispiel Mindestlaufzeiten) oder auch explizit den Ausschluss bestimmter Leistungen. Typische Leistungsgegenstände für SLAs sind Themen wie Systemverfügbarkeit, Reaktionszeiten, Ausfallsicherheit oder das Vorhalten von Server-Ressourcen.
So kostet ein Premium-Arbeitsplatz mit einem größeren Bildschirm, mehr Rechnerkapazitäten, einem zusätzlichen Softwarepaket zur Bildbearbeitung und einer 724 Hotline schnell das Mehrfache eines Standardarbeitsplatzes. Kostentransparenz und Verständlichkeit mittels eines IT-Servicekatalogs sind die Voraussetzung für die Akzeptanz einer kundenorientierten, verursachergerechten Leistungsverrechnung sowie effektiven Planung.
Angesichts der Komplexität des Themas lässt sich ein BSM-Modell praktisch nur in Einzelschritten umsetzen, die allerdings in eine Gesamtstrategie eingebettet sein müssen. Unternehmen benötigen viele Zwischenetappen. Das Analystenhaus Forrester rechnet mit mindestens vier Jahren. Aber der Weg ist das Ziel, und das Ziel lohnt.

Dr. Thomas Gerick ist verantwortlich für die Unternehmenskommunikation bei USU in Möglingen.