As I know the clause 0.2 "Process approach" in FDIS 9001:2000 again changed. Moreover there is an ISO/TC176' decision to produce special guidance module regarding this problem. Neverthless, how should I start, using cl. 4.1 of ISO 9001:2000?

4.1 a) Identifying processes
I identified
- 6 interested parties (customers,
stuff, owners etc.)
- 8 key production processes ( marketing, design, purchasing, production etc.)
- 7 main management processes (responsibilities,planning,recourses, measurement etc.)
So I have a matrix of 6*8*7=336 processes.OK
4.1 b) Determining the sequense and interaction of these processes. Ha-ha,
Shall I identify input and output for all these processes?
How shall I describe this interaction to stuff and auditors ( a matrix, a lot of flowcharts, in procedures)?
4.1 c) Determining criteria and methods required to ensure that both the operation and control of these processes are effective.
I don't know how to do it, because I understand that my internal and external auditors are not able to estimate: "Are operation and control really effective?".
And what is the noun for the adjective "effective" - effectiveness or efficiency. You know that it is a big difference between them.

Thank you in advance

"4.1 b) Determining the sequense and interaction of these processes. Ha-ha,
Shall I identify input and output for all these processes?
How shall I describe this interaction to stuff and auditors ( a matrix, a lot of flowcharts, in procedures)?"

Perhaps the best visual way to show interactions between processes is with a Venn Diagram. All will be disproportionaly affected in all probability. You may elect first to do some type of Regression Analysis to determine correlation between processes to help you create the diagram. Inputs/outputs is a good place to start.

Regards,

Kevin

"...4.1 c) Determining criteria and methods required to ensure that both the operation and control of these processes are effective..."

Inspections and tests.

"...I don't know how to do it, because I understand that my internal and external auditors are not able to estimate: "Are operation and control really effective?"

You determine this - not auditors.

"...And what is the noun for the adjective "effective" - effectiveness or efficiency. You know ..."

Effectiveness ~ Does it work and if so how well?

Efficiency is an input/output ratio in units appropriate to what you're looking at. There are natural gas furnaces which are 95% efficient and there are others which are 60% efficient. This is an instance of BTUs lost to entrophy (potential of the gas put in {input} vs the BTUs output to the home). In manufacturing processes things can get much more complex. Try an internet search for Machine Efficiency, for example. See what you get back...

I suggest it is worthwhile flowcharting the Product or service delivery process, at he 'macro level', before embarking on preparation of your Procedure Manual. You might have over 300 sub processes but only one or two product types which the manual should address.

I am developing a Quality Management System for a small company. I plan to use graphical process models like the one shown in the beginning of the ISO 9001:2000 Standard in place of writing text procedures, (except for the required 6) to describe our processes. Is anyone else taking this approach?

We are using some process models to describe high level functions but we are mostly using flowcharts in place of text procedures. From the registrars and auditors we've talked to, flowcharts seem to be preferred over text procedures as much as possible anyways!

Just an opinion, but I find that the level 2 procedures lend themselves to be written documents that reference the work instructions that are flow-charted.

In reality, very few use the procedures, most use the work instructions and forms.

By flow-charting work instructions it makes it easier for the general work population to understand and perform.

ASD...

-> I find that the level 2 procedures lend themselves to be
-> written documents that reference the work instructions
-> that are flow-charted.

I disagree. I believe level 2's are the first to be flow charted. I haven't had a client use text level 2's since 1995.

Originally posted by Marc Smith:
I haven't had a client use text level 2's since 1995.

Marc,
Do you mean text only L2 procedures?


------------------

I suggest flow charts everywhere you can. Especially level 2's. Most larger companies have problems doing some lower level documents in flow charts such as work instructions and/or travelers because their MRP/ERP systems print them.

Almost any procedure can be, and should be, flow charted. Text documents are to be avoided at almost any cost.

