Stabilisierung eines FMCG-ERP-Projekts: einheitliches Reporting mit SAP Analytics Cloud

Diese Fallstudie richtet sich an CFOs und IT-Leiter, die mehr als ein ERP-System betreiben und keine einheitlichen Zahlen bekommen. Die Kurzfassung: Ein festgefahrenes grenzüberschreitendes Reportingprojekt zwischen Oracle in Singapur und SAP in Großbritannien wurde in sechs Monaten stabilisiert. Fünf Dinge haben das bewirkt. Ein kleinerer Lenkungsausschuss mit echter Entscheidungsbefugnis. Ein Umfang, der auf die Berichte beschnitten wurde, die Entscheidungen tragen. Abgestimmte Definitionen über beide Systeme. SAP Analytics Cloud als einheitliche Reportingschicht. Und lokale Champions statt Schulungsraum. Wenn Sie in derselben Lage sind, beginnen Sie mit Governance und Definitionen, nicht mit der Werkzeugdebatte.

Die Geschichte beginnt mit einem festgefahrenen ERP-Analytics-Projekt in einer bekannten FMCG-Gruppe mit Hauptsitz in Singapur. Die Gruppe hielt 26 % an einem britischen Energydrink-Unternehmen. Trotz der Minderheitsbeteiligung lag die Managementkontrolle in Singapur, sodass die Strategie aus den Vorstandsetagen in Asien das tägliche Reporting und die Planung in Europa prägte.

Die Technik machte es schwerer. Singapur betrieb Oracle ERP. Großbritannien betrieb SAP ERP. Beide arbeiteten für sich, und zusammen erzeugten sie ein Reportingproblem, das bereits Monate an Aufwand verschlungen hatte.

Die Zahlen passten selten zusammen. Abstimmungen zogen sich tagelang hin. Selbst die einfache Umsatzberichterstattung fiel unterschiedlich aus, je nachdem, welches System man abfragte.

Innerhalb von sechs Monaten nach Beginn des Stabilisierungseinsatzes wurde aus einer scheinbar gescheiterten Initiative ein grenzüberschreitendes Reportingmodell, dem Finanzen und Betrieb gleichermaßen vertrauten.

Vor der StabilisierungBeim Neustart

GovernanceVor der StabilisierungGroßer Lenkungsausschuss, Entscheidungen vertagtBeim NeustartNur echte Entscheider, Entscheidung in der Sitzung

UmfangVor der StabilisierungEin Whiteboard voller AnforderungenBeim NeustartBerichte, die Entscheidungen tragen

DefinitionenVor der StabilisierungGleiche Bezeichnung, andere Bedeutung im jeweiligen ERPBeim NeustartAbgestimmte Definitionen für Umsatz, Kosten und Marge

ReportingVor der StabilisierungAbstimmung in Excel, die Tage dauerteBeim NeustartOracle- und SAP-Daten in einem Modell in SAP Analytics Cloud

AkzeptanzVor der StabilisierungSchulungsraum, danach zurück zu ExcelBeim NeustartLokale Champions, ein Team nach dem anderen

Die Tabelle fasst die Ausgangslage zusammen und zeigt, wie jedes Problem gelöst wurde.

Herausforderung	Auswirkung	Lösung mit SAP Analytics Cloud
Zwei ERP-Systeme: Oracle in Singapur, SAP in Großbritannien	Zahlen stimmten nicht überein; die Abstimmung dauerte Tage	Beide speisten ein gemeinsames Reportingmodell
Unklare Verantwortung für das Reporting über Grenzen hinweg	Die Strategie in Asien stieß auf operative Daten in Europa	Standard-KPIs sorgten dafür, dass beide Gesellschaften dieselben Kennzahlen meldeten
Langsame Umsatzberichterstattung	Zahlen wichen je nach Quellsystem ab und verzögerten Entscheidungen	Einheitliche Planung und Berichterstattung verkürzten den Zyklus
Planung nicht abgestimmt	Singapur legte die Strategie fest; Großbritannien setzte sie mit anderen Annahmen um	Gemeinsame Planungsmodelle brachten beide Geschäfte auf eine Linie

