Diagnosis-First ERP: What Does the New Way Look Like in Practice?

The first three articles in this series built a mechanism: the man-day model had to sell diagnosis cheaply because it priced inputs; and once AI made mechanical work cheap, the quality of the decision became the only real differentiator. One question remains: what does that mechanism look like inside a project? This article does not ask a new question — it describes the sequence. How does a diagnosis-first ERP journey proceed, step by step?

The Five Steps of the New Way

1. Measure: Before watching a demo or collecting proposals, put numbers on the current state — how much of your processes is documented, how clean is the master data, who owns which decision. Without measurement, every following step rests on guesswork.
2. Diagnose: Turn the measurement into a finding. "Inventory accuracy is low" is an observation; "post-count correction entries cluster in this warehouse, in this product group" is a diagnosis. Diagnosis tells you which problem is worth solving.
3. Write the criterion: Write the project's definition of success before it starts, with a number and a date. "Go-live" is not a success criterion; "month-end close drops from five working days to two" is. The criterion must be verifiable independently of the vendor.
4. Sequence phases by dependency: Let technical dependency — not departmental appetite — determine phase order. If a phase cannot work without the output of the one before it, that order is not open for negotiation.
5. Tie acceptance to evidence: At the end of each phase, the record should not say "it works" but "this scenario, with this data, was run by this person and passed." If acceptance is not tied to evidence, the handover meeting turns into an argument.

The Old Way vs. the Diagnosis-First Way

The two ways do not perform the same work in a different order; they make different decisions at different levels of knowledge. The difference is clear in a table:

Not a Product Name — a Capability Category

The most visible consequence of the diagnosis-first way is that product selection moves in the sequence. The decision is not made with a brand name but with three parts: which capability, by which criterion, under which precondition. "Bill-of-materials management" is a capability category; "can revision history be kept on a multi-level BOM?" is that category's criterion; "product master data must be de-duplicated first" is its precondition.

That triple also generates the questions to put to the vendor — and those questions become the skeleton of the specification. The brand question does not disappear; it moves to the end. Whether a product is the right choice only becomes an answerable question once capability and criterion are written down. In projects that run the other way around, the specification ends up written backwards from the feature list of the product already chosen.

Phase Order Is Set by Dependency

In most projects the phase plan is negotiable: which module opens first is decided by departmental appetite or the vendor's delivery schedule. In the diagnosis-first way that order is a technical constraint. A few concrete examples:

• Manufacturing execution cannot be built before the bill of materials and the work-order flow work — execution consumes the BOM's output.
• Costing produces no meaningful result before stock movements are recorded correctly; cost is a derivative of movement.
• Sales reporting is not reliable before customer and product master data are de-duplicated — duplicate records corrupt the report silently.

When these dependencies are violated the project does not stop; something worse happens — a phase built in the wrong order appears to work, and the problem only surfaces once data accumulates. Tying phase order to dependency prevents that delayed failure up front.

Acceptance Is Tied to Evidence

The most expensive moment in a project is the handover meeting: the argument between "this was in scope" and "this is extra development" decides which side gets the invoice. The only way to pre-empt that argument is to tie acceptance to evidence from the start.

In practice this means recording the outcome of every acceptance scenario not merely as pass/fail but, when it fails, classified by cause — missing configuration, missing data, an out-of-scope request, or a genuine defect? Those four causes invoice four different parties. Next to it goes the name of the person who approved. Without classification, every "failed" record falls into one pile, and at the handover meeting who is right becomes a matter of who speaks loudest rather than what was recorded.

Where Do You Start?

The first of the five steps is measurement — and measurement has a starting point of its own. To see your own project's risk profile you can use the 10-question ERP Risk Score assessment: process maturity, executive ownership, change management, data quality, internal resources, scope clarity, budget realism, customization appetite, timeline and team experience — ten dimensions, scored with their weights, placing you in one of four risk bands. The result is an estimate, not a diagnosis: it tells you where to look, not what to do. But it gets the first of the five steps behind you.

This is the fourth and final article of a 4-part series.
1. Is the End of Man-Day Consulting Near?
2. An X-Ray of AI Promises
3. What AI Made Cheap in ERP, and What It Made Valuable
4. Diagnosis-First ERP: What Does the New Way Look Like in Practice? (this article)

To not miss new analyses, subscribe to the MindDX-Digital Excellence newsletter.