Systems Approach or Process Approach? Micro level of managing

[systems_thinker]

systems_thinker -

It seems as though you have a fairly narrow view of "quality". Why couldn't the quality process and the resulting QMS be established to cover the full breadth of issues you have raised in this example?

On the one hand you are providing a good description of systems thinking and providing some nice examples...then you seem to fall into the trap of putting "quality" in its own little box.

My guess is that this is based on your observations of how things are being done in most organizations but maybe it is more useful to define the role the QMS should/could play in supporting a fully integrated system rather than identifying the things wrong today?

Regards

Perhaps I'm wrong, but I don't think I have a narrow view of quality - I simply recognize that it is only one of the many forms of waste that may be present in a production system. If you agree with that recognition, then I would ask you to consider why we would emphasize improving quality over eliminating the other wastes that might be present in the system? Instead of adopting a quality-driven approach that focuses on removing one of the wastes, might it not be possible to proceed systemically to remove all of the wastes?

There is no doubt that quality improvement is a key part of the improvement of any system. The example I gave above shows that. The role the QMS can play is to provide the framework, process and tools for identifying and eliminating the causes of poor quality (the waste of defects). But the QMS is not "the system" - it is only the process for managing one of the wastes present in the system.

Hope this clarifies,

s_t

 

[systems_thinker]

Good question and good response.
The only thing I can add is that you may want look at the slowest point in your stream. It will be that operation that dictates the "drum beat" or sets the timing of the overall process. By increasing the throughput in the chosen operation you should increase overall throughput. But once again remember:
If you standardize a sub-par process - we all make junk the same way.
If you increase throughput in a sub-par process - we all make junk quicker!

Which shows nicely, Randy, the relationship between quality and flow in the value stream. Do you use drum-buffer-rope in your own operations?

s_t

 

[Randy Stewart]

A couple things here:

On the one hand you are providing a good description of systems thinking and providing some nice examples...then you seem to fall into the trap of putting "quality" in its own little box.

I didn't take it that way. QS-9000, ISO-9000, Q-1, Pentastar, Marks of Excellence, etc. have never been able to accomplish what they were really striving to do. I agree that it was mainly due to it being a "quality only" focus.
QS stated, for example, documented training was only for those that had a direct affect on the quality of a product. Well we could argue that purchasing low grade material had a direct affect but I never had an auditor look at our training for purchasing. What about process engineers, another arguable situation.
What I'm trying to say is that it's not trapping quality in a box. It has to be spread out throughout the organization. I don't even mention "quality" in any of my presentations, I refer to customer requirements and customer satisfaction tools. Rework etc. is part of customer unsatisfied marks.
I agree with you that it has to apart of an integrated system, but as soon as you say the "Q" word it becomes something for the inspectors to handle.
As you go through the process approach you will see where the overlaps are i.e. work environment (QS/ISO/Lean) to environmental (ISO-14000) to safety (OHSA), etc. Those areas is where a hard focus can really bring about change.

 

[NYHawkeye - 2005]

