Dear Gemba Coach,
Isn’t flow the ultimate aim of lean?
Personally, I feel that the aim of lean is to digest Toyota’s lessons about “achieving the complete elimination of waste in pursuit of the most efficient methods.” Flow is one aspect of this, but far from the only one – the TPS is a system.
What can we learn from Toyota’s progressive development of a system – all the way back to its founding? And what can we learn from our own misinterpretations of it?
When you go to the gemba, whether in manufacturing or in software development, the first instinct is to look for flow: Are the products flowing fast enough? Are the user stories flowing? Will we deliver on the sprint?
Flow is a brilliant technique for revealing problems – which then need to be resolved. The aim is not flow in itself … but the endless pursuit of better products through better thinking.But when you visit Toyota’s museums in Toyota City, it is striking that Sakichi Toyoda, the inventor, was obsessed with making better looms. He was not a cotton manufacturer – he was a loom engineer, working on both design and development. Much like the Toyota company now designs and manufactures cars. He was continuously redesigning his looms to eliminate muri – overburden – from their use. Design advances included:
- One-hand operation of the loom with a clever shuttle guide, that made work easier as well as improving quality by taking away unevenness (mura) in the weaving. It also increased efficiency by half (https://www.toyota-industries.com/company/history/toyoda_sakichi/)
- Automatic shuttle-changing mechanism with enabled continuous operation of the loom at high speed
- Self-stopping loom when a cotton thread broke to avoid producing defective yarn – and freeing operators from having to watch the machine operate: it would stop in case of a problem, thus inventing “intelligent automation.”
Sakichi Toyoda continuously worked with his employees to design both better looms and better ways of making looms. He didn’t see the difference. In that sense, his aim was to design out muri (overburden), mura (stop-and-go) and muda (waste) from both product and process. The lesson here is quite complex:
- Consider what aspect of your product can be improved to make it easier to operate for customers,
- Assemble the product to exacting standards and then simplify operations through incremental kaizen,
- Evolve the assembly process until anyone can operate it safely while producing quality work. As this process is repeated work becomes simpler and less expensive – as well as easier to adapt flexibly.
These early principles can be captured by the techniques of VA/VE: value analysis and value engineering:
- Value analysis is about building on kaizen ideas about better making products in production now to design out issues and 1) improve the product through 2) smoother work.
- Value engineering is about drawing from these learning experiences the lessons to integrate into next-generation products and processes to continue to improve customer usage whilst reducing total cost.
If you ask me what lean really is, it is about systematically eliminating waste from products and production through kaizen – and believe me, we need it. For instance, watch this great video about improving a food bank operation: https://www.youtube.com/watch?v=EedMmMedj3M
The first improvement is improving the product – i.e. reducing the box to make it easier to handle for customers (you see them later fitting the box in their carts) and not shipping so much air. Then the production process is improved through, yes, flow. But the first step is to production/process improvements.
Three Hard Lessons
The first lesson of lean is constantly listening to customers and watching how they use the product or its alternatives to get a job done and strive to make it easier both to use and to produce.
Related to this, the second lesson of lean is about jidoka or building-in quality. In the West, we separate engineering and delivery. We ask engineers to design a product, and then production has to somehow make it work. In production, the same happens. Production puts it together and then quality inspects the result; okays it or not. Basically, the next step in the value flow is quality for the upstream step; the quality function accepts it or not – and then rejects it or asks for rework.
This is incredibly wasteful.
The hard lesson of studying the TPS is to learn to move the quality checks as far back into the process as possible to check quality where the operation is produced. This requires a complete mental turnabout on how quality is produced. Defects are not made by magic or divine intervention – they are made. Defects are put into the product.
Unknowingly, maybe, but made all the same. When I say something false in this column, I either do so naively (not knowing that what I say is not right) or deliberately (choosing to simplify a point to make it easier to read). The question then is: Do I wait for readers to correct me? Or do I take on the fact-checking responsibility myself? And if the latter, how does that impact my writing technique?
This issue here is not just of technique, but also curiosity and courage:
- Curiosity: Am I curious to find out where the problem is inserted in the product in the first place? Or do I think that as long as it’s okay and stopped at final inspection it really doesn’t matter? Particularly when I see something not quite right but well within tolerances, do I have to the curiosity to look into it further?
- Courage: Can I be bothered to fix an issue when it’s simpler to inspect the bad component out? Finding the right poka-yoke to spot the problematic feature within the work is often difficult as work in mostly done in black boxes – will I have the energy to keep on digging until it’s fixed?
The third deep lesson from Toyota is – yes – flow. Better flow will reveal technical problems and whether resources are placed at the right place. Definitely, flow makes things better – but not in itself. Keeping flow requires constant attention to changing market conditions and new problems which is why flow works better than non-flow.
Flow Obsession Misleads
Back to the Toyota museum. I remember Christophe Riboulet, the CEO of an inspection machine company, pointing out (I had missed it) that looms were on a conveyor belt as early as 1927. Henry Ford’s conveyor flow had spread fast and far. The just-in-time approach was revolutionary on quite another level, however.
In order to maintain assembly flow, Ford had reasoned he needed inventories of standard parts: 1/operators could help themselves from a bin of similar parts as they needed them and 2/ if a part was problematic, they could discard it and pick the next one. In order to keep these component bins filled, it was okay to produced huge batches of each part in order to secure the supply.
Kiichiro Toyota turned this thinking on its head. In order to secure the supply, we should have the minimum inventory on hand – and no more. This would not only keep us vigilant and make sure all supply problems are solved quickly but also save cash (less inventory) and ultimately costs (equipment designed closer to real demand). The logical conclusion of this reasoning is greater flexibility of production processes.
To understand how flow obsession can be misleading, take a look at a VSM:
The current-state map makes it look like there is a single part being produced, and all inventories are simply due to differences in cycle-time.
However, the future-state map reveals that two parts are being built in this value stream: left and right. Indeed, the future state sets up a kanban:
But the VSM still focuses on this one part – although at stamping, we can see they produce at least three different references.
By contrast, a Material and Information Flow analysis from Toyota is all about flexibility (more about this analysis in a future column):
What are the non-flexibility points that create inventory and, yes, slow down flow? When you look at lead-time, stagnation is mostly due to a lack of flexibility rather than different cycle-times. Cycle-time is cycle-time and can be independent of takt time unless you try to optimize the mean, not the lead-time.
Flexibility brings us to standards: how well do you know how to do A, then B, then how well do you know how to switch from A to B and back. Standards are about breaking jobs into skilled tasks and ordering them smartly (yes, flow again) to have smooth and seamless work. The lesson from Toyota here is: where is the skill:
- Do I understand the impact of every move on the final product and process?
- Do I understand the impact of changing from one activity to the next on the final product and process?
Language is not always helpful. By breaking up reality into design and production, language encourages us to think in terms of right design, and then right production. Toyota tradition doesn’t work that way: “First, human engineers meticulously build each new line component by hand to exacting standards, then, through incremental kaizen (continuous improvement), steadily simplify its operations. Eventually, the value added by the line’s human operators disappears, meaning any operator can use the line to produce the same result.” (https://global.toyota/en/company/vision-and-philosophy/production-system/.) That’s fairly explicit.
Mastering a task involves kaizen because learning occurs through familiarization – turning it on the potter’s wheel again and again until you truly understand it (and not coding the line in the software once and for all). From that perspective, clearly standardized work and kaizen are inseparable, two faces of the same coin. By seeking to master the sequence, one discovers opportunities for continuous improvement, which makes the sequence more efficient and more predictable and so on. Less muri, less mura, so less muda.
The lesson Toyota has to teach us is indeed a number of operational tricks, such as jidoka and just-in-time, to make us think more deeply about how smart are our products or services and how skilled we are in every step of delivering them. Flow is one part of the equation, but as a means, not an end. Flow is a brilliant technique for revealing problems – which then need to be resolved. The aim is not flow in itself (if it flows too smoothly, take some inventory or resources out and see what happens), but the endless pursuit of better products through better thinking.
