Warum Monitoring nicht gleich Monitoring ist – eine Erfolgsgeschichte

Monitoring. An sich nichts Neues. Jeder kennt es, jeder braucht es, fast jeder hat es. Beim Stichwort «Monitoring» denkt man zu aller erst an die Überwachung von Systemen, Datenbanken und Hosts sowie diversen Infrastrukturkomponenten. Eigentlich könnten wir auch schon wieder unseren Blog beenden. Warum sollten Sie nun weiterlesen, wenn Sie das alles ja schon kennen?

Hier die Antwort: Darum. Darum, weil ein professionelles Monitoring viel mehr ist als nur die technische Überwachung von Systemen. Darum, weil es nicht ausreichend ist bunte Ampeln zu bestaunen und reaktiv einzelne Alarme abzuarbeiten. Darum, weil Sie unter Umständen auch der Revision oder internen Kunden gegenüber zur Nachhaltigkeit und Nachvollziehbarkeit verpflichtet sind. Darum, … okay, genug jetzt.

Die letzten Monate haben wir unsere Kundin, ein Industrieunternehmen einer Industrie- und Grosshandels Gruppe, bei der Einführung und Weiterentwicklung einer Monitoring Lösung auf Basis des SAP Solution Manager 7.2 begleitet und in enger Abstimmung mit den Verantwortlichen aus den Bereichen Support und SAP Basis die Lösung optimiert und finalisiert. In den folgenden Absätzen werden wir in unverfälschter Weise die «Findings» und «Learnings» aus Sicht unserer Kundin wiedergeben und um zusätzliche Informationen ergänzen.

Zu Beginn des Projekts stand die einzusetzende Lösung, der SAP Solution Manager 7.2, bereits fest, da dieser schon in diversen anderen Bereichen eingesetzt wurde und bekannterweise die Anforderungen an ein Monitoring von SAP Systemen erfüllte. Knowhow im Bereich Monitoring war bei unserer Kundin generell vorhanden, jedoch wurde Unterstützung für den Aufbau, die Einführung sowie die die Weiterentwicklung der Monitoring Lösung gewünscht.

Schritt 1: Grundlagen

Der erste Schritt bestand in der Auswahl benötigter Metriken (Monitoring Daten), der Anpassung von Schwellwerten (gelb / rot) für eine optionale Alarmierung sowie der Auswahl der gewünschten Alarme selbst. Es wurde beschlossen mehr Daten zu sammeln als zu alarmieren um nachträgliche Analysen zu ermöglichen aber auch um das Alarmaufkommen in einem machbaren Rahmen zu halten. Im Fokus steht die Aufrechterhaltung eines stabilen Systembetriebs mit einer begrenzten Anzahl an personellen Ressourcen. Stand 13.03.2020 gibt es bei unserer Kundin 40 verschiedene Alarme:

Schritt 2: Alert Inbox

Der Solution Manager bietet zur Bearbeitung von Alarmen zwei wesentliche Tools: Die Alert Inbox und die Bearbeitung von Alarmen anhand von Tickets (Störungen) im Rahmen der IT-Servicemanagement Funktionalitäten. Da die Bearbeitung von Störungen durch eine aktive Alarmierung «Neuland» für unsere Kundin war und nach der Aktivierung des Monitoring mit einem zu hohen Alarmaufkommen durch nicht optimal konfigurierte Schwellwerte gerechnet werden musste, wurde die Verwendung der Alert Inbox beschlossen und längerfristig die Verwendung von Tickets empfohlen. Das oberste Ziel war, dass die Support und Basis Mitarbeiter im Falle einer Störung vom System aktiv informiert werden und sonst für andere Arbeiten zur Verfügung stehen. Regelmässige, manuelle Systemprüfungen sollten nicht mehr durchgeführt werden müssen. Vor der Übergabe der Alert Inbox an unsere Kundin wurden die Alarme zuerst von uns bearbeitet und erste Optimierungen der Schwellwerte vorgenommen. Anschliessend folgte die Schulung der Mitarbeiter sowie die Übergabe mit fortlaufender Unterstützung unsererseits zum Aufbau von Knowhow auf Kundenseite.

Die Bearbeitung von Alarmen über die Alert Inbox war generell möglich und technisch einwandfrei, hatte jedoch vor allem in Hinblick auf die Prozessierung durch mehrere Support Mitarbeiter sowie die Störungsdokumentation bei unserer Kundin einen mittelprächtigen Eindruck hinterlassen. Die negativen Punkte:

