SteelWoman said:
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.