iSixSigma

FPY – First Pass Yield – What's the Right Way?

Six Sigma – iSixSigma › Forums › General Forums › General › FPY – First Pass Yield – What's the Right Way?

This topic contains 6 replies, has 5 voices, and was last updated by  Martin K. Hutchison 7 months, 3 weeks ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • June 29, 2018 at 6:20 am #56040

    Steve
    Participant

    I understand the calculation for FPY

    # of defective units/# of units

    So for example I have 3 quality gates:

    300 – Floating Quality Gate
    350 – Quality Gate After Test
    400 – Pre-Delivery Inspection

    My question would be…. is my FPY calculation based on # of units produced in that day… overall. OR, # of units that went through “300 Floating Quality Gate” divided by the number of defective units coming out of that Quality Gate?

    300 – 5 units – 4 units checked as good, 1 unit bad = FPY 80%
    350 – 10 units – 6 units checked as good, 4 units bad = FPY 60%
    400 – 10 units – 9 units checked as good, 1 unit bad = FPY 90%

    because we are calculating our FPY based on the number of units produced for the day throughout the facility, and this seems very wrong.

    However, I run into the notion… we use total # of units produced throughout the facility so our overall FPY is accurate in the historical data… so looking back at 2017, our FPY reflects correctly. But if that’s true, then isn’t our daily FPY for these quality gates off?

    RTY is easy, 300 FPY*350 FPY*400 FPY = RTY

    But the way we are calculating our FPY is throwing me for a loop. Can someone easily sort this out for me. The absolute correct way of determining FPY. And is there actually a different calculation for historical FPY vs Daily FPY?

    Thanks

    0
    June 29, 2018 at 7:24 pm #202761

    Strayer
    Participant

    FPY applies to a single step in the process or to the final output without regard to what happened before. The way you’re calculating it conflates FPY with RTY, It’s wrong and misleading. Regarding your final question, the only difference between historical and daily FPY is the time span for the data points.

    0
    July 2, 2018 at 7:26 am #202775

    Wäsbom
    Participant

    Our production consists of about 20 different test stations and we use two different kind of yield.
    Total yield:
    How many units passing all test stations without any remark, (1-Fail/Total).
    Only looking at units ready for stock and whatever period you want.
    All failed units are fixed and NOT scraped.

    Station yield:
    To analyze poor Total yield we look at yield per station to see where to focus for best impact.
    Don’t actually know what to call these type of yield calculations but it works for us.

    0
    July 2, 2018 at 7:45 am #202777

    Mike Carnell
    Participant

    @Diego What does that mean “It works for us.”

    0
    July 2, 2018 at 9:38 am #202783

    Martin K. Hutchison
    Participant

    “Works for us” is one of the top justifications that I have heard for ineffective practices that I have heard.

    If you think of SS in terms of “opportunities to make a mistake” and its iterations, you could run 10 parts through 3 tollgates and measure units into the tollgate vs. bad units, and thus each tollgate has a FPY. You could then sum the “opportunities” and the failures to then get system FPY- the 10 parts would generate 30 opportunities etc. But that might be a number that only impresses the suits- it isn’t tactical enough to be practical, unless you use it to see if improvements for one tollgate are hurting the KQC that you measure in another, but you could see that from that tollgate

    0
    July 2, 2018 at 11:24 pm #202788

    Wäsbom
    Participant

    It only means that as long as you know exactly what you are measuring it doesn’t matter what you call it. System FPY is what we report to the managers.
    SecondPY, ThirdPY, Defects Per Unit along with Station yield is what use for analyzing improvement opportunities.
    My way of thinking might be affected by the fact that we are not a SS company in my eyes.
    An effort was made to implement SS but unfortunately a perfect example of how you shouldn’t do. We have no MBB or BB to pull the strings so “Ineffective practice” can be the consequence of that.

    0
    July 3, 2018 at 7:09 am #202789

    Martin K. Hutchison
    Participant

    I don’t think the key is being a SS company, but in being a Continuous Improvement company. SS is a tool for continuous improvement. When functional managers are themselves always improving and encourage their people to work cross-functionally on their priorities and also on other functions priorities, then you can pull out the bag of Lean/SS/TOC tricks as needed.

    0
  • Author
    Posts
Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.