Reporting über zwei ERP-Systeme

Mit Oracle in Singapur und SAP in Großbritannien fühlte sich das Reporting an, als führe man zwei getrennte Unternehmen. Das Finanzteam zog dieselbe Kennzahl aus beiden Systemen und bekam unterschiedliche Antworten. In einem Monatsreview präsentierte Singapur eine Umsatzzahl, und Großbritannien widersprach sofort mit einer anderen. Der Streit dauerte länger als das Review.

Die Leute fielen auf Excel zurück, weil es sich sicherer anfühlte: stundenlang exportieren, abstimmen und die eigene Version der Wahrheit bauen. Kurzfristig funktionierte das und erzeugte chronische Verzögerungen im Konzernreporting. Mein Artikel darüber, warum CFOs immer noch zu Excel greifen, behandelt dieses Muster allgemeiner.

Konsolidierung zum Monatsende

Der Monatsabschluss war der schwierigste Teil. Eine Position, die in einem ERP unter „Betrieb“ lag, landete im anderen manchmal unter „Verwaltung“. Ich habe einmal einen Konsolidierungsentwurf gesehen, in dem dieselbe Ausgabe unter verschiedenen Überschriften doppelt auftauchte. Das zerstörte das Vertrauen in die Zahlen. Verspätete Ergebnisse wurden zur Regel, und wenn die Gruppe veröffentlichte, folgten meist Korrekturen.

Operatives Reporting

Die Probleme gingen über das Finanzwesen hinaus. Oracle verfolgte Lieferungen, SAP verfolgte Bestände, und es gab keine einheitliche Quelle. Ein Lagerleiter erzählte mir, er habe in einer Woche drei verschiedene Bestandsberichte bekommen, alle mit unterschiedlichen Beständen. Er lachte, als er es sagte, aber es bremste echte Entscheidungen. Die Nachschubplanung hinkte hinterher, und Lieferverzögerungen ließen sich schwerer erklären, weil der Betrieb den Dashboards nicht traute.

Die Werkzeugdebatte

Die Wahl eines Reportingwerkzeugs wurde selbst zum Projekt. Manche Manager mochten das Kostenprofil von Power BI; andere drängten auf SAP wegen der längeren Roadmap. Ich saß in einem Workshop, in dem die Hälfte der Zeit auf „Warum SAC und nicht Power BI“ entfiel statt auf die Reportinganforderungen. Die Debatte dauerte Monate und kostete Schwung.

Widerstand der Anwender

Selbst nachdem die ersten Dashboards live waren, blieb die Nutzung gering. Ich erinnere mich, wie jemand in einer Finanzbesprechung ein Dashboard öffnete, kurz hinschaute, es schloss und zu seiner Excel-Tabelle zurückkehrte. Niemand stellte das infrage. Die Leute vertrauten dem, was sie kannten, und die Dashboards hatten sich dieses Vertrauen noch nicht verdient.

Governance neu aufsetzen. Die Meetings fühlten sich endlos an, und die Beteiligten gingen auseinander, ohne zu wissen, wer entschieden hatte. Die Führung verkleinerte den Lenkungsausschuss auf die echten Entscheider. Die Sitzungen wurden kürzer und entschlossener, und Eskalationen erreichten schnell die richtigen Leute. Perfekt war es nicht, aber es kam Bewegung in die Sache. Mein Leitfaden zum Führen eines SAP-Lenkungsausschusses legt dieselben Prinzipien dar.

Den Umfang in den Griff bekommen. Die Beteiligten stritten ständig darüber, welche Zahlen in die Konzernsicht gehörten, und die Anforderungsliste war unbeherrschbar geworden. Ich erinnere mich an ein Whiteboard in einem Workshop, das von einem Ende zum anderen mit Wünschen bedeckt war, die Hälfte davon ohne Bezug zu irgendeiner echten Entscheidung. Der Rahmen, der funktionierte: Das Reporting muss nur abdecken, was Entscheidungen treibt. Sobald das vereinbart war, nahm die Lieferung Fahrt auf.

