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

[Paul Simpson]

IT is the only one discussed so far.

Fully agree. I don't think any of us were disputing the role that key processes play. I think I even stated as much in an early post in this thread.

I think if you look at earlier threads there is a ot of disagreement about what are core processes and what are not. There are threads going back to before the new standard came out (still calling it new after 5 years!). Here are a couple I found quite easily.

http://elsmar.com/Forums/showthread.php?t=5695

http://elsmar.com/Forums/showthread.php?t=4172

But, as it comes to support processes, we seem to agree on most examples, except, for this one.

I don't agree that there is any consensus.

I don't know, perhaps IT supporting activities are different in the UK than in USA.

I doubt it very much, we all use global companies

I agree with all these selections, and mentioned calibration and maintenance in my previous post as well. All supporting processes. All important.

I wouldn't say that calibration or maintenance is a support process on its own, either. Maybe a sub process to one of the "manufacturing" or "testing" processes or in a business infrastructure process somewhere.

I just cannot understand why you see supporting the computer and software and data a company uses is any different than supporting gages. To me, it seems completely parallel.

You assume I agree that calibration and maintenance are support processes. In their own right they are too small to be processes. They may be sub processes to some business planning process but in their own right they still don't get to the edge of my radar.

In any case, there is no sense beating it to death. In the end, my clients will choose and I have no issue if they select IT Support as a process or not. You may pursue your approach as well.
We'll just have to choose to disagree.

So nobody moves any further forward and we will have this debate over years to come and always end up with ... we will have to agree to disagree. It would probably help if we could deal with points in the debate as they come up. Otherwise it is just contradiction .... no it isn't (apologies to Monty Python).

 

[Paul Simpson]

No

Hello Paul:

Is SPC a process?

Thank you,

Dirk

Not even close. SPC could be part of a support process on measuring. I still think of core processes as starting at the customer and ending at the customer. Anything else fits in as either a support process or as part of a core process.

 

[Helmut Jilling]

So nobody moves any further forward and we will have this debate over years to come and always end up with ... we will have to agree to disagree. It would probably help if we could deal with points in the debate as they come up.

Well, sure, it would be nice to come to a logical consensus. But, I have presented my arguements, and you have disagreed. You have presented yours, and I have not seen the logic of your position.

So, unless either of us has any further insight to share, I don't see benefit to beat it further. Otherwise, we just reiterate the same points over.

We often agree on other topics, but not this time.

I don't see where the size of the process is the criteria. You cited recruitment as an example of a support process. I'm OK wiith that. But, it too, is a pretty small process, so size cannot be the criteria.

The ISO standards allow the organization to define the processes. Unless they are grossly wrong, the auditor must accept what the organization has defined. I don't see any authorization for auditors to debate the selection, unless they are demonstrably unacceptable.

As I indicated, about half of my clients identified IT as a process, and half did not. Which half is correct?

We'll agree on future discussion threads.

 

[Jim Wynne]

So nobody moves any further forward and we will have this debate over years to come and always end up with ... we will have to agree to disagree. It would probably help if we could deal with points in the debate as they come up. Otherwise it is just contradiction .... no it isn't (apologies to Monty Python).

You might recall that when I courageously jumped in earlier I said that unless terms are well-defined, debates will degenerate into bilateral gainsaying. I was thinking of The Argument Clinic when I said it. After everyone understands the terms and they still disagree, it's probably not going to change, unless some compelling new argument occurs to some one. No sense flogging a dead horse.

 

[vanputten]

2,147 Views

What concerns me the most about this discussion is that there have 2,147 views of the thread. We still haven't defined what we mean by "process." I believe that Paul is trying to make a case that in certain organizations, certain things are not customer oriented processes, or may be supporting processes. But they way it is presented, it appears as though it is being stated as fact across all organizations.

To say that SPC, calibration, or maintainance is not a "process" and I mean any kind of process ("core", "sub", "supporting", customer oriented), is pure lunacy. They might even be many processes. The AIAG printed an entire book on SPC and it is not a "process?"

