Turtle maps and Flowcharts - How is everyone approaching Turtle maps and flowcharts?

  • Thread starter Thread starter ISOPete
  • Start date Start date
I

ISOPete

Wanted to get an idea on how everyone ia approaching this. The great debate as we know it is do we need process maps. :frust: In some other threads I notice people are using turtle diagrams. Here where I work we are using Flowcharts with our input/output/owner/measurements listed on the chart.
What has everyone done to meet this requirement. the input is greatly appreciated. :agree1:
 
Elsmar Forum Sponsor
As is my usual pattern, I have been monitoring these discussion threads and thinking in a different way. ISOPete's original question was

The great debate as we know it is do we need process maps?

The requirement for and the creation of turtles and other diagrams have been discussed in the threads noted by Marc. Most participants have provided examples of how to do the diagrams. My thought process has been what is the purpose of the diagram? If the only reason is that it is perceived to be (or actually) mandated by the TS16949 standard that does not mean that it provides value to your organization.

I know that process diagrams can be useful and I am not arguing that they are wasteful. But sometimes we spend a lot of time on the style and format of the drawings and it is not adding anything to improving the process.

Just my thoughts.

Bill Pflanz
 
The only requirement by the specification is that the organization identify its processes, their application, and linkages. How we do that is up to us. The process charts as described could work very well. It is my intent to develop a modified turtle diagram that's a little easier to follow.

I just went through the Lead Auditor training last week at AIAG and they hammered on the Turtle Diagrams pretty hard. We spent the better part of two long days learning the principles and practicing turtles through detailed exercises. The turtle exercise was also a pretty significant part of the test on the last day.

This is the way the IATF is requiring that 3rd party auditors be trained so it makes sense to me to follow somewhat of a turtle diagram plan in defining processes in order to expedite the audit process.

One of the instructors said that a well annotated flow chart would work just fine.
 
TWallace said:
This is the way the IATF is requiring that 3rd party auditors be trained so it makes sense to me to follow somewhat of a turtle diagram plan in defining processes in order to expedite the audit process.

One of the instructors said that a well annotated flow chart would work just fine.

Are you saying that the only reason for doing turtle diagrams is to make life easier for an auditor?

Bill Pflanz
 
Bill Pflanz said:
Are you saying that the only reason for doing turtle diagrams is to make life easier for an auditor?

Bill Pflanz
Not at all, you have to document your processes anyway. Why not use this method to have a continuity in internal and 3rd party audits.

The automotive industry is mandating that if you wish to do business with them, you will perform process audits. While I personally believe that you can conduct effective and efficient elemental audits, the automotive process audit models do have positive characteristics that can be beneficial. Initially, the process audits forces those of us who have done mostly elemental audits to look at our businesses from a little different perspective.

It has been my experience that if you and your 3rd party auditor are both speaking the same language (automotive process models or turtles) it makes the life of the management rep a bit easier come surveillance audit time.
 
TWallace said:
This is the way the IATF is requiring that 3rd party auditors be trained so it makes sense to me to follow somewhat of a turtle diagram plan in defining processes in order to expedite the audit process.

TWallace,
The operative word here is "plan"...organizations should use the turtle diagram to PLAN how your process will be layed out. The problem is, many companies, misguided by their Certification Bodies, AND AIAG training, for that matter, have generated almost useless, cryptic models, that no one can possibly follow to implement a process. The process model should be a self-explanatory model, which, in the absence of the document champion, should be implementable and auditable by company employees at large.

I have seen processes defined by a single "Macro turtle" which does not constitute a process. In fact if we must use this "misleading" turtle analogy, it's really a convoy of turtles...that is, several linked activites, each with individual inputs, outputs, responsibilities...etc and finally, not fixed but potentially changing associated metrics or measurables, which must be assessed and reviewed for continued suitability at regular intervals.

I'm digressing from the original topic, but...to finish my thought... once processes are capable and stable, you can discontinue monitoring, or change the measurable which you are monitoring. For this reason, I don't include the metrics in my "process flows", or as part of the "turtle". They're managed through a "Metrics Dashboard" database (copyrighted P. Ravanello) which is Management's repository and access portal to all "performance gauges" in the company. Because they are subject to change, I don't want to include them in my Process Flow Charts, which would require that they be subject to potential frequent revision. I just reference the "Metrics Dashboard" in my Flow Charts.

AIAG needs to re-think their training...and upgrade it to include some "best-in-practice" models which they should solicit from the Certification bodies (with the approval of the authors, of course).

Patricia Ravanello
 
Last edited by a moderator:
ISOPete said:
Wanted to get an idea on how everyone ia approaching this. The great debate as we know it is do we need process maps. :frust: In some other threads I notice people are using turtle diagrams. Here where I work we are using Flowcharts with our input/output/owner/measurements listed on the chart.
What has everyone done to meet this requirement. the input is greatly appreciated. :agree1:


1- "The great debate as we know it is do we need process maps."
Process maps in the form of blocks, triangles and circles; NO. The only requirement is to identify your process. IMO the process identification tool that has been overlooked is the control plan. If you were QS prior to your TS2 certification it is most likely that the control plan already identified your processes, and even linked them together.

2- "I notice people are using turtle diagrams."
Turtle diagrams are not a TS2 requirement, BUT, they make it very easy to initially plan and determine the needs of a process. As you may have learned in your AIAG audit class, P. Crosby develped this diagram in the 70's.

3- "What has everyone done to meet this requirement."
Owners of the process used the "turtle" to identify the needs of the their process. Our quality management team voted to use the Visio flowchart package to formally document the process.
 
Process Auditing: A Change in How Auditors Work

This article just appeared in "Inside Quality" this week - Process Auditing: A Change in How Auditors Work

sorry I can't post a direct link, but I may be able to e-mail the article if anyone has difficulty in finding it in the mag. :)
 
Last edited by a moderator:
Key Processes Map - the Big Picture

Sam said:
1- " If you were QS prior to your TS2 certification it is most likely that the control plan already identified your processes, and even linked them together.

The Control Plan only covers the processes of Production (not even all of Product Realization and/or the APAP Processes).

ISO/TS 16949 requires that you define ALL your processes, they aren't just referring to Product Realization...they're including all the customer-, management-, support- and operating system-oriented processes (System-oriented processes is a classification they didn't identify, but is a necessary classification).

Your Key Processes Map should include and link all you key OPERATING processes, not just those of Product Realization.

You have to step back and look at the BIG PICTURE of your Management Operating System.

Patricia
 
Back
Top Bottom