Systematische Prozessverbesserung des IT-Monitorings

Konsolidierung des IT-Monitorings als Projektbeispiel für eine Prozessoptimierung in 3 Monaten.

Der Six Sigma DMAIC-Zyklus dient dazu, die Qualität ihrer Prozess zu steigern und gleichzeitig Kosten zu senken. Dass dies auch bei der Konsolidierung von Monitoring-Systemen in der IT funktioniert, zeigt das folgende Projektbeispiel. Ein Team ermittelt systematisch, welche Plattform sich am besten als die zukünftige zentrale Monitoring-Lösung eignet.

DMAIC steht als Abkürzung für die fünf Phasen eines Six Sigma Projekts:

  • Define – Festlegen des Prozesses und der wichtigsten Kundenanforderungen an den Prozess
  • Measure – Messen des Erfüllung der Kundenanforderungen
  • Analyze – Analyse der Kernursachen, wenn Kundenanforderungen nicht erfüllt werden
  • Improve – Identifizieren und Planen von Verbesserungsmaßnahmen
  • Control – Nachverfolgen und Sicherstellen des langfristigen Projekterfolgs

Ich möchte hier an einem Beispiel zeigen, wie der Six Sigma Zyklus dabei hilft, daten- und faktenbasierte Entscheidungen zu einem Monitoring-System zu treffen und umzusetzen.

1. Define

Ein Six Sigma Projekt beginnt stets mit einer quantifizierten Beschreibung von Ausgangssituation, Zielen und erwartetem Nutzen eines Projekts.

Die Problemdefinition des Projekts lautet wie folgt:

Die IT-Abteilung des Unternehmens A betreibt insgesamt 3 Monitoring-Lösungen:

 – Nagios für SAP-Monitoring

 – HP Openview für das Monitoring von Netzwerk- Equipment

 – CA Spectrum für das Monitoring der virtualisierten Server

Die Gesamtkosten für alle 3 Lösungen belaufen sich auf ca. 100T Euro pro Jahr.

Die Gesamtkosten sollen um mindestens 50% reduziert werden. Die Anzahl der Monitoring Tools im Unternehmen ist minimal.

Wichtig ist, dass die Projektbeschreibung und die Ziele des Projekts quantifizierbar formuliert werden. Nur so kann man den Erfolg des Projekts tatsächlich durch einen Vorher/ Nachher Abgleich nachweisen.

Das Team wird anschließend noch eine Prozessbeschreibung der Monitoring-Prozesse in ihren jeweiligen Abteilungen erstellen (LIPOK). Dieser Vorgang dient an dieser Stelle des Projekts vornehmlich dazu, den Scope festzulegen – es ist nicht Ziel hier eine ausgiebige Prozessanalyse durchzuführen.

Im nächsten Schritt werden die Anforderungen an das Monitoring erarbeitet. Das CTQ-MatrixWerkzeug der Wahl ist hier die “CTQ-Matrix“. Dabei werden aus den gesammelten, unspezifischen “Kundenstimmen” (oder Voice of Customer/VoC) zunächst Kernthemen identifiziert. Dann einigt sich das Team auf eine messbare Definition der Kundenanforderung (nennt man in Six Sigma CTQ).

2. Measure

In dieser Phase wird die Erfüllung der Kundenanforderung gemessen. Für die konkrete Problemstellung in diesem Projekt musste das Team ermitteln, wie gut jede Monitoring-Lösung die CTQs erfüllt.

Dazu einigten wir uns auf eine detaillierte Anforderungsmatrix, in der wir alle drei Werkzeuge gegenüberstellen wollten. Die Anforderungsmatrix wurde in 3 Schritten erarbeitet:

  1. Brainstorming möglicher Anforderungen an ein Monitoring-Tool
  2. Clustering der Antworten
    • Grundfunktionalitäten
    • SLA-Reporting
    • Grafische Benutzeroberfläche
    • Bedienbarkeit
    • Alarmierung/ Autoreaktion
    • Sonstiges
  3. Zuordnung der Detailanforderungen zu den jeweiligen CTQs, damit der Erfüllungsgrad der jeweiligen CTQs genau gemessen wird

Anschließend ging das Team die Detailanforderungen durch. Je Anforderung wurde markiert, ob das Monitoring-Tool die Anforderung vollständig erfüllt (9 Punkte), teilweise erfüllt (3 Punkte) oder gar nicht erfüllt (0 Punkte).

Das Ergebnis war ein genauer Score für jedes Monitoring-Tool, wie gut es die existierenden Kundenanforderungen erfüllte.

3. Analyze

In dieser Phase findet üblicherweise die Analyse und Verifizierung der Kernursachen von Prozessproblemen statt. Six Sigma spielt hier in der Regel besondere Stärken aus, weil sein Werkzeugkasten mit umfangreichen statistischen Tools ausgestattet ist (Hypothesentests, Kovariate Analysen, ANOVA, usw.).

Für die weitere Bearbeitung der Monitoring-Thematik war dies natürlich nicht erforderlich. Die Measure-Phase hatte jedoch ergeben, dass selbst das beste Tool mit dem höchsten Score (Nagios) nicht alle Detailanforderungen abdecken konnte.

Also erarbeitete das Team mit Hilfe einer Pugh-Matrix, welche Anforderungen Nagios noch abdecken musste und wie genau dies umgesetzt werden musste. Am Ende der Analyse hatte das Team ein fertiges Implementierungskonzept für Nagios.

4. Improve

Das Team war sich nun einig, dass Nagios alle Anforderungen an eine Gesamtmonitoring-Lösung abdecken konnte.

Nun wurde ein Ablaufplan für die nächsten Wochen erstellt, um die erforderlichen Integrationsarbeiten zu erbringen. Außerdem wurde in dem Plan festgelegt, wann die alten Monitoring-Werkzeuge abgeschaltet werden und entsprechende Wartungsverträge gekündigt werden sollten.

Der Projektplan wurde dem Projektsponsor (Leiter IT) vorgestellt und verabschiedet. Das Team setzte die Maßnahmen gemeinsam um.

5. Control

In der Control-Phase wurden vom Team Prozessbeschreibungen für das Monitoring erstellt und Kollegen in die neue Umgebung eingewiesen. Bestimmte Prozesse mussten noch geändert werden. Beispiel: Statt wie früher SLA-Reports aus drei verschiedenen Abteilungen zu konsolidieren, hatte der Service Manager nun nur noch eine Informationsquelle für sein Reporting.

Das Team traf sich in den folgenden 12 Monaten im Anschluss an die Umsetzung noch insgesamt 6 Mal um offene Punkte zu bearbeiten und den Erfolg des neuen zentralen Monitorings sicherzustellen.

Projektbeteiligte: 3 Mitarbeiter aus dem Fachbereich, 1 Black Belt als Moderator

Projektdauer: ca. 3 Monate (12 Projektsitzungen zu je 1,5 Stunden zzgl. Aufwand für die Umsetzung der Maßnahmen)