Wer einen IT-Service anbieten will, hat ein gravierendes Problem: Es mangelt an Transparenz bei der Bereitstellung und Verwaltung der Dienste. Das hat viele Ursachen, die wichtigste jedoch ist die fehlende Integration. Zwar nutzt man vielerlei Management-Konsolen, um in Sachen Performance nicht zu enttäuschen, ganzheitliches IT-Business-Management bleibt jedoch Fehlanzeige. Ausgehend von den zugrunde liegenden Prozessen bietet sich eine Alternative, die vor allen Dingen eines leisten kann: Die Integration aller maßgeblichen Aspekte in ein durchgängiges Framework.

Für viele IT-Diensteanbieter geht es aus nahe liegenden Gründen in erster Linie darum, einen Service mit bestmöglicher Performance bereitzustellen. Dazu gibt es eine Vielzahl von Tools und Management-Konsolen. Doch gerade die sind oft der eigentliche Kern eines tiefer gehenden Problems: Denn statt Klarheit zu schaffen, verursachen sie eher ein Datendickicht aus proprietären Standards und Teilansichten, die einen ganzheitlichen Überblick verhindern. Vor allem tragen sie kaum dazu bei, die ablaufenden Prozesse auf Seiten eines IT-Service-Providers im Detail zu beleuchten. Vielmehr stehen Verfügbarkeit, Performance und Güte von Teilbereichen im Mittelpunkt.

So wichtig diese Aspekte auch sind, sie bilden einen Service immer nur zum Teil und von der technischen Warte aus ab. Das mag zwar das Fundament für jeden Service bilden, bleibt jedoch den meisten Anwendern und Managern ein Rätsel, wenn sie dessen Auswirkungen auf ihr Geschäft nicht entschlüsseln können.

Reines Performance-Management, das ohne Zweifel auch abgedeckt sein sollte, ist somit sicher nicht der Weisheit letzter Schluss. Stattdessen kommt es zunehmend darauf an, (IT-) Dienste durch ganzheitliches Management so zu unterstützen, dass sie in ihren prozessualen Bestandteilen fassbar werden. Neben technischen Spezifikationen spielen hierbei zum Beispiel auch terminliche und personalbezogene Aspekte eine entscheidende Rolle. So gilt es auch, bei der Wahl der Tools umzudenken. Statt nur auf rudimentäres Performance-Management zu setzen, sollte man Werkzeugen den Vorzug geben, die ganzheitliches Business-Management durchgängig unterstützen. Schließlich geht es neben der Überwachung von IT-Infrastrukturen auch um Servicedefinitionen, Service-Level-Agreements (SLAs), Personalbedarfsplanung, Analyse der Hardwarevoraussetzungen, Beschaffungsprozesse für Hard- und Software, Anwenderbetreuung und vieles mehr.

Beispiel Filialanbindung

Von Prozessen ist zwar oft die Rede, aber man macht sich eher selten die Mühe, zu definieren, was die charakteristischen Merkmale eines Prozesses sind und wie diese sich Tool-seitig am besten darstellen lassen. Eine typische Aufgabenstellung für einen Service-Provider könnte etwa lauten: Die Zentrale eines Handelsunternehmens mit 35 Anwendern soll mit drei Filialen à 15 Usern über einen Virtual-Private-Network-Zugang (VPN) verbunden werden, damit sich die zentralen Business-Applikationen auch in den Niederlassungen nutzen lassen.

Entscheidungen im Vorfeld

Um diesen Service anbieten und in Betrieb nehmen zu können, muss man zunächst die VPN-Verbindung näher definieren und anhand der individuellen Bedürfnisse entscheiden, ob ein statisches, teildynamisches oder dynamisches VPN zu implementieren ist, welcher Internet-Provider den Zuschlag bekommen soll und wie die Anforderungen an Durchsatzraten und Verfügbarkeitszeiten aussehen.

Im vorliegenden Beispiel ließe sich das folgendermaßen darstellen: Die Filialen sollen mit je 15 Usern und einer Übertragungskapazität von 1 GB pro Sekunde angebunden sein. Dabei soll eine Verfügbarkeit von 99,9 Prozent bei einer Betriebszeit von 24 Stunden an sieben Wochentagen gewährleistet sein. Die Zugriffsraten sollen 95 Prozent betragen, wobei man die VPN-Tunnels teilt (shared). Natürlich sind auch andere Kenngrößen denkbar - entsprechend kann man verschiedene Leistungsklassen mit ihren jeweiligen Preisen festlegen und über einen Serviceprodukt-Katalog anbieten.

