Von CW-Redakteurin Karin Quack

Wir wollen nicht mehr nur als Dienstleister unterwegs sein, sondern unser IT-Geschäft optimieren, um Partner des Business zu werden", erklärte Hans Mörtl, Senior Manager IT-Planung/Architektur-Management bei der Mercedes Car Group der Daimler-Chrysler AG. Da sich die Agenda der IT-Manager immer noch "in vielen Teilen" um die Kosten drehe, laute das Motto heute: Do more with less. Wer ein begrenztes Budget sinnvoll einsetzen will, kommt um ein Enterprise Architecture Management (EAM) nicht herum. Auf der diesjährigen Kundenveranstaltung ("Planning IT Exchange") des EAM-Spezialisten Alfabet AG berichteten Anwender von ihren Schwierigkeiten, das Thema EAM im Unternehmen zu etablieren.

Mörtl fasste seine Erfahrungen in sechs Punkten zusammen. Grundvoraussetzung ist für den Mercedes-Manager eine gemeinsame Sprache zwischen Business und IT. Mit dem IT-Kunden lässt es sich am leichtesten über Prozesse reden. Hier sollte die IT den Fachabteilungen entgegenkommen.

Es gibt aus Mörtls Sicht drei Arten von Prozessen: Management-, Kern- sowie Unterstützungsprozesse. Sie müssen kategorisiert und geordnet werden.

"Transparenz an und für sich ist noch kein Wert", sagte der Mercedes-Manager. Sie bekomme erst Gewicht, wenn man etwas damit anfange. Das bedeute: Optimierungsziele formulieren. Bei Daimler-Chrysler sind - wie in vielen Unternehmen - die Kernprozesse vertikal unterschiedlich. Aber es gebe gleiche Bestandteile, die sich standardisieren ließen, so Mörtl.

Planung ist ein Regelkreis

Aus den Zielen sind Aktionen abzuleiten: Die Projektvorschläge ergeben sich an den Schnittstellen einer Matrix, deren Achsen die Organisation und die Prozesse bilden.

Auf dieser Grundlage lassen sich dann konkrete Projekte priorisieren. Entscheidungskriterium sind die zu erwartenden Vorteile für das Unternehmen.

Planung funktioniert als Regelkreis. Auch die Ablehnung eines Projekts ergibt einen Sinn - sofern der Entscheidungsprozess dokumentiert ist. Projekte, die sinnvoll sind, aber im Moment kein Budget erhalten, sind zumindest schon definiert und können gemacht werden, sobald Geld dafür da ist.

Daneben gab Mörtl den Zuhörern noch ein paar gute Ratschläge mit auf den Weg:

• Eine IT-Master-Planung muss unbedingt mit den Geschäftsstrategien verbunden werden. Isolierte Aktivitäten sind reine Powerpoint-Malerei.

• Das Ergebnis der Planung ist ein integrierter Kalender, der jedoch nicht statisch ist, sondern "lebt". Das muss jeder Mitarbeiter verinnerlichen.

• Da die Planung ein iterativer Prozess ist, ist jemand nötig, der ihn managt.

Die lange Reise der Winterthur

Vor allem mit der "traditionell" dezentral organisierten Konzernstruktur kämpft Christoph Gall, verantwortlich für IT-Strategie und Unternehmensarchitektur bei der Winterthur Versicherung. "Jede Markteinheit hat eine andere IT", klagte er in seinem launigen Vortrag. So gab es 32 verschiedene Datenbankprodukte, 15 Betriebssysteme und mehr als 30 Programmiersprachen. Dass diese Vielfalt hohe IT-Kosten verursacht, versteht sich von selbst.

Im Jahr 2000 machte sich der Versicherungskonzern deshalb auf die Reise zu einer übergreifenden IT-Planung. Im ersten Schritt verschickte er Fragebögen an alle IT-Einheiten, um den Status quo der dortigen Systeme abzufragen. Der hohe Aufwand und die Angst vor zu viel Transparenz im Hauptquartier hielten die lokalen IT-Verantwortlichen aber davon ab, die Bögen auszufüllen, berichtete Gall.

Anschließend setzte die Winterthur ein großes internationales Projekt auf. In dessen Rahmen wurden zwar viele Daten gesammelt, aber nicht aktuell gehalten, weshalb sie schnell veralteten. Immerhin durften die Architekturplaner einen Teilerfolg verbuchen. Wie Gall berichtet, haben sie mit den gesammelten Daten "einfach mal herumgespielt" - auf Basis des Tabellenkalkulationsprogramms Excel. Damit erhielten die CIOs bislang nicht vorhandene Informationen über ihren eigenen IT-Laden. Und je besser die Qualität der zugelieferten Daten, desto aussagekräftiger waren diese Informationen. Leider stieß die Excel-basierende Anwendung schnell an ihre Grenzen - zumal immer nur ein Anwender darauf zugreifen konnte.

