|
Elsmar Cove Forum Sidebar
|
|
|
|
Monitor the Elsmar Forum
|
| Monitor New Forum Posts
|
|
Follow Marc & Elsmar
|
|
|
Elsmar Cove Groups
|
|
|
Sponsor Links
|
|
|
|
|
|
Donate and $ Contributor Forum Access
|
 |
|
Sponsored Links
|
|
|
|
Courtesy Quick Links
|
 Links that Elsmar Cove visitors will find useful in your quest for knowledge:
Howard's International Quality Services
Atul's Symphony Technologies
Marcelo Antunes' SQR Consulting
Bob Doering's Correct SPC - Precision Machining
NIST's Engineering Statistics Handbook
IRCA - International Register of Certified Auditors
SAE - Society of Automotive Engineers
Quality Digest Portal
IEST - Institute of Environmental Sciences and Technology
ASQ - American Society for Quality
|
|
 |
|

28th January 2002, 06:15 AM
|
|
Appreciated Member
Registration Date: Jan 2002
Location: United Kingdom
Age: 52
|
|
Posts: 1,705
Thanks Given to Others: 457
Thanked 552 Times in 355 Posts
Karma Power: 226
|
|
|
Quality Management System Processes
Hi! A starter for 10. How are people getting on with explaining processes to their organisations? Now that we have everyone attuned to documenting procedures for their departments we're asking them to bin them and think about customer serving (or core) processes and administration / support processes.
How many processes that you've implemented have cut across departmental boundaries?
How are the process inputs and outputs identified to the people working the process?
How comfortable are you and the process owners with process monitoring and measurement and has this lead to more data in the QMS?
Now that a lot of processes don't necessarily have to be documented has this reduced the amount of documentation in your systems?
No ulterior motive with this, just curious as to how different the Process Approach is in its implementation.
|

1st February 2002, 09:47 AM
|
 |
E-Mails Invalid or Rejected by Recipient System
Registration Date: Oct 2001
Location: UK
|
|
Posts: 61
Thanks Given to Others: 0
Thanked 0 Times in 0 Posts
Karma Power: 0 Karma: 10 
|
|
It's a poser innit Del?
Paul,
I am having a nightmare trying to get people to distinguish between processes and procedures.
This is due to the fact that terminology such as process and procedure is used corporately in such a flippant way that people make assumptions about what they really mean!
I am trying gradually to expalin the differences to people but I may as well be trying to tell them that I'm the daughter of Cher and Elvis! They just don't get it!
They will though. I've put together a core business process based on our project management activities which is our main area of business. This process spans across the org. Under each section there are support processes which span across varius functions as required.
MAybe by showing them (visually) what is meant by a process maybe they'll realise the difference between the two!
lau.
|

1st February 2002, 02:43 PM
|
 |
Still plugging along
Registration Date: Nov 2001
Location: USA
|
|
Posts: 546
Thanks Given to Others: 13
Thanked 23 Times in 17 Posts
Karma Power: 102
|
|
Talk about timing!
This is what my morning was all about today!
I spent the better part of the last two days determining our processes (after the input from the Implementation Team) and drawing beautiful flowcharts in Visio that showed the process being described along with all the inputs and outputs to the other processes.
Then I get into a meeting with one of our departments and my boss, who is the VP of the department as well as the QMS Management Rep, scraps it.
So we get into a disagreement about the role of "processes" and how they will be represented.
One of my coworkers in the meeting has a lightbulb go off and says "oh, so the difference between a process and a procedure is....yada yada. I've always thought of them as the same thing".
Anyway, our "processes" will cut across departmental lines since we have now decided that our "processes" will be : Commercial (everything having to do with the money: contracting the work, invoicing, proper submission of reporting, etc); Technical ( everything having to do with the technical aspects of our work, including design, maintenance of equipment, engineering changes, etc.); and Operations ( the carrying out of our services). The support processes will be procurement, human resources, marketing, etc.
Blows all of my nice flowcharts out of the water, but that's OK. I'll start over. No problem.
I just don't how it's going to look....
|

1st February 2002, 04:19 PM
|
|
|
|
Its sounds to me like you are talking about the level of processes, rather than the definition of processes themselves.
You can consider processes at the macro or micro level - they are both still processes, and obviously processes are made up of interlinked sub-processes.
I'm sure most, if not all companies departments evolve naturally around processes, and many departmental procedures will continue to serve as a written description of a process.
|

