von Dr. Andreas Hufgard

Ein Plädoyer für die kontinuierliche betriebswirtschaftliche Konsolidierung von SAP-Landschaften und ihren Geschäftsprozessen in fünf Schritten.

Die Konsolidierung von SAP-Systemen ist eine komplexe Aufgabe. Dessen sind sich viele SAP-Anwenderunternehmen nicht bewusst. Solche Konsolidierungsprojekte sind immer mit Chancen und Risiken verbunden. Sie erfordern eine dezidierte Analyse der technischen und betriebswirtschaftlichen Rahmenbedingungen. Mit dem bloßen Zusammenschieben von Tabellen aus unterschiedlichen SAP-Systemen auf ein zentrales SAP-System ist es also längst nicht getan. Es gilt vielmehr, neben der technischen Vorgehensweise die betriebswirtschaftlichen Synergieeffekte zu analysieren und auszureizen. Wird eine exakte Analyse vernachlässigt, führt dies unvermeidlich zu einem hochkomplexen „Mega-SAP-System“. Ein solches muss – wie in einem Katalysator – aufwändig bereinigt, skaliert und standardisiert sowie im Hinblick auf die Qualität, sprich Excellence, der Anwendungen harmonisiert werden. Erst wenn all diese Kriterien erfüllt sind, kann erfolgreich transformiert und konsolidiert werden. Dieses Verfahren bietet sich aber nicht nur an, wenn verschiedene SAP-Systeme zusammengeführt werden sollen, sondern auch wenn Strategien, Geschäftsmodelle und Geschäftsprozesse an die SAP-Infrastruktur angepasst werden müssen. Diese so genannten Business-IT-Transformationen bieten die Chance, Freiraum für notwendige Innovationen zu schaffen.

Was heißt SAP-Konsolidierung?

Die Zusammenführung von zwei oder mehreren Mandanten wird allgemein als SAP-Konsolidierung bezeichnet. Die Mandanten zeichnen sich dadurch aus, dass sie in unterschiedlichen SAP-Systemen, sprich auf unterschiedlichen Servern, an unterschiedlichen Standorten, angelegt waren. Die Auslöser für eine Konsolidierung der SAP-Mandanten sind in der Regel Einsparprogramme oder Unternehmensfusionen. Neben dieser so genannten Mandantenkonsolidierung gibt es noch Multi-Konsolidierungen aus mehreren Quellsystemen und Teilkonsolidierungen von bestimmten Organisationsbereichen. Letztere werden meist im Zuge von Restrukturierungen oder bei Merger & Acquisitions (M&A) angewendet.

Der Konsolidierungsprozess selbst kann in zwei Stufen unterteilt werden. In der ersten Stufe, der technischen System-Konsolidierung, wird an sich nur die Ablauffähigkeit des Mandanten auf einem zentralen SAP-System in einem bestimmten Rechenzentrum beeinflusst und verändert. Sie stellt die einfachste Form der Konsolidierung dar. Ziel der technischen System-Konsolidierung ist es, genau diesen Mandanten von einer Systemumgebung auf eine andere zu verlagern und dort zum Laufen zu bringen. Die volle Mandanten-Konsolidierung macht aus zwei oder mehreren Mandanten eine Einheit, die nur noch durch die Organisationselemente in SAP, beispielsweise Buchungskreise und Werke, unterschieden werden können. Inzwischen ist auch bewiesen, dass es unproblematisch ist, hunderte von Buchungskreisen und Werken in einem SAP-Mandanten zu betreiben. Dies belegen die vielen Anwendungen, die bei Großkonzernen erfolgreich eingesetzt werden. Im Rahmen von IBIS RBE-Plus-Systemanalysen wurden beispielsweise Einzelsysteme mit über 500 Buchungskreisen und 2.500 Werken pro Mandant festgestellt. Untersucht wurden jeweils ein amerikanischer und ein deutscher Konzern.

Ihre wirklichen Nutzenpotenziale können Konsolidierungsprojekte aber erst in der zweiten Stufe entfalten. In der zweiten Stufe werden neben den technischen Elementen auch immer betriebswirtschaftliche Maßnahmen einbezogen. Jedoch sind solche Projekte nicht einfach zu realisieren, da sie nicht alleine im Verantwortungsbereich der IT-Abteilung liegen und somit eine abteilungsübergreifende Zusammenarbeit erfordern. Wie immer wenn man etwas wirklich Nützliches erreichen will, sollten aber gerade bei Konsolidierungsprojekten „Business“ und „IT“ gemeinsam agieren und die Unternehmensleitung, Fachabteilungen sowie die IT-Abteilung an einem Strang ziehen.

Zentralisiere und alles wird gut?

