Service-orientierte IT-Strukturen – mehr Wunsch als Wirklichkeit

Outsourcing ist auf dem Vormarsch. Sehr viele, zumeist große Unternehmen betrachten mittlerweile die Auslagerung von IT-Prozessen nicht mehr als Expertise-Aderlass, sondern als Entlastung, um sich besser auf die Kernprozesse des Geschäfts konzentrieren zu können. Freilich können Prozesse nur dann erfolgreich ausgelagert werden, wenn klar ist, welche Anwendungsprogramme sie enthalten und welche Rolle ein jedes dieser Programme für den jeweiligen Prozess spielt, oder anders ausgedrückt: welche Serviceleistung es liefert.
Nur dann können nämlich hinreichend exakte Vereinbarungen zwischen Dienstleister und Kundenunternehmen, beispielsweise in Form von Service-Level-Agreements getroffen werden. Die Umsetzung von herkömmlichen Anwendungen in Services ist im übrigen auch dann angezeigt, wenn nicht ausgelagert wird – ist doch heute kaum noch eine Abteilung in einem Unternehmen bereit, für die IT pauschal zu bezahlen. Vielmehr will man genau und nur für das löhnen, was die abteilungsspezifischen Prozesse an Rechenleistung verbrauchen.

<b>Trennung von Nutzerverwaltung und Programmlogik</b>

Mit Werkzeugen aus dem Bereich Identitätsmanagement wie dem ‘Identity Manager’ von IBM Tivoli, Control-SA von BMC, dem ‘Identity Automation Framework’ von Novell oder DirX von Siemens lassen sich sowohl Infrastrukursoftware als auch Anwendungslösungen Service-tauglich machen. Technisch wird bei einer solchen Transformation in erster Linie die gesamte Nutzerverwaltung von der übrigen Programmlogik abgekoppelt. Diese Operation macht die entsprechenden Programme im übrigen nicht nur Service-tauglich, sondern gleichzeitig auch Portal-tauglich. Denn Portale sind ja genau solche Anwendungen, die –  ohne dass sie eine eigene Nutzerverwaltung haben – bestimmte Funktionen für diejenigen Anwender zur Verfügung stellen, die auf diese Funktionen ein Zugriffsrecht haben.

Die Trennung von Nutzerverwaltung und System- oder Anwendungslogik erzeugt fast von allein eine Optimierung der IT-Abläufe, weil sie eine Justierung dieser Abläufe an den Geschäftsprozessen erzwingt. Diese sind in isolierter Form nämlich viel deutlicher erkennbar. Dadurch ist es viel einfacher möglich, eine Gewichtung der verschiedenen Geschäftsprozesse nach bestimmten Kriterien vorzunehmen und damit den Einsatz knapper Systemressourcen zu optimieren. Durch eine solche Gewichtung lassen sich besonders bei Systemausfällen teilweise Millionen von Euro sparen. So kann beispielsweise der minuten- oder gar stundenlange Ausfall eines automatischen Arbitragesystems bei einer auf Devisenhandel spezialisierten Bank hohen geschäftlichen Schaden anrichten, während der Ausfall einer größeren Anzahl von Geldautomaten zwar ärgerlich für viele Kunden, aber nicht ruinös für das Geldinstitut ist. Ein zweites Beispiel: der Ausfall von Druckerservern mag bei einem Geldinstitut für einige Zeit hinnehmbar sein, nicht aber bei einem Transportdienstleister, der auf Grund dieser Havarie keine Reisedokumente mehr ausgeben kann.

<b>Verknüpfung von Betriebswirtschaft und IT</b>

Interne oder externe Verträge, die den Umfang und die Art der informationstechnischen Leistungserbringung regeln (Service Level Agreements), gibt es schon lange. Trotzdem macht bis dato nur rund ein Fünftel aller Unternehmen in Deutschland von diesem Instrument Gebrauch. Der Grund mag darin liegen, dass die Verknüpfung der Potenziale der hardware- und softwaretechnischen Komponenten mit den Geschäftsabläufen sich noch in einem rudimentären Stadium befindet. So lange die meisten Unternehmen ihre Geschäftsprozesse nur sehr lückenhaft kennen und das Bewusstsein von der Wertigkeit dieser Prozesse wenig entwickelt ist, wird sich daran kaum etwas ändern.

Ohne Klärung und explizite Beschreibung dieser Zusammenhänge ist aber schon eine simple Identifizierung von IT-Komponenten und deren Zuordnung zu den entsprechenden Prozessen nicht möglich. Moderne Systemmanagement-Werkzeuge versuchen deshalb hier den Vorreiter zu spielen, indem sie Hardware- und Software-Komponenten automatisch identifizieren und die gefundenen Teile mit den Geschäftsprozessen verknüpfen.