The role the QMS can play is to provide the framework, process and tools for identifying and eliminating the causes of poor quality (the waste of defects.

s_t -

My personal view and the approach we are trying to take in our organization is that the role of the QMS is much broader than how you have defined it above. The role of the QMS is to provide the framwework, process and tools for identifying and eliminating all forms of waste.

For example, our QMS encompasses all process improvement activities across the organization including production, design, shipping, finance, purchasing, etc... We operate a printed circuit board assembly area using a drum-buffer-rope approach. The DBR implementation happened because of our continuous improvement programs which are part of our QMS. Although the DBR implementation ultimately gave us some true "quality" improvements it was initially done to reduce wastes associated with over production, early production, etc.... As the chaos was brought under control we did have the opportunity to turn our process engineers back into engineers rather than expediters.

I think we are fundamentally saying the same thing but assuming you can't attack all types of waste through your QMS is short selling what can be done with ISO. I could personally do without the ISO standard but as has been mentioned it is a widely accepted standard with customer and management support and I believe that it is flexible enough to be used in conjunction with lean, TOC, or any other improvement approach.

 

[Randy Stewart]

fundamentally saying the same thing

Yes I agree with you.

 

[NYHawkeye - 2005]

If you standardize a sub-par process - we all make junk the same way.

If you increase throughput in a sub-par process - we all make junk quicker!

This is a great point Randy. At least in our organization we have had much more success standardizing the process through lean/TOC tools first then looking at the quality of the processes.

In fact, as we have "leaned" things out it has become impossible to ignore the waste generated through sub-par processes. Prior to leaning things out it was too dificult to get anyone's attention - the attitude was just grab the next thing and build it while the other problem was "fixed".

The beauty of the D-B-R approach is that any issues prior to the drum get visiblity through the constraint planner and any issues following the drum get visibility through the production planner. Nothing more frustrating to the team than seeing something screwed up after it has made it through the constraint

 

[Craig H.]

Randy, ST

You may have something here. We do have multiple products, 5 - 6 main (possibly "pacemaker") processes that pretty much control what we can do. And, we do have finished goods inventory. I am not sure how to apply this, but I am going to try, using what you said. Is there a symbol "library" that also explains what the symbols/shapes mean? How about books??

After your last posts, I suspect this is going to yield some eyeopeners. Thanks.

Craig

 

[systems_thinker]

s_t -

My personal view and the approach we are trying to take in our organization is that the role of the QMS is much broader than how you have defined it above. The role of the QMS is to provide the framwework, process and tools for identifying and eliminating all forms of waste.

For example, our QMS encompasses all process improvement activities across the organization including production, design, shipping, finance, purchasing, etc... We operate a printed circuit board assembly area using a drum-buffer-rope approach. The DBR implementation happened because of our continuous improvement programs which are part of our QMS. Although the DBR implementation ultimately gave us some true "quality" improvements it was initially done to reduce wastes associated with over production, early production, etc.... As the chaos was brought under control we did have the opportunity to turn our process engineers back into engineers rather than expediters.

I think we are fundamentally saying the same thing but assuming you can't attack all types of waste through your QMS is short selling what can be done with ISO. I could personally do without the ISO standard but as has been mentioned it is a widely accepted standard with customer and management support and I believe that it is flexible enough to be used in conjunction with lean, TOC, or any other improvement approach.

I think we're in basic agreement. There is a post above where I suggested that a pathway to systematic improvement was through using ISO 9004:2000 as the guiding methodology and then deploying tools from Lean, TOC etc. as required.

My only caveat is that, in the companies I have seen which have been certified to ISO 9001:2000 (or the 1994 editions), this is the exception rather than the rule. In those situations ISO 9004:2000 (or its 1994 equivalent) was ignored, the focus was squarely on defect reduction, and there was either no desire or knowledge of how to broaden the effort to attack other wastes in the system.

Perhaps something the ISO industry needs to consider is how, in the certification model, registrars ensure that ISO 9004:2000 has been considered and actioned. Right now, as I understand it, there is no obligation to do so, yet the ISO 9004 document is far more valuable and important from a system point of view than the certification one.

Cheers,

s_t

 

[systems_thinker]

Randy, ST

You may have something here. We do have multiple products, 5 - 6 main (possibly "pacemaker") processes that pretty much control what we can do. And, we do have finished goods inventory. I am not sure how to apply this, but I am going to try, using what you said. Is there a symbol "library" that also explains what the symbols/shapes mean? How about books??

After your last posts, I suspect this is going to yield some eyeopeners. Thanks.

Craig

In a Lean value stream there will be one and only one pacemaker, dedicated to a product or product family. The drawback to the Lean approach is that you will have to design and model the system, create the pacemaker, and implement the new state and that is fairly large-scale change.

The TOC approach can be used with your system as its currently configured by identifying the constraint or bottleneck and then applying the five focusing steps of TOC to lift it and create a process of ongoing improvement. In this process you can use the DBR application to address the production control and scheduling issue and improve the throughput of the system (note that "throughput" in TOC terms has a very precise meaning).

An often overlooked part of TOC is the logic-based Thinking Tools which are very powerful but not necessarily easy to learn or use. Their value is similar to Lean Value Stream Mapping and modelling - they allow you to visualize the current situation to determine cause-and-effect relationships in the system which are producing undesireable effects, identify the root causes, build the future or improved reality, and develop a plan of action to transition to the improved state. They help answer the key questions of What to change?, What to change it to?, and How to cause the change?

Hope this helps,

s_t

 

[Randy Stewart]

Here's a couple tables of icons.
Again, if you can't read them I'll send an email.