Die Verantwortlichen in den Unternehmen können Einsparungen, die durch Konsolidierungsprojekte erzielt werden können, einfach nachvollziehen. Auf den ersten Blick erscheinen diese zunächst oft plausibel. Schließlich können Standorte, Hardware und Schnittstellen zentralisiert und infolgedessen reduziert werden. Meist ist deswegen die technische Konsolidierung von SAP-Mandanten auch die erste (und einfachere) Projektphase. Falsch wäre es allerdings auf dieser ersten Konsolidierungsstufe zu verharren. Denn die Synergieeffekte, die mittels technischer Konsolidierungen erzielt werden, sind vermeintlich nicht so groß, wie sie vordergründig erscheinen. Das liegt daran, dass lediglich die mandantenübergreifenden Tabelleninhalte und alle Vorgänge, die auf der Systemebene stattfinden, zusammengeführt werden. Beispielsweise Nummernkreise oder auch technische Objekte der Entwicklungsumgebung sind davon betroffen. Diese machen zusammen zwar rund ein Drittel der SAP-Datentabellen aus, beziehen sich jedoch kaum auf betriebswirtschaftliche Inhalte. In diesem Zusammenhang müssen auch gegenläufige Effekte berücksichtigt werden. So steigen durch eine technische Konsolidierung die Komplexität, Ausfallrisiken sowie die Dauer von Change-Zyklen. Darum empfiehlt es sich, die Situation, Potenziale und Risiken klar zu bewerten, bevor eine technische Konsolidierung überhaupt begonnen wird.

Tabelle: Pro- und Contraeffekte eines zentralen SAP-Systems

Aufgrund der hier ausgeführten Chancen und Risiken ist es nicht überraschend, dass den Versprechungen der Konsolidierungsbefürworter massive Argumente entgegengehalten werden. Dies geschieht aus gutem Grund: Denn die Vorteile einer solchen Konsolidierung können vollkommen bedeutungslos werden, wenn die Risiken und Nachteile eines solchen Projektes nicht beachtet, analysiert und identifiziert werden. Zu Großrechner- und SAP R/2-Zeiten war in diesem Zusammenhang oft die Rede von so genannten„Dinosaurier-Systemen“, die jede Art von organisatorischen Wandel verlangsamten oder gar unmöglich machten. Um solchen hochkomplexen Systemstrukturen entgegenzuwirken, müssen konsequent zusätzliche Konsolidierungsmaßnahmen in Angriff genommen werden.

Bestimmte Arten der Zusammenführung von SAP-Systemen liegen allerdings nahe und sind unkritisch. Dies verdeutlicht ein Beispiel aus der jüngeren SAP-Vergangenheit: In den 90er Jahren wurden SAP-Systeme nach bestimmten Funktionen, beispielsweise Anwendungen für die Logistik und das Rechnungswesen, getrennt eingeführt. In solchen Fällen ist eine Konsolidierung sinnvoll, da die Vorteile einer Integration schlicht überwiegen. Doch schon bei Personal-Systemen gilt das aufgrund der geringeren Integrationsnotwendigkeit und wegen datenschutzrechtlichen Bestimmungen nicht mehr. Auch dezentrale SAP-Systeme für weltweit verteilte Werke oder Verkaufsniederlassungen in unterschiedlichen Ländern sind in der letzten Konsolidierungsrunde (bis in das Jahr 2003) meist auf wenige Regionalsysteme zusammengefasst worden. Das wirft die Frage auf, was es nun, auf diesem Niveau angekommen, noch weiter zu zentralisieren gibt? Diese Frage kann das Projektteam nur richtig beantworten, wenn es die betriebswirtschaftlichen Nutzungsunterschiede dezidiert kennt und bewerten kann.

Drum vergleiche, wer sich ewig bindet!

Wenn diese betriebswirtschaftlichen Nutzungsunterschiede verlässlich verglichen werden sollen, ist ein Abgleich der tatsächliche Nutzung aller im Einsatz befindlichen SAP-Anwendungen erforderlich. Vor einer Gegenüberstellung aller Tabellen und aller Programm-Codes kann hier nur eindringlich gewarnt werden. Solche Vergleiche erzeugen viele unnötige Daten, die zu keinem verwertbaren Ergebnis führen. So kann ein kompletter Tabellenabgleich beispielsweise die Unterschiede in den Sprachversionen der im Einsatz befindlichen SAP-Systeme aufzeigen. Ein solches Ergebnis hat allerdings wenig Aussagekraft, wenn die einzelnen Versionen gar nicht genutzt werden. Vergleiche sollten sich daher ganz gezielt mit den genutzten Aspekten der SAP-Infrastruktur beschäftigen.

