Geordnete Abläufe statt Wildwuchs – so stellen sich Chefs den IT-Betrieb vor. In diesem Zusammenhang ist häufig von der IT Infrastructure Library (ITIL) die Rede, die nun in Version 3 erschienen ist. Dieser Artikel gibt einen Überblick über das Qualitätsmanagement nach ITIL und erklärt die wichtigsten Fachbegriffe.

Je größer ein Unternehmen ist, desto wichtiger wird es, die Arbeitsabläufe nicht nur zu strukturieren, sondern auch zu standardisieren. Alle natürlichen Systeme streben nach maximaler Unordnung – und so ist es auch mit Geschäftsprozessen. Mit der Zeit entsteht Wildwuchs, der für alle Beteiligten von Nachteil ist, und neue Mitarbeiter haben es schwer, sich einzuarbeiten, weil Aufteilungen historisch und nicht logisch sind. Das Stammpersonal kämpft mit Zuständigkeitsproblemen. Kunden warten viel zu lange. Die Kosten sind zu hoch und die Qualität leidet.

Lösung für die IT-Branche

Diese Erkenntnisse sind nicht gerade neu, seit Beginn der Industrialisierung weiß man um diese Probleme. Und so sind auch die Lösungsansätze mittlerweile mannigfaltig, unter anderem wegen der Vielzahl von Branchen. Als speziell auf IT-Belange zugeschnittene Lösung bietet sich ITIL an.

Wie der Name IT Infrastructure Library andeutet, ist ITIL eine Sammlung von Büchern. Diese wichtige Feststellung ist vor jeder ITIL-Beschreibung zu treffen, denn sie grenzt ITIL klar ab von den ISO- und anderen Normen. ITIL ist eine Empfehlung, keine Norm. Daher gibt es keine strengen Anforderungen, je nach Bedarf kann eine Implementierung für das Unternehmen maßgeschneidert werden. Ein Vergleich von ITIL mit einigen ISO-Normen ist im Kasten “ITIL und andere QM-Welten” zu finden.

Die ITIL stammt von der britischen Beratungsstelle für EDV in der öffentlichen Verwaltung. Die Nutzer haben sich im IT Service Management Forum (ITSMF, [1]) zusammengeschlossen. Die Originalsprache der Bücher ist also Englisch, die deutsche Übersetzung behält die englischen Fachtermini bei. Somit kommt auch dieser Artikel an den fremdsprachigen Bezeichnungen nicht vorbei. Die ITIL 2 gliedert sich in insgesamt elf Bücher, die jeweils einen Satz von Prozessen und Methoden beschreiben, die für bestimmte Funktionen erforderlich sind. Der Übersichtlichkeit wegen verzichtet dieser Artikel darauf, die genauen Zuordnungen der Prozesse zu den Büchern zu erläutern. Die wichtigsten seien dem Namen nach erwähnt: Service Support, Service Delivery, Planning to Implement Service Management, Application Management, ICT Infrastructure Management, Security Management.

Doch zunächst ein paar Grundlagen, die für das Verständnis aller modernen Qualitätssicherungsmaßnahmen wichtig sind: “Was ist Qualität? – Der Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt.” Auch wenn diese Definition nicht der ITIL, sondern der ISO 9001 entstammt, beschreibt sie treffend, worum es geht: Es gilt, Merkmale zu identifizieren und Anforderungen festzulegen. Zudem sind Verfahren erforderlich, um die Merkmale zu messen.

Der Regelkreis

Alle heutigen QM-Welten kennen in der einen oder anderen Form einen Zyklus wie den PDCA (Plan, Do, Check, Act). Aktionen werden geplant, dann ausgeführt und überprüft, danach wird auf das Ergebnis der Prüfung reagiert. Diese Reaktion beeinflusst die nächste Planungsphase, und so schließt sich der Kreislauf (Abbildung 1). Dieser Regelkreis ist auch unter dem Schlagwort kontinuierliche Verbesserung bekannt.

Abbildung 1: Die Abfolge von Plan, Do, Check und Act gibt es so oder ähnlich in allen Systemen für Qualitätsmanagement.