At Harley we flow charted just about everything except the 'quality' manual and many assembly and other various documents which the MRP software spits out. My smaller clients do the same.

The problem at many companies is as you get down to the level of assembly / work instructions (in addition to any MRP/ERP systems problems) is the detail level necessary. It becomes harder (with some processes) to use flow charts because of detail issues.

David, you've been visiting the forums long enough to see my extreme Pro-Flow Chart bias. Not to mention my Flow Chart rants.

There are numerous examples in my Implementing ISO Guide (unabashed promo).

At the least, all level 2 'procedures' should be flow charted.

-> I haven't had a client use text level 2's since 1995.

This means I haven't had a client which used text documents as level 2's since 1995. They have all exclusively used flow charts.

-> Do you mean text only L2 procedures?

I'm not sure what you mean here - but if you are saying "Yes - use text only documents for level 2's", the answer is NO. Use Flow Charts for ALL level 2's and the majority of level 3's.

I really appreciate the comments. I have the rare opportunity of being able to implement a first time quality management system in a company that's over 15 years old. The company is very successful and would like to obtain ISO 9001 registration within 18-24 months. I would like to do this one, in a state-of-the-art manner, but keep it as simple as possible. The people are very apprehensive about "over documentation".

I plan to use flowcharts to show the sequence and interaction of processes, but I want to use the "Input-Output Process Models to describe processes like Management Review, Product Quality Planning, Design & Development, etc.

Flow charts are good, BUT (as you said Marc) detail is often a factor. I beleive this is even the case in L2 docs. Therefore I support using both flowcharts and supporting text explanation.
The problem I have is that you really need flowchart software that is easy and quick to use. If you do a flowchart in WORD and someone wants to add a new action/activity in the process, then you burn off 30+ minutes reshuffling the flowchart.

So I suppose it's a warning. Don't go gung-ho flowchart crazy only to commit vast resources to drawing and re-drawing flowcharts - with poor/no ROI.


------------------

This is exactly the phase I am in. I am currently registered to ISO 9001:1994. We will be converting our system to ISO9K:2K. I would like to get rid of a lot our text documents. We have so many 'operations' manuals it's ridiculous! My wish would be to convert work instructions and as many other procedures as possible to flow charts. I just think they are easy to follow and it's nice for employees that do not have very good reading comprehension skills.

Has anybody (other than Marc- no offense Marc) used flow charts in their systems? How do they like them? How does management and front line workers feel about them?

http://16949.com/ubb/biggrin.gif

We're in the same boat here. Iv'e developed a few to sample and have had mixed reviews. Samples drafted were for Internal Audit Process, Plant ECO Process (wich actually originate at Corp level but we have routing/approval/processing/tracking at our level), and SOP Processing.

These processes deal mainly with staff level personnel, yet some have a hard time comprehending 'What does it mean?' While others want so much detail, a trained monkey could follow the process. So basically what I am saying IMHO, is a lot will depend on the 'business culture' and change receptiveness of your management, staff & associates.

Currently, I'm being beaten down, but NOT giving up! For those that want/need more detail, I'm recommending one-one training that will be available upon request and development of a sample cheat-sheet type example book that can be referenced (especially when tasks aren't performed by some people more than a few times a year).

Strength of preserverance to us all!

------------------
Eileen V. Wall
ISO Coordinator

FG,
I agree with Marc that at Level 2's flow charts work very well.

In our business our work instructions (Level 3) need specific detail at station or operator level. Flow charts just aren't appropriate.

I think for a company's first documented quality system, flow charts or picture graphs can be more useful, especially in training new employees.

This probably goes without saying, but, you shouldn't have to create a flow chart for anything that is out of your domain. Have the Production Department flow chart their processes. Have Shipping and Receiving, Engineering, Purchasing, etc., do their own. The flowchart scheme has been floated around here, but, like always, they expect Quality to do the work. Let them do the rough draft and you polish it up. Three months ago, all departments were directed to do exactly that at my place of employment. The only one created, so far,was our Quality Plan, by yours truly. (It's posted at this site in the FTP files). The text procedures, while maybe being passe, were greeted with much less resistance because they didn't have to write them. Quality did it and they made recommendations/suggestions for accuracy. We may be the exception to the rule, but flow charting is meeting with more resistance than text procedures. Personally, I insist that everyone do their own. If not, they get what they get. JMHO

