A blind start
Large projects launched without an objective answer to the question “Are we ready?”
Assumed scope
Scope is estimated in meetings rather than from data; surprises and unnecessary modules surface during acceptance testing.
Knowledge tied to individuals
Every decision depends on one person; knowledge stays with individuals and walks out the door when the team changes.
- 01
You cannot transform what you do not measure.
Every journey starts with a maturity measurement (Checkup); without it, every remaining step rests on guesswork.
- 02
Scope is not assumed; it is discovered.
The real need emerges from evidence, not from meetings.
- 03
Design follows evidence, not opinion.
Every design decision rests on the evidence of the previous step.
- 04
Knowledge should build up in the system, not in individuals.
Every step produces a traceable output; even when the team changes, what was done and why is not lost.
- 05
AI produces; people carry the responsibility.
AI speeds up repetitive work; the decision and the responsibility stay with people. The level of control depends on the output type: measurement reports go through consultant approval, and some documents are produced by an authorised user themselves.
Who controls what - 06
Transformation is not a project; it is ongoing maturity.
Maturity is measured again as the transformation continues; go-live is not an end point but a new point of measurement.
- 07
Scope first, then price.
The price of Implement is fixed once the scope validated in Assess has been written down; a written scope instead of open-ended man-days.
- 01
Measure
Before watching demos or collecting proposals, put the current state into numbers: how much of your processes is written down, how clean the master data is, who owns which decision. - 02
Diagnose
Turn the measurement into findings. “Stock accuracy is low” is an observation; “in which warehouse and which product group the post-count correction entries concentrate” is a diagnosis. - 03
Write the criterion
Define success before the project starts, in a measurable form. “Go-live” is not a success criterion; the criterion must be verifiable independently of the vendor. - 04
Order the phases by dependency
Let technical dependency, not module appetite or the delivery calendar, set the order of the phases. If a phase cannot work without the output of the previous one, the order is not up for debate. - 05
Tie acceptance to evidence
At the end of every phase, the record should not say “it works” but “this scenario was run with this data by this person, and it passed”. If acceptance is not tied to evidence, the handover meeting turns into an argument.
- MeasureCheckupMeasures digital maturity across the technology, process and leadership dimensions; the report goes through consultant review and approval.
- DiscoverDiscoverClarifies the real need through evidence-based discovery and turns it into a prioritised scope.
- DesignDesignAn installation plan, configuration steps and acceptance scenarios — tied to the scope and traceable.
- TrainTrainPrepares the team for the new way of working: role-based training documents and assessment questions.
- VerifyProcessVerifies with event data whether the transformation really works: by measurement, not by declaration.
- SustainSupportPost-go-live support based on the knowledge base of the product you bought.
| Decision | The old path | The diagnosis-first path |
|---|---|---|
| Scope | At the proposal stage, with the least information | After measurement, based on findings |
| Product selection | First question: which brand? | Last question: which capability, against which criterion? |
| Phase order | By the delivery calendar | By technical dependency |
| Acceptance criterion | “We went live” | A written scenario, evidence and the person who approved it |
| Where the budget goes | Installation and mechanical work | Diagnosis and the quality of decisions |
06Selection discipline
A capability category, not a product name
The most visible result of the diagnosis-first path is that product selection moves in the sequence. The decision is made not with a brand name but in three parts: which capability, against which criterion, with which precondition. The brand question does not disappear; it moves to the end.
Diagnosis first, in practice: MindDX Assess08Commercial principle
Your transformation should not be a blank cheque.
The scope is validated first, then the price of the implementation is put in writing; the core journey proceeds as Assess, Implement and Transform, and each step is a separate decision. What is bought, and how, is on the How we work page.
How we workA software-independent start
The measurement and discovery steps are independent of any solution: you start from your company’s reality, not through a vendor’s lens.
Human control, with its scope in writing
Measurement reports (Checkup and Audit) go through consultant review and approval; for the other outputs, who controls what is written in the assurance table.
Assurance tablePublished references
We work with manufacturing, distribution and engineering companies in Türkiye; our customers and their views are published.
CustomersWritten scope first
The price of Implement is given once what you will receive has been written down. A written scope instead of an open-ended man-day invoice.
FAQQuestions
Frequently asked questions
Before deciding on software or licences, we measure the current state, the processes and readiness with evidence. The transformation is then planned from a measured starting point rather than from estimates.
If the organisation and the way people work together are not ready, even the best technology may not be adopted. So processes, roles and interactions are made visible first; technology is applied on that foundation.
MindDX is a digital transformation company; MindDX Platform is its own product. AI brings speed and consistency; a person makes the decision and carries the responsibility. The level of control depends on the output type and is written in the assurance table.
Our approach starts independent of software: maturity and needs are measured first, and the product question comes last. The solution categories we work with are on the Solutions page; third-party licensing and the commercial structure depend on the software and the scope.
This page explains why we work the way we do. How we work explains what is bought and how the work proceeds: the Assess → Implement → Transform journey, plus Checkup, Process and Support, which can be bought on their own.
Start your own transformation by measuring it.
Measure where you stand, validate the scope with evidence, then decide.