What Is Run Time Per Unit in Manufacturing Scheduling? EDGEBIC Definition

Run time per unit in manufacturing scheduling is the number of hours a routing step needs to process one piece of product. The engine multiplies it by the order quantity to size the run portion of the step, so a step at 0.5 hours per unit on an order for 100 units becomes 50 scheduled hours. It is the pure, recurring per-piece work content, kept separate from the fixed setup time a step incurs once no matter how many pieces are made.

This entry is part of the EDGEBIC by User Solutions glossary series; for the wider vocabulary of scheduling, see the manufacturing glossary. Run time and setup time are the two halves of a step's work content, so read this next to what is setup time in manufacturing.

How Run Time Per Unit Works

A routing step describes one operation on one work center, and its duration comes from two pieces: a fixed setup and a variable run. Run time per unit captures the variable half. It answers the question "how long does one piece take here?" and the engine scales that answer by the number of pieces the order actually calls for.

The arithmetic is deliberately transparent. Total run hours for a step equal the per-unit figure multiplied by the order quantity. A step at 0.5 hours per unit is 50 hours for 100 pieces and 20 hours for 40 pieces, with no separate entry needed for each order size. That single per-unit value is what makes the same routing usable across every quantity you might build.

Setup sits on top of the run hours as a one-time cost. Because run time scales and setup does not, keeping them as separate fields is what lets both behave correctly. Bury a fixed cost inside the per-unit figure and small orders will undercount it while large orders overcount it; split them and the schedule stays honest at every quantity.

A Concrete Example

Suppose a drilling step takes half an hour to drill one part. You record run time per unit as 0.5 hours on that step. There is no need to think about any particular order yet; you are describing the operation itself.

Now an order arrives for 100 parts. The engine multiplies 0.5 by 100 and places 50 hours of drilling into the schedule, then adds the step's fixed setup, say one hour to install the fixture, for a total of 51 hours. A later order for 40 parts reuses the identical routing: 0.5 times 40 gives 20 run hours plus the same one-hour setup, for 21 hours total.

The per-unit value did all the scaling. The planner entered the operation once, and it produced the right hours for two very different order sizes without any per-order editing.

How EDGEBIC Uses It

Run time per unit is a routing-step field that flows straight into how the step is sized and placed.

• The scheduling engine multiplies run time per unit by order quantity to size the run portion of the step, then adds setup, before allocating the total across shifts and machine instances.
• The routing is quantity-independent. Because the per-unit value scales automatically, one routing serves every order size without duplicate time entries.
• Cost and load downstream both build on the resulting hours, so an accurate per-unit figure keeps estimates, utilization, and quotes consistent.

Once a step's run hours are known, buffers such as queue time compose around it before the next step can start. To see how the sized hours of every step add up against a work center's available time, read load vs capacity in scheduling.