Mit der Einführung des ITIL-Standards haben viele Unternehmen ihre IT-Betriebsprozesse de facto vereinfacht. Der Weg von der IT-Manufaktur zur IT-Fabrik schien dadurch geebnet. Doch die mit ITIL verbundenen hohen Erwartungen erfüllten sich oft nicht. Während sich die Prozessreife in der Tat weiterentwickelte, blieben Effektivitäts- und Effizienzlücken im IT-Betrieb oft bestehen.

Die Verantwortlichen in den Unternehmen haben daraus gelernt: Ein prozessualer Standard ist nur ein Puzzlestein auf dem Weg zur Industrialisierung.

Das Prinzip Lean Management

Neue Prinzipien der Arbeitsorganisation und der Steuerung an der Nahtstelle von optimierter Aufbau- und Ablauforganisation führen in der Prozessindustrie unter dem Motto "Lean Management" zu signifikanten Produktivitätssteigerungen, hoher Flexibilität und wachsender Geschwindigkeit. Diese Prinzipien lassen sich auch auf das Tagesgeschäft heutiger IT-Betriebe übertragen und mit geeigneten Werkzeugen unterstützen.

In den 80er Jahren waren deutsche Unternehmen, unter anderem in der Automobilindustrie, stolz auf ihren hohen Anteil an Eigenfertigung. Wie in Manufakturen üblich, waren die Produktionsprozesse wenig standardisiert, lieferten allerdings Produkte hoher Qualität, die dem Gütesiegel "Made in Germany" gerecht wurden.

Der Eintritt von Konkurrenten aus Fernost in den Weltmarkt kam für viele dieser Unternehmen einem Erdbeben gleich. Japanische Unternehmen waren binnen kürzester Zeit in der Lage, hochwertige Fahrzeuge zu niedrigeren Kosten zu produzieren. Ihr Vorteil war die gegenüber den deutschen Unternehmen effizientere Produktions- und Arbeitsorganisation.

ITIL-Effekte werden aufgefressen

IT-Verantwortliche stehen heute vor einer ähnlichen Herausforderung: Sie müssen ihre Kosten und ihre Leistungen permanent mit dem Markt messen, wo Innovationen wie Cloud Computing zu immer günstigeren Angeboten führen. Die erwarteten ITIL-Effekte auf Effizienz und Produktivität haben sich vielfach nicht gezeigt oder sind höheren Ansprüchen zum Opfer gefallen.

Auf den Entscheideretagen in Unternehmen reift daher zunehmend die Erkenntnis, dass der gordische Knoten zur Industrialisierung des IT-Betriebs noch nicht gelöst ist. Synonym dafür ist das latente Gefühl, keinen wirklichen "Griff" an den Aufgaben zu haben. Die in IT-Betrieben herrschende "Kleinteiligkeit" (Benutzeradministration, Kapazitäts-Management, Ticket-Bearbeitung, Changes etc.) verstärkt dieses Gefühl.

Sechs Tipps zum Umgang mit Regelwerken
ITIL, CoBIT, Togaf & Co. haben durchaus ihren Sinn. Aber eine zu enge und unkritische Ausrichtung auf solche Standards wird den individuellen Anforderungen der Unternehmen oft nicht gerecht.

Tipp 1:
Lassen Sie sich nicht von einem Regelwerk vereinnahmen, sondern entwickeln Sie eine kritisch-konstruktive Distanz dazu.

Tipp 2:
Versuchen Sie nicht, individuelle Erfordernisse des Unternehmens in den Standard eines Methodenwerks zu pressen.

Tipp 3:
Definieren Sie ein unternehmensspezifisches Framework und übernehmen Sie nur die Teile aus den Regelwerken, die nützlich sind und verstanden werden. Beachten Sie dabei die Pareto-Regel (mit 20 Prozent Aufwand 80 Prozent der Dinge regeln), damit keine zu komplizierte Frameworks entstehen.

Tipp 4:
Entwerfen sie zum Unternehmen passende Prozesse, zum Beispiel mit der "Wertschöpfungsmaschine" von Andreas Suter oder der Business-Engineering-Methode von Hubert Österle.

Tipp 5:
Bestehen Sie auf klaren und präzisen Begriffsdefinitionen. Prüfen Sie Ihre Definition, indem sie drei Stakeholder/Experten aus Ihrem Unternehmen nach deren Interpretation fragen. Wenn jeder etwas anderes interpretiert, taugt die Begriffsdefinition nicht.

Tipp 6:
Greifen Sie bei Servicedefinitionen auf fundierte und konkrete Werke zum IT-Produkt-Management oder Service-Engineering zurück (beispielsweise von Harry Sneed, Tilo Böhmann oder Klaus-Peter Fähnrich).

Viele IT-Betriebe sind überfordert

