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? :rolleyes:
:ko: :smokin:

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' :D

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? :vfunny:
:ko: :smokin:

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.

:ko: :smokin:

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

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.

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 :biglaugh: 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.:bonk: :ko: :smokin:

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.

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!:biglaugh:

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

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.

To me the difference is who is going to use them and what they're going to use them for.

Jim Wade said:
Just trying to help, energy. :)
So what's your opinion or interpretation of the practical difference between a process and a procedure (bearing in mind the fact that the 'standard' tells us that they are two different things: see 9000 3.4.1 and 3.4.5)?
rgds Jim

Jim, I do appreciate the help. Really. But, you ask more questions than actually help me with a straight answer. But, that's what teachers do, ain't it?:lick:

To me, I show you a flowchart which contains our Order Entering Process. Shows what we do, inputs and putputs. That flowchart also represents a procedure that a new sales person can use to see all the things that are part of the process. Does it say "Sit by the phone and wait for a call"? No. If I flew up another 20, 000ft and look down, you can see now see other flowcharts all around that one. Guess you could now say that it's part of a overall process. Now, it looks like my flowchart of our Q Plan. The Q plan also shows specific steps in a process. Is it a procedure? To me, yes. Miss one of those steps and you are inviolation of the "procedure". Can you cite an N/C for violating a process?
I'm getting a headache and it's Sunday and almost time for that western decadent show "The Sopranos".

Incidentally, last night I watched an HBO Original Movie called "Gathering Storm" about Winston Churchill. Excellent. He really had a real hard time convincing his countrymen what was happening in the Rheinland. I must confess that I was fascinated by his "Bowler". :vfunny: Vanessa Redgrave and Albert Finney? were outstanding, as Mr. & Mrs. C. Rent it!:p
:ko: :smokin:

Isnt the requirement to document the sequence and interaction of processes, not the actual steps needed to perform the process.

By flowcharting the process steps hasnt the company taken the decision that it is a necessary control for product quality to ensure the process is conducted as described by the flowchart ? Isnt it therefore reasonable to point out at audit (or whatever) if a process is not being conducted in accordance with the companies planned arrangments defined in its flowchart ?

Thanks Jim, I think we have a common understanding of Process and Procedure.

So from Mr Energy's question about getting an N/C for violation of a process, is this in fact not applicable as a process doesnt describe a way to conduct an activity - that is a procedure (or flowchart) ?

Also going back to Mr Energy's question on what would be audited in the absence of a procedure, I would say that the process would be audited against the applicable requirements of ISO9001:2000. Clearly without a procedure the steps used to achieve the result would be insignificant compared to the actual effectiveness of the process - you dig ?

energy said:

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? :rolleyes:
:ko: :smokin:

The path I've chosen to follow provides a matrix of responsibilities/authorities (as process custodians) for each of the processes we have identified in our QMS. Then on the process flow charts the only reference is between a process user (operators/engineers/supv/etc...) and the process Custodian (manger responsible).

The matrix lists positions down the left and processes across the top, then in the grids use keys to identify responsibility (C = Custodian, I = Input, O = Output, R = Records, S = Supplier).


