Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #47840

    Mr T

    Help! I’m trying to introduce FMEA (design) in my department.
    Any tips on facilitating the “what can go wrong?” bit in fmea meetings.
    While I understand the process of FMEA ,it’s quite challenging getting people to think of the ways in which something can fail. I often find that people are very good are picking wholes in something once it’s been released/approved.


    Steve Kraus

    I’m no expert, nor am I sure what functional area your ‘department’ is (marketing, IS, etc.).  But, from a systems/process perspective, here are a few things we do…
    The most obvious:  where has the process failed before, and how/why has it failed?  Beyond that, we look for…

    Anywhere there’s a human or system ‘handoff’.  How do you know the ‘handoff’ has quality?  That the work done BEFORE the handoff is done, and done right.  And, that the person/system AFTER the handoff has picked up the process step to do?
    Systems/processes being down.  On the systems side, you simply can’t assume that the human or computer is ‘always up and always available’.  What about vacations, power outages, systems down for backup/maintenance?
    Systems/processes being compromised.  How do you know the customer/company employee/machine ‘knows’ or ‘still knows’ how to do the process step right?  This obviously gets into training, certification, calibration (for machines), etc.  New people/customers/employees in a process are often failure points.



    A great aid to stimulate ideas, or to serve as a checklist of sorts, is the 6 M’s – Man, Method, Machine, Material, Measurement, Mother Nature (Environment).  Nearly all variation can be categorized into these buckets, and virtually all failure modes can be traced back to one of these basic categories.  Depending on your scope, some of these may not be relevant.  Use the ones that make sense.  
    Before you start your FMEA, make sure you have a detailed process map, along with specific requirements for each step.  These are essential elements of the planning that should always be done.  A fishbone diagram and C&E matrix are also extremely helpful planning tools to generate ideas about potential failure modes. 
    Lastly, if your scope is too wide, you may need to break up your FMEA into pieces, each one focusing, for example, on specific aspects of the design.  And ask colleagues or search the internet for examples to share with your team.



    As rightly stated by Risky, you need to have a process map of the process you need to do an FMEA on.  FMEA is nothing but a preventive tool to identify any potential risks in the process. 
    So if you do not have the process map you may not be following the sequence of the flow.
    Also ensure that FMEA is done as a team and not a ONE MAN SHOW.  You need to involve someone from all cadre from the process as everyone would have different view points of the occurrences of the problems if any.  Ideas also will be many for the solutions to be put in place for the high RPNs.


    David Then

    Numero is absolutely correct that DFMEA/ FMEA is not a one man show. Cross-functional team concession is needed. However, in order to cut down the duration or discussion time (to improve efficiency), it is advisable to start populating individual input from the team and  table this for discussion later especially on the  “O”, “S” and “D” ranking and possible resolution.
    Best regards.



    I have been very lucky with FMEAs and the teams I have worked with in the past.  One thing that I have done that has helped me the most is doing a preliminary FMEA before I meet with the team.  However, I don’t ever show it to them.  I do this so that if the conversation during the FMEA dries up, I can throw out some ideas and provide input for the team to consider.  Also, doing a preliminary FMEA helps me to do some indepth thinking about the particular issue that will be discussed.

Viewing 6 posts - 1 through 6 (of 6 total)

The forum ‘General’ is closed to new topics and replies.