MindDX Process
Process measurement and improvement, delivered with partner technology and guided by a consultant.
MindDX Transform
Go-live is not an end; it is a new measuring point.
Measure, improve and sustain the live system. Scope and duration are set together.
Process / Support — as needed.
How continuous improvement works
Until go-live, how the system would be used was an assumption; after go-live it is data. Transform is reading that data regularly and building decisions on it — not more consulting hours, but measurable improvement.
- 01Measure — How processes actually flow is derived from the system's own event records, instead of assuming they flow as designed.
- 02Separate — Each deviation is classified: a genuine business need, a training gap, or a badly designed step.
- 03Improve — Only what passed that separation gets changed. Turning every deviation into a customisation permanently raises the cost of every future upgrade.
- 04Verify — The effect of the change is read again with the same measure; the improvement is recorded as a measurement, not a claim.
This loop does not start automatically and has no fixed duration; how often each step runs is decided in the conversation.
Components
MindDX Support
The contracted support team knows your setup; the Support Copilot answers self-service from the knowledge base of the product you bought. No tickets are opened automatically.
What we do not publish
- A fixed Transform package
- A standard Transform price
- An automatic 12-month Support
- Process included automatically
- Automatic continuation after go-live
One sentence stands in their place: scope and duration are set together.
Frequently Asked Questions
About the products
Does Transform start automatically after go-live?
No. Neither Process nor Support is an automatic continuation; scope and duration are set together. We publish no fixed Transform package and no standard duration.
How do you run continuous improvement after an ERP go-live?
Go-live is not an ending but the first real measurement point: until then how the system would be used was an assumption; from then on it is data. Continuous improvement is four steps, repeated. (1) MEASURE: derive how processes actually flow from the system's own event records, instead of assuming they flow as designed. (2) SEPARATE: decide which deviations are a genuine business need, which are a training gap, and which are a badly designed step. (3) CHANGE: change only what passed that separation — turning every deviation into a customisation permanently raises the cost of upgrades. (4) RE-MEASURE: verify the effect with the same measure. Step two is the one most often skipped, and when it is, improvement ends up following the order of user complaints. At MindDX the measurement is Process's work and post-go-live questions are Support's.
How do you measure whether an existing ERP system needs improvement?
There are two different questions, and confusing them leads to the wrong investment. The first is "was the system set up correctly" — assessed through configuration, unused modules, accumulated customisations, master-data quality and user adoption; its output is a prioritised action list. The second is "how do the processes actually flow" — measured not by questionnaire but from the system's own event data, showing variants, bottlenecks and rework loops. The first tells you the health of the installation, the second the health of the business; neither substitutes for the other. In practice the order matters: process deviations measured without knowing the installation's health usually turn out to be symptoms of a configuration fault. At MindDX the first is Audit and the second is Process.
How is process mining used in an ERP transformation?
Process mining derives the real flow of processes from the system's transaction records: which variants exist, where waiting builds up, which steps get repeated. In an ERP transformation it helps in three places. BEFORE: it shows today's flow as it actually happens rather than as documented — so the scope discussion runs on data instead of assumption. DURING: it shows early the gap between the flow as designed and the flow as running. AFTER: it verifies the effect of an improvement with the same measure. The precondition is data: every step needs an identifier, a timestamp and an event name — without those three there is no analysis, which is why data suitability is measured up front. At MindDX the analysis is delivered with partner technology and consultant guidance; on Odoo the event log is extracted directly from your system, on Zoho and abas it is transferred with a standard template.
How can AI-assisted ERP support use a company's own context?
"Context" is not one thing, and which layer is actually used decides how useful an answer is. In practice there are four layers: (1) PRODUCT context — which system the question is about; (2) INSTALLATION context — that company's own configuration and customisations; (3) PROJECT context — design decisions and their reasons; (4) HISTORY context — what was asked before. A support tool should say which of these it reads, because two of them produce very different answers: a tool with product context only gives correct but general answers, while a tool with installation context can answer specifically for that company. MindDX Support uses product context today — which system it is comes from your purchase rather than being guessed from the message — and builds the answer from that product's knowledge base. It does not read the customer's installed system; when the knowledge base runs out it points to a support agreement instead of inventing an answer.