SPC (statistical process control) charts and SD (System Dynamics) models

[Marc]

An OLDIE!

Re: Linking SPC & SD (long)
Joe Kilbride
Fri, 4 Nov 94 10:46 CST

Bob Klein wrote re: my interest in the linkages between SPC (statistical process control) charts and SD (System Dynamics) models:

>Quality Function Deployment (QFD) links the Voice of the Customer
>(customer wants and needs are at the center of any valid TQM
>effort) to internal metrics a.k.a. performance measures. It is
>these internal metrics and performance measures that are plotted
>on SPC charts. And it is these same metrics that show up in SD
>models.

I agree with Bob's explanation of how these tools can be deployed throughout an organization in concert with one another. However, what I have been interested in is how SPC and SD work at the level of individual mental models. Both tools tend to provide their users with entirely new ways of perceiving, and therefore improving, their worlds. In other words, they give you AHAs! of a very similar nature. IMHO, here is why.

Buckminster Fuller said something like (and I paraphrase) "Don't teach me new ways of thinking. Instead give me a tool that makes me think in new ways." That is what SPC and SD models do: they provide a tool that forces us to think in new ways. These tools help us make the shift that Senge describes as moving from:

events---->patterns of behavior--->underlying structures

Here is how the tools enable the shift...

The key aha of variation/SPControl charting is that until you can differentiate between common and special cause behavior, you have no way of distinguishing important (i.e., special cause) events, from unimportant (i.e., random, or common cause) events. No matter how good it makes you feel to be a "take charge, action-oriented manager", ANY reactions to common cause events, no matter how well-intended or logical they may seem, are likely to be detrimental to process performance.

The impact of this is that when managing a work process, every event is a problem of equal magnitude until we begin control charting. Using SPC charts forces us to stop reacting to (common cause) events, and to see beyond them to the patterns of behavior that emerge over time as we plot the data. By studying the patterns of behavior using SPC, we learn that only special causes are events of importance, i.e., problems to solve. All other variation is inherent in the system itself. Eventually, as the system becomes stable (i.e., no special causes), further improvement requires examining the underlying structure of the process itself, which is the source of all common cause variation. In summary, the progression SPC charting enables is as follows:

When you: You shift from:
--------------------------- -------------------------------------
- begin keeping SPC charts - events ---> patterns of behavior
- get system in-control - patterns ---> underlying structures


Like SPC charts, which provide a tool and a discipline for seeing beyond the common cause events in a process, SD models help us see beyond day-to-day events (like a drop in sales or an inventory shortage) to the underlying feedback structures that are generating the observed behavior in complex, dynamic systems. The progression SD modeling enables is:

When you: You shift from:
-------------------------------- -----------------------------------
- plot Behavior Over Time (BOT) - events ---> patterns of behavior
- map, model, simulate - patterns ---> underlying structures

What all this boils down to is captured by Peter Senge at the beginning of Chapter 7 in The Fifth Discipline: "The bottom line of systems thinking is leverage--seeing where actions and changes in structures can lead to significant, enduring improvements...Our nonsystemic ways of thinking are so damaging specifically because they consistently lead us to focus on low-leverage changes."

In short, SPC and SD models help us (a) stop reacting to events and (b) gradually ascend the "ladder of leverage" from events to patterns to underlying structures. The effect of doing so is twofold:

- we avoid taking counterproductive actions, like blaming actors within the system for system behavior, or reacting to common cause events, which is called "tampering" by Deming

- the actions we take instead have greater positive impact

I hope this more clearly describes my interest in SPC/SD linkages than my previous post. In the spirit of the Learning Org list, I welcome any additional clarification of my thinking by others on the list.

Bye for now...

