In dem Maße, wie Unternehmen abhängiger von den Geschäfts- und Produktionsprozessen der IT-Systeme werden, steigen auch die Anforderungen an die Qualität dieser Abläufe. Sie ähneln mittlerweile den Ansprüchen, die schon seit Jahren an die industrielle Fertigung gestellt werden.

Deshalb treibt der Münchner Speicherchip-Produzent Qimonda die "Industrialisierung der IT" voran. Er versteht darunter die Übertragung von Methoden der Produktion auf den IT-Betrieb. In diesem Zusammenhang liegt es nahe, auch die etablierten Werkzeuge zur Steuerung und Kontrolle der Fertigungsqualität auf die IT-Prozesse zu übertragen. Beispiele dafür sind die Statistical Process Control (SPC) zum Überwachen von Systemressourcen oder die 8-D-Methode als Grundlage für die systematische inhaltliche Aufarbeitung von Ausfällen und Störungen.

Zudem hat Qimonda einen besonderen Schwerpunkt auf die Umsetzung von Lean Six Sigma (L6S) gelegt. Dieses Konzept verbindet zwei voneinander unabhängige Ansätze zur Steigerung der Prozess-Performance (mehr zur Einführung von Lean Six Sigma im ersten Teil der COMPUTERWOCHE-Serie "Six Sigma in der IT").

So wenig Abweichungen wie möglich

Six Sigma zielt darauf ab, die Streuung eines statistisch verteilten Prozesses so weit wie möglich zu begrenzen, also einem bestimmten Prozessmerkmal besonders wenige und sehr geringe Abweichungen zu gestatten. Wie wichtig das ist, illustriert ein Beispiel: Dauert ein Produktionsprozess zwischen wenigen Stunden und mehreren Tagen, so weist er eine sehr hohe Streuung auf. Die Folge davon ist, dass sich nur schwer einschätzen lässt, wann ein Produkt tatsächlich fertig wird. Ist dieser Prozess zudem Teil einer logistischen Kette, so wirkt sich diese Streuung auch auf die anderen Abläufe und damit auf das Gesamtsystem negativ aus

Six Sigma ist nun Ausdruck des Versuchs, derartige Variationen innerhalb enger Grenzen zu halten. Das "Six-Sigma-Level" entspricht in der Qualitätskontrolle einer Rate von maximal 3,4 Ausfällen auf eine Million Ausfallmöglichkeiten.

Damit ist Six Sigma sowohl das Qualitätsziel als auch eine Methode zum Qualitäts-Management. In Six-Sigma-Verbesserungsprojekten kommen unterschiedliche Qualitätswerkzeuge zur Anwendung. Geleitet werden die Projekte von speziellen Six-Sigma-Experten, den "Black Belts" (siehe auch: "Six Sigma zahlt sich in der IT aus")

Der "Lean"-Gedanke hat seinen Ursprung in einer "Unternehmensphilosophie", die in Japan entwickelt wurde: der "Lean Production". Darunter versteht man das Weglassen aller überflüssigen Aktivitäten in den betrieblichen Abläufen, sprich: sowohl in der Produktion als auch in der Verwaltung. In dem oben angeführten Beispiel eines Produktionsprozesses ließe sich also mit der "schlanken" Methode die durchschnittliche Fertigungszeit verringern (mehr zum Thema Management-Methoden in "Prozessgüte heißt Wettbewertbsvorteil").

Itil ist eine notwendige Voraussetzung

Die statistischen Six-Sigma-Werkzeuge beruhen auf sehr vielen Daten, die für ein bestimmtes Qualitätsmerkmal vorliegen. Auf den ersten Blick erscheint es deshalb fraglich, ob sie sich auch auf die Abläufe des IT-Betriebs anwenden lassen. Das ist durchaus möglich. Aber es setzt voraus, dass die Betriebsprozesse systematisch nach dem Referenzmodell "Itil" (IT Infrastructure Library) strukturiert sind. In diesem Fall gibt es durchaus Abläufe, die eine ausreichend hohe Anzahl an Wiederholungen aufweisen.

Ein typisches Beispiel dafür stellt der Incident-Management-Prozess dar. Wie am Beispiel von Qimonda demonstrierbar, kann Lean Six Sigma helfen, die Performance bei der Bearbeitung von IT-Vorfällen (Incidents) signifikant zu verbessern. Der "Lean"-Aspekt zielt dabei auf die Verringerung der durchschnittlichen Bearbeitungszeit; die Six-Sigma-Werkzeuge sollen die Variation der Bearbeitungszeit im Rahmen halten.

Am Anfang steht die Beschreibung

Ein L6S-Projekt beginnt stets mit der Definition einer "Project Charter". Sie besteht aus einer kurzen, prägnanten Beschreibung des Problems, der betroffenen Personen, des monetären Verbesserungspotenzials ("Business Case"), einer messbaren Zieldefinition, einem groben Projektplan und der Auswahl des Projektteams.

Der Projektleiter sollte ein umfassend ausgebildeter Black Belt sein. Manager aus dem betroffenen Problembereich unterstützen das Team als Sponsoren. Zudem empfiehlt es sich, einen Champion aus der Führungsebene zu benennen.

Wie das Projekt ins Rollen kam

Der Auslöser für das L6S-Projekt bei Qimonda war der subjektive Eindruck, dass das Bearbeiten von Störungen zu lange dauerte. Allein dieser Eindruck kann – neben Frustration auf Seiten der Anwender und des IT-Personals – durchaus Einfluss auf das Geschäftsergebnis haben.