Kommunikation, die relevant wirkte. Frühere Updates waren allgemein gehalten, sodass Finanzen, Betrieb und IT jeweils eine andere Deutung mitnahmen. Wir stellten auf zugeschnittene Updates um: Reporting-Zeitpläne für das Finanzwesen, Änderungen an den Logistikprozessen für den Betrieb, eine technische Roadmap für die IT. Die Leute stellten bessere Fragen, weil die Updates ihre Sprache sprachen.

Lokale Champions. Schulungen allein hatten nicht gewirkt: Die Leute saßen die Sitzungen ab und gingen am nächsten Morgen zu Excel zurück. Die Wende kam durch lokale Champions, Kollegen, die in ihren Teams bereits Ansehen hatten und die Dashboards informell in eigenen Worten erklärten. Ich saß in einer dieser Sitzungen, und der Unterschied war auffallend. Die Leute stellten Fragen, die sie in einer Schulung nie gestellt hätten. Die Akzeptanz verbesserte sich Team für Team.

Die Tabelle fasst zusammen, was sich änderte und warum es wirkte.

Schwerpunkt	Was sich änderte	Wirkung
Governance neu aufgesetzt	Lenkungsausschuss auf die echten Entscheider verkleinert; kürzere, schärfere Sitzungen	Entscheidungen fielen in der Sitzung; Eskalationen liefen schnell
Kontrolle des Umfangs	Anforderungen auf Reporting gekürzt, das Entscheidungen treibt	Weniger Debatte, klarere Datenmodelle, weniger bewegliche Ziele
Zugeschnittene Kommunikation	Getrennte Updates für Finanzen, Betrieb und IT	Jedes Team verstand, was für es zählte; das Vertrauen kehrte zurück
Lokale Champions	Coaching unter Kollegen in kleinen Gruppen statt formaler Schulungen	Die Akzeptanz stieg Team für Team; die Abhängigkeit von Excel sank

Als die Werkzeugauswahl schließlich abgeschlossen war, gewann SAC, unter anderem weil es Oracle- und SAP-Daten ohne aufwendige Eigenentwicklung in ein Modell bringen konnte. Das nahm der Diskussion etwas Hitze. Berichte spiegelten Änderungen weit schneller wider als der alte Exportzyklus. Eine Controllerin aus dem Finanzbereich sagte, es sei das erste Mal gewesen, dass sie nicht auf eine nächtliche Datenaktualisierung warten musste, um ihren Tag zu beginnen.

Als der Finanzmanager zum ersten Mal Oracle-Daten und SAP-Daten nebeneinander in einem Dashboard sah, fiel ihm eine Last von den Schultern. Dieser Moment beendete die Debatte.

SAC deckte auch mehr als das Finanzwesen ab. Der Betrieb wollte eine Sicht auf Logistik und Lagerhaltung, das Personalwesen wollte Personalplanung. Planung, Reporting und Visualisierung auf einer Plattform zu haben, machte den Unterschied zwischen einer taktischen Notlösung und einem langfristigen Fundament. Die vorgefertigten Vorlagen verschafften dem Team einen Vorsprung, auch wenn sich manche generisch anfühlten, und das Tempo der ersten Lieferung stellte das Vertrauen nach Monaten der Verzögerung wieder her.

Ein technischer Hinweis, falls Sie dieses Design nachbauen. Live-Datenverbindungen in SAC sind auf SAP-Quellen beschränkt, etwa SAP HANA, BW, S/4HANA, BPC embedded, BusinessObjects-Universen und SAP Datasphere. Daten außerhalb von SAP, etwa aus einem Oracle ERP, kommen meist über eine Importverbindung, ein Universum oder eine zwischengeschaltete Datenschicht herein. Entscheiden Sie diese Architektur früh, denn sie bestimmt, wie aktuell die Zahlen jeder Seite sein können.

Der erste Meilenstein war das Datenmodell. Oracle und SAP mussten beide in eine Struktur einspeisen, was schwerer war, als es aussah. Felder trugen dieselbe Bezeichnung, bedeuteten aber in jedem System etwas anderes. Es dauerte Wochen, Definitionen abzugleichen, bis sich das Finanzwesen einig war, was Umsatz, Kosten und Marge tatsächlich bedeuteten.

