case studies
ERP Recovery: FMCG Group Adopts SAP Analytics Cloud for Unified Reporting
Noel DCosta
- Last Update :
This story begins with a stalled ERP project in a well-known FMCG group based in Singapore. The company had control over a UK counterpart, which complicated things further, because Singapore ran Oracle and the UK ran SAP. They wanted one consistent analytics reporting solution across both. That part sounded simple on paper, but it was far from it. Costs kept rising, deadlines kept slipping, and users started to lose confidence. This is the story of SAP Analytics Cloud for Unified Reporting.
When we looked closely, governance had broken down, and reporting goals were unclear. This combination left the project drifting. The turnaround came when leadership agreed to a recovery plan and introduced SAP Analytics Cloud.
-
The platform supported cross border ERP recovery.
-
It allowed reporting and planning from Oracle and SAP in one place.
-
Teams could finally share consistent numbers.
Within six months, what looked like failure became an ERP reporting turnaround and, perhaps more importantly, a practical SAP Analytics Cloud success story.
The recovery showed that SAP Analytics Cloud could bridge Oracle and SAP, creating one reporting model that finance and operations both trusted. What began as a failing FMCG ERP project in Singapore turned into a clear SAP Analytics Cloud success story, with unified planning and cross-border reporting delivered in just six months.
Background: Complex ERP Landscape Across Borders
The group has its headquarters in Singapore, managing thousands of employees across regions. It also owned a 26% stake in a UK energy drinks business. Despite the minority share, management control rested in Singapore.
This meant boardroom strategies in Asia shaped daily reporting and planning in Europe, sometimes effectively and sometimes less so.
The technology setup made the situation harder. Singapore relied on Oracle ERP, while the UK business used SAP ERP. Each platform worked well on its own. Together, they created problems that many underestimate. Numbers rarely matched. Reconciliations dragged on for days.
Even something as basic as revenue reporting came out differently depending on which system you checked. I have seen this before, and it is what people mean when they talk about ERP system integration.
The group knew it had to act. They wanted a single platform that could connect both worlds, remove duplication, and support unified planning.
That ambition naturally led them to explore SAP Analytics Cloud. Unlike tactical fixes, SAC gave them the chance to tie reporting and planning into one framework across subsidiaries.
Some of the objectives were straightforward, at least on paper:
Deliver cross ERP analytics that combined Oracle and SAP data
Provide transparent reporting across Singapore and the UK
Address common FMCG ERP challenges such as speed of reporting and data consistency
Build a foundation for financial planning across global subsidiaries
It sounded achievable. Yet, as I noticed during initial conversations, agreement on ambition does not always translate into agreement on approach.
Case Study: ERP Integration Challenges in FMCG Group
| Challenge | Impact | Resolution with SAC |
|---|---|---|
| Dual ERP systems (Oracle in Singapore, SAP in UK) | Numbers did not align, and reconciliations consumed days of effort. | Used SAP Analytics Cloud live connections to bring Oracle and SAP data into one reporting layer. |
| Unclear reporting ownership across borders | Boardroom strategy in Asia clashed with daily execution in Europe, leading to confusion and delays. | Standardized KPIs in SAC dashboards ensured both entities reported on the same metrics. |
| Slow revenue reporting cycles | Basic figures such as revenue differed depending on the source system, delaying executive decisions. | Unified planning and reporting in SAC cut cycle times and gave leadership one source of truth. |
| Cross-border planning misalignment | Singapore controlled strategy, but Europe executed operations with different assumptions and timelines. | End-to-end planning in SAC allowed shared models and scenarios across both subsidiaries. |
The Project Breakdown: What Went Wrong
1. Reporting across two ERPs
With Oracle in Singapore and SAP in the UK, reporting felt like running two separate businesses. Numbers did not line up. Finance teams often pulled the same metric from each system and ended up with two different answers. For revenue alone, I remember one meeting where Singapore presented a number and the UK challenged it on the spot with a different figure. The argument went on longer than the review itself.
People fell back on Excel because it felt safer. They spent hours exporting, reconciling, and building their own “truth.” That worked in the short term but created long delays in group reporting.
Finance teams needed days to produce consolidated results
Key figures like revenue and cost were defined differently
Reconciliation in Excel became a permanent crutch
For situations like this, SAP Analytics Cloud provides a single model that connects across ERP systems and removes the duplication. You can also see how this links into the ECC to S/4HANA migration journey, which is often happening in parallel.
2. Consolidation challenges
Month-end was the toughest. Singapore held management control, but the UK had its own structure under SAP. Mapping accounts and categories was messy. 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 was reported twice under two different headings. That killed trust in the numbers.
Publishing results late became the norm. And when the group finally did publish, revisions often followed because errors slipped through.
Group reports did not always show a single version of truth
Chart of accounts mapping lacked consistency
Consolidated numbers were sometimes reissued
This is why companies move toward SAP consolidation capabilities. A strong SAP business case usually highlights how a single framework can align reporting across business units and improve trust in results.
3. Operational reporting gaps
It was not just finance. Logistics and warehouse reporting was just as broken. Oracle tracked shipments, SAP tracked stock, and there was no single source of data. A warehouse manager told me once that he received three different stock reports in one week, all with different balances. He laughed when he said it, but you could tell it was slowing down real work.
Replenishment decisions dragged. Shipping delays were harder to explain because operations did not trust the dashboards. They wanted one report they could all stand behind, but the systems just were not talking to each other.
Inventory reports conflicted between Oracle and SAP
Shipments and stock levels needed manual reconciliation
Supply chain planning slowed due to unclear data
Using the same platform for supply chain management and reporting is often the only way to resolve these inconsistencies. For example, SAP Enterprise Warehouse Management (EWM) is designed to handle exactly this kind of integration gap.
4. Concerns with tool selection
Choosing a reporting tool became a project of its own. Finance questioned whether Excel could just continue to be the consolidation tool. IT warned that integration with both ERPs would be complicated. Operations said they did not care about platforms, only that the reports made sense.
Power BI was floated as an alternative. Some managers liked its cost profile. Others pushed for SAP because of the longer roadmap. I sat through a workshop where half the time was spent debating “why SAC and not Power BI” rather than discussing reporting needs. That debate went on for months. It drained momentum.
Finance doubted a new tool would reduce workload
IT worried about the integration effort
Power BI was suggested as a lower-cost option
Prolonged debates delayed SAP Analytics Cloud approval
For teams in that debate today, here is a practical breakdown of SAP Analytics Cloud vs Power BI. It helps frame the choice in real terms rather than in endless meetings.
5. User resistance
Even after the dashboards went live, adoption stayed low. Users did not see the benefit. They were told to “use SAC,” but nobody explained how it would help their day-to-day work. Training was provided, but without purpose behind it, it washed over people.
I remember watching someone open a dashboard in a finance meeting, glance at the numbers, then close it and go back to their Excel sheet. Nobody even questioned it. That quiet resistance was real. People trusted what they knew.
Users leaned on ERP reports rather than new dashboards
Excel stayed the fallback for daily decisions
Training did not connect to real business needs
Reports lacked context and felt unfinished
These adoption challenges come up again and again. A structured SAP implementation approach includes change management, which makes a real difference in helping users move away from old habits.
Reporting Across Two ERPs
| Challenge | Impact |
|---|---|
| Oracle in Singapore and SAP in the UK produced conflicting results | Revenue and cost figures differed, meetings drifted into debates, and decisions slowed. |
| Excel became the fallback for cross-entity reporting | Long export and reconciliation cycles delayed group reporting by days. |
| Key metrics were defined differently across systems | Leaders lost confidence due to no single version of truth. |
| Permanent reliance on reconciliation activities | Analysts spent time fixing numbers instead of explaining results. |
Consolidation Challenges
| Challenge | Impact |
|---|---|
| Different account structures and ownership rules across entities | Late month-end close and frequent post-publication revisions. |
| Inconsistent mapping of “operations” versus “admin” costs | Double counting and misclassification reduced trust in results. |
| Manual consolidation steps across regions and currencies | Close cycles stretched, auditors raised queries, and leadership waited. |
Operational Reporting Gaps
| Challenge | Impact |
|---|---|
| Shipments tracked in Oracle, stock in SAP, no single view | Conflicting inventory balances and unclear supply positions. |
| Warehouse KPIs misaligned with finance KPIs | Replenishment lagged, bottlenecks went unnoticed, service levels dipped. |
| Manual reconciliation of shipments, receipts, and on-hand stock | Planners made decisions on stale data and firefighting increased. |
Concerns with Tool Selection
| Challenge | Impact |
|---|---|
| Debate over keeping Excel, choosing Power BI, or moving to SAC | Decision paralysis, workshops focused on tools rather than needs. |
| Concerns about integrating two ERPs into one analytics layer | Approval cycles stretched and pilot efforts lost momentum. |
| Skepticism about user adoption and training overhead | Risk of buying a tool that teams would not use at scale. |
User Resistance
| Challenge | Impact |
|---|---|
| Dashboards launched without clear business context | Users stayed with ERP reports and Excel because they trusted them more. |
| Training delivered but not tailored to roles and decisions | Low adoption, limited feedback, and slow improvement cycles. |
| No local champions to answer day-to-day questions | Teams reverted to old habits and new tooling looked underused. |
Intervention Strategy: Realigning Governance, Scope & Change Management
1. Resetting governance
The first thing we tackled was governance. Before, meetings felt endless, and I remember people leaving the room unsure who had actually made the call. We cut that down. A smaller group of real decision makers sat at the table. Sessions became shorter, but more decisive. It was not perfect, sometimes decisions were still messy, but at least things moved forward.
Smaller steering group, faster outcomes
Escalations reached the right people quickly
Less confusion after meetings
2. Getting the scope under control
Scope was another problem. With Oracle on one side and SAP on the other, people argued constantly about which numbers belonged in the group view. I saw long lists of requirements that nobody really needed. Eventually, we trimmed it to the essentials. Reporting in SAP Analytics Cloud only had to cover the areas that actually drove decisions, not everything under the sun. Once we agreed, delivery picked up.
Clearer scope stopped endless debates
Data models focused on business outcomes
Fewer moving targets for the team
3. Communication that felt relevant
Earlier, updates were too generic. Different teams heard the same broad message and left with different interpretations. We changed that. Finance got one set of focused updates, operations another, and IT theirs. I noticed people started asking better questions, because they finally felt the project was speaking their language. That approach is something I often connect to in SAP implementation strategy. When communication matches the audience, momentum grows.
Communication tailored to each group
Stakeholders clearer on where things stood
Trust slowly returned to the project
4. Local champions
Training alone had not worked. People sat through sessions but still opened Excel the next morning. What helped was picking local champions. These were colleagues who already had credibility in their teams. They explained 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 in a formal class.
Peer champions gave context that stuck
Users felt less intimidated by the tool
Adoption improved one team at a time
Where things turned
Looking back, these steps i.e. governance reset, scope clarity, targeted communication, and local champions, were what turned the corner. It was not a perfect turnaround, but it gave space for the reporting models and planning tools to show their value. Without that, the technology itself would have been wasted.
Intervention Strategy: Governance, Scope, Communication & Change Champions
| Focus Area | What We Did | Impact |
|---|---|---|
| Resetting Governance | Cut down endless meetings by forming a smaller steering group with real decision makers. Sessions were shorter, sharper, and more decisive—even if not always perfect. |
|
| Getting Scope Under Control | Trimmed bloated requirements across Oracle and SAP. Focused SAP Analytics Cloud reporting only on decisions that mattered. |
|
| Communication That Felt Relevant | Replaced generic updates with tailored messages—finance, operations, and IT each got focused updates. This matched the audience, a lesson I often connect to in SAP implementation strategy. |
|
| Local Champions | Picked peer champions instead of relying only on training. They explained dashboards informally in their own words, which resonated more than classroom sessions. |
|
| Where things turned: Governance reset, scope clarity, targeted communication, and local champions worked together to realign the project. It wasn’t perfect, but it gave space for the reporting models and planning tools to show their value—instead of being wasted. | ||
See How I Make Your ERP and AI System Selection or Implementation right for you.
ERP & AI System Selection – Identify and choose the right ERP or AI-enabled platform to fit your business needs.
Project Support & Recovery – Keep your project on track or bring failing implementations back under control.
ERP Modernization – Transform existing ERP systems to modern, efficient, and scalable ERP environments.
GET IN TOUCHRelated Articles: ERP Selection and Integration Challenges
ERP and AI Tech Consulting Advisory
Guidance on balancing ERP strategy with AI-driven insights and avoiding common evaluation pitfalls.
Noel DCosta: ERP and Integration Hub
Explore in-depth resources on ERP selection, integration practices, and leadership perspectives.
Oracle ERP vs SAP
A side-by-side breakdown of two major ERP platforms with practical factors executives consider.
SAP Integration Suite Delivery Delays
Insights into recurring bottlenecks in SAP Integration Suite rollouts and lessons for project managers.
Why SAP Analytics Cloud Was Chosen
When the debate finally ended, the decision leaned toward SAP Analytics Cloud. I think part of it was practicality. It could connect to both Oracle and SAP without endless custom work, and that alone took some heat out of the discussion.
The finance team had been asking for a single model that did not force them to keep reconciling two sets of numbers. SAC offered that bridge.
1. Integration mattered most in their Situation
There was always a question about whether one tool could handle data from two very different ERPs. In practice, SAC showed it could link live to both. Real-time access was a big deal, especially for people tired of waiting days for reconciliations. I remember the relief on one manager’s face when he saw Oracle data and SAP data side by side in a single dashboard. That kind of integration is exactly what is described in SAP Analytics Cloud.
Direct connections to Oracle and SAP
Less manual effort in reconciliation
Same report available for all regions
2. More than just finance
Another reason was scope. The project was not only about finance. Operations wanted a view of logistics and warehousing, and HR wanted workforce planning. SAC covered planning, reporting, and visualization on one platform. People were skeptical at first, but when they saw operational data tied into financial plans, the value became clearer. It reminded me of some of the arguments in SAP Analytics Cloud for Planning.
Unified planning and reporting tools
One platform across business functions
Better link between operations and finance
3. Speed of delivery
There had been too many delays already. Prebuilt content and templates gave the team a head start. I will admit, some of the templates felt a little generic, but they provided a base to build from. Delivery moved faster than expected once those were in play. It helped that live connections cut out the usual wait for data refreshes.
Looking back, the choice was not just about features. It was about confidence. People wanted a tool that matched both the immediate reporting headaches and the longer roadmap. SAC answered enough of those concerns, even if not perfectly, to win out over other ERP analytics tools like Power BI.
Why the Choice Fell to SAP Analytics Cloud
| Focus Area | What We Saw | Impact |
|---|---|---|
| Integration Across ERPs | SAC linked Oracle and SAP in real time, without heavy custom work. A relief for finance, who were tired of reconciling two sets of numbers. More detail in SAP Analytics Cloud overview. |
|
| Beyond Finance | Covered finance, logistics, HR, and planning. Showed how operations and finance could be tied together. Echoes points from SAC for Planning. |
|
| Speed of Delivery | Prebuilt templates gave a starting point. Live connections cut delays and kept momentum. A practical boost for a team used to long waits. |
|
| Where it landed: The decision was less about flashy features and more about confidence. SAC ticked enough boxes—ERP integration, wider scope, quicker delivery— to win over both finance and operations, even against options like Power BI. | ||
Implementation Highlights: Getting SAP SAC Live Across Two ERPs
The first milestone was designing the data model. Both Oracle and SAP had to feed into one structure, which was more complicated than it looked on paper.
Fields carried the same label but meant very different things in each system. The design team spent weeks mapping definitions until finance could finally agree on what revenue, cost, and margin really meant.
That alignment was essential for SAP Analytics Cloud implementation.
1. Live connections vs data imports
There was a lot of debate about whether to use data imports or live connections. Imports seemed safer at first because the team had more control, but it quickly became clear that delays would continue if they stuck with that method.
Live connections gave direct access to Oracle and SAP data. Reports reflected changes as they happened, which built confidence.
I remember one controller saying it was the first time she did not need to wait for overnight refreshes. More on how live connections make the difference is covered in SAP Analytics Cloud Live.
Oracle and SAP data side by side in SAC
No overnight waiting for refreshed numbers
Easier to trace back to source transactions
2. KPI alignment across entities
Another turning point was when KPIs were finally aligned across both businesses. What used to be a constant argument in monthly reviews slowly became less of an issue.
A single set of definitions, built into the SAC model, helped reduce back-and-forth. This is where the value of thoughtful SAC data model design really came through.
3. Dashboards for real users
Dashboards were rolled out step by step, starting with finance. Sales and operations followed, each getting reports tailored to their work.
Some users complained about the early versions feeling too rigid, and to be honest, they were right. But over time the dashboards improved, and examples from SAP Analytics Cloud for Planning helped shape how the visualizations evolved.
Looking back, the go-live was not perfect. There were gaps, small frustrations, and a lot of late nights. Yet people could finally see finance, sales, and operations data in one place. That visibility mattered more than the rough edges.
Business Outcomes: What Was Achieved in 6 Months
The relaunch wrapped up within six months. That felt like a big relief because momentum had been slipping for a long time. This time the rollout stuck, and people noticed.
Some of the finance staff even said they were surprised at how quickly things turned around, which was not something you often hear in ERP projects.
1. Adoption finally took hold
User adoption stayed high because training was not generic. Sessions were tailored by function, and people could see how SAC actually applied to their work.
For finance it meant faster closes, while for operations it meant clearer supply chain reporting. More on this approach can be seen in SAP Analytics Cloud for Planning.
Tailored training sessions for each department
Less dependence on Excel during daily reporting
Positive feedback loop as more people used dashboards
2. Unified reporting across entities
The biggest shift was financial reporting. For the first time, Oracle and SAP data sat in one model inside SAC. That reduced arguments over definitions and cut down on reconciliation.
Executives could review numbers without waiting for Excel files to circulate. If you look at SAP Analytics Cloud, this is exactly where the tool shows its value.
3. Planning cycles improved
Planning became faster, although not perfect. SAC gave planners the ability to model scenarios and align them with actuals. What had taken weeks before now took days.
Sometimes managers asked for more detail than the dashboards provided, but the fact that they trusted the numbers was already a big improvement. Insights on how SAC supports financial planning are also shared in SAP Analytics Cloud Planning.
In short, the company gained executive visibility across both entities, improved planning cycles, and finally saw the return on effort that had been missing before. Perhaps the most telling sign of success was that nobody asked to go back to the old process.
Things to Avoid in ERP & Analytics Projects
| Mistake | What It Caused | Lesson |
|---|---|---|
| Unclear governance | Endless meetings, no clear decisions, delays mounted | Reset roles and decision rights early |
| Scope drift | Reporting goals kept shifting, confusion grew | Keep scope tight and business-focused |
| Ignoring users | Users lost confidence, adoption slowed | Engage stakeholders early and often |
| Over-customization | Wasted time rebuilding reports, more complexity | Use templates and connectors first, customize later |
| Weak change management | Training missed the mark, users stuck to old habits | Bring in local champions and peer coaching early |
" I depend on SAP Analytics Cloud to keep reporting aligned across regions.
It helps me cut through conflicting data, so our leadership can move forward with confidence.”
– Project Lead, Group Reporting"
Related Articles: Finance & ERP Insights
SAP FICO Essentials
A practical guide to core finance and controlling processes, with examples on how companies apply FICO for reporting and compliance.
SAP License Negotiation: 10 Key Points
Understand license tiers, hidden costs, and the negotiation tactics that directly impact financial planning in SAP projects.
Why CFOs Still Rely on Excel
Lessons from major ERP project failures that highlight the finance visibility gap and why Excel remains a fallback.
SAP Implementation Cost & Budget Breakdown
Detailed insights into cost drivers, budget pitfalls, and the financial levers that determine the true expense of SAP rollouts.
Lessons Learned & Recommendations
Looking back, some lessons stood out more than others. Governance in a multi-ERP setup mattered far more than anyone expected.
Without clear ownership, reporting fell apart quickly. Once the governance reset was in place, things started moving again. For leaders working on SAP project best practices, it is worth investing the time upfront.
Integrated tools add real value
Integrated planning and reporting tools changed the pace of decision making. Having Oracle and SAP data come together in SAP Analytics Cloud saved time and removed arguments. It was not only about dashboards but also about alignment in planning cycles. This is explained further in SAP Analytics Cloud for Planning.
Data models need alignment first
Another clear lesson was that tool selection should never come before data model alignment. At the start, there was debate about Power BI versus SAC. In hindsight, that debate missed the point. If your definitions do not match, no tool will help. Once alignment happened, SAC became the natural fit.
Change management makes or breaks adoption
Change management felt like extra work at first. Yet it turned out to be central. Training, local champions, and ongoing communication made adoption stick. Without this, dashboards would have remained unused. For others considering a SAC implementation checklist, I would place change adoption strategies right at the top.
These lessons may not sound new, but in practice they are the difference between a recovery project that limps along and one that delivers.
Conclusion
The project showed that SAP Analytics Cloud was not just another reporting tool. It became a platform that tied together two ERPs and gave leadership one set of numbers they could actually work with.
That mattered because before, cross-border ERP reporting felt like a constant argument over whose data was right. Now, both Singapore and the UK saw the same figures on the same screen.
For an FMCG environment, speed always counts. Finance had struggled with late consolidations and operations faced conflicting stock reports. With SAC for FMCG industry reporting, the group gained unified planning and analytics that reduced delays.
Decisions could move faster, even if some users still held on to old habits for a while. I remember one warehouse lead saying that for the first time, stock levels in his report matched what finance showed. That sort of alignment builds quiet confidence across teams.
It also prepared the ground for future growth. The rollout moved beyond reporting into areas like forecasting and planning.
That was closer to end-to-end analytics enablement, where the same platform supports both strategy and day-to-day tracking. Perhaps the real success was not the dashboards themselves but the shift in mindset. People spent less time debating numbers and more time discussing choices.
If you have any questions, or want to discuss a situation you have in your ERP Implementation, please don't hesitate to reach out!
Questions You Might Have...
1. Why did the FMCG group struggle with ERP reporting at the start?
It came down to two systems that just didn’t talk to each other. Singapore was on Oracle, the UK was on SAP. Every month, finance had to stitch the numbers together by hand. It took days, and no one fully trusted the outcome.
Meetings would stall because one side said, “Our numbers show this,” while the other side said, “Well, ours don’t.” On top of that, the steering group was too big. Too many people in the room, nobody actually making a decision.
After a while, it became obvious: costs were piling up, confidence was slipping, and the project was going nowhere.
2. What changed the direction of the project?
The shift came when leadership admitted the project was stuck and agreed to a recovery plan. They cut the steering group down to a handful of decision-makers, set firmer priorities, and picked SAP Analytics Cloud as the one reporting tool.
That choice gave the team a single target instead of chasing endless requests. Updates also changed…finance got different updates than operations, so everyone knew what was happening that mattered to them.
Suddenly, meetings weren’t about who to blame but about what was next. That’s when people started to believe the project might actually deliver.
3. How did SAP Analytics Cloud help with Oracle and SAP together?
At first, nobody believed one tool could handle both ERPs. But SAC connected directly into both, which meant the group could finally see numbers side by side.
No more waiting for reconciliation files or arguing about which sheet was correct. I still remember the look on one finance manager’s face when he saw Oracle and SAP data in the same dashboard, like a weight had lifted.
Was it perfect? No. But it cut out the busy work and gave everyone the same view. That alone cooled a lot of the tension that had built up.
4. Why was scope such a problem in the beginning?
The scope was a problem because everyone wanted everything. Finance wanted one set of reports, operations wanted another, and IT kept getting asked for data nobody was ever going to use.
The list of “must-haves” kept growing until it was unmanageable. I remember sitting in a workshop where the whiteboard was covered end to end with requests, and half of them had nothing to do with real decisions. It slowed everything down.
When we finally said, “Look, reporting only needs to cover what drives decisions,” the picture got clearer. We stripped out the noise, focused on what mattered, and the project started to move again. It was less about fancy dashboards and more about nailing the essentials. That’s what got people back onside.
5. How was communication fixed during the recovery?
Earlier, the project team blasted the same message to everyone. Finance, operations, IT — they all got the same updates, and half the time nobody knew what applied to them. It felt like wallpaper.
When we switched to tailored updates, things changed. Finance got clear numbers and timelines that mattered to budgets. Operations got updates about logistics and processes. IT got their own technical roadmap.
Suddenly, people stopped asking, “What does this mean for us?” because the message already answered it. I could see the shift in meetings… people asked sharper questions because they actually understood what they were hearing. That’s when trust started creeping back in.
6. What role did local champions play?
This was a big one. Training sessions didn’t stick. People showed up, sat through a demo, and then went back to Excel the next day. The difference came when we picked local champions i.e. colleagues who already had respect in their teams.
They weren’t trainers by title, but when they explained dashboards in their own words, people listened. I sat in one of those sessions, and the tone was night and day compared to the formal classes.
People felt comfortable asking questions, even the “stupid” ones. Adoption wasn’t instant, but slowly, team by team, folks started using the tool instead of ignoring it. Champions were the bridge.
7. What impact did governance changes have?
Meetings got shorter and sharper. Before, we’d sit for hours, argue circles, and leave with no decision. With a smaller steering group, decisions actually got made. It wasn’t always pretty, but momentum returned.
Escalations didn’t sit around for weeks, they went straight to the right person. That meant issues stopped festering, and people didn’t waste time rehashing the same problems. Honestly, it wasn’t perfect…sometimes the smaller group still dragged their feet, but compared to before, it was night and day. Governance reset gave the project a spine again.
8. How did the finance team benefit from SAC specifically?
For finance, the pain point was reconciling two sets of numbers every single month. Oracle on one side, SAP on the other. SAP SAC gave them a single model that pulled directly from both.
No more waiting days for files to land in inboxes. The first time they saw a consolidated dashboard, the sigh of relief was real. It wasn’t just faster, it meant they could finally trust the numbers enough to walk into a meeting without hedging every statement.
That confidence spilled over. When finance trusted the numbers, the whole project carried more weight.
9. How did operations and HR use SAC beyond finance?
At first, operations and HR felt like spectators. It was all finance talk, and they didn’t see the point. But once SAC started tying in logistics data and workforce planning, they perked up. Operations could track warehousing and transport costs alongside financial data.
HR could plan headcount against budgets. It clicked when they saw how their numbers tied into finance decisions. For the first time, different departments weren’t working from disconnected spreadsheets.
The link between operations, HR, and finance gave leadership a wider picture than they’d ever had. That’s when SAC stopped being “a finance tool” and started being the group’s planning tool.
10. Looking back, what turned a failing ERP project into a success?
Really, it wasn’t one magic thing. It was a mix: governance reset, trimming the scope, changing communication, and leaning on local champions. SAC helped because it fit both Oracle and SAP without endless custom work, but the tech alone wouldn’t have saved it.
What mattered was people actually trusting the process again. I remember how low morale had gotten… folks were just waiting for the project to collapse. Six months later, those same people were presenting dashboards they’d built themselves.
That turnaround came from clarity, ownership, and a tool that didn’t get in the way. The project didn’t end up perfect, but it went from near-failure to something the group could build on. And honestly, that’s what most ERP recoveries look like, messy but workable if you get the basics right.
