Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

03.07.2006

Architektur ordnet Anwendungschaos

Wie sich die Integration der Business-Applikationen bewerkstelligen lässt.

Der Siegeszug der PCs in den 80er Jahren, das stetig zunehmende Selbstbewusstsein der Fachabteilungen und der E-Business-Hype um die Jahrtausendwende haben die IT-Verantwortlichen immer wieder vor dieselben Probleme gestellt: Außerhalb jeder strategischen Planung entstanden geschäftskritische Anwendungen, die teilweise gleiche Funktionen abdecken und redundante Daten vorhalten. Über die Konsolidierung der ERP-Systeme (Enterprise Resource Planning) ist in den vergangenen Jahren viel geschrieben worden. Weniger publik wurden die Schwierigkeiten, die CIOs damit haben, den Applikationswildwuchs jenseits der ERP-Systeme zu beschneiden.

So könnten Sie vorgehen

Einen "Königsweg" für die Konsolidierung der Business-Anwendungen gibt es nicht, sagt der Gartner-Manager Axel Jacobs. Aus folgender Checkliste lässt sich aber vielleicht eine grobe Orientierung ableiten:

IT-Governance: Schulterschluss der interdisziplinären Teams, ausgerichtet an den Hauptprozessen sowie den Daten- und Informationsflüssen.

Anwendungsarchitektur: Strukturierung der Geschäftsprozesse entlang einer definierten Architektur bis auf die Applikationsebene,

Proof of Concept: Mit Pilotprojekten lässt sich die Praxistauglichkeit der Architektur überprüfen.

IT- und Architektur-Controlling: Rückkopplung und Messung der erwarteten Ergebnisse.

gegebenenfalls Anpassung der Architektur - im Falle (zwischenzeitlich) veränderter betriebswirtschaftlicher Anforderungen.

Architektur-Governance: Etablieren einer aktiven, interdisziplinären Architekturfunktion mit Überwachungsmandat.

Roadmapping - die Kür, die auf die Pflicht folgt: Richtung, Prioritäten und Zeitpläne für künftige Strukturentwicklungen werden kommuniziert.

Hier lesen Sie …

Mehr zum Thema

www.computerwoche.de/

570273: Die IT muss ihren Erfolg planen;

569037: Transparenter Bebauungsplan;

566749: Ganzheitliches IT-Controlling;

575113: Comeback des Kunden-Managements.

Eigentlich sollte dieses Problem keines mehr sein - sagen viele Hersteller und mit ihnen einige Analysten. Erstere verweisen auf ihre "integrierten" Produktsuiten und Softwarearchitekturen, Letztere auf Themen wie Portfolio- und Asset-Management.

Unterschiedlicher Reifegrad

Tatsächlich haben viele Anwender im Zuge der ERP-Konsolidierung auch ihre Customer-Relationship-, Supply-Chain- und anderen Management-Systeme auf die Produkte ihres Standardsoftwarelieferanten umgestellt. Außerdem gibt es fast überall Ansätze für IT-Bebauungspläne und eine darauf basierende Konsolidierung des Softwarebestands - bis hin zum Software-Lifecycle-Management.

Doch der "Reifegrad" dieser Bemühungen ist durchaus unterschiedlich, hat Axel Jacobs festgestellt. Als Vice President Consulting bei Gartner hat er Einblick in die Ergebnisse der Assessments, denen das Marktforschungs- und Beratungsunternehmen die IT-Architekturen seiner Kunden unterzieht. Sein Fazit: Bislang haben sich noch keine "Best Practices" für die Konsolidierung der Business-Systeme herauskristallisiert.

Sprunghafter Anstieg

Die Frage, wie viele geschäftskritische Anwendungen ein Unternehmen haben sollte, lässt sich nicht pauschal beantworten. Nach der Erfahrung von Rüdiger Spies, Executive Advisor bei der Experton Group, sind 40 bis 50 "tragende" Applikationen eine gute Hausnummer für einen größeren Betrieb. Um die Jahrtausendwende habe jedoch der damals propagierte Best-of-Breed-Ansatz zu einem sprunghaften Anstieg der Anwendungen geführt, so dass es bisweilen für jeweils eine Million Euro Umsatz eine Business-Anwendung gegeben habe.

Tatsächlich berichten Konzern-CIOs hinter vorgehaltener Hand von bis zu 1000 Anwendungssystemen, deren Updates sie verwalten und deren Daten sie integrieren müssen. Der EAI-Ansatz (Enterprise Application Integration) hat seinerzeit zumindest für eine Verbindung zwischen den Einzelfunktionen gesorgt. Doch beschränkt er sich auf die technische Seite des Problems. Die Integration auf der geschäftlichen Seite berührt er nicht.

