I’m trying to track employee efficiency with MES. For most of our operations, we have a production standard and it is pretty simple to track efficiency. When an employee reports quantity, their labor hrs are compared to their earned hours (prod std * qty).
But for some operations, we only have a setup standard time and we set the labor entry to Time Only - Backflush Qty. For these operations, how are hours earned?
The below image is a screenshot of labor transactions from a particular operation with a setup standard with a labor entry of time only. It shows that 2 employee’s labor transactions earn hours, but Backflush’s labor transaction also earns hours. They sum up to 0.37 hours (which is the setup standard of the part).
If that was the case, then the employee’s efficiencies would be 100% which they are not all that unfortunately.
Epicor’s field help says this regarding Earned Hours. For setup when not complete, “earned hours = EstSetHours x SetupPctComplete or ActSetupHours, whichever is less”. When setup is complete, “Earned Hrs = EstSetHours - ActSetHours + SetReworkHours - Burden Hours for this labor detail record.”
This seems to be happening for some of the labor transactions. The operation is not marked complete so as the description says, Earned Hours = ActSetupHours. Since the labor time was 0.02 hours, the labor transaction reports 0.02 earned hours. This also happens for a labor transaction of 0.03 hours. Then, quantity is reported via Backflush from the subsequent operation. This initial backflush labor entry captures the remaining earned hours as defined above ("When setup is complete, "Earned Hrs = EstSetHours - ActSetHours).
All labor transactions (including backflush) that happen after this point on for this specific operation do not earn any hours. This is where the problem lies and it’s probably a result of how we have it set up right now and I’m not sure about the solution. For the purpose of capturing employee efficiency, I don’t want Backflush to earn any hours.
We blended setup into the production time as the job was made so we did not clock time on setup, only on production, so my results were simpler to control. The process we used was setup in 2012 and we stopped backflushing last year and now capture every start stop.
If you don’t want backflush operations to earn hours then you can remove the estimated hours.
Yeah we don’t want certain operations to have production times because they are steps of the process that are independent of Job Qty (which also is variable). Thus, we don’t want a certain prod std multiplied out by the job qty because this would create fluctuating and ultimately inaccurate estimated labor for these operations.
To your second point about removing estimated hours, I think that would remove cost from the part/job which I don’t want to lose. Right? Maybe there’s a way to do this without losing cost.
Have you looked at Fixed Hours instead of Minutes per piece for those quantity independent operations?
Yes you would have to move the hours to another operation if you wanted to keep the estimate. We did this to create what operations called EZ jobs under 10 pieces and 10 minutes. I moved all of the operation time to a single final operation and set the operations to backflush.
Cost would come from the actual time spent regardless of estimate.
Greg, thanks for the suggestion. I haven’t found a clear definition of Fixed Hours but as the name suggests, I’m assuming that this is a UOM that is fixed, being independent of the quantity of the job (similar to how a setup time is).
I’ve just tried to test a job out switching 0.5 hours from setup time to 0.5 Fixed Hours in an operation.
The operation before and after it both have Time - Backflush Qty labor entry. When I reported the full qty for Op 50 via MES and backflushed labor, the two other Time - Backflush Qty operations displayed backflush labor transactions and the operations were completed, but the operation with Fixed Hours was not. Any idea how this happened or a solution?
I did find one attribute that looked different than the other operations so maybe this is a factor in no quantity being backflushed for this operation. The operation had “RequestMove” checked. I unchecked the box and tried backflushing labor again but nothing changed.
I don’t have any idea how request move would effect the backflush. You could try processing the material queue record to see if the backflush would then process. I don’t think you can change it later and get a do over backflush.
From Understanding Earned Hours KB0113497. I assume the EstSetHour is really EstProdHours since it starts with If the Production Standard is Fixed.
I would throw two more operations on the bottom of the job making sure request move is not checked and do a start and end activity again for a quantity of 1 just to see if it will move. Is there any useful info in the backflush log?
For Production:
If the Run quantity > 0: EarnedHrs = EstProdHours / RunQty x LaborQty If the Production Standard is fixed hours: EarnedHrs <= EstSetHours – ActSetHours + SetReworkHours – Burden Hours for this labor detail record If the operation quantity = 1: EarnedHrs = Operation Hrs Remaining (EstProdHours - ActProdHours) or Hours Worked (BurdenHrs), whichever is less
