My approach
Not a report. Change that holds.
Consulting that ends in a document changes nothing. My approach connects disciplined analysis with work alongside the people who actually run the process, until the change becomes routine.
Principles
Six points that guide every engagement
I look at the system as a whole
A problem that shows up in the warehouse was usually born in procurement or planning. I examine the whole chain before recommending a local fix.
I involve whoever runs the process
A solution written without the people who will carry it out will not survive its first week. They know where it gets stuck — and usually why.
I stay through the rollout
Support does not end when the plan is handed over. I stay in the picture during implementation, when the gaps nobody could foresee show up.
I check the data and the reality
Numbers tell half the story. The other half only appears when you go down to the floor and watch how the work is really done.
I set priorities
Not every gap is worth fixing. I separate what affects the business result from what is merely irritating, and start with the first.
I build a mechanism for improvement
The goal is for the organisation to keep improving on its own. So every engagement ends with measures and a control routine that stay behind.
The process
Four stages
01
Diagnose
Learning the organisation, the floor, the data and the business challenge.
02
Design
Setting priorities, a solution and a plan that can be carried out.
03
Implement
Connecting the parties and supporting the change as it happens.
04
Control & improve
Measuring results, correcting gaps and embedding a routine that holds.
How long does the diagnosis stage take?
It depends on the scope and on how many parties are involved. A focused diagnosis of a single process is considerably shorter than a diagnosis of an entire supply chain. In the intro call we define the boundaries together, and with them the timeline and the cost.
We already know what the problem is. Can we skip to design?
Sometimes, yes. If there is an earlier diagnosis, or the problem is well defined and backed by data, I can start at the design stage. But I will not skip it merely to save time — a solution built on a wrong diagnosis costs far more.
What happens if the teams resist the change?
Resistance is usually information, not an obstacle. In most cases it points to something in the design that did not account for reality on the floor. That is why I involve the teams from the diagnosis stage rather than presenting them with a finished plan.
Do you carry out the change, or only recommend it?
I stay through implementation. How closely varies with the project and with the organisation's own capacity to lead it — from hands-on support to a periodic control routine. That is agreed up front.