Please Review my High Level QM (Quality Management) Process Map

[michellemmm]

Well I still don't understand half of the processes with supplier and repair and training, etc you are referring to. That does not need to be depicted here. However, I noticed that you didn't post any of the ways in which you are complying to ISO. (not to say that I don't want feedback)

I think you are too concerned with showing lower level processes and their sequence which should not be displayed in the QM. Those flows will be represented in procedures or work instructions but not the manual. I think your theory is incorrect.

Let me share one of early experiences in my career that changed the way I think and approach situations...

Picture this ...1982...Oil Crisis...Layoffs... business contraction...I ended up reporting to Sr. VP after 2 years of experience (became the acting Manager of Manufacturing Engineering ). I was at the same level as the directors and VP of manufacturing. One day, the VP of Quality walks to my bosses' office and hands him a 50+ page quality report (we did not use PC or emails back then..all charts were done by hand). My boss says "Thank You." He then places the report in his trash can. The Quality director objected to his action. My boss told him:"I know what this report is...Get back with me when you can shrink this in 1/2 page."

My point is: Higher level reports and maps do not need details. Details belong to lower level...

When I design my QMS, my first map aligns business processes with QMS and ISO. My starting point is "Business Planning." The ending point is "Continual Improvement." I then choose critical processes and map them out, identifying the details to a certain level. For third level, I zoom and construct a turtle....

A CEO does not need to see how non conforming material process or RMA ties to CAR or document control.

The first map I ever posted, portrayed high level sales strategy and was butchered by auditors in this forum...They questioned the accuracy and usefulness...That particular map was praised by my mentor and is being used and proved effective...

I personally think you have too many details for top level map (unless they are micro/nano managers)... Your map should be used by top management and customers (top management) and they simply need a city map and not turn by turn map.

When you are approaching top management, try to shrink/contract your conversation/report/material to less than 2 minutes...For those 2 minutes need to cover what normally takes place in one/two hours management meeting...

Good Luck!!!!!!

 

[CliffK]

Well I still don't understand half of the processes with supplier and repair and training, etc you are referring to.

Okay. Does it help if I say:

• Upstream process instead of internal supplier
• Downstream process instead of internal customer

Or --

• Process that provides inputs instead of internal supplier
• Process that uses outputs instead of internal customer

However, I noticed that you didn't post any of the ways in which you are complying to ISO. (not to say that I don't want feedback)

How about these two paragraphs that I wrote in the middle of my post:

How about Old Fashioned Text (OFT)? You could easily capture the level of detail in this chart in one or two well-chosen paragraphs. I would venture to say you could hone those paragraphs to perfection in far less time than you have spent on this chart so far.

Or if you want to have charts that say something meaningful and specific to your organization, create them and incorporate them into your manual by reference.
​

I think you are too concerned with showing lower level processes and their sequence

I hate to see people waste time on generic fluff when they can spend time on something of actual value.

which should not be displayed in the QM.

Why not? If you were run over by a beer truck, which charts would be of more value to your successor? Cookie-cutter charts that could fit any organization or charts that describe what actually goes on in your organization?

Those flows will be represented in procedures or work instructions but not the manual. I think your theory is incorrect.

I think you don't know my theories about quality manuals. One is the beer truck theory. It goes like this: if the management rep gets run over by a beer truck, the quality manual should contain enough information so the new management rep can get up to speed quickly.

Another is the KISS theory.

According to my theories, the quality manual adds value in terms of continuity. It can also help the management rep should he forget some detail about the QMS. A simple quality manual costs the organization less because it's easy to understand. People may actually read a simple quality manual.

 

[CliffK]

Let me share one of early experiences in my career that changed the way I think and approach situations...

<big snip>

When you are approaching top management, try to shrink/contract your conversation/report/material to less than 2 minutes...For those 2 minutes need to cover what normally takes place in one/two hours management meeting...

Good Luck!!!!!!

Good post. No disagreement here.

Here's my problem with the chart in question: all of the information on it could be conveyed in three short sentences along with two bulleted lists and one numbered list.

The result would be less work to create, occupy less space on the page and be easier to understand.

