Most ERP projects start unmeasured: readiness is guessed, scope is assumed from interviews, decisions hinge on a consultant. The result: overruns, needless modules, unadopted systems. There is a better way.

What we see

The enemy: transforming blind

Blind start

Big-bang projects launched with no objective answer to “are we ready?”.

Assumed scope

Scope guessed from interviews, not data; surprises and needless modules erupt in UAT.

Person-bound knowledge

Every decision hinges on a consultant; knowledge stays in people and walks out the door.

Our convictions

Measure first. Then transform.

01You can't transform what you haven't measured. Every journey starts with a maturity measurement (DMI).

02Scope is not assumed, it's discovered. Real need surfaces through evidence, not interviews.

03Design on evidence, not opinion. Every design decision rests on the prior step's evidence.

04Knowledge must compound in the system, not in people. Every step produces a traceable artifact.

05AI drafts, an expert approves. AI does the repetitive work; a consultant reviews the critical calls.

06Transformation is not a project, it's ongoing maturity. The score is re-measured each release and climbs.

07Transparent pricing is trust. Modules sell at a published list price — no man-day surprises.

The method

From conviction to method: five steps

A stance is only worth as much as the sequence it turns into. These five steps are the backbone of every Smarty engagement — and their order is not a preference but a dependency: each step consumes the previous one's output.

Measure
Before watching demos or collecting proposals, put the current state into numbers: how much of the process is written down, how clean the master data is, who owns which decision. Without measurement every later step rests on a guess.
Diagnose
Turn the measurement into a finding. “Stock accuracy is low” is an observation; “which warehouse and which product group concentrate the post-count corrections” is a diagnosis. The diagnosis tells you which problem is worth solving.
Write the criterion
Write the definition of success before you start — with a number and a date. “Going 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.
Order phases by dependency
Let technical dependency set the phase order — not module appetite or the vendor's delivery calendar. If a phase cannot run without the previous phase's output, the order is not negotiable.
Tie acceptance to evidence
At the end of each phase the record should not read “it works”, but “this scenario, with this data, was run by this person and passed”. Where acceptance is not tied to evidence, the handover meeting turns into a debate.

The difference

Old way versus the diagnosis-first way

The two paths do not do the same work in a different order; they take the same decisions at a different level of information. The gap becomes visible when you look at it decision by decision.

Decision	Old way	Diagnosis-first way
Scope	At proposal time, with the least information	After measurement, based on findings
Product selection	First question: which brand?	Last question: which capability, by which criterion?
Phase order	By the vendor's delivery schedule	By technical dependency
Acceptance criterion	“We went live”	Written scenario + evidence + named approver
Weight of the budget	On setup and mechanical work	On diagnosis and decision quality
Owner of the risk	Entirely the customer	Shared, tied to the criterion

Decision

Old way

Diagnosis-first way

Scope

At proposal time, with the least information

After measurement, based on findings

Product selection

First question: which brand?

Last question: which capability, by which criterion?

Phase order

By the vendor's delivery schedule

By technical dependency

Acceptance criterion

“We went live”

Written scenario + evidence + named approver

Weight of the budget

On setup and mechanical work

On diagnosis and decision quality

Owner of the risk

Entirely the customer

Shared, tied to the criterion

Selection discipline

Not a product name — a capability category

The most visible consequence of the diagnosis-first path is where product selection sits in the sequence. The decision is made not with a brand name but with three parts: which capability, by which criterion, under which precondition.

That triad also generates the questions you 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 is a question that can only be answered once capability and criterion are written down.

A concrete example

Capability

“Bill-of-materials management” is a capability category.

Criterion

“Can revision history be kept on a multi-level BOM?” is that category's criterion.

Precondition

“Product master data must be de-duplicated” is that capability's precondition.

The long-form account of this approach — five steps, comparison and examples: Diagnosis-first ERP: what the new way looks like in practice

What this unlocks

From chaos to confidence

A measured start

You know where you stand and where to start by score, not intuition.

Less rework

When scope fits reality, surprises, needless modules and overruns shrink.

Adoption that sticks

Evidence-based design and role-based training make the system actually get used.

Frequently Asked Questions

About our approach

What does the “measurement-first” approach mean?

Before any software or licence, we measure the current state, processes and readiness on evidence. So transformation is planned from a numerical starting point, not guesswork.

Why organisation and interaction first, technology second?

Socio-technical research is clear: even the best technology isn't adopted if the organisation and its interactions aren't ready. We first simplify process, roles and interaction, then apply technology onto that ground.

Is Smarty software or consulting?

A blend: AI brings speed and consistency, an expert consultant checks and approves the evidence. The output is a human-approved report, not raw LLM.

Don't you sell a specific ERP/CRM?

Our approach is software-agnostic. We work with Odoo, Zoho and abas; but we first measure maturity and need, then recommend what fits — need-first, not product-first.

Is Smarty an AI tool?

No — Smarty is a measurement-first consulting platform that uses AI inside it. AI copilot tools start after requirements are gathered, and most need access to your live system to work. Smarty produces the requirements itself through structured multi-stakeholder discovery, frames them with maturity and readiness, and delivers consultant-reviewed reports — not raw AI text — while discovery never touches your data. It doesn't compete with AI copilots; it can even be used alongside them.

Get your X-ray — start free

Free Mini DMI Browse solutions →

ERP transformation would always be a gamble. We refused to accept that.