Aufräumen statt migrieren:SAP-Analytics-Landschaft zukunftsfähig weiterentwickeln

Über viele Jahre sind in Business-Warehouse-Systemen Anwendungen, Kennzahlen und Berichte gewachsen, während sich Organisationen, Prozesse und Geschäftsmodelle kontinuierlich verändert haben. Neue Anforderungen wurden ergänzt, statt bestehende Strukturen zu hinterfragen und zu bereinigen. So entstanden historisch gewachsene Business Warehouse (BW)-Landschaften mit redundanten Inhalten, komplexen Abhängigkeiten und zunehmender Unübersichtlichkeit. Eine Modernisierung bietet nun die Chance, gewachsene BW-Strukturen nicht einfach fortzuführen, sondern sie grundlegend zu hinterfragen und zukunftsfähig weiterzuentwickeln.

Im Mittelpunkt steht dabei weniger die technische Erneuerung als die Frage, welche Daten, Prozesse und analytischen Anwendungen künftig tatsächlich benötigt werden – und wie sich daraus eine schlankere, klar strukturierte und leistungsfähige Analytics-Landschaft entwickeln lässt. „Wer eine BW-Landschaft unverändert übernimmt, modernisiert keine Analytics-Landschaft. Er modernisiert lediglich die technische Plattform“, sagt Jochen Weintz, Geschäftsführer der Infocient Consulting GmbH und erfahrener Begleiter von SAP-Analytics- und BW-Modernisierungsprojekten.

Mit der Komplexität gewachsener Analytics-Landschaften steigt der Bedarf, diese Strukturen grundlegend zu überprüfen. Zwar liegt häufig der erste Impuls darin, möglichst schnell auf eine neue Plattform zu wechseln und bestehende Inhalte weitgehend unverändert zu übernehmen. Genau darin sieht Jochen Weintz jedoch eines der größten Risiken: „Die technische Migration ist selten die eigentliche Herausforderung. Schwieriger ist die Entscheidung, welche Inhalte überhaupt noch einen fachlichen Mehrwert liefern und welche historisch gewachsen sind.“ Eine erfolgreiche Modernisierung beginnt deshalb nicht mit der Migration einzelner Objekte, sondern mit einer systematischen Bestandsaufnahme.

Erst inventarisieren, dann entscheiden

Bevor Anwendungen migriert werden, empfiehlt sich eine systematische Inventarisierung und Bewertung der bestehenden BW-Landschaft. Welche Berichte werden tatsächlich genutzt? Welche Datenmodelle sind redundant? Welche Add-ons oder Eigenentwicklungen werden künftig überhaupt noch unterstützt?

Zudem zeigt sich in dieser Phase bereits häufig eine Vielzahl unterschiedlicher Altlasten: nicht mehr genutzte Datenmodelle, Queries und Workbooks, überholte ABAP-Programme, redundante Kennzahlen und Datenstrukturen oder sehr alte Datenbestände. Hinzu kommen teilweise technische Objekte und Anwendungen, die von der Zielplattform nicht mehr oder nur noch eingeschränkt unterstützt werden. Erst wenn diese Transparenz geschaffen wurde, lassen sich fundierte Entscheidungen treffen.

Dabei geht es nicht ausschließlich um technische Objekte. Viel wichtiger ist die fachliche Bewertung jeder einzelnen Anwendung:

• Welche Berichte werden tatsächlich benötigt?
• Welche Kennzahlen besitzen heute noch fachliche Relevanz?
• Welche Anwendungen können entfallen?
• Wo lohnt sich ein vollständiger Neuaufbau?

Diese Bereinigung reduziert nicht nur den Migrationsaufwand, sondern schafft gleichzeitig eine deutlich übersichtlichere Analytics-Landschaft.

Architekturentscheidungen gehören an den Projektanfang

Eine weitere Erkenntnis aus Modernisierungsprojekten betrifft grundlegende Architektur-entscheidungen. Namenskonventionen, Schichtenmodelle oder Berechtigungskonzepte wirken auf den ersten Blick wie technische Detailfragen. Tatsächlich geht es jedoch um weit grundlegendere Fragen: Welche Systeme übernehmen künftig welche Aufgaben? Wo liegt die zentrale Semantik? Und wo wird Fachlogik implementiert?