When Lou Gerstner became president of IBM, he refused to allow Powerpoint presentations into his meetings because people were spending too much time on eye candy and not enough time on content. That's how the chart in question makes me feel.

 

[michellemmm]

Good post. No disagreement here.

Here's my problem with the chart in question: all of the information on it could be conveyed in three short sentences along with two bulleted lists and one numbered list.

The result would be less work to create, occupy less space on the page and be easier to understand.

When Lou Gerstner became president of IBM, he refused to allow Powerpoint presentations into his meetings because people were spending too much time on eye candy and not enough time on content. That's how the chart in question makes me feel.

Cliff,
If you think eye candy is bad, please consider necessity of balancing right brain and left side of brain. I use eye candy because I am an artist and an analytical scientist. Without color, I doze off....

Let me share one of my maps....
You may need your sun glasses...

I am attaching a simple one I call them IPOMs (Input-Process-Output Maps)... This is MY FORMAT...It is not a flow chart. In my IPOMs, you rarely see a decision box branching, unless it is a MAJOR one...Horizantal sections represent a simplified "turtle".
My IPOMs are gated and structured based on PDCA...I may change them later to DMAICR...

This map was constructed to depict "Continual Improvement" road map of RMA process.

 

[JaneB]

Do others feel that this is a waste? If so, how do you comply with 4.2.2 c?

Yes. (And I bet that raises a storm of protest).

4.2.2c does NOT mandate any diagram nor a process map.

These days I very rarely bother with a 'process map' or a 'system diagram'. Unless my client has a preference for graphic representation, I rarely find that the time & effort involved is worth it.

Plus, people have different ways of 'modelling' or representing things. Your model suits you but you may loathe one of mine, and vice versa. I hate the fact that the customer turns up in 2 separate places in the classic ISO 9001 model, for example.

It's possible at times that the process of doing it is a valuable activity in itself. Again, I have very rarely found that with the clients I've worked with - but that may also be associated with the types of clients, systems and fields I've had.

I've now pretty well stopped doing 'process maps' or 'system diagrams' - the clients rarely see the point and don't get value from them. So they're not worth the time (& thus my cost). I most often these days use either words (eg, short description of management processes, specific references within procedures to other procedures) or a very simple generic type of diagram. And if I came across an auditor absolutely insisting on a 'process map'... I'd find another auditor (or certifier), frankly.

The strength of the debate on this topic is interesting - some people express strong preference for a particular posted diagram/map/representation, while others express strong criticisms. You certainly can't make everyone happy!

 

[cthink]

Cliff,
If you think eye candy is bad, please consider necessity of balancing right brain and left side of brain. I use eye candy because I am an artist and an analytical scientist. Without color, I doze off....

Let me share one of my maps....
You may need your sun glasses...


That's my sort of visuals!

I work in a community services area and some of the process or procedure documentation I help our staff with needs to be visual or colorful. Some staff are fantastic in delivery of service to our "customers" but often are not big on the technical detail like paperwork or documents so this sort of visual works for them.

Also some of our "customers" may be disadvantage youth or people with a disability. Putting the "eye candy" in documents that they need to read or understand really helps.

Our high level QMS "map" doesn't have any pics but is a colorful visio diagram. Our board and management team find it easy to understand how everything fits and connects within the whole organisation with this type of visual. We are a diverse organisation with a number of quality standard requirements not just ISO so I find this helps piece it all together.

So to echo some other comments, what works for our organisation may not be suitable in another environment but I don't think that makes any one type more "right" (or wrong for that matter), it just means you need to take into account your audience as well.

cheers

 

[CliffK]

<snip>
So to echo some other comments, what works for our organisation may not be suitable in another environment but I don't think that makes any one type more "right" (or wrong for that matter), it just means you need to take into account your audience as well.

cheers

Quite right. I'm glad you found a solution that works for the organization.

That said, I would add some considerations:

First, graphics cost more than text to deliver any given payload of information. They take more time to polish and get right. An excellent example is the graphic that launched this thread. It's on its third iteration, and you can see the huge amounts of labor that have gone into getting it into its current state. The same information could have been conveyed in three short sentences, two bulleted lists and one numbered list. The text could have been written in much less time than needed to revise the chart.

