Why aren’t the laws of lean articulated?
Dear Gemba Coach,
Aren’t there laws of lean, just as there are laws of physics? And why aren’t these clearly articulated yet?
This is a very intriguing question and you’ll have to bear with me if my answer is not as straightforward as one could wish – my doctoral background is in “knowledge sciences” (whatever that is), and the question you’re asking is not as simple as it sounds.
There ought to be laws of lean, surely, and I feel as you do. But there is a drinking game we’ve played with LEI CEO John Shook – for every lean “law” I propose, he finds an opposite law that would work just as well. For instance, I’d say something like I feel is self-evident such as: “lean thinking is a process (how do we make this leaner) not a state (Are we lean yet?)” John counters that “lean thinking is a worldview that entails holistically grasping the dynamic (never static) relationships between process, people, and purpose and moving them into balance,” and so on. It’s hard to dispute either, but it’s also hard to come to any general conclusion.
I’ve been thinking about this long and hard and my hunch that our very looking for laws of lean reflects a profound misconception. The two founding concepts of lean were (1) to increase production efficiency by consistently and thoroughly eliminating waste and (2) to respect humanity by developing every worker to his or her full ability. The basic methodology is “the lake and the rocks” – by reducing the lead-time, waste appears. By solving the problems and eliminating the waste, the timeline from customer order to collecting cash is reduced, and hence production efficiency is improved.
Waste is created by human beings – that’s Taiichi Ohno’s core intuition. People’s misconceptions about efficiency make processes wasteful. Actually, it’s not so much that there are efficient processes versus inefficient processes in absolutes, but that circumstances change and that efficiency is contingent on people and technology. For instance, I was last week in a plant that makes a wide range of rather simple products (a few components to assemble to a casting body). Assembly of one product typically takes from a few seconds to a few minutes by a skilled operator according to the type, but the products vary in size from the hand-held variety to the several tons kind. The factory floor therefore looks like a schoolroom arrangement of single-product, single operator workstations (too few operations to make lines worthwhile and too many product differences to have standard stations).
It makes sense when you think about it. As a new product is put on the market, demand is high, so it’s easy to occupy one operator all day long building the new product. But, when the product starts to lag, or the market turns sour as it is at the moment, what happens is that an operator will do the day’s production in a few hours, sometimes less (or, conversely, several weeks of sales in a few hours of production). As a result, one operator will move from one station to another several times in the day – which is massively inefficient, as each change entails significant loss of time (up to twenty minutes to finish with one station, with clean up and etc., and starting up at the next station).
By thinking about takt time and single-piece flow, we quickly realized that if we could have an operator build enough products on one station without leaving the station and without overproducing, the productivity gain would be massive. The issue now becomes to be clever about redesigning work stations to be able to build a wider range of products, which requires a lot of collaborative head-scratching and working with the operators themselves. It’s all contingent. In a situation where demand is high, it’s smarter to have one station per product working at full speed. In a situation where demand is low, it’s worth hassling with multi-product stations so that operators don’t move around so much during the day.
Arguably, a multi-product cell is better because a larger basket of products should absorb better market variations than a single-product cell, but, let’s face it, a mutliproduct workstation is not likely to be as efficient or ergonomic that a single-product station (until we get MUCH better at solving many intractable process engineering issues). The issue here is whether we seek to (1) apply a law, as in “thou shalt produce in single-piece-flow” or (2) develop people by using single-piece-flow to reveal the kind of waste they tolerate in the systems they’ve created. Again, products are made by people for people, with people. I can’t think of any natural law that is applicable where so much people are involved. The only certain thing about statistics is they don’t apply at the individual level, and reality is contingent.
Bag of Tools
The purpose of lean techniques is to reveal waste, not to create the perfect process – which, by the way can’t ever exist since something can always be improved. The test of good visual management is to be able to see at one glance whether we are in a normal or abnormal situation. All lean tools tend towards that, from pull just-in-time tools (ahead or late compared to customer demand), to andon and jidoka tools (operation is OK versus not OK), to kaizen and standards, seeking to understand causes always in greater detail and depth. At the end of the day, the lean tools are essentially a bag of tricks to test production as it happens – the “confirmation method” essential to any hypotheses-testing analysis.
However, your question raises a deeper point. Scientific thinking appears when rather than trying to solve the problem, seeing whether it works, trying something else if it doesn’t and doing so until we’ve cracked it and we move on, we explore several distinct hypotheses in parallel and confirm them regardless of whether the problem has gone away or not -- this is the essence of set-based concurrent engineering, a unique lean engineering technique.
So far, my understanding of lean has hinged on the notion that “in order to make products, you have to make people.” In my work with companies, I have hitherto focused on (1) people development – knowing how to best use the equipment we have to produce good parts and (2) machine development – continuously improving equipment and automation to support people in producing the best parts. I had completely missed the importance of the test methods in the development of knowledge. In most high-tech companies, we find a number of test and calibration tool, but we’ve never looked at them as other than linked to the process. Recently, I’ve started taking a closer look to the development of measuring tools as well, and the impact on process understanding has been surprisingly quick and significant. Although I make TPS veterans smile with my newest discovery (it just sounds obvious to them – they’ve been practicing jidoka all along) I now look at three development programs to improve the overall process:
To return to your question, overall, I suspect that seeking laws is about seeking permanence, whereas lean thinking is about seeking adaptability. Laws are reassuring because we have such trouble with accepting that things change all the time: life is not always fair, the goal posts move and there are no guarantees. There may be “laws” of lean thinking, and yes, one-piece-flow or stop-at-defect might be more effective in absolutes to any alternative. Whether this is the case or not, I believe this is a rather fruitless path to develop our understanding of lean. The question should rather be how well we master our current test methods, and what does this tell us about technical and human processes we did not see before. The questions we ask define our reality, so, in the poet’s terms, we’ve got to learn to love the questions.
Is my crazy new boss right that applying standardized work is the foundation of lean?
Dear Gemba Coach,
My new boss is a lean fanatic crazy about standards. He’s created a new team to audit standards and is telling us that applying standardized work is the foundation of lean. It’s creating a lot of resistance, and I don’t know what to make of it.
Can 5S apply to coding?
Dear Gemba Coach,
We’re exploring lean in software development. Can 5S apply to coding?
Isn’t there a better way to manage inventory than just-in-time?
Dear Gemba Coach,
This is 2019. Isn’t there a better way to manage inventory than just-in-time by now?