Functional vs Process Based Documentation

[Marc]

Functional vs. Process Based QMS Documentation

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

 

[Marc]

Any comments on "This Old Thread"?

 

[Link Xue]

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

 

[Claes Gefvenberg]

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 )

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

 

[RoxaneB]

Have my cake and eat it to?

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

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.

 

[Allan]

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.

 

[Claes Gefvenberg]

Aha.. A new poster.


Hello Allan, and welcome to the Cove.

/Claes

 

[Mike S.]

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

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?

 

[RoxaneB]

What benefit is there to do it another way?

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.

 

[Mike S.]

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?