Given that, it doesn't make sense (to me at least) to jump into a lot of diagramming when creating QMS documents, unless there's a compelling reason, such as yours.

Second, not everyone has the talent that allows you to create great charts. In fact, I would that your talent is very rare. I've seen plenty of examples and most are, well, just wretched. Most other Covers with broad exposure to lots of organizations (auditors, consultants, trainers) share my opinion, if the comments that I have read are any indication (and I think they are.)

What does that mean? Well, let's say you've created a great set of flow charts for your organization and you move on because you win the lottery or get run over by a beer truck. Who will maintain these charts? Chances are very good that the organization does not have someone with your talent and the charts will not be well maintained.

 

[cthink]

Second, not everyone has the talent that allows you to create great charts. In fact, I would that your talent is very rare. I've seen plenty of examples and most are, well, just wretched. Most other Covers with broad exposure to lots of organizations (auditors, consultants, trainers) share my opinion, if the comments that I have read are any indication (and I think they are.)

What does that mean? Well, let's say you've created a great set of flow charts for your organization and you move on because you win the lottery or get run over by a beer truck. Who will maintain these charts? Chances are very good that the organization does not have someone with your talent and the charts will not be well maintained.

Good points Cliff,

I think we often spend too much time recreating things our predecessors have done "their way" (sometimes the written docs you inherit too) and I acknowledge I am adding to the problem for whoever follows me.

I suppose as a lone quality support person within the organisation I do what works for me and delivers for my internal customers. Many only have documented procedures the good old way and that suits them.

I would be happy if things were just documented using Plain English but there's a whole other topic that's dear to my heart

again thanks for posing your questions

Cheers
Wendy

 

[cthink]

I'm not sure what you found complicated - perhaps the whole thing. But I think it's pretty straight forward, ultimately which is all that matters. If you could elaborate, I would appreciate it.

I mentioned that I would repost my tentative "finished product" and here it is. There is some explanation that is probably needed which makes it not so "straight forward" as some but much more comprehensive IMO.

Layout:
The requirements for the QS come in at the top. There are four "key processes": system (SOP2s), mgmt (MOPs), support (SOPs), and customer (COPs). The "system (SOP2s)" encapsulates everything as internal audits and control of doc/records touch everything.

Explanation:
There are sort of two models here. The first is the mgmt level processes, which are the arrows stemming out of the MOPs (blue square). Essentially, data from the SOPs, COPs, and SOP2s (green, pink, and yellow) is fed into the MOPs (mgmt - blue) and then CAPAs are fed back for correction and improvement.

Then, you have the other key processes for the company, not just mgmt. This is shown by the dotted black line. The MOPs and SOPs feed into the COPs which ultimately feed into the customer.

That's sort of the explanation in a nut shell. If you have feedback, I'd love to discuss and improve my model. If you'd like to use it, please do so.

Thanks!

Just one question, I see that Internal Audits are in the yellow system area, I can't see where Corrective & Preventive Action and Cont Imp "flows" from Internal Audits to delivery areas. If audits pick up on C&PA or identify how things could be improved how does that interact??

To me it looks like C&PA is moving from the inside out to the audit area??? or have I misunderstood this altogether

Thank you for posting this, I have enjoyed the discussion and following your thought and the responses.

 

[cdagnan]

Having been fortunate to see Patricia's model and how she lays out a process I think we all need t otake a step back and remember that the QMS is not about making widgets, its about managing a business which delivers what a customer wants at a price which means they'll keep buying and we'll still be around!

The broad overview of Patricia's model shows clearly the interaction of the key process that enable a busienss to function.

I would change the "customer oriented process" name to Product or Service depending on the client as imho all processes are be customer facing. also perhaps change control should be more a system oriented process as the change relates to the documentation/controls the output of which is the correctwidget/service.

The clear information flow and the use of colour in the process layouts - there is one posted on another thread - clearly show how a top level process works.

ISO9000 is about the system and processes that create a satisfied customer - not about making correct widgets. The correct widgets are a consequence of the management decisons in using the information around them - fro mthe results of the 12 process Patricia has in her model.

I have a lot of work to do to move from over 200 documents in a 80person company to 12 key process and a few more below...whilst maintaining the output and quality..