energy

I agree, I wish it was easier to get department heads to do their own procedures in a timely manner. However, my priorities and theirs are different.

Originally posted by David Mullins:
Flow charts are good, BUT (as you said Marc) detail is often a factor. I beleive this is even the case in L2 docs. Therefore I support using both flowcharts and supporting text explanation.
The problem I have is that you really need flowchart software that is easy and quick to use. If you do a flowchart in WORD and someone wants to add a new action/activity in the process, then you burn off 30+ minutes reshuffling the flowchart.

So I suppose it's a warning. Don't go gung-ho flowchart crazy only to commit vast resources to drawing and re-drawing flowcharts - with poor/no ROI.If you use something like SmartDraw - cheap and easy - and publishes easily on the web - with links. Now, this is a 'cheapie' quick export that i put up 'for informational purposes', but it does show you can do it and do it well. Including getting in all the necessary details. A client did a flow chart setup on their intranet which was really neat. They used SmartDraw. Their main screen showed a 'skeleton' - the high level process map ISO now 'requires. From that skeleton you could click, for example, purchasing and you would be transported to the highest purchasing flow chart. And it had links to other flow charts. One link was to the engineering flow chart - because engineering had an input (providing specifications for purchased parts, for example). It was a really cool job. I was really impressed. There was almost no text documents in the places except for the travelers (which Mapix output).

That said, when I first started flow charting systems for ISO in 1995 I used a 'main' flow chart and had a page or 2 of text for 'explaination of details'. In the years since I have found you can get just about all the details you need on a flow chart - including applicable forms (by number), inputs from other 'systems', outputs and where they go, responsibilities, etc.

-> If you do a flowchart in WORD and someone wants to add a
-> new action/activity in the process, then you burn off 30+
-> minutes reshuffling the flowchart.
->
-> So I suppose it's a warning. Don't go gung-ho flowchart
-> crazy only to commit vast resources to drawing and
-> re-drawing flowcharts - with poor/no ROI.

I also want to say I agree that the way you set things up. If you over complicate the issues and make a Monster System, you're not helping things at all.

[This message has been edited by Marc Smith (edited 07 August 2001).]

-> This probably goes without saying, but, you shouldn't
-> have to create a flow chart for anything that is out of
-> your domain. Have the Production Department flow chart
-> their processes. Have Shipping and Receiving,
-> Engineering, Purchasing, etc., do their own.

Yes, yes, YES!

In the effort to 'map' our production processs, I've been working with both the Process Engineers and Primary Supervisor. I can't imagine trying to do it alone, but by the same token it wouldn't get done without me either. Mapping out the process flow isn't their primary concern and based on priorities...would be pushed down the line indefinatly. Teamwork is the key.

I've done two departments so far changing my approach after the first department was done because getting enough of their time at one sitting to outline, discuss & review was difficult.

The second department review (using the new method) worked much bettter for all of us. Took about 15-20 mins meeting with them and about an hour to put together the flowcharts (I used Visio).

What was created? Overview of Dept - what are the 'critical or singnificant' processes, then a seperate flowchart for each process (detail key steps), and then combined on another page to show department-processes-detail together. Five pages in all and everyone was pleased. It isn't as detailed as the first was, but I am finding incremental steps are easier to 'sell' to all involved and have gained better support in doing so.

The next level (when we get their) I'm planning will involve the associates working at the process steps. Develop 'job cards' that would be associated with the step/process (identifying what existing documentation are used Specs/Work Instructions/SOPs/Forms/etc... This will assist in updating/improving on the 'certified training program' we currently have in place (used for 2 years in some departments - still being set up in others).

