How a North American Appliance Giant Spent Three Years Building an EPM House Starting With the Roof, and Why Oracle EPM Fixed It by Starting With the Foundation
By Pedro San Martín, Asher & Company
There is a conversation I have had, in some variation, at least a dozen times in my career. It usually starts with a CFO or a CIO sending me a deck. The deck has a lot of slides. There are architecture diagrams, vendor logos, implementation timelines, and a budget number that, when I see it, makes me pause.
The deck ends with a question phrased as a request for validation. Read it twice and it is a cry for help. "We've been at this for two and a half years. The system is live. But we still can't answer the question we started with. What are we doing wrong?"
This is the story of one of those conversations, at a company I'll call AndroMex Appliances. It is North America's largest manufacturer of home appliances, a private company headquartered in Mexico City. It has revenues approaching USD 5 billion, 11 manufacturing plants across nine countries, approximately 9,500 employees, and a product portfolio spanning refrigerators, gas ranges, washing machines, and air conditioners sold under multiple brand licenses including major global names across 70+ countries.
AndroMex had done what thousands of companies do every year. They bought a world-class EPM platform. They hired a reputable implementation partner. They followed the vendor's recommended deployment path.
And they built the most expensive, most sophisticated planning system in the company's history on top of nothing.
After two and a half years and somewhere between USD 4 and 6 million in implementation costs, they still couldn't answer the question they started with. "Which of our products, in which markets, through which channels, are actually making us money?"
I got the call from the CFO on a Tuesday. By Thursday I was in Mexico City. By Friday afternoon, I knew what had happened and how to fix it.
The Battlefield Context
AndroMex was a well-managed company. By any operational measure, it was a sophisticated manufacturer. It was vertically integrated across most of its supply chain, with SAP S/4HANA as its core ERP backbone, SAP BW/4HANA as the data warehouse, Microsoft Azure for cloud infrastructure, and Power BI for operational dashboards. Its data warehouses shared business intelligence across sales, logistics, and finance.
The technology stack was not the problem. The problem was the sequence.
When the Finance and IT leadership teams had sat down three years earlier to design their EPM transformation roadmap, they had made a decision that seemed logical at the time. Start with planning and budgeting, because that's what the CFO needs most urgently.
The CFO needed a consolidated financial plan across 11 plants, multiple currencies, 70+ markets, and several brand licensing structures. The annual budgeting process was taking four months and was still done largely in Excel. It was painful, slow, and produced a plan that nobody trusted six weeks after it was approved.
So they bought SAP BPC (Business Planning and Consolidation). Best-in-class tool. Excellent vendor support. Solid implementation partner. And they spent fourteen months building a planning model that covered AndroMex's whole financial structure, with P&L by plant, by brand, by market, and by product category.
The model looked extraordinary. Beautiful, even. Cascading hierarchies. Intercompany eliminations. Currency translation. Workflow and approval chains.
There was just one problem.
The cost inputs feeding the plan were allocated overhead rates from the general ledger. They were the same blunt, plant-wide averages the Excel model had used for the previous decade. The planning model was sophisticated in its financial architecture and hollow in its economic content. When you asked it "what does it cost to make a refrigerator for the Brazilian market versus the Mexican market?", it gave you an answer. But the answer was a weighted average of everything AndroMex made, allocated by revenue percentage, adjusted for nothing.
It was, in the words of the COO when I finally showed him what was inside the model, "like using a thermometer to measure the weight of a patient." Technically an instrument. Measuring the wrong thing entirely.
I. The Three Moments When the Alarm Should Have Sounded
Moment One: the BPC go-live. Fourteen months after the project started, the SAP BPC system went live. The budgeting cycle ran through it for the first time. The CFO noticed something right away. The budget numbers the model produced were almost identical to the prior year's Excel-based budget, adjusted for inflation. There was no analytical insight. No product-level visibility. No channel-level profitability. Just a faster way to produce the same inadequate numbers that the Excel process had been producing for years. The implementation partner said this was expected, because the model needed more cycles to mature. The CFO accepted this explanation. He shouldn't have.
Moment Two: the PaPM addition. Eighteen months in, with BPC live but delivering limited insight, the team decided to address the profitability gap by adding SAP Profitability and Performance Management (PaPM) on top of the existing architecture. The logic went like this. BPC handles the plan, PaPM handles the profitability analysis, the two talk to each other, problem solved.
But PaPM is a profitability allocation engine. It needs a cost model to allocate from. AndroMex didn't have one. What it had was a general ledger with cost centers and a chart of accounts. PaPM dutifully allocated those general ledger costs to products and channels. It used revenue as the primary driver, because no activity-based data existed for a more granular allocation.
The result was a profitability model that showed every product, in every market, at approximately the same margin. Because the costs had been spread proportionally to revenue. That is a mathematical tautology. If you allocate costs by revenue, your margin percentages will cluster around the average. You learn nothing about which products are profitable.
Moment Three: the strategy meeting. Twenty-eight months into the implementation, the CEO held a strategic review. The question on the table was simple. Should AndroMex exit the Brazilian market, where volumes were declining and the competitive environment had intensified?
The finance team pulled the PaPM report. Brazil showed a 9.2% EBITDA margin, slightly below the group average of 11.4% but not dramatically so. The strategic recommendation was to stay and invest in Brazil.
Six months later, the regional CFO in Brazil ran a bottom-up analysis using local cost data, actual logistics costs, real brand licensing fees, and accurate warranty costs. It put Brazil's true EBITDA margin at 2.1%. The gap between 9.2% and 2.1% was the price of having no cost model.
That was the moment the global CFO called me at Asher & Company.
II. The PACE Causal Model
III. The Data
AndroMex Appliances: Operational Profile
| Metric | Value |
|---|---|
| Revenue (estimated) | ~USD 5.2 billion |
| Manufacturing plants | 11 across 9 countries |
| Employees | ~9,500 |
| Markets served | 70+ countries |
| Product categories | Refrigerators, gas ranges, washing machines, ACs, microwaves |
| Key brand licenses | Multiple global OEM licenses |
| ERP backbone | SAP S/4HANA |
| Data warehouse | SAP BW/4HANA |
| Cloud infrastructure | Microsoft Azure |
| BI layer | Power BI |
| EPM investment (failed path) | USD 4–6M over 30 months |
| Data quality score pre-transformation | 80% |
| Data quality score post-transformation | 95% |
The Cost of Building in the Wrong Order
| Phase | Tool | Duration | Investment | What it produced | What was missing |
|---|---|---|---|---|---|
| Phase 1 | SAP BPC | 14 months | ~USD 2.2M | Consolidated financial plan | Cost-to-serve by product/channel |
| Phase 2 | SAP PaPM | 10 months | ~USD 1.8M | Revenue-allocated profitability | Activity-based cost foundation |
| Phase 3 | Integration fixes | 6 months | ~USD 1.1M | Partial data reconciliation | Causal model between costs and outputs |
| Total wrong path | 30 months | ~USD 5.1M | Faster Excel | Economic reality |
The Brazil Profitability Gap: Model vs. Reality
| Metric | SAP PaPM output | Bottom-up regional analysis | Gap |
|---|---|---|---|
| Brazil EBITDA margin | 9.2% | 2.1% | −7.1 pp |
| Logistics cost as % of revenue | 4.1% | 9.8% | −5.7 pp |
| Brand licensing fee allocation | 1.2% | 3.4% | −2.2 pp |
| Warranty & after-sales cost | 0.8% | 2.9% | −2.1 pp |
| Working capital cost | Not modeled | 4.2% | −4.2 pp |
| True economic margin | 9.2% (model) | 2.1% (reality) | Strategic error |
Oracle EPM Correct Build Sequence vs. SAP Path
| Layer | Correct sequence (Oracle EPM) | Wrong sequence (SAP path) | Time to insight |
|---|---|---|---|
| 1 — Cost foundation | Oracle PCM: activity-based costing first | SAP BPC: planning first, no cost model | 12 months → insight |
| 2 — Profitability | Oracle PCM: product/channel/customer P&L | SAP PaPM: allocated from GL averages | 18 months → real margins |
| 3 — Planning | Oracle EPBCS: plans driven by real cost rates | SAP BPC: plans driven by GL allocations | 24 months → credible plan |
| 4 — Consolidation | Oracle FCCS: built on real economics | SAP BPC consolidation: built on averages | 30 months → strategic clarity |
IV. The Three Decisions
Option A: Exit Brazil's Low-End Refrigerator Segment, Defend Premium
Use Oracle PCM's fully loaded cost-to-serve data to segment the Brazilian product portfolio. Exit the three low-end refrigerator SKUs where true economic margin was negative after logistics, licensing, and warranty costs. Maintain and invest in the premium refrigerator line where true margin was 14.2%.
PACE stage: Execute, immediate (0–6 months)
Expected benefits:
- Brazil portfolio EBITDA margin improves from 2.1% to approximately 8.4% on remaining SKUs
- Working capital reduction of USD 18–22M as low-margin inventory is wound down
- Manufacturing capacity freed at the San Luis Potosí plant, redeployable to higher-margin SKU production
- Ends the strategic noise around a Brazil exit, because the answer is portfolio rationalization
Risks:
- Volume loss triggers fixed cost deleverage in the short term, so the Brazil P&L looks worse before it looks better
- Distribution partners in Brazil lose volume and will need relationship management
- Brand licensing partner may object to SKU rationalization, which calls for a contract review
Trade-off: Margin improvement vs. short-term volume optics. The CFO who makes this decision will face a quarter of negative volume headlines before the margin improvement becomes visible. It requires board-level conviction that the PCM data is correct. After three years of being told the old system was accurate, that conviction is itself a change management challenge.
Option B: Reprice the 27% of Value-Destroying SKUs Across All Markets
Use Oracle PCM's product-level economic P&L to identify the 92 SKUs (27% of portfolio) where true economic margin is negative. For each, present a repricing analysis. What price increase would bring the SKU to breakeven, and is that increase feasible given competitive dynamics? Where price increase is not feasible, initiate discontinuation.
PACE stage: Validate → Execute (6–18 months)
Expected benefits:
- Portfolio-level EBITDA margin improvement of 3–5 percentage points across all markets
- Reduction in manufacturing complexity, since fewer SKUs mean longer production runs and lower setup costs
- Working capital improvement as slow-moving, low-margin SKU inventory is reduced
- Oracle PCM model becomes the permanent gate for new SKU launches
Risks:
- Sales organization resists SKU rationalization because volume targets are built around the existing portfolio
- Some value-destroying SKUs are loss leaders that drive attachment sales
- Distribution channel may react negatively if key price points are eliminated
- 18-month timeline means value-destroying SKUs continue consuming resources during analysis
Trade-off: Portfolio discipline vs. commercial relationships. The Oracle PCM data makes the conversation unavoidable. It does not make it comfortable.
Option C: Rebuild the Annual Planning Process on Oracle EPBCS Cost Drivers
Use Oracle PCM activity-based cost rates as the permanent foundation for the EPBCS planning model. Every financial plan is built bottom-up, from volume forecast to activity demand to resource cost to financial P&L. Eliminate all remaining revenue-proportional cost allocations. Implement Oracle FCCS for statutory consolidation, connected to the same cost model.
PACE stage: Formulate → Validate → Execute (18–24 months)
Expected benefits:
- Financial plan reflects economic reality for the first time, with plan vs. actual variance falling from 18% to under 6% in the first cycle
- Annual budgeting process reduces from four months to six weeks
- CFO can present the board with a plan where every cost assumption is traceable to a specific activity driver
- Strategic decisions (enter/exit markets, launch/discontinue products, invest/divest capacity) supported by a causal model
Risks:
- Organizational change management is the primary risk, since the finance team must learn to plan from drivers instead of percentages
- Data quality requirements of the PCM model are demanding (95% required vs. 80% at project start)
- The transition period (months 1–8) is operationally disruptive, with two planning systems running in parallel
- Oracle PCM requires ongoing maintenance as the cost structure changes
Trade-off: This is the only option that permanently eliminates the root cause. Options A and B are decisions made possible by the new model. Option C is the model itself, institutionalized. The organization that chooses Option C is choosing to manage by economic reality rather than financial convention. That is a cultural transformation as much as a technology one.
V. Lessons Learned
1. Planning without a cost model is just budgeting. And budgeting is not management. A financial plan tells you what the numbers will be. An economic model tells you why the numbers will be what they will be, and what levers exist to change them. SAP BPC gave AndroMex a financial plan. Oracle PCM gave them an economic model. The plan was useless without the model. The model made the plan meaningful.
2. The logical build sequence for EPM is non-negotiable: costs first, profitability second, planning third, consolidation fourth. Every CFO who has lived through an implementation in the wrong order understands this viscerally. Every CFO who hasn't tends to dismiss it as consultant theory. It is causality. You cannot plan what you have not measured. You cannot measure profitability without tracing costs. You cannot trace costs without an activity model. The sequence is an architectural requirement.
3. Revenue-proportional cost allocation is a mathematical tautology. When you allocate costs by revenue, your margin percentages cluster around the average by construction. You learn nothing about which products are profitable and which are not. Every CFO already knew the portfolio average margin. The entire value of a profitability system lies in its ability to deviate from the average. Revenue-proportional allocation eliminates that variance. It is the accounting equivalent of measuring everyone's height with a ruler that always shows 1.75 meters.
4. The Brazil decision exposed a model problem. The data to calculate Brazil's true economic margin existed in AndroMex's systems. It sat in SAP S/4HANA, in the logistics system, in the brand licensing contracts, and in the warranty claims database. What didn't exist was the model that connected those data sources causally. Oracle PCM added no new data. It offered a new way of reading data that already existed. The most expensive EPM mistakes happen when companies have data they cannot read.
5. SAP BPC and SAP PaPM are excellent tools in the right sequence. They are expensive mistakes in the wrong one. This case is not an argument against SAP's EPM tools. BPC is a world-class planning platform. PaPM is a sophisticated profitability engine. The failure at AndroMex came from the order. Both tools require a cost model to feed them. Neither creates the cost model itself. The tools performed as designed. They were designed to receive inputs that didn't exist.
6. The cost of the wrong sequence goes beyond the wasted investment. It includes the decisions not made. AndroMex spent USD 5.1M and thirty months building a system that couldn't answer its own questions. But the real cost was the Brazil strategic decision that was nearly made on false data. If the CEO had committed to Brazil investment based on a 9.2% EBITDA margin that turned out to be 2.1%, the capital allocation error would have been an order of magnitude larger than the implementation cost. The danger of a wrong EPM model is that it fails invisibly. It produces numbers that look right, feel right, and point in the wrong direction.
7. Oracle EPM's modularity is its strategic advantage, if you use it in the right order. Oracle EPM succeeded where the SAP path failed because of the suite's architectural coherence, more than the strength of any single tool. Oracle PCM is designed to feed Oracle EPBCS. Oracle EPBCS is designed to feed Oracle FCCS. The data model is consistent across layers. The cost drivers defined in PCM become the planning drivers in EPBCS. The plan built in EPBCS feeds the consolidation in FCCS. AndroMex had spent six months and USD 1.1M trying to build that integration between SAP BPC and SAP PaPM. It came standard in the Oracle architecture. Because Oracle designed the suite to be built in the right order.
Pedro San Martín is Founder & Principal of Asher & Company, a specialized advisory firm in Enterprise Performance Management, profitability architecture, and strategic finance across the Americas and Europe. He works with CFOs and finance leaders to design and implement EPM architectures in the correct logical sequence. Every model starts with the cost.
asher.company | Insights. Real decisions, real consequences, no textbook answers.
