Von Thomas Bez, TEDESCA Unternehmensberatung www.tedesca.com, Januar 2010.

Einleitung

Auch wenn man in der Praxis eines Service Management Projektes (zum Beispiel die Restrukturierung eines Servicebereiches, die Entwicklung von SLA und dem Aufbau eines Service Level Management, einem Service Outsourcing etc.) selten nach ausschließlich einer "reinen Lehre" vorgeht, ist die Orientierung an einer Methodik bzw. einem Referenzmodell (Framework) unbedingt erforderlich. Solche Referenzmodelle beginnen ihre Entwicklung in einem bestimmten Industriesektor bzw. einer Branche, entwickeln sich im Laufe der Jahre über mehrere Releases weiter, sofern sie erfolgreich sind und nicht wieder aussterben. Ein aussterbendes oder ausgestorbenes Referenzmodell in der Telekommunikation ist den älteren Semestern noch unter dem Namen "FCAPS" erinnerlich, einem inoffiziellen Akronym, das das ziemlich simple Prozeßmodell aus dem ITU-T Standard M.3400 mit seinen fünf Funktionsbereichen meint.

Viele dieser Referenzmodelle zeigen die Tendenz, im Laufe ihrer Entwicklung universeller zu werden und zumindest den Anschein zu erwecken, daß ihre Konzepte über den Industriesektor hinausreichen, für den sie ursprünglich geschaffen wurden. Wir selbst sind mit zwei dieser Frameworks ganz besonders vertraut:

• ITIL (IT Infrastructure Library), einer Sammlung von "Best Practices" oder neuerdings etwas bescheidener "Good Practices" aus dem IT Service Management, ohne die im IT-Servicebereich nichts mehr geht,
• eTOM (Enhanced Telecommunications Operations Map) des TeleManagement Forum, das sich immer stärker als de-facto Standard für die Gestaltung der Geschäftsprozesse in der Telekommunikationsindustrie durchsetzt.

Wir wollen aufzeigen, (A) daß ITIL tatsächlich den Ansatz zeigt, universell für das Service Management auch jenseits der IT zu werden, und (B) inwieweit dies speziell für die Telekommunikation gilt durch eine Anwendung parallel zu den Standards des TeleManagement Forum.

Anwendbarkeit des ITIL Lebenszyklus

Wenn wir für die einzelnen Prozesse der fünf Lebenszyklusphasen ermitteln (oder abschätzen), wie stark sie in Spezifiken der IT verhaftet sind, differenzieren wir einerseits nach der Methodik, die ITIL entwickelt (z.B. Prozeßsteuerung, Rollen, RACI-Matrizen), und andererseits den konkreten Objekten (z.B. KPI, Assettypen, Ressourcen, Fähigkeiten) mit denen ITIL operiert. Die konkreten Objekte sind naturgemäß stärker IT- oder branchenspezifisch. Da ITIL selbst auch keinen Versuch unternimmt, diese Objekte zu standardisieren, sondern ausdrücklich ein Good Practice Framework ist, bleibt die Bandbreite der Anwendbarkeit von ITIL-Methodik hoch. Wo der Prozeß andererseits stark von den behandelten Objekten abhängt, ordnen wir den Prozeß insgesamt dem "eher IT-spezifischen" Bereich zu. Einleuchtende Beispiele dafür sind Capacity Management oder Access Management.

Sieht man sich das Prozeßtemplate der ITIL an, das sich in die Bereiche Process Control, den eigentlichen Prozeß sowie Process Enablers aufspaltet, so kann man feststellen, daß Branchenspezifika vor allem den Bereich der Enabler (insbesondere Ressourcen und Fähigkeiten = Capabilities) betreffen.

KPI sind nicht notwendigerweise IT- bzw. branchenspezifisch. Je nach ihrer Position im Kennzahlsystem und insbesondere, wenn es sich um aggregierte Verhältniszahlen handelt, was häufig der Fall ist, können KPI-Schemata auch aus anderen Industriesektoren "kopiert" werden - ganz im Sinne der Nutzung einer "Good Practice". Eine prozentuale Verringerung der Wiederherstellzeit (MTRS) im Berichtszeitraum (ein Beispiel aus dem Availability Management) läßt sich für beliebige Services ermitteln.

Wir haben selbst in einem einige Jahre zurückliegenden Projekt "Mobile Virtual Network Enabler" (MVNE) die IT-fremde Anwendung der ITIL-Methodik (seinerzeit auf Basis v2) selbst versucht und waren mit dem Ergebnis zufrieden. Das Projekt verlangte die Koordination mit mehreren externen und internen Dienstleistern (Typen 2 und 3 nach ITIL Terminologie). Betroffen waren die Prozesse