Choose to define processes how you want. Agree to disagree.

We've beat an undefined, dead horse to death. I agree with hjilling and Jim Wayne and I do not understand Paul's point.

Regards, Dirk

 

[Paul Simpson]

More pure lunacy

It is time to corral the wagons or beat a dignified retreat. As there doesn't seem to be much of a thread to this thread I'll do the latter.

But first ....

The reason I try and get some agreement on the process approach is:

1. It is supposed to be the core of 9k2k
2. From the details in this (and other) threads there is not a consensus about what a process is
3. We also don't seem to be able to differentiate between core processes and support
4. If we as professionals can't agree what hope is there out in the field?
5. If consultants, organizations and assessors don't agree that is a ripe area for conflict

Please see attached process map. It is very simple (better to illustrate the argument).
There are three core processes in this particular depot. A service / maintenance activity, a cleaning process and (occasionally) a repair / modification service provided to vehicles. These are defined as the core processes - i.e. the ones the customer is paying for.

There is one process that supports all of these - the planning activity where this organization talks to the customer, arranges for vehicles to be available at the agreed programme for the service or cleaning operations.

There is also a business planning process for providing (short term and long term) the resources the business needs and a separate process for monitoring these processes against objectives set in the business planning process and feeding back into the review process.

Anything about specific departments and sub processes on this interrelationship map is just fog, IMHO! Hence no IT Management and no SPC.

It may be I have been a bit abrupt in my posts but it is because I believe we need to agree principles here. The details we can disagree on to our heart's content.

 

[harry]

Hi Paul

I wish to thank you and hjilling for the very interesting exchange. It sets our mind thinking and in the process we gain new knowledge.

Depending on which angle I am looking at things, I think both you and hjilling are not wrong.

Take for instance invoicing. It is definitely a support process to you. However, in a scenario where payment for goods sold/collection are a serious problem and the problem is so bad that it cascades down the whole system affecting purchase of raw materials and finally finished goods - does this seemingly not so important support process become an important or core process? For failure to address or monitor it may result in inability to supply your product and finally disrupting the production of your client.

In other words, I think the interpretation should not be too rigid as we are part of a business which is subjected to influences and changes in the environment surrounding us.

 

[Paul Simpson]

Don't confuse support with unimportant

Hi Paul

I wish to thank you and hjilling for the very interesting exchange. It sets our mind thinking and in the process we gain new knowledge.

Thank you harry, I hope the entertainment value alone is worth the entrance fee .... waddaya mean it's free?

Depending on which angle I am looking at things, I think both you and hjilling are not wrong.

Now we've agreed to disagree - apparently I'm alone in thinking I'm the only one marching in step! Still being alone has never been a problem for me on the cove.

Take for instance invoicing. It is definitely a support process to you. However, in a scenario where payment for goods sold/collection are a serious problem and the problem is so bad that it cascades down the whole system affecting purchase of raw materials and finally finished goods - does this seemingly not so important support process become an important or core process?

There are arguments that invoicing (or "getting the money in" as I prefer to call it - as that emphasizes that it cuts across departmental boundaries) is a core process as it interfaces with the customer at one end.

But anyway my point on support processes is not to demean them, they are, as you rightly say, important. Paying their invoices is the way the customer gets to pay our wages after all. You should manage all the support processes as you would your core processes. The finance department is well known for measures related to creditors and debtors payments in terms of the number of days.

For failure to address or monitor it may result in inability to supply your product and finally disrupting the production of your client.

So again you have process measures in place for these support processes - you can even have process measures in place for the smaller support activities like calibration, maintenance, IT support, data backup etc. But if you start to call these activities processes people concentrate on them rather than focussing on the core processes the customer pays for.

In other words, I think the interpretation should not be too rigid as we are part of a business which is subjected to influences and changes in the environment surrounding us.

