ISO 9001 2015 Documentation for Engineering and Design

[cferrer]

Hello Everyone,

Could you help clear out my confusion about where do the different design documents such as sizing arrangements, mathematical calculations, dimensioning, configurations overview concept documents, etc. , fall within the pyramid hierarchy of documents of a QMS (i.e. Policy, Procedures, Instructions, forms, records...).

And how about the knowledge-base? where does this fall under. We have a repository of technical descriptions and guidelines. Are this considered procedures, forms, instructions?

Thanks in advance

Chris

 

[John Broomfield]

Hello Everyone,

Could you help clear out my confusion about where do the different design documents such as sizing arrangements, mathematical calculations, dimensioning, configurations overview concept documents, etc. , fall within the pyramid hierarchy of documents of a QMS (i.e. Policy, Procedures, Instructions, forms, records...).

And how about the knowledge-base? where does this fall under. We have a repository of technical descriptions and guidelines. Are this considered procedures, forms, instructions?

Thanks in advance

Chris

Chris,

I understand your desire for a rigorous hierarchy of documents commonly found in hard copy parts of documented management systems. The structure made the management system easier for users to navigate and find exactly what they needed.

That structure with its document coding scheme made hard copy systems easier to administer too.

But with electronic procedures and their hyperlinks to instructions, forms and tools we are seeing more and more that every doc is controlled as part of its parent procedure.

Be careful to separately control design inputs and outputs as records that may be tied to each project. Indeed, each drawing is controlled as a project document until it is superseded or updated to become the “as built” or project record

So, let’s take a look at the docs you identified:

- sizing arrangements - serves as a project instruction before becoming a record unless standardized across your practice when it would be controlled as an instruction

- mathematical calculations - record

- dimensioning - normally standardized practice-wide, so an instruction

- configurations overview (concept documents) is an output of the conceptual design stage before it becomes a record as detailed construction drawings take over.

Your knowledge base is a reference library and its documents (records really) are not subject to revision control. Again, today’s search engine savvy users prefer keywords in place of hierarchy.

John

 

[Pancho]

Hi Chris,

I understand your confusion. Many documents such as you describe do not fit into the classic descriptions. Drawings, for example, provide evidence of your design (could be records) but they also provide instruction to installation crews (could be work instructions).

Fortunately, the standard does not restrict your documents to the "pyramid" that you mention. Section 7.5.1.2 requires the QMS to include "documented information determined by the organization as being necessary for the effectiveness of the quality management system". ISO 9000 defines documented information as that created in order for the organization to operate, as well as to provide evidence of results achieved (records). So you are free to have "technical descriptions", "technical guidelines", "Mathematical calculations", "Drawings", "work orders", etc.

In our QMS wiki we have a forum for "Technical Notes" where we keep documents like internal descriptions and guidelines that our engineers regularly consult even though they are not part of any particular work instruction. We also have different forums for each project, where we keep the calculations, design reports and drawings for that project. The information is then used where required without worrying too much about what the document category is.

Hope this helps!
Pancho

 

[cferrer]

Hello Guys,

These are very insightful explanations. Thanks you very much!

Coincidently, I haven’t been able to stop thinking about this so in the mean time I was brainstorming and wrote a few things down so I thought I would share it.

Mechanical Design:

• Drawings and 3D Model --> drafts for design review, not controlled
• Drawings and 3D model finalized --> production planning and assembly instructions
• Drawings red-lined from assembly --> ??
• Corrected drawings and 3D model --> Final system documentation, i.e. as-built records

Electrical Design: Similar as mech. Design

Systems Engineering:

• Hardware Design concepts --> production planning documents
• Communications and interfaces design notes --> production planning documents
• Engineering calculations and dimensioning decisions --> internal to systems engineering, not passed down. Is this a record?
• First-draft PLC Programs, state machines, operating concepts --> I guess same as above
• Parametrizing/Configuration data --> I guess it is like an appendix to a work instruction
• Final system performance and hardward configuration compendium --> I guess what one would normally call the system specification (perhaps a record)

R&D (knowledge-base, not controlled):

• Project reviews and technical Lessons learned
• Sizing and calculation guidelines
• Design Guidelines
• Technical Descriptions
• Product or replacement Investigations
• Market or technology research
• Product benchmarks

I guess the collection of all records from each of these departments is what the medical device industry would normally refer to as "Design History File" (DHF), correct?

However, I am starting to realize that I just have to „think outside the box“ more and think in tags in today’s dynamic and multidimentional environment.

I guess my real questions are:

Are our engineering documents percieved and treated correctly?

Which engineering documents do I really want/need to control as a small company ?

What is the best strategy for a small company to achieve design (quality) assurance without making the mistake of controlling too much and thus exposing too much in case of an audit?

Any thoughts?

 

[srinivasbom]

hai my friend.
am srinivas, i was assigned to iso 9001:2015. my company is engineering contracting company takeover the maintenance projects in the field of mechanical, electrical and instrumentation departments of Power Plants and Oil & Gas companies. we are just started the preperation of quality manual. which clause do i need to include and which are not to include, can you please guide?

 

[AndyN]

Hello Everyone,

Could you help clear out my confusion about where do the different design documents such as sizing arrangements, mathematical calculations, dimensioning, configurations overview concept documents, etc. , fall within the pyramid hierarchy of documents of a QMS (i.e. Policy, Procedures, Instructions, forms, records...).

And how about the knowledge-base? where does this fall under. We have a repository of technical descriptions and guidelines. Are this considered procedures, forms, instructions?

Thanks in advance

Chris

Chris: You are labouring under an old model. ISO 9001 never required such a structure, despite the fact that it became commonly used. Furthermore, this structure ended up CREATING the problem you are wrestling with - trying to pigeon hole documents document classifications totally artificially.

Similarly, unless there's a compelling reason for you to do this, your quality manual should only be like a "quick-start" guide, like you'd get with a new item of electrical equipment (not like the full blown user manual you also get)

I'd avoid creating a monster you'll have to feed from now and for ever...

 

[AndyN]

hai my friend.
am srinivas, i was assigned to iso 9001:2015. my company is engineering contracting company takeover the maintenance projects in the field of mechanical, electrical and instrumentation departments of Power Plants and Oil & Gas companies. we are just started the preperation of quality manual. which clause do i need to include and which are not to include, can you please guide?

Please see my other post...

 

[John Broomfield]

Chris,

How about consulting the creators and users of engineering information to determine their objectives of the process: controlling documented engineering information?

You may find it goes something like this:

“Valid engineering information readily available to authorized users and invalid information withdrawn from project use”.

Once you have this process objective you can then see if the existing process is effective. If it isn’t then issue a CAR to define that nature of the nonconformity and to engage creators and users in removing the root causes of this processes’ failures from the system.

You may also be able to engage some of the creators and users in mistake-proofing their process so they’ll be more inclined to make it work effectively.

Proposing solutions looking for a problem may result in pushback.

Better to define and agree upon the problem that needs to be solved.

Best wishes,

John

 

[cferrer]

Hello Everyone

Your inputs are very interesting indeed. I thank you all for your input and your time and for keeping the spirit of helping.

Greetings,

 

[billyjack332]

Are basic AWS weld symbols on a production released drawing a ISO 9001 :2015 requirement ? Please advise.