2nd February 2002, 12:53 AM
|
|
Courtesy Access
Registration Date: Feb 2002
Location: California
|
|
Posts: 20
Thanks Given to Others: 0
Thanked 1 Time in 1 Post
Karma Power: 48 Karma: 15 
|
|
|
I think there are many different ways (and no absolute correct way) to approach this:
My take is that all organizations (systems) consist of a series of processes; for example, a manufacturing company may have the following processes: Order Management, Materials Management, Production Management, Human Resource Management, etc. Each of these processes can be represented by a flowchart (but can certainly be represented in other ways, perhaps by a Gannt chart, picture, or other method).
All of these processes consist of activities (sub-processes) that can be documented in procedures. The Order Management process, for example, may be supported by 3 or 4 documented procedures, such as quoting, order entry, order changes, etc.
Dividing the company into key processes makes the complex system more manageable: you can develop measurable objectives for the processes, you can audit by process, you can review resource requirements for each process, etc.
The biggest challenge is to get people to understand that we are talking about processes, not departments.
Once they get that, this works very well.
Julie
|
|
Thanks to juliedrys for your informative Post and/or Attachment!
|
|

5th February 2002, 03:42 AM
|
|
Appreciated Member
Registration Date: Jan 2002
Location: United Kingdom
Age: 52
|
|
Posts: 1,705
Thanks Given to Others: 457
Thanked 552 Times in 355 Posts
Karma Power: 226
|
|
|
Just as I thought!
The replies are similar to what I expected. I've been speaking to clients about processes and have had mixed responses. My ideas are a bit radical for some: Get rid of all your procedures and just document a series of inputs to an area, measures in place within the area and who and what is involved (resources), they don't even have to flowchart under the new ISO!
Where it goes from there is that most people feel dubious about dumping all the procedures thay have created and NOT REPLACING THEM WITH ANYTHING, except a small list of items (as above).
Don't get me wrong I think procedures are great in the right place and that flowcharts work well in visually displaying how things "flow" through the organisation. I also happen to believe that work instructions have a place where it is important that operations are carried out in a defined sequence and to a prescribed format but these days we have a lot of people who are specifically trained for tasks and the operations are controlled by IT systems ..... so do we need anything documented?
How radical is this for auditors? If a process is working smoothly and measures show that they are then don't expect to see a document that describes it! Get out there and talk to the people, don't stick your nose in a manual for half an hour and come back with a list of typos!
Auditors beware ..... the real world beckons!
|

5th February 2002, 04:41 AM
|
 |
E-Mails Invalid or Rejected by Recipient System
Registration Date: Oct 2001
Location: UK
|
|
Posts: 61
Thanks Given to Others: 0
Thanked 0 Times in 0 Posts
Karma Power: 0 Karma: 10 
|
|
|
And so say all ofus
Paul,
 Yes I agree.
I'm having the same problem, people don't feel comfortable unless they have reams and reams of paper surrounding them documenting how to clean the loo and make the coffee.
My approach is similar to your and I do feel that work instructions do have a place in a quality system if only to act as a training manual or reference guide.
I'm anxious to cut down the amount of paperwork and to eliminate the 'bureaucratic' image that people seem to have of Quality.
May the force be with me eh?
|

5th February 2002, 05:04 AM
|
 |
Courtesy Access
Registration Date: Dec 2001
Location: England
|
|
Posts: 1,652
Thanks Given to Others: 10
Thanked 72 Times in 50 Posts
Karma Power: 213
|
|
|
Here Here
I also agree with the above post from Paul.
Personally I would also like to ditch all procedures as the simple fact of the matter is that no-one uses them and they add no value to the organisation. They only serve as road maps for blind auditors to pick up trivial findings.
However many of our customers still want, and expect to see written procedures. So although the new ISO9001:2000 standard frees us up from the torment of procedures, our customers have not, but this may change as the new standards influence spreads.
Fingers crossed.
|
|
Thanks to M Greenaway for your informative Post and/or Attachment!
|
|
Lower Navigation Bar
|
|
|
Do you find this discussion thread helpful and informational?
|
Visitors Currently Viewing this Thread: 1 (0 Registered Visitors (Members) and 1 Unregistered Guest Visitors)
|
|
|
| Thread Tools |
Search this Thread |
|
|
|
| Display Modes |
Rate Thread Content |
Linear Mode
|
|
Forum Posting Settings
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
|
|