iSixSigma

Service FMEA

Six Sigma – iSixSigma Forums Old Forums General Service FMEA

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #35125

    Zoltan Varadi
    Member

    Dear Experts,
    There is a GB project focusing on a service issue: they targeted to improve operational availability of an SMT line, and it seems the biggest problem is the length of time spent on recovering machines when they broke down. The process in question is obviously the service: recovering the broken machine. They are doing it for certification (I am supposed to coach them), so they have to demonstrate all important tools, including FMEA.
    Of course we know what a process FMEA is, and have done it a few times, but we have no experiences with such service processes. It would be great if you could share experiences, tricks, and main concerns of a service FMEA.
    Thanks in advance.

    0
    #97803

    Mikel
    Member

    Zoltan,
    A process is a process is a process. FMEA is based on a process map of the process being studied. I assume you have an accurate one of the service process. From there it is simple (but tedious). Go through the process map one step at a time and document all of the things we know go wrong, their impact on all downstream customers when they happen (severity), how often they happen (occurance), and how do you know they happen (detection). I would suggest to you that line down > change over time is a high severity, occurances of greater than one per month is a high occurance, and detection that the machine stops is the very highest detection number.
    I have done this project at least 10 times on a SMT line. TPM is probably a more logical tool set to start with instead of Six Sigma, because the ways to get occurance to go down and detection to go up are embedded in TPM.

    0
    #97808

    Laszlo Buda
    Participant

    Szia Zoltan!
    I am pleased to see another Hungarian among the ranks of Six Sigma professionals.  I am always looking to expand my network of Hungarian contacts beyond Cleveland for both professional and “magyar hálozat” purposes.  If you would like to swap stories, please contact me directly at [email protected]

    0
    #97818

    Matthew
    Participant

    Products and services are similar in many respects.  I agree with you that the FMEA is an excellent tool to help identify and mitigate the risks.  As far as a Process FMEA is concerned, I support Stan, a process is a process is a process.  The Design FMEA, I think, may be a useful addition to your service process creation process.
    Looking at the headings of a DFMEA, try to interpret these as the relate to a service (as opposed to a product), and develop a testing plan that allows you to assess the effectiveness of your service at meeting customer requirements.
    Function:  What need of the customer does this service meet?  Try to be quantitative with this if possible. (e.g. answer complaint calls within 5 rings)
    Failure Mode: In what ways can the function not be met? If you are able to define the function quantitatively this becomes simple. (e.g. unable to answer complaint call with 5 rings, or unable to answer complaint call with X rings (where X is some critical customer disatisfier with unique effects).
    Effects: What is the effect of EACH of the failure modes and its relative severity (You will have to define a severity ranking system for your services – but apply it consistently, or the RPN values will be lost). (e.g. Loss of Customer, or Customer Disatisfied – Actively communicates disatisfaction to others…)
    Causes: What is the cause for the Failure Mode (not the effect, but you knew this)?  What part of the design of your service will allow you not to acheive the requirements of the Function.  (e.g. insufficient line coverage during peak call periods) Occurence should be based on an internal sampling of data for the failure rate by EACH cause of the service process to meet desired results.
    Controls: What measures, systems, processes, procedures, standards will be made to define the service to acheive standardized work and develop repeatability (so you can effectively run Six Sigma projects around the data later on – we are human (or at least I am) and the process will have errors in it…) Detection becomes how well your process actually achieves customer requirements based on external data (from customers and again segmented by CAUSE).
    Base Service SS projects around the RPN, and keep the FMEA visible at all levels, don’t allow it to stagnate or it will be lost.
    Matthew Smith.
     

    0
Viewing 4 posts - 1 through 4 (of 4 total)

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