Quality Management System (Core) Processes and Administration / Support Processes

[Paul Simpson]

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.

 

[Laura - 2003]

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.

 

[JodiB]

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....

 

[Unregistered]

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.

 

[juliedrys]

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

 

[Paul Simpson]

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!

 

[Laura - 2003]

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?

 

[M Greenaway]

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.

 

[JodiB]

No one using procedures?

Without a written contract with a client you only have your word against his. Would you tolerate that? Would you do a deal worth thousands of dollars based on a verbal agreement consisting of a multitude of terms and conditions?

Why should a company insist on contracting with outsiders and yet not contract with its own workers in the provision of the company's business???

A written procedure is indisputable, evidential, documentation of the way a company operates and contracts with its employees to perform the company functions. It is intended to be the reference for all verbal disputes over responsibilities, methods, and any other clarifications that are needed.

They are developed as a result of "best method" thinking, so that employees have the proper tools and that proper staffing is maintained.

They provide clarification and translate the personal knowledge of the few into tangible knowledge of the organization.

When I hear things like "let's dump the procedures", I equate it with my child's teacher replying to my child's spelling question with : "well, how did Johnny tell you to spell it?" Or " you're a big kid now, how have you always spelled it before?" instead of saying " Go look it up in the Webster's dictionary".

 

[tfish]

Ditch all the procedures????

We simply need to provide appropriate clear links between the procedures to define our processes.

Look at the new "process" version as the Deming PDCA system and apply the elements as you go around the circle.