Contents
- What the setup looked like
- What was going wrong
- Reporting across two ERPs
- Month-end consolidation
- Operational reporting
- The tool debate
- User resistance
- The intervention: governance, scope and change management
- Why SAP Analytics Cloud won the debate
- Implementation highlights
- Business outcomes at six months
- Lessons learned
- How this engagement would look in 2026
- Frequently asked questions
This case study is for CFOs and IT leaders running more than one ERP who cannot get a single set of numbers. The short version: a stalled cross-border reporting project between Oracle in Singapore and SAP in the UK was recovered in six months. Five things did it. A smaller steering group with real authority. Scope cut to the reports that drive decisions. Agreed definitions across both systems. SAP Analytics Cloud as the one reporting layer. And local champions instead of classroom training. If you are in the same position, start with governance and definitions, not the tool debate.
The story begins with a stalled ERP analytics project in a well-known FMCG group headquartered in Singapore. The group held a 26% stake in a UK energy drinks business. Despite the minority share, management control sat in Singapore, so boardroom strategy in Asia shaped daily reporting and planning in Europe.
The technology made it harder. Singapore ran Oracle ERP. The UK ran SAP ERP. Each worked on its own, and together they created a reporting problem that had already consumed months of effort.
Numbers rarely matched. Reconciliations dragged on for days. Even basic revenue reporting came out differently depending on which system you checked.
Within six months of the recovery engagement, what looked like a failed initiative became a cross-border reporting model that finance and operations both trusted.
The table summarises the starting position and how each problem was resolved.
| Challenge | Impact | Resolution with SAP Analytics Cloud |
|---|---|---|
| Two ERPs: Oracle in Singapore, SAP in the UK | Numbers did not align; reconciliation took days | Both fed into one reporting model |
| Unclear reporting ownership across borders | Strategy in Asia clashed with operational data in Europe | Standard KPIs meant both entities reported the same metrics |
| Slow revenue reporting | Figures differed by source system, delaying decisions | Unified planning and reporting shortened the cycle |
| Planning misalignment | Singapore set strategy; the UK executed on different assumptions | Shared planning models aligned both businesses |
Reporting across two ERPs
With Oracle in Singapore and SAP in the UK, reporting felt like running two separate businesses. Finance pulled the same metric from each system and got different answers. In one monthly review, Singapore presented a revenue figure and the UK challenged it immediately with another. The argument ran longer than the review.
People fell back on Excel because it felt safer: hours of exporting, reconciling and building their own version of the truth. It worked short term and created chronic delays in group reporting. My article on why CFOs still reach for Excel covers that pattern more widely.
Month-end consolidation
Month-end was the hardest part. A cost sitting under "operations" in one ERP sometimes ended up under "admin" in the other. I once saw a consolidation draft where the same expense appeared twice under different headings. That killed trust in the numbers. Late results became the norm, and when the group did publish, revisions usually followed.
Operational reporting
The problems went beyond finance. Oracle tracked shipments, SAP tracked stock, and there was no single source. A warehouse manager told me he had received three different stock reports in one week, all with different balances. He laughed when he said it, but it was slowing real decisions. Replenishment lagged, and shipping delays were harder to explain because operations did not trust the dashboards.
The tool debate
Choosing a reporting tool became a project in itself. Some managers liked Power BI's cost profile; others pushed for SAP because of its longer roadmap. I sat through a workshop where half the time went on "why SAC and not Power BI" instead of reporting needs. The debate lasted months and drained momentum.
User resistance
Even after the first dashboards went live, adoption stayed low. I remember watching someone in a finance meeting open a dashboard, glance at it, close it and go back to their Excel sheet. Nobody questioned it. People trusted what they knew, and the dashboards had not yet earned that trust.
Resetting governance. Meetings felt endless and people left unsure who had made the call. Leadership cut the steering group down to the real decision-makers. Sessions became shorter and more decisive, and escalations reached the right people quickly. It was not perfect, but things started moving. My guide to running an SAP steering committee sets out the same principles.
Getting scope under control. People argued constantly about which numbers belonged in the group view, and the requirement list had become unmanageable. I remember a workshop whiteboard covered end to end with requests, half of them unrelated to any real decision. The framing that worked: reporting only needs to cover what drives decisions. Once that was agreed, delivery picked up.
Communication that felt relevant. Earlier updates were generic, so finance, operations and IT each took away a different interpretation. We switched to tailored updates: reporting timelines for finance, logistics process changes for operations, a technical roadmap for IT. People started asking better questions because the updates spoke their language.
Local champions. Training alone had not worked: people sat through sessions and went back to Excel the next morning. The change came from local champions, colleagues who already had credibility in their teams, explaining dashboards informally in their own words. I sat in on one of those sessions and the difference was striking. People asked questions they never would have asked in a class. Adoption improved one team at a time.
The table summarises what changed and why it worked.
| Focus area | What changed | Impact |
|---|---|---|
| Governance reset | Cut the steering group to real decision-makers; shorter, sharper sessions | Decisions made in the meeting; escalations moved quickly |
| Scope control | Trimmed requirements to reporting that drives decisions | Less debate, clearer data models, fewer moving targets |
| Tailored communication | Separate updates for finance, operations and IT | Each team understood what mattered to it; trust returned |
| Local champions | Peer coaching in small groups instead of formal classes | Adoption improved team by team; Excel reliance fell |
When the tool selection finally concluded, SAC won, partly because it could bring Oracle and SAP data into one model without heavy custom work. That took some heat out of the discussion. Reports reflected changes far faster than the old export cycle. One financial controller said it was the first time she had not needed to wait for an overnight data refresh to start her day.
The first time the finance manager saw Oracle data and SAP data side by side in one dashboard, a weight lifted. That moment closed the debate.
SAC also covered more than finance. Operations wanted a view of logistics and warehousing, and HR wanted workforce planning. Having planning, reporting and visualisation in one platform made the difference between a tactical fix and a longer-term foundation. The prebuilt templates gave the team a head start, even if some felt generic, and the speed of that first delivery restored confidence after months of delay.
One technical point if you plan to copy this design. SAC live data connections are limited to SAP sources such as SAP HANA, BW, S/4HANA, BPC embedded, BusinessObjects universes and SAP Datasphere. Non-SAP data such as an Oracle ERP usually comes in through an import connection, a universe or a data layer in between. Decide that architecture early, because it sets how fresh each side's numbers can be.
The first time the finance manager saw Oracle data and SAP data side by side in one dashboard, a weight lifted. That moment was the proof point the whole project had been waiting for.
The first milestone was the data model. Oracle and SAP both had to feed one structure, which was harder than it looked. Fields carried the same label but meant different things in each system. It took weeks of mapping definitions before finance agreed what revenue, cost and margin actually meant.
Dashboards rolled out in steps. Finance came first, then sales and operations, each with reports built around their actual work. Early versions felt too rigid. Users said so, and they were right. The dashboards improved, and agreed KPIs replaced what had been constant monthly arguments.
The relaunch completed within six months. For the first time, Oracle and SAP data sat in one model inside SAC. Reconciliation arguments dropped, and executives reviewed numbers without waiting for Excel files to circulate.
Planning cycles that had taken weeks took days. Planners could model scenarios and compare them with actuals. Some managers wanted more detail than the dashboards gave, but the fact that they trusted the numbers was already significant.
A warehouse manager mentioned that, for the first time, the stock levels in his report matched what finance was showing. That quiet alignment across departments was the real indicator. Nobody asked to go back to the old process.
The table lists the mistakes that stalled the project and the lesson from each.
| Mistake | What it caused | Lesson |
|---|---|---|
| Unclear governance | Endless meetings, no decisions, mounting delays | Reset roles and decision rights early |
| Scope drift | Reporting goals kept shifting | Keep scope tight and tied to decisions |
| Ignoring users | Users lost confidence and adoption slowed | Involve users early and give them context |
| Over-customisation | Time wasted rebuilding reports | Start with templates and standard connectors; customise later |
| Weak change management | Training missed the mark; old habits stuck | Bring in local champions and peer coaching early |
Three lessons stand above the rest. Governance matters more than the tool: without clear ownership in a multi-ERP setup, reporting falls apart whatever the platform. Align data definitions before tool selection: the Power BI versus SAC debate missed the point, because no tool fixes definitions that do not match. And change management decides adoption: without champions and targeted communication, the dashboards would have stayed unused.
Three things would change if the same work started now.
A data layer would sit between SAC and the sources. SAP Datasphere, now part of SAP Business Data Cloud, gives federated access to SAP and non-SAP sources with a semantic model on top. For a two-ERP case like this, harmonising Oracle and SAP data in that layer is cleaner than doing it inside each SAC story. It also gives SAC a live connection to the harmonised model.
Natural-language questions would replace some dashboard builds. SAC's natural-language query and Joule let finance ask for, say, revenue by region for the quarter, Singapore against the UK. No story has to be built first. That speeds up work once the data is harmonised. It does not close a definition gap.
The commercial conversation would start from the ERP contract. Check what analytics your cloud ERP contract already includes before negotiating SAC. Full SAC planning is licensed separately, and hybrid estates with one entity on cloud ERP and another not still need careful licensing.
The governance reset, scope discipline, local champions and tailored communication would not change. Those patterns hold whatever the technology. The human work of getting two ERPs to report the same numbers does not get automated. For more on SAC itself, see my SAP Analytics Cloud guide.
Why did this FMCG group's ERP reporting project stall?
Singapore ran Oracle and the UK ran SAP, and every month finance stitched the numbers together by hand. It took days and nobody fully trusted the result. Reviews stalled when Singapore presented one figure and the UK challenged it with another. The steering group was also too large, so nobody made decisions. Costs rose, confidence slipped and the project drifted.
What changed the direction of the recovery?
Leadership admitted the project was stuck and agreed a recovery plan. The steering group was cut to a small group of real decision-makers, priorities were set, SAP Analytics Cloud was chosen as the single reporting tool, and communication became audience-specific. Meetings moved from blame to what came next, and people started to believe the project could deliver.
How did SAP Analytics Cloud handle both Oracle and SAP?
SAC brought Oracle and SAP data into one reporting model, so both appeared side by side in a single dashboard without manual reconciliation files. Seeing both systems in one view was the moment that ended the tool debate. Note that SAC's live connections only support SAP sources; Oracle data typically arrives through an import connection, a BusinessObjects universe or a data layer such as SAP Datasphere.
Why did users resist the dashboards at first?
The dashboards launched without enough business context. Users were told to use SAC, but nobody showed how it applied to their daily work, and training was generic. People trust what they know, and the dashboards had not earned that trust yet. Local champions, explaining the dashboards in their own words, changed that.
What does a successful ERP reporting recovery look like?
It is rarely one thing. Here it was a governance reset, scope reduction, agreed definitions, tailored communication and peer champions working together. SAC helped because it brought both ERPs into one model without heavy custom work, but technology alone would not have saved the project. Six months in, people who had been waiting for it to collapse were presenting dashboards they had built themselves.
Written by