Here's my dilema though:
Before I left I made packets for each process custodian for their use to identify the key components of each process, including what documents they currently use...with the goal of reviewing and compliling process flow charts. Upon my return (5 weeks out) I find that nobody did anything! And yes, the plant manager was in my corner before I left...but the QA Mgr (after people started asking question that he couldn't answer) told everyone to hold off until I got back.

I came back so rested and excited about the project only to be slapped in the face.

Some days I think I need a new job now...rather than wait to the end of the summer.... I'm disgusted and frustrated by it all. Management tells me this must be done, I tell them the best case senario that needs to be followed in order to complete ontime, and then everyone just sits on their hands waiting for me to do it all! Well *()&%$)* THEM! :frust:

Thanks for letting me vent! :ko: Maybe I should switch the water to vodka in my water bottles.....
Eileen

Jim, Martin, Marc, Eileen, et. al.:

I think I just had a moment of panic/hysteria/frustration...

Am I understanding this correctly? For every process we have, we must have a process map? That process map should define all of the various interactions between related processes, define the procedures within that process, define the analysis, monitoring & measurement activities to be conducted, be documented and list the types of records kept and somehow show how management has reviewed and approved this?

Is this right? :confused:

Michael

I wonder if your choice of the word 'define' is intentional. ISO9001 requires us to 'define' a lot of things but this does not necessarily mean in a documented procedure. Procedures can be defined by, for example a computer system that only allows things to be done a certain way, or by custom and practice.

Michael T said:

Jim, Martin, Marc, Eileen, et. al.:

I think I just had a moment of panic/hysteria/frustration...

Am I understanding this correctly? For every process we have, we must have a process map? That process map should define all of the various interactions between related processes, define the procedures within that process, define the analysis, monitoring & measurement activities to be conducted, be documented and list the types of records kept and somehow show how management has reviewed and approved this?

Is this right? :confused:

This just came in from AQS. it's a seminar scheduled for next month. here's what they offer:

Learn how to map your processes

Make procedures and work instructions simpler and user friendly - cut down on Quality System documentation by 50%!

ISO 9001: 2000 requires the adoption of a process approach. Companies that develop effective and efficient processes are those most likely to succeed.

NEQC is pleased to offer this course again after training over 50 companies to help document processes, procedures, and work instructions effectively. Understand what process mapping is and how it differs from flow-charting and regular procedural text. Learn how to make your quality management system easy to develop, implement, and understand by all employees AND beneficial to the bottom line. This course provides the tools and methodology to identify your current business processes and provide a future roadmap for re-engineering your processes.

I will be attending. As for the differences,
I'll be the judge of that! :vfunny: :ko: :smokin:

M Greenaway said:

Michael

I wonder if your choice of the word 'define' is intentional. ISO9001 requires us to 'define' a lot of things but this does not necessarily mean in a documented procedure. Procedures can be defined by, for example a computer system that only allows things to be done a certain way, or by custom and practice.

Martin,

Yes - my definition of defined is intentional and means documented. If it is not documented how can it be defined and how can it be verified during an audit?

Thanks!

Mike

As my previous post stated something can be defined without necessarily being documented. Examples given were a computer system and custom and practice.

So for example if I were to audit your order entry system you might tell be the process is defined by the computer system. I would interview the people entering orders and see by demonstration that the computer system indeed defines the order entry process steps, and certain things like error proofing have been taken into account. If I find that everyone entering orders uses the same system in the same way I might also conclude that the process steps are defined by custom and practice.

No problemo.

M Greenaway said:

As my previous post stated something can be defined without necessarily being documented. Examples given were a computer system and custom and practice.

So for example if I were to audit your order entry system you might tell be the process is defined by the computer system. I would interview the people entering orders and see by demonstration that the computer system indeed defines the order entry process steps, and certain things like error proofing have been taken into account. If I find that everyone entering orders uses the same system in the same way I might also conclude that the process steps are defined by custom and practice.

No problemo.

Martin... okay. I'll buy that. However, how do my Customer Service people know how to conduct order entry without procedures? Computers can goof-proof alot of things, but I don't think it will allow any Tom, Dick, or Harry to come in off the street and sit down and enter an order. However, if Tom, Dick or Harry picks up the procedure (flowchart) and follows that - he (or she) can do order entry.

Custom and practice are dangerous. For example, if Jim trains Bob in Order Entry and Jim does it Jim's way vs. established custom and practice and it's not quite right, then Bob is going to do learn it incorrectly. Bob then teaches Tina to do order entry. Tina learns Jim's way - but now Jim is long gone and no one knows why Jim did it that way... Do you see the problem?

:confused:

Monday is getting uglier by the minute....

energy said:

This just came in from AQS. it's a seminar scheduled for next month. here's what they offer:

Learn how to map your processes

*snip*

I will be attending. As for the differences,
I'll be the judge of that! :vfunny: :ko: :smokin:

Let us know - I'm interested in your opinion on what they say.

Jim Wade said:



Good question, Michael.

If the answer is "they don't, so we need procedures", then use them!

Nobody, I think, is claiming we don't need written procedures anymore, but it's fact that (apart from the special six) they are no longer required, as long as we can demonstrate competence .

However, descriptions of processes are required (see my post about a dozen back for possible NCs in this area).

rgds

Jim

Jim,

That is what prompted my original question. Let me get this straight... I don't have to have procedures documented (except for the magical six) but I do have to have processes documented. Is that correct?

Michael T said:

Jim, Martin, Marc, Eileen, et. al.:

I think I just had a moment of panic/hysteria/frustration...

Am I understanding this correctly? For every process we have, we must have a process map? That process map should define all of the various interactions between related processes, define the procedures within that process, define the analysis, monitoring & measurement activities to be conducted, be documented and list the types of records kept and somehow show how management has reviewed and approved this?

Is this right? :confused:

The requirement is that you identify the processes utilized in the QMS. At our location some areas are vastly overdocumented while others are underdocumented. My goal is to symplify the documentation format so that all process users can easily find the information they need to do their work (regarless if it's their first day or 5th year with the company). Currently the system is numbered to the 1994 standard, is very complex and not user friendly for that level employee.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~`
Let me provide an example:

The Assembly Production Process consists of the following key components:
~Inputs (Pos and Neg pasted plates, Separator, Lead, Cases, Int Covers)
*Tekmax (pos/neg plate and separator combined to make elements)
*COS (Cast-On-Strap - Lug bonding of each element)
*Case-Out (inserting elements into containers)
*Cover line (Heat Seal joining intermediate cover to container)
~Outputs (Assembled battery units ready for Acid fill, Formation, and Final Cover)

The process maps are to be placed in each department that uses them and will show each process componenet and what current procedure is used/needed (unwritten or documented as - inspection tests, specifications, work instructions, SOPs, forms for records, etc...)

The process custodian has the authority to designate what documented procedures are required (verified by me to maintian certification requirements). This person is then responsible to effectively communicate to all associates working with the process what the procedures are.

The new process documented system is numbered according to the process identifier. When processes overlap use the appropriate reference and it becomes as easy as following painted footprints on the floor.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As I said before, that is my GOAL for our system. The Process custodians were designated by the Plant Manager. I provided lists all documents currently used in each department (Specs, WIs, SOPs, Forms, and current Record Retention Log). All that was expected was that the custodian define what the key components are of the given process and identify where the documents are used. After my return we were to meet up (one on one) to review what the requirements were, ensure compliance (adjust processes as needed), remove any overdocumentation (if present) and issue the updated documents.

To me this was simple and straightforward albiet time consuming for some of the processes. Delegation to process users was encouraged in order to bolster ownership of the processes (which goes along with the Kaizen/Lean training we received).

As I said earlier, after 5 weeks, out of 11 process custodians (me being one of them - and issuing out updated Documentation Process procedures so they can use them as a general guidline for content and format)...anyway where was I...Right I get back only to find that NOBODY did ANYTHING! Well that isn't fair, one process manager (ENV) did identify updates for a few records on the retention log, which is all that was needed since we just achieved ISO 14001 certification.

Basically, my beef is that when it comes to putting anything down in writing it's like pulling teeth out of an angry aligator with nothing but your bare hands! And what is worse is management sitting back letting it all happen. I interpret this as - they don't want to do it so if they wait long enough, either I'll get fed up - draft something - and review it with them or the goal date will change. In this case it was made clear neither of those things were going to happen, but the situation remains the same.

Hi Eileen...

I know your frustration... I'm there. Trying to get supervisors to write procedures is like asking them to cut off their own arm. Actually, I think some might rather loose a limb than write a procedure. :mad:

Mayhaps I'm better off than I think -- Perhaps my terminology is getting me trapped in my own paradigm. (Like that? Good BS Bingo material.... :vfunny: )

Here's what I currently have:

Each department has:

"Procedures" that are flowcharted that spell out how to do what they are supposed to be doing. Each department has several of these "procedures" For example: In our Corrugating Department, the Tuber Division produces tube. In that division, the Tubing Run procedure is a flowchart that starts out with receiving the mfg order, generating the appropriate production log, setting up the machine, producing tube, testing tube, determining acceptability, run completion, post run. Each one of these steps (plus others not listed for brevity) references it's own Work Instruction that further delineates how the step is to be performed. Additionally, if the step has some type of form to be filled out, that will also be listed (Ex. Fill out Tuber Production Log (tpl001) per cg14w).

Does this make sense?

I think I'm ready for the white jacket with the loooooonggg sleeves... :bonk:

Thanks!!!

Mike: Yes, that does make sense.

Our are currently set up similarly, but split apart (so 1 process might have 5 work instructions (identified by ISO 1994 elements) and numerous SOPs. Inspection, Measuring, and Recording requirments are clearly called out along with the process procedures.

I just want to take what they have, clean it up, and organize it so they'll actually be more useful to everyone.

Jim Wade said:

Plenty of possibilities there, if the registrars take the process approach seriously. Take your pick from:

4.1a) Processes not identified

4.1a) Application of processes not identified

4.1b) sequence and interaction of processes (not procedures!) not determined and [4.2.2c)] described

