Gastbeitrag von Jochen Ott, IT Service Management Architect bei Microsoft Deutschland
Im letzten Beitrag konnten Sie meine Sicht zum Thema „Gemeinsam neue Services liefern“ finden. Wir haben die Bereiche People Change Management, DevOps und Modern Service Management gestreift und zusammen erkannt, dass traditionelle Bereiche in der IT-Organisation sich neu zusammenfinden müssen.
In Vorbereitung auf diesen fünften Beitrag, der Ihnen hier nun vorliegt, habe ich mit meinem Kollegen Martin Reincke, ebenfalls Service Management Architect, ein Gespräch geführt. Die zentralen Fragestellungen lauteten: Wie sieht die zukünftige Welt eines „Service Monitoring Service“ aus? Wird es nur noch ein Tool geben? Was müssen wir überhaupt in Zukunft überwachen? Was kommt aus anderen Bereichen (Daten-Analyse) hinzu?
Wie agierten wir im klassischen Service Management?
Die Notwendigkeit einen Prozess zu verbessern ist permanent gegeben – soweit so gut. Es ist allgemeiner Konsens, dass Prozesse nicht in Stein gemeißelt sein dürfen, sie müssen sich verändern können. Leider sehen wir beide viel zu oft bei Kunden, dass eine Veränderung häufig von den neuen Features eines (neuen) Tools abhängt. Aus der Einführung entsteht ein Projekt und plötzlich ist nicht mehr eine notwendige Änderung eines Prozesses im Fokus, sondern die Einführung eines neuen (ITSM) Tools. Dieses neue Tool wird Löcher stopfen. Es werden aber auch neue Baustellen an neuen Orten aufgemacht. Wieder verbringen viele Menschen sehr viel Zeit damit, dieses eine Super-Tool zu beschreiben, zu finden, dann doch anzupassen, zu implementieren und alle anderen Bereiche daran anzukoppeln. Um dann bei 80 Prozent Fortschritt und nach mehreren Jahren wieder von der Realität eingeholt zu werden und von vorne zu beginnen.
Nun stellen wir uns noch zusammen vor, dass für die Firma, für die wir tätig sind, die beiden Begriffe „Merger and Aquisition“ keine Fremdworte sind – wir haben dann das berühmte Fass ohne Boden vor uns. Was also tun? Martin Reincke beschreibt das so:
- Ignorieren der realen Welt und weiterhin an dem sicherlich richtigen Ziel festhalten, ein zentrales Tool haben zu wollen.
- Wir entsorgen diesen Gedanken – weil einfach nicht machbar – und konzentrieren uns darauf, die Ziele eines Prozesses zu erreichen, ohne auf ein Universal-Tool zu warten.
- Wer verwenden den MetaData-Ansatz und fokussieren darauf, die bei allen Prozessen gemeinsamen Ziele zu erreichen. Der Ansatz hier: Integration aller Beteiligten.
- Kombinieren von 1) und 3) indem wir ein zentrales Tool überall nur da befürworten, wo es wirklich Sinn macht und wir dann unsere Prozesse mit dem MetaData-Ansatz verbessern.
Wenn wir uns in Richtung Cloud bewegen, sollte der Weg in Richtung 4) gehen. Dieser Punkt unterstützt direkt das Konzept Entwickler Skills innerhalb von Service Management aufzubauen. Wenn wir mit Möglichkeit 1) erfolgreich sein wollen, muss Systemintegration, Data und Reporting ein Teil von Service Management werden.
Nachdem wir nun die Frage nach dem einen zentralen Tool beantwortet haben, möchten wir mit Ihnen an einer Stelle einmal tiefer eintauchen – Alert versus Incident.
Wie ich schon im letzten Beitrag erörtert habe, sind prozessorientierte Menschen und Tool-fokussierte Menschen nicht ausreichend vernetzt. Sie integrieren sich nicht gut. Das Ergebnis ist die Tatsache, dass Alerts und Incidents zwei völlig unterschiedlichen Welten zugeordnet werden.
Der erste Schritt in einem Incident Management-Prozess ist „Detection“ und wie schon vorher in dieser Serie diskutiert, muss die automatisierte Erfassung eines der Ziele sein. Automatisierte Erfassung von Ereignissen ist aber nichts anderes als das, was die andere Fraktion mit „Monitoring“ bezeichnet. Alerts sind also die Trigger für Incidents und Problems. Alerts sind dann konsequenterweise eine Vorstufe eines Incidents oder eines Problem Records.
Incident- und Problem-Management innerhalb von Modern Service Management muss also in Alerts und vor allem in die in einem Alert enthaltenen Daten schauen. Diese wertvolle Informationsquelle darf nicht länger nur in der Tool-Welt vorhanden sein.
Resümee: Es geht nicht darum ein einziges Tool zu haben, sondern eine integrierte Lösung mit allen Informationen, aus der die schon angesprochenen neuen und einfachen Analysemethoden, die passenden Informationen bereitstellen. Die Diskussion Monitoring Tool oder Incident Tool hilft uns nicht weiter. Genau hier sind wir beim „Service Monitoring Service“.
Im nächsten Beitrag erwartet Sie ein Blick in diesen „Service Monitoring Service“. Haben Sie schon einmal darüber nachgedacht, dass ein Incident mit einer hohen Dringlichkeit und hohem Impact Auslöser für eine automatisch erstellte Telefon-Konferenz ist? Ist die Krise da, muss niemand mehr nach den Einwahlinformationen fragen, die Telefonkonferenz ist einfach schon offen, automatisiert und vom Tool gesteuert.
Dieser Beitrag ist Teil einer mehrteiligen Artikelserie. Autor der Serie ist Jochen Ott, IT Service Management Architect bei Microsoft Deutschland.
Serie: Die Zukunft des IT Service Managements im Cloud-Zeitalter
- Teil 1: Einführung
- Teil 2: Modern Service Management 1
- Teil 3: Modern Service Management 2
- Teil 4: Gemeinsam neue Services liefern
- Teil 5: Wie könnte ein Service Management Service aussehen?