Der wesentliche Unterschied zwischen Qualitätskontrolle und Qualitätssicherung (QS): Während die erste (aus der Frühphase der Industrialisierung stammend) nur die Produktqualität untersucht, damit keine schlechten Teile zum Kunden gelangen, führt die Qualitätssicherung eine Feedbackschleife ein, einen so genannten Regelkreis. Die Ergebnisse der Prüfung beeinflussen den Fertigungsprozess, sodass mehr Produkte die Prüfung bestehen.

Von Qualitätsmanagement (QM) spricht, wer die gesamte Organisation so ausrichtet, dass er nachvollziehbar und (vorab) gelenkt produziert.

ITIL-Terminologie

Wie viele Disziplinen pflegt auch das Qualitätsmanagement nach ITIL eine eigene Terminologie und definiert, was es mit welchem Begriff beschreibt:

Rolle: Eine Rolle ist eine – unter Umständen nur zeitweilige – Tätigkeit. Während in Unternehmen Stellen existieren (definierte Aufgabenbereiche, die vertraglich mit einem Mitarbeiter und einem Gehalt verbunden sind), gibt es in den meisten QM-Welten aus der Unternehmenshierarchie herausgelöste Tätigkeiten. Eine Rolle beschreibt, was zu tun ist. Sie ist ganz oder zeitweise mit einem Mitarbeiter besetzt, dem Rolleninhaber. Dieser kann wechseln. Eine Rolle kann auch mit mehreren Mitarbeitern besetzt sein, genau wie ein Mitarbeiter mehrere Rollen innehaben kann. Hier gibt es das geflügelte Wort von den Hüten, die eine Person aufhaben kann.

Ein Rolleninhaber darf zur Erreichung der in der Rolle festgelegten Ziele unter Umständen – zumindest theoretisch – auch Personen Anweisungen geben, die in der Hierarchie über ihm stehen. Eine Rolle ist in sich zielkonfliktfrei, das gilt jedoch nicht immer auch für die Mitarbeiter, wenn sie zugleich mehrere Hüte aufhaben, beispielsweise Security Manager und Incident Manager.

Prozess: Eine Abfolge von Tätigkeiten, die in Wechselwirkungen und -beziehungen stehen. Prozesse haben Eigentümer (Process Owner), die bestimmen, welche Abläufe im Prozess wie stattzufinden haben. Process Manager wiederum ist die Rolle jener Mitarbeiter, die Prozesse tagtäglich ausführen.

Kunde und Anwender: Wichtig ist in der ITIL-Welt auch die Unterscheidung zwischen Anwendern von IT-Systemen und Kunden. Der Begriff Anwender bezeichnet die (natürliche) Person, die tatsächlich eine konkrete Leistung der IT-Organisation in Anspruch nimmt, beispielsweise den Mitarbeiter vor dem PC, der eine Textverarbeitung startet.

In fast allen Fällen ist dieser Mitarbeiter jedoch nicht Kunde der IT-Organisation. Der Terminus Kunde bezeichnet jene verantwortliche Stelle, die mit der IT-Abteilung eine Leistung vereinbart, also das so genannte Service Level Agreement (SLA) abschließt. Konkret könnte das etwa der Abteilungsleiter des Mitarbeiters sein, der Installation und Betrieb der Textverarbeitung vertraglich geordert hat. Vereinfacht gesagt kommunizieren Kunden mit dem Service Level Management und Anwender mit dem Service Desk (Abbildung 2, [2]).

Abbildung 2: Anwender kommunizieren tagtäglich mit dem Service Desk. Der Kunde, beispielsweise die Abteilungsleitung, hat die Leistung beim Service Level Management bestellt. (Bild: © Kess DV-Beratung GmbH)

Übersicht über die Prozesse

ITIL definiert eine große Zahl von Prozessen, die miteinander interagieren. Die wichtigsten sind:

Incident Management: Die Unterscheidung zwischen Störungen und Problemen ist wichtig. Bei einer Störung (Incident) handelt es sich um die Unterbrechung einer vereinbarten Leistung. Ein Problem ist eine strukturelle Unzulänglichkeit, die in der Folge Störungen verursacht. Das Incident Management beseitigt aufgetretene Störungen zeitnah und dokumentiert dies. Bereits beim Anruf des Anwenders erstellt es ein Trouble Ticket, das die Störung bis zur Beseitigung begleitet und dann archiviert wird. Das Incident Management befasst sich nicht mit der Analyse der zugrunde liegenden Probleme.