4.1c) criteria and methods for operation and control of processes not determined

4.1d) resources and information to support operation and monitoring of processes not ensured

4.1e) Processess not measured analysed and monitored

4.1f) Insufficient action to continually improve processes

4.2.1d) Insufficient documentation to to ensure effective planning, operation and control of processes

5.6.2e)Top management not reviewing information on process performance

5.6.3a)Top management not taking action on process performance

6.3 Organization hasn't determined, provided or maintained process equipment (both hardware and software)

7.1 Organization hasn't planned and developed processes needed for product realisation.

7.1 d) insufficient records of processes [not just product!] meeting requirements.

8.2.2 Audit programme not considering status and importance of processes

8.2.3 Insufficient measuring and monitoring of processes to denonstarte process ability

8.4 Insufficient information about characteristics and trends of processes.

rgds Jim


Well, as a company that has to "define" what our processes are (not ISO or the Registrar), we have addressed those processes per requirements. Which process did you specifically have in mind?
Jim, for the majority of your "findings", I would have to ask that question.
And, as I don't have to have them written, except 6, here are my goals and objectives and how we measure them. You are assuming that our processes have not been determined and that they are not being measured. No? How dare you?:vfunny:
:ko: :smokin:

How about thinking about it this way.No matter what you think about QS/ISO/ or TS. the thought proces is the same, it's called a solid busssiness practice.

