The Quality Blog

Just a quick not to share some recent experience. I was at several clients over the last two months, each with an identical issue. These clients are in different industries, aerospace, automotive, and pharmaceuticals. The issue was legacy, or lack thereof. Each company has been wildly successful over the years, (two are over 100 years old) but when it came to Product Development, a great deal of waste was present due to relearning that which has already been learned. This is partly their customer’s fault, by not accepting years of data on identical product, but nonetheless, testing and making prototypes to test at reliability and confidence levels requiring 6 or more samples, is very expensive and time consuming.

My recommendation to them was to develop a legacy based product development system. This means that all that we already know is easily retrievable and used to reduce overall time in PD. The risk is low and the confidence in these designs must be high with a good deal of history. It may be that the concept of confidence is misunderstood. The more I see, experience, etc… the more confident I am. Statistical confidence without engineering judgment and legacy will drive unnecessary testing and longer PD to market.

I would first explain that if I had a design or process which was potentially catastrophic (sev 9 or 10) I would attempt to error proof the Failure Mode (if cost permits) then I would explain criticality (combo of Sev and Occurrence) where I could draw a picture of why reducing Occurrence was my primary course of action, where I could either error proof the cause or improve the process capability of the machinery/tooling (or improve tolerance if the design was not fully completed yet)  and then finally, I would look at detection for items at risk based on the first two. Actions are determined at each step, Three times in the development process I can take an action. Once actions have been recorded I calculate RPN, assign RPN to each action and re-rank the RPN after the verification or validation of the effectiveness of the action. (wheeew that is a lot of words)

Much has been said about outsourcing, some good and some bad. What cannot be debated is that outsourcing is here to stay and it is a cost effective way to manage an important part of your business. Outsourcing your supplier process is one of the areas which can be quite effective (cost and performance) if done professionally. Let me explain.

Supply Chain Management is not just about ranking a suppliers ability to meet IOS or TS requirements. It encompasses a relationships, sourcing decisions, engagement levels, quality of systems as well as performance and future development to attain even higher levels of performance. These elements must all be included in a supply chain management strategy. If not, a significant amount of inefficiency can take place.

It has been estimated by industry insiders that a full 33% or 1/3 of the energy spent on suppliers is redundant or could be done in a more integrated way. While it is agreed universally that supplier engagement in product development activities almost always returns a benefit in simplicity of designs with lower costs/price. Engageing too late when suggestions for design for assembly or manufaturing cannot make it into the design, is a common sentiment.

Supply Chain management is often left up to different departments with little or no coordination and results linked not to a process but to individual SQA/STA (supplier developmemt engineers) experience.

Outsourcing the complete Supply Chain Management function provides several benefits:

1. One focused organization looks at sourcing, engagement, collboration, performance and development instead of possible different departments.
2. Integration reduces amount of time per supplier and emphasis is placed on high value products and processes
3. Cost can be shared across many OEM’s where generic data, and development activities would benefit many customers instead of individual customers
4. Suppliers can share in the expense of being managed

In summary, I do not mean to say that all organizations do not practice effective Supply Chain Management, I am suggesting that expertise exists, that could do an equally effective job (or better) and do it at a cost that is competitive or below what internal resources are doing it for today.

Does anyone have a comment or question?

http://www.quality-one.com/services/supply-chain-management.php

What is Failure Mode Avoidance? FMA is the effort taken to organize and report the failure history to be used at the very beginning of a new product or process development. The non inclusive list of sources of the Failures are as follows:

• Warranty
• Campaigns (recalls)
• DV Test failures
• Continuous Improvement Activities/Six Sigma DMAIC
• Production Line Failures
• Customer/Assembly Failures

These are summarized and actions are required at Design reviews to show haw the item was either

• Error Proofed (designed out)
• Made more capable (Cpk 1.67 or greater for high volume production)
• Mistake Proofed or Controlled

The value of FMA (or FPA Failure Prevention Analysis) is mostly avoiding current problems from happening again, and lost time in design if the item requires revisiting. For many companies 30% of all failures are repeats.

What have we learned and how to avoid it must be an integral part of the Product Development process and Lean PD.

I have not written in awhile but wanted to write about the matrix approach to process FMEA. I have proven at several customers that over 80% of all PFMEA activity has negative value. This assumes of course that the user has done FMEA’s on their processes in the past.

Efficiency can be improved by over 70 % by corelating causal items with verbs for assembly. For example: Fasten, or Secure can have as many as 30 plus causes of failure, but they are usually consistant. That means that each time I fasten or secure, the reasons why I might fail to do it properly are known and used over and over again. Based on this the FMEA practioner may only choose to use causes that make sense for the specific application and not re- brainstorm (is that a word)  all of them (recording them on the form). This has no value as a team sees that the causes repeat many times even though probability (occurrence) is low. By doing the corelation and preparing the fmea FROM THE KNOWNS  the team can quickly focus on the new, changed, past failures and environments.

Are FMEA’s actually proprietary. I have been hearing this over and over again far too many times. The purpose of the FMEA is to collaborate on risks, not hide behind the proprietary statement. It is common if you do not want someone to see what is on the FMEA, that we call it proprietary. I would ask a simple question, is it really or are you bad at creating them. I think it is an excuse not to show how poor they are performed….

An excellent comment on the blog made me think of an underpass on a Detroit highway. Driving down the road I found that  road was flooded. Being the weird individual that I am and having read a comment about the discussion being the most important thing in an FMEA, I logically saw an analogy of the flood to the FMEA process.

Water will flow unobstructed based on Gravity. Water will flow out in quite a few directions simultaneously. As the water spreads it covers a lot of area. Teams work in the same way. All kinds of info and discussions can take place spreading out, thinking of every possible thing that can go wrong.

That is the problem, all the discussion is like water spreading out in all directions. We are not getting it where we need it. FMEA is like plumbing. FMEA channels the water like in irrigation to the crops that need it most, It is like plumbing in that there may be differing directions that I want the water to flow, not everywhere. Too many times teams sit down with a blank form and go for it and end in despair due to hour long discussions only to end with, but that wont  happen because we did this thing or followed this practice. How frustrating. FMEA is very effective, but the planning for the experience is every bit as important as its’ outcome.

I am at Ford Today, working on all the assembly plant operations for three new or significantly changed product lines. Ford has always been in the forefront of FMEA use and it is still true today. The techniques we are using here would not necessarily be recognized by the vast majority of FMEA users out there. In fact, the fmea’s being developed for complete assembly plants are quite manageable in size, not what you would expect from past line by line development activity. Why?????

We have leaned out the FMEA process by seperating the knowns as legacy and focus only on the change bothe incidental and intentional. For those of you in the know Incidental and Intentional Change are the primary things that Toyota looks as as well in DRBFM (Design Review Based on Failure Modes).

By seperating what is known and turned into standard work, The Lean FMEA technique only looks at the:

• New Operations
• Changes to Operations
• Past Failures
• Incidental change due to Noise Factors like environment or operator preferences.

Process assesmbly FMEA is now quick and quite effective as the ratio of actions to line items is much greater. This is due to more emphasis, focus and attention applied to the subset of what is probable (changes) and discounting the possibles where no change is likely to drive failure where it did not exist before.

In the future Ford will probably adopt Lean FMEA for all assembly in Vehicle Operations, and we will be there to continue the relentless never ending task of making FMEA and other quality tools more efficient and effective.

In order to achieve higher velocity in product development, it is important that the process be dynamic. Since success is the anti function to failure, failure should be an integral part of Lean PD. More importantly the finding of potential failure and the counter measures taken to eliminate it either by error proofing, or collaborative design measured by process capability. (Cpk)