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.

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..."

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

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.

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.

Oops...I did it again. :o 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.

You know that.
I know that.
What I don't know is how to convince the supervisors of that.
Any ideas?

Train them, and make them do the job for a while.

Don,

Nice analogy. I will have to borrow it if you don't mind.

Systems Thinking: I couldn't agree with you more.

We spent some time in another thread discussing CARs and asking the 5 Whys. So I won't expand on that topic.

For discussion:

Systems Thinking is vital, IMHO!! This is true in all facets of life. Opponents to Systems thinking: Superficial Thinking, Suboptimization, and Instant Results. These opponents work together to make a System invisible. Have a problem? Solve it before you know what actually went wrong. Make any sense? Sadly, it happens every day.

Management attention = "Nanoseconds": exactly right! Management is looking for 'instant results', positive ones at that. Leads to suboptimization, wrong diagnosis, and more work and aggrivation. A good plan? We all know the answer to that. Still, it is expected, so we blunder ahead. Is it any wonder why people become so disenchanted with their work? I can't imagine otherwise.

Systems Thinking is new for many. It is seldom taught in Western and European business. WED: "People charging this way and that way can do a lot of damage!" Nobody working together on the process, each working on what they 'think' is important. Just misguided effort, usually leading to making things worse.

Organizations need Organizational Aim. Aim is created by Senior Management with knowledge of the System and Managerial Theory (SoPK). Aim is the top level of Systems Thinking, I suppose.

Well, back to the group...

Regards,

Kevin

And now you all know why I call my 'company' Cayman Systems. No kidding...

Probably 15 years ago I took a course "Business as a Process" - which is where I first was exposed to looking at all business processes as interacting systems. I still have the courswe book here somewhere. There used to be a GREAT Mac software program called Stella (long gone and won't work on my system since system 7.1) which was great for modeling business systems.

Jim Biz, I like your idea regarding the CAR and root cause. It would seem to work well.

AJPaton said:

I particularly liked the Wizard's Tale.

Thanks. That little piece is from Integrated Process Management by Roger Slater. I strongly suggest the book for anyone in this field.
How do you move from a stable experienced workforce to a new inexperienced workforce, training issues included.

Ahhh, lament the loss of apprenticeship programs.

Typically, many would answer this is a manner such as documentation, but that is only a partial answer. I may not have a better answer, but I do have a few suggestions that may (or may not) help.

Any activity within an organization can be viewed as a process, even its personnel. Therefore, you would want to manage your workforce just as you would any other process. When a process is made to be robust, the interactions of the personnel have minimal impact. In process management, many firms overlook this. They will invest countless time and money on equipment and statistical techniques but when Joe Employee decides to retire, his replacement throws the whole program into chaos. Why? Because Joe Normal was doing things that were not part of the process management plan is why.

I probably sound like a broken record, but whenever process management plans are implemented, the plan must consider the system, not the components. Sadly, many plans do not do this. At a previous employer, the company invested thousands and thousands of dollars on improved and upgraded manufacturing and testing equipment. Meanwhile Jane Employee was out there attaching the component leads (later defined as a key input variable) in the same old way. Thus, all the nice charts and graphs and such generated by the computer controlled machines did not mean diddly.

It sounds like you are pretty far into this so I would offer another humble suggestion: start now! I would also suggest you pick up a copy of Slater's book I mentioned above.

Laura M said:

Oops...I did it again. Typed something that didn't read like what I meant.

I knew when you posted that you did not mean that training was some simplistic answer. My diatribe was against some training programs as a whole, not against your response. If I implied as much, I apologize.

I have taken issue with training programs as a whole for some time now and here is why.

How many of you were sent to (or sent some to) what was described as [Insert Latest Buzz Word Here] Training. Then upon attending, it was nothing more than lecture and workbooks. That is not training, that is education. When a program educates, it disseminates knowledge, training disseminates experience. Read it like this:

Would you rather have sex education or sex training?

…but the follow-up dialogue was excellent.

Thanks.

Kevin said:

I will have to borrow it if you don't mind.

No problem.

Management is looking for 'instant results', positive ones at that. Leads to suboptimization, wrong diagnosis, and more work and aggravation.

True enough. But, when we fall for it, are we any less guilty. Remember my diatribe from last year about speaking different languages? Just as management expects their workforce to be trained, we should expect nothing less from our managers. Or else, as I tell mine:

Tell what you want accomplished, then stay out of my way and let me do it.

Diatribe mentioned above is here:

Total Quality Management - Is TQM On Your Radar? (http://Elsmar.com/Forums/showthread.php?t=3380)

Systems Thinking is new for many. It is seldom taught in Western and European business.

True enough. That is why I harp on it so much. The more the word gets out, the quicker we can change that.

Marc said:

I still have the course book here somewhere.

I would be interested in the title if it is different than the course name. I would like to scrounge up a copy to read.

Regards,
dWizard

[This message has been edited by Don Winton (edited 26 April 2000).]

Don,

I said: Systems Thinking is new for many. It is seldom taught in Western and European business.

You said: True enough. That is why I harp on it so much. The more the word gets out, the quicker we can change that.

Harp all you like!! I am listening and trying to do the same. When you consider the small percentage of organizations that are process-oriented vs. results-oriented, we need all the help and harping we can get!

Marc,

I hadn't realized the story behind the name. It is refreshing to see that you have lived with that revelation for the past 15 years and pursued the propagation of this management method. Bravo!

Regards,

Kevin

...I would be interested in the title if it is different than the course name. I would like to scrounge up a copy to read...The 'book' is from a course I took titled "Total Cycle Time - Business as a Process". This was a course I took that was put on by Hillenbrand Industries (aka Batesville Casket in Batesville, Indiana). In the course they taught you how to look at the entire company and flow chart it from the top down so that you end up with a series of inter-related systems. You then look at each system and determine cycle time. It talks about cross-functional teams, and the importance of (the US auto industry has learned this theory...) cross-functional teams. They showed how to do flow charts in a cross-functional format, in fact.

Actually there is a heck of a lot in a rather small booklet. The 'Plan, Act....' cycle they use is "Try, Test, Learn, Modify, Feedback". It talks about barrier identification utilizing many things, including the well known fish bone chart. It talks about the learning curve but also the forgetting curve.

One of the interesting features is the evaluation of yeild on every process (such as order entry) and how to target improvement efforts across the entire business. SPC is suggested for most processes, not just manufacturing processes. In short, it throughout talks about all this as a means to (you probably guessed this) continuous improvement.

The original name for my 'company' was Field Bio-Electronics. I took the name in 1970. On a contract basis I was working with hospital equipment - repair, alignment and calibration - such as EEG and EKG machines. Around 1990 someone asked me what that name had to do with what I was doing. There had been an evolution in my life as with all our lives, and with the contract work I did which had shifted from the medical arena to manufacturing and quality assurance. In today's world, if you talk about systems, it is automatically related to computer systems - but 10 years or so ago that was not the case. I 'renamed' my company Cayman Systems as I saw that what I was involved in was/is business systems.

Yup - I'm a 'systems' freak.

Now that we are back on the subject of Systems Thinking, ill bring up the name Peter Senge again. Last time i did this nobody had heard of him, and i thought he was the best known American Management Guru.

His book was called the Fifth Discipline, and to be honest i didnt understand a bit of it, the sum total of what i learnt could be summarised on a postage stamp. but if you are really into Systems Thinking this is THE book.

If you want to sort out the boys from the Bull***tters, when somebody starts to name drop Senge just ask them what actually is the Fifth Discipline. Nobody has yet demonstrated to me that they clearly understood what it is.

Anybody out there want to enlighten me?

Andy,

Until your post, I had never heard of Senge either. I am trying to get a hold of a copy of his book, but the local library here sucks. But, I will find a copy and I want to read it.

My systems thinking was primarily drawn from the ideas put forth in Roger Slater's 'Integrated Process Management' and theories of my own that I put into practice at a former employer.

This particular employer produced semi-conducting photodetectors. They were basically manufactured 'cradle-to-grave' in house. Basically, we would take the raw material and chemicals and when the process was complete, a photodetector was born. The problem was that was a departmentalized process. Wafer fabrication was one operation, assembly another and so forth. My area of responsibility was final test. Problem was final test was the first area to see results of 'tweaking' in the other areas.

Fabrication thinks that a two second reduction in cycle time is a good thing. They do it. A few days later, I have a batch of product that is worthless. Fabrication failed to consider the results of their actions across the entire system. Assembly and packaging were no different. Every time Joe or Jane employee thought they had a good 'idea' a change would be made and the consequences would only be evident later (normally too late). That is when I developed a pre-cursor to the circular versus linear/Venn diagram theory presented here a few months back.

So, the first thing I had done was every process would be standardized. After they were standardized, controls were put in place to ensure the standard was being adhered to. Parallel to this, I began a massive education of the work force of exactly how the photodetectors worked, including technical details that had to be presented in a non-technical manner (if you have ever done this, you know how difficult it can be). Employees were encouraged to make suggestions to improve the process, but rigorous testing (verify and validate) of the change was done prior to the change being implemented (process control).

Next, staff was trained on (at the time) the systems theory model I developed. It was quite similar to some graphical techniques you would see in a business school. It was a graph that would show that while one area of the system was being optimized, other areas were actually being worsened (a little hard to demonstrate here).

Anyway, I will try to get a copy of Senge's book and let you know my opinion.

Regards,

dWizard

Your tale reminded me of my first employer, they supplied Intel with fabrication equipment, and made design engineering changes for cost or production reasons, without considering "form, fit and function"

(If a revision to a part isn't formed the same, fit the same and function the same as the old part, it must be given a new part #)

After we caused multiple wafer batches of Pentiums to be scrapped, the 800 pound gorilla called our customer descended upon us. We ended up with an Intel product line and another for everyone else in the world.

The moral of the story, don't tinker with the system if you don't know the consequences!

AJP

AMEN!

The evils of suboptimization. Creating a small shread of cost savings upstream which results in major dollar loss downstream. And if the stream is long enough and murky enough, you never find the problem.