I am the new guy but I still have some brains left!.

Al...

How about thinking about it this way.No matter what you think about QS/ISO/ or TS. the thought proces is the same, it's called a solid busssiness practice.

I am the new guy but I still have some brains left!.

Al...

Why would c) be included in 2.8.1 of 9000-2000?

2.8.1 Evaluating processes within the quality management system

"When evaluating quality management systems, there are four basic questions that should be asked in relation to every process being evaluated."

a) Is the process identified and appropriately defined?

b) Are the responsibilities assigned. (That answers my responsibilities question, I think)

c) Are the procedures implemented and maintained? Huh?

d) Is the process effective in achieving the required results?

Does that imply "if needed"? Why stick procedures here?

Could it mean that a procedure be implemented and maintained as you evaluate the "process"? Why ask it? Kind of like the chicken and egg thing. It looks out of place here. This is some murky s--t!:bonk: :ko: :smokin:

Without reading ALL of these replies, I guess it all just depends on who your audience is and the improtance of getting this across.

For example, a small business could have simple flow charts with responisbilities located in Job Descriptions.

Or you could have a flow chart that was in A3 that also had columns beside the flow chart that stated responsibility and authority (escalation).

Flow charts aren't always the best solution but do go a long way to pleasing everybody. If I could prove that through my Job Descriptions and interviewing personnel that the responsibilities were known, I don't think it would be an issue. Then you could always look at problems in the business and see if this related to the fact that these responsibilities aren't documented in the procedures.

Many ways and just a few flying thoughts as I was passing through.
:bigwave:

Virtually all of our "procedures" are flowcharts. Actually, they a flowcharts of our processes. Within the flowchart, each step is itself a process/task (or decision) and the "responsibility" is assigned by naming the position that performs it.

All our positions have job descriptions and associated training & skills matrices that serve as authorization to perform tasks.

Granted we have a skilled work force, but I don't see how this approach couldn't work anywhere. Appropriate flowcharts are posted in each work area along with a training signoff sheet for each to show who is and who isn't "trained" on the procedure.

FWIW, our auditor has no problem with this, and actually quite the contrary, really likes it since he can readily follow what has, is and will happen in the procedure.

Just what Stevie said there about his auditor actually liking the flow charts I find very interesting.

Since the new Standard, all talk has been about flow charts. I use them quite effectively and they work for me. However, no where in the Standard does it say you MUST have flow charts. Yet time and again I see and hear of Auditors asking for this.

It would seem that about 3 years ago, flow charts were frowned upon by third party auditors who wanted more "substance". Now those same auditors are (almost) demanding it.

Getting off the track a little there but just thought it was interesting to note.

:bigwave:

Very well said Jim

To restate - a flowchart does not necessarily describe a process. So if you are merely taking your procedures and flowcharting them it is quite likely that your processes have not been adequately defined.

M Greenaway said:

Very well said Jim

To restate - a flowchart does not necessarily describe a process. So if you are merely taking your procedures and flowcharting them it is quite likely that your processes have not been adequately defined.

Exactly right! Proper definition is the key. If someone just flowcharts their current "procedures" the actual process may not fully be defined. This is usually because procedures are typically for a single, homogeneous functional area and processes don't respect an organizations functional boundaries. Processes do what needs to be done, but not necessarily efficiently. That's where process improvement comes in.

