Subject: Re: Q: Re-organizations regarding documents /Roberts/Robinson
Date: Thu, 17 Jun 1999 09:32:33 -0600
From: ISO Standards Discussion

Teresa recently forwarded the following:

> We are ISO 9001 and QS-9000 registered. Our quality system documentation at
> levels 1 and 2 has been organized around the ISO and QS standard. We have a
> quality manual and one regulation for each applicable section of the ISO
> standard. However, we are finding this system unwieldy and find that our
> documentation system all too often is cumbersome and impends our primary
> purpose of manufacturing connectors.
>
> We would like to transform our quality system documentation so that it
> reflects how we operate rather than how we document those operations. We
> would most likely reorganize around our functional units, but we might also
> reorganize around our departments. Is one of these models better than the
> other? And has anyone undergone such a reorganization of their quality
> documentation?
>

My employer has just spent considerable time and effort to move from functional-based documentation to process-based documentation because of the immense amount of duplication that occurs -- every department had different employee performance review procedures, with the resulting variance in results.

Needless to say, developing procedures that are not process-based will cause difficulty for auditors, both internal and external. How can they accurately assess the effectiveness of the preventive action process if each department handles things differently?

ISO is processed-based and companies should adopt this methodology in their operations and documentation or they will end up with a documentation nightmare on their hands.

Just my $.02 worth

Ralph

Any comments on "This Old Thread"?

I like the idea of Process Based QMS Documentation, benefits both internal & external auditing, simpleness & practicality.

Any comments on "This Old Thread"?Sure... Here goes:

Many of us used to describe our systems department by department. This caused trouble due to the fact that processes often span across several deps. When each dep. described only their part of the process, paying scant attention to the rest of it, trouble often followed in the interaction between departments. We lacked the overview of the entire process.

So: Describe the processes. (Now we only have to figure out how to handle the problems that occur in the interaction between processes :rolleyes: )


I like the idea of Process Based QMS Documentation, benefits both internal & external auditing, simpleness & practicality.
Yes, a system that is easy to audit is desirable and any benefits to auditing are welcome as long as they don't interfere with the main objective: To build a system that serves the users well

/Claes

Maybe it's because I'm an only child, but why can't I have it all? :o

Process-based documentation at the higher levels. This documentation shows inputs and outputs across the board...who the Internal Customers and Internal Suppliers are. It provides for an easy understanding that the outputs of Department A can be the inputs for Departments B and/or C.

But within the Departments, there will exist the functional documentation...that job specific level. Here is how one taps a heat, here is how one restarts the reheat furnace, here is how one verifies the status of the tensile machine, and so on.

This does, of course, lead to what some may consider an overabundance of documentation, but this is the method that works best for us...not only in ensuring we've documented every thing where the absence of which could adversely impact our ability to meet Customer/regulatory/statutory requirements, but it also is just another tool to help demonstrate due diligence.

Hi all,

Here in my company, I have revamped the whole system from a functional base to a process based system. It took some time but I did it in record time. (days and nights). I started with flowcharts defining how the process works in our system then transferred it to a document. We eventually got certified in January '04.

The flowchart helped me alot to define the process and as well as when I do my internal audits.

Aha.. A new poster. :)


Hello Allan, and welcome to the Cove. :bigwave:

/Claes

Maybe it's because I'm an only child, but why can't I have it all? :o

Process-based documentation at the higher levels. This documentation shows inputs and outputs across the board...who the Internal Customers and Internal Suppliers are. It provides for an easy understanding that the outputs of Department A can be the inputs for Departments B and/or C.

But within the Departments, there will exist the functional documentation...that job specific level. Here is how one taps a heat, here is how one restarts the reheat furnace, here is how one verifies the status of the tensile machine, and so on.

This does, of course, lead to what some may consider an overabundance of documentation, but this is the method that works best for us...not only in ensuring we've documented every thing where the absence of which could adversely impact our ability to meet Customer/regulatory/statutory requirements, but it also is just another tool to help demonstrate due diligence.

Rox,

Why not? Makes sense to me. Despite all the process approach hoopla, in reality many companies still have some "departments" that are service organizations for many different processes. For example, maybe the test and measurement department has very expensive equipment and a need for high-skill people to run it. Maybe 5 different "process" lines cannot afford to each have their own T&M group, so the T&M department provides this service to all 5 process lines. Seems to me that one set of "functional" documentation for T&M makes sense (i.e. hardness test procedure or breakdown voltage procedure), and the process documentation just has a step that says "send to T&M for hardness test" or "send to T&M for breakdown voltage test", something like that. Where's the harm? What benefit is there to do it another way?

What benefit is there to do it another way?

:agree1:

My personal opinion is that the whole idea is to have a system that works for your own organization....I don't believe that intent changed when the Standard did.

What benefit, indeed...we're asking ourselves that right now with a push from our parent company to conform to the document standardization methodology. It's primarily political now...but the solution I provided has been accepted...for now...

The process approach is a wonderful way to look at systems and allows people to realize that they don't work/live in a bubble. But, to reverse an old saying, don't lose sight of the trees for the forest. Sometimes, as you hinted at Mike, the specific documentation, the job/department/function based documentation, is needed.

Rox,

Maybe I'm missing the obvious, but, considering the example I gave, what alternative(s) would they suggest?

In your situation, what are they suggesting vs. what you have proposed? Can you give an example?

Am I being dense again? :confused:

Rox,

Maybe I'm missing the obvious, but, considering the example I gave, what alternative(s) would they suggest?

In your situation, what are they suggesting vs. what you have proposed? Can you give an example?

Am I being dense again? :confused:

No, you're not being dense...don't worry. :D I didn't go into details because it just wasn't worth it. Suffice to say, the methodology that our parent company wishes for us to adopt is almost strictly process related. Which may work fine where they are...but here in Canada with a Union, well, we have different needs.

So, while I understand the political benefit to conforming, and we will, my suggestion is that we will do so slowly over the course of the next year. Every document in our system comes up for review every 365 days (unless it is put into modification during that time). When the review cycle is initiated, documents will be modified to keep both the parent company and our employees happy.

Suffice to say, the methodology that our parent company wishes for us to adopt is almost strictly process related.

So, does this mean you might have the same instructions for, as an example, how to "tap a heat" appearing in several different "process" documents?

Just curious is all.

So, does this mean you might have the same instructions for, as an example, how to "tap a heat" appearing in several different "process" documents?

Just curious is all.

Nope. When a process document gets to "tap a heat" there will be a reference to a document where the details on how to tap a heat will be found. One level is process related...one level is functional.

Hi all,

Here in my company, I have revamped the whole system from a functional base to a process based system. It took some time but I did it in record time. (days and nights). I started with flowcharts defining how the process works in our system then transferred it to a document. We eventually got certified in January '04.

The flowchart helped me alot to define the process and as well as when I do my internal audits.


Wow! You did all that? Alone??? I think you're a genius....Welcome