Advice on Structuring Documentation

[Rachel]

Hey everyone,

Just out of curiosity - when you guys put together your documentation for 9K:2K, how are you going about structuring it??

We're shooting for 9K:2K - from a starting point of QS 9000. All of the documentation that I've seen so far in this company is virtually backboned by the 4-series clauses...we had a quality manual that was separated into 20 sections, we had 20 "4-Series" SOPs, and then the documentation just kind of spun off from there (Level II SOPs that have assigned numbers and WIs that were also assigned numbers). Given the *process-oriented* approach to 9K:2K, I'm really hoping to step away from the clause-based documentation structure, and instead separate the top-level SOPs by department. How much of a headache is this?

The biggest problem that we have in our documentation that I can see is cross-referencing. That is, okay...let's say Document B makes mention of Document A, or the process outlined in Document A. Someone comes along and changes Document A in a way that makes Document B invalid...but there's no system in place to highlight that Document B now needs some attention. This happens a lot when forms are obsoleted - we'll mention Form X, for example, in SOP 1; when Form X gets obsoleted, it's still mentioned in SOP 1, and there's no way to know that it's still mentioned. (Sorry - my explanations are a little convoluted...)

Can anyone offer any suggestions regarding how to get around this? We have *reference* sections in our SOPs - which are not always well-maintained, and do not always solve the problem as they only list references that are *explicitly* mentioned.

Thanks for all your help - I've only been on for a week or two, and you guys have already saved my butt quite a few times!

Cheers,
-R.

 

[Tom W]

Welcome!

It sounds as though the frustration is mounting. There is not right answer here for your situation. I would say this however - scrapping the entire system and starting over should not be an option. Making changes to your current system a little at a time, might be a long way but might also give you the ability to tie everything together like it sounds like you want to. If you are now QS have you thought about TS16949. It is based on 9K:2K but specifically for the automotive industries.

Are you new to the system and trying to learn it, if so I can feel your pain! Having cross-reference lists for your documents might be the fastest and easiest methods right now, until you can make other changes that you feel better control your system.

Sorry I can not give you a definite answer on your issue. Just keep visiting the Cove and you will get more than enough help. There are some great people here that really know their stuff.

 

[Douglas E. Purdy]

Process Vs. Procedure Approach

Hey everyone,

Just out of curiosity - when you guys put together your documentation for 9K:2K, how are you going about structuring it??

We're shooting for 9K:2K - from a starting point of QS 9000. All of the documentation that I've seen so far in this company is virtually backboned by the 4-series clauses...we had a quality manual that was separated into 20 sections, we had 20 "4-Series" SOPs, and then the documentation just kind of spun off from there (Level II SOPs that have assigned numbers and WIs that were also assigned numbers). Given the *process-oriented* approach to 9K:2K, I'm really hoping to step away from the clause-based documentation structure, and instead separate the top-level SOPs by department. How much of a headache is this?

The biggest problem that we have in our documentation that I can see is cross-referencing. That is, okay...let's say Document B makes mention of Document A, or the process outlined in Document A. Someone comes along and changes Document A in a way that makes Document B invalid...but there's no system in place to highlight that Document B now needs some attention. This happens a lot when forms are obsoleted - we'll mention Form X, for example, in SOP 1; when Form X gets obsoleted, it's still mentioned in SOP 1, and there's no way to know that it's still mentioned. (Sorry - my explanations are a little convoluted...)

Can anyone offer any suggestions regarding how to get around this? We have *reference* sections in our SOPs - which are not always well-maintained, and do not always solve the problem as they only list references that are *explicitly* mentioned.

Thanks for all your help - I've only been on for a week or two, and you guys have already saved my butt quite a few times!

Cheers,
-R.

Rachel,

I currently am not working on a 16949 QMS, but am in the process of transitioning a QS built to 1994 version of ISO 9001 to the 2000 Process-Based Approach for a QMS. I agree with getting away from the documented procedures, but wonder about the department orientation approach. We are to identify the processes and their interaction. I am beginning with a Core Process that resembles the QMS Model for Clause 7 - Product Realization, from customer communication-to-shipping product to customer. This will be a Level 2 Process Document that is Owned and Managed by the Management Team. During the development of this process we are identifying the process measures that will become our metrics for monitoring and measuring the various aspects of the Core Process. Once that is complete, then I plan to create a Top Level representation of the QMS to be placed in the Quality System Manual along with a reference to all the Processes and Documented Procedures.

Doug

 

[Claes Gefvenberg]

Given the *process-oriented* approach to 9K:2K, I'm really hoping to step away from the clause-based documentation structure, and instead separate the top-level SOPs by department. How much of a headache is this?

Look out! You may be in for a major headache if you go for SOPs by department, since processes often span over several departments. If you are going to change the system I suggest that you go for Process based SOP's instead.

/Claes

 

[Rachel]

how do you draw it? how??how??

Yeah, Doug, that's kind of what I plan to do too. In the long term, I hope to have all of this stuff documented on an interactive page in our Intranet - something that looks like a process flow chart - so that someone who wants a work instruction for testing, say, product viscosity can start at the overall process, click on "QA", click on "Product Testing", and then find "Using the Viscometer" in the work instruction list.