Solche Entscheidungen bestimmen maßgeblich die langfristige Wartbarkeit und Konsistenz einer Analytics-Landschaft. Wer solche Entscheidungen erst während der Umsetzung trifft oder mehrfach verändert, verursacht häufig erhebliche Folgekosten. „Wenn man nach mehreren Jahren Projektlaufzeit feststellt, dass grundlegende Architekturentscheidungen falsch waren, wird jede Korrektur extrem aufwendig“, weiß Weintz. Ein belastbares Zielbild sollte deshalb bereits zu Projektbeginn definiert werden. Es dient während der gesamten Modernisierung als Orientierung und verhindert, dass kurzfristige Einzelentscheidungen später zu Inkonsistenzen führen.

Dabei muss nicht jede fachliche Logik zwangsläufig im Data Warehouse liegen. Operative Geschäftsregeln gehören grundsätzlich in die operativen Systeme, unternehmensweit relevante Semantik und harmonisierte Kennzahlen sollten möglichst zentral definiert werden, während berichtsspezifische Darstellungen in der jeweiligen Reporting-Schicht umgesetzt werden können. Entscheidend ist, für jede Logik bewusst festzulegen, wo sie fachlich und technisch am sinnvollsten aufgehoben ist.

Fachbereiche gestalten die Modernisierung aktiv mit

Ebenso entscheidend ist die Rolle der Fachbereiche. In vielen Projekten werden sie erst eingebunden, wenn neue Berichte getestet oder freigegeben werden. Aus Sicht des Experten greift dieser Ansatz in der Praxis deutlich zu kurz. Weintz: „Der Fachbereich ist kein Abnehmer der neuen Lösung. Er muss aktiver Gestalter des gesamten Modernisierungsprozesses sein.“

Schließlich entscheidet der Fachbereich über den fachlichen Nutzen einer Anwendung, priorisiert Anforderungen und bewertet, welche Inhalte künftig tatsächlich benötigt werden. Entsprechend sollten Vertreter der Fachbereiche bereits bei der Definition des fachlichen Zielbilds und der Priorisierung der Modernisierung eng eingebunden werden.

Klare Verantwortlichkeiten schaffen Vertrauen

Damit Entscheidungen nachvollziehbar bleiben, empfehlen sich eindeutige Verantwortlichkeiten für Anwendungen, Berichte und Kennzahlen. Für jede fachliche Anwendung sollte klar dokumentiert sein, wer verantwortlich ist und wer im Zweifelsfall Entscheidungen trifft.

Dieses Verantwortungsmodell erleichtert nicht nur die Modernisierung selbst, sondern verbessert langfristig auch den Betrieb der Analytics-Landschaft. Gerade im Zuge einer BW-Modernisierung bietet sich die Gelegenheit, solche Governance-Strukturen dauerhaft zu etablieren.
Roadmaps orientieren sich am Geschäft – nicht an technischen Objekten

Auch für die Planung der Migration ist fachliche Expertise nötig. Anstatt technische Objekte einzeln zu migrieren, sollten zusammengehörende Anwendungen gemeinsam betrachtet werden. Häufig bestehen fachliche Abhängigkeiten, die eine gemeinsame Umsetzung sinnvoll oder sogar notwendig machen. Priorisiert werden sollte dabei nach Kriterien wie fachlicher Nutzen, strategische Bedeutung, geplante Prozessänderungen, organisatorische Veränderungen im Unternehmen sowie Abhängigkeiten zu laufenden SAP-S/4HANA-Projekten.

Entscheidend für die Reihenfolge der Modernisierungswellen kann auch die Frage sein, welche Anwendungen kurzfristig benötigt werden oder ohnehin vor fachlichen Veränderungen stehen. Gerade die enge Verzahnung mit der ERP-Transformation spielt dabei eine wichtige Rolle: „Wenn parallel eine S/4HANA-Transformation stattfindet, sollte die BW-Modernisierung nicht losgelöst davon betrachtet werden. Fachliche Veränderungen in den Quellsystemen wirken sich unmittelbar auf die Analytics-Landschaft aus.“

Nicht jede Modernisierung verläuft gleich

Welcher Modernisierungspfad sinnvoll ist, hängt wesentlich von der zukünftigen Zielplattform und der Ausgangssituation des Unternehmens ab. Bei einer In-Place-Conversion nach BW/4HANA lassen sich viele Anpassungen schrittweise innerhalb der bestehenden Landschaft vorbereiten, sodass kein langfristiger Parallelbetrieb zweier BW-Systeme erforderlich ist.

Andere Conversion-Verfahren erfordern dagegen zumindest zeitweise einen Parallelbetrieb. Bei einer Weiterentwicklung in Richtung SAP Datasphere beziehungsweise Business Data Cloud handelt es sich aus Sicht von Weintz sogar um einen schrittweisen Neuaufbau der Analytics-Landschaft.