Define the process: Inputs->Steps & Activities->Outputs

Do this by using those affected by it:
Suppliers [Internal]->Process Workers->Customers [Internal]

I appologize if I'm restating the obvious, but if you flowchart your processes you've defined how your business operates. You can then fill in the gaps to whatever "standard" it is that you wish to conform to in a way that "fits" your business rather than fitting your business to the standard.

OK, sermon's over. Thanks for listening. (Or Not!)

Steve, The Impertinate Bast..

I keep six honest serving men
(They taught me all I know);
Their names are What and Why and When
And How and Where and Who.
- Rudyard Kipling

Jim Wade said:

At least three of us (SteveTIB, Martin and I) are in agreement that a flowchart is not adequate description of a process.

•••*BTW does anybody else share that view? •••

However, it seems that some registrars accept flowcharts as process descriptions for 9001:2000 purposes.

So, what's happening?

Are we wrong and the registrars right?

Are we right but the registrars don't care?

Or ...... ???

rgds Jim

or......your interpretations are too tight to state, correctly, that the use of flowcharts is unacceptable. If every step in the process is shown in a flowchart, what more do you need? I don't get it. Call it what you want. Much ado about nothing.JMHO:bonk:
:ko: :smokin:

Jim Wade said:

At least three of us (SteveTIB, Martin and I) are in agreement that a flowchart is not adequate description of a process.

rgds Jim


Jim,

I can only speak for myself, but I don't think anything is an adequate description of a process, IF it isn't proprely defined, i.e., identifying ALL inputs, activities & outputs.

If it is properly defined, a process can be flowcharts, text documents, whatever you like can be used to "document" your processes. Choose the style that works best for your organization and use it.

best regards,
Steve

Garbage in, garbage out.

does a flowchart, showing just which step comes next. describe "the sequence and interaction of processes"

Jim,
I'm having a problem following your thinking here. If step 1 comes before step 2 is that not a "sequence"? And if after step 2 a decision must be made (step 3) if TRUE go to step 4 if False return to step 1 or refer to another process flow (i.e. Control of NC Material) - does that not show an "interelation"?
:confused:

Randy

You are defining process steps - not processes themselves.

A process is something that converts inputs to outputs, uses resources and controls. A procedure (be it flowcharted or not) defines a specific way to carry out a process.

So if you consider the classic process model of a box with inputs to the left, outputs to the right, and controls to the top and resources to the bottom, and then you show how the outputs of one link with the inputs to another you have defined processes and their interaction.

A procedure on the other hand may just describe the steps inside the process box descibed above, and ignore inputs, outputs, resources, controls and interactions of the process.

You may have fortunately defined all of this in one documented flow chart or procedure, it can be done. But if you have followed the traditional 1994 structure and are just flowcharting your existing procedures you may well miss the point.

You are defining process steps - not processes themselves

Okay, what is the difference between process steps and the sequence of processes?
My procedures shows who performs and what is done in step 1 and that it falls before the person responsible for step 2 performs his operation. Our flow show the same information.
:confused: :bonk:

Dear Cove Members and Visitors,

Attached is a pdf file of a flowchart we intend to use to describe a quotation process. Call it a procedure, call it a process, call it anything. We're going with it. Disregard the mis-alignment of the responsibility circles next to the responsibility box. Something happened when I sent the visio document to the Adobe Distiller. It will be corrected prior to release. Have at it boys and girls. I will listen very carefully to all serious responses. See how nice I am?:biglaugh: :ko: :smokin:

Ok, I'll go first.

First impression was OMG look at all the blocks! But then I took it step by step and it wasn't so bad. I could follow it. Looks pretty much like a procedure to me due to the amount of steps...Which is not to say that it wouldn't pass as a process. A single procedure flowchart that doesn't require additional procedures to describe a process can be the whole enchilada IMO.

I don't see where this might link to any of the other "processes" if this is to be used as a process flowchart - where the input comes from (marketing process?) or where the output goes to (design? delivery?).

And since I'm a chick, I like using color on flowcharts.:) It makes it a happier document and can be used effectively to distinguish one type of act from another or responsibility, etc.

Lucinda,

Beside some glaring errors I see since posting it, my input is simply "Request for Quotation or Re-Quote" Upper L/H corner. It ends with "Quotation to Salesman or Rep". (output) Unless it becomes an order, that's it. We also have a Project Execution Flowchart that deals with an actual order. I guess someone can say, show two more blocks. One called "Limbo" and the other pointing to the Project Execution Process.