Von der Definition zur Freigabe

Ein einfacher Steuerungsprozess könnte in diesem Kontext so aussehen: Zunächst konfiguriert man die technischen Merkmale, hier also Benutzerzahl und Übertragungskapazität. Im Anschluss daran fügt man die verwaltungstechnischen Eigenschaften wie Betriebszeiten, Zugriffsraten und Verfügbarkeit hinzu. Dann legt man die Preise für den Dienst fest und lässt diesen unter Umständen vom Firmen-Controlling genehmigen. Schließlich gibt man den Dienst im Rahmen eines Servicekatalogs als Angebot für den Kunden, hier die Filialen, frei.

Wird das Angebot zur Einrichtung der VPN-Anschlüsse angenommen, ist zunächst zu prüfen, ob die vorhandenen Kapazitäten ausreichen oder ob man sie erweitern muss: Unter anderem ist konkret zu klären, ob der VPN-Router der Zentrale noch genügend VPN-Tunnels bietet und ob für jede Filiale VPN-Router vorhanden sind. Ist dies nicht der Fall, müssen neue bereitgestellt, also ein Change-Prozess angestoßen werden. Im Wesentlichen gliedert sich ein Change-Prozess für Hardwarekomponenten in die Teilbereiche Bestellung, Testen, Konfiguration und Freigabe zum Betrieb (siehe auch Itil). Sofort befindet man sich in einem Geflecht von (Sub-) Prozessen wie etwa den Bestellprozessen, deren Abläufe in Bezug auf Termine, Abhängigkeiten und Zuständigkeiten zu klären sind, um eine möglichst effektive Abwicklung zu gewährleisten.

Wechselwirkungen

Jeder dieser Prozesse beschreibt die Zustände von Objekten - hier des VPN-Service beziehungsweise der VPN-Router. Darstellen lassen sich darüber hinaus die möglichen, am Objekt auszuführenden Aktivitäten (einige davon unter Umständen parallel) und die Überführung der Objekte in Folgezustände (Transitionen). Eine Aktivität kann in diesem Zusammenhang aus mehreren Einzelaktionen wie dem Ausfüllen von Pflichtparametern bestehen. Im gewählten Beispiel zählen dazu die Definition der technischen Merkmale nach Anzahl der User, die Übertragungsrate oder das Zuweisen von Referenzdokumenten wie das eines zugehörigen SLA-Vertragsdokuments.

Ein Management-Tool sollte sicherstellen, dass alle Prozesse frei modellierbar sind. So kann die Einrichtung des VPN-Anschlusses für die eine Filiale aus technischen oder organisatorischen Gründen anders erfolgen als für die zweite. Die verwendeten Tools sollten dementsprechend flexibel und technologieunabhängig ausgelegt sein. Wenn etwa Filiale 2 der Auslandsgesellschaft des Konzerns untersteht, ist die Bewilligung der Budgets für einen VPN-Router ein anderes Verfahren als bei Filiale 1. Das heißt, der erste Schritt des Change-Prozesses würde als Subprozess für Filiale 2 andere Schritte durchlaufen als der Subprozess für Filiale 1. Dem muss das Management-Tool Rechnung tragen können.

Jeder Teilservice ist ein Prozess

Bleibt man beim VPN-Anschluss, gilt außerdem: Obwohl es sich für den Kunden dabei dem Anschein nach um nur einen Dienst handeln mag, sind es de facto zwei, nämlich der VPN- und der dafür benötigte Internet-Zugang. Diese können durchaus von verschiedenen Dienstleistern bereitgestellt werden. Daraus folgt: Für jeden Teilservice muss ein entsprechender Prozess mit den jeweiligen Abhängigkeiten definiert sein.

Prozesse lassen sich auf unterschiedliche Arten modellieren. Einen gängigen Ansatz bietet zum Beispiel die Business Process Modelling Language (BPML). Im Grundsatz handelt es sich bei BPML um die Spezifikation eines abstrakten Prozessmodells sowie eine XML-Syntax zum Beschreiben der ausführbaren Geschäftsprozesse und deren unterstützende Einheiten. Unabhängig von einer bestimmten Anwendungssemantik liefert sie ein abstraktes Modell und die Grammatik zum Ausdruck von generischen Prozessen. Aufgrund dessen kann man die BPML für eine Vielzahl von Anwendungen heranziehen. Ein Nachteil der BPML: Ihre Möglichkeiten bei der Objektmodellierung sind begrenzt.

