How to begin tracking FPY (First Pass Yield) and "Downtime" tracking

B

burns290

I am looking for some initial guidance here... I am the (new) QE of an assembly /test area for hydraulic motors. FPY is not currently tracked and I want to begin tracking it....Good ideas on how to start, what has worked not worked for you?

Also - We tend to have an enormous amount of downtime...Like 25%

We currently track this as downtime, even though not all of the recorded notes on the shift report caused a line stoppage. Some were just reductions in efficiency. Before we try to reinvent the wheel, any suggestions?
 

Bev D

Heretical Statistician
Leader
Super Moderator
well, I would begin as simple as possible.
you will need to be very clear on definitions and that there will be no blame assigned. I woudl also use paper - or better yet a giant white board

for FPY you can start by defining any unit that 'loops back' to a previous operation or diverts to a 'rework' operation as failed. Count each unit that moves through an operation the first time. (if you don't have serial number control you can use toe tags, collored dots, etc. to mark the part as failing; or your standard non confomring material marking) FPY = failed units / first time proceesed units at each opeartion. RTY = FPY1*FPY2...the advanced - and more accurate - method is to define any rework as a failed unit. even when the reowrk is done at teh bench where it was detected and no loop back or diversion takes place.

You should also impress upon the operators that the failure is to be recorded not the 'guess' at the cause. I certainly would avoid over aggregated buckets of 'cause' such as operator error, supplier problem, process problem or equipment malfunction. This bucketing makes true improvement nigh onto impossible because it is often wrong and lacks sufficient detail to be actionable. The recorder of the occurence of the event rarely investigates or knows the true cause. This can be added later after the investigation and validation of cause...if the recorder actually knows the cause it would beg the question: why haven't we fixed if we know what it is?

For downtime the same principles apply. Only you can add greater detail in the definitions regarding type of downtime. Since the main focus of downtime tracking is to drive improvements such that the equipment is always available and funcitoning properly to produce product that meets requirements your definitions are critical. the critical element is that an equipment malfunction that doesn't directly stop production becuase of timing or a work around should still be recorded as downtime because it is only luck or serendipity or extra capacity that avoided the production stoppage.

Again no 'causes' that is for investigation to determine.
 
I

iamtroll

I agree with Bev, start simple, post it where everyone can see it, be flexible at the beginning so you can make adjustments to the input info and of course no blame game. Here is a quick spreadsheet that I like to use at startup to make sure that I get the "Other" column in control quickly in case I missed some significant defects.
 

Attachments

  • First Pass Yield.xlsx
    213 KB · Views: 857
Top Bottom