Greetings Covers!

I started with a new company this year and one of my tasks is to help their frail QMS – both to pass the audit AND to improve the business’ performance. (Yes, they actually get that!) Anyway, they barely squeaked by at registration last year, mostly because they really didn't understand 4.1 – not really process-based, everything was quite “departmentalized,” they were doing system audits from a generic checklist, etc, etc. They have little to no metrics – the Policy and Objectives are weak and must be redone. The registrar noted that they expect to see some real defined and measurable objectives next time, and would like to see process based internal audits.

So, I’d like to share my plan with you guys, for a reality check, to make sure I’m on the right track. For reference, at my old company we had a good consultant when we first built the QMS in 2002 – this is really the first time I’ve done it myself. Here’s what I’m planning:

1. Educate management about the process approach. (Done, they like it)

2. Identify the key processes – I know them as Management Processes and Product Realization processes (and sub-processes) (Done)

3. Create a process map (broad brush) showing interaction of the processes.

4. Create process maps for each of the processes, identifying the responsibilities, objectives, inputs, outputs, controls, etc (the PDCA approach)

5. Identify how the existing procedures fit in to the newly identified processes.

a.Identify areas where a procedure (or work inst.) is needed, or exists but really isn’t necessary.

6.Identify where measurements should be taken, but aren’t (from the objectives of the processes)

a.Identify the records (or lack therof) and fix that.

7.While I and others create/edit these docs, I will pressure management to come up with the upper-level Objectives, then we will re-write the Quality Policy, making sure it meshes with the Objectives.

8.After all the process maps, procedures, and work instructions are complete, we will check to make sure that all ISO standard requirements are met (This is a gap analysis, right?)

9.Lastly, we will revise the Quality Manual to include the correct references and linkages.

10.Next we will train everyone to the new system. (Including training auditors in process-based auditing)

11.Then we will schedule and perform the internal audits using a process-based planning checklist and reports. (Many good examples here at The Cove:thanx: )

12.Lastly, we will conduct a management review to analyze the fruits of this effort.

13.Nov. 1, 2006 will be the surveillance audit. I’m hoping this one goes well.

Thanks in advance for any advice! This forum has been a great resource.:D

Tym

It looks pretty comprehensive! It seems you've got a lot of the subtleties I look for in a QMS implementation.

Here are a couple of thoughts:
For item 4, you might consider using turtle diagrams. This will also roll in items 5 and 6. They are also very useful in planning for process audits.
As you stated in 6, I believe that the objectives should be tied in to the measurements of the processes you've defined. Ideally you should have the "process objectives" in 6 support the "upper-level objectives" in 7. To do this, you may want to define the upper-level objectives first, then make sure that the process objectives support the organization objectives
There's my :2cents:

Good plan - a nice grasp of the importance of implementing the system. Make certain that you get the natural process owners to be able to do a 'show and tell' of their process: -

They should know (like in the biblical sense):-

The requirements (customer, regulatory, ISO etc.)

The process (inputs, outputs, controls.)

The performance (objectives, measurements, monitoring and results)

The actions (Improvement or correction, depending on above)

Put together a 3 ring binder with four tabs and have each owner populate this with 'evidence'. Then do a show and tell and evaluate how well they 'sell' their process. Make the most senior manager (CEO, Pres. whatever) ask some 'auditor style' questions and a big 'show me'.

But, whatever you do, don't use the bloody turtle..........unless you want to live with the consequences............:frust:

Good Luck!
Andy

What is the issue with using Turtle Diagrams. My Automotive customer and registrar live and die by them. I feel kind of stuck if I don't use them.:topic:

G Stein

Put together a 3 ring binder with four tabs and have each owner populate this with 'evidence'. Then do a show and tell and evaluate how well they 'sell' their process. Make the most senior manager (CEO, Pres. whatever) ask some 'auditor style' questions and a big 'show me'.

But, whatever you do, don't use the bloody turtle..........unless you want to live with the consequences............:frust:

What consequences? :confused: Can you be more specific? I feel that they're a good tool you can use to summarize a lot of important process information. Process owners can use them to understand their processes, management can use them to review the processes, and internal auditors can use them to prepare for audits and evaluate the effectiveness of the processes.

By the way, the last audit I did where the company used binders populated with evidence (they called them "Smart Books") it earned them a nonconformance. It turns out they used the binders (which never got updated) instead of the official controlled documents. :whip:

What is the issue with using Turtle Diagrams. My Automotive customer and registrar live and die by them. I feel kind of stuck if I don't use them.:topic:
I think a lot of companies do them (wrong) to make a customer or auditor happy. I use them because I like them - even with non-automotive clients...

)


But, whatever you do, don't use the bloody turtle..........unless you want to live with the consequences............:frust:

