“Data, of course is important, but I prefer facts.”
This wise quote is attributed to Taiichi Ohno, often credited as the creator of the Toyota Production System. As we build the businesses of the future, we need to understand the difference between facts and data if we want to create real value. Where do we find facts? Not on a dashboard, not via a video feed, not in a PowerPoint. We find facts where the work is done, at the gemba (the Japanese word for the place where the actual value-creating work happens).
At LEI we help business leaders strengthen strategy and operations through lean product and process development. In some ways, the term “process development” is misleading. During my years at Delphi, for example, we switched our thinking from developing and launching new processes to developing and launching new value streams. This simple switch, which we learned from Dr. Alan Ward, the late co-author of Lean Product and Process Development, made a significant impact for us on what “good” looked like. Installing and debugging equipment was no longer sufficient; we needed to create a value stream where a signal to produce would go in and a part would come out. This meant we needed real facts. We couldn’t improve without them.
Facts Versus Data
Here’s a quick story about facts versus data.
Early in my Industrial Engineering career I was performing a detailed downtime study on a highly automated manufacturing system. The system itself consisted of three interconnected machines and contained a total of approximately 210 processing and check steps. Connected to this system was a factory information system (FIS) which was collecting data. Part way through the study, the software engineer who created this system walked by and asked me what I was doing. When I explained he said, “Did you know that the FIS system tracks each downtime occurrence, by station, and the length of repair time?” I respectfully asked him to stand with me for a few minutes to watch.
Shortly thereafter, a terminal jammed in a feeder-bowl and the machine stopped. And nothing happened. The machine operator was elsewhere, staging materials. This was a fact. So I asked, “Does the repair time captured by the FIS include the wait time for the operator to respond? If so, then it really isn’t ‘repair time’.” Next, I pointed out that the terminal jam was not machine-related but was actually due to too much lubricant on the terminals, so they were sticking together and jamming. Another fact. “Does the FIS note that?” I asked. The answer was no.
We had spent literally millions of dollars and put a lot of trust in a system that collected data but could not provide critical facts. We had the best of intentions, but we still weren’t thinking deeply enough. This is why we can’t build the next generation of great businesses using that type of data as a starting point. Data is wonderful, but we need facts, and we need to know how to coach others how to look for facts and work with them to solve tough problems.
People, Processes, and Tools
Many people entering technical fields become overly focused on tools, which is understandable. They are readily taught as independent topics at universities. But unfortunately, stitching together a series of tools does not yield successful value streams.
Jim Morgan and Jeff Liker detail the three elements of a true lean development system in their book The Toyota Product Development System:
- People (the Operator, the Industrial Engineer, and the Software Engineer),
- Process (the production system and the materials), and
- Tools (the Factory Information System and the Downtime Study)
It’s the interaction of all three that must be considered, and there is no better place to understand this interaction than the gemba.
Learning how to develop processes begins with acknowledging that all results are the outputs of processes. To achieve better results, the processes need to be identified, understood and improved. This is why the organizations that are the best at process development always start with reflecting and learning from the current situation. You want to get clear on the “whats and whys” around process.
- What aspects of the process are working well and why?
- What areas are problematic and why?
- Are there sections being bypassed via workarounds, or any other useful discoveries?
All of these answers—you guessed it—are best found at the gemba.
We all must learn how to observe what’s happening in the various gembas: the production gemba, where the value-added work is done; the development gemba, where product and process are simultaneously developed; and the supporting area gembas (such as legal), where work is being done to enable great product and process development to occur and for the resulting value streams to be successful.
Taking this one step further, well-designed processes are actually easier to observe: Normal versus abnormal conditions can readily seen and investigated. Some of the more familiar tools that enable this condition might be standard work-in-process inventory levels, supermarkets, and shadow boards. But as you get further from the production gemba, the work tends to be knowledge-based, and observing the status of the work becomes more difficult. Clear milestones and a good obeya process can greatly help.
None of this be done alone; your people make it all happen! Mapping the value streams, whether concept to design or order to ship, will give you a great start. Having a map be technically correct is less important that the lessons learned that result from the activity. And just the act of creating a product development value stream map will force the identification of all the functional areas, and therefore the stakeholders, that must be engaged in developing the right new products and processes.
As a thought experiment, take the next minute to write down the answer to the question, “Why do projects or initiatives fail?” (This is an exercise I learned from John Shook, author of Managing to Learn). Now take your list and ask, “Why does this happen?” What I’ve learned is the lack of alignment amongst the stakeholders is a root cause to most, if not all, the failure modes. Scope creep? You’re probably not aligned on the focus area. Lacking resources? You’re probably not aligned on business priorities. The point is, in process development, think about how you will keep the various stakeholders engaged throughout the entire development process. Consider:
- How can you draw out the experience of the tooling engineer to create better workstations?
- What might the industrial designer share that will lead to better user interfaces in software?
- What can the supplier add that will keep you from unknowingly damaging the materials?
- What can the operator teach you?
True story, while working on a mock-up of a future assembly system, I had an operator ask me if we could move the symmetrical parts to the outer edges of the work envelope and the parts that required more manipulation and orientation to the center of the work envelope. I said, “Sure, but why?”. Her answer still gives me goose bumps today. “I can grab symmetrical parts with either hand, but if the parts that require precise orientation are in the center, I can grab them with my dominant hand and do a better job placing them in the product.” (Jessica, thanks for participating in that experiment and teaching me so much).
There’s a lot of talk in tech about the creation of “digital twins” today. In process development, that could be a model of the current process or even of the proposed process. Like any tool, these things should be approached from the perspective of, “How will I engage the stakeholders in their use?” The reality is, digital twins can be very useful, but also disengaging… almost like a black box where data goes in and data comes out. So now we have come full circle… Perhaps a corollary to Mr. Ohno’s quote is, “Tools are of course important, but I prefer them in support of people and process.”
If you’re an emerging product leader, yes, learn the tools, but use them together as a complete process while leveraging the knowledge and experience of your cross-functional stakeholders. Because at the end of the day, it’s people who create value for other people.
Introduction to Lean Process Development
Design better processes that deliver results—on time and at launch.
While I agree with the sentiment of the article, how would the author propose a better system to collect data on the FIS? ” Was a better way found? Where the factory workers asked to manually capture the accurate length of repair time? Data like this is helpful in conjunction to going to the Gemba. I highly doubt that most institutions have perfect to the split-second ways to capture accurate data, and that’s ok! Data should be used to drive strategy and decision making. It would have been great to know how the author helped improve the FIS.
Presenting examples in an article to point out the obvious fact that data is flawed, and therefore we need to go and see to see the reality (true) without providing a better solution weakens the argument, in my opinion. The message should focus on using data to understand trend, variation, and direction, and as a way to either initiate or validate what we regularly see at the Gemba. Neither (Gemba and data) is sufficient by itself in the work of research, PDSA, and process improvement.