• Event/Incident/Problem Management,
• Change Management/Request Fulfillment,
• Service Level Management.

Insbesondere die gemeinsame, abgestimmte Definition der Betriebsprozesse und -prozeduren, das Aufsetzen des SLA-/OLA-Management sowie die Definition des Service Desk wurden durch die gewählte Vorgehensweise erleichtert.

Verbesserungen mit ITIL v3

Version 3 von ITIL hat sich zum Ziel gesetzt, die IT an den jeweiligen Geschäftsprozessen auszurichten, denen sie dienen soll, und die IT stärker an die Unternehmensziele zu binden. Daher liegen die auffälligsten Neuzugänge in ITIL Version 3 in den Bereichen Service Strategy, Continual Service Improvement (diese beiden Lebenszykluselemente sind komplett neu) und Service Operation. Service Strategy und Continual Service Improvement sind allerdings in den ITIL-Büchern noch in einer Weise beschrieben, die die Verallgemeinerung auf andere Kategorien von Services nicht behindern kann. Die Bedeutung von ITIL v3 sehen wir darin, daß die Beziehung der IT zum Kerngeschäft des Unternehmens und die Rolle der IT als dienender Technologie herausgearbeitet wurde. Das ist eine Sichtweise, die es auch für andere Services aufzugreifen lohnt.

Es sollte eigentlich überraschen, daß gerade Service Operation, das man als den ursprünglichen Kern von ITIL betrachten kann (da dort die vom Kunden wahrgenommene Wertschöpfung stattfindet), mit ITIL Version 3 eine starke Erweiterung erfahren hat. Immerhin kamen dazu:

• Event Management
• Request Fulfillment
• Access Management

Allerdings sind gerade das die Prozesse, die wir selbst in ITIL Version 2 am stärksten vermißt haben. Im schon erwähnten Beispielprojekt MVNE haben wir das Event Management als Teil des Incident Management eingeordnet und das Request Fulfillment auf das Change Management abgebildet - wo beide Prozesse jeweils nicht besonders gut hinpassen. Besonders für jemanden, der aus der Telekommunikationswelt kommt, ist das ITIL-Framework ohne diese Erweiterungen schlichtweg unvollständig.

Wir haben hier Event Management als generisch eingeordnet. Zwar sind die Events und die Tools (z.B. Monitoringsysteme) branchenspezifisch, der Prozeß selbst ist aber relativ simpel und allgemeingültig. Ähnlich steht es um das Request Fulfillment. Es fällt auf, daß ITIL mit Version 3 gerade in den stärker generischen Prozessen seine Erweiterungen erfahren hat. Das belegt unsere eingangs geäußerte These vom zunehmenden Allgemeinheitsgrad von Referenzmodellen im Lauf ihrer Evolution.

Das Request Fulfillment nimmt im ITIL Buch über Service Operation nur einen schmalen Raum ein. Da das Request Fulfillment die Standard Changes beinhaltet, kann in anderen Branchen die bedeutung des Prozesses deutlich größer sein. Augenfällig wird das für die Telekommunikation, wenn man die Level 2 und 3 der eTOM-Definition der Fulfillment-Prozeßkette betrachtet. Fast alle diese Teilprozesse, die sich bis in Logistik und Field Provisioning erstrecken (man denke an die Bereitstellung eines DSL-Anschlusses), fallen nach ITIL-Termini unter Request Fulfillment. Daß ITIL in diesem Bereich aber noch immer von anderen Voraussetzungen ausgeht, kann man daran erkennen, daß der Service Desk als zentrale Stelle der Abarbeitung von Service Requests gesehen wird.

Der Service Desk, obwohl kein Prozeß, sondern eine Funktion, ist im Bild mit gezeigt. Als Single Point of Contact für den Kunden wird ein Service Desk zwar im Prinzip immer gebraucht, seine Ausgestaltung in ITIL scheint uns aber nicht ohne weiteres verallgemeinerungsfähig. Ebenfalls eine Sonderrolle spielen die Common Service Operation Activities, manchmal auch "Daily Operations" genannt. Als unstrukturierte Sammlung von Aufgaben werden sie selbst von ITIL stiefmütterlich behandelt. Man kann das vielleicht so erklären, daß diese Tätigkeiten (wie z.B. regelmäßig Backups ziehen) nicht auf explizite Service Requests zurückgehen und in der IT meist aus einer Hand, also ohne zusätzliche Prozeß- oder Providerschnittstellen, erbracht werden. Jedenfalls entziehen sich die Common Service Operation Activities, so wie sie in ITIL beschrieben sind, jeder sinnvollen Verallgemeinerung. Man führe sich vor Augen, daß solch aufwendige Prozesse wie Preventive Maintenance darunter fallen.