Eine konservativ gerechnete Business-Case-Betrachtung für das Formulieren der L6S-Project-Charter ergab einen möglichen Gewinn von 400 000 Euro pro Jahr. Dieser Berechnung zugrunde lag als Ziel die Verbesserung der durchschnittlichen Vorfallbearbeitungszeit um 20 Prozent – über alle Services brachtet.

Neben diesem primären Ziel wurden auch sekundäre formuliert. Dazu zählten eine bestimmte "First Call Resolution Rate", hohe Kundenzufriedenheit und niedrige Service-Desk-Kosten.

Ein weiteres wichtiges Element der Project Charter ist das Projektteam einschließlich des zugeordneten Black Belt, der Sponsoren und des Champions aus dem Topmanagement. Das Team bei Qimonda wurde – entsprechend dem Charakter des weltweit verteilten Incident-Management-Prozesses – international besetzt. Als Projektleiter zeichnet der Portugiese Paul Gouvea verantwortlich.

Die fünf Phasen des Projekts

Das Qimonda-Projekt ist aufgeteilt in die bekannten Six-Sigma-Phasen Define, Measure, Analyse, Improve, Control (DMAIC). In der Define-Phase wurden zunächst die Basisdaten aus dem Service-Management-Tool extrahiert und in allen Einzelheiten statistisch analysiert. Es handelte sich um Informationen zu insgesamt 11 000 Vorfällen, die in einem Beobachtungszeitraum von zwei Monaten abgeschlossen worden waren.

In der Measure-Phase galt es, festzustellen, wie gut der bestehende Prozess die Kundenanforderungen erfüllte. Bereits hier ergaben sich einige interessante Erkenntnisse: Beispielsweise richtete sich die Bearbeitungsdauer im Wesentlichen nach der Priorität des Vorfalls. Diese Priorität legte der Service-Desk allerdings nach sehr unterschiedlichen Kriterien fest. Und dabei richtete er sich im Allgemeinen nicht nach den für diesen Service abgeschlossenen Service-Level-Agreements (SLAs).

Zudem ließ sich ein Unterschied in der Streuung der Vorfall-Bearbeitungsdauer ausmachen – je nachdem, ob es sich um Vorfälle an Arbeitstagen oder an Feiertagen handelte. Dieser Effekt war letztlich auf eine partielle Vermischung der eigentlich getrennten Abläufe von Incident- und Problem-Management zurückführbar. Das passierte vorzugsweise an Arbeitstagen, wenn sich die Experten vom Third-Level-Support teilweise sofort und sehr zeitintensiv darum kümmerten, die Ursachen zu beheben. An Feiertagen hingegen konzentrieren sich die Mitarbeiter vom First- und Second-Level-Support darauf, ein Problem möglichst schnell über eine provisorische Lösung zu entschärfen. Die Behebung der Ursache wird auf einen späteren Zeitpunkt verschoben, wenn sie ohne Zeitdruck geschehen kann. Schließlich wurde auch offenbar, dass Bearbeitungsdauer je nach Support-Gruppe variierte. Sie war durchweg länger in Gruppen, die insgesamt weniger Vorfälle zu bearbeiten hatten.

Hypothesen über Ursache und Wirkung

Die erhobenen Daten wurden in der Analyse-Phase weiter ausgewertet. Ausgehend von einer detaillierten Prozessabbildung generierte das Team anhand einer C&E-Matrix (Causes-and-Effects-oder auch Ursache-Wirkungs-Diagramm) erste Hypothesen über Ursache und Wirkung. (Ein Verzeichnis von Abkürzungen im Six-Sigma-Umfeld finden Sie bei "SixSigmaFriends.com") Die vorgeschlagenen Maßnahmen bewertet Qimonda mit Hilfe einer detaillierten Prozess-FMEA (Failure Method and Effects Analysis).

Die konkreten Maßnahmen werden in der Improve-Phase umgesetzt. Sie zielen auf eine Datenbereinigung des Systems, eine stärkere Konzentration auf die SLAs und eine konsequente Aufarbeitung der Priorisierungsregeln. Als weitere Erfolgsfaktoren haben sich eine lückenlose Statusüberwachung und ein stärkeres Ausrichten der Betriebsabläufe an den Anwendern herauskristallisiert.

Das Projekt befindet sich derzeit im Abschluss. Ein quantitativer Nachweis darüber, ob alle Projektziele erreicht wurden, liegt noch nicht vor. Es besteht aber kein Zweifel, dass mit den umgesetzten Maßnahmen deutliche Verbesserungen erzielbar sind.

Das Fazit ist durchweg positiv

Damit wäre der Beweis erbracht, dass Methoden, die ursprünglich zur Verbesserung industrieller Produktionsprozesse entwickelt wurden, auch die IT-Betriebsabläufe optimieren können. Das gilt insbesondere für die Verbindung von Lean Six Sigma mit einer Strukturierung der IT-Prozesse nach Itil: Das Referenzmodell liefert den Bezugsrahmen dafür, wie die IT-Abläufe inhaltlich zu strukturieren sind. Darauf aufbauend, ermöglicht L6S eine Verbesserung der Prozesse unter Berücksichtigung quantitativer Aspekte.

Profitieren werden davon besonders die IT-Abteilungen in industriellen Unternehmen: Mit der Vereinheitlichung der von IT-Abteilung und internen Kunden angewendeten Methode rücken die beiden Unternehmensbereiche gedanklich näher zusammen. Das viel beschriebene "IT-Business Alignment" lässt sich deutlich leichter herstellen, wenn alle Beteiligten nach denselben Prinzipien und Methoden arbeiten und eine gemeinsame Sprache sprechen. (qua)