Starting Fresh or Keeping your QS procedures?

[SteelWoman]

We just had our first TS Transition Team meeting in which top management was involved - up to this point the Quality people did a preliminary gap analysis and put together some basic information for this first meeting. One of the first things we discussed today was the REQUIRED procedures for TS versus the QS procedure-based program - do we want to take advantage of the opportunity to DITCH some procedures and change them to control plans or process flow diagrams to show the process or do we want to keep the existing procedures as the foundation of the new TS program. After MUCH discussion the Mgmt group decided to keep the procedures for non-machine processes (like sales, purchasing, etc) and keep ONLY the control plans for machine processes (eliminating what were "duplicate" procedures for those processes). Of course we'll work into the mix the required interaction of process documents, define the processes, etc.

Anywho, I'm just curious about how the rest of you folks are approaching this - are you tossing it all (but the required 7) and starting fresh, or building off the QS foundation that is already there?

 

[Sam]

We developed our TS2 process based the existing QS process and was completed in about six months. As we progressed through the development and identified processes we found that we could eliminate some procedures.

 

[Marc]

We just had our first TS Transition Team meeting in which top management was involved - up to this point the Quality people did a preliminary gap analysis and put together some basic information for this first meeting. One of the first things we discussed today was the REQUIRED procedures for TS versus the QS procedure-based program - do we want to take advantage of the opportunity to DITCH some procedures and change them to control plans or process flow diagrams to show the process or do we want to keep the existing procedures as the foundation of the new TS program. After MUCH discussion the Mgmt group decided to keep the procedures for non-machine processes (like sales, purchasing, etc) and keep ONLY the control plans for machine processes (eliminating what were "duplicate" procedures for those processes). Of course we'll work into the mix the required interaction of process documents, define the processes, etc.

Anywho, I'm just curious about how the rest of you folks are approaching this - are you tossing it all (but the required 7) and starting fresh, or building off the QS foundation that is already there?

You suggest there are redundant procedures or that parts of existing ones overlap excessively. Before I would change a thing, I would be sure to understand why and how the current system, which you feel is bloated, came to be. Did QS really increase your systems documentation?

I say this because when I look back, there were so many times a procedure was required but not a documented procedure. In the cases where there was a 'way of doing something' that everyone understood and did the same way, we verified by interview. In that way we eliminated a lot of documents. I have long pushed this methodology, and whilst this link is to a 1999 e-mail, I started this 'minimal documentation' approach (including flow charts instead of text procedures, particularly for systems {as opposed to, say, WIs}) back in 1994. See http://Elsmar.com/level2/accolades.html#document. I used this approach with Motorola in the semi-conductor sector QS9K implementation back in 1997-98 so I know it is applicable to large corporations.

I have attached a couple of .pnt files and the powerpoint source file (the .pnt export isn't very good). Granted, this is basically ISO - but the comparison holds to some degree. Has anyone put together a comparison of documents required by: QS9K vs. TS 16949 vs. Customer Requirements (the key words are 'Customer requirements' - when you consider Customer Requirements, will you really be in a position to decrease documentation requirements)?

I'm not up to date with TS. I'm catching up. After a year of working with Stolle as the Harley-Davidson QE (as well as the Visteon and Valeo Greensburg QE), I'm back in QS mode. But when I looked at this a couple of years ago I wrote: "TS-16949 does not change anything except to allow the automotive companies to regain individual control over more of the specifics (such as exactly how they want their APQP process followed - specific paperwork, etc.) More than anything, TS-16949 generalizes QS-9000. In addition, it brings in a few things from the German VDA document as well as Italy's and France's national requirements. For those seeking some relief, whatever TS-16949 leaves out is picked up by individual requirements. Relief will be, hopefully, in interpretations, if at all. Automotive is automotive." Was I off base in this evaluation?

I guess what I'm getting at is the evolution of the system(s) and documentation. Just as we can track processes, we can look at systems and ask why they evolved as they did. Was there less documentation before implementing QS-9000 (or ISO 9001 for that matter)? Did the increase in documentation help? Note: From all the 'success' stories I've read about how QS (or ISO) implementation did so much good, I almost have to assume that this is true. I am really interested, as you proceed, what you find. And I'm interested in what others are experiencing.

 

[SteelWoman]

Good reply, Marc. Basically, I'm trying very hard to step outside this QS system I've lived with for lo these many years and look at it with "fresh eyes" since I have a chance to change it for the better with TS. Unfortunately, my MRT took the stance that they want to KEEP as much as possible in place (an "it ain't broke, don't fix it" combined with "how can we achieve TS certification the QUICKEST" tact). But I've always felt some of our "documented procedures" were redundant duplications for the sake of having procedures.

Question: When you say you advocate "processes" where the standard requires a process but doesn't necessarily require a "documented" process, you're also saying that has flown in an audit - that the personnel interviews are sufficient to confirm the process? This is blowing my little tiny QS mind - I'm so used to being asked for a procedure and it's related controlled documents. For instance, I JUST had a meeting today with a guy from Maintenance - the TS standard in 7.5.1.4 talks about us having a system for effective planned maintenance and the only real documenting it talks about is documenting, evaluating and improving maint objectives. In the course of our conversation, he told me that he does have a process for inspecting tools used by his maintenace guys and a form they can fill out to get a tool replaced when it's in disrepair. You're saying in this kind of case TS is just vague enough that I DON'T have to have a "procedure" for that AND don't have to make that form a controlled doc, as long as I DO have the process in place? That's a very "freeing" concept my QS-indoctrinated brain is struggling with.....