Bezüglich Continual Service Improvement, insbesondere der Governance, ist zu beachten, daß für die Bewertung der real existierenden Prozesse hinsichtlich Compliance und Reifegrad eine Reihe von Standards existiert, die in Teilbereichen auch konkurrieren. Zu nennen wären neben dem ITIL-eigenen Process Maturity Model (PMM), das auf CMM basiert, noch COBIT und das sehr neue "CMMI for Services". Weitere separate Standards existieren zum IT Security Management (ISO 27001) und zum Business Continuity Management (BS 25999).

In den hier aufgezeigten Grenzen halten wir die Methodik von ITIL auch für Services anwendbar, die ihrer Natur nach keine IT-Services sind. Das folgende Bild soll Beispiele solcher Services verdeutlichen.

Die Frameworks des TMF

Das TeleManagement Forum (TMF) ist keine klassische Standardisierungsorganisation wie zum Beispiel die ITU-T, sondern ein unabhängiges Industriekonsortium von Telco-Netzbetreibern, -Herstellern und Dienstleistern. Das ist vermutlich sein größter Vorzug, da dies die Schwerfälligkeiten der klassischen Telco-Standardisierung überwunden hat.

Dieser Kurzüberblick ist keine Einführung in eTOM; TMF selbst bietet für diesen Zweck ein Primer-Dokument an. Wir haben die Ehre, selbst Mitglied des TMF zu sein, und beraten gern zu Inhalten und Anwendung der Standards.

Das TMF hat eine Reihe von aufeinander aufbauenden Frameworks und Entwicklungs- bzw. Marketingaktivitäten auf den Weg gebracht, die zusammen dem einen Ziel dienen, das schon im Namen der Organisation festgeschrieben ist: dem Management von Telekommunikationsnetzen. Diese Frameworks sind:

• NGOSS (Next Generation Operations Support and Software) setzt sich zur Aufgabe, TK-Serviceprovidern interoperable Lösungen zum Management ihrer Services und Netze an die Hand zu geben
• eTOM (Enhanced Telecommunications Operations Map) ist das Prozeßmodell hinter allen Aktivitäten des TMF, das eine sehr TK-spezifische Sicht auf die Geschäftsprozesse eines Betreibers zeichnet
• TAM (Telecom Applications Map), eine nicht bindende Übersicht über Applikationen bzw. Applikationsfunktionen von OSS, die für die Erfüllung der eTOM-Prozesse erforderlich sind
• SID (Shared Information/Data Model), ein Fundus objektorientierter Informationsmodelle, die die Schnittstellen zwischen OSS oder Applikationen (im Sinne der TAM) beschreiben
• eine Reihe weiterer Aktivitäten, zum Beispiel Technologie- und Showcase-Programme, die die Interoperabilität von OSS-Lösungen praxisnah demonstrieren sollen, sowie Zertifizierung von OSS-Lösungen auf Konformität zu den TMF-Standards

Der Funktionsbereich "Strategy, Infrastructure & Product" wurde mit eTOM Release 3 in den frühen 2000er Jahren eingeführt. Somit verfügte die Telekommunikationsindustrie schon relativ früh über ein Referenzmodell, das alle wesentlichen Geschäftsprozesse abdeckt. Die Enterprise Services liegen eindeutig nicht im Fokus des TMF. Sie sind dem Referenzmodell offenbar der Vollständigkeit halber hinzugefügt, ermangeln aber einer detaillierteren Beschreibung.

Die Zuordnung der einzelnen Prozesse bzw. Lebenszykluselemente, die unser Bild zeigt, ist nur eine grobe Annäherung.

Das NGOSS-Programm läßt sich am besten anhand der historischen Entwicklung der Hersteller-Netzbetreiber-Beziehungen verstehen. Die Telekommunikationswelt ist geprägt von proprietären Lösungen, sozusagen Firmen-"Standards" der Hersteller, die zwar auf der Netzebene weitgehend interoperabel sind, nicht jedoch in ihrem Management. Netzbetreiber haben ihre eigenen Operations und Business Support Umgebungen entwickelt und über viele Jahre weiterentwickelt.

Aus Wettbewerbs- und wirtschaftlichen Gründen drängen TK-Netzbetreiber seit langem auf standardisierte Schnittstellen im Netzmanagement und auf mehr Flexibilität bei der Beschaffung von Operations Support Systemen auf der Basis von Standards und existierenden Systemlösungen (Commercial off-the-shelf Software, COTS).

