What is Your Favorite Format for Systems and Procedures?

[TownDawg]

Favorite Format??

Hello, and good morning. I am in the midst of bringing a fairly new start-up company to ISO/TS 16949 compliance. (joy!)

I have been toying with several different ideas to present my QPs and WIs -- but still struggling to find the 'perfect format'. My current drafts use a Visio cross-functional flowchart for my QPs and a detailed word document (like the older QS formats with scope, responsibilities, records, etc.. etc.. ) for my WIs.

My corporate 'advisors' seem to think I haven't found the perfect way to get this done tho -- so I am in the search. Does anyone have a template they really like? -- that meets all the TS requirements?

Thanks in advance.

 

[Valeri]

ISO/TS 16949:2002 does not require the use of process maps.

You can use policies, procedures, work instructions, etc. as long as you can show "process flow".

We have 7 out of 8 plants (#8 due in March) certified to TS - all I did was create a "15,000 foot" process map for each "section" of the spec. and combined the (21) QS-9000 procedures into (5) for the TS spec, making sure the additional requirements were identified within each and linked the procedure to the appropriate map.

 

[TownDawg]

I got way too many questions, and prolly way too many pieces of background information to get it all posted here.

Are you too busy to just call me here at work?

 

[Mike S.]

Dawg,

I'm of the opinion that the procedures and WI's need to suit the user(s) so I have no single favorite format. Who will be using each document the most? Maybe consult with the users and see which type of presentation format they prefer, how much detail they need, etc. This may vary greatly from document to document. I use a combination of flowchart only, text only (maybe with some pictures and/or charts), both flowchart and text, and sometimes no document at all -- training only where appropriate. Hope this was helpful.

 

[howste]

That's exactly what I was going to say. Thanks for saving me the trouble, Mike!

 

[TownDawg]

Well I guess what I am struggling with.. What HAS to be in the content. I am hearing that I have to identify my inputs, my outputs -- I am hearing that I have to show scope, application etc.. and yes -- you are right.. the input I am receiving from corporate is not a problem with my FORMAT.. the idea looks good.. They are telling me that the documentation does not meet the standard, in terms that all of the items that HAVE to be addressed in the content of my documentation is not clear or addressed completely.

Hrrm.. where's that free consultant when you need them?

 

[Mike S.]

Dawg,

That's a bit tougher nut to crack! I'm not familiar with TS16949 but there are many practicing and practical experts here who are and I'm sure they can provide some fine advice on specific questions. And there are some fine consultants available too (but not for free outside of the advice they give here on the Cove). And you might try contacting Marc, the site host, about his services from private consulting to access to "premium files" on the site.

But, in general, everywhere the word "shall" appears in the standard, you have to have the "shall" addressed in some appropriate way.

And try the search functions whenever you have a specific question -- it is likely your question has been addressed before. There are examples of ISO9001 manuals and procedures, and probably some from TS16949 as well.

 

[TownDawg]

Thanks everyone for your input. I got some good information here on this forum, and some additional private messages and phone calls as well. Let me go take about 4 aspirin, and get started on this again.

Again, thanks!!

 

[howste]

...I am hearing that I have to show scope, application etc...

If this is being said, I'd question where the requirement is. The only document required to have a "scope" defined is the quality manual, and it's the scope of the entire QMS, not the document. No document is required to have an "application" section. When TS 16949 requires a document, it also defines what is required. If there is no "shall" in the standard, you've got flexibility in what the content is.

Example: 8.3 requires a procedure. "The organization shall ensure that product which does not conform to product requirements is identified and controlled to prevent its unintended use or delivery. The controls and related responsibilities and authorities for dealing with nonconforming product shall be defined in a documented procedure." In some format then, you need to define
- controls to ensure nonconforming product is not unintentionally used/delivered
- responsibilities for the above
- authorities for the above
Anything else you include is only there for your own business needs and/or preference. I'm attaching one of my clients' procedures that meets the requirement. I'm not saying it's perfect, but it meets their needs.

I hope this helps...

 

[db]

Just to piggyback on howste, required documents must also meet the requirement of 4.2.3. But once again, how you do that is up to you. For example, 4.2.3 e) requires in part, that dcouments remain readily identifiable. So, how do you identify your documents; by name, number, shape, color? I don't know, pick your poison.

My favorite way is to do everything in HTML, and then you can give them all of the glitze and glamor of the internet. But the "what will these things look like" is only constrained by what works (and doesn't) for you.