A lot of EPM challenges start long before the build begins.

Not in the configuration. Not in the reports. Not in the integrations.

But in the early design decisions about what the platform should and should not do.

I have been thinking about this through two lenses lately: systems thinking and design thinking.

Systems thinking asks: what is causing the behaviour we are seeing?

Design thinking asks: what is the user actually trying to get done?

Both matter in EPM, because many issues that appear after go-live were already shaped when the scope was defined.

You know the questions that come up a few months in:

  • Why are users still maintaining offline models?
  • Why is no one using the system calculations?
  • Why are forecasts still late?

All fair questions.

But they usually trace back to earlier decisions.

  • What did we decide to put into EPM?
  • What did we leave outside?
  • What did we try to fit into the platform because it was technically possible?

I have seen versions of this play out more than once.

A finance team may already have a detailed model for a specialist planning area: workforce, customer volumes, project costs, borrowings, or something similar. It works. The users understand it. The logic has evolved over many planning cycles.

Of course, EPM can often be customised to replicate a lot of it.

But that is not really the question.

The better one is: should it?

Some things clearly belong in EPM: revenue planning, OpEx, drivers, scenarios, management reporting, and areas where finance owns the planning logic.

Some things are better handled through a hybrid approach. EPM can still be where numbers are reviewed, challenged, consolidated, and reported while the detailed calculation lives somewhere more suited for the job.

And some things are best left to specialist systems because the domain has its own depth, rules, and rhythm.

The trap is assuming that because EPM can do something, it should.

"We are implementing an FP&A solution, so most planning and forecasting should probably live inside it."

Understandable. But planning is not a single discipline.

Forecasting headcount is planning.

Forecasting customer demand is planning.

Forecasting borrowings is planning.

Same word. Very different work. Different users. Different rules. Different cadences. Different levels of detail.

The label "FP&A solution" tells you what the platform is good at.

It does not mean every forecast in the business belongs inside it.

That is how well-intentioned projects quietly become more complex than they need to be.

And over time, users tend to start creating workarounds. Not because they dislike the system, but because the system no longer reflects how the work actually gets done.

For me, one of the most important questions in an EPM programme is not:

"What should we build?"

It is:

"What should we deliberately not build here?"

That conversation can be uncomfortable early in a project.

But it saves complexity and trust later on.