Rebuilding after HPCM: smaller stack, sharper answers.
In short. Oracle Hyperion Profitability and Cost Management belongs to the on-premises Hyperion generation, and its users face a transition to Oracle's cloud offerings. That crossroads is a fair 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. What follows are publicly known facts about the product's lifecycle, stated neutrally, and an honest description of an alternative.
Why are HPCM users re-evaluating now?
Because the platform decision has been taken out of their hands, and the modelling decision has not.
HPCM is part of the on-premises Hyperion family. Oracle's strategic direction for this product area is its cloud EPM portfolio, and organisations running HPCM on premises face a migration project of some form: to Oracle's cloud profitability offering or elsewhere. CONFIRM: precise, current Oracle lifecycle wording, checked against Oracle's published support policy at time of publication
A forced migration is disruptive. It is also the cheapest moment you will ever get to reconsider the model itself, because the re-implementation cost must be paid either way.
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. CONFIRM: typical duration range C&P is willing to commit to publicly
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 CONFIRM: committed range |
| Pricing model | Enterprise licence and infrastructure or cloud subscription (per vendor terms) | Subscription plus expert build; the client team runs the model CONFIRM: current commercial wording |
Fair questions.
- Is Oracle discontinuing HPCM?
- Oracle's direction for this product family is its cloud EPM portfolio; on-premises Hyperion customers face lifecycle and support decisions per Oracle's published policies. Check the current state directly with Oracle. CONFIRM: verified lifecycle summary sentence at publication date Our point does not depend on any deadline: re-implementation is required either way, so the modelling question is open either way.
- 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.