Die Ungenauigkeit einer manuellen Untersuchung ist dabei ein erheblicher Nachteil. Oft werden ganze Systembereiche oder wichtige Details vergessen. Mit der gravierenden Folge, dass nach der Übernahme ins Zielsystem notwendige Funktionen nicht zur Verfügung stehen. Solche Situationen können für ein Unternehmen katastrophal sein. Deswegen empfiehlt sich hier der Einsatz von speziellen Werkzeugen für die Nutzungsanalyse und den professionellen Nutzungsabgleich. RBE Plus stellt beispielsweise sicher, dass die SAP-Quell- und Zielsysteme gezielt und systematisch untersucht werden (Verweis auf Artikel „7 Grundsätze“).

In gewachsenen Systemlandschaften geht schnell der Überblick verloren. Die Frage, warum und wie genau welche Prozesse und Funktionen abgewickelt werden, kann in den seltensten Fällen exakt beantwortet werden. Viele SAP-Anwender haben diesbezüglich lediglich Vermutungen oder besitzen zumindest einen Teilüberblick über die Prozesslandschaft. Dafür sind zwei Dinge maßgeblich verantwortlich: Einerseits die Mitarbeiterfluktuation in den Unternehmen und andererseits die Erkenntnis, dass SAP-Systeme aufgrund der ständigen Änderungen und Anpassungen zur Unordnung streben. Da diese Situation in den meisten Unternehmen anzutreffen ist, gibt es keine echte Alternative zur werkzeugbasierten Nutzungsanalyse (siehe Artikel Situations- und Potenzialanalyse). Nur wenn eine solche Analyse durchgeführt wird, kann ein Konsolidierungsprozess erfolgreich angestoßen und abgeschlossen werden. Nehmen wir als Beispiel die genutzten und ungenutzten Kundentransaktionen oder das kundenindividuelle Customizing, welches in einem SAP-System ständig vorgenommen wird. Es kann im Nachhinein sehr schwierig werden, die Zugehörigkeit dieser technischen Objekte wiederum auf einen Mandanten beziehungsweise die betriebswirtschaftliche Nutzung in diesem Mandanten zurückzuführen. Deswegen ist es sehr wichtig vor der Konsolidierung auf Mandanten- oder Systemebene eine Nutzungsanalyse durchzuführen. Nur so kann im Nachhinein diese Information reproduziert werden und entlang der Prozesskette die richtigen Rückschlüsse gezogen werden.

Ein Praxisbeispiel aus RBE Plus-Analysen: Bei einem großen deutschen Mischkonzern wurden aktuell nur noch 10% der Fakturaarten genutzt. Aufgrund von Verkäufen, Aufkäufen und Fusionen wusste in der IT niemand mehr, woher die anderen kamen oder warum sie noch existierten. Ein mehrköpfiges Projektteam wurde eingesetzt, um für den anstehenden Upgrade die Relevanz der einzelnen nicht mehr genutzten Fakturaarten zu bereinigen. Demnach werden viele Upgrades auch deswegen teurer, weil vorher nicht bereinigt bzw. konsolidiert wurde.

Lücken schließen und Identitäten abgleichen!

Eine geradezu „schmerzhafte“ Erkenntnis, die viele IT-Konsolidierer gemacht haben, ist die Tatsache, dass sich aufgrund der betriebswirtschaftlichen Nutzungsunterschiede zwei völlig unterschiedliche Teilprojekte ergeben. Einerseits müssen Funktionalitäten, die im Zielsystem fehlen neu eingeführt und andererseits jene, die im Ziel- und Quellsystem identisch sind, mühevoll abgestimmt werden. Die spannende Frage hierbei ist, welches Vorhaben eigentlich den größeren Aufwand verursacht? Hier gilt es zu berücksichtigen, dass es grundsätzlich auch die Alternative gibt, ein neues „redesigntes“ Zielsystem aufzubauen, das ohne Altlasten die besten Konzepte (Best Practices) übernimmt und den „Aufbruch zu neuen Ufern“ entscheidend erleichtert.

Ein Praxisbeispiel aus RBE-Analysen: Ein osteuropäischer Konzern hatte wohl aufgrund des relativ niedrigen Lohnniveaus der ansässigen Entwickler zwei extrem individualisierte SAP-Mandanten für zwei seiner Teilgesellschaften aufgebaut, die er jetzt konsolidieren wollte. Nach Auswertung der RBE Plus-Nutzungsanalyse wurde der Neuaufbau des Zielmandanten beschlossen. Der Aufwand für den Abgleich wäre wesentlich größer gewesen. Die Vergleichsanalysen sollten deswegen, insbesondere folgende Fragen beantworten und infolgedessen verwertbare Ergebnisse schaffen:

• Im Rahmen der Identitätenanalyse: Welche Prozesse, Funktionen etc. werden im geplanten Zielsystem und mindestens einem Quellsystem genutzt?
• Im Rahmen der Lückenanalyse: Welche Prozesse, Funktionen etc. fehlen im Zielsystem und werden in einem oder mehreren Quellsystemen genutzt?

Die Identitätenanalyse ermittelt, welche Transaktionen, Prozesse und Funktionen in allen SAP-Systemen vorhanden sind und genutzt werden. Nachdem die identischen Prozesse und Funktionen identifiziert sind, muss für diese Objekte deren Anpassung im Detail betrachtet werden. Ziel dieses Detailabgleiches ist es, festzustellen, ob bei den übereinstimmend verwendeten Schlüsseln die Attribute deckungsgleich sind oder nicht. Bei identischen Schlüsseln können diese im besten Fall beibehalten und auch im gemeinsamen System verwendet werden. Geht das aus rechtlichen Gründen nicht und müssen die Schlüssel abweichen, so muss das Projektteam entscheiden, welche zukünftig zu verwenden und umzusetzen sind. Der technische Tabellenabgleich ist hier recht einfach machbar. Allerdings gilt es im Vorfeld zu klären, was fachlich richtig ist? Deshalb müssen auf Grundlage der Analyse zu allererst die fachlichen Vorgaben festgelegt werden.

Die Lückenanalyse erkennt hingegen alle Transaktionen, Prozesse und Funktionen der Quellsysteme, die nicht im Zielsystem vorhanden sind. Hier sollte festgelegt werden, ob diese auch künftig zur Verfügung stehen sollen. Prozesse und Funktionen, die später im Zielsystem zusätzlich vorhanden sein sollen, müssen dann entsprechend eingeführt und betreut werden. Sollen die fehlenden Prozesse nicht übernommen werden, so muss den Anwendern eine Alternative aufgezeigt werden, wie ihre Anforderungen künftig IT-gestützt erfüllt werden können.

Auf Basis von Vergleichsanalysen können weitere Nutzenpotenziale erkannt, bewertet und erschlossen werden, die über eine technische oder im Extremfall rein mechanistische SAP-Konsolidierung hinausgehen. Ist die Frage des Zielsystems noch offen, können auch Quell- und Zielsystem in der Vergleichsanalyse vertauscht werden.

In fünf Schritten zur Excellence im Zielsystem

Die vorgeschlagenen Schritte folgen zunächst der Reverse Business Engineering (RBE)-Richtung. Diese erstreckt sich von der IT-basierten Ausgangssituation über die betriebswirtschaftlichen Potenziale und der damit verbundenen Abstimmung mit der Fachabteilung bis hin zur Einbindung der Unternehmensleitung. Für geplante Business Transformationen, die zunächst zu Change-Management-Aktivitäten oder Re-Design-Projekten des so genannten Forward Business Engineerings (FBE) führen, muss die umgekehrte Reihenfolge eingehalten werden. Die Methoden können für beide Projektarten verwendet werden.
Abbildung 1: In fünf Schritten zu Excellence und Innovation

• Schritt 1: Der Abgleich der wirklich genutzte Elemente auf Identitäten und Lücken im Zielsystem, erlaubt es umgekehrt, die nicht genutzten Elemente zu identifizieren und schließlich zu bereinigen.
• Schritt 2: „Teure“ Anwender und Randbereiche der Nutzung werden fokussiert, um konkrete Ansatzpunkte für die Reduktion von Betriebs- und Betreuungskosten zu finden.
• Schritt 3: Standardisierung spart Kosten durch klare Richtlinien und Vereinfachung. 
• Schritt 4: Für eine Harmonisierung wird versucht, die effizienteste und effektivste Umsetzung eines Geschäftsmodells zu finden, um in ähnlichen Bereichen die Stammdaten, Funktionen oder Prozesse daran anzugleichen und zu reduzieren.
• Schritt 5: Um die eine Transformation zielorientiert und innovativ zu gestalten, muss auf IT-Ebene eine vorausschauende Adaptionsbereitschaft angestrebt werden.    
  
  

Alle Projektleiter oder Planer eines Konsolidierungsprojektes sollten versuchen, auf Grundlage der Ergebnisse der Vergleichs-, Lücken- und Identitätenanalyse, möglichst alle fünf Schritte zu durchlaufen. Das Bereinigen, Skalieren und Fokussiere kann am besten vor einer technischen Systemkonsolidierung umgesetzt werden. Die Folgeschritte Standardisieren und Harmonisieren sind zeitlich unabhängig machbar. Die systematische Vorbereitung zum „Transformieren“ ist eine Fähigkeit, die es permanent auszubauen gilt.

Weitere Informationen wie RBE Plus die Schritte im Einzelnen unterlegt, geben wir Ihnen gerne in einem Projektvorschlag.