CascoDev
CascoDevTagline
CascoDevBolt
Casco Development > ShopVue Blog > Detecting Bottlenecks by Backlog
Detecting Bottlenecks by Backlog 

By Morgan Witthoft, Senior Consultant, Casco Development

Our next metric, backlog size, comes from the basic intuition that a bottleneck will have a heap of work waiting for it all the time.

 

The computation is:

Find every operation waiting at a work center "right now".

To measure the backlog in hours, take the sum of:

(standard setup time) + (quantity ready) x (standard run time per pc)

or, for operations that have a fixed run time (such as heat treat)

(standard setup time) + (standard run time for the operation)

You should measure the backlog size several times – say, every day at 6:00am. After a week's worth of measurements, the work centers with the biggest average backlog become suspects.

Also notice the data you need:

  • Accurate standards
  • Real-time WIP status (quantity ready at each work center)

Reasons why you can't confidently conclude that you've found the bottleneck include:

  • Summing the setup standard is unreliable; setup standards themselves are notoriously vague, and a well-managed work center will combine setups anyway.
  • Summing the operation time is unreliable; heat treat and similar work centers typically process several orders at once.

Note this calculation suggests analyzing by work center rather than by workpoint. This is because

  • Routings typically plan indicate the work center, not the specific machine, in which case quantity ready "at a machine" cannot be computed
  • Work centers with many similar machines should compute a combined backlog. For example, if you have a work center with nine lathes, each lathe (workpoint) might have a small amount of WIP waiting, but the backlog for "lathing in general" is the (large) sum of all nine of these backlogs.