Chicken or egg: standard ERP first, or deep customisation first?

The answer is usually stated as a principle, and a principle is hard to argue with and equally hard to believe. This piece turns it into money, and names the three numbers it stands on — set all three to zero and the paths cost the same.

Every ERP project reaches a moment where the order has to be decided: put the standard system into production first, or customise it deeply around each department and only then go live?

The answer is usually stated as a principle — build the standard spine first, kaizen each department after. But a principle is hard to argue with and equally hard to believe. This piece turns it into money: what does the wrong order cost, and exactly which three numbers is that claim standing on?

1. Three traps in "customise deeply from day one"

When the project team tries to please every department by copying the old habits onto the new software:

Automating the chaos. If the underlying process is not standardised, the item master still holds duplicates and the posting rules are still vague, deep customisation is just using technology to digitise a wrong process. The new system will produce errors faster and at larger scale.

Breaking data integrity. A feature tailored for sales can make a salesperson very fast while quietly skipping a posting constraint, breaking accounting's document flow, or corrupting available stock. Optimising locally in one department usually creates a blockage somewhere else. This is what the first piece called fragmented data — except here the company manufactures it itself.

Technical debt. Hundreds of lines of customisation written in a hurry before go-live turn the system into a patchwork. It cannot be upgraded, maintenance costs climb, and the failures that appear are the quiet kind.

2. The three-layer model

This section was written by the editor from the principle the source states — the original stops just before presenting the three layers. It is an interpretation, not the author's own words.

The three layers have to be finished in order, because each one only stands on the one beneath it.

1. A standard core that runs. Clean masters, clear posting rules, and at least one document that closes a full cycle from creation to report. Without this layer everything above it is built on sand. The target here is not "elegant" — it is "runs, and is correct".
2. Standardise how the work is done. One point of entry per kind of information, no spreadsheets running outside the flow, one agreed way of naming and classifying. Few people enjoy this layer because it touches habits, but it is what decides how much layer three costs.
3. Department-level kaizen. Now customise — but by this site's standard: measure first, change second, in waves, each wave carrying its own measurement. The three previous pieces here are all examples of layer three, and none of them would have been possible without layer one running.

The most interesting thing about this order is not technical: a meaningful share of the "must-have" requests evaporates after a few months on the standard core. Not because anyone won an argument, but because once real work flows through a real system, users discover that what they demanded at the start is no longer necessary. Customising first means paying for those too.

3. Putting a number on it

The difference between the two paths sits in four lines, and only the customise-first path pays them:

The fourth line is the one most often forgotten, because it never appears on an invoice. But five months of not being live is five months in which the business receives nothing at all, while still paying the project team.

And here is where honesty is required: the whole argument sits in three numbers — the rework share, the evaporation share, and the months of delay. Set all three to zero and the two paths cost exactly the same. The estimator above lets you do that. If all three genuinely are zero in your business, the order stops being a money question and this piece does not apply to you.

4. The real answer: do both at once

Framing this as "standard first or customise first" is the wrong question, and it is wrong in a way that costs money. In practice the cheapest path is to stand up the standard core and, at the same time, customise deeply for a few operationally decisive steps — a few, and genuinely decisive.

The reason is behavioural rather than technical: a system missing the one step people live by will not be used. Nobody objects out loud; they quietly reopen the old spreadsheet. The company then pays in full for a system while still running on the old tool — a loss that appears on no invoice and is nonetheless real and measurable.

What makes a step "operationally decisive"

Three marks, and it needs all three:

1. It sits on the daily path of money or goods, not on a month-end report.
2. Without it the user has a way around — and that way around is cheaper than using the system.
3. Configuration cannot fix it, meaning the settings have already been tried and did not get there.

If a request fails any of the three, it belongs to layer three and it can wait. Most "must-have" requests fail this test — which is precisely why a meaningful share of them evaporates after a few months.

In practice the count is small: a few steps, not a few dozen. If your "operationally decisive" list runs to twenty items, it has almost certainly not been filtered, and you are on your way back to customise-everything-first under a different name.

Three paths, measured side by side

The estimator above compares all three on one horizon. On the default assumptions the both-at-once path is cheapest — but the striking part is that it beats standard-only by a small margin, while beating customise-everything-first by an enormous one. In other words: choosing wrongly between "standard only" and "both at once" is a small mistake; choosing customise-everything-first is the expensive one.

And the honest part: if skipping the decisive steps costs nothing — set the lost-benefit share to zero — then standard-only is cheaper than both-at-once, exactly as it should be. The entire case for building a few things early rests on people routing around a system that lacks them. If that is not true in your business, do not build them early.

5. When this order is wrong

Every principle has a region where it does not hold, and naming that region is the only way to make the principle trustworthy:

• When the standard core cannot run the core business at all. In some industries, without one specific flow the system cannot post a single valid document. Then that flow belongs to layer one — it is foundation, not customisation.
• When a legal constraint forbids running an approximation. Invoicing, tax, regulated industries: there is no going live with a version that is nearly right.
• When the customisation is cheaper than the argument. A small, clear change that touches no ledger and removes a whole department's resistance — just do it. All three earlier pieces here are of that kind.

The order is not a question of discipline, nor of architectural correctness. It is a question of money: get it wrong and you pay for customisations the people who asked for them will stop wanting, and you pay in months during which nobody received anything.

The figures here are illustrative and are not taken from any client's system or project. Replace them with your own in the estimator above.