Zustandsautomaten

Eine andere Vorgehensweise leitet sich aus der UN/Cefact Modeling Methodology (UMM) ab. Kernpunkt ist es dabei, das Verhalten von Objekten im System quasi als Zustandsautomaten abzubilden. Zustandsautomaten korrelieren Aktivitäten des Bedieners oder eintreffende Ereignisse mit den Zuständen des Automaten. Eine Aktivität kann dabei aus mehreren Aktionen bestehen. Eintreffende Ereignisse lösen abhängig vom Zustand und etwaigen weiteren, temporär auftretenden Bedingungen eine Aktion aus. Ist eine Aktivität abgeschlossen, kommt es gegebenenfalls zu einer Zustandsveränderung (Transition). Ein Zustandsautomat lässt sich also im Wesentlichen durch die Parameter Zustand, Ereignis, Bedingung, Aktivität und Folgezustand beschreiben.

Man kann einen Prozess demnach als Aktivitätskette durch einen Zustandsautomaten abbilden. Das Verhalten ist transparent auf der Ebene des Objekts dargestellt, auf das der Prozess wirkt. Durch dieses Verfahren lassen sich also sowohl Objekte als auch Geschäftsprozesse beschreiben.

Auf den VPN-Service für Filiale 1 bezogen, ergäbe das zum Beispiel folgende Kette:

Der VPN-Service ist …

1. beauftragt,

2. bereitgestellt,

3. betriebsbereit (vollständig),

4. in Betrieb (aktiviert),

5. abgelaufen (annulliert).

Der Prozessablauf ist also fest an eine Instanz des Service gekoppelt. Das heißt allgemein, dass Prozesse immer Datenelementen zugeordnet sind, die sich unter Umständen hierarchisch aggregieren lassen. Daraus ergibt sich auch eine Hierarchie der Prozesse. Der VPN-Service kann so erst betriebsbereit (vollständig) gesetzt werden, wenn der benötigte VPN-Router zum Betrieb freigegeben ist.

Personen und ihre Rollen

Entscheidend bei den Inbetriebnahmen eines Dienstes ist auch immer, wer die handelnden Personen sind. Wichtig für den VPN-Service ist zum Beispiel die Rolle des Servicedesigners, der den Dienst plant. Daneben muss aber auch geklärt sein, wer etwa die VPN-Router für die Zentralen und Filialen bestellt oder wer für die Internet-Anschlüsse zuständig ist. Daraus ergibt sich, dass das verwendete Tool ein entsprechendes Rollen- und Berechtigungssystem unterstützen muss.

Die Personenzuordnung nach Zuständigkeiten sollte in möglichst granularer Aufteilung erfolgen: Exemplarisch könnte dies wie folgt aussehen: Für die Inbetriebnahme des VPN-Routers in der Zentrale ist ein Supporttechniker ‘support’ verantwortlich, da er die Rolle ‘Verantwortlicher für Ressourcen-Betrieb’ hat und der zuständigen Arbeitsgruppe ‘Zentrale’ angehört, die dem VPN-Service zugewiesen ist. Für die Inbetriebnahme des VPN-Routers in der Filiale 1 ist dagegen ein Supporttechniker ‘support Filiale 1’ zuständig, da er dieselbe Rolle besitzt, aber der Arbeitsgruppe ‘Filiale 1’ angehört, die dem VPN-Router für Filiale 1 zugewiesen ist.

Jeder Prozess, jeder Zustand und jede Aktivität müssen sich schließlich mit Terminen beziehungsweise Phasen belegen und überprüfen lassen. Benachrichtigungen zur Erinnerung sollten innerhalb des Frameworks möglich sein.

Der Kraftakt lohnt nicht

Die Einführung einer Lösung, die alle hier genannten Aspekte abdeckt, ist aufwändig und damit auch kostspielig. Doch der Kraftakt lohnt sich in mehrfacher Hinsicht. Er sorgt für eine reibungslosere Abwicklung und Inbetriebnahme von Diensten, gewährleistet darüber hinaus, dass die Services und deren zugrunde liegenden Prozesse insgesamt transparenter werden, und führt schließlich zu einer besseren Beziehung zum Auftraggeber. (ue)