Service Desk: Der Service Desk als Organisationseinheit verbindet den IT-Betrieb mit den Anwendern. An ihn wendet sich ein Anwender, wenn eine Unterbrechung der vereinbarten Leistung auftritt – ein Incident. Der Service Desk kann eine Erst-Entstörung vornehmen, dann spricht man vom Skilled Service Desk.

Problem Management: Dieser Prozess legt das Augenmerk nicht auf die rasche Beseitigung von Leistungsunterbrechungen, sondern auf die Analyse, die Schwachstellen im IT-System finden soll. Das Problem Management arbeitet auf Grundlage der Aufzeichnungen des Incident Management und beauftragt Experten damit, die Probleme entweder durch Lösungen zu beseitigen oder Umgehungslösungen (Workarounds) bereitzustellen, mit denen wiederum das Incident Management neu auftretende Störungen abstellen kann. Erarbeitet das Problem Management Lösungen, schickt es eine Bitte um Änderung an das Change Management. Dieser Prozess kann auch vorbeugend tätig sein.

Change Management: Jede Veränderung in der IT-Welt eines Unternehmens ist ein so genannter Change, der gelenkt werden muss. Ein Mitarbeiter beantragt Changes mit den verwirrenderweise RfC genannten Anträgen (Request for Change). Ein Change ist eine sehr formale Angelegenheit. Der Antragsteller füllt ein Formular aus, das beschreibt, was zu ändern ist, wer es ändern soll, welche Auswirkungen die Änderung hat und so weiter. Das Change Management verwaltet diese Anträge, ein Change Advisory Board entscheidet über sie. Dieses Beratungsgremium setzt sich je nach Bedeutung des Change aus Entscheidern und Experten sowie unter Umständen auch Sicherheitsbeauftragten zusammen. Um wiederkehrende Changes nicht jedes Mal erneut bewerten zu müssen, gibt es auch so genannte Routine Changes, die nach erfolgreicher Umsetzung für die Zukunft freigegeben sind.

Release Management: Zusammenfassungen von Configuration Items (Hard- und Software), die die erforderlichen Tests bestanden haben und nun ausgebracht werden sollen, nennt man Releases. Testen, Integrieren und Archivieren sowie erfolgreiche Rollouts stehen im Fokus des Release Management. Wichtig ist außerdem, dass beispielsweise Software-Rollouts die korrekten Versionen ausliefern, auch dies ist Aufgabe dieses Prozesses.

Configuration Management: Hier steht die Dokumentation im Mittelpunkt. Die CMDB, Configuration Management Database hält die Dokumentation vor (Abbildung 3). Die Informationen konzentrieren sich auf die Betriebsmittel und Prozesse. Daher stellen sie eher einen Teil einer Dokumentenlenkung dar, wie sie beispielsweise ISO 9001 kennt.

Capacity Management: Ein Unternehmen möchte seine Hard- und Software effizient einsetzen. Capacity Management sorgt dafür, dass dies optimal geschieht, außerdem liefert es dem Problem Management Informationen und bezieht selbst welche von ihm.

Availability Management: Größere Firmen müssen zudem die Verfügbarkeit von Leistungen steuern. Das Availability Management definiert die angebotenen Abstufungen der Verfügbarkeit und setzt sie um, auch hier besteht eine Schnittstelle zum Problem Management.

Service Level Management: Dieser Prozess schreibt die Qualitäten, also die Inhalte der Leistungsvereinbarungen mit den Kunden, fest. Daneben verhandelt das SLM die konkrete Umsetzung dieser Anforderungen.

Security Management: Ein Unternehmen muss seine IT-Systeme aus vielen Gründen gegen missbräuchliche Verwendung schützen. Das Security Management kümmert sich um Sicherheitsanforderungen gemäß den Leistungsvereinbarungen (SLAs) sowie den gesetzlichen und unternehmenspolitischen Anforderungen.

IT Service Continuity Management: Dieser Prozess plant Maßnahmen, die den Betrieb im Katastrophenfall sicherstellen sollen. Der Plan definiert technische, organisatorische und finanzielle Anforderungen, um im Falle großer Schwierigkeiten die vereinbarten Leistungen gewährleisten zu können.