_ _____________________________
/ )| Joe Kilbride |( \
/ / | Kilbride Consulting | \ \
_( (_ | Downers Grove, IL | _) )_
(((\ \>|_/->_____________________<-\_|</ /)))
(\\\\ \_/ / \ \_/ ////)
\ / "I have seen \ /
\ _/ the enemy, \_ /
/ / and he is us." \ \
/ / -- Pogo \ \


PS -- To readers unfamiliar with SPC, my apologies for using terminology you may be unfamiliar with. If interested and want to learn more, consider the recommendations below. I personally have found Joiner's book helpful. Everyone on the Internet who seems to know anything about SPC and variation swear by the Wheeler books. I'm ordering them myself.

- Brian Joiner's "4th Generation Management" available from Joiner
Associates @ 800/669-8326, or

- Donald J. Wheeler's books including "Understanding Variation" or
"Understanding Statistical Process Control" from SPC Press
@ 800/545-8602

Thank you, thank you, thank you! I'm dealing with quite a few folks who think that it's acceptable to write as a response to a non-conformity, "Operator inattention, spoke to operator to pay more attention before product leaves area."
Then they're surprised to find in a review that all of their operators suffer from the same "inattention" problem in the exact same area. Seems apparent that there's a deeper problem, but when you're hacking down trees I guess it is hard to see the forest.
We're working on building a long-term viewpoint on production problems, so the excitement continues.

[Marc]

Originally posted by AJPaton:

"Operator inattention, spoke to operator to pay more attention before product leaves area."

This was one of my lessons 15 years ago in corrective action - it was "...you will see this all the time. It is NOT a Root Cause..."

[Kevin Mader]

AJ,

You posted: "Operator inattention, spoke to operator to pay more attention before product leaves area."

Sounds like the person with inattention is the one writing the response. People within the System are only responsible for 6% (WED). That is to say, if they have their 100%, they would only contribute 6%. The System is responsible for 94% of the issues. Management is responsible for the System. If I received a CAR with a response like this, I would be disappointed, but wouldn't fall victim to the same folly. Why did the person fill this out so poorly? Answer: part of the 94% and I am part of that. So I share the blame. Rarely blame the 6%, as the means to fix things is generally beyond their authority and responsibility and is not theirs to handle.

People are looking to do the least they have to fix a problem. They minimize effort by doing poorly at an investigation into 'root cause'. But what effort was given to training the person doing the proper investigation? Who's responsibility was/is that? Does the finger point at you?

People need the tools to succeed and direction. They also need to pay more than lip service to the continuous improvement philosophy (part of the 6%). My advice (and Laura's) retrain the individual given the CAR to complete with a method that will work. Also, have them get beyond the superficial thinking, as a response like the one they supplied helps nobody and never will. It will only make matters worse.

Regards,

Kevin

[Jim Biz]

Aj – a thought If I may I agree with both Kevin & Laura – here's what "helped" for us given similar responses. (I usually found “operator miss-read gage” - or operator didn’t read or was not aware of xx document” – talked to operator.)

Some of our floor managers do/did not clearly understand (or rememberfrom training) what a true “ROOT Cause is”. - We rearranged and upgraded our Cor-Act report form to “help them toward a more focused investigation/results process”, by including descriptive notations behind Short Term & Long Term response sections as a “remember –guide”

1 Describe the problem
2 Short term action (what immediate physical action/steps can be taken to resolve the current problem)
3) Long term action (what physical action – change(s) to equipment, processes or system documents - will prevent future occurrence)
4) Root Cause discovered during investigation…. (What SINGLE cause was determined for the problem)?

Root Cause was intentionally left for the last section. It was our thinking that by the time they do what they are best at doing. (Figure out what physically needs to be done), the reason they needed to do it (single Root Cause for the occurrence) will be more evident to them.

This approach wouldn't be a cure-all for every situation (and you can insert your own wording as reminders) but it did at least "make more sense" for my managers when investigating problems. It was fairly simple to remind them that “talking to the operator" was not a physical change.

[Don Winton]

Kevin said:

People within the System are only responsible for 6% (WED). That is to say, if they have their 100%, they would only contribute 6%. The System is responsible for 94% of the issues. Management is responsible for the System.

Generally true. Hence the reason that, in order for a system to function properly, it must be thought of as a system. The individual filling out the questionable CAR was seeing only his little portion of the system rather than the entire system.

A viable solution may be additional training, but that training must include systems thinking. An analogy I sometimes (actually, most of the time) use is the automobile. You go out and purchase 4 new tires from the dealer. One of the tires has a flat spot, as manufactured. This tire thinks that flat spot is normal (he has always had it), but the car the tires are installed upon knows there is something wrong (bouncing and shaking as it goes down the road).

Now apply the same analogy to this system under discussion. The employee in question did not see anything wrong with what he was doing (apparently), but the system did.

Taking a different track, the flat spot developed slowly over time. The tire was fine when installed (freshly trained), but slowly degraded over time. Eventually, the system (car) noticed, but the tire in question thought everything was fine (nobody informed him a flat spot was bad). Entropy in action. So, is the solution to retrain early and often? Or, is a better solution to find out why the flat spot developed in the first place and fix that?

Generally, I think the requirement for 'additional' training as a solution to fixing a systems problem sometimes gets overused. Follow the link below, for example:

*** DEAD LINK REMOVED 2002-04-01 ***

Unless some method is used during the training to make it stick, I believe it is a waste of time. Marc's example above of root cause analysis seems to apply here. Is lack of training the root cause to the employee failing to correctly fill out the CAR, or does the actual problem lie elsewhere?

When I give training, I try to develop a program that would be applicable to the attendees (hence the automobile analogies I use so often). The attendees understand those and can relate. The average person knows how long their commute takes (common cause). If, on one morning a traffic jam (special cause) makes them 15 minutes for work one day, does that mean they are going to leave home early every day? If the traffic jam occurred on a more frequent basis, then it changes from a special cause to a common cause and must be addressed differently (working on the system, i.e. different route, improve the highway, leave work 15 minutes early every day, etc.). This the audience understands. Try explaining the difference from a textbook and watch their eyes glaze over, especially some management types who seem to have the attention span in the nanoseconds.

Do not train the supervisors to correctly fill out a CAR. Train them as to why it is important to correctly fill out a CAR in regards to the system as a whole. And make it stick. Just a thought.

Regards,
dWizard

Thanks for the thoughts and ideas. I particularly liked the Wizard's Tale.
I'll admit that training is still one of the chief reasons/excuses for our production problems. (Partly because we've not had a comprehensive program.)
Unfortunately(?) we've been expanding rapidly recently, and our % of 20+ year vets is falling to the onslaught of new faces.
So our formerly stable workforce, with supervisory expectations of knowledgeable workers is making an about-face. Attitudes have yet to follow.
I've been in a company that dealt with rapidly expanding business by hiring BSEEs and MSEEs to do assembly work, figuring that they could adjust to uncertainty. That's not going to happen here, and it shouldn't.
Since you've shed light on my last question, here's another, which may not belong in this forum. How do you move from a stable experienced workforce to a new inexperienced workforce, training issues included.

[Laura M]

Oops...I did it again. Typed something that didn't read like what I meant. I meant, let the supervisors that respond "operator inattention" do their employees job for a while and recognize that some of the quality problems aren't the employees fault...because the supv. has the same problems. It was somewhat tongue in cheek, I guess. Inadvertantly made it sound like CAR training I guess...but the follow-up dialogue was excellent.