I’ve been coaching a Gemba Academy customer through the use of some specific tools.
This individual works in a MRO environment meaning he deals with very high mix and low volume.
This person is struggling to understand how to create a value stream map since their process is anything but static.
In other words, what takes 30 minutes today may take 3 hours tomorrow. So how do you document this sort of variability on a value stream map?
What problem are you trying to solve?
I did my best to explain that everyone deals with variability and that a VSM will never be a perfect snapshot of the process.
For example, traditional producers of widgets will experience the same sort of problem since there may be 110 units between process A and B today but only 92 units between process A and B tomorrow.
Which one should they document on their VSM? My thoughts? It doesn’t matter.
You see, the point of a VSM, or any “tool” for that matter, is to improve the process. It’s meant to help us solve a problem.
So, in this traditional producer example, the fact they’re obviously building in batches may, in fact, be the problem they should address.
In other words, attempting to construct a Monte Carlo simulation to model the variability in the process or spending days worrying about the exact figures we should note on a VSM is most likely a gigantic waste of time.
Remove the Handcuffs
Too often I see lean and six sigma practitioners handcuff themselves with tools.
They read a book about value stream mapping and then struggle with the concept since they don’t produce stamped-steel steering brackets with relatively stable demand!
So, instead of worrying about how a particular lean or six sigma tool can be used to improve your process start by asking yourself the following question – what problem am I trying to solve?
Go to Gemba
And, really, the only way you’ll be able to answer this question is by going to gemba, or the place the work is done, and observing.
So, until we know what problem we’re trying to solve, it’s best to forget about value stream mapping. Forget Quick Changeover. Forget 5S. Forget regression. Forget “tools” in general.
Instead, go to gemba, observe, and question.
Tools are meant to serve
In summary, lean and six sigma tools are here to serve us… not handcuff us.
So if you ever find yourself struggling to find a way to make a particular tool work for your situation take a step back and ask yourself… what problem am I trying to solve?
Do you agree?
Do you agree with my take on this? Have you seen people, possibly yourself, become handcuffed with lean and six sigma tools? If so, how did you handle the situation?