MÜNCHEN (COMPUTERWOCHE) - Mit einheitlichen Software-Releases können Unternehmen Kosten sparen und den Support vereinfachen. Doch der Weg zu homogenen IT-Strukturen ist steinig. Die schiere Zahl installierter Systeme und die oft stark modifizierten Programme besonders im SAP-Umfeld bereiten den Verantwortlichen Kopfzerbrechen.

Der Aufschwung kommt, doch niemand weiß genau wann. Gewiss ist für viele deutsche IT-Verantwortliche derzeit nur eines: Der Kostendruck bleibt bestehen - und damit die Notwendigkeit, IT-Strukturen effizienter als bisher zu gestalten. Ein Zauberwort dabei heißt Konsolidierung. Es bezieht sich gleichermaßen auf organisatorische wie auf technische Fragen. In der meist heterogenen Softwarelandschaft mittlerer und großer Unternehmen steht deshalb auch das Thema Release-Management ganz oben auf der Tagesordnung.

Kostenträchtige SAP-Projekte

Ein Paradebeispiel für kostenträchtige Einführungs- und Migrationsprojekte gibt noch immer SAP mit den unterschiedlichen R/3- oder mySAP.com-Varianten. Zwar haben rund 90 Prozent der deutschen Anwender eine Release-Version ab 4.x im Einsatz, schätzt Stefan Klose von der Deutschen SAP-Anwendergruppe (DSAP). Doch in Großunternehmen wie Siemens mit zum Teil mehreren hundert installierten SAP-Systemen reicht das Spektrum von 4.0B, 4.5B über 4.6B bis hin zur jüngeren Version 4.6C. Dagegen sind 3.x-Releases nur noch selten anzutreffen; die älteste R/3-Version mit Supportgarantie von SAP ist 3.1I.

Im Schnitt arbeiten die Kunden mit drei bis vier unterschiedlichen R/3-Releases, sagt Michael Staade von Alldata Systems. Das SAP-Systemhaus betreut neben Großunternehmen wie Bayer, Wella oder Daimler-Chrysler Aerospace auch Mittelständler. Letztere befinden sich laut Staade meist auf einem aktuelleren Release-Stand. Grund dafür sei die höhere Komplexität in Großunternehmen und der damit verbundene Aufwand beim Release-Wechsel. Gerade Konzerne könnten oder wollten diesen häufig nicht schultern, aber: "Auch die Großen haben erkannt, dass sie sich nicht mehr so viele Releases leisten können." Harald Ohler, Leiter des Competence Centers SAP bei CSC Ploenzke, teilt diese Einschätzung. Die Vereinheitlichung von IT-Strukturen und damit auch des Release-Managements sei ein "genereller Trend" bei deutschen

Anwendern.

Ursächlich für die schwierige Release-Vereinheitlichung ist ein Phänomen, das Staade "eigendynamisches Customizing" nennt. Gemeint sind die vielfältigen Anpassungs- und Erweiterungsmöglichkeiten, die SAP für seine Programmpakete offeriert. "Das reine technische Upgrade macht den Release-Wechsel nicht teuer und kompliziert", erklärt auch Anwendersprecher Klose. Probleme träten immer dann auf, wenn viele eigene Funktionen in R/3 programmiert oder sogar das System selbst modifiziert wurde. "SAP ist der Weltmeister, was Funktionalitäten angeht."

Zwar habe der Walldorfer Softwarehersteller das Thema über ein detailliertes Erweiterungskonzept entschärft. Alle Vorgaben zu verstehen und umzusetzen sei für Systemverantwortliche aber "eine richtige Herausforderung". Hinzu kommt der Zeitdruck, der gerade in SAP-Projekten noch immer zu Fehlern führt. Klose: "Um bei der R/3-Einführung Zeit zu sparen, wird schon mal der Vorschlaghammer rausgeholt. Das kann sich bei einem späteren Update rächen."

Mit der Einführung von R/3 Enterprise hat SAP die Schwierigkeiten beim Release-Wechsel gemildert, meint Ohler. Kernfunktionen von R/3 sind dabei gekapselt und bleiben bis zum Jahr 2007 stabil. Anwender können somit beispielsweise Updates im Modul HR einführen, ohne andere neue Funktionen im FI-Modul aktivieren zu müssen. Das Core-System bleibt unberührt.

Weniger Aufwand mit R/3 Enterprise

MySAP.com-Komponenten wie CRM, APO oder BW lassen sich schon jetzt unabhängig vom darunter liegenden Basis-Release aktualisieren. Für diese Anwendungen hat der Hersteller ohnehin eine andere Release-Taktung gewählt. "Wenn R/3 Enterprise erstmal im Einsatz ist, reduziert sich der Aufwand bei Erweiterungen deutlich", so Ohler. "Deshalb sind auch kürzere Projektlaufzeiten zu erwarten."

Aus nahe liegenden Gründen ist SAP unterdessen bemüht, die Anzahl unterstützter Software-Releases zu verringern. So müssen etwa Anwender älterer R/3-Versionen, die nicht upgraden wollen, künftig einen Wartungsbeitrag bezahlen. Die Walldorfer erhoffen sich davon nicht zuletzt, Kunden für mySAP.com zu gewinnen.

