Zu den gewohnten Aufgaben im IT-Infrastrukturumfeld hat sich in den vergangenen Jahren eine weitere hinzugesellt: Die IT-Zuständigen sollen Transparenz und Steuerbarkeit erhöhen sowie das Kosten-Nutzen-Verhältnis möglichst günstig gestalten.
Fazit
Six Sigma und Itil passen gut zusammen. Vor allem die Itil-Prozesse Incident-, Availability- und Capacity-Management eignen sich für ein zahlenorientiertes und statistisches Vorgehen, wie es Six Sigma mit sich bringt. Auf der technischen und organisatorischen Seite werden Transparenz und Messbarkeit vorangetrieben, was die Prozesse steuer- und standardisierbar macht. Auch auf der betriebswirtschaftlichen Seite entstehen Kostentransparenz und eine bessere Steuerbarkeit des IT-Budgets.
Diese neue Qualität im IT-Betrieb manifestiert sich in zunehmender Industrialisierung. Ein standardisiertes IT-Infrastrukturumfeld lässt sich leichter steuern. Das hat einen ähnlichen Effekt wie der Schritt von der Handfertigung zur Massenproduktion in der Industrie.
Im Zuge dieses Wandels lassen sich Erfahrungen und Werkzeuge nutzen, die schon in der industriellen Produktion Anwendung finden. Allerdings ist eine Fließbandfertigung nur bedingt mit IT-Dienstleistungen vergleichbar. Abläufe, Zusammenhänge und Inhalte gestalten sich anders. Dasselbe gilt für die Aufgaben und Anforderungen an die beschäftigten Personen.
Richtung Industrialisierung
Ein Tool, das sich sehr gut von der industriellen Fertigung auf den IT-Betrieb übertragen lässt, ist Six Sigma. Bekannt ist es vor allem aus der Prozessverbesserung. Neben einer Methode zur geordneten Einführung von Prozessen bietet Six Sigma den Nutzern eine Vorgehensweise und einen Werkzeugkoffer, mit dem sie ihre Prozesse verbessern können.
Die Verbesserungen lassen sich zahlen- und datenorientiert über Messungen und Analysen ableiten. Der große Pluspunkt von Six Sigma ist dabei, dass die Abläufe transparenter, messbarer, genauer und damit wesentlich besser steuerbar werden. Für den IT-Betrieb bedeutet das also einen großen Sprung in Richtung Industrialisierung der IT-Infrastruktur.
Das methodische Vorgehen
Für die Behandlung von Prozessen hält Six Sigma zwei Möglichkeiten bereit: den DMAIC-Zyklus für die Verbesserung und den DMADV-Zyklus für die Einführung. Das Vorgehen an sich ist bei beiden annähernd identisch.
Beim DMAIC-Zyklus liegt die Betonung auf den Schritten M wie Measure, A wie Analyse und I wie Improve. Im DMADV-Zyklus ist das Verhältnis der einzelnen Phasen zueinander im Prinzip ausgewogener, wobei für die Neueinführung aber die Schritte D wie Design und V wie Verify (sprich: Umsetzung) ein gewisses Übergewicht bekommen.
Am besten lässt sich Six Sigma durch Zahlen und grafische Darstellungen verdeutlichen. Die Forderung des Six-Sigma-Konzepts heißt: 3,4 Fehler auf eine Million produzierte Einheiten, also 99,99966 Prozent Genauigkeit. Aber wie lässt sich dieses Ziel beziehungsweise ein mit Augenmaß angepasstes in einer Dienstleistungsumgebung erreichen?
Im Serviceumfeld geht es häufig um wiederholtes Abarbeiten von Prozessen. Diese setzen sich zusammen aus einem Eingangskanal (Was kommt herein?), einem produktiven Teil (Was wird gemacht?) und einer Übergabe (Was geht hinaus?). Der produktive Teil erzeugt Ergebnisse (Daten), die bei genügend großer Menge häufig den Verlauf einer Glockenkurve oder Gaußschen Normalverteilung annehmen.
Six Sigma geht von gemessenen Prozessergebnissen aus, also beispielsweise von der Zeit, die benötigt wird, um einen bestimmten Vorgang zu erledigen. Die Streuung oder Verteilung der Ergebnisse soll in Richtung auf ein bestimmtes Ziel verändert werden. In unserem Beispiel heißt das: Der Vorgang soll jedes Mal innerhalb einer vorgegebenen Zeitspanne erledigt sein.
Die in der Best-Practices-Sammlung Itil beschriebenen Prozesse befassen sich explizit mit der Produktion im IT-Infrastrukturumfeld. Langjährige Erfahrungswerte helfen dabei, die IT-Produktion zu organisieren. Für die Einführung der Prozesse bietet Itil allerdings keinen Leitfaden an. Hier kommt die Six-Sigma-Methodik ins Spiel. Mit Hilfe des DMADV-Zyklus lassen sich alle Itil-Prozesse einführen. Der DMAIC-Zyklus hilft, vorhandene Abläufe zu optimieren.
Beispiel Incident-Management
Statistisch verwertbare Daten, wie Six Sigma sie benutzt, finden sich vor allem in den Prozessen Incident-Management sowie Availability- und Capacity-Management. Die Daten des Incident-Managements betreffen die Störungen von IT-Leistungen, im Availability-Management sind es Verfügbarkeitsdaten, im Capacity-Management Kapazitätsangaben für Systeme und Komponenten. Daraus lassen sich Abweichungen analysieren und Verbesserungen für die Prozesse ableiten wie es Six Sigma mittels des DMAIC-Zyklus tut.
Was Six Sigma für die Verbesserung von Itil-Prozessen leisten kann, zeigt ein Beispiel aus dem Incident-Management. Nehmen wir an, ein Kunde ist mit der Leistung des Incident-Managements unzufrieden. Um ihm die gewünschte Leistung liefern zu können, muss die IT-Abteilung oder der externe Dienstleister zunächst die Vorgabe an die Prozessverbesserung genau eingrenzen. Dazu wird der Incident-Management-Prozess als "Sipoc" (Supplier Input Process Customer Output) dargestellt. Anschließend gilt es, die Kundenanforderungen (CCR = Critical to Customer Requirements) an die Leistungen des Incident-Managements festzuhalten und zu gewichten. Den Kundenanforderungen werden dann Messgrößen (CTQ = Critical to Quality) zugeordnet. Beides erfolgt mittels einer Tabelle. Die Messgrößen sollten durch die Tools des Incident-Managements (Telefonanlage und Ticketing-Tool) ermittelbar sein.
Danach ist bekannt,
welcher Prozess oder Prozessteil untersucht wird,
was der Kunde wünscht,
wo die Probleme liegen und
welche Messgrößen zu verwenden sind.
Die Messdaten werden standardisiert in täglichen, wöchentlichen oder monatlichen Reports geliefert eventuell auch nach individueller Abstimmung mit dem User Helpdesk. Die Messergebnisse lassen sich in Excel oder speziellen Tools erfassen und mit Hilfe statistischer Verfahren aufbereiten.
Zur Analyse der Messergebnisse dienen die mit dem Kunden vereinbarten Vorgaben (SLAs = Service-Level-Agreements). Die Messergebnisse aus mehreren Wochen oder Monaten werden mit den Vorgaben verglichen, um zu sehen, ob die SLAs verletzt werden und wie groß die eventuelle Abweichung ist.
Zeichnen sich Diskrepanzen ab, wird nach den möglichen Ursachen, deren Abhängigkeiten und Wirkungen gesucht. Diese lassen sich in einem Ursache-Wirkung-Diagramm (auch Ishikawa- oder Fischgrätendiagramm genannt) festhalten. Um die jeweils betroffenen Prozessteile eingrenzen zu können, sind die möglichen Ursachen den einzelnen Prozessabschnitten zuzuordnen.
Kontrolle ist besser
Nachdem Messergebnisse und die Analyse vorliegen, kann die Verbesserung in Richtung auf die Vorgaben und Ziele des Kunden beginnen. In einer Tabelle werden die betroffenen Prozessteile, die aufgetretenen Fehler sowie deren Folgen und Ursachen dokumentiert und gewichtet. Auf dieser Basis lassen sich Maßnahmen vorschlagen und deren Umsetzungsgrad kontrollieren. Die Fachleute sprechen hier von Failure Mode Effect Analysis (FMEA) oder Fehler-Ursachen-Analyse. Die vorgeschlagenen Maßnahmen sind möglichst auch einer Kosten-Nutzen-Analyse zu unterziehen.
Ob die Wünsche und Ziele der Kunden erreicht sind, wird in der nächsten Phase "Kontrolle der Ergebnisse" geprüft. Wie die Einführung von Prozessen, so mündet auch die Prozessverbesserung in die Kontrolle der umgesetzten Massnahmen sowie in Vorkehrungen, um eine dauerhafte Veränderung zu erreichen.
Für die Kontrolle eignet sich die FMEA. Zur dauerhaften Veränderung bietet sich die statistische Prozesskontrolle an. Hier geht es um regelmäßige Messung der problematischen Prozessteile. So kann der Verantwortliche Abweichungen rechzeitig entdecken und entsprechend gegensteuern. (qua)