After the 'job-cards' are completed it would be up to the supervisors/engineer to review the existing written procedures and submit updates/revisions as needed (creating new if needed). *I might make a few suggestions* http://16949.com/ubb/smile.gif

Of course this is a lot of work and will take time, but in the end we'll have a great system in place that (hopefully) will be easy for anyone new to learn, everyone to use, and simple to maintain, audit & update.

If anyone has tips or suggestions to improve on this....PLEASE let me know!

------------------
Eileen V. Wall
ISO Coordinator

For the continuous improvement part of process models, I've asked the department managers to provide a couple of quality objectives and performance measurements. Although I've given them a couple of examples, they still seem to be struggling to find time to provide even that.

I am adamant though that the objectives and performance measurements must come from them they in order to be meaningful and accepted.

Just a thought:

Perhaps the manager’s don’t know what to pick, even beyond the examples you have furnished. It has been my experience that many ‘managers’ don’t really understand what it is to be a manager. Setting objectives is not only difficult for them, it is often times disastrous even though their intentions may be well meaning.

They will need your continued guidance in this area. They will need to see how objectives in all areas work towards the common organizational aim as well as that of the System. Remember: in order to improve something, you need to know where you are today and define operationally where you want to be in the future.

Regards,

Kevin

Good advice Kevin. Maybe since they've never had a formal quality system in place, a good quality objective would be to help them each establish one baseline. Then a monthly performance measurement to that baseline would come natural.

Originally posted by HFowler:

...I plan to use graphical process models like the one shown in the beginning of the ISO 9001:2000 Standard...
Is anyone else taking this approach?

I GUESS I AM THE ONLY ONE CREATING PROCESS MODELS LIKE THE ONE SHOWN IN THE ISO 9001:2000 STANDARD.

I do appreciate all of the helpful comments though.