Mittlerweile ist die Idee des Best of Breed wieder passé: "Die Unabhängigkeit von einem Anbieter wiegt nicht auf, was ich mir an Komplexität einhandle", erläutert Spies den Trend zu wenigen strategischen Lieferanten. Doch begründete Ausnahmen von der Beschaffungsregel gibt es immer - vor allem in den kundennahen Anwendungsbereichen, wo sich die Unternehmen von ihren Mitbewerbern unterscheiden wollen. Außerdem sorgen die Softwareanbieter mit Fusionen, Zukäufen und den darauf folgenden strategischen Ankündigungen selbst dafür, dass die Kunden ihre Anwendungsportfolios ständig überarbeiten müssen.

Die Beschränkung auf eine Anbieterarchitektur ist laut Spies aber schon mal ein guter Anfang. Für sich allein genommen führe sie allerdings ebenso wenig zum Ziel wie ein EAI-System und ein isoliertes Portfolio-Management. Deshalb türme sich derzeit eine zweite Welle der Konsolidierung auf. Von der ersten unterscheide sie sich dadurch, dass sie mit der Definition einer einheitlichen Architektur beginne.

Unerledigte Hausaufgaben

Offenbar haben viele Unternehmen um die Jahrtausendwende ihre "Hausaufgaben" nicht gründlich genug erledigt, bestätigt Jacobs: "In den Jahren 2001 und 2002 ging es vor allem darum, die IT zu rationalisieren, zu konsolidieren und - wo möglich - auszulagern. Um die Architektur in ganzheitlicher Form hat man sich wenig gekümmert."

Das ist insofern verständlich, als es den Unternehmen damals vor allem darum ging, ihre IT-Kosten zu verringern. Ein Achitekturprojekt bewirkt aber erst einmal genau das Gegenteil: Es kostet Geld. "Die Rückzahlungsperiode für eine ganzheitliche Architekturumsetzung im Bereich von Business-Systemen liegt in der Regel nicht unter vier Jahren", weiß Jacobs. Zu einer Zeit, als die Firmenleitungen einen Return on Investment (RoI) innerhalb von Monaten erwarteten, war das nicht durchsetzbar. Darüber hinaus sind solche Vorhaben kaum attraktiv: Sie verlangen den Beteiligten weniger Kreativität als vielmehr Disziplin ab.

In der Zwischenzeit habe sich die Einstellung gegenüber derartigen Themen "tendenziell" positiv verändert, räumt Jacobs ein. Doch auch die zweite Konsolidierungswelle habe oft den Charakter eines Feigenblatts: "Es gibt nur wenige Projekte, die wirklich in das Herz, also die Gesamtkomplexität von gewachsenen Architekturen, vorstoßen; die meisten kratzen das Thema lediglich an."

Ein Praxisbeispiel

Zu den Unternehmen, die das Thema augenscheinlich sehr gründlich angegangen sind, zählt die Henkel AG, Düsseldorf. Wie deren CIO, Peter Hinzmann, berichtet, wurde die Konsolidierungsaufgabe dort schon 2001 in Angriff genommen - direkt nach Abschluss der "Jahr-2000"-Umstellung. Das Ziel bestand unter anderem darin, eine globale Steuerung des Unternehmens mit Hilfe eines effizienten IT-Portfolio-Managements aufzubauen und die Geschäftsprozesse weltweit zu harmonisieren - im Einklang mit der IT-Konsolidierung.

In diesem Zusammenhang erstellte Henkel "Business Process Blueprints" und ERP-Templates, die bis zum Ende des kommenden Jahres weltweit ausgerollt sein sollen. 2004 wurde der Template-Ansatz dann auf die "Satelliten-Applikationen", sprich: die Nicht-ERP-Anwendungen, ausgedehnt. Gemeinsam mit den Prozesseignern erarbeitete die Henkel-IT durchgängige Best-Practice-Prozesse und setzte sie softwaretechnisch um. Die Frage der Implementierungstechnik war für Hinzmann dabei stets zweitrangig: "Wir legen sehr viel Wert auf Prozessunterstützung, auf Kosten-Nutzen-Betrachtung und Provider-Profile; danach wählen wir die Applikation aus."

Bestandteile der Archtektur