Unübersichtlich

Unstrukturiert

Keine Kontrolle

Keine Dokumentation

Schritt 3: Monitoring mit Tickets

Aufgrund der wachsenden Routine der Support Mitarbeiter sowie der steigenden Anforderung des Business in Hinblick auf Auswertungsmöglichkeiten und Revisionssicherheit wurde die zuvor geplante Verwendung von Incidents im Alarmfall beschlossen. Zukünftig sollten Alarme (gelb / rot) ein Ticket erzeugen und die Bearbeitung dieser über die Apps zur Meldungsbearbeitung erfolgen und nicht mehr über die Alert Inbox. Controlling Mechanismen werden über vordefinierte Dashboards zur Verfügung gestellt. Folgender Prozess wurde definiert und die Mitarbeiter vor der Aktivierung wiederum geschult:

• Jeder Alert erstellt ein Incident (eine Störungsmeldung)
• Wird ein weiterer Alert zu einem bereits bestehenden Incident ausgelöst, wird das vorhandene Ticket aktualisiert
• Das Incident wird von einem Support Mitarbeiter in Bearbeitung genommen
• Kann ein Problem vom 2nd Level Support nicht gelöst werden, wird für den jeweiligen Fachbereich ein Folgeticket angelegt
• Wurde die Störung behoben, ein Folgeticket angelegt oder der Fachbereich / Key User per Mail oder telefonisch informiert, wird das Incident auf «Lösungsvorschlag» gestellt und bestätigt
• Nicht bestätigte Meldungen werden nachts automatisch über einen Hintergrundjob bestätigt

Schritt 4: Reaktions- und Bearbeitungszeiten

Durch die Verwendung von Reaktions- und Bearbeitungszeiten wird die zeitnahe Bearbeitung und Lösung von Incidents sichergestellt. Darüber hinaus dienen diese den Support Mitarbeitern auch zur Orientierung um sicherzustellen, dass Incidents in der korrekten Reihenfolge und Zeit bearbeitet werden. Zusätzlich bietet diese Konfiguration den Vorteil, dass Tickets mit ablaufender Reaktions- oder Bearbeitungszeit verfolgt werden können. Reaktions- und Bearbeitungszeiten wurden in Abstimmung mit unserer Kundin wie folgt definiert:

Bewertung unserer Kundin

Im Vergleich zur Erstbewertung unter der Verwendung der Alert Inbox hat sich die Zufriedenheit unserer Kundin und deren Mitarbeiter stark erhöht:

Abarbeitung der Tickets in der «richtigen» Reihenfolge dank Priorisierung und Messung von IRT / MPT

Supporter haben eine gute Übersicht über ihre Tickets und die ihrer Kollegen

Analysen und Aktionen werden dokumentiert und können über Suchfunktionalitäten gefunden werden

Stundenaktuelle Übersicht für das Management mit den ITSM Dashboards

Kontrolliertes und strukturiertes Arbeiten ist nun möglich

Anforderung der Revision werden erfüllt

Ausblick

Die initialen Anforderungen unserer Kundin konnten durch den SAP Solution Manager 7.2 in Verbindung mit dem IT-Servicemanagement voll erfüllt werden. Aufgrund der gesammelten Erfahrungen und das ebenfalls steigende Interesse der Fachbereiche an einer professionellen Überwachung rechnen wir mittelfristig mit weiteren Anforderungen in folgenden Bereichen, die eine gezielte Alarmierung direkt an die Fachteams notwendig machen:

• Überwachung von ein- und ausgehenden IDocs
• Überwachung von Anwendungslogs
• Überwachung von Jobabbrüchen- und Joblaufzeiten

In einem Pilotversuch konnten wir die Anforderungen bereits erfolgreich umsetzen und die Rahmenparameter bestimmen, die für eine erfolgreiche Überwachung in den drei genannten Themenbereichen benötigt werden.

Zu guter Letzt…

… bieten wir Ihnen noch ein paar Impressionen aus dem SAP Solution Manager in der Form von Screenshots. Sollten auch Sie Beratung und Unterstützung bei der erfolgreichen Umsetzung Ihrer Monitoring Lösung benötigen, stehen wir Ihnen sehr gerne zur Verfügung.