This requires a lot of work from our two-person IT department, though (we're pretty small), and it's not going to be completed anytime soon - and definitely not before our initial assessment audit. In the interim, I'm a little flustered as to how to logically set up the flow of documentation.

Maybe I should have been a little more specific. I didn't really mean I wanted to separate by department - it's just that our overall process is pretty much a flow from department to department. Being as new as I am, I'm still thinking "okay, from customers to sales, to purchasing, to production, to packing, to shipping". But there's overlap, of course, and that's where I'm getting stuck - I guess I'm wondering how you would fit in processes like CI and data analysis into a process flowsheet - just box around everything and label the box as CI?

 

[David Hartman]

Yeah, Doug, that's kind of what I plan to do too. In the long term, I hope to have all of this stuff documented on an interactive page in our Intranet - something that looks like a process flow chart - so that someone who wants a work instruction for testing, say, product viscosity can start at the overall process, click on "QA", click on "Product Testing", and then find "Using the Viscometer" in the work instruction list.

This requires a lot of work from our two-person IT department, though (we're pretty small), and it's not going to be completed anytime soon - and definitely not before our initial assessment audit. In the interim, I'm a little flustered as to how to logically set up the flow of documentation.

Maybe I should have been a little more specific. I didn't really mean I wanted to separate by department - it's just that our overall process is pretty much a flow from department to department. Being as new as I am, I'm still thinking "okay, from customers to sales, to purchasing, to production, to packing, to shipping". But there's overlap, of course, and that's where I'm getting stuck - I guess I'm wondering how you would fit in processes like CI and data analysis into a process flowsheet - just box around everything and label the box as CI?

Rachel,

Using Visio (which may not be the best tool, but it does work) you can develop a process flow that contains hyperlinks to pertinent documents and/or lower-level process flows that contain links to specific documents. This provides a over all process flow that may contain links to the "system-level" documents (Managment Review, Preventive/Corrective Action, etc.) and links to specific lower-level flows that contain links to their pertinent documents. With a little experience with Visio and hyperlinking this is not very difficult to develop.

 

[RoxaneB]

Okay...documentation structure for us is...

Manual
Required procedures...top level doc's on those 6 items
Work Instructions...detailed 'how-to' tasks...how to verify the tensile machine, how to tap a heat, how to change a wiget on a gizmo...
Forms....tables, templates, matrices, etc.

Using a document software package, we can link associated documents together. In other words if SOP Alpha references WI Beta in it, down in the 'Related Documents' field, we insert a link to WI Beta...and vice versa as appropriate.

So, let's say SOP Alpha is changing...our software program prompts us "Do you wish to notify the authors of associated documents about this document change?" Yes or no....if I am the author of both, I tend to say no. If there are other people involved then I select yes.

 

[Rob Nix]

A simple way, for a smaller company, to ensure that when one document is changed, all related ones are considered also, is to create a matrix where you list all documents (procedures, instructions, forms) horizontally and vertically; and then put check marks where they intercept when they are related.

 

[Wes Bucey]

Okay...documentation structure for us is...

Manual
Required procedures...top level doc's on those 6 items
Work Instructions...detailed 'how-to' tasks...how to verify the tensile machine, how to tap a heat, how to change a wiget on a gizmo...
Forms....tables, templates, matrices, etc.

Using a document software package, we can link associated documents together. In other words if SOP Alpha references WI Beta in it, down in the 'Related Documents' field, we insert a link to WI Beta...and vice versa as appropriate.

So, let's say SOP Alpha is changing...our software program prompts us "Do you wish to notify the authors of associated documents about this document change?" Yes or no....if I am the author of both, I tend to say no. If there are other people involved then I select yes.

This is excellent forethought, Roxane. It is the essence of Configuration Management that consideration be given to ALL associated documents and processes when modifying ANY document or process.

Care to share the brand of your Documentation Management software? I think it might be worthwhile to start a thread under Documentation and Forms.

 

[RoxaneB]

This is excellent forethought, Roxane. It is the essence of Configuration Management that consideration be given to ALL associated documents and processes when modifying ANY document or process.

Care to share the brand of your Documentation Management software? I think it might be worthwhile to start a thread under Documentation and Forms.

I wish I could say it was my idea, but it is an inherited system....my predecessor's predecessor. But the aspect of related documentation that has been more prominently used during my time in this department has been listing not only documents controlled within our management system, but documents outside of the management system (e.g., additional software packages like Purchasing, reference books provided to us by our Brasilian parent company, etc.).

I thought there was a thread somewhere in the Cove where we discussed software packages, but my organization uses QSi...recently purchased by IBS. They have software programs with modules for ISO 9001, QS9000, and ISO 14001. We elected not to purchase all programs...just the ones that were of greater value such as the electronic training records database (which allows for self-training online), document control, and a few others.

I think Rob's idea of a matrix for a smaller organization is excellent! I don't know the size of Rachel's organization is (haven't checked her profile), but it was great of Rob to point out that an expensive option isn't always the best option!