Bestehende Strukturen werden nicht einfach übernommen, sondern fachlich bewertet und neue Anforderungen direkt in der Zielarchitektur umgesetzt: „Bei Datasphere beziehungsweise Business Data Cloud muss man realistisch davon ausgehen, dass ein Parallelbetrieb über längere Zeit nicht vollständig vermeidbar ist. Je nach Größe und Komplexität der bestehenden Landschaft kann dieser Prozess Monate, teilweise auch Jahre dauern“, erläutert Weintz.

Daraus ergibt sich ein pragmatischer Ansatz: Neue Anforderungen und größere fachliche Änderungen sollten direkt auf der neuen Plattform umgesetzt werden. Bestehende Anwendungen werden anschließend schrittweise nach ihrer fachlichen Priorität überführt oder neu aufgebaut. Entscheidend ist dabei, den Parallelbetrieb als bewusst gesteuerte Übergangsphase zu verstehen – mit einem klar definierten Ziel und einem geplanten Ende.

Datenqualität bleibt der wichtigste Erfolgsfaktor

Unabhängig von der gewählten Zielarchitektur entscheidet letztlich die Qualität der Daten über die Akzeptanz der neuen Lösung. Bereits kleinere Abweichungen gegenüber dem Altsystem können zu einem erheblichen Vertrauensverlust führen – selbst wenn die neue Lösung fachlich korrekt ist. Fachliche Abnahmen, Kennzahlenvergleiche und umfangreiche Tests sind deshalb kein Projektschritt zum Abschluss, sondern begleiten die gesamte Modernisierung.

Datenabgleiche, die Validierung zentraler Kennzahlen und fachliche Tests sollten von Beginn an als eigenständige Projektaufgaben eingeplant werden. Dabei wird insbesondere der Aufwand für Testfälle, Testdaten und die Verfügbarkeit der Fachbereiche häufig unterschätzt. Auch fachliche Unterschiede zwischen Alt- und Neusystem müssen frühzeitig erkannt und bewertet werden. Denn nicht jede Abweichung ist automatisch ein Fehler: Entscheidend ist, ob die neue Lösung die fachlich gewünschte Definition und Logik korrekt abbildet. „Wenn die Daten nicht stimmen, ist alles andere bedeutungslos.“

Kosten und Ressourcen realistisch einplanen

Neben der technischen Umsetzung sollten Unternehmen auch die weniger sichtbaren Aufwände einer Modernisierung frühzeitig berücksichtigen. Bereits die Inventarisierung und fachliche Bewertung der bestehenden Landschaft kann erhebliche Ressourcen binden. Gleiches gilt für die Einbindung der Fachbereiche, Datenabgleiche, Tests und fachliche Abnahmen.

Bei einer BW/4HANA-Modernisierung können beispielsweise die Anpassung älterer BW-Objekte, kundeneigener Entwicklungen oder ABAP-Code sowie die Ablösung nicht mehr unterstützter Komponenten zusätzlichen Aufwand verursachen. Bei einem Neuaufbau in Richtung SAP Datasphere beziehungsweise Business Data Cloud kommen insbesondere die Entwicklung der Zielarchitektur, die fachliche Neukonzeption und die Neuverteilung von Fachlogik auf unterschiedliche Architekturschichten hinzu.

Diese Aufwände sind jedoch nicht nur als Kostenfaktoren zu betrachten. Gerade die Bereinigung von Altlasten, die Vereinheitlichung von Kennzahlen und die Neugestaltung der Architektur schaffen den eigentlichen Mehrwert einer Modernisierung. Entscheidend ist deshalb eine realistische Planung, die diese Aufgaben von Beginn an berücksichtigt und nicht als unerwartete Zusatzarbeiten behandelt.

Die Wahl zwischen SAP BW/4HANA und der Business Data Cloud ist wichtig – sie ist jedoch selten die eigentliche Schlüsselfrage einer BW-Modernisierung. Entscheidend ist vielmehr, ob Unternehmen die anstehende Transformation nutzen, um ihre Analytics-Landschaft fachlich zu bereinigen, Verantwortlichkeiten klar zu definieren und ein belastbares Zielbild zu entwickeln.

Eine gelungene Modernisierung zeigt sich letztlich daran, dass die Analytics-Landschaft einfacher, verständlicher und zukunftsfähiger geworden ist: Fachbereiche erhalten schneller die Informationen, die sie benötigen, neue Anforderungen lassen sich leichter umsetzen und redundante Strukturen werden konsequent reduziert. Erst dann entsteht eine moderne Datenplattform, die nicht nur technisch aktuell ist, sondern auch den zukünftigen Anforderungen des Unternehmens gerecht wird.

Julia Kowal, Fachjournalistin

Infocient