Die Dashboards wurden schrittweise ausgerollt. Zuerst kam das Finanzwesen, dann Vertrieb und Betrieb, jeweils mit Berichten, die um ihre tatsächliche Arbeit herum gebaut waren. Die ersten Versionen wirkten zu starr. Die Anwender sagten das, und sie hatten recht. Die Dashboards wurden besser, und vereinbarte KPIs ersetzten die ständigen monatlichen Auseinandersetzungen.

Der Neustart war innerhalb von sechs Monaten abgeschlossen. Zum ersten Mal lagen Oracle- und SAP-Daten in einem Modell in SAC. Die Abstimmungsstreitigkeiten gingen zurück, und die Führungskräfte prüften Zahlen, ohne auf kursierende Excel-Dateien zu warten.

Planungszyklen, die Wochen gedauert hatten, dauerten Tage. Planer konnten Szenarien modellieren und mit den Ist-Werten vergleichen. Manche Manager wollten mehr Detail, als die Dashboards boten, aber dass sie den Zahlen vertrauten, war schon bedeutsam.

Ein Lagerleiter erwähnte, dass die Bestände in seinem Bericht zum ersten Mal mit dem übereinstimmten, was das Finanzwesen zeigte. Diese leise Übereinstimmung zwischen den Abteilungen war der eigentliche Indikator. Niemand verlangte, zum alten Prozess zurückzukehren.

Die Tabelle listet die Fehler auf, die das Projekt ausgebremst haben, und die Erkenntnis aus jedem.

Fehler	Folge	Erkenntnis
Unklare Governance	Endlose Meetings, keine Entscheidungen, wachsende Verzögerungen	Rollen und Entscheidungsrechte früh neu festlegen
Schleichende Ausweitung des Umfangs	Die Reportingziele verschoben sich ständig	Den Umfang eng halten und an Entscheidungen koppeln
Anwender übergangen	Die Anwender verloren Vertrauen, die Akzeptanz stockte	Anwender früh einbeziehen und ihnen Kontext geben
Übermäßige Anpassung	Zeit ging für den Neubau von Berichten drauf	Mit Vorlagen und Standard-Konnektoren starten; später anpassen
Schwaches Change Management	Schulungen verfehlten das Ziel; alte Gewohnheiten blieben	Lokale Champions und Coaching unter Kollegen früh einbinden

Drei Erkenntnisse stechen heraus. Governance zählt mehr als das Werkzeug: Ohne klare Verantwortung in einem Umfeld mit mehreren ERP-Systemen fällt das Reporting auseinander, gleich auf welcher Plattform. Datendefinitionen vor der Werkzeugauswahl abstimmen: Die Debatte Power BI gegen SAC ging am Punkt vorbei, denn kein Werkzeug repariert Definitionen, die nicht zusammenpassen. Und Change Management entscheidet über die Akzeptanz: Ohne Champions und zielgerichtete Kommunikation wären die Dashboards ungenutzt geblieben.

Drei Dinge würden sich ändern, wenn dieselbe Arbeit heute begänne.

Zwischen SAC und den Quellen läge eine Datenschicht. SAP Datasphere, inzwischen Teil von SAP Business Data Cloud, bietet föderierten Zugriff auf SAP- und Nicht-SAP-Quellen mit einem semantischen Modell obendrauf. Für einen Fall mit zwei ERP-Systemen wie diesen ist es sauberer, Oracle- und SAP-Daten in dieser Schicht zu harmonisieren, als in jeder einzelnen SAC-Story. Es gibt SAC außerdem eine Live-Verbindung zum harmonisierten Modell.

Fragen in natürlicher Sprache würden manche Dashboard-Entwicklung ersetzen. Mit der Abfrage in natürlicher Sprache in SAC und mit Joule kann das Finanzwesen etwa nach dem Umsatz je Region im Quartal fragen, Singapur gegen Großbritannien. Zuvor muss keine Story gebaut werden. Das beschleunigt die Arbeit, sobald die Daten harmonisiert sind. Eine Definitionslücke schließt es nicht.

