Responsibilities in a Process Flowchart

[energy]

How important is it to show responsibilities (who) for functions on a process flow chart? Is it? If it is, how do you address this? Would the flow charts have to be tiered in such a way as to show who is responsible for a particular function?

 

[Michael T]

Hmmmm....

Hey Energy...

I think responsibility is important, in a general way.

We address this by having an Approval Chart that shows the individuals who are "approved" (through training & supervisor verification) to the procedure. Anyone who is "approved" to the procedure is ultimately responsible for the function. Individual responsibility (by job title) is not listed on the flowchart except in those instances where the procedure is specific to an individual's job description... For example: a Failure Analysis procedure - the only person authorized to conduct the FA is the FA Manager who has been specially trained in metallurgy, etc.

Hope this helps.

Have a great weekend... hope the fishies are bitin'

 

[energy]

Curious

Michael T.,

The text procedures always had a place for responsibilities and duties. I can envision showing an Auditor my beautiful flow chart and he/she asking, "Who does that?" or "Nice, but where does it show who are the key players?" Maybe it's just me, but I would ask it. "Is this done by your people or an outside source?" "How do I know who to question on this procedure?"
I understand how you have done it, but isn't there an easier way? Because we are talking about the new version of the standard, with the emphasis on process flows, the reference flow charts that I have been looking at, are devoid of responsibilities. I believe it's because they were mainly used as attachments, or overviews, of a text procedure where responsibilities were identified. Any other ideas out there from this talented group? Well, some of you are. Now you know I jus maka da funny joke, yes?

 

[energy]

Confusing

The "problem" came up when I was looking at Engineering's version of what used to be called Contract Review. The Engineering Manager crafted his flow chart in Visio with three sections identified. Vision a flowchart with two horizontal lines that divided the chart into three sections. In the left margin were the three groups responsible for the activities. All processes were connected with these demarcation lines running through them. All the other charts we have, (mine) are not designed that way. I want to remove the lines and make them uniform. Actually, I already did. The VP Engineering said ISO requires responsibilities, he thought. So, I started thinking. That's why I posted.

Jim, you say we only need 6 procedures. I've heard that before, I just don't believe it enough to fight an Auditor with your post or any others advocating this. I'm not a brilliant guy and wouldn't know where to begin. So, we will have flowcharts/procedures where we think they are needed. The driver is "could we do this process without having somebody remember what it is". Like, a new person coming in and being asked to perform it. Would it be helpful having it documented? Monday, we'll have some more input and see where it goes. Thanks.

 

[Kevin Mader]

energy,

I am familiar with the Visio template that uses the sectioned areas to illustrate what function does what. To be honest, I found trying to use this template to difficult and created a muddled composition when trying to illustrate complex processes.

I personally believe that it is important to indicate responsibility if the flowchart is a stand-alone item. Jim raises an interesting point in regards the supplementary use of flowcharts in place of traditional practices. I believe that the use of flowcharts exclusively is probably not appropriate. I have used them mostly to illustrate the procedure's flow and to minimize the verbiage in the procedure.

Kev

 

[M Greenaway]

In a book I picked up a while ago called 'Process Management for Quality Improvement', which pre-dated ISO9001:2000 by some years, it spoke of process mapping (as opposed to flowcharting) where the process 'box' was split. In the top half was the process descrption and in the bottom half was named the responsibility.

Easy peasy.

 

[energy]

Re: Re: Confusing

Jim Wade said:

I said "In the six cases where we are required to have a documented procedure, or where we choose to have one ... ".

I'm not shouting....

And where we choose not to have procedures, responsibilities still need to be defined and we can do that any way that suits us.

rgds Jim

YO SCREAMER Okay, Let's suppose I decide to not have a procedure for Purchasing or Customer Supplied Product or any number of sections of the standard, that are not mandatory. What would an Auditor ask to verify if any of these sections have been addressed? Assume that I don't have a written anything for the two areas I mention above. Ask me. Martin, you too. Maybe I can get a feel for what I really need.

Kevin, you are absolutely correct on the muddled thing with the Visio template. That's why I do not want to do mine over. I really liked his chart, but I'm jammed for space as it is, and more important, I'm lazy. Maybe if had started from scratch, but they're done.

 

[Marc]

Jim Wade said:

And simply flowcharting a procedure does not give you a process description!

A 'simple' flow charting procedure may not be sufficient for a process description, however I have seen and done flow charts which are quite sufficient. I have even seen flow charts with appendixes in which details were laid out. I have also seen flow charted process where they did this in a face page.

You really have to ask how complex the process is which you want to flow chart and apply an appropriate covering methodology and format.

As far as responsibilities, I recommend every step be in a text block beside the step or in the step shape its self.

Don't over complicate it and don't under estimate what you can do with a flow chart. I have been a process mapping and flow charting fan for years. In fact, I address process mapping and give a methodology in my Implementing ISO file. One might say a process map is nothing more than a glorified flow chart but now we're into semantics related to total content, general intent and to some degree format. Basically both are linear representations of what occurs.

 

[energy]

Woe is me

Jim Wade said:

But at least one one thing is for sure: a process and a procedure are two different thngs (see ISO 9000:2000 definitions).

And simply flowcharting a procedure does not give you a process description!

rgds Jim

Imagine my dismay when I present our, whatever you call it, to an Auditor for Cause and Corrective Action and he tells me that it's a flowchart and not a process description. Imagine that this would really happen. Just imagine!

And, I see no question similar to what we may be asked. I do see a lot of theory steeped in narrow interpretations.

 

[Marc]

Jim Wade said:

But at least one one thing is for sure: a process and a procedure are two different thngs (see ISO 9000:2000 definitions).

This does not mean that each cannot be represented in a similar fashion. The fact that they are different does not preclude their being represented using a similar methodology including a similar format.

If an auditor told me I could not use a flow chart methodology for one or the other I'd tell him/her to take a hike. It's the totality of the representation that matters. It's a function of the contents and the intended use - not the methodology.