Daraufhin begannen die zentralen Architekten, ein Metamodell für ein Architektur-Repository zu entwickeln, mit dem sich Beziehungen zwischen den unterschiedlichen IT-Komponenten herstellen ließen. "Das Ergebnis war so eindrucksvoll, dass niemand dafür Geld ausgeben wollte", spottete der IT-Stratege. Das System drohte, viel zu komplex zu werden.

Also sollte der Umfang des Vorhabens beschränkt werden. Anfangen wollte das Architekturteam mit den Applikationen. Allerdings musste das zugrunde liegende Metamodell erst einmal in Software abgebildet werden. Und dieser Versuch scheiterte im ersten Anlauf. "Die Softwareanbieter, die unser Modell verstanden, waren zu teuer", erinnert sich der Chefarchitekt.

Kleine Schritte als Schlüssel

Mangels Alternativen ging das Winterthur-Team daran, das Metamodell selbst abzubilden - in der Microsoft-Datenbank "Access". Das Ergebnis entsprach allerdings nicht den Erwartungen: "Vieles, was mit der Excel-Anwendung funktionierte, ging in der Access-Applikation keineswegs", lernten Gall und seine Mitarbeiter.

Es musste ein professionelles Planungswerkzeug her. Die Schweizer entschieden sich für Planning IT von Alfabet. Den im Oktober 2005 gestarteten Proof of Concept gestaltete das Team so, dass das System im Erfolgsfall gleich online gehen konnte. Der Pilot wurde im Februar 2006 ausgerollt - mit nochmals reduziertem Funktionsumfang. "Kleine Schritte sind der Schlüssel", weiß der Winterthur-Manager heute.

Derzeit erlaubt das System allerdings nur eine statische Darstellung und noch keine Simulation von Effekten, bemängelt Gall. Das liege weniger am Tool als an der "internen Reife", also an den Prozessen, am Vertrauen in die Architekturdisziplin und an der Bereitschaft, den Aufwand zur Bereitstellung der Datenbestände zu erbringen. Um den "Himmel der Architekten" zu erreichen, will Gall beispielsweise ermitteln können:

• welche Konsequenzen die Einführung neuer Business-Modelle hat,

• inwieweit ein Modell kompatibel mit der IT-Strategie ist,

• welche Projekte dafür notwendig sind und welche flachfallen müssen,

• wo neue Services und Interfaces zu schaffen sind,

• welche Infrastruktur-Skills das Unternehmen künftig benötigt,

• wie das Design neuer IT-Landschaften aussehen sollte.

Governance aus einer Hand

Ähnlich wie Gall leidet Herbert Voß, Architektur- und IT-Governance-Chef der AMB Generali Informatik Service GmbH, darunter, dass das Konzerndach eine Reihe von starken, selbständigen Marken verbindet. "Aber wir verfolgen Einheitlichkeit dort, wo es nichts mit dem Produkt zu tun hat", betonte der IT-Architekt. Die IT nehme in dieser Hinsicht eine Governance-Funktion wahr.

Mit Hilfe von Bordmitteln hat AMB Generali den "Flickenteppich" der IT zumindest oberflächlich vereinheitlicht, berichtete Voß: "Aber noch darf niemand eine Ebene tiefer schauen." Das habe seinen Grund unter anderem in einem "Webfehler". Auf den ersten Blick leuchtet der Versuch ein, die unterschiedlichen Anwendungsbereiche konzernweit von je einem Kompetenzteam auf der Management- und der IT-Seite gemeinsam behandeln zu lassen. Aber er schlug fehl: Die Fachkompetenz-Zentren waren immer einer bestimmten Gesellschaft zugeordnet, weshalb sie auch vorrangig in deren Interesse handelten. "Wir haben eine Ausnahme nach der anderen genehmigt", so Voß.

Aus diesem Grund etabliert AMB Generali derzeit unabhängige Kompetenzzentren, die oberhalb des gesellschaftsbezogenen Key-Account-Managements agieren. Noch eine Ebene tiefer nimmt die IT ihrer Governance-Funktion wahr. Sie setzt sich aus Projekt-Portfolio-Management, Programm-Management, Architektur-Management und Qualitäts-Management zusammen. Diese Funktionen einem - wenn auch internen - Dienstleister anzuvertrauen, mag dem einen oder anderen Außenstehenden ungewöhnlich erscheinen. Für den Konzern steht jedoch im Vordergrund, dass diese vier Aufgaben überhaupt in einer Hand liegen.