A system bought to solve a problem nobody wrote down will be assessed, years later, against an outcome nobody agreed to.
Ask the leadership team to trace one ordinary decision from beginning to end. Not a strategic decision — an ordinary one. Raising a customer's credit limit. Confirming a delivery date to a client who will commit their own capital on the strength of it. Follow it from trigger to record, and count the systems of record it crosses.
Most executive teams cannot answer without checking, and the checking takes days. That is the finding, before any analysis begins. Each crossing is a point at which the decision waits, is re-entered, is reconciled, or is taken against a version of the truth another system has already superseded.
The standard defence of the resulting estate is familiar and, on its face, reasonable: no single system solves every problem, so large organisations run several. That is true. It is also a confession. An estate of several systems is rarely a deliberate decision to run several; it is the residue of a sequence of purchases, each defensible on its day, each defining the problem narrowly enough to fit the budget then available and the function then complaining loudest.
Which produces the question this article is about. Was the system selected to solve a defined problem, or was the problem defined by the shortlist?
The Strategic Context
Enterprise systems are among the largest discretionary commitments an organisation makes outside physical assets and acquisitions, and they are unusual in one respect governance rarely accommodates: they are approved once and paid for indefinitely. Capital expenditure returns to the board through depreciation, asset reviews and replacement cycles. A subscription renews by default — an allocation decision made once and honoured forever unless someone actively re-opens it, and re-opening it is nobody's key result area.
Vendors commonly price these arrangements against the size of the buying organisation rather than usage or benefit delivered — a defensible model, but one in which the fee tracks the buyer's growth rather than the buyer's outcome. What a supplier's price is actually built on deserves examination of its own [Related article: Do You Know Your Suppliers' Costs, or Only What They Charge You?]; this article stops at the licence.
The second structural feature is governance scope. The implementation is a project, with a start, a finish and a completion report. The change in how the organisation works is a programme, carrying dependencies, adoption risk and benefits that arrive after the project team has gone. The accumulated estate is a portfolio, with opportunity costs no single business case can address. Most organisations govern the first with rigour, the second with optimism, and the third not at all.
The Confession Inside the Standard Defence
The claim that no single system solves every problem is usually offered as reassurance. Read carefully, it is a diagnosis of how the estate was assembled.
Had the organisation specified its problems precisely, it could have allocated them deliberately across a small number of platforms with defended boundaries. Instead each function specified its own problem in its own terms, funded its own selection, and bought a system whose scope ended where the vendor's product ended. Every one of those decisions was rational locally. An estate is what local rationality accumulates into.
Two further misreadings follow from the same root.
The first is that integration is a technical matter to be handled after selection. It is not. Integration cost is fixed at selection, by where product boundaries fall relative to where decisions actually travel. By the time a technical team is asked to connect two systems, the expensive choice has been made by someone else.
The second is the belief that a system will impose discipline where none exists. A system encodes a process. Where the organisation has not defined its own, the system encodes an assumption drawn from the vendor's other clients — and the organisation discovers, months after go-live, that it has adopted an average of other people's operating models without debating whether that average suits it.
Reframing the Issue
The useful reframe is straightforward and uncomfortable to live with. Procurement is not the first step in solving the problem. It is the last step in defining it, and it should not begin until the definition can be tested.
A definition is complete when four things are agreed in writing. Which decisions improve, named specifically. How often each is made, and what it currently costs in elapsed time, rework or error. What information it requires, and where that lives today. And what degree of improvement would justify the whole-of-life cost — settled before any vendor is contacted, because a threshold set after the demonstration is not a threshold.
Organisations resist this because the pressure to act is real, usually generated by a visible operational failure that makes buying feel like responding. But the alternative to a fast purchase is not a slow one: it is a fast definition, achievable in weeks by people who already know the answers, followed by a selection that produces a specification a vendor can be held to.
What an Un-Integrated Estate Charges, and Who Pays It
The costs of fragmentation are real, recurring and never assembled into a single figure any executive owns. Some are visible if anyone looks: interface maintenance, reconciliation effort at every period close, duplicated master data and the time spent arguing over which copy is authoritative, and licences retained because something still depends on them. Irritating, but tractable.
The larger costs are structural. The first is decision latency: where a decision crosses several systems of record, its speed is set by the slowest reconciliation in the chain, and that delay is paid on every instance, indefinitely. The second is the cost of change — any new capability must be built as many times as there are systems that touch it, each build carrying its own testing and risk of divergence. The third is optionality: an estate quietly determines which strategies are feasible, and one requiring a unified customer view cannot be executed where customer identity differs across four systems, whatever the strategy document says.
Melvin Conway's observation that systems come to mirror the communication structures of the organisations producing them applies with force here. An estate assembled function by function encodes those boundaries into the technology and makes every cross-functional decision permanently more expensive. The organisation chart of a decade ago is still charging rent.
Not all of that estate carries competitive weight. Much of it is infrastructure no customer values and no competitor is losing to, where sole ownership is a choice rather than a necessity — including whether it might be held jointly with a rival [Related article: When Sharing Infrastructure With a Competitor Is the Right Call].
The Process You Never Wrote Down Is the One You Are Buying
There is a reliable predictor of implementation difficulty that costs nothing to test. Ask whether the organisation can describe in writing the process the new system is meant to carry — where it starts, where it finishes, what enters and leaves it, and who is accountable at each handover.
Where that description exists, configuration is a translation exercise. Where it does not, configuration becomes an act of invention performed by consultants under time pressure, from whatever they can extract from whoever is available that week. The organisation has outsourced the design of its own operating model to contractors who will leave, and will encounter that design only through its consequences.
This is also where dependency on individuals is relocated rather than removed. Organisations often buy systems to reduce exposure to key people leaving; what usually happens is that the dependency changes address, from those who knew how the work was done to the few who know how the system was configured and why. Left undocumented, the knowledge risk has changed shape, not size.
Consider a hypothetical illustration. A mid-sized manufacturer configures its demand planning logic around a definition of "committed order" supplied verbally by two planners in a workshop. Neither is present three years later when the business asks why inventory persistently overshoots in one product family. Nobody can say why the rule exists, so nobody will change it. The example is invented; the failure mode is ordinary.
Benefits Without an Owner Are Forecasts, Not Commitments
Business cases for enterprise systems are approved on benefits. Few of those benefits appear in any executive's targets afterwards.
The test is unsentimental. For each claimed benefit, name the accountable executive, the baseline measured before the change, the date it is expected, and what happens to that person's assessment if it does not arrive. Where all four exist, the benefit is a commitment. Where any is missing, it is a forecast — and forecasts do not defend themselves in the resourcing arguments that follow go-live, when the project team disbands and operational pressure returns.
Baselines deserve particular attention: they are the element most often skipped and the only one that cannot be recovered later. An organisation that never measured its decision cycle time, error rate or rework volume beforehand forfeits any ability to demonstrate improvement, and is left asserting benefit — which reasonably invites the suspicion that none occurred.
Decision Framework
These gates sit before vendor engagement, not after. Each is a test the organisation applies to itself.
| Gate | The question it settles | Evidence that satisfies it |
|---|---|---|
| Problem definition | Which decisions improve, how often are they made, and by how much must they improve to justify whole-of-life cost? | A decision inventory with cycle times and failure rates, baselined before any vendor is contacted |
| Process ownership | Who owns the end-to-end process this system will encode, across functional boundaries? | A named accountable executive whose assessment changes if the process does not improve |
| Estate position | What does this add to, replace or duplicate in what we already run? | A current-state map of the systems of record the affected decisions touch, plus a decommissioning commitment |
| Whole-of-life cost | What does this cost over the full term, including interfaces, reconciliation and future change? | A cost model covering the licence term and the integration estate, not the project |
| Reversibility | If this proves wrong in three years, what does exit cost and how long does it take? | Contracted data extraction rights, exit terms, and a tested estimate of switching cost |
A proposal that cannot clear the first gate should not reach a shortlist, however urgent the operational pain. One that fails only the fifth may still deserve approval — but consciously, as a long-duration constraint on freedom of movement rather than as a procurement.
From Strategy to Execution
The immediate work is diagnostic and cheap. Trace three or four commercially significant decisions across the estate, as described at the outset, and publish the count. Name an owner for the estate as a whole: a role with standing authority over what may be bought, not a technical function consulted after the money is committed. Neither step requires capital, and both change what the next business case has to survive.
The medium-term work is capability building, and the part most often deferred. Two capabilities matter most: specifying a process end to end across functional boundaries, and holding enough internal configuration knowledge to change the system without a vendor engagement each time. Without the first, the organisation keeps buying against vague requirements. Without the second, every later operational improvement becomes a procurement.
The long-term positioning question is architectural. An estate can be allowed to accumulate, or deliberately layered — a small number of systems of record with defended boundaries, everything above them treated as replaceable. The second costs more and preserves the ability to change direction. Sequencing is its own discipline, and internal readiness is only half of it, since a go-live is also a claim on the attention of customers and partners who did not ask for it [Related article: Are You Timing to Your Own Readiness, or Your Customer's?].
Signals to Monitor
Watch for the number of systems touched by a single decision rising rather than falling after an implementation — a reliable sign the new system was added to the estate rather than into it. Watch for reconciliation effort at period close growing while finance describes it as normal, and for shadow tools: spreadsheets, local databases and messaging threads carrying decisions the estate cannot support, the most honest available measure of the gap between the system bought and the outcome required.
Watch for benefit claims that change definition between the business case and the first post-implementation review, and for change requests that increasingly require vendor involvement, which locates configuration knowledge outside the organisation. Externally, vendor consolidation can alter the roadmap, pricing and support model of a system the organisation cannot readily leave.
Questions for the Leadership Team
- How many systems of record does one ordinary commercial decision cross today, and who is accountable for reducing that number?
- For the last enterprise system we approved, can we produce the written problem definition and the improvement threshold that existed before the shortlist was drawn?
- Which named executive's assessment changes if the benefits in that business case do not arrive, and against what baseline will arrival be measured?
- What is the whole-of-life cost of the current estate, including interfaces, reconciliation and systems retained only because something depends on them — and which could we exit within twelve months?
- Which strategies we have discussed are not currently executable because of how our systems are arranged, and has anyone said so out loud?
Closing Perspective
The decision that matters is not which system to buy. It is whether the organisation will define its own problems precisely enough to hold a supplier to an outcome, and hold itself to the process changes that make the outcome possible.
That preparation is uncomfortable, because it exposes ambiguity the organisation has lived with productively for years: who really owns a process, what a decision actually costs, which numbers are authoritative. A purchase can be made without resolving any of it — the system will be installed, the project will close, and the ambiguity will be encoded rather than removed, at which point it becomes far more expensive to address.
An estate is a record of decisions. Read years later, it shows plainly whether an organisation bought systems or bought outcomes, and the difference is paid every month by everyone who has to decide anything inside it.
About the author
Kevin Jogin is Founder & Principal Advisor at EraNorth. Meet the Founder.