Implementing the Process Based Approach - Reality check needed

[howste]

Re: Implementing the process-based approach. Reality check needed.

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! 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 , 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?

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

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

 

[AndyN]

Re: Implementing the process-based approach. Reality check needed.

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

Andy

 

[howste]

Re: Implementing the process-based approach. Reality check needed.

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.

 

[Jen Kirley]

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.

 

[Helmut Jilling]

Re: Implementing the process-based approach. Reality check needed.

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

 

[Helmut Jilling]

Re: Implementing the process-based approach. Reality check needed.

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