As for being a "chick", no doubt about it!;) :ko: :smokin:

Yes, my opinion is that you should add those two blocks.

but surely your business doesn't come out of limbo does it? Have ya'll defined a customer relations process or a marketing process or anything else that describes the way you do market analysis, or populate your website or communicate with potential customers? That would be the process that provides the input, right? and at the other end, yes you should link to the next process that you have defined.
That is what the whole "interaction between processes" is all about :lick:

Oh yeah, I must add the qualifier "IMHO"....

(just keep throwing that bait out there my flirty fisherman!)

Lucinda,

The limbo was in reference to the end of the quote process. No order, there's nothing left to do. All those other things you mention will be handled in due time. One step at a time. This is not a Quality Plan, just a piece of the pie. We have a similar chart for another quote process for another sector of our business. It is different so I didn't want to muddy the issues on one chart. The reason that this was posted is because there appears to be fine line between a flowcharted procedure and a process. If I wanted to flowchart the quote process the way I think others would like it, I would have one line starting with the receipt of the quote straight to limbo or the Project Execution Process. Then I would have one line from receipt of order straight to ship the goods. I'm interested in which auditors would have a problem with submitting this as a process vs procedure. But, it's Friday and this is a day of low activity here in the Cove.

And, that's not bait, Scuba Girl!:biglaugh: :ko: :smokin:

energy,

I agree with Lucinda. Without some "input and output" it's not a fully defined process. (IMHO)

OBTW,
There is a "shape" in the Visio Flowchart stencil that is for a "predefined process" (a rectangle with side bars). That's what I use for hand-offs between processes. Additionally, there are "termination" shapes that can be used to identify starting and ending points that aren't necessarily processes.