Good Luck!
Andy

Andy,

Would you elaborate a bit on the consequences? I always like to know the pitfalls in any process. The turtle seems like a solid tool that's intuitive and easy to follow, but if there's a way to screw it up, I'll find it!

Tym

I have used turtles, process map, flow charts, diagrams to show an define various processes including contract review through out the door, and support processes. Never had an issue with an auditor going through the registration process for ISO9001/TS16949. We also used them for ISO14001:2004 with a different registrar with no issues. They both liked what we had. Use whatever works for your organization.

There's a saying....."Just because you can, doesn't mean you should."

In the context of the Turtle, we have to understand what it was originally created for - to get external auditors to prepare and think 'process' when doing an ISO/TS 16949. It's a bastardized Ishikawa/Fishbone diagram, of course.

As a visual metaphor is 'looks nice' but misses the point of an implementation tool which is to get the management of the organization to define and document it's processes, their sequence, interaction and the methods and criteria by which the process(es) are controlled.

Filling out a turtle (which is all people want to do, to get the nasty task over with) completely misses the point. What's more, many folks (here) feel validated if their registrar (many of whom have never been through the pain of implementing the 'process approach') doesn't write a finding or, indeed, enjoys seeing them - of course they would, they got trained to use them!!

I've found that management have no clue what to put in what box, but if you lead them through a process mapping/value stream mapping exercise, the lights go on about how inefficient and convoluted their processes are. The improvements jump off the diagram - the turtle does what all turtles do - move slowly along...........

Better still, the sequence and interaction of the processes is where most organization have problems and turtles don't help (at all) with that aspect!

By using them, you miss the most valuable opportunity to develop a true system and look for improvements - getting each part of the organization to use a turtle re-inforces the 'silo' and won't help break down barriers.

My mantra here is and will always be - what benefit is this to your management?

Sure many folks will say "I love them, my auditor does" etc. but the real answer is what your management tell you about them........

Andy

Alright Andy,
I see what you mean. I'm pretty sure I see how a turtle can be valuable for audit planning. Are you saying folks are using them for processes?

Take a look at the file I attached. I got it from the Cove, perhaps the owner will chime in? What is its purpose and where does this document fit into the Quality system? From the "How" Section, I can see that numbered Procedures and Work Instructions still exist. What does this diagram provide that isn't available in those documents and why was it chosen to provide that information?

I'm asking seriously - I've been researching the process-based approach for a couple of weeks now, and while it's getting more clear I still see half forest/half trees.

Thanks to all,
Tym

Yup! And in one totally bizarre case - the whole system!

Duh!:lmao:

Andy

First off, I'd better start by saying, I'm not trying to be argumentative (OK, maybe just a little). I want to go point by point through AndyN's post, because I feel that there's a bias there, and I have some different opinions. Of course, opinions are like armpits - everybody has two, and most of them stink.

There's a saying....."Just because you can, doesn't mean you should."

And another saying... "If the only tool you have is a hammer, everything looks like a nail."

In the context of the Turtle, we have to understand what it was originally created for - to get external auditors to prepare and think 'process' when doing an ISO/TS 16949. It's a bastardized Ishikawa/Fishbone diagram, of course.

I think the Ishikawa/Fishbone diagram is a pretty good tool too. Is there something wrong with modifying it (bastardize implies that it's not legitimate) for another purpose?

As a visual metaphor is 'looks nice' but misses the point of an implementation tool which is to get the management of the organization to define and document it's processes, their sequence, interaction and the methods and criteria by which the process(es) are controlled.

As a consultant I don't encourage people to use a turtle instead of a process map. I like to use a top-level process map (which defines sequence and interactions), lower-level process maps (to define lower-level sequence and interactions), and turtle diagrams (to define the details that won't fit on the process maps).

Filling out a turtle (which is all people want to do, to get the nasty task over with) completely misses the point. What's more, many folks (here) feel validated if their registrar (many of whom have never been through the pain of implementing the 'process approach') doesn't write a finding or, indeed, enjoys seeing them - of course they would, they got trained to use them!!

Sounds like somebody shoved a turtle down your throat! :whip: I've also seen very poorly done process maps that completely miss the point, done by people who just wanted to get the "nasty task" over with.

I don't care what the registrar auditor wants. As a 3rd party auditor I've never written a nonconformity because a company didn't have a turtle diagram. I've also never written a nonconformity because they didn't have a process map. I have written nonconformities when they didn't adequately describe their processes and interactions (in whatever format they chose).

I've found that management have no clue what to put in what box, but if you lead them through a process mapping/value stream mapping exercise, the lights go on about how inefficient and convoluted their processes are. The improvements jump off the diagram - the turtle does what all turtles do - move slowly along...........

