Standard adoption vs custom design: who owns every future change?

· EPM

The demo always fits - your month-end close is what doesn't. How to decide, per requirement, between adopting standard EPM content and building custom, without inheriting the worst of both.

The demo always fits. The month-end close is where the gaps show up.

Every EPM project eventually lands on the same argument: do we adopt the standard, pre-built content, or do we design a custom solution around how we actually work? Teams treat it as a feature comparison. It is not. Standard versus custom is really a question of who owns every future change. Standard content shifts maintenance onto the vendor's roadmap but couples you to its assumptions. Custom gives you exact fit but makes you the sole maintainer - testing, documentation, key-person risk and all. Get that framing right and the rest of the decision gets much easier.

What the industry has already learned

This debate has been fought hardest in the ERP world, and the scars are instructive.

SAP's whole "clean core" movement exists because two decades of custom code inside ECC made S/4HANA migrations brutally expensive. The doctrine: keep the core unmodified, run fit-to-standard workshops first, and push genuinely needed logic into a separate extension layer. Gartner now treats customisation debt as a named category of technical debt with its own remediation playbooks - the danger being the "strategic stall", where accumulated custom stops the platform from supporting anything new.

Meanwhile, every EPM vendor has converged on the same answer from the supply side: an app store. Jedox ships Best Practice Accelerators (Integrated Financial Planning, Sales, HR, ESG) from its Marketplace; Anaplan has its App Hub; OneStream its Solution Exchange. That convergence is the industry telling you where standard ends: P&L, balance sheet, cash flow, currency conversion, versioning and workflow are commodity patterns distilled from thousands of projects. Whatever is left over is the only part worth building.

The rough consensus number is the 80/20 rule: a well-chosen platform should cover 80-90% of requirements through configuration, with custom reserved for the residue - yet that residue commonly eats 10-30% of the implementation budget. Which tells you exactly where the money leaks.

The upgrade tax is the real price of custom

Custom is rarely expensive to build. It is expensive to keep. Every custom object converts vendor releases from free improvements into billable regression-testing events - and cloud EPM makes it worse, because releases arrive on the vendor's cadence, not yours. There is also a subtler cost: customisations go redundant as the vendor ships the same capability natively, and you keep paying maintenance on something the product now does for free.

This is how custom models end up frozen and unmaintained. Nobody budgeted for re-testing forty bespoke reports every platform update, so the instance freezes on an old version, and the "flexible" build becomes the thing blocking every new feature.

So price custom honestly: build cost plus (test-and-fix effort per release, times releases per year, times five years). Present that number, not the build quote. Every custom object is a subscription you pay for in regression tests, at the vendor's release cadence.

Decide per requirement, never per project

The worst version of this debate happens once, at proposal stage, as a single binary. That is a false choice. A planning solution is 150-300 discrete requirements, and each one sits somewhere different on the ladder:

The burden of proof escalates up the ladder because each rung transfers maintenance liability from the vendor's roadmap to the client's payroll. The default answer is always the rung below the one that was asked for. Add an Adopt/Adapt/Build column to your requirements register - and if more than 30% of rows say Build, challenge the workshop notes before you challenge the product.

"We're special" - where clients are wrong, and where they are right

Every client believes their P&L planning is unique. After years of implementations I have yet to meet a cost centre expense plan, an FTE-driven personnel plan or a three-statement linkage that genuinely needed inventing from zero. What clients call uniqueness in these areas is usually their current Excel file's layout - and your Excel layout is a habit, not a requirement.

But clients really are unique in three places:

  1. Revenue mechanics - how orders, projects, subscriptions or tariffs actually convert to recognised revenue.
  2. Allocation logic - which encodes the steering model and internal politics, not accounting.
  3. Operational drivers - the beds, seats, tonnes and billable hours upstream of finance.

That is where competitive behaviour lives, and forcing it into a generic template destroys the tool's value. So split the model map in discovery: the finance backbone defaults to Adopt/Adapt; the value drivers are the only zone where Build is presumed legitimate. Clients are unique where they make money, not where they close the books.

A simple test when someone says "that won't work here": ask them to name the business decision that would be made differently under the standard design. If the answer is about formatting or column order, it is an Adapt, not a Build.

Standard content is a discovery tool, even when you'll build

Here is the underrated part: the biggest payoff of an accelerator is not saved build time, it is better requirements. Install the standard model in week one, load a cut of the client's own chart of accounts, and run workshops against a live, clickable model. You will get sharper feedback in two hours than in two weeks of blank-page interviews, because people cannot articulate requirements in the abstract but can instantly tell you why the thing in front of them is wrong.

Even when you decide to build custom, review the nearest standard model as reference architecture first: version management, workflow states, spreading logic, currency handling. Going custom does not mean starting from a blank canvas - it means implementing your process with proven patterns. Write down five patterns to reuse and three to explicitly reject, with reasons. That half-day is the highest-leverage review a project can run.

The hybrid reality: standard core, custom edges

Mature EPM estates converge on the same shape: a standard core (dimension conventions, versioning, currency, workflow, security scaffolding, load framework) with small, documented custom modules at the edges for the truly differentiating logic. The core stays close to vendor patterns so upgrades, new consultants and knowledge-base articles still apply; the edges are bounded by clean interfaces.

Two warnings from the field:

And a design note that connects back to cube design: even in a fully custom build, adopt the standard model's Version and Time dimension conventions verbatim unless there is a written reason not to. It keeps the door open to adopting standard content later as a mapping exercise instead of a rebuild.

Governance: stopping custom creep

Custom creep never arrives as one big request. It arrives as twenty small ones from power users after go-live, each individually reasonable, until the next consultant needs three weeks just to map what exists. The fix is boring and effective:

And when you must say no to a customisation, say it gracefully: acknowledge the need, reprice the request in lifetime terms ("four days now, plus two days every upgrade, forever, plus one person who must always understand it"), and offer a reversible path - run the standard pattern for one full planning cycle, then revisit with evidence. Most customisation demands evaporate after one cycle, because they were anxiety about change, not requirements.

The one-sentence policy

If you keep nothing else, keep Microsoft's line, which compresses the whole debate into seven words: "adopt wherever possible, adapt only where justified." Sequence it, don't ideologise it: exhaust configuration first, then marketplace content, then extensions alongside the core, and true custom last - decided per process, in workshops, with your process maps on the table.

The standard content gets you live quickly. How you handle the last 20% decides how well the solution holds up over the years. And whichever way each requirement lands, the delivery approach that makes the answer survivable is the same - start small and scale deliberately. More on that in the delivery post.

Back to all posts