Method
Diagnosis before prescriptions
The same disciplined sequence sits behind every engagement, whether the result is a process change, a reconfigured tool, or a custom system.
-
Understand
Every engagement begins inside the operation: how work arrives, who touches it, what they rely on, and where it goes next. The version of the process that matters is the one performed on a busy day, not the one in the manual.
-
Diagnose
Symptoms and causes get deliberately separated. A late report is a symptom; duplicated data entry is a cause. A quiet CRM is a symptom; a system that demands work and returns none is a cause. Fixing symptoms buys weeks - fixing causes buys years.
-
Prioritise
Findings are ranked by operational impact against effort and disruption. Not everything found gets fixed first, and some findings should not be fixed at all - a judgement that is stated openly rather than buried in a long report.
-
Design
The practical improvement is designed at the simplest level that will hold: a process change, a responsibility with a name on it, a better use of a tool already paid for, or - where genuinely justified - a custom system.
-
Implement
Changes go into real use in a managed sequence the business can absorb while trading. Implementation is treated as part of the engagement, because a plan that stalls after the report has improved nothing.
-
Measure
Each change is checked against what it was meant to do. Honestly. Some changes need adjusting, and occasionally one should be reversed - finding that out quickly is a feature of the method, not a failure of it.
-
Improve
What was learned feeds the next round. The aim is for improvement to become a rhythm the business owns - not a dependency on any outside party, including Metrixan.
Try it
From symptom to cause
Pick a familiar complaint and trace it downward. The reflex answer and the real fix are rarely the same thing.
The monthly report is always late
Buy a dashboard tool - treats the symptom
The report needs data from three systems
Two of the systems disagree, so figures are corrected by hand
They disagree because the same customer is entered twice, differently
No single agreed source for customer records
Fix the record structure and entry rules; the report then largely assembles itself - with or without a new tool.
Principles
Positions the method takes
Why diagnosis comes first
Recommendations made before understanding are guesses with confidence. The first stretch of every engagement is spent establishing what is actually happening, because the visible complaint is usually the cheapest clue, not the answer.
Why software does not fix a broken process
Software amplifies the process it is given. Automating a process with unowned steps and unwritten rules produces the same failures, faster and at scale. Processes get repaired before they get automated.
Why simple solutions are considered first
The order of consideration is fixed: a process change, then better use of existing tools, then custom software. Many engagements end with fewer systems than they started with. Custom builds happen when the need is real - and then they are built properly.
How implementation stays controlled
Every change has an owner, a sequence, and a checkpoint. The business keeps trading throughout. Nothing is switched off until its replacement has been proven in real use.