I've found that management have no clue how to create a process map either. But if you lead them through exercises on how to use any appropriate tools, the lights go on. This includes turtle diagrams.

Better still, the sequence and interaction of the processes is where most organization have problems and turtles don't help (at all) with that aspect!

I don't know about your turtles :confused:, but mine include include sequence and interactions. Usually in more detail than in the high level process map.

By using them, you miss the most valuable opportunity to develop a true system and look for improvements - getting each part of the organization to use a turtle re-inforces the 'silo' and won't help break down barriers.

If you think processes are silos, no tool will help. Any process must look within itself for control and improvement so that necessary results are achieved and interactions with other processes are effective. That's what process maps can help to do, and that's what turtle diagrams can help to do (at least mine do - I don't know what you've seen).

My mantra here is and will always be - what benefit is this to your management?

:yes: Yup.


Sure many folks will say "I love them, my auditor does" etc. but the real answer is what your management tell you about them........

Andy

:yes: At the end of the day, we agree at least on a few things. :agree1:

O.K. So I'm biased. People come here to ask for help. I've offered mine based on not what I do with clients, but what I see many people try and get in a real mess by using them. But, boy oh boy, the folks that introduced them feel really validated when the external auditor says 'nice work' - the problem with being a consultant is we either confuse our clients with 'options', when most want to know about one or two methods (which actually work) so they can select one. My advice is that they're not an implementation tool, even if they can be used. I guess it's my upbringing. I was taught to look after the tools I had, not just go and find a new one to do the same job. Get the skills to use what you have, if you like!

I'm against the hype that this confounded diagram is being hawked as being a silver bullet. Read other posts around here to see that a large population are using them without any beneficial goal in mind. So, without any qualification from us as 'helpers' new folks will (naturally) assume all these tools are equally useful. I won't stand by and let that false assumption prevail. Even the AIAG/Plexus/IATF training is down-playing them! My bet is because they have become a legend as the way to get past the auditor (Doh!).

But why do I care - I have the next great visual metaphor which will change everything..................hahahaha, hehehehe.......:lmao:

Andy

I'm biased too. Andy, I very much respect your thoughts, ideas, and input to the forums, even if I disagree with a point now and then. I hope Tym (and everyone else here) realizes that everyone has their own take on things based on knowledge and experience. Everything posted here should be taken with a grain of salt and everyone should form their own opinions. Preferably opinions that agree with mine. :lmao:

I've taken to using turtle drawings when it's helpful to plan an audit because not all proceses look very clear cut or linear. When one wants to show types of controls, input, responsibilities, records etc. in a quick sketch it can be dreamy. If the diagram doesn't quite work right, alter it.

I agree it's not a replacment for process documents.

Same goes for flow charts, which can be quite a big help but IMHO shouldn't be relied on for the whole system.

...As a consultant I don't encourage people to use a turtle instead of a process map. I like to use a top-level process map (which defines sequence and interactions), lower-level process maps (to define lower-level sequence and interactions), and turtle diagrams (to define the details that won't fit on the process maps)...


Howste, I thought your comments were very well spoken.

Andy, I agree there are NO silver bullets, therefore Turtles are not a silver bullet either. Neither are flowcharts, process maps, fishbones, trees, etc. But, they are pretty handy nails for non-engineering folks to use to understand the process aspects of their activities. All these things are just tools, and I don't have any favorite tool in my toolbox.

More important than what diagram format we use, I think it is extremely beneficial for folks to define the important criteria of effectiveness for each process, so that they can measure them, and make sure each process interaction optimizes to them.

I don't think the diagram format a client uses is critical. But, I'm disappointed that so few understand this key part of defining what "Good" should look like. I would argue it is far more important than drawing a picture of the sequence (since everyone already knows what the sequence is).

...
Take a look at the file I attached... What is its purpose and where does this document fit into the Quality system? From the "How" Section, I can see that numbered Procedures and Work Instructions still exist. What does this diagram provide that isn't available in those documents and why was it chosen to provide that information?
Thanks to all,
Tym

This diagram is just one way to describe the info. As stated in my other post, the format is not magic, but a decent visual device to expand on the details in this process. I thought it pretty clear. One could put that info into a procedure, but is that format any more or less clear? Less visual, perhaps.

The turtle or individual map just describes each process independently. I agree with Andy and Howste - a turtle has to work under a high-level flow diagram that shows the overall sequence of all the processes.

So, pick the tool that fits each process best. One will be best on a flowchart. One will be best on a router. One may be fine with a turtle or procedure. One may even be best in an interactive DVD. Don't limit your selection of tools. Use the best tool for each process, and be glad you ahve choices.

PS: somewhere on Elsmar, I have posted a "modified" turtle diagram that includes a few extra boxes. You might find that version is more useful than the standard one.