I've used 2 approaches in my business systems manual.
1. a matrix of iso requirements and our procedures.
2. a process flow diagram that can be applied to any task in the organisation, with system procedure numbers referenced to the number ID of the activity in a separate table - to keep the picture tidy. (don't ask for a copy - my e-mail has been shot for nearly 3 months, plus it's not something I'm inclined to share at this stage).

------------------

-> I GUESS I AM THE ONLY ONE CREATING PROCESS MODELS LIKE
-> THE ONE SHOWN IN THE ISO 9001:2000 STANDARD.

I'm not sure what you mean by this. The 'process model' shown is at least 20 years old and simply represents the base flow of a business. All of a sudden I'm hearing "Process Model" this and "the ISO Process Model" that.

Businesses are nothing but processes. What does the ISO 'process model' say to us? It's a simplistic 'model'.

I discussed this in another thread somewhere, but I'm not up for a SEARCH this morning. I'll briefly summarize:

Many years ago I trained in Total Cycle Time and "Business as a Process". I have my old course manual right here at hand. The ISO figure is a simplistic PDCA (without credit, I might add) representation.

More importantly, as a buzz word it's confusingly simple. Business Process Model. Now I ask you - what was business before? Was it not a process? Were there no inputs and outputs before? Was there no feedback?

Folks - please - don't over complicate this 'new' ISO process 'model'. The fact that they sling a box on top which reads "Continual Improvement of the quality system" doesn't change a thing. Succesful companies do continually improve in many ways - the quality management system is only one of the many. I saw the same representation over 25 years ago. This is nothing new or earth shaking.

My answer is NO - you are NOT the only one following the process model shown in the ISO standard. Everyone is.

If you are saying that using flow charts is NOT graphical, I think you're somewhat confused.

Mr. Smith,

I am not saying that flowcharts aren't graphical, of course they are. I was just looking for ways in addition to flowcharts and process maps to illustrate processes and I thought the model in the standard was a nice simple example.

Ah! My apologies! I guess I look at some of these graphics and tired of so much being made out of such a simple graphic. I think sometimes we reach a point where the graphics are so - let's say individual - that they become confusing to everyone except s/he who put it together.

I like simplicity - which is what flow charts are about. I consider venn diagrams and such good - illustrative. But some 'graphics' reach a point where it becomes absurd.

I apologise for being grouchy this morning. I really wanted to sleep in a few hours and was grumpy.

No apologies necessary. Thanks for waking me up.

Marc..if you are grumpy..then we all are grumpy...this is my first week back after months and it hit me the same way...But if everyone understood our simply approach we would be out of work so as frustrating as it is,,,,,,,**** it must be our age, disposition and military backrounds that makes us get "grumpy" over complicated "New" stuff, when we have been seeing/hearing it for years... I say the same about 6 sigma.... its just good old fashion quality engineering.....what is the mystery? Same with graphic presentations......whats the mystery/hoopla? We all are doing it in one way or another......

Marc raises a longstanding (but current) criticism of Quality concepts and tools: overstating the obvious.

For me, it is part of the fad status things generally receive and why we see them come and go. Tools or concepts are latched onto, given a new look or name and “poof”: you have something “new”. Albeit that many of these tools/concepts run their cyclic lives and are new to some, those that are deeply entrenched in the Quality movement such as Marc is see this as rehashing the obvious. I guess it is a matter of fact. It frustrates me time to time. Ugh!!!!

I agree with Marc and many others, simpler models, tools and concepts are best. I say this for two reasons. First, our lives are complex enough. Second, we tend to be very superficial, and as such, never have time to get into the details. In a ‘now’ society, you have a few seconds to make your point or forget about it. Cruel or not, those are the standing rules to this paradigm.

As to the thread topic, graphs and illustrations are essential to make points quickly and concretely. Anyone would rather follow a flow chart than to read many nested paragraphs in a procedure. With the advent of TV and computers, graphic environments are the norm, not the exception. Anyone wanting to be read in an organization must do so in bullets or by illustrations in a presentation. Anything more will receive yawns and “deleted without being read.” Communication is serious business, yet we stumble in the way we send messages or in how we interpret them. Is it any wonder why organizations, governments, schools and families struggle?

Regards,

Kevin


p.s. I love using Venn Diagrams and flowcharts. For an excellent reference on how to use flowcharts in documentation, I refer folks to the Leader's Handbook by Peter Scholtes. He shows the reader a variety of flowcharts and how he incorporates their use into the documentation and 'flow' processes.

Just my 2 c's worth on the subject. When I first begin the ISO route with the company that I've been contracted with for the past four years, I used a a simple but effective method(that I had used before).
1) Form a steering committee of all managers of major processes(yes,ALL)
2)explain the purpose and intent of the project. Tell each manager to go away, form their own mini-team and rough-draft a flow chart of the process, showing major events.
3) Come back in a week and let the committee see what you have. If it looks good to all, go away again and, with your mini-team, write a procedure outlining the who, what, when and where of events, according to the flow chart.
4)Come back in a week and let the committee discuss and agree on your results. If all are agreeable, go away again and write any specific work instructions pertaining to events that should require them.
5)Come back in a week and again let the committee discuss and agree. When all agree,
turn the package over to doc control to format.
6)Return final draft to steering committee for final approval.
7)Return approved flow chart, procedure and work instructions to doc.control for distribution (in our case, both electronic and hard copy).
This method has worked for me for years. It can be used in ANY company or process. The end product is a flow chart, procedure and work instructions that are easy to follow, easy to train on and should satisfy any auditor, internal or external.
Try this approach,and, like Mickie, you just might like it !
By the way, Visio basic flowchart software is inexpensive and easy to use.
Ross Simpson

Ross,

I really like your approach. It places responsibility where it should be and not totally with the QA Manager. However, this may not work so well in a company that has very limited resources. Sometimes one manager "wears many hats" and has very little time to do flowcharts, procedures and work instructions in a timely manner. Nor does he have "mini teams" that can dedicate time to such functions.

