The backflushing of labor is triggerred when the NEXT sequenced labor OP is reported complete. The Backflush labor process must specifically be launched & running. (It is not like material backflushing the at is always running as a core process).
Â
Because the backflush OP is not triggererd to backflush until the next sequenced OP is reported complete, there is an inherent delay in actual (physical) processing of the work at that OP and when your systemic view of its status is updated to refelct (what should be) reality (other than the fact that you are backflushing standard time & accumulating labor cost based on cycle time of OP and prodqty of OP).
Â
If your OPs beng considered for this (including the NEXT OP that will trigger the backflush) are of appreciable total time, this delay may not be acceptable.
Â
If you are reschedule (via Global) nightly, until the OP backflushes, its load will continue to be scheduled (even though perhaps physically completed). Even if you don't nightly reschedule, the fact that load is not relieved can impact your (manual) scheduling process of new jobs.
Â
As it sounds like the goal here is to simplify labor reporting (and accum time/cost of the OP std's instead of actuals incurred), Qty reporting might be a sutiable compromise. A single Report Qty entry through MES will give more 'real time' status information but doesn't require the Start Activity/End activity 2 entry reporting.
Â
We massively utilize backflush labor in one area of our business where a single unit (that may have 3- 10 OPs in the job details because of our highly structured multi-level phantom BOMs and SubAssemvly structures) only actually take 3-7 minutes to produce 1 pc (so backflushing gives real time enough status, & we don't burden employees with excessive labor entry, that even bar code enabled, would otherswise be an excessive percentage of the time required to build 1 unti of the product.
Â
These jobs only have one labor reporting OP (and we set them as QTY reporting so a single bar code enabled report qty entry takes care of the entire job - also triggering backflush of most fo the material as we utilize material backflushing heavily in this area as well).
Â
In our machine shop (which supplies parts to this assembly area like vendors do), the operations are much longer and the methods much more complex. (This area is also finite scheduled and rescheduled with nightly global reschedule - so relieving load as it actually occurs is important).
Â
Complex CNC OPs (that tend to be the longest running OPs in these jobs & ones we wish to compare actual (start/end) times to std times, are Time & QTy reporting type. Less complex (but more numerous) secondary OPs (relatively quick drilling, pressing, stamping, deburring, painting or washing operations) are not (as) critical to attempt to measure actuals versus standards (as it would also force excessive reporting versus the work actually being done & unless done extremely dilegently in very real time, the variances would be less likely to be a result of 'bad' standards, slow (or faster than norm) individuals, or quality issues incurred that slow the process & just as likely nto exact real time start/ends - so for these we just specify Qty reporting.
Â
Consider your environment and what you gain versus lose between the extremes of Time & Qty versus Backflushing of labor (and consider Qty reporting as a middle ground if applicable).
Â
I DO suggest that (as a company) you honestly consider if the decision is being driven (in any way) by resistance from shop workers to DO the reporting (for fear of being personally measured, or 'because things were just fine before and we never had to do this', etc., - AND/OR if the direct supervisors/manager(s) in these areas being considered for backflushing simply don't want to fight the battle (and it can be a battle) of setting expectations that labor be reported accurately/timely & sustain the effort to make it 'normal'.
Â
Often it is portrayed as a 'pick your battles' issue if you are newly implemented - but I can tell you: Once you relent (and delay insisting on accurate/timely labor entry), reasons not to tackle te issue will be forever rising & because it was delayed once, it will be taken less seriously each time it is delayed. (Credibility on portrayed importance of doing it is blown & the battle will be many fld times more difficult as time oges on and it doesn't happen.)
Â
With touch screens/bar coding, it is just not that big a deal to do labor reporting. (They doth protest much to much when the reality of it is truly looked at!)
Â
In general it is resisted because people just don't like to feel like they are being personally 'micro measured' - and even if you make the effort to not delay & have people do it correctly from day one, therer will be those who 'test' the company (or manager's) resolve by making sloppy entries - or outright skipping it (testing to see if it is noticed and if anyone comes back to them about it & shows continued resolve to have it done right).
Â
This is an ERP system (which unlike old MRP II) dollarizes things ('things' being enterprise resources: people, inventory, equipment, capacity value, output absorbed costs, etc.,) so measures are in dollars (and business decisions are based on performance values that have been dollarized).
Â
While Labor is no longer typically the largest cost component as it once was in manufacturing (as outsourcing has driven up material cost percentages, related supply chain management/planning costs, and technology (which has a cost by itself) makes direct labor much more productive than it once was. even benefit costs arerivlaing direct payroll for hourly workers these days in moreand more companies) - it is that very increase in the productivity of workers that makes measurement of output so important.
Â
Small lapses in expected output can translate to big delayed product shipment dollars & measurement can reveal weak individuals (dragging down the production team), weak processes, opportunities to improve supporting technologies and equipment, quality problems, etc.,.
Â
...All revealed through accurate & timely labor reporting (so make sure you are not handicapping the return on investment in your ERP system by not insistenting upon appropriate activity reporting & sustaining it).
Â
That said, classic ERP can be heavy handed and often becomes an end unto itself that Lean efforts (kanban, strong processes, trained and well managed workforce) can outperform without all the ERP overhead and cost.
Â
Find the balance point (and accept that the point will move as you continually improve and change how you leverage the tools you have).
Â
Rob Brown
Versa Products
Â
Because the backflush OP is not triggererd to backflush until the next sequenced OP is reported complete, there is an inherent delay in actual (physical) processing of the work at that OP and when your systemic view of its status is updated to refelct (what should be) reality (other than the fact that you are backflushing standard time & accumulating labor cost based on cycle time of OP and prodqty of OP).
Â
If your OPs beng considered for this (including the NEXT OP that will trigger the backflush) are of appreciable total time, this delay may not be acceptable.
Â
If you are reschedule (via Global) nightly, until the OP backflushes, its load will continue to be scheduled (even though perhaps physically completed). Even if you don't nightly reschedule, the fact that load is not relieved can impact your (manual) scheduling process of new jobs.
Â
As it sounds like the goal here is to simplify labor reporting (and accum time/cost of the OP std's instead of actuals incurred), Qty reporting might be a sutiable compromise. A single Report Qty entry through MES will give more 'real time' status information but doesn't require the Start Activity/End activity 2 entry reporting.
Â
We massively utilize backflush labor in one area of our business where a single unit (that may have 3- 10 OPs in the job details because of our highly structured multi-level phantom BOMs and SubAssemvly structures) only actually take 3-7 minutes to produce 1 pc (so backflushing gives real time enough status, & we don't burden employees with excessive labor entry, that even bar code enabled, would otherswise be an excessive percentage of the time required to build 1 unti of the product.
Â
These jobs only have one labor reporting OP (and we set them as QTY reporting so a single bar code enabled report qty entry takes care of the entire job - also triggering backflush of most fo the material as we utilize material backflushing heavily in this area as well).
Â
In our machine shop (which supplies parts to this assembly area like vendors do), the operations are much longer and the methods much more complex. (This area is also finite scheduled and rescheduled with nightly global reschedule - so relieving load as it actually occurs is important).
Â
Complex CNC OPs (that tend to be the longest running OPs in these jobs & ones we wish to compare actual (start/end) times to std times, are Time & QTy reporting type. Less complex (but more numerous) secondary OPs (relatively quick drilling, pressing, stamping, deburring, painting or washing operations) are not (as) critical to attempt to measure actuals versus standards (as it would also force excessive reporting versus the work actually being done & unless done extremely dilegently in very real time, the variances would be less likely to be a result of 'bad' standards, slow (or faster than norm) individuals, or quality issues incurred that slow the process & just as likely nto exact real time start/ends - so for these we just specify Qty reporting.
Â
Consider your environment and what you gain versus lose between the extremes of Time & Qty versus Backflushing of labor (and consider Qty reporting as a middle ground if applicable).
Â
I DO suggest that (as a company) you honestly consider if the decision is being driven (in any way) by resistance from shop workers to DO the reporting (for fear of being personally measured, or 'because things were just fine before and we never had to do this', etc., - AND/OR if the direct supervisors/manager(s) in these areas being considered for backflushing simply don't want to fight the battle (and it can be a battle) of setting expectations that labor be reported accurately/timely & sustain the effort to make it 'normal'.
Â
Often it is portrayed as a 'pick your battles' issue if you are newly implemented - but I can tell you: Once you relent (and delay insisting on accurate/timely labor entry), reasons not to tackle te issue will be forever rising & because it was delayed once, it will be taken less seriously each time it is delayed. (Credibility on portrayed importance of doing it is blown & the battle will be many fld times more difficult as time oges on and it doesn't happen.)
Â
With touch screens/bar coding, it is just not that big a deal to do labor reporting. (They doth protest much to much when the reality of it is truly looked at!)
Â
In general it is resisted because people just don't like to feel like they are being personally 'micro measured' - and even if you make the effort to not delay & have people do it correctly from day one, therer will be those who 'test' the company (or manager's) resolve by making sloppy entries - or outright skipping it (testing to see if it is noticed and if anyone comes back to them about it & shows continued resolve to have it done right).
Â
This is an ERP system (which unlike old MRP II) dollarizes things ('things' being enterprise resources: people, inventory, equipment, capacity value, output absorbed costs, etc.,) so measures are in dollars (and business decisions are based on performance values that have been dollarized).
Â
While Labor is no longer typically the largest cost component as it once was in manufacturing (as outsourcing has driven up material cost percentages, related supply chain management/planning costs, and technology (which has a cost by itself) makes direct labor much more productive than it once was. even benefit costs arerivlaing direct payroll for hourly workers these days in moreand more companies) - it is that very increase in the productivity of workers that makes measurement of output so important.
Â
Small lapses in expected output can translate to big delayed product shipment dollars & measurement can reveal weak individuals (dragging down the production team), weak processes, opportunities to improve supporting technologies and equipment, quality problems, etc.,.
Â
...All revealed through accurate & timely labor reporting (so make sure you are not handicapping the return on investment in your ERP system by not insistenting upon appropriate activity reporting & sustaining it).
Â
That said, classic ERP can be heavy handed and often becomes an end unto itself that Lean efforts (kanban, strong processes, trained and well managed workforce) can outperform without all the ERP overhead and cost.
Â
Find the balance point (and accept that the point will move as you continually improve and change how you leverage the tools you have).
Â
Rob Brown
Versa Products
>________________________________[Non-text portions of this message have been removed]
>From: jeppersn <jepperson@...>
>To: vantage@yahoogroups.com
>Sent: Thursday, May 30, 2013 9:29 AM
>Subject: [Vantage] [Vantage 3.03.409c] Backflushing labor
>
>Â
>I am trying to figure out how backflushing labor works. There is a desire, by our production manager, to be able to backflush a select few operations on all jobs so that they report a standard amount of labor time without the line workers having to manually log into the MES and log their time.
>
>How and where is this set up? I see on the Job Entry screen where an operation's labor entry can be changed from time and quantity to backflush only, but how does the system know how much labor to backflush. Also, how would I set up a specific operation to default to blackflush only? Are there any other tips/tricks regarding backflushing labor that you guys can offer?
>
>Thanks!
>
>Jay
>
>
>