Will a one-process approach to ISO/TS 16949:2002 fly?

[Barahir]

We're getting ready to undergo transition from QS9 to TS2, and the first order of business is to get our processes defined. Here's my thought. Since TS2 says that the organization defines their processes, is there any reason that we can't say that we have only one defined process (Customer Satisfaction), and that everything else we do (from marketing to post-delivery services and everything in between) is a function/job/task/method of completing of that one process. I made up a general turtle diagram on what that would look like.

What I'm really wondering is if it would fly or not. I suppose the easiest way to find out would be to call our registrar/auditor and ask them if they thought it was doable, but I figured I'd use all you knowledgeable people as a sounding board first. What do you think?

 

[db]

I often use a similar tactic when working with new clients. However, if you think about what we want to do with processes, it becomes clear that a one process approach will become a nightmare. So, I then start taking the one process apart. We break it down into several COPs and even more SOPs. With some organizations, we end up going down several layers. For example, manufacturing may be a process. But if we examine manufacturing, you will find it is comprised of several processes, each of which we want to control separately. So, we break manufacturing down into those processes. One of those may be complex enough, that we want to break it down as well.

The key is not to look at identifying your processes, based on what the standard requires, but to look at them from the standpoint of what you want to do with the processes. That will determine how far you want/need to go.

 

[Jim Wynne]

We're getting ready to undergo transition from QS9 to TS2, and the first order of business is to get our processes defined. Here's my thought. Since TS2 says that the organization defines their processes, is there any reason that we can't say that we have only one defined process (Customer Satisfaction), and that everything else we do (from marketing to post-delivery services and everything in between) is a function/job/task/method of completing of that one process. I made up a general turtle diagram on what that would look like.

What I'm really wondering is if it would fly or not. I suppose the easiest way to find out would be to call our registrar/auditor and ask them if they thought it was doable, but I figured I'd use all you knowledgeable people as a sounding board first. What do you think?

Welcome to the Cove! I think it it's a great idea, which is why the registrar won't go for it. The registrar is going to want to see the details of "sub-processes" and their inputs, outputs and relationships. In a similar vein, I wrote this in a post yesterday in this thread:

Contrary to popular misconceptions, there is only one process, and it begins with the solicitation of business and ends with a profit-producing product (or service) in the hands of a happy customer. The object behind the identification of interrelated processes should not be to confirm the peaceful coexistence of disparate processes. It should be to eliminate the disparity and have everyone in the company pulling on the same end of the same rope.

 

[Craig H.]

Welcome, Barahir!

This is one of those ideas that, in theory, make perfect sense, but in practice can become cumbersome. That said, I see no reason why you couldn't include the turtle in the top-level document, and refer to process maps for the supporting processes. Without the supporting maps, though, I think most auditors will have you running for cover.

 

[Barahir]

We'd already identified what we believe to be our processes (see attached), but I was just thinking that going with the 1-process approach might be (for lack of a better term) easier and more focused way to go about transitioning our quality system to TS compliance.

Over the last six plus years that I've been in quality, my opinion on quality systems and the multitude of standards, be it ISO, QS, TS, VDA, etc. is that the ultimate goal of a company is to have a happy customer by getting them exactly what they want exactly when they want it. By doing this, you keep them happy and they keep coming to you, which is where you make your money (the main goal of a business according to most non-quality people I've spoken to about this). The quality management systems and the Standards and Technical Specifications are essentially there to have you put a system in place that will (hopefully) ensure that you can do this one thing (satisfy the customer) consistently.

My other thought about saying that we have one process (Customer Satisfaction) would be that by doing that it provides focus throughout the entire organization on what our end goal is. I think it would help to get away from the fractioning of jobs where an employee might currently say, "My job is to run this machine for 8 hours" to a mindset where the employee can see that his task is to run that machine, but his job is to produce quality product to keep the customer happy.

Anyway, I'm sure that this isn't anything new or fresh to anyone but I'm really hoping that this transition from QS9 to TS2 can really help shift the focus in the right direction.

Perhaps instead of looking at it from a standpoint of having 1 overall process, maybe a melding to the two and saying we have one customer oriented process (Customer Satisfaction) and then several sub-processes that assist that. And those sub-processes would be the ones that in the pdf file I attached I have listed up top as customer processes?

I've been given pretty much free reign here to determine the shape of our TS system, but the downside is that they want the manuals (Quality Manual, SOPs and Work Instructions) to be completed by month's end. So I've got quite a bit of work ahead of me.

 

[ralphsulser]

Barahir, I suggest you list your "core manufacturing processes" and show how they are linked by interaction and sequence. (preferably in a flow diagram) Then a turtle for each of the individual core processes showing inputs and out puts, sub processes, and support functions to that process. This is how we did it and the TS auditor liked it.
I have attached our over view process flow map. Hope this helps.

 

[Craig H.]

Barahir:

After your last post I am thinking that I approached this from a direction that was slightly off. What your last post has at the core of it, to me, are not necessarily the tasks and subtasks, but rather the overall objectives of the firm. As one of the lower-level processes would have process aims, so, to, does the big(est) picture you provided in your first post. Why not tie these main objectives to the overall turtle, then provide corresponding sub-goals for each lower process map? That way the line guys, and the support folks, and everyone else, knows how they can help "...increase on time delivery to 99.8%".

 

[Icy Mountain]

I agree with db and JSW05..you'll need to define more that one process and not just to satisfy and auditor. The overall process, "Find Out What Customer Needs" through "Put What Customer Needs on His Dock Better Than Anyone Else" will need broken down so that you can manage the goals and achievement thereof. In broad categories:

• Sales Process (ID What Customer Needs)
• Engineering Process (Design, Develop and Document What Customer Needs)
• Purchasing Process (Acquire What You Need to Make What Customer Needs)
• Manufacturing Process (Make What Customer Needs)
• Delivery Process (Stock and Deliver On Time In One Piece)

Now that you've got some controllable chunks, figure out which processes satisfy the TS requirements and connect them together so that both you and the auditor can figure out if you do.
The attached picture is worth a thousand words, each team in the yellow wheel is a process, the overlay of the TS requirements shows which processes are meeting a particular requirement.

...the ultimate goal of a company is to have a happy customer by getting them exactly what they want exactly when they want it. By doing this, you keep them happy and they keep coming to you, which is where you make your money (the main goal of a business according to most non-quality people I've spoken to about this). The quality management systems and the Standards and Technical Specifications are essentially there to have you put a system in place that will (hopefully) ensure that you can do this one thing (satisfy the customer) consistently.

You've hit the nail on the head here. Please, take a minute to consider the semantics. The ultimate PURPOSE of a company is to help a customer satisfy a need. Aligning everyone on that purpose is motivational because it gives meaning to the "job". The GOAL or OBJECTIVE is to make a profit while fulfilling your PURPOSE. "Let's go make a profit" is not very motivational.
I see compliance with TS as stabilizing the processes that fulfill the purpose so that you can Plan-Do-Check-Act based on real data rather than conjecture. That way you are not only satisfying the customer consistently but also ever more increasingly and efficiently (continual improvement!)
-Icy

 

[Jan C]

three cheers for ICY

You are very good at this ISO stuff, your answers are alway very well written and thought out! Thanks for taking the time to "train" us on a good quality attitude, which, after all is what it is all about.

 

[Jan C]

Now that I have done all of my sucking up , I am attaching my process map for improvement ideas. I don't know that I am that happy with it but it served the purpose I needed it to but I don't know what the auditor will think?