Zwischen Entwicklung und Betrieb

27.09.2007
Von Björn Hinrichs 
Das dritte Itil-Buch "Service Transition" beschreibt, wie sich Designideen in die Praxis überführen lassen.
Die Itil-Version 3 führt erstmals das Konzept des "Early-Life" ein. Hier tragen Transition und Operation gemeinsam die Verantwortung für den Service.
Die Itil-Version 3 führt erstmals das Konzept des "Early-Life" ein. Hier tragen Transition und Operation gemeinsam die Verantwortung für den Service.

Kaum eine Schnittstelle innerhalb der IT-Organisation ist derart belastet und von Schwierigkeiten geprägt wie die zwischen den Entwicklungs- und Betriebsabteilungen. Umso höher sind die Erwartungen, wenn Itil in der neuen Version 3 dieser Konstellation nicht nur wie in der vorangegangenen Ausführung zwei oder drei Prozesse widmet, sondern gleich einen eigenen Band.

Head

Text

Service Transition bildet gemeinsam mit Service Design und Service Operation den inneren Service-Lifecycle. Er dreht sich um den Kern der Service Strategy, und er ist von den Konzepten des Continual Service Improvement (CSI) umgeben beziehungsweise durchdrungen.

Analogie zum Rad

Das für das Modell gewählte Bild trifft in vielerlei Hinsicht zu: Ein Rad, das ohne die Führung einer Radnabe angestoßen wird, gerät nach ein paar Metern ins Trudeln und fällt letztlich um. Analog dazu kann auch der Service-Lifecycle ohne die Führung der Strategie auf Dauer nicht die Richtung halten. CSI kommt die Aufgabe zu, den Schwung aufrechtzuerhalten, damit das Rad nicht stillsteht und die Strategie in Bewegung umgesetzt wird.

Für die drei Phasen in der Mitte bedeutet dies aber auch: Nur ein ausgewogenes Gewicht gewährleistet eine vibrationsfreie und richtungsstabile Fahrt. Jedes unangemessene Übergewicht in einer der Phasen erzeugt eine Unwucht im gesamten Service-Lifecycle.

Dies kann für die eine oder andere IT-Organisation zur Herausforderung werden, stehen doch viele von ihnen noch in einem ausgedehnten Kräftemessen zwischen Entwicklung und Betrieb. Was soll da jetzt noch ein dritter Faktor?

Die Grenzen sind bewusst offen

Die Aufgabe, die Service Transition erfüllen soll, ist weit mehr als die eines Schiedsrichters oder einer Schutztruppe zwischen den Streithähnen Entwicklung und Betrieb. Service Transition übernimmt die Verantwortung dafür, die im Service-Design-Package (SDI) angelegte Umsetzung der Servicestrategie Wirklichkeit werden zu lassen, also Services und Infrastrukturen in geordneter, kontrollierter und nachvollziehbarer Weise in den Betrieb zu überführen.

Die Grenzen zu den Phasen Service Design und Service Operation sind dabei bewusst offengehalten. Es gibt zu beiden Phasen Übergangsbereiche mit gemeinsamer Verantwortung.

Der Umfang ("Scope") der Service-Transition-Phase ist klar gegliedert: Der Prozess "Service Transition Planning and Support" trägt die übergeordnete Verantwortung für die Planung und Steuerung der Gesamtphase. Diese Verantwortung beginnt und endet weit außerhalb der Grenzen der eigentlichen Transition-Phase.

Für den Übergang in den Betrieb führt die Itil-Version 3 das Konzept des "Early Life" ein. In dieser Phase tragen Transition und Operation gemeinsam die Verantwortung für die IT-Services, die Service-Level-Agreements (SLAs) gelten noch als Pilot, und die Prozesse der Service Transition leisten den "Early-Life-Support". Erst zum Ende des Early Life werden die Services endgültig abgenommen und die SLAs scharf geschaltet.

Aus drei werden sieben Prozesse

In der Version 2 kam Itil mit drei Prozessen aus, um Serviceänderungen in den Betrieb zu überführen und die Serviceinfrastruktur zu dokumentieren. Die neue Version wartet gleich mit sieben Prozessen auf.

Hier wies Itil V2 eklatante Schwächen auf sowohl in den Beziehungen der drei Prozesse untereinander als auch in deren Verhältnis zu den angrenzenden Prozessen. Doch die Vielzahl der Prozesse in der neuen Service-Transition-Phase bedeutet für viele Service-Manager eine erhebliche Herausforderung. Wie viele Organisationen sich ihr stellen und dieses umfangreiche Konzept vollständig einführen, muss sich erst noch zeigen.

Innerhalb der sieben Prozesse lassen sich zwei Kategorien unterscheiden. Da sind zum einen die Prozesse, die den gesamten Lifecycle unterstützen. Sie betreffen auch Service Strategy, Service Design, Service Operation und Continual Service Improvement. Dazu gehören das Change-Management, das Service-Asset- und Konfigurations-Management sowie das Knowledge-Management.

Zum anderen gibt es die Prozesse, die ihren Fokus primär auf die Aktivitäten der Service Transition legen. Dazu zählen das Release- und Deployment-Management sowie "Service Testing and Validation", "Evaluation of a Change or Service" und der eingangs erwähnte Prozess Transition Planning and Support.