The point I am trying to make (albeit very badly) is that there is a principle behind the process approach that processes cut across departmental boundaries and the process measures give everyone a focus on the overall process objective - satisfying customer requirements. If you allow everything to be labelled a process and give it a place at the "high table" then you can't get the focus on the important few measures of organizational effectiveness - or quality if you will.

That is why you need rigidity in the principles and flexibility in the application.

 

[Jim Wynne]

So again you have process measures in place for these support processes - you can even have process measures in place for the smaller support activities like calibration, maintenance, IT support, data backup etc. But if you start to call these activities processes people concentrate on them rather than focussing on the core processes the customer pays for.

Can you name a process that the customer doesn't pay for?

The point I am trying to make (albeit very badly)

Don't be so hard on yourself--leave that to me

In all seriousness, I still say that it's definition of terms that's the problem, and I think you're saying something similar. I disagree in trying to narrowly define "process" though; jargonizing something rarely assists in clarification, and often further obscures the thought being conveyed.

Here's the problem, imo: ISO 9000 and TS 16949 call for a process approach, but companies aren't set up that way, and the people in charge of the QMS have no power to change it. Manufacturing companies have departments, and there are walls between them. The intent of the process approach is to drill passages through those walls, if not break them down altogether. But executives like their walls, and managers like having their spheres of authority definitively circumscribed. "This is my bailiwick, and these are my people, and we'll do things my way." Enter the hapless management representative, an earnest type who has been granted responsibility and no authority, who is expected to erase those carefully drawn and jealously guarded lines and take the pork chop out of the hungry tiger's mouth. Good luck. Under those circumstances, is it any wonder that five people will give five different answers as to what a process is?

 

[Paul Simpson]

Can you name a process that the customer doesn't pay for?

I can name a few that the customer doesn't think they pay for but realize that's an answer to a different question - so point taken. In my defence - I did say the customer pays the wages!

Don't be so hard on yourself--leave that to me

I know I can rely on you to jump on any stray posts, Jim. Still you're not as harsh as that JSW05!

In all seriousness, I still say that it's definition of terms that's the problem, and I think you're saying something similar. I disagree in trying to narrowly define "process" though; jargonizing something rarely assists in clarification, and often further obscures the thought being conveyed.

I agree.

The ISO definition of activity that transforms inputs into outputs means everything becomes a process. I was just going through a typing process on the cove .... can you imagine the process interrelationshp that has all those on it.

We need a debate about what is a company level process and what is not - I have put my marker down and there are a few others down now, too.

Here's the problem, imo: ISO 9000 and TS 16949 call for a process approach, but companies aren't set up that way, and the people in charge of the QMS have no power to change it.

Now I think companies are set up that way originally but then the departments get in the way. I agree QMS people are not empowered to change it - but only because there is no consensus on what a process approach organization is! If there were the MR could go to their MD / CEO and say: "Look if we don't have our QMS looking something like this then we don't get the certificate our customer says we need to have." This is all exacerbated by the current crop of registrations where some companies have been waved through with an ISO 9001.1994 system with a couple of flowcharts attached. Something the CB / Registrar has to deal with.

Manufacturing companies have departments, and there are walls between them. The intent of the process approach is to drill passages through those walls, if not break them down altogether. But executives like their walls, and managers like having their spheres of authority definitively circumscribed. "This is my bailiwick, and these are my people, and we'll do things my way." Enter the hapless management representative, an earnest type who has been granted responsibility and no authority, who is expected to erase those carefully drawn and jealously guarded lines and take the pork chop out of the hungry tiger's mouth. Good luck. Under those circumstances, is it any wonder that five people will give five different answers as to what a process is?

Nicely put. Goes back to either a MR that has the clout to be able to say to the MD / CEO "Look this is the problems we get with the "Over the wall" management system" and be able to show some numbers as to problems / delays caused by the departmental silos. Then to sell the short term pain / long term gain of a process approach where organizations are aligned - very similar to the lean philosophy of Toyota's system. Or the alternative is you get the certification / accreditation bodies getting serious about only issuing certificates to organizations who really do "get it."