Das sollte ein SLM-Tool können

Zum Abschluss der Beitragsreihe zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“ möchte ich noch auf das Anforderungsprofil für ein Service-Level-Management-(SLM-) Tool eingehen und Ihnen einen kurzen Marktüberblick – natürlich ohne Anspruch auf Vollständigkeit – vermitteln.

Zentrale Anforderung: Sammeln und Auswerten der definierten Metriken

Auf die Bedeutung von Kennzahlen und Metriken bin ich ja bereits im zweiten Beitrag der Beitragsserie eingegangen. Da in der Praxis die Anzahl und Vielzahl von Metriken schnell steigt, ist eine Software-Lösung erforderlich, die dieses Volumen auch bewältigt, d.h. automatisiert sammelt und auswertet.  Konkret bedeutet dies, dass die Metriken auf eine geeignete Art und Weise abgebildet und dann den definierten IT-Services zugeordnet werden. Um dann den Erfüllungsgrad der Service Level auswerten zu können, müssen Messpunkte der Services mit einem Messkonzept zuverlässig überwacht werden.

In meiner Arbeit habe ich versucht, eine Anforderungssammlung zu erstellen, die die Notwendigkeit eines integrierten Gesamtsystems verdeutlicht. An dieser Stelle nochmals herzlichen Dank an meine Kollegen bei amasol, die mir beim Erstellen des Anforderungskatalogs geholfen haben.

Als Grobschema wurden die folgenden Anforderungskategorien definiert:

  • Definition der SLM-Objekte
  • Servicekatalog und Leitungsstrukturen
  • Management von SLAs
  • Management von Dienstlieferanten
  • Management der Dienstqualität
  • Schnittstellen zu Prozessen und Datenquellen
  • Grundsätzliches Verwenden des Tools
  • Tool-Hersteller

Die einzelnen Kategorien wurden dann mit drei Prioritätsstufen gewichtet:

  • Prioritätsstufe 1: essenziell
  • Prioritätsstufe 2: erforderlich
  • Prioritätsstufe 3: optional

Die Darstellung des kompletten Anforderungskatalogs würde den Umfang dieses Beitrags sprengen, ich kann ihn aber bei Interesse gerne auf Anfrage zur Verfügung stellen.

Marktüberblick: Sammeln und Überwachen vs. Verarbeiten

Betrachtet man derzeit den Markt für SLM-Softwarelösungen, so muss generell zwischen Lösungen zum Sammeln und Überwachen der Metriken und Lösungen, die diese Metriken auch verarbeiten, unterschieden werden. Zum Messen der Applikations-Performance bietet der Markt eine Vielzahl von Produkten. Der „Peer Insights“ von Gartner in der Kategorie APM enthält allein ungefähr 25 Produkte.

Die Software-Lösungen sind dabei häufig in unterschiedliche Pakete unterteilt, die jeweils nur eine bestimmte Funktionalität abdecken. Darüber hinaus setzen die Hersteller auf verschiedene Messmethoden und -technologien. Um aber eine Gesamtlösung zu erhalten, müssen diese Einzelprodukte zu einem „Bundle“ zusammengefasst werden. Problem in der Praxis: Häufig arbeiten die Programme nur mit Systemen des gleichen Herstellers zusammen.

Auch für die Auswertung der erfassten Metriken gibt es auf dem Markt mittlerweile eine ganze Reihe von Lösungen.  Diese werden in der Regel unter der Kategorie IT-Servicemanagement (ITSM) geführt, ein direkter Vergleich dieser Lösungen istallerdings häufig nicht möglich. Der Grund: Die Lösungen sind aus einer Kombination aus Hard- und Softwareverwaltungsprogramme sowie Help-Desk-Tools entstanden und damit kaum vergleichbar. Darüber hinaus wird die Definition, was ITSM genau ist, von sehr differenzierten Begriffserklärungen und Sichtweisen beeinflusst.

Deshalb mein Tipp: Eine spezifische Marktevaluierung sollte immer auf der Grundlage eines individuellen Anwendungsfalles erfolgen.

Das SLM-Toolset der amasol AG

Als naheliegenden Anwendungsfall aus der Praxis möchte ich zum Abschluss kurz zwei SLM-Lösungen vorstellen, die bei der amasol AG im Portfolio sind und für meine Arbeit zu Einsatz kamen:

Dynatrace Managed diente als Monitoring- Lösung und zeichnete Messdaten der amasol -Anwenderaktionen durch Real User Monitoring auf. Zusätzlich wurden auch synthetische Messwerte von externen Messstationen des Herstellers einbezogen. So konnte ich die Kennzahlen „optische Vollständigkeit“ und „Verfügbarkeit“ eines amsaol-internen Service messen.

Apptio Digital Fuel ITBM wurde für die Abbildung der Metriken verwendet. Die Messdaten aus Dynatrace wurden über eine Schnittstelle an ITBM angebunden und anschließend systematisch verarbeitet und aufbereitet. Damit wurde exemplarisch die SLA-Tauglichkeit der Metriken nachgewiesen.

Falls Sie Fragen zu den hier vorgestellten Produkten haben oder weitere Informationen benötigen, stehen Ihnen meine Kollegen jederzeit gerne zur Verfügung.

Damit endet die Beitragsserie zu meiner Bachelorarbeit „Definition und Umsetzung von Service-Level-Metriken für die Applikations-Performance aus Endanwendersicht“. Ich hoffe, ich konnte Ihnen einige interessante Denkanstöße zum Thema Service Level Management vermitteln.

Wenn Sie sich mit mir über die Inhalte meiner Arbeit oder das Thema Service Level Management austauschen möchten, erreichen Sie mich unter dominik.hecker(at)amasol.de.

Dominik Hecker ist als Senior Consultant im Technology Business Management (TBM) Team von amasol tätig. Er beschäftigt sich dort schwerpunktmäßig mit ServiceNow-Projektmanagement sowie DigitalFuel-Beratung und -Implementierung im IT-Financial-Umfeld. Außerdem arbeitet er an API-Integrationen bestehender Lösungen (GraphQL, API) sowie Low-Code-Entwicklung von Add-Ons für bestehende System (Oracle Apex)

Nach der Berufsausbildung zum Fachinformatiker arbeitete Dominik zwei Jahre als IT Systems Engineer in IT-Projekten auf der ganzen Welt (IT-Dienstleister Goethe Institut).

Bereits während seines Studiums der Wirtschaftsinformatik arbeitete er als IT-Admin bei amasol und stieg dort dann 2018 als Consultant im TBM-Team ein. Der Titel seiner Bachelorarbeit lautet: „Service Level Management als Grundlage für den Leistungsnachweis von IT-Services."

Privat liebt Dominik Hunde, elektronische Musik und Schlauchbootfahren auf Flüssen (Rafting).

Autor:
Dominik Hecker