Freilich sind Geschäftsprozesse nicht nur und vielleicht nicht einmal zum größeren Teil durch die IT-Infrastruktur determiniert. Entsprechende Ansätze aus dem Bereich Systemmanagement sollten deshalb mit betriebswirtschaftlich orientierten Vorgehensweisen nach dem Muster von Werkzeugen wie ARIS (‘Architektur integrierter Informationssysteme’) von IDS Scheer zusammengeführt werden. Dort wird versucht, mehrere betriebliche Sichtweisen in einem Gesamtmodell nachzustellen (Aufbauorganisations-, Ablauforganisations- und Datensicht) und sie zueinander in Beziehung zu setzen.

Für die damit verbundene größere Ausdrucksvielfalt ist natürlich ein Preis zu zahlen. Die Formalismen des Beschreibungsapparats sind bei Systemen wie ARIS nur beschränkt algorithmisch verwertbar und können ohne Zusatzinformationen und /oder Transformationen nicht in andere Formalismen und Algorithmen überführt werden. So verursacht es beispielsweise einigen Aufwand, um ARIS-Modelle in die Konstrukte der ‘Flow Definition Language’ (FDL) zu überführen. Mit FDL arbeiten gewöhnlich die so genannten Workflow-Managementsysteme wie beispielsweise Staffware oder MQSeries Workflow, mit denen Geschäftsprozesse automatisiert werden können.

<b>Der Service-Begriff muss formal schärfer gefasst werden</b>

Derzeit existieren keine auch nur annähernd kanonischen Repräsentationen von Geschäftsprozessmodellen. Dies wäre freilich die Voraussetzung, damit solche Modelle auch dann miteinander kompatibel sind, wenn sie von unterschiedlichen Werkzeugen erstellt worden sind, beziehungsweise damit eine automatische Übersetzung zwischen einer Prozess-Modellierungsprache und einer Workflow-Management-Sprache möglich wird.

Die Informatik-Forschung versucht derzeit, generische Strukturen bei der Modellierung von Geschäftsprozessen zu schaffen. Dabei wird unter anderem auch auf Konstrukte wie Frameworks und Entwurfsmuster (Design Pattern) zurückgegriffen, die in der Programmentwicklung für die möglichst generische Darstellung eines Problemkreises entwickelt wurden.

Ganz gleich, ob dieser Weg zielführend ist – die mangelnde Akzeptanz der entsprechenden Konstrukte in der Softwareentwicklung stimmt eher skeptisch – so ist doch unbestreitbar, dass nur durch eine Kanonisierung der Formalismen im Bereich der Geschäftsprozess-Modellierung einem Wildwuchs von Kästchen und Pfeilen Einhalt geboten werden kann. Nur dann kann mehr Automatisierung in diesem Sektor erreicht werden, nur so können verschiedene Lösungsansätze miteinander verglichen werden.

Vom Leistungsangebot her bewegen sich die betriebswirtschaftlich aufgebohrten Ansätze aus der Systemmanagement-Ecke wie beispielsweise das ‘Business Service Management’-Konzept von BMC und Prozessanalyse-Werkzeuge wie der ‘Process Performance Manager’ von IDS Scheer stark aufeinander zu. Beide rekonstruieren Geschäftsprozesse über System- und Organisationsgrenzen hinweg und erzeugen anhand von Prozesskennzahlen wie Durchlaufzeit oder Liefertreue Modelle für die Analyse und Optimierung.

Bezeichnenderweise haben beide Hersteller letzte Woche eine Allianz angekündigt. Ziel ist es eine gemeinsame Lösung zu entwickeln, die die einzelnen Komponenten der ARIS Process Platform von IDS Scheer mit den Business Service Management Produkten von BMC verbinden. Anwendern der gemeinsamen Lösung soll es möglich sein, Ursache-Wirkungs-Beziehungen zwischen Systeminfrastruktur und betriebswirtschaftlichen Geschäftsabläufen zu erkennen. Hat ein Lieferant beispielsweise zu spät oder die falsche Ware geliefert, so konnte er den Fehler bisher nur im eigenen Geschäftsprozess suchen. Die neue Lösung soll nun die Beurteilung der Verfügbarkeit der Systeminfrastruktur und somit eine durchgängige Ursachenanalyse auf betriebswirtschaftlicher und auf IT-Ebene ermöglichen.