Rebuilding after HPCM: smaller stack, sharper answers.
In short. Oracle Hyperion Profitability and Cost Management belongs to the on-premises Hyperion generation. Oracle's own readme for release 11.2.1.0.000, dated March 2020, states that it includes Premier Support through at least 2030 - so nothing is forcing your hand, which is the best possible moment to ask a bigger question: whether to re-implement an allocation engine, or move to a time-driven model that costs activities directly. This page maps the second option.
A note on tone: Oracle HPCM is capable software and this page will not pretend otherwise. The only lifecycle statement we make is the one Oracle's own 11.2 readme carries; the rest is an honest description of an alternative. We are not claiming Oracle is withdrawing the product.
Why do HPCM users re-evaluate at all?
Not because a deadline says so. Because the modelling decision was never really made.
HPCM is part of the on-premises Hyperion family, and Oracle documents release 11.2 with Premier Support through at least 2030. Oracle also sells cloud EPM products, and some organisations will move there in time. Either way the choice is theirs to schedule, which is the useful part.
A migration is disruptive whenever it happens. That is an argument for choosing the moment rather than inheriting it, and for spending the re-implementation budget once, on the model you actually want.
The question is not "which vendor gets the licence fee". It is "should the new model work the same way as the old one".
What did HPCM do well, and what did it leave open?
HPCM is, at heart, a powerful allocation engine: ledger balances flow through staged allocation rules to cost objects. For regulatory allocation, shared-services chargeback and management ledger purposes, that architecture served well.
What allocation architectures leave open is causality at the transaction level. Rules distribute cost in percentages; they do not measure what an order, a shipment or a patient episode actually consumed. When the question moves from "how do we spread IT cost" to "which customers lose us money", rule-based allocation runs out of resolution.
That second question is what time-driven activity-based costing was built for.
What does a modern TDABC stack look like?
Four layers, all of them lighter than the last generation.
Data in
Extracts your systems already produce: GL balances, payroll, transactional logs. One of our current models runs on a 525,000-row shipment dataset refreshed from the client's operational system. No data warehouse project required.
A capacity model
Resources grouped into cost pools, each with a capacity cost rate: cost of capacity supplied divided by practical capacity. This replaces multi-stage allocation with a single, explainable economic statement per resource pool.
Time equations
Each transaction's cost is a formula of its characteristics: minutes as a function of order lines, delivery stops, handling type, complexity. A handful of equations costs millions of transactions, which is why maintenance does not balloon the way rule libraries do.
Decision surfaces
Whale curves, cost-to-serve by customer and product, capacity utilisation, scenario views. In our stack this layer is CostCtrl, and the client's finance team, not a consultancy, operates it.
ALLOCATION ENGINE VS TIME-DRIVEN MODEL
How does the migration run?
Four steps, deliberately boring.
Inventory the decisions, not the rules
List what HPCM outputs are actually used, by whom, for which decisions. Most legacy models carry rules nobody has read in years; the decision inventory is always shorter than the rule inventory.
Rebuild the economics as capacity and time
Map cost pools, set practical capacities, draft time equations for the transactions that matter. This is modelling work, measured in weeks.
Run parallel on one period
Same source data through old and new models. Differences are examined, explained and documented. This step converts scepticism into sign-off, and it is where the old model's hidden assumptions surface.
Cut over and hand over
The model moves to the client's team with the refresh process documented. Any regulatory allocation outputs the organisation must keep producing are reconciled from the new model's results.
MIGRATION IN FOUR STEPS
How do the approaches compare?
| Legacy allocation suite (HPCM generation) | Modern TDABC stack (CostCtrl) | |
|---|---|---|
| Modelling approach | Staged allocation rules over ledger balances | Capacity cost rates and time equations over transactions |
| Time equations | Not native; time-based logic approximated through drivers | Native; core costing mechanism |
| Data volume | Aggregated ledger and driver tables | Transaction-level; models run on hundreds of thousands of rows |
| Implementation time | Enterprise EPM project, typically quarters | First working model in weeks, not quarters. |
| Pricing model | Enterprise licence and infrastructure or cloud subscription (per vendor terms) | Subscription plus expert build; the client team runs the model |
Fair questions.
- Is Oracle discontinuing HPCM?
- Not as far as Oracle's published documentation shows. The readme for release 11.2.1.0.000, dated March 2020, states that it includes Premier Support through at least 2030. Oracle also sells cloud EPM products, and the lifecycle documents that would settle the longer view are not readable without an Oracle account, so check your own entitlement directly with Oracle. Our point does not depend on a deadline: the modelling question is worth asking whether or not you ever move.
- Can a TDABC model reproduce our regulatory allocations?
- Usually the required outputs can be reconciled from a TDABC model, and the parallel run in step 3 proves it case by case. Where a regulator mandates a specific allocation form, the model produces it as a report rather than as its core logic.
- We have years of HPCM rules. Is that all wasted?
- No. The rules encode institutional knowledge about cost relationships. The decision inventory in step 1 harvests that knowledge; what gets retired is the machinery, not the understanding.
- Who runs the new model after cutover?
- Your finance team, in CostCtrl. That is the design goal, not an afterthought: every engagement ends with handover, and the case studies on this site describe clients operating their models years on.
- What if we choose Oracle's cloud option instead?
- Then choose it with a decision inventory in hand and clear eyes about what rule-based allocation can and cannot answer. If cost-to-serve and customer profitability are on your board's agenda, test any candidate against those questions before you commit.
Facing the HPCM decision?
A 30-minute call with a senior partner: we map your current model's decision inventory and tell you honestly whether TDABC fits. No pitch, no vendor bashing.
- Reply
- Within one working day
- Who answers
- A partner, not a bot
- Commitment
- None
Notes and trademarks. This page compares approaches to cost and profitability modelling and reflects our professional opinion alongside publicly available product information, current as of mid-2026. It is commentary on fit, not a statement about the quality of any product, and not advice for a specific situation. Verify current product and support details with the vendor: Oracle's HPCM 11.2 readme is the source for the support statement above. Oracle, Hyperion and HPCM are trademarks or registered trademarks of Oracle Corporation and/or its affiliates. Cost and Profitability Consulting and CostCtrl are independent and not affiliated with, authorised, sponsored or endorsed by Oracle Corporation.
Proof
A distributor in New Zealand. €1.335M of cost-to-serve made visible, then halved, and 830 loss-making customers brought down to 295.
Read the case study →Who you would be talking to
Miguel Guimarães, Founding Partner
Cost and profitability practitioner for 25+ years. Presented the Damco cost-to-serve case at Managing for Profit (Amsterdam RAI, December 2009), on the same programme as Robert S. Kaplan.
Call +351 910 313 731