Supplier Management: In diesem Prozess stellt die IT-Abteilung eines Unternehmens eine geordnete Beziehung zu seinen (externen) Dienstleistern her. Sie beurteilt Lieferanten und wählt sie aus. Deneben legt sie die Art und Weise der Kommunikation mit externen Dienstleistern des Unternehmens fest.

Finance Management für IT Services: Das Finance Management sorgt dafür, dass der gesamte IT-Betrieb betriebswirtschaftlich funktioniert. Es schafft Kostentransparenz, die saubere Kalkulationen ermöglicht und eine Verfolgung der Kostenentwicklung erlaubt. Außerdem schafft das Finance Management die Abrechnungsmöglichkeiten für interne und externe Kunden.

Abbildung 3: So unterstützen sich wichtige ITIL-Prozesse: Sie kommunizieren untereinander und produzieren beziehungsweise konsumieren die Informationen in der zentralen Datenbank CMDB. (Bild: © Kess DV-Beratung GmbH)

Das ist neu an der ITIL 3

Am Kern von ITIL ändert sich mit der ab Sommer 2007 stufenweise eingeführten Version 3 nur wenig. Niemand muss sich re-zertifizieren, der ITIL-2-Zertifikate besitzt. Es gibt fünf Core-Bücher, die wie in Abbildung 4 beschrieben auf Hub (Achse), Spokes (Speiche) und Rim (Felge) eines gedachten Rades positioniert sind: Service Strategy, Service Design, Service Transition, Service Operation und Continual Service Improvement. Ein ausführliches Glossar [4] beschreibt die wichtigsten ITIL-Termini. Diese Kernbücher sind nun aus einem Guss. Bei ITIL 2 merkte man an manchen Stellen die verschiedenen Fertigstellungsdaten. Allerdings ist jetzt der ganze Satz Bücher notwendig – sich wie früher auf die ersten zwei zu beschränken ist nicht mehr möglich. Drei weitere Werke sollen noch erscheinen. ITIL kümmert sich ab Version 3 um die so genannten Service Lifecycles und möchte eine Integration von IT und Business erreichen. Aus diesem Grund nimmt das Werk mehr Bezug auf Geschäftsprozesse als früher. Statt nur eine Sammlung von Prozessen zu sein, vertritt ITIL jetzt eine ganzheitliche Sicht, die im Englischen als “holistic service management lifecycle” bezeichnet wird. Service Strategy Dieser Band beschreibt die notwendige Servicestrategie der Organisation. Während des Service Lifecycle ist die Unterstützung des Geschäfts des Unternehmens von zentraler Bedeutung. Der Band definiert Ziele und Anforderungen sowie Prinzipien wie beispielsweise das Outsourcing. Kosten und Risiken eines Serviceportfolios müssen überblickbar sein. Das Serviceportfolio ist die Sammlung aller Services, nicht nur der für den Kunden sichtbaren – die stehen im Service Catalogue. Effizienz bleibt wichtig, ist aber nicht ausreichend. Rollen in diesem Teil sind etwa Service Owner und Process Owner. Service Design Strukturierte Richtlinien und Prozesse helfen dabei, aktuelle wie zukünftige Anforderungen zu erfüllen. Die Prozesse zum Betrieb der IT-Services sind hier zusammengefasst, das Werk hat daher ein ähnliches Ziel wie das Service-Delivery-Buch: Service Level Management, Service Catalogue Management, Capacity, Availability und Service Continuity sowie Information Security und Supplier Management. Services müssen sich ändern und verbessern, um dem Kunden besser zu dienen. Rollen sind unter anderem Service Catalogue Manager, Service Level Manager, Availability Manager, Security Manager. Service Transition Das Einführen von Services ist logischerweise Teil eines Lifecycle. Die Überführung solcher Services in den täglichen Betrieb muss natürlich genauso strukturiert gelöst sein wie alles andere. Leistungsunterbrechungen soll das System von vornherein minimieren. Zusammen mit dem Management des verfügbaren Wissens (Service Knowledge Management) wird hier eine Anforderung umgesetzt, die schon die ISO 20 000 aufgestellt hat. Change und Release Management bilden daher logische Teile dieses Werks. Zu den Rollen zählen Service Transition Manager, Service Test Manager, Release Package and Build Manager sowie Deployment Manager. Service Operation Das Erbringen der Leistungen und die Kontrolle des Erfolgs sind hier zusammengefasst, also der tägliche Betrieb. Prozesse aus Service Support, Application und Infrastructure Management, aber auch Service Delivery finden sich wieder. Der Servicebetrieb muss stabil ablaufen, aber auch effektiv. Zum Incident und Problem Management gesellen sich Event und Access Management sowie Request Fulfillment. Rollen sind beispielsweise Service Desk Manager und Analyst. Continual Service Improvement Kontinuierliche Verbesserung findet im Continual Service Improvement ihren Niederschlag. Die Mitarbeiter müssen Service wiederholbar erbringen, mit konstanter Qualität. Die Lenkung der Fähigkeit, dies zu tun, ist der Kern des Qualitätsmanagements. Es kombiniert mehrere Prinzipien, fügt aber auch neue hinzu, etwa das Service Measurement. Von der ISO 20 000 übernimmt ITIL 3 das Feedback-System. Rollen sind unter anderem Service Manager, CSI Manager oder Reporting Analyst. Konsequenter und mit Liebe zum Detail Die ITIL erweitert ihren Horizont. Von der rein strategischen Ebene geht sie jetzt auch zur taktischen über und betrachtet Teilabschnitte von Aufgaben, etwa die Phasen des Lifecycle. Manche Abschnitte gehen sehr nah an die technische Ebene. So teilen sich nun beispielsweise die Aufgaben des Service Level Management (SLM) in Service Portfolio Management, Service Catalogue Management, Service Level Management und Service Reporting. ITIL bleibt sich treu. Allerdings zieht sie einige Ansätze jetzt konsequenter und vor allem vollständiger durch. Eine Rumpf-ITIL (nur Service Delivery, Service Support) ist kaum mehr vorgesehen. Die verbesserte Verzahnung mit Geschäftsprozessen dürfte die Akzeptanz in Unternehmen erhöhen. Wer ISO 20 000 verwendet, dem wird dies vermutlich entgegenkommen. Eine leichte Annäherung in Richtung ISO 9001 könnte ITIL auch in der Industrie beliebter machen. Dennoch ist eine Umsetzung von ITIL 3 mit Aufwand verbunden. Viele der feingliedrig gestalteten Prozesse sind für die größten der großen Unternehmen sinnvoll, kleinere Organisationen werden hier Prozesse und auch Rollen zusammenfassen. Abbildung 4: Die Bestandteile von ITIL in der Version 3.

