How do you avoid common pitfalls and mistakes when performing a process FMEA?

It may sounds trivial, but when the team is performing the brainstorming and analysis, it can be difficult to resist the temptation of trying to "save the world". At the end, the outcome must be the actions to avoid/mitigate the failures. Keeping the scope too broad, will only make the members to lose the focus and not spend the necessary energy on what matters the most.

In a process FMEA, presume the design is correct, and focus on where the process can not make parts to print. I have seen PFMEAs get derailed by blaming everything on design, and we have no process issues. Similarly, I have seen Design FMEA go wrong by blaming manufacturing for not making it to print, and therefore, no design issues. Yes, a shaft size of 25 mm +/- 1 micron may be absurd. Drop a note to the designer, and then have the PFMEA focus on what can go wrong so we don't meet print. Bear in mind a ranking system makes 3 buckets. 1) Stuff we have to fix, 2)Stuff to fix if we have time, and 3)Stuff we won't worry about.

Use a turtle diagram to visualize the process and identify the linkage activities and other components of the process. Generate a process flow chart making sure that all steps involved in the process are identified. Now you are ready to brainstorm possible means of failure. Brainstorm must be done correctly. The facilitator must not pass judgment on any of the suggestions. When all team participants run out of ideas, the group then makes concensus decisions on which failure modes to rate.

Another way to do this is with a decision table. Also called a truth table, it enumerates every possible permutation of the known design inputs that you get from the scope. From there you can determine with a pivot table what is most likely to happen and focus the effort there -- essential for focusing in a small startup environment.

When performing a process FMEA, it is crucial to define the scope properly to avoid common mistakes. Make sure you and your team fully understand what the boundaries of the process being analyzed are. It will ensure process boundaries are identified. The scope must include all phases of the process, from inception to completion, to ensure that no critical aspect is overlooked. It will ensure that all phases of the process are considered. Consider how the process in question interacts with other processes within the system to ensure that all possible interconnections are considered. It will ensure that interactions with other processes are evaluated.

- Um time multifuncional no FMEA é crucial para trazer perspectivas diversas, expertise e insights abrangentes, resultando em análises mais robustas e eficazes para identificar e mitigar potenciais falhas.

Stick to the scoring criteria that is included with the method being used. Do not deviate unless you have data to justify the change in scoring. Your management team and your customer need to be aware of the true risks associated with the process. This also makes process decisions easier to defend should the need arise.

This is where subject matter experts come in handy. An open and honest conversation with them over each point often leads to a more accurate criticality score, whatever formula you are using.

A trained and competent person is rarely the root cause of an issue. People do not fail processes - processes fail people. Root cause analysis needs to dig past the excuses to find the means by which the process did not enable the person to achieve consistent output to the process.

Again, a tool like a decision table comes in handy for this. Especially early on, as you often don't know what you don't know at that point in the process. The decision table often gives you something to start with as it gives you every possible permutation of potential occurrences based on the design inputs.

When looking for solutions always look for 2 things: 1. Is the solution systemic? I.e: the solution should not depend on a single individual or team to deliver but should be defined within a process. For eg: to calculate number of units processed, a bar code scan should be set up rather than an individual counting at the end of a line. 2. Is there a way to collect data as part of validating effectiveness of the solution? If yes, what data is collected and how the data needs to be summarized/analyzed thought of.

A good way to do this is to order it by post control criticality, bubbling the highest ones to the top. That way the top issues are escalated quickly and subsequently addressed.