The Elsmar Cove Business Standards Discussion Forums More Free Files Forum Discussion Thread Post Attachments Listing Elsmar Cove Discussion Forums Main Page
Welcome to what was The Original Cayman Cove Forums!
This thread is carried over and continued in the Current Elsmar Cove Forums

Search the Elsmar Cove!

Wooden Line
This is a "Frozen" Legacy Forum.
Most links on this page do NOT work.
Discussions since 2001 are HERE

Owl Line

The New Elsmar Cove Forums   The New Elsmar Cove ForumsThe Elsmar Cove Forums
  ISO 9001/4:2000
  Process Approach

Post New Topic  Post A Reply
profile | register | preferences | faq

UBBFriend: Email This Page to Someone! next newest topic | next oldest topic
Author Topic:   Process Approach
HFowler
unregistered
posted 03 August 2001 08:39 AM           Edit/Delete Message   Reply w/Quote
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?

IP: Logged

ISO in Baltimore
Lurker (<10 Posts)

Posts: 7
From:Baltimore, MD, USA
Registered: Jun 2001

posted 03 August 2001 10:08 AM     Click Here to See the Profile for ISO in Baltimore   Click Here to Email ISO in Baltimore     Edit/Delete Message   Reply w/Quote
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!

IP: Logged

Al Dyer
Forum Wizard

Posts: 814
From:Lapeer, MI USA
Registered: Oct 2000

posted 03 August 2001 05:40 PM     Click Here to See the Profile for Al Dyer   Click Here to Email Al Dyer     Edit/Delete Message   Reply w/Quote
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...

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4367
From:West Chester, OH, USA
Registered:

posted 05 August 2001 01:58 AM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
-> 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.

IP: Logged

David Mullins
Forum Contributor

Posts: 284
From:Adelaide, South Australia, Australia
Registered: Nov 1999

posted 05 August 2001 09:14 PM     Click Here to See the Profile for David Mullins   Click Here to Email David Mullins     Edit/Delete Message   Reply w/Quote
quote:
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?

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

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4367
From:West Chester, OH, USA
Registered:

posted 06 August 2001 02:37 AM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
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.

IP: Logged

HFowler
unregistered
posted 06 August 2001 02:23 PM           Edit/Delete Message   Reply w/Quote
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.

IP: Logged

David Mullins
Forum Contributor

Posts: 284
From:Adelaide, South Australia, Australia
Registered: Nov 1999

posted 06 August 2001 08:47 PM     Click Here to See the Profile for David Mullins   Click Here to Email David Mullins     Edit/Delete Message   Reply w/Quote
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.

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

IP: Logged

Fire Girl
Forum Contributor

Posts: 58
From:Orillia, Ontario, Canada
Registered: Apr 2001

posted 07 August 2001 09:12 AM     Click Here to See the Profile for Fire Girl   Click Here to Email Fire Girl     Edit/Delete Message   Reply w/Quote
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?

IP: Logged

E Wall
Forum Contributor

Posts: 114
From:Columbus, GA USA
Registered: Jun 2001

posted 07 August 2001 10:18 AM     Click Here to See the Profile for E Wall   Click Here to Email E Wall     Edit/Delete Message   Reply w/Quote
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

IP: Logged

goose
Forum Contributor

Posts: 31
From:nc
Registered: Apr 2001

posted 07 August 2001 10:24 AM     Click Here to See the Profile for goose   Click Here to Email goose     Edit/Delete Message   Reply w/Quote
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.

IP: Logged

HFowler
unregistered
posted 07 August 2001 10:39 AM           Edit/Delete Message   Reply w/Quote
I think for a company's first documented quality system, flow charts or picture graphs can be more useful, especially in training new employees.

IP: Logged

energy
Forum Contributor

Posts: 308
From:New Britain, CT
Registered: Nov 2000

posted 07 August 2001 11:46 AM     Click Here to See the Profile for energy   Click Here to Email energy     Edit/Delete Message   Reply w/Quote
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

IP: Logged

HFowler
Forum Contributor

Posts: 15
From:Gilbert, SC
Registered: Aug 2001

posted 07 August 2001 02:52 PM     Click Here to See the Profile for HFowler     Edit/Delete Message   Reply w/Quote
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.

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4367
From:West Chester, OH, USA
Registered:

posted 07 August 2001 03:06 PM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
quote:
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).]

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4367
From:West Chester, OH, USA
Registered:

posted 07 August 2001 03:38 PM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
-> 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!

IP: Logged

E Wall
Forum Contributor

Posts: 114
From:Columbus, GA USA
Registered: Jun 2001

posted 08 August 2001 09:15 AM     Click Here to See the Profile for E Wall   Click Here to Email E Wall     Edit/Delete Message   Reply w/Quote
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*

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