Im Kern stellt sich die Frage, wie die IT-Betriebstätigkeiten organisiert und gesteuert werden sollen. Die damit befassten Mitarbeiter beantworten diese Frage wie folgt: Sie organisieren ihren Arbeitsalltag anhand des Tagesgeschäfts. Hinzu kommt Projektarbeit, die sich aufgrund häufiger Terminverschiebungen eher volatil gestaltet. Für Unterbrechungen der Abläufe sorgen immer wieder Ad-hoc-Sonderaufgaben sowie stochastische Aufgaben mit hoher Priorität.

Aus Sicht des Mitarbeiters funktioniert diese Herangehensweise. Aus höherer Flughöhe betrachtet, offenbart sich jedoch ein Teufelskreis: Unterbrechungen sorgen für Verzögerungen und Ineffizienzen, die wiederum weitere Verzögerungen und Unterbrechungen nach sich ziehen. Viele IT-Betriebe sind folglich mit der Organisation und Priorisierung ihrer Arbeit überfordert.

Kaizen und Kanban als Vorbild

Die Produktions-und Fertigungsindustrie bietet Lösungen an. Kanban-orientierte Steuerungsverfahren mit hoher Dezentralität, Eigenverantwortlickeit und Werkzeugunterstützung helfen bei der Optimierung. Kaizen (Kontinuierliche Verbesserung) kann auch in der IT gelebte Praxis werden.

Der Schlüssel für den effizienten IT-Betrieb liegt in der Arbeitsorganisation. Sie ist das Bindeglied zwischen Aufbau- und Ablauforganisation. Die Mechanismen an dieser Schnittstelle bestimmen Effektivität und Effizienz. Dabei besteht die Herausforderung in der Balance zwischen Aufgaben, Mengen/Volumen und Ressourcen.

Statt komplexer Steuerungsphilosophien mit einer ganzen Schrankwand voller Kennzahlen reichen oft wenige Prinzipien zur Bewältigung dieser Aufgabe. So sehen sie aus:

1. Teamregeln einführen

Eine wesentliche Veränderung besteht in der teamzentrierten Verantwortung. Anders als bisher soll und darf das IT-Betriebsteam eigenverantwortlich arbeiten und über die notwendigen Prozesse - unter Einhaltung von definierten Standards als Rahmen - selbst bestimmen. Die Arbeit wird nicht mehr zugewiesen (nach dem "Push-Prinzip"); die Mitarbeiter nehmen sie sich vielmehr selbst von einem zuvor priorisierten Stapel. Dies setzt allerdings voraus, dass das Management auf die Fähigkeiten der Mitarbeiter vertraut.

2. Die Arbeit visualisieren

Voraussetzung für die Dezentralisierung von Verantwortung ist Transparenz bezüglich der Aufgaben. In den IT-Betrieben muss jedes Teammitglied wissen, welche Aufgaben anstehen, woran gerade gearbeitet wird und wo es eventuell Schwierigkeiten in der Abarbeitung gibt. Die Aufgaben gilt es zu visualisieren. Sie speisen sich aus Quellen wie Changes, Incidents, Problems, Aufträge etc. In kleineren IT-Teams reicht ein Whiteboard zur Visualisierung. Für größere IT-Betriebe gibt es kostengünstige Werkzeuge wie "Jira" von Atlassian.

3. "Work in Progress" begrenzen

IT-Betriebe sind besonders leistungsfähig, wenn die Arbeit möglichst gleichmäßig durch die Einheiten "fließt". Bei jeder Unterbrechung kommt es zur Anhäufung von Arbeiten, also zum Stau. Damit verbundene Rüstzeiten führen zu Ineffizienzen. Es gilt, Staus und Engpässe gar nicht erst entstehen zu lassen. Die Begrenzung des jeweiligen Arbeitsvolumens hat sich als probates Mittel zur Verringerung von Rüstzeiten erwiesen. An jedem Arbeitsplatz darf nur eine kleine Zahl von Aufgaben "offen" sein. Das jeweilige Limit ist unternehmensspezifisch auf Basis von Kennzahlen zu ermitteln und bewegt sich meist zwischen vier und acht.

4. Ergebnisse quantifizieren

Ein hoher Industrialisierungsgrad wird in Fertigungsunternehmen oft durch maximale Transparenz mit Hilfe von Kennzahlen erzielt. Viele IT-Verantwortliche nehmen sich diese Industrien als Beispiel.

7 Fehler im Kennzahlen-Management
Kennzahlensysteme sind ein probates Mittel zur Kosten-Nutzen-Analyse in der IT. Leider machen Unternehmen bei der Anwendung gravierende Fehler.

1. Out of the Box ist trügerisch
Kennzahlen "Out of the Box" sind zweifellos verlockend, und sie kommen überraschend häufig vor. Das starre Korsett mit standardisierten Messpunkten kann jedoch zu einer unreflektierten Sichtweise und Einschätzung führen. Kosten und Leistungen müssen auf Grundlage der bestehenden Struktur gemessen werden.