Kein Patentrezept

Ein Zitat aus dem ITSMF-Buch “IT Service Management – eine Einführung” [3] macht zum Schluss klar, worum es bei ITIL nicht geht: “Die Praxis zeigt, dass […] eine Warnung angebracht ist: ITIL ist keine Zauberformel. Erwarten Sie keine Wunder. ITIL beschreibt Best Practices zur Verbesserung der IT-Service-Management-Prozesse, bietet aber keine Patentrezepte für IT-Organisationen. ITIL liefert hauptsächlich einen Referenzrahmen für die Prozesseinrichtung innerhalb der IT-Organisation und viel weniger eine Richtlinie für die Organisationsstruktur.”

Es bleibt: Eine Kosten-Nutzen-Rechnung

ITIL allein macht die IT-Abteilung eines Unternehmens nicht von heute auf morgen effizient. Zudem sorgen die Rolleneinteilung sowie die Rollenbesetzung mit mehreren Personen, die oft nicht mit der hierarchischen Struktur des Unternehmens übereinstimmen, für zusätzliche Kommunikation, das heißt, es entsteht ein gewisses Maß an Mehraufwand.

Ob und in welchem Grad sich dieser Mehraufwand durch Vermeidung von Doppelarbeit aufgrund der verbesserten Dokumentation ausgleichen lässt, ist kaum vorhersagbar.

Auf jeden Fall wird der Betrieb einer IT-Organisation durch Qualitätsmanagement nach ITIL aber berechenbarer und verlässlicher. Es ist daher absehbar, dass ITIL beziehungsweise die ISO 20 000 im IT-Bereich eine ähnliche Stellung erreichen werden wie die ISO 9001 im produzierenden Gewerbe. (mhu)