If lean really is about innovation, why does so much of it seem to be about logistics?
Dear Gemba Coach,
If lean really is about innovation, why does so much of it seem to be about logistics, with truck preparation areas, leveling boxes, small trains, kanbans and so on?
Because logistics is the way into innovation – very good question. This is simple when you’re used to thinking this way, but it needs a bit of hard thought to get one’s mind around it. A product or service is about delivering value to customers – helping them along in one of the processes they’re trying to get done.
This value is typically made up of parts assembled together if a product, or various processes coming together if it is a service, put together on supporting processes and so on. Intuitively if one succeeds in improving the value of each component (function/cost) and assembles them more effectively together (in ways that customers can benefit from), then the value to customers increase. If the product is better than the competing ones, at least on one critical dimension valuable to customers, of if the service is more useful, then customers prefer your product or service over others and you’re away.
Since times and tastes change and technology evolves, any provider needs to constantly strive to improve the value of its products or services by improving the value of the component parts and most importantly by fitting them better together to create a better, fully integrated offer.
On the Gemba: Engineering
And this is what companies do. I was on the Gemba recently of an engineering department and they were listing all the projects they were working on to improve the company’s products’ value, as well as all the problems they were solving to fix customer issues. They were working very hard, but, let’s face it, we will never have enough engineering resource to tackle every engineering problem we have. This begs two questions:
- How do we know that engineers are working on the right problems? (they are absolutely convinced they are).
- How do we know they are working on the right problems in the right order? (because everything fits together, a solution now will impact other issues in a different way as a solution in three months – the tide never stops coming).
Let’s face it, engineering is quite far from the customer. Engineers are at the end of a chain of “engineering request changes” from either customer service or production, or at the end of a change of marketing driven product innovation, but they hardly ever work with customers directly.
As Takehiko Harada reminds us in his great book on Management Lessons From Taiichi Ohno, kaizen is about getting value closer to the final process, the customer. How do we engage engineers in kaizen to get them closer to customers’ actual usage?
And what does any of this have to do with logistics?
Back at the Gemba, we now stand at the truck preparation area. In order to make sure the customer – or distributor – truck is fully complete, we’ve established a “fake truck” zone that we consolidate throughout the day and aim to finish a few hours before the real truck comes in order to make sure we fill the truck up exactly according to the manifest.
This means that boxes of finished parts are pulled from the line exactly in a planned order according to the takt time and the Leveling Bow where the withdrawal kanbans tell the logistics train operator what to withdraw from which cell at what time.
Life is never easy, so production cells will occasionally struggle to deliver the right products on time because of either a quality issue that required rework, a machine misbehaving which required resetting, a missing or wrong component, someone with a critical skill away on holiday and so on. In lean, the management chain’s job is to be a chain of help and support frontline management and teams in solving all problems so that they can keep up with the internal demand from the logistics pick up train.
Some of these problems are caused by production management and can be fixed there. But as the cells improve through kaizen (bringing, by the way, their value closer to the final customer through the logistics pull), deeper issue will emerge that concern product and process design. This creates a flow of specific demands for engineering help.
Now, let’s imagine that a managerial miracle has happened and management has decided that a part of engineers’ time should be spent in production helping operations to figure out and fix their daily delivery problems. As they tackle and solve immediate production problems to support the delivery of this specific product or service for this order NOW! They also get their hands dirty and start “thinking with their hands” – understanding the reality of the process and product better.
This hands-on understanding can feed into another important flow of the demand for engineers to tackle: customer quality complaints. Assuming production can “clear the window” and solve its own issues, an engineer’s mind is now bombarded by two information flows: quality complaints and making-stuff-at-the-right-time issues.
When dealing with brainy matters, we need to remember that data in context is information, information and understanding is knowledge, and knowledge and care is wisdom. In other words, creating a constant context for engineers to see real life’s clear and present “now” issues is essential to their understanding of the deeper engineering problems. This is never easy, because production rhythm is often in minutes or hours, whilst engineering works over weeks, months or even years. But still, and that’s the point, working on NOW! production issues creates the right mental context to understand what really goes on with the product.
What about product design? In lean, there is a takt time of new products and each evolution of the product should be pushed hard to be the most attractive to today’s customers, whilst retaining the robustness, quality and cost advantage of previous iterations. In practice engineers’ minds receive four flows of information:
- “Now!” production issues, for real customers right now.
- “Now!” quality issues from real customer complaints right now.
- Takt-driven product renewal needs to prepare the next product iteration
- Technology change question when one tech fundamentally questions how we do things.
How should we organize engineering to respond to these very various demands? To be honest, I have no idea. I don’t believe there are generic answers, other than making sure to clearly distinguish projects with a specific customer intent, and development of new technologies to create usable technical bricks (the former always eat up the latter). Beyond that the answers vary and completely depend on the nature of the product and process and where works needs to be done and how – as well as the organization’s history and habits.
My point here is that without the two first flows of information coming right from “now!” service to customers, engineers will work context-free (and invent their own contexts) and come up with over-complex solutions to issues unrelated with live customer needs. Typically, this is how we end up with brand new products that don’t convince customers and huge waste of engineering precious time and energy.
First deliver to customers, then work on value analysis (fixing issues in production right now to deliver on time to customers) and figure out value engineering (solving engineering problems to better design the next generation product).
With this flow of problem solving clearly in mind, we can better understand your question. Lean is not about logistics per se, lean is about bringing value closer to customers which starts with logistics (not surprising, as logistics delivers to customers) but certainly does not end there. Lean is about getting the whole business working better together from investing in new technologies to product design to process design to production to delivery.
Realizing JIT’s Full Power
As we discuss in The Lean Strategy, we’re not looking here for reusable knowledge (how can the same “knowledge” apply in a different context), but for reusable learning:
- Understanding the gains we’re after,
- A starting point,
- A direction for research (and a method to move on).
Just-in-time, as a full system, creates a spider’s web tissue of suppliers involved in delivering precisely, value analysis and value engineering that feeds back in how the full product or service can be improved cycle after cycle. This is the real, full power of just-in-time: it not only brings logistics value closer to customer, but ultimately (if seen as such) engineering value as well.
The starting point is logistics to fulfill 100% of customer demand 100% on time. But that is only the first step. What we’re after is continuously improving the product or service. The method is to get engineers always closer to customers’ real usages by solving real customer issues – as well as think big thoughts about how new technologies can better solve “now!” problems.
Lean Lessons from Cobra Kai(zen) and the Karate Kid
The unexpected wake-up call of the modest perfection of the original Karate Kid movie was that we need to move beyond defending this or that method of work and look to highlight opportunities of improving things beyond monetization, says Michael Balle in this reflection on the meaning of this classic movie.
How Using Kanban Builds Trust
Kanban functions as a trust machine because everyone using it must understand what they have to do and why, says Michael Balle: "Our purpose here is to share our ideas on what we believe is important in lean thinking."
The Sanity of Just-in-Time
Path dependence is the worst enemy of smart resolution, argue the authors, who suggest greater "frame control" with enabling tools such as just-in-time to respect people on the frontline and respect the facts they share about what is happening to them. "Mastering the path as opposed to being led by it, means looking up frequently to reevaluate both destination and way as new information comes to light."