Auch Gartner-Manager Jacobs plädiert dafür, mit End-to-End-Prozessen zu beginnen, beispielsweise mit einer Bedarfsplanung, die vom CRM-System bis in die Produktion hinein reicht. Dabei gibt er jedoch zu bedenken, dass die Vereinheitlichung der Prozesse eher das kleinere Problem sei. Sie erfordere lediglich einen "Gewaltakt auf der Organisationsebene". Weit schwieriger sei aus der IT-Sicht die ganzheitliche Integration der Daten und Informationen. Kaum ein Unternehmen kenne beispielsweise für den Business-Intelligence-Bereich eine wirklich durchgängige Datenarchitektur, die sich vom lokalen über das regionale bis zum zentralen Reporting durchziehe.

Im Detail hat Gartner vier Domänen definiert, die eine IT-Architektur behandeln müsse:

1. die Business-Domäne, die Ist-Prozesse festlegt und Soll-Prozesse definiert;

2. die Domäne der Daten und Informationen;

3. die Technik-Domäne, die sich mit den zugrunde liegenden Infrastrukturplattformen befasst, und

4. die Lösungsdomäne, die die vorgenannten Bereiche umfasst, also beispielsweise den Einsatz von Applikationen im Gesamtzusammenhang beschreibt.

Die Architekturfrage lediglich mit einem Herstellernamen - sei es nun SAP, Oracle oder Microsoft - zu beantworten, verbietet sich hier von allein. Zumindest in Bezug auf die beiden erstgenannten Domänen könne es sich der Anwender im Normalfall nicht so einfach machen, bestätigt Jacobs. Wenn er es doch tue, erhalte er die Quittung oft genug dann, wenn Modifikationen die Standardisierungsbestrebungen konterkarierten: "Die Herstellersysteme sind zum einen von Natur aus instanziierbar und keineswegs zwingend einförmig, zum anderen müssen sie bestimmte Freiheitsgrade, also Parametereinstellungen, erlauben, um den Ansprüchen der Fachabteilungen zu genügen." Aus diesem Grund komme das Anwenderunternehmen um eine herstellerübergreifende Architektur wohl kaum herum.

Architektur, Strategie, Operating

Damit diese Architektur ihr Ziel erreicht, bedarf es laut Jacobs aber einer weiteren Komponente: einer Governance-Struktur. IT- und Fachbereiche müssen in Form interdisziplinärer Teams gemeinsam dafür sorgen, dass sich Business-Anforderungen und Architektur permanent im Einklang befinden.

Bestandteil der Governance sei häufig ein Portfolio-Management, das sich nicht nur auf Projekte beziehe, sondern auch statische Elemente - Applikationen und Infrastruktur-Assets - einschließe, führt der Gartner-Manager aus: "Auf diese Weise lässt sich die Architekturarbeit mit der strategischen IT-Planung sowie dem operativen IT-Management integrieren."

Eine Königsdisziplin der IT

Diese Verzahnung ist eine Königsdisziplin des IT-Managements, mithin alles andere als eine leichte Aufgabe. Denn hierfür muss ein Workflow, der Strategie und operatives IT-Management verbindet, nicht nur definiert und umgesetzt, sondern auch mit der notwendigen Durchschlagskraft ausgestattet werden.

Im anderen Fall würde die geleistete Arbeit schnell obsolet, denn das Architekturthema ist ein "Moving Target". Es erfordert das ständige Streben nach Balance, so Jacobs. Das unterstreicht auch Henkel-CIO Hinzmann: "Prozesse können sich durch Gesetzesnovellen, Marktverhalten oder einfach durch dynamisch verbesserbare Komponenten verändern. Die Applikations-Templates in Releases zu modifizieren und entsprechend auszurollen ist eine permanente gemeinsame Aufgabe der IT und des Business."

Hinzmann hat es eigenen Angaben zufolge geschafft, für sein Konsolidierungsvorhaben einen positiven RoI zu errechnen. Das sollte auch anderen IT-Verantwortlichen Mut machen, das Architekturthema ihren Vorständen anzudienen - zumal die Mehrzahl der Unternehmen nicht mehr ganz so strikt auf die Kosten fixiert ist, sondern die IT auch wieder unter dem Nutzenaspekt betrachtet.

Argumentationshilfe für den CIO

Jacobs hat hierfür ein paar Argumentationshilfen gesammelt: "Es lohnt sich, unter dem Hinweis auf Opportunitätskosten die Frage zu stellen: Was passiert, wenn wir es nicht tun?" rät der Gartner-Manager. Ein "probates Mittel" sei es auch, das Regulierungs- und Compliance-Thema anzuschneiden: "Architekturelles Arbeiten kommt hier einer Versicherung gleich". Last, but not least gebe es auch unmittelbar einleuchtende Vorteile. Dazu zählten die kostengünstigere "Herstellung" von IT-Services sowie die schnellere Reaktion auf Veränderungen im Geschäftsmodell, folglich mehr Dynamik und Effektivität im Business.