Unternehmenszukäufe, neue Produktlinien und sich ständig ändernde Vertriebskanäle sorgen für Wildwuchs in der Applikationslandschaft. Oft wird das Konzept der Service-orientierten Architektur (SOA) als Allheilmittel für den Aufbau einer kostengünstigen und effizienten IT-Landschaft angepriesen. Aber muss jedes Unternehmen seine komplette IT-Architektur umkrempeln, damit sich Applikationen konsolidieren lassen? Tatsächlich gibt es eine ganze Reihe von Stellschrauben, an denen der IT-Verantwortliche drehen kann, um eine ausufernde Softwarelandschaft einzudämmen.

Konsolidierungspotenzial heben

Gerade wenn Organisationen durch Zukäufe gewachsen sind, müssen sie sich erst einmal einen Überblick darüber verschaffen, welche Software überhaupt eingesetzt wird und für welche Zwecke sie die einzelnen Abteilungen nutzen. In großen Firmen existieren nicht selten mehrere tausend Applikationen parallel. Da der Konsolidierungsprozess das Unternehmen oft als Ganzes mit all seinen Geschäftsprozessen betrifft, lässt sich signifikantes Konsolidierungspotenzial nur dann identifizieren, wenn möglichst große Teile des Unternehmens in die Betrachtung einbezogen werden. Deshalb sollte ein solches Projekt immer auf der Vorstandsebene verankert sein.

Konsolidieren ja - aber nach welchen Kriterien?

Mit speziellen Methoden und Datenbanken können IT-Verantwortliche sämtliche Applikationen erfassen. Bevor IT-Verantwortliche jedoch damit beginnen, sollten sie festlegen, nach welchen Kriterien die Softwarelandschaft konsolidiert werden soll. Das ergibt sich meist aus den strategischen Vorgaben für die Unternehmens-IT. Ein häufiger Anlass ist die angestrebte Reduktion der Betriebskosten: Gibt es weniger Applikationen, sinkt der Administrationsaufwand. Aber auch der Wunsch, möglichst unternehmensweit auf eine einheitliche ERP-Plattform zu migrieren, kann Auslöser für die Konsolidierung sein.

Im folgenden Schritt müssen sich die IT-Verantwortlichen einen Überblick über die Ist-Situation der Softwarelandschaft verschaffen. Das ist oft ein mühseliger Prozess, da die Informationen nicht an zentraler Stelle vorliegen. Zumal darauf zu achten ist, dass sich die im Repository gesammelten Informationen auch weiterhin pflegen lassen. Denn eine Softwarekonsolidierung ist nicht selten auf Jahre angelegt. Würden Änderungen nicht permanent in die Bestandsaufnahme einfließen, wäre dies fatal. Eine Datenbank für ein solches Projekt muss deshalb eine laufende Pflege der Daten zulassen - mit einfachen Excel-Dateien ist es meist nicht getan.

Ausgangspunkt Geschäftsprozess

Man sieht den Wald vor lauter Bäumen nicht - dieses Gefühl beschleicht wohl so manchen CIO, wenn er die Softwarelandschaft im gesamten Unternehmen untersuchen muss. Trotzdem ist der Top-down-Ansatz bei der Analyse von Konsolidierungspotenzial unumgänglich. Die Geschäftsprozesse sind dabei der Ausgangspunkt: angefangen bei Level 0 - den Kerngeschäftsprozessen wie zum Beispiel Einkauf, Produktion oder Service auf oberster Ebene, bis zum Level 3 - einer Detaillierungsstufe bis auf Subprozesse hinunter, beispielsweise bei der Bewertung von Lieferanten oder Order-to-Cash-Prozessen.

Wenn Unternehmen nicht schon generell sämtliche Geschäftsprozesse und die entsprechenden Applikationen analysiert und dokumentiert haben, hilft oft ein Referenzmodell, um sich einen Überblick über Prozesse und Anwendungen zu verschaffen. Auf Grundlage eines solchen Modells müssen die Projektverantwortlichen die Abteilungsleiter befragen, wie die Prozesse und die IT in ihrem Verantwortungsbereich strukturiert sind. So entsteht Schritt für Schritt ein komplettes Bild der gesamten IT im Unternehmen.

Mit Programm-Management alles im Griff