Trotz der gestiegenen Komplexität im Gesamtmodell der Prozesse bringt die Itil-Version 3 deutlich mehr Klarheit in die Verteilung der Aufgaben, Kompetenzen und Verantwortungen. Ob es die Schnittstelle zwischen Change- und Release-Management ist oder die Rolle des "Change Advisory Board" viele Unklarheiten der Version 2 sind in den neuen Büchern bereinigt worden.

Der Prozess Service Transition and Support plant und steuert die gesamte Lifecycle-Phase. Change-Management stellt sicher, dass Änderungen auf kontrollierte Weise registriert, bewertet, autorisiert, priorisiert, ge-plant, geprüft, vollzogen, dokumentiert und nachgeprüft werden. Die Betonung liegt hier auf der administrativen Kontrolle und Steuerung. Den Vollzug der Change-Entwicklung und der Auslieferung von autorisierten Veränderungen übernimmt dann das Release- und Deployment-Management.

Tests als interner Dienst

Neu hinzugekommen ist Service Testing and Validation. Dieser Prozess übernimmt vom Release- und Deployment-Management das Testen einer Änderung oder eines neuen Release quasi als eine interne Dienstleistung. Damit lassen sich die Verantwortlichkeiten für Entwicklung und Test auch in den Prozessen unterscheiden. Der Umfang der Tests erstreckt sich dabei nicht nur auf technische Details. Vielmehr zielt er insbesondere darauf ab, zu prüfen, inwieweit der in der Strategie und im Design geplante Nutzen für den Kunden auch erreicht wird.

Service-Asset- und Konfigurations-Management stellt ein logisches Modell aller Service-Assets und Configuration-Items bereit. Es umfasst die gesamte Infrastruktur und alle Anwendungen, die für die Servicebereitstellung erforderlich sind, sowie alle wichtigen Dokumente und Dokumentationen.

Abschied von zentraler CMDB

Die neue Itil-Version verabschiedet sich endgültig von der Idee einer zentralen Configuration-Management-Datenbank (CMDB). Sie setzt stattdessen auf ein Configuration-Management-System. Es besteht aus einer Vielzahl unterschiedlicher Sichten und Präsentationsformen, die auf die vielfältigen physischen Datenbanken und auf weitere Quellen zurückgreifen.

Der Prozess des Knowledge-Managements ist ebenfalls neu. Seine Aufgaben, Ziele und Herausforderungen sind im Prin-zip die gleichen, mit denen sich die Manager des oftmals un-ternehmenskritischen Wissens heute auch ohne Itil schon herumschlagen. Eine konsequente und klare Einbettung dieses Prozesses in den Service-Lifecycle vervollständigt das Gesamtbild der neuen Itil-Version und bietet denen, die das Knowledge-Management betreiben, endlich einen Platz im Service-Management-System.

Prinzipien und Ergänzungen

Ein zentrales Prinzip innerhalb der Service-Transition-Phase ist die Adaption des "V-Modells". Es dient der Zuordnung definierter Ebenen der Testrealisierung. Konkret zeigt es auf, wie die Spezifikationen der Business-An-forderungen ("Requirements") im Rahmen des Service Design und in der Service Transition weitergeführt und detailliert aufgearbeitet werden. Parallel dazu betrachtet es die Validierungsmaßnahmen, mit denen sich die Services offiziell abnehmen und in den Betrieb überführen lassen.

Diese Maßnahmen müssen mit der jeweiligen Stufe der Requirements-Bearbeitung übereinstimmen, und im Einklang damit werden die Organisationen beziehungsweise Mitarbeiter eingebunden. Den Startpunkt jeglicher Aktivitäten bilden immer die Anforderungen des Kunden bezüglich eines Service.

Ein weiteres durchgängiges Konzept der Service Transition betrifft die "Stakeholder-Analyse" und das "Stakeholder-Management". Stakeholder sind hier diejenigen, die im sprichwörtlichen Sinne Aktien in einem Thema oder einem Projekt haben. Alle Beteiligten in allen Prozessen der Service-Transition-Phase haben die Aufgabe, die Ergebnisse, Erwartungen und vielfältigen Kommunikationsbeziehungen zu steuern, die sich auf diese Stakeholder beziehen.

Inhaltlich etwas kurz ausgefallen

Neben den Kapiteln zu Prozessen und Querschnittsthemen bietet der Band 3 der neuen Itil-Version noch einige kurze Abschnitte zum unterstützenden Technik-einsatz, zu Herausforderungen und Risiken sowie zur Einführung der Konzepte in einer IT-Organisation. Diese Abschnitte sind etwas kurz ausgefallen. Sie lassen ausreichend Raum für die geplanten ergänzenden Bücher der "Complementary Guidance". Hier hätten sich die Nutzer doch etwas mehr Substanz gewünscht.

Fazit: Die Good-Practice-Ansätze und Konzepte der Service Transition bieten einen umfangreichen Ansatz zur Gestaltung der Schnittstelle zwischen Entwicklung und Betrieb. Fehler und Unschärfen der Version 3 wurden bereinigt und einige ergänzende Konzepte eingeführt, die bislang nur außerhalb von Itil existierten. Auch in dieser Hinsicht ist Itil erwachsener geworden.

Große Organisationen werden die Vielzahl der Prozesse und Rollen ohne größere Schwierigkeiten abbilden können. Für kleinere Organisationen kommt es darauf an, sinnvoll zu bündeln.

Einen Band "Small Scale Implementations" gab es schon für die Itil-Versionen 1 und 2. Für die neue Ausführung wird er wahrscheinlich nicht lange auf sich warten lassen. (qua)