Das kommerzielle Gespräch würde beim ERP-Vertrag beginnen. Prüfen Sie, welche Analytics-Funktionen Ihr Cloud-ERP-Vertrag bereits enthält, bevor Sie über SAC verhandeln. Die volle SAC-Planung wird separat lizenziert, und hybride Landschaften, in denen eine Gesellschaft Cloud-ERP nutzt und eine andere nicht, brauchen weiterhin eine sorgfältige Lizenzierung.

Der Governance-Neustart, die Disziplin beim Umfang, die lokalen Champions und die zugeschnittene Kommunikation würden sich nicht ändern. Diese Muster gelten unabhängig von der Technik. Die menschliche Arbeit, zwei ERP-Systeme dazu zu bringen, dieselben Zahlen zu melden, wird nicht automatisiert. Mehr zu SAC selbst finden Sie in meinem Leitfaden zu SAP Analytics Cloud.

Warum geriet das ERP-Reportingprojekt dieser FMCG-Gruppe ins Stocken?

Singapur betrieb Oracle und Großbritannien SAP, und jeden Monat setzte das Finanzteam die Zahlen von Hand zusammen. Das dauerte Tage, und niemand traute dem Ergebnis vollständig. Reviews gerieten ins Stocken, wenn Singapur eine Zahl präsentierte und Großbritannien mit einer anderen widersprach. Der Lenkungsausschuss war außerdem zu groß, sodass niemand Entscheidungen traf. Die Kosten stiegen, das Vertrauen schwand, und das Projekt trieb dahin.

Was änderte den Kurs der Stabilisierung?

Die Führung räumte ein, dass das Projekt feststeckte, und einigte sich auf einen Stabilisierungsplan. Der Lenkungsausschuss wurde auf eine kleine Gruppe echter Entscheider verkleinert, Prioritäten wurden gesetzt, SAP Analytics Cloud wurde als einheitliches Reportingwerkzeug gewählt, und die Kommunikation wurde zielgruppengerecht. Die Meetings wandten sich von Schuldzuweisungen dem zu, was als Nächstes kam, und die Leute begannen zu glauben, dass das Projekt liefern konnte.

Wie ging SAP Analytics Cloud mit Oracle und SAP gleichzeitig um?

SAC brachte Oracle- und SAP-Daten in ein Reportingmodell, sodass beide ohne manuelle Abstimmungsdateien nebeneinander in einem Dashboard erschienen. Beide Systeme in einer Sicht zu sehen, war der Moment, der die Werkzeugdebatte beendete. Beachten Sie, dass die Live-Verbindungen von SAC nur SAP-Quellen unterstützen; Oracle-Daten kommen typischerweise über eine Importverbindung, ein BusinessObjects-Universum oder eine Datenschicht wie SAP Datasphere.

Warum widersetzten sich die Anwender den Dashboards zunächst?

Die Dashboards starteten ohne ausreichenden geschäftlichen Kontext. Den Anwendern wurde gesagt, sie sollten SAC nutzen, aber niemand zeigte, wie es sich auf ihre tägliche Arbeit bezog, und die Schulung war allgemein gehalten. Die Leute vertrauen dem, was sie kennen, und die Dashboards hatten sich dieses Vertrauen noch nicht verdient. Lokale Champions, die die Dashboards in eigenen Worten erklärten, änderten das.

Wie sieht eine erfolgreiche Stabilisierung des ERP-Reportings aus?

Es ist selten ein einzelner Faktor. Hier waren es ein Governance-Neustart, Umfangsreduzierung, abgestimmte Definitionen, zugeschnittene Kommunikation und Champions aus den eigenen Reihen, die zusammenwirkten. SAC half, weil es beide ERP-Systeme ohne aufwendige Eigenentwicklung in ein Modell brachte, aber Technik allein hätte das Projekt nicht gerettet. Nach sechs Monaten präsentierten Leute, die darauf gewartet hatten, dass es zusammenbricht, Dashboards, die sie selbst gebaut hatten.