Die mittlerweile zahlreich gewordenen unabhängigen Hersteller von (IT-basierten) Operations Support Systemen benutzen das TMF, um ihre Lösungen zu positionieren und zu propagieren. So hört man über das TMF manchmal die aus der Sicht dieser Hersteller formulierte Aussage "It is a big marketing engine." Andererseits ist uns die Einschätzung eines Managers der British Telecom in Erinnerung, der meinte "TMF is the only serious player in town."

Harmonisierung von TK- und IT-Standards

Die Telekommunikationswelt hat Gründe, sich um eine Harmonisierung ihrer Standards mit denen der IT-Welt zu bemühen, da die IT aus ihrer reinen Supportrolle (z.B. die Informationsinfrastruktur für den Netz- und Servicebetrieb oder die benötigten OSS-Applikationen bereitzustellen) herausgewachsen ist. IT wird zunehmend Teil des Telekommunikationsprodukts. Andererseits nimmt der Grad des Outsourcing von Betriebsfunktionen zu, die häufig von nicht TK-spezialisierten Providern übernommen werden.

Versuche, die Prozeßmodelle von TMF und ITIL über die gesamte Service-Wertschöpfungskette oder auch nur für die operativen Prozesse zur Deckung zu bringen, müssen aber scheitern. Es ist vielleicht möglich, aber nicht angemessen, die "Services", von denen eTOM spricht (Services, die als TK- oder Content-Produkte durch einen TK-Provider vermarktet werden), mit den Services von ITIL zu identifizieren. Beide Referenzmodelle haben eine unterschiedliche Granularität und Skala im Sinn, wenn sie von Services sprechen.

Weitere augenfällige Unterschiede zwischen beiden Welten sind:

• Das Accounting und Billing spielt in der Wertschöpfung des TK-Serviceproviders eine herausragende Rolle. Dieses Thema ist in ITIL praktisch nicht repräsentiert, da die Abrechnung von IT-Services anderen Prämissen folgt und eine um Größenordnungen geringere Komplexität aufweist.
• Die in eTOM vorgenommene Dreiteilung in Customer Relationship, Service und Resource (Network) Management spiegelt genau wider, wie TK-Serviceprozesse ablaufen und Provider organisiert sind - bis hinein in die statische Organisation. Die Unterscheidung dieser Ebenen ist der IT und damit auch ITIL fremd.
• Die Aufgaben eines Service Desk gemäß ITIL verteilen sich im eTOM-Modell über etwa 30% aller operativen Level-2-Prozesse.
• Eine CMDB ist dem Management von Telekommunikationsnetzen (noch) fremd. SID hat inhaltlich keine Ähnlichkeit mit der CMDB; am nächsten kommen ihr noch die Service und Network Inventories, wobei letzteres gelegentlich nur rudimentär erfaßt ist.

Wenn ein Telekommunikationsservice durch mehrere Provider gemeinsam erbracht wird, kann ITIL hingegen sehr hilfreich sein, um die für das Zusammenwirken erforderlichen Serviceprozesse zu definieren. Ein Mobile Virtual Network Operator (MVNO) oder -Enabler (MVNE) ist, wie bereits erwähnt, dafür ein instruktives Beispiel. Ansatzpunkte für die Anwendung der ITIL-Methodik ergeben sich in der TK-Wertschöpfungskette unter anderem:

• im Bereich Assurance: Event/Incident/Problem Management können partiell oder bestimmte Technologien vollständig outgesourct sein, insbesondere die Leistungen des Field Service;
• im Fulfillment: Change Management/Request Fulfillment, einschließlich der Fulfillment Logistik und wiederum einschließlich Field Service;
• IT- oder IT-nahe Services allgemein, bis hin zu Teilbereichen des Billing oder das Invoicing.

Fazit

Service Manager in Industriesektoren, die für die Definition ihrer Services auf kein ausgereiftes eigenes Referenzmodell zurückgreifen können, sollten ITIL in Betracht ziehen und von IT-Spezifika abstrahieren. ITIL v3 ist ein wichtiger Schritt, um das Referenzmodell einer breiteren Anwendung zugänglich zu machen.

Die Telekommunikationsindustrie hat hingegen ein vergleichsweise altes und gereiftes Service-Referenzmodell. Eine Anwendung von ITIL "in großem Maßstab" ist in diesem Kontext nicht sinnvoll. Für bestimmte operative Prozesse kann ITIL jedoch auch vorteihaft in der Telekommunikation eingesetzt werden, besonders dort, wo Provider-Subprovider-Beziehungen existieren.