Konsolidierungsprojekte brauchen Zeit, währenddessen steht das Unternehmen nicht still. Hier liegt ein möglicher Stolperstein. Deshalb müssen die Verantwortlichen neue IT-lastige Projekte stets auf ihre Konformität mit der gesamten Infrastruktur, die gerade verändert wird, abklopfen. Das fällt in den Aufgabenbereich der Mitarbeiter, die das Architektur-Management verantworten. Im Rahmen des Programm-Managements wird dann geprüft, ob die einzelnen IT-Projekte tatsächlich effektiv ineinander greifen und ob sie im Vorfeld einer Softwarekonsolidierung überhaupt sinnvoll sind: So lohnt es sich zum Beispiel nicht, eine Anwendung um neue Funktionen zu erweitern, wenn diese im Rahmen des Projekts ein paar Monate später abgeschaltet wird. Es ist die Aufgabe des Programm-Managements, hier Transparenz zu schaffen. Sind Programm- und Architektur-Management etabliert, kann der IT-Verantwortliche Architekturprinzipien, Standards und Governance-Strukturen für die zukünftige Softwarelandschaft festlegen. Das ist der Soll-Zustand. Auf dieser Basis erstellen die IT-Verantwortlichen eine Roadmap, die den Weg zur neuen IT-Architektur beschreibt.

Auf das Datenmodell kommt es an

Mit Hilfe der schon angesprochenen, extra zu diesem Zweck entwickelten Datenbanken können IT-Verantwortliche herausfinden, mit welchen Geschäftsprozessen die einzelnen Anwendungen verknüpft sind. Zudem können sie Applikationen erfassen und danach klassifizieren, welche Geschäftsprozesse sie abdecken. Die gewonnenen Daten bilden dann die Entscheidungsgrundlage für ein Konzept zur Softwarekonsolidierung.

Entscheidend ist dabei das Datenmodell des Repositorys. Denn darin ist festgelegt, welche Attribute und Informationen für die einzelnen Applikationen zu erfassen sind. Diese reichen von elementaren Angaben wie Name und Kurzbeschreibung der Applikation bis hin zu komplexen Themen wie Betriebs- und Supportkosten. Angaben zur Zahl der Instanzen einer Applikation oder ob eine Software regional oder zentral eingesetzt wird, sollte das Datenmodell ebenfalls enthalten.

Diese Berichte geben Auskunft darüber, an welcher Stelle für ähnliche Geschäftsprozesse verschiedene Anwendungen im Einsatz sind, die aber im Wesentlichen dieselben Aufgaben erledigen.

Die Guten ins Töpfchen: Softwareauswahl

Im nächsten Schritt ermittelt das Projektteam anhand der Datenbank das tatsächliche Konsolidierungspotenzial und quantifiziert die Möglichkeiten anhand der gesetzten Ziele: Wo lassen sich Betriebs-, Support- und Prozesskosten reduzieren? Erreichen wir mit dem benannten Konsolidierungspotenzial eine höhere Agilität? Solche Fragen gilt es in dieser Projektphase zu klären.

Dann müssen die Verantwortlichen entscheiden, welche Applikationen sie abschalten wollen und welche quasi als Standard unternehmensweit deren Aufgaben übernehmen sollen. Dabei ist es sinnvoll, nach folgenden Kriterien vorzugehen:

1. Abdeckungsgrad der Geschäftsprozesse, denen die Appli-kation zugeordnet ist beziehungsweise zugeordnet werden soll.

2. Betriebs- und Supportkosten einer Applikation.

3. Business Continuity Risk, das heißt die Zukunftssicherheit einer Plattform. Damit wird der Investitionsschutz gewährleistet.

4. Eignung für einen Shared-Services-Ansatz.

Die Applikationen sollten möglichst auf Standards aufbauen, damit sie einfach an verschiedenen Stellen im Unternehmen einsetzbar sind. Das ist auch eine wesentliche Voraussetzung, falls das Unternehmen eine Service-orientierte Architektur (SOA) aufbauen möchte.

Haben die Verantwortlichen die geeigneten Anwendungen ausgewählt, können sie alle anderen Lösungen sukzessive abschalten. Dabei ist es wichtig, dass in den Konsolidierungsplan ein Migrationsprojekt integriert ist, das vor dem Abschalten der Applikationen abgeschlossen wird. (ba)