If anyone wishes to complicate the "process model" can do it going to the Structured Process Analysis" (software industries) used during the last 30 years; it covers the diagramming techniques necessary to model essential business data and process elements using an Entity Relationship Diagram, Context Level Diagram, Decomposition Diagram, and Dataflow Diagram. These diagrams represent "What" the business requirements are for a given business area vs "How" the business requirements are performed. But as Marc said: Keep the process model simple!

I am developing a QMS following ISO 9001:2000 for two companies: one construction building company and one small concrete production company.

I plan to use graphical models like flowcharts, to illustrate most of the (Level 2) procedures and work instructions.
I wish to construct a basic flowchart for each company, portraying its core process.
From there, I intend to liase with procedures and/or work instructions, corresponding to the processes identified.

My problem is to identify the sequence of processes or sub processes that are involved in the core process of service/product realization, i.e., Chapter 7 of ISO 9001:2000.

I assume that probably there is a normal standard sequence of processes which are common to most cases of similar type companies; Can someone help me with an example or sample of those main processes/sub processes I am trying to illustrate?

But what are your difficulties?
In identifying processes or in classifying them or in using flowchart method?

Try taking a browse through http://Elsmar.com/Imp/

There's a good section on high level vs. low level flows.

Originally posted by eee
But what are your difficulties?
In identifying processes or in classifying them or in using flowchart method?

My difficulties are mainly in identifying key processes or critical processes, not in flowcharting them.
That's why I would like to have the views of someone who already had to implement a QMS 9001:2000 in similar type (engineering construction) companies or someone who could give me a hint to overcome this initial process identification phase.
In any case, all the views and contribution, as yours, are certainly welcomed.
Thank you.

Dear Marc,
Thanks for your suggestion. I found it a good help, namely slides 205 and 274.
However, for example in slide 205 (top level operations flowchart) while I have no problem with the supporting processes, what do you think it could be a good sequence of core "product-related" procedures for a building construction company, starting from the project design process (as opposed to sales/marketing) and finishing with the deliver of product (construction building completed) to the client?

I'll be somewhat brief, but the bottom line is you stand back and map top level processes the same as you do lower level processes.

When I start with an implementation, I start with high level flows - I define, with the client, what their main processes and product(s) are. Purchasing. Sales. Marketing. Design. Assembly. Service. Things you mentioned. I'm not that close to the construction industry to be able to give you an example list - I could guess because to some degree all companies have common sub-processes.

How do you identify these top level processes (systems in my lingo)? You flow out what you do and look at each step in the process. As you're doing the flow, you identify 'significant' systems. I don't know any magic way to do it. I always used flow charts because flow charts (or business / process modeling software) are simplest to me. As I flow things out, I identify the systems and sub systems. Actually, the top level is the easiest - but not necessarily the most obvious - to define.

However, I can tell you to look at how your company fits into different situations. That is to say, what all your company does. Do you 'do the whole thing' internally? Or, do you sub-out design, sub-out metal fabrication? Or do you sometimes do everything and other times sub your services out to bigger companies, or do you sub-out sub-processes on your projects?

How about it folks - anyone have any ideas with regard to high-level systems in the construction indstry?

:bigwave: Henrique Dasilva, Welcome to the forum!

In regards to this statement:
"...while I have no problem with the supporting processes, what do you think it could be a good sequence of core "product-related" procedures for a building construction company, starting from the project design process (as opposed to sales/marketing) and finishing with the deliver of product (construction building completed) to the client?"

A few factors that I am aware of that may affect the approach taken include Primary Role for Projects (i.e., if the construction company is the Architect, CEM and GC for the entire project your flows would be different than if you were either the CEM or GC but not the architect.). If the company always does all, then there would be one continual flow, but if some projects are only one portion...then your responsibilities would only be to those criteria processes.

