Those of you who are familiar with Shingijutsu’s materials and teaching (or at least familiar with Nakao-san’s version of things) have heard of “The Seven Flows.” As a brief overview for everyone else, the original version, and my interpretations are:
- The flow of people.
- The flow of information.
- The flow of raw materials (incoming materials).
- The flow of sub-assemblies (work-in-process).
- The flow of finished goods (outgoing materials).
- The flow of machines.
- The flow of engineering. (The subject of this post.)
A common explanation of “the flow of engineering” is “the footprints of the engineer on the shop floor.” I suppose that is nice-sounding at a philosophical level, but it doesn’t do anything for me because I still didn’t get what it looks like (unless we make engineers walk through wet paint before going to the work area).
Common interpretations are to point to all of the great gadgets, gizmos and devices that it does take an engineer (or at least someone with an engineer’s mindset, if not the formal training) to design and produce.
I think that misses the point.
All of those gizmos and gadgets should be there as countermeasures to real, actual problems that have either been encountered or were anticipated and prevented. But that is not a “flow.” It is a result.
My “put” here is that “The Flow Of Engineering” is better expressed as “The Flow of Problem Solving.”
When a problem is encountered in the work flow, what is the process to:
- Detect that there even is a problem. (“A deviation from the standard”)
- Stop trying to continue to blindly execute the same process as though there was no problem.
- Fix or correct the problem to restore (at a minimum) safety and protect downstream from any quality issues.
- Determine why it happened in the first place, and apply an effective countermeasure against the root cause.
If you do not see plain, clear, and convincing evidence that this is happening as you walk through or observe your work areas, then frankly, it probably isn’t happening.
Other evidence that it isn’t happening:
- People working around or improvising “to get the job done.”
- If you have andons, they are never pulled, or they go off quickly every time.
- No line stops. (Yes, this is a very, very bad thing.)
At the cultural and human-interaction level:
- Leaders saying things like “Don’t just bring me the problem, bring a solution!” or belittling people for bring up “small problems” instead of just handling them.
- People who bring up problems being branded as “complainers.”
- A system where any line stop results in overtime.
- No simple, on/off signal to call for assistance. No immediate response.
- If initially getting help requires knowing who to phone, and making a long explanation before anyone else shows up, that ain’t it.
- “Escalation” as something the customer (or customer process) does when the supplying organization doesn’t respond. Escalation must be automatic and based on elapsed-time-without-resolution.
Go look. How is your “Flow of Problem Solving?
I haven’t seen anything on the application of lean to design and development, but this would be the flow that matters there?
Brian –
From what I was taught, the “Seven Flows” all relate to the production process (whether manufacturing or administrative information processing).
Design engineering certainly has an impact, and I think it is a major player in this flow. That is because I think design changes are one possible countermeasure that this flow could deliver.
However, I do not believe Nakao-san intends “The flow of engineering” to be the design/development process itself.
That being said, design engineering *is* a production process, and all of the “seven flows” would apply if I were assessing how efficiently it was being done. In this case, the “flow of engineering” (aka “the flow of problem solving”) would assess how well the system responds when a design engineer has a problem of some kind that delays his work or his deliverables.
Thanks for commenting! It is nice to know people read this stuff.