see attached file. (I hope it's attached anyway)

SteveTIB said:

energy,

I agree with Lucinda. Without some "input and output" it's not a fully defined process. (IMHO)

OBTW,
There is a "shape" in the Visio Flowchart stencil that is for a "predefined process" (a rectangle with side bars). That's what I use for hand-offs between processes. Additionally, there are "termination" shapes that can be used to identify starting and ending points that aren't necessarily processes.

see attached file. (I hope it's attached anyway)

Steve,

FYI....no attachment

While my chart doesn't specifically say "input" or "output", you can see that we receive quote. That's input. Give the Quote to the Representative. That's output. File the quote. That's output. I just don't get it.
Yes, I'm familiar with the "predefined process" stencil and the circles for start and finish. But, I don't think Auditors would concentrate on those templates as much as content. Had I used them, I would still be charged with no input or outputs defined.

Thanks for the response. The more the merrier.:ko: :smokin:

Jim, you slipped in here in between posts. Glad you liked the chart. Now, our Quality Plan shows the quotation and order blocks on it as well as all the other processes. These are charts that will be referred to in the final Qual Plan. So, I guess we can call it a procedure. It will still be titled process in the hope that I get one of those auditors who just want to pin me with a badge.:vfunny: :smokin:

Energy,

Very nice flowchart!

I'm just curious, though, what would this procedure or process or -- let's say document -- look like if you were ONLY concerned with satisfying the needs of your organization internally? In other words, if you didn't have to worry about making any auditors happy or meeting any standards.

Mike S. :thedeal:

Jim,

Missed your comments in between posting. Please go back to my response to Steve. I edited it, just for you.

Mike S. It would look the same. Nothing special except the responsibilties thing. We would know who does what.

Enjoying the feedback. Keep it coming. I will argue that my inputs and outputs are there, just not highlighted as such. You go from left to right. Auditors are pretty smart people, even if a bit eccentric.:ko: :smokin:

The input and output that I was referring to is the input from the previous process, and the output to the next one. In other words, the identification of what process came first and which one comes next. I can see that this process has many individual outputs all along the way. But for "interaction between processes" you need to show how they fit together. Follow?

I understand, Potty Princess. That was a good one.

To decide which processes occur first in some instances is impossible to do. Many processes happen simutaneously. I think that you may one of those auditors that I would have to have a blanket party for if you were to grace our doorstep. Just kidding. You'd be welcome here anytime, except in an official capacity.
:vfunny: :ko: :smokin:

M Greenaway said:

Very well said Jim

To restate - a flowchart does not necessarily describe a process. So if you are merely taking your procedures and flowcharting them it is quite likely that your processes have not been adequately defined.
By the same token, text does not necessarily describe a process. Just because you write out your process steps in text and come up with a procedure does not mean they adequately define you processes.

You're throwing up a false, totally invalid arguement.

Jim Wade said:

At least three of us (SteveTIB, Martin and I) are in agreement that a flowchart is not adequate description of a process.

••• BTW does anybody else share that view? •••

However, it seems that some registrars accept flowcharts as process descriptions for 9001:2000 purposes.

So, what's happening?
Are we wrong and the registrars right?
Are we right but the registrars don't care?

Or ...... ???
Or you're confusing content with format. What is important is that the format and content be appropriate for what the document is being used for. That always calls for an opinion and is in large part dependent upon the level (height, if you will) you are looking from, the process(es) and it's (their) complexity as well as the required precision.

Jim Wade said:

1 why did the creators of ISO 9000 define 'process' and 'procedure' as two different things if in fact they are one and the same?

2 does a flowchart, showing just which step comes next. describe "the sequence and interaction of processes" as required by 4.1b)?
1. The 'creators' of ISO 900x were struggling with verbiage and cultural definitions just as is happening in this thread. I think they addressed concepts with their definitions. They don't define a specific format. Their concept relates most to the content.

2. If you take a minute to look at the slides around http://Elsmar.com/Imp/sld038.htm - you will see that flow charts can intersect and thus ... interactions are illustrated. Who was it - I forget now who and in what thread they were uploaded but there were two excellent examples. Much better than my poor, abstract attempt. One was titled XYZ Corporation - Business Process Cycle (it is a high level flow chart) and another was Commercial Process - Comm. Service Provision Overview. Both are excellent illustrations, with consideration to the level and their use, of flow charts which show the interactions of processes. And you can show the interaction of processes right down to the individual process its self.

To say a flow chart just shows which step comes next is like saying one note in a song or melody only preceeds another note and does not address the melody as the whole. There is not just 1 flow chart. There are many and they interact. Your concept of what a flow chart is is quite narrow.

High level conceptual: http://Elsmar.com/Imp/sld039.htm a la ISO 9001.

Marc

The argument is not invalid or false.

If you take the time to read the definitions given in ISO9000 it may finally dawn on you.

Remember ISO9001 does NOT require you to document your process STEPS, that is what you are doing by flowcharting your procedures. You are not creating process descriptions you are merely re-writing your procedures into another format. Just by doing that alone does not satisfy the requirements to define in your Quality Manual your processes and their interaction.

To peddle the myth that an ISO9001:1994 company can upgrade to the 2000 version by changing the format of their procedures to flowcharts is laughable.

M Greenaway said:

To peddle the myth that an ISO9001:1994 company can upgrade to the 2000 version by changing the format of their procedures to flowcharts is laughable.
I don't know that anyone is 'peddling' the idea the simply changing text procedures to flow charts 'satisfies' the 'requirement' that the inter-relationship of processes be defined. I sure haven't said that anywhere. As far as I know you can use text and/or flow charts and/or pictures to do this.

I am saying you can very well use flow charts to define the interactions of processes and you can use them at any level. After 4 successful upgrades (not to mention numerious registrations), I know this to be acceptable to several registrars and believe it to be true in general.

I will also say if the original implementation was done correctly the upgrade should be a snap as it was for 4 of my former clients whom I helped with in their upgrade projects. Folks are far over reacting to upgrading. If you did it right the first time you should be showing the inter-relationships of your processes. This simply is not something new.

M Greenaway said:
If you take the time to read the definitions given in ISO9000 it may finally dawn on you.
Now really. You and energy make a pair when it comes to getting snippy. I've read the same words you have and I believe you read too much into them.

Marc said:

You and energy make a pair when it comes to getting snippy.

And, of course, this isn't. It's uncalled for. You already did your admonishing and I thought the groveling was adequate.

Yup - you did swell! :D

Very sorry.

I do get slightly tetchy when someone quotes me and then calls it a totally false, invalid argument.

Particularly when the accusation is totally unfounded !

I'm sure there are enough incompetent (energy's favourite word) assessors out there to dish out an ISO9001:2000 cert to companies that have merely flowcharted their existing procedures.

M Greenaway said:

Very sorry.

I do get slightly tetchy when someone quotes me and then calls it a totally false, invalid argument.

Particularly when the accusation is totally unfounded !

I'm sure there are enough incompetent (energy's favourite word) assessors out there to dish out an ISO9001:2000 cert to companies that have merely flowcharted their existing procedures.