2. Irreführende Schätzungen
Der Top-down-Ansatz wird scheitern, wenn das Unternehmen die hierfür vorgesehenen Kennzahlen nicht vernünftig bilden kann. Sind die Basisdaten in der geforderten Form nicht vorhanden, müssen sie entweder geschätzt oder über eine mühsame Implementierung beschafft werden. Das Ergebnis ist entweder ungenau oder aufwendig zu bilden, so dass der Nutzen auf der Strecke bleibt.

3. Unscharfe Kennzahlen
Häufig kalkulieren Unternehmen mit fragwürdigen Werten, weil sie die benötigten Werte nicht messen können. So lässt sich die Zahl der Hardwaretypen im Windows-Umfeld nur schwer bestimmen, wenn die Geräte in unterschiedlichen Abteilungen eingesetzt werden und kein umfassendes Asset-Management existiert. Der Einfachheit halber wird dann die Kennzahl der unterschiedlichen Windows-Versionen herangezogen, weil diese durch die Softwarelizenzierung bekannt ist. Jedoch ist diese Zahl ein schwächerer Komplexitätstreiber als die Hardwaretypen, weshalb das Abbild der Organisation unscharf wird.

4. Top-Level-Informationen ohne Basis
Wenn das Projekt vom Vorstand angestoßen wurde, müssen die angeforderten Zahlen geliefert werden. Durch die Verwendung grober Schätzwerte sind Drilldowns zu den tatsächlichen operativen Kennzahlen kaum möglich: Die Ursache-Wirkungs-Kette ist nicht belastbar. Schaltet eine Top-Level-Kennzahl auf Rot, erwartet das Management, dass der Grund hierfür bekannt ist oder zumindest schnell gefunden wird. Deshalb sind die richtigen Basisinformationen viel wichtiger für die Steuerung der Organisation als die Top-Level-Informationen. Ohne die passende Grundlage hängen die Top-Level-Kennzahlen in der Luft.

5. Verwirrende Komplexität
Kennzahlen berechnen sich nicht automatisch aus komplizierten Formeln. So ist beispielsweise die Zahl der Windows-Server eine reguläre Leistungskennzahl, die zudem für das Asset-Management benötigt wird. Auch bei umfassenden Kennzahlensystemen ist Komplexität kein Grundpfeiler des Erfolgs. Unternehmen müssen die richtige Balance finden zwischen einer realistisch machbaren Vorgehensweise und dem, was einen Leistungs-, Kosten-, Komplexitäts- oder Risikotreiber genau repräsentiert.

6. Fehlerhafte Umsetzung
Vor der Entwicklung eines Kennzahlensystems steht die Definition, welche Aspekte der IT konkret gesteuert werden sollen. Jeder IT-Verantwortliche hat seine eigene Philosophie und setzt andere Prioritäten: Einer bevorzugt Prozesse und ITIL, ein anderer plädiert für Services und Servicekataloge, der Dritte schließlich bleibt bei klassischen Funktionen wie der Anwendungsentwicklung und der Infrastruktur. Entsprechend müssen die Kennzahlen angeordnet werden.

7. Falsche Schlüsse
"Normale" Kennzahlen haben einen kleinen Haken: Sie zeigen zumeist nur an, ob die Arbeit richtig gemacht wird - und nicht, ob die richtige Arbeit gemacht wird. So weist etwa Organisation A ein sehr gutes Kostenniveau bei ihren Unix-Servern auf, während Organisation B nur eine unterdurchschnittliche Performance bei ihren Mainframes zeigt. Vergleicht man hingegen die Kosten für den einzelnen Bausparvertrag oder für das einzelne Depot bei beiden Organisationen, kann das Preis-Leistungs-Verhältnis schon ganz anders aussehen. Aus der Perspektive des Topmanagements stellt sich vielleicht die Leistung des relativ schlechten Mainframe-Bereichs besser dar als die Leistung der relativ guten Unix-Abteilung. An den geschäftlichen Stückkosten zeigt sich der Unterschied von Effektivität und Effizienz.

Das Thema "Kennzahlen" bildet in vielen IT-Betrieben allerdings eine Achillesferse: Auf der einen Seite gibt es umfassendes Datenmaterial, beispielsweise zu Verfügbarkeit, Antwortzeiten oder Incidents. Auf der anderen Seite fehlen entscheidende Kennzahlen und deren Interpretation für eine ganzheitliche Planung, Steuerung und Verbesserung. Es gilt also, den Fokus auf die Kennzahlen zu lenken, die eine kontinuierliche Verbesserung des IT-Betriebs ermöglichen. Sie sind als Standard umzusetzen und an jedem Arbeitsplatz verfügbar zu machen. (qua)