Servicemanagement kein Selbstläufer
Auf die technische Basis kommt es an
Viele Unternehmen richten ihren Fokus verstärkt auf die Wertschöpfungsketten, die unmittelbaren Säulen ihres Geschäfts. Der Stellenwert der IT als nur mittelbarer Träger dieser Wertschöpfungsprozesse fällt entsprechend gering aus. Das Gros der Anbieter von Servicemanagementlösungen greift diesen Trend gern auf: So stehen ihre oft lückenhaften Architekturen nicht im Brennpunkt. Für Unternehmen ist diese Oberflächlichkeit aber eine gefährliche Botschaft.
Eine oberflächliche Vermarktungsweise kommt vielen Anbietern von Servicemanagementlösungen
recht. Sie ermöglicht ihnen, nicht nur technische Lücken zu kaschieren, sondern auch die hohe
Komplexität solcher Lösungen herunterzuspielen und sperrige IT-Management-Frameworks so gleich mit
vergessen zu machen. Dabei ist die Gesamtkonstruktion durch die Bausteine IT-Servicemanagement und
darauf aufbauend das Business-Management noch komplexer geworden. Bietet eine
Servicemanagementarchitektur nicht von Grund auf alle notwendigen Funktionen und Schnittstellen,
steht der Anwender nach dem Kauf trotz vollmundiger Marketing-Parolen wie Automation,
Vereinfachung, Produktivitätszuwächse und kräftigen Einsparungen bald im Regen. Denn die
propagierte enge Verzahnung von IT und Geschäftsprozessen stellt besonders hohe Ansprüche an die
technische Basis.
Teillösungen …
Zunächst gilt es, die Architektur der einzelnen Lösungsangebote zu bewerten. Reine
Servicemanagementsysteme sind auf die Zuarbeit der Grunddisziplinen angewiesen: auf die Verwaltung
des Netzwerks, der Server, Applikationen und Middleware sowie das Storage- und das
Telekommunikationsmanagement. Ein Unternehmen kommt mit diesem Ansatz nicht umhin, eine
Gesamtlösung aus Plattformen unterschiedlicher Hersteller zusammenzusetzen. Das steigert die
Komplexität der Lösung sowie den Integrations- und später den Betriebsaufwand – zumal die einzelnen
Plattformen nicht von vornherein aufeinander abgestimmt sind. Auch IT-domänenübergreifende
Korrelationen, wie sie zur Fehlerverfolgung und -isolierung entlang der Geschäftsprozesse dringend
notwendig sind, lassen sich bei einem fragmentierten Lösungsansatz mit vielen separaten Datenbanken
nur schwer vornehmen.
Offerten aus der Netzwerkmanagementecke haben mit den gleichen Nachteilen zu kämpfen: Auch sie
sind auf die Ergänzung durch andere Plattformen angewiesen, um als Komplettlösung für das
Servicemanagement gelten zu können.
… versus Komplettlösungen
Anbieter von Servicemanagement-Komplettlösungen bieten weit bessere Perspektiven. Die für die
Lösungskonzeption erforderlichen Bausteine anderer Hersteller sind hier von Haus aus integriert.
Mit Blick auf ein Ende-zu-Ende-Servicemanagement sind sie auf das Zusammenspiel von Werkzeugen und
Schnittstellen abgestimmt. Die Gesamtkonstruktion ist dadurch weniger komplex, der Integrations-
und Betriebsaufwand fällt geringer aus.
Bei einigen Herstellern treffen Interessenten allerdings auch hier auf Einschränkungen: Teils
setzt sich die Gesamtarchitektur aus so genannten Building Blocks mit jeweils separater Datenbank
für die Alarmmeldungen zusammen. Das erschwert die Fehlerverfolgung und -isolierung unnötig oder
kompliziert sie zumindest durch Transformationsprozesse zwischen den Datenbanken. Eine zentrale
Datenbank mit einem einheitlichen Objektformat für alle eingehenden Alarme ist eindeutig die
bessere Lösung.
Die Achillesferse vieler Anbieter vermeintlicher Komplettlösungen ist zudem ihre mangelnde
Präsenz innerhalb der Domäne des Telekommunikationsmanagements. Das erschwert dem Unternehmen die
Aufgabe, seine Servicemanagementlösung in Einklang mit der seines Service-Providers zu bringen –
mit durchgehenden Ende-zu-Ende-SLAs, die diesen Namen verdienen.
Integrationsbreite gefragt
Ein Unternehmen kann nur dann auf ein lückenloses Servicemanagement bauen, wenn es alle
installierten und geplanten IT-Systeme einbeziehen kann. Diese Herausforderung ist nicht einfach zu
meistern, denn das Systemumfeld der meisten Unternehmen ist äußerst heterogen ausgeprägt. Deshalb
muss ein Servicemanagementanbieter ein breites Spektrum von Integrationsagenten vorhalten und eine
Vielzahl an Protokollen und Schnittstellen unterstützen. Über sie fließen die Messergebnisse aus
den zu überwachenden Systemen innerhalb der IT-Domänen Netzwerk, Server, Applikationen und
Middleware, Speichersysteme und Telekommunikation idealerweise in eine zentrale Datenbank ein. Dazu
sollte das System an Protokollen und Schnittstellen TL1 (Transaction Language), MML (Man Machine
Language), Syslog, Applikations-Logs, SNMP (Simple Network Management Protocol), Corba (Common
Object Request Broker Architecture), XML (Extensible Markup Language), C++ und Java
unterstützen.
So genannte generische SNMP-Module ermöglichen es zudem, proprietäre Systeme mit ihren Private
MIBs (Management Information Bases) einzubeziehen. Verbleibende offene Integrationsschnittstellen
sollten zumindest über Element-Managementsysteme anderer Hersteller wie Ciscoworks, BMC Patrol, CA
Unicenter, IBM/Tivoli Enterprise, Microsoft Operations Manager (MOM) oder Remedy Gateway ausgefüllt
sein. Zudem sollten Entscheider die Alarmweiterleitung im Blick behalten: Sie muss offen gestaltet
sein und für Geschäftspartnerschaften via Internet mit den beim Partner installierten
Servicemanagementlösungen funktionieren.
Ereignismessung
Auch beim Messen der Ereignisse, die via Integrationsagent aus den IT-Systemen gemeldet werden,
heißt es: aufgepasst! Ein breites Angebot vorgefertigter Templates für die unterschiedlichen
Zielsysteme ist Pflicht. Denn solche Templates muss ein Unternehmen nur noch geringfügig an den
Messeinsatz anpassen. Das verkürzt die Implementierungszeit und senkt den Konfigurationsaufwand im
laufenden Betrieb. Leistungsfähige Lösungen bringen es auf mehrere hundert solcher vorgefertigter
Messschablonen, die dem Systemverantwortlichen das Leben erleichtern.
Für verbleibende Zielsystemlücken sind weitere Messvorlagen gefordert. Sie sollten per Skript-
und XML-Definition erstellbar sein. Allerdings muss der Systemverantwortliche bei beiden Verfahren
das Gewünschte von Grund auf definieren. Das verdeutlicht, wie wichtig ein breites Angebot an
Templates ist. Für die Verdichtung der Ereignisse zu Alarmen sind Mapping-Dateien gefragt. Ihre
Anzahl ist ein wichtiges Kriterium, um an der zentralen Konsole einer Ereignisflut vorzubeugen und
möglichst nur fehlerträchtige Ereignisse in die zentrale Datenbank zur Weiterverarbeitung
aufzunehmen. Leistungsfähige Lösungen halten dazu tausende solcher Mapping-Dateien vor.
Alarmkorrelation
Die Angebotsbreite entscheidet mit über die Qualität der Alarmkorrelationen für die
Problemrecherche. Eine zentrale Datenbank, in der alle Alarme im gleichen Objektformat abgelegt
sind, ist ein Qualitätsfaktor für professionelle, domänenübergreifende Korrelationen. Eine
Korrelations-Engine sollte in drei Stufen greifen: Modellierungstechnik, Event-Management und
Zustandskorrelation (Condition Correlation).
Die Modellierungstechnik isoliert und analysiert Fehlerursachen und unterdrückt symptomatische
Alarme. Im Idealfall geschieht dies automatisch. Der Event-Manager korreliert Alarme aus
unterschiedlichen IT-Domänen. Dazu muss es möglich sein, ohne großen Aufwand Regeln zur
Qualifizierung von Alarmen und zur Alarmbehandlung zu hinterlegen sowie Ereignismuster und mögliche
Ursachen zuzuordnen. Parallel muss der Event-Manager für ein komplettes Fehlerbild die Alarme der
Syslog- und Applikations-Log-Dateien berücksichtigen, so unter anderem Werte zum
Antwortzeitverhalten von PCs und Servern. Die Condition-Correlation-Technik kommt komplexen,
atypischen Fehlerkonstellationen auf die Spur: Sie setzt Alarme von Systemen, IT-Services und
Prozessen, die nicht in unmittelbarem Zusammenhang stehen, in Beziehung.
In dieser Form strukturiert, identifiziert eine Korrelations-Engine in der Praxis über 90
Prozent der Fehlerursachen. Der gestaffelte Durchlauf eröffnet in der ersten und zweiten Instanz
besonders schnelle Problemreaktionen. Die Korrelationshierarchie verdeutlicht Fehlertrends im Netz
eher. So kann eine IT-Abteilung frühzeitig (proaktiv) aufkommenden IT- und damit Prozessproblemen
entgegenzusteuern.
Echtzeit-Reporting
Die Herausforderungen, vor denen Reporting in Echtzeit steht, sind vielfältig. An erster Stelle
steht Business Service Intelligence (BSI), also die Anforderung, Störungen innerhalb der IT auf
ihre Auswirkungen auf die Geschäftsprozesse abzubilden. Die Ergebnisse gilt es auf der Konsole des
IT-Serviceverantwortlichen ad hoc als konkrete betriebswirtschaftliche Kenngrößen wie Kosten,
Produktivitätsverlust und betroffene Kunden einzublenden. Die Methodik bildet nicht nur die
Voraussetzung dafür, IT-Probleme zu priorisieren und nach ihrem Stellenwert für das Geschäft
anzugehen. Der Überblick an der IT-Servicekonsole ermöglicht zudem, IT-Ressourcen effizienter
zuzuweisen und damit Kosten sparender auszuschöpfen.
Ein so genanntes Relationship Mapping sorgt für die Verbindung zwischen IT-Ressourcen und
Wertschöpfungsketten: Es schließt automatisch von Alarmkonstellationen auf deren Auswirkungen auf
die Geschäftsprozesse und die daran beteiligten Gruppen – intern wie extern bei Geschäftspartnern
und im Kundenkreis. Entsprechend sollten möglichst viele solcher Relationship-Mapping-Dateien
hinterlegbar sein, um für schnelle gezielte Reaktionen auf Prozessebene so wenig Kenntnislücken wie
möglich bestehen zu lassen.
Der Servicemanager benötigt die Echtzeit-Reporting-Fähigkeit auch für langfristige
Betrachtungen: Er erhält auf Tastendruck die Auswertung bis zum aktuellen Zeitpunkt, also ohne
Aktualitätsverlust. Auf dieser Informationsbasis gewinnen Trendanalysen an Genauigkeit. Daneben
erlaubt ein echtzeitfähiges Reporting-System, Momentaufnahmen zum Geschäftssystem oder ausgewählten
Teilen abrufen. Entwicklungstrends im Geschäftssystem treten so plastischer vor Augen,
beispielsweise um zum richtigen Zeitpunkt Systemerweiterungen anzusetzen. Aktuelle Auswertungen und
gezielte Momentaufnahmen dienen zudem als wertvolle Zusatzinformationen zur Auflösung besonders
schwieriger Fehlerkonstellationen. Auch Revisoren und Controller profitieren von solchen
Echtzeitdaten. Deren Aktualität an Telekommunikationsschnittstellen ist gar nicht hoch genug
anzusetzen, um hier die Einhaltung der SLAs durch den Service-Provider permanent im Blick zu
behalten: Allein in der Echtzeit-SLA-Verfolgung inklusive fortlaufender Dokumentation steckt ein
erhebliches Einsparungspotenzial. Bei Nichteinhaltung von SLAs können sie schnell und beweiskräftig
Strafzahlungen beim Dienstleister einfordern.
Servicemanagement ist kein Selbstläufer – auch wenn viele Anbieter das gern glauben machen
wollen. Optimierbar sind Wertschöpfungsprozesse am besten immer noch dadurch, dass man sie
durchgehend mit möglichst wenigen manuellen Eingriffen gestaltet. Erst dann kommen die Vorteile des
Servicemanagements voll zum Tragen.
Lesen Sie mehr zum Thema