That's two posts that have used me as tennis ball to make a point. I'm flattered, if not a little dissappointed at this unruly behaviour. Is that how it's spelled? Can't tell anymore. Maybe it's time for a big wet kiss. Gotta love it!:biglaugh: :ko: :smokin:

<center>http://16949.com/gif/lips.gif</center

M Greenaway said:

Very sorry.

I do get slightly tetchy when someone quotes me and then calls it a totally false, invalid argument.

Particularly when the accusation is totally unfounded!
I don't think there is an accusation per se there. At best I'm stating my opinion. If you interpret someone disagreeing with you as an 'accusation', I agree you are tetchy. I simply disagree with your arguement. In my opinion it is false and invalid taken in context.

I'm sure there are enough incompetent (energy's favourite word) assessors out there to dish out an ISO9001:2000 cert to companies that have merely flowcharted their existing procedures.
Oh, I don't know that it's all that bad. And it could in part be that your expectations are very high and/or that your interpretation(s) are very strict.

Marc said:

<center>http://16949.com/gif/lips.gif</center

You always were a sweetie! Right back at ya!:agree: :ko: :smokin:

Marc says
"I am saying you can very well use flow charts to define the interactions of processes and you can use them at any level. After 4 successful upgrades (not to mention numerious registrations), I know this to be acceptable to several registrars and believe it to be true in general.

I will also say if the original implementation was done correctly the upgrade should be a snap as it was for 4 of my former clients whom I helped with in their upgrade projects. Folks are far over reacting to upgrading. If you did it right the first time you should be showing the inter-relationships of your processes. This simply is not something new. "


BTW...didn't check out how to put this in blocks...sorry...LOL

thank you.....It's so great to hear that...its what i believe and practice (successfully) but I what am sooooo tired of saying and have people look at me as if i have 2 heads. I have come to the conclusion that many just don't get it, and its not worth the effort discussing it with them....after the first go around.

Lets consider an ISO9001:1994 company that structured its procedures around the twenty clauses. As such they have a documented procedure entitled 'Product Identification and Traceability', how would flowcharting such a procedure turn it into a process definition ?

Hi Jim,

Yep... got a bunch of the first ones. Each operation has one.

Got one second one - it details the process flow from order entry to product going out the door and lists all the critical procedures involved.

Cheers!

I think you're right Jim, it's peoples different definitions.

We have both type of charts you described, and we call them both flowcharts. Mostly because this was something new to the organisation and they were all produced on a 'flowchart'ing program. It's just the terminology we use. We just have higher level and lower level diagrams.

A box (or decision) in the higher level diagram typically opens up a lower lever diagram showing greater detail of how to perform the original task. This might happen again, further and further down untill our users are happy with the level of detail shown.
(Besides being able to jump to another chart, each box also has a text description attached)

To us the definition of process or procedure is irrelevant.

BTW each chart, higher or lower, process or procedure, defines inputs, outputs, customers and measurement.

I agree about the definition issue. In the examples posted above the only difference is orientation. If one wants to argue one is a flow chart and another is a process description, that's OK by me. But to me they're both the same with potential differences lying in the amount of detail which is determined by the intended purpose of the document.

Now - if you're asking for examples, I suggest you read back through this thread. As I remember I cited several examples and others have posted several as attachments.

The more the merrier, but I believe what you're looking for is already in this thread.

Jim

I think my earlier post show that I agree with what you are saying. Perhaps the difficulty in some people comprehending this is the use of the term 'flowchart' in the posts. Lets not forget that a flowchart is just a format of a document. What we are really talking about is the difference between what you need to do to define your processes and their interaction, and what you want to do to define the method of executing a process. That is the difference my friends.

Note that ISO9001:2000 only mandates that you document the METHODS of executing six 'processes', but it requires you to define all your processes and their interaction in your Quality Manual - this definition does not need to contain the method of execution of each process.

Jim

I would define document control as a process in itself, writing down its method of execution turns it into a procedure !!

Also I wouldnt consider any form of management as being a process in itself, as it has no material inputs and outputs (unless you want to make the process definition very obscure and say that the unmanaged thing is the input, and the managed thing is the output, which I think is going too far).

JMEO

Martin

OK Jim

I think its just a slight difference in interpretation. Perhaps better to say that document control is not a 'business process', where we define a business process as a high level general grouping of related sub-process which when grouped together we manage, measure, etc under the one business process grouping (which we may call management, as one example).

Am I getting it ?

P.S. my 'smart filter' at work wont let me get to your link, can you post it as an attachment please ?