The most expensive decision in an EPCM implementation is made in week two. Long before anyone writes an allocation rule.
It is the dimensional design.
Most teams start with the rules, and that is understandable. Rules are where logic lives, they are visible, and they demonstrate well in a steering meeting.
But in Oracle Enterprise Profitability and Cost Management, the dimensional model quietly determines how flexible that application will be for the next five years.
The instinct is to mirror the general ledger:
- Cost Centre
- Department
- Business Unit
It feels right, because financial ownership, budgeting and variance reporting are already organized that way.
Then the questions change:
- What does it cost to manufacture one unit?
- Which activities consume the most shared services?
- Which customers are absorbing our overhead?
The ledger answers one question extremely well. Who incurred the cost.
A profitability model must answer two more:
- What work was performed?
- What consumed it?
In EPCM, organizational structure sits in the Entity dimension. Activity, product, customer and region are custom dimensions you have to design on purpose, and you get up to eleven of them.
Three things I look at in every EPCM design review.
1. Keep Activity Separate from Organizational Structure
The cost center represents ownership. An activity represents the work being performed.
Today they may look identical. After the next reorganization they usually are not.
Separating them early costs a conversation. Untangling them later costs a project.
2. Every Allocation Needs a Driver You Can Defend
In EPCM the driver definition tells the system how to split source data across destinations.
Common examples: headcount, machine hours, floor area, transaction volume, labor hours, revenue.
If you cannot explain in one sentence why a cost lands where it lands, the design needs another pass. Someone in finance will ask, and the answer has to be short.
3. Design for the Questions That Arrive in Year Two
Initial reporting requirements rarely survive contact with a curious CFO. Profitability by product, customer or region tends to follow, and sooner than the plan assumed.
There is a practical asymmetry worth understanding.
Rules are included. EPCM organizes them into models and rule sets with sequence numbers, and you can undo a single rule, a rule set, or all of them.
Dimensions are not. Every rule has to resolve every dimension in the application, so introducing one later means revisiting rules you have already written and tested, along with the metadata, drivers, forms and reports sitting on top of them.

The EPCM implementations I have seen age well are not the ones with the most rules. They are the ones where the dimensional model still answers new questions two years after go-live.
An extra week on dimensional design at the start is usually cheaper than a redesign later.