Nach Staades Projekterfahrung bereitet die technische Abwicklung bei der Vereinheitlichung noch die wenigsten Probleme. "Viele Vorhaben scheitern schon vorher, weil keine gemeinsamen betriebswirtschaftlichen Strukturen vorhanden sind." Mindestens die Hälfte des Projektaufwands und des Erfolgs hingen davon ab, ob es gelinge, einheitliche betriebswirtschaftliche Grundlagen zu schaffen. Diese Erfahrung musste etwa die Alldata-Muttergesellschaft Arag machen. Beim Auslands-Rollout von R/3 gab es schon Probleme, sich auf einen gemeinsamen Kontenrahmen zu einigen. "Der Mutterkonzern führt etwa 1500 Konten", so Staade, "die kleine Niederlassung in Tschechien aber braucht die nicht."

Dass einheitliche IT-Strukturen dazu beitragen können, die Kosten zu senken, ist unbestritten. Für Ohler liegen Sparpotenziale allerdings weniger im einheitlichen Release-Management als darin, die Vielzahl installierter Systeme zu verringern. Dann seien auch Einsparungen im Betrieb und in den Prozessen möglich. Nach einer Zusammenlegung könnten IT-Verantwortliche beispielsweise die Supportorganisation verkleinern. Auch Hardwarekosten lassen sich drücken, wenn etwa mehrere SAP-Systeme auf einem Server installiert sind und verschiedene Teilorganisationen bedienen.

Ein prominentes Beispiel liefert der Siemens-Konzern, der weltweit mindestens 200 SAP-Systeme betreibt. Schätzungen zufolge sind damit auch vier bis fünf unterschiedliche R/3-Releases im Einsatz. Siemens-CIO Friedrich Fröschl hat die IT-Konsolidierung zur "obersten Priorität" erklärt. Von der Vereinheitlichung und Zusammenlegung der SAP-Systeme verspricht sich der Manager jährliche Einsparungen in dreistelliger Millionenhöhe.

Ohler hält solche Werte für erreichbar, vorausgesetzt, Siemens schöpfe die Sparpotenziale einer regionalen IT-Konsolidierung aus. Untersuchungen von CSC Ploenzke hätten ergeben, dass für einen globalen Konzern eine regional ausgerichtete IT-Konsolidierung unter Kosten-Nutzen-Aspekten am sinnvollsten sei. Weniger gut habe ein Szenario mit nur einem Zentralsystem abgeschnitten. Eine vollständig dezentral ausgerichtete Organisation, wie sie gegenwärtig bei Siemens anzutreffen ist, berge ebenfalls zu viele Nachteile.

Auf der Client-Seite, also im Windows- und Office-Bereich, sieht der CSC-Ploenzke-Mann weniger Einsparmöglichkeiten durch ein einheitliches Release-Management. Um heterogene Client-Strukturen in den Griff zu bekommen, gebe es zudem andere Möglichkeiten, beispielsweise über Thin-Client-Konzepte oder Web-Frontends.

In vielen Fällen ist eine Standardisierung allerdings auch auf den PCs vonnöten, wie das Beispiel der Techniker Krankenkasse (TK) zeigt. Die Hamburger stellten die rund 8000 Client-Rechner im letzten Jahr komplett auf Windows 2000 und Office 2000 um. Unterschiedliche Release-Stände sind unternehmensweit eher selten anzutreffen, berichtet Hans Herbert Langer, Fachbereichsleiter IV-Support. Insbesondere bei Office-Anwendungen sei ein einheitliches Release-Management dringend notwendig. "Ein Wildwuchs in diesem Bereich würde uns über Gebühr Support- und Kompatibilitätsprobleme bereiten."

Automatische Softwareverteilung

Für das "Betanken" der Rechner verwendet Langer das Programm "Netinstall" von Net Support. Dabei wird über das Symantec-Tool "Ghost" zunächst eine Standardinstallation aus dem Netz gezogen und ein Standard-Image auf die Clients gespielt. Die unterschiedlichen Anwendungsroutinen und Updates installiert das IT-Team dann weitgehend automatisch, das heißt ohne Eingriff der Benutzer, via Netinstall. Ähnlich verfahren die Hanseaten mit den R/3-Frontends.

Auch im Backend strebt die TK homogene IT-Strukturen an. So arbeiteten die R/3-Module HR (Human Resources) und FI/CO (Finance and Controlling) früher in unterschiedlichen Release-Ständen. Mittlerweile wurden beide Systeme auf die aktuelle R/3-Version 4.6C migriert. Dadurch ergeben sich vor allem im Support "wesentliche Erleichterungen", sagt Langer. In Euro und Cent lassen sich die Einsparungen aber nur schwer beziffern.

Automatische Softwareverteilung ist auch bei der Dresdner Bank fester Bestandteil des Release-Managements. In den Geschäftsstellen der Bank gebe es keine unterschiedlichen Release-Stände, erläutert Klaus Schönkäs vom unternehmenseigenen IT-Dienstleister Dregis. "Die haben alle das gleiche Office, das gleiche Betriebssystem und den gleichen Patch-Level." Auf den rund 30.000 Clients der Niederlassungen arbeitet derzeit fast ausnahmslos Microsofts Office 97 unter Windows NT 4.x.

Technisch hat Dregis die Release-Verwaltung über eine Change-Management-Datenbank realisiert. Im Backend und inbesondere am Standort Frankfurt/Main sehen die Strukturen anders aus. Wegen der dezentralen Verwaltung ist auch die IT der Banker in diesem Bereich sehr viel heterogener aufgestellt.

Das allerdings soll sich ändern. Seit der Fusion mit dem Allianz-Konzern im Herbst 2001 läuft auch in der IT ein umfassender Reorganisations- und Integrationsprozess, der nach Meinung von Experten mehr als drei Jahre dauern kann. Damit verbunden sind Konsolidierungsprojekte "auf allen Ebenen", wie aus dem Unternehmen zu hören war. (wh)