IP: Logged

HFowler
Forum Contributor

Posts: 15
From:Gilbert, SC
Registered: Aug 2001

posted 08 August 2001 09:46 AM     Click Here to See the Profile for HFowler     Edit/Delete Message   Reply w/Quote
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.

IP: Logged

Kevin Mader
Forum Wizard

Posts: 611
From:Seymour, CT USA
Registered: Nov 98

posted 08 August 2001 10:19 AM     Click Here to See the Profile for Kevin Mader   Click Here to Email Kevin Mader     Edit/Delete Message   Reply w/Quote
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

IP: Logged

HFowler
Forum Contributor

Posts: 15
From:Gilbert, SC
Registered: Aug 2001

posted 08 August 2001 11:09 AM     Click Here to See the Profile for HFowler     Edit/Delete Message   Reply w/Quote
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.

IP: Logged

HFowler
Forum Contributor

Posts: 15
From:Gilbert, SC
Registered: Aug 2001

posted 08 August 2001 04:10 PM     Click Here to See the Profile for HFowler     Edit/Delete Message   Reply w/Quote
quote:
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.

IP: Logged

David Mullins
Forum Contributor

Posts: 284
From:Adelaide, South Australia, Australia
Registered: Nov 1999

posted 08 August 2001 08:42 PM     Click Here to See the Profile for David Mullins   Click Here to Email David Mullins     Edit/Delete Message   Reply w/Quote
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).

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

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4367
From:West Chester, OH, USA
Registered:

posted 09 August 2001 07:55 AM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
-> 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.

IP: Logged

HFowler
Forum Contributor

Posts: 15
From:Gilbert, SC
Registered: Aug 2001

posted 09 August 2001 09:28 AM     Click Here to See the Profile for HFowler     Edit/Delete Message   Reply w/Quote
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.

IP: Logged

Marc Smith
Cheech Wizard

Posts: 4367
From:West Chester, OH, USA
Registered:

posted 09 August 2001 11:24 AM     Click Here to See the Profile for Marc Smith   Click Here to Email Marc Smith     Edit/Delete Message   Reply w/Quote
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.

IP: Logged

HFowler
Forum Contributor

Posts: 15
From:Gilbert, SC
Registered: Aug 2001

posted 09 August 2001 11:52 AM     Click Here to See the Profile for HFowler     Edit/Delete Message   Reply w/Quote
No apologies necessary. Thanks for waking me up.

IP: Logged

barb butrym
Forum Contributor

Posts: 662
From:South Central Massachusetts
Registered:

posted 09 August 2001 12:36 PM     Click Here to See the Profile for barb butrym   Click Here to Email barb butrym     Edit/Delete Message   Reply w/Quote
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,,,,,,,Hell 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......

IP: Logged

Kevin Mader
Forum Wizard

Posts: 611
From:Seymour, CT USA
Registered: Nov 98

posted 09 August 2001 12:56 PM     Click Here to See the Profile for Kevin Mader   Click Here to Email Kevin Mader     Edit/Delete Message   Reply w/Quote
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.

IP: Logged

Ross Simpson
Forum Contributor

Posts: 13
From:Irvine, Ca., USA
Registered: Dec 1999

posted 10 August 2001 02:31 PM     Click Here to See the Profile for Ross Simpson   Click Here to Email Ross Simpson     Edit/Delete Message   Reply w/Quote
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

IP: Logged

Al Dyer
Forum Wizard

Posts: 814
From:Lapeer, MI USA
Registered: Oct 2000

posted 10 August 2001 02:40 PM     Click Here to See the Profile for Al Dyer   Click Here to Email Al Dyer     Edit/Delete Message   Reply w/Quote
Barb,

IP: Logged

HFowler
Forum Contributor

Posts: 15
From:Gilbert, SC
Registered: Aug 2001

posted 10 August 2001 03:00 PM     Click Here to See the Profile for HFowler     Edit/Delete Message   Reply w/Quote
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.

IP: Logged

rrramirez
Forum Contributor

Posts: 29
From:Caracas, Venezuela
Registered: May 99

posted 16 August 2001 07:16 PM     Click Here to See the Profile for rrramirez   Click Here to Email rrramirez     Edit/Delete Message   Reply w/Quote
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!

IP: Logged

All times are Eastern Standard Time (USA)

next newest topic | next oldest topic

Administrative Options: Close Topic | Archive/Move | Delete Topic
Post New Topic  Post A Reply
Hop to:

Contact Marc Smith | The Elsmar Cove Home Page

Please Visit the new Elsmar Cove Forums! All these threads are there and much more!

Main Site Search
Y'All Come Back Now, Ya Hear?
Powered by FreeBSD!Made With A Mac!Powered by Apache!