For my limitied exposure/participation in construction (2 projects with Flour Daniel in Texas: In one we were the CEM only to a county project and the other was a State Jail project where we were the CEM and GC.) I would say basic 'significant/critical' top level (presuming Arch/CEM/GC role) would be similar to:
Customer Design Consult/Bid Package Evaluation
Design & Financial Approval
Developement of Front End Documents & Blueprints
Design & Financial Amenments Approval
Project Scheduling Outline & Groundbreaking Date Set
Selection of Subcontractors
Groundbreaking
Construction Phase
Punchlist Review/Customer Eval
Build Document Registry
Project Documentation Indexed/Storage

Then I would create a 'checklist' of all critical/significant and non-key processes followed by a break-down of each of the identified critical/significant process and then non-key processes as you feel are needed.

Best Wishes, Eileen

Henrique
This was discussed in another thread not that long ago.
That's why the forum has a search engine.
I'll see if I can locate it for you.
Now I'll take my happy pills.
:ko:

I don't know, Dave. I did a search on 'construction' and didn't really find anything. I don't remember any threads specific to construction. If you find something, please do post the link. I'm getting old and my memory is failing me.

*** DEAD LINK REMOVED ***

I'll post my explanation of why this thread is appropriate when I get back from my 1on1 swim coaching session.

David - here's :thedeal:

50 degrees here in the Mid-West & you're talking Swim lessons --
You're explaination better be a goodie - Tee hee :biglaugh:

Regards
Jim

It's Spring time here. 65'F today, but 85'F by Friday.
It was an indoor heated pool. I've been doing triathlons on and off for 12 years and decided it was time to get serious about qualifying for the Hawaii Ironman (one of those mid life crisis things).. but enough of that!

I believe the aforementioned link to be pertinent because it was looking at mapping out the companies processes for referencing of procedures.

In my posts in that thread I talked about the activities associated with a basic process. This would fit Henrique's scenario, regardless of which company. Sure you could then expand it to include whatever you like, but you don't have to. It can be applied to ANY process in any business.

Marc has mentioned in similar threads that this is not splitting the atom. This is straight forward user friendly logic. Marc saw it 30 years ago and it hasn't changed since.

I suspect Henrique's problem isn't so much section 7, but section 4.2.2 - mapping the L2 procedures against the company's activities. And if I'm wrong, just replace the generic name of an activity with the actual.
OR
Talk to the people doing the work and write down the steps - now there's an original thought. You need to do that to write procedures anyway.
BEFORE YOU START - sure you can write L2 procedures without getting in depth, may be even preferable, and sure consultants don't want to waste time actually talking to workers (ouch - just joking guys, really).

OK, so what am I rambling on about? Has the chlorine affected my sanity (no, that's the alcohol)?

Please find attached an example of what it is I am on about.
1. If you can't apply this basic flowchart to a process, then question if you should be doing the process.
2. If you use this flow chart in any way to promote yourself, others, make money, save face, etc, I'll hunt you down like a dog, UNLESS you send $200 and my phone number to hotlineescorts.com.au. The girls will do the rest.


Now, I'll just go and get the water out of my ears!

Great post Dave - well worth the short wait !!

I give it 5 stars :D

His and Eileen's were exellent. Thanks, folks, for the ideas and help!

I wish to thank you all for your thoughts and advice.
No doubt I feel much better now with lots of good stuff emerging from your replies, especially Marc, Dave and Eileen's.
I will certainly go on and use your contributions to start listing and flowcharting my building industry QMS processes!
Thank you once more and I will be looking forward to joining this forum and your wise views in the future.
Best wishes,
Henrique:bigwave:

Once the document is completed and approved by the auditors I would suggest to post in this forum for the benefit of the members

Good idea, Venkat. I will do that even if it takes a couple of months (to be approved by the auditors)!

Related Threads:

ISO 9001:2000 Process Approach - What is it? Is it 'Real'? (http://Elsmar.com/Forums/showthread.php?t=3720)
The Process Approach: Is a process more than a procedure with a flowchart? (http://Elsmar.com/Forums/showthread.php?t=5695)
'Process Approach' to ISO 9000 Internal Audits - Identify an 'owner' for each process (http://Elsmar.com/Forums/showthread.php?t=5181)
Process Approach - Take 2 - Process Management vs. Function Management (http://Elsmar.com/Forums/showthread.php?t=4454)

Our documentation it is structured as follows:

Level 1. Main Processes
Level 2. Sub Processes
Level 3. Working instructions and forms

Levels 1 and 2 contain flow charts, sometime combined with text description.

Level 3 contains details for normal operating.

vio

I suggest flow charts everywhere you can. Especially level 2's. Most larger companies have problems doing some lower level documents in flow charts such as work instructions and/or travelers because their MRP/ERP systems print them.

Almost any procedure can be, and should be, flow charted. Text documents are to be avoided at almost any cost.

At Harley we flow charted just about everything except the 'quality' manual and many assembly and other various documents which the MRP software spits out. My smaller clients do the same.

The problem at many companies is as you get down to the level of assembly / work instructions (in addition to any MRP/ERP systems problems) is the detail level necessary. It becomes harder (with some processes) to use flow charts because of detail issues.

David, you've been visiting the forums long enough to see my extreme Pro-Flow Chart bias. Not to mention my Flow Chart rants.

There are numerous examples in my Implementing ISO Guide (unabashed promo).

At the least, all level 2 'procedures' should be flow charted.

-> I haven't had a client use text level 2's since 1995.

This means I haven't had a client which used text documents as level 2's since 1995. They have all exclusively used flow charts.

-> Do you mean text only L2 procedures?

I'm not sure what you mean here - but if you are saying "Yes - use text only documents for level 2's", the answer is NO. Use Flow Charts for ALL level 2's and the majority of level 3's.


could you tell me the means of "L2"?thanks!

could you tell me the means of "L2"?thanks!

It's referring to the 'levels' of documentation in a QMS (pyramid) L2 = procedures, L3 = instructions etc.

Hi all,

I am looking for more clarification on clause 7 product realization. My department is basically handling sales and marketing division. Will this clause is applicable or can we treat it as exclusion??

do reply me urgently..:confused:

Hi all,

I am looking for more clarification on clause 7 product realization. My department is basically handling sales and marketing division. Will this clause is applicable or can we treat it as exclusion??

do reply me urgently..:confused:

Welcome to The Cove Forums! :bigwave: :bigwave:

The clause that applies to you is 7.2 Customer-related processes and can not be excluded.

Tell us more about your organization. What does the scope of certification include?

Stijloor.

Thnks for replying..
Basically we are Information and communication Technology (ICT) company. I belong to Business Development department which is the front face to all our customers. We offer a wide range of solutions from software development to network managment, Data server, FMS services.

being into Business Develpoment, we do not have any ownership of product development. It belongs to other departments which are part of my company. Same way we have project implementaion and management team separately for excecuting orders/projects which customers award us.

In this whole case, Will this clause is applicable? I m really confused:confused:

being into Business Develpoment, we do not have any ownership of product development. It belongs to other departments which are part of my company.

When you say you have no ownership of product development does this mean the customer has an interface with the developers directly? Don't you, in Business Development, agree with customers on technical specs or delivery timeframes? Or is this handled directly with the developers? Who handles the reviews of customer requirements to ensure that there are sufficient resources to enable them to be met? Business Development or the developers? Who agrees with the customer that a commitment to a project can be made?

If you are looking at this as a department, then you might want to rethink '7.2' as a process. Often (Business development) organizations make commitments to customers (sales, if you prefer) that, once agreed upon, can't be met without stretching the development organization so that other projects are affected, overtime has to be worked or work isn't completed at all, or on time! Ask your development management if the sales process is very effective sometime!