High-Mix Low-Volume: Scheduling Hundreds of Small Jobs

High mix low volume scheduling holds together when flexible machines are pooled and sequence-dependent setup is priced, so hundreds of small jobs load against one honest finite plan. A shop running 300 active orders under 50 pieces each lives on machine flexibility and changeover discipline. EDGEBIC by User Solutions pools interchangeable machines so jobs spread across the cluster, and prices each changeover by what ran before, so the plan charges the real setup and the optimizer can group compatible work.

For the pooling mechanism, see work center groups explained. For sequence-dependent setup, see the setup matrix explained. For the sector view, see high-mix low-volume scheduling and the classic job shop scheduling challenges. Pair this with contract manufacturer scheduling and tool-and-die setup-heavy scheduling. The full map is at how different industries use EDGEBIC.

What makes high-mix low-volume hard

High-mix low-volume shops share two traits that break simple schedules. The first is sheer job count: hundreds of active orders, most of them small, each with its own routing and due date. The second is that volumes are low, so setup time is a large share of every job. On a 20-piece order, an hour of changeover can be most of the work, where on a long run it would vanish into the background.

Two habits make this worse. Pinning each part to one machine ignores that most parts could run on several, so machines back up while their equivalents sit idle. And treating setup as a flat average ignores that changeover cost depends entirely on what ran before, so the plan is wrong in both directions at once: optimistic on the expensive changeovers, pessimistic on the cheap ones.

A high-mix plan that matches the floor needs two things fixed together: machine flexibility modeled as pools, and setup modeled as a real, sequence-dependent cost.

Pool the flexible machines

In a high-mix shop, the real capacity for a class of work is the cluster of machines that can do it, not any single one. EDGEBIC models this with work center groups: a routing step targets a pool of interchangeable machines, and the engine picks the best member for each job on every run.

The pick is capacity-aware. By default the engine chooses the member that finishes the job earliest, evaluating each machine against live capacity including the reservations already made in the same run. So hundreds of small jobs spread across the whole cluster automatically, and a part is not stuck waiting on a pinned machine while its equivalent is free. If machines differ in speed, each pool member carries a factor applied to run time, so a slower backup's longer time is accounted for.

This is where the fast-machine-plus-backup pattern gets easy. Put both in the pool, give the backup its speed factor, and the engine uses the backup when doing so finishes a job sooner than waiting for the fast machine. You do not decide job by job; the pool and the factor let the engine make the call against the real load. And when you add a machine to a pool, every routing step that uses it considers it on the next run with no edits. For the concept alone, see what a work center group is.

Price the setups by sequence

Pooling spreads the work; setup pricing keeps the plan honest. In a low-volume shop, sequence is where the capacity is won or lost, because changeover is such a large share of each job.

EDGEBIC stores changeover as a matrix keyed by machine and by the pair of products involved. You keep it small with setup families: group parts that change over identically, price each family-to-family transition, and add product-level overrides for the exceptions. A matched cell replaces the routing's flat setup rather than adding to it, so the cell holds the total changeover for that transition. Same part back to back returns zero automatically, and each machine carries its own matrix because changeover physics differ per machine.

With setups priced, the plan charges the real cost of a sequence rather than an average that is wrong both ways. That does two things. It makes the finish dates believable, because the changeover time in the plan is the changeover time on the floor. And it gives the optimizer something to work with: the least-setup goal can reorder a machine's queue to group compatible jobs and minimize total changeover, while still protecting due dates. The optimizer proposes, you accept before it commits, and the result is guaranteed not to be worse than where you started on the goals you ranked. For the concept, see what a setup family is.

A worked high-mix picture

Consider a week with 60 small jobs, most 20 to 40 pieces, all needing the milling pool of four machines, one faster than the rest. Each part belongs to one of five setup families based on fixturing.

With the steps routed to the pool, the engine spreads the 60 jobs across all four mills, placing each on the member that finishes it earliest and accounting for the fast mill's speed factor. No mill jams while another idles. With each mill's setup matrix loaded, the plan charges the real changeover for whatever order it runs, so the finish dates are believable rather than optimistic.

Now run the least-setup goal on the busiest mill's queue. Instead of a sequence that bounces between fixturing families and pays a changeover on nearly every job, the optimizer groups the jobs by family, so a run of same-family parts pays the mechanical swap only, and the family changes happen a handful of times across the week instead of on every job. On low-volume work, where setup rivals run time, that regrouping frees real capacity, and it is capacity the pooling then spreads across the cluster.

Reliable dates in a chaotic mix

A high-mix shop reschedules constantly as orders land and priorities shift. Because the plan loads every job against real finite capacity, and setups are priced by sequence, the dates it produces hold up to being read and defended. When capacity shifts and a pooled job moves to a different machine on reschedule, that change surfaces clearly. When you log what actually ran, the reschedule anchors each machine's next changeover to the part that genuinely completed there, so the setup charged reflects reality rather than a stale plan.

For jobs where the commitment is the due date, you can add backward scheduling so small jobs finish just in time and do not clog the floor early. Pooling, setup pricing and backward scheduling reinforce each other: the pool spreads the load, the matrix makes each machine's sequence honest, and backward keeps work in process down. In a high-mix shop, where the plan is rebuilt several times a week as new orders land, that combination is what keeps each replan believable instead of a fresh round of optimistic dates the floor will ignore by Wednesday.

Common mistakes in high-mix scheduling

Pinning parts that could run on several machines. A pinned step cannot use the pool, so it queues while equivalent machines idle. Route flexible steps to the group.

One product in a setup pair has no family. The family lookup needs both sides; assign one and leave the other unassigned and the plan falls back to a flat default with no error. It is the most common cause of a matrix that "does not work."

Setup cells holding only the clean or purge. A matched cell replaces the flat setup, so a cell missing the mechanical swap deletes it from the plan. Cells hold the total changeover.

Running the least-setup goal before the matrix exists. The goal needs priced transitions to optimize against; it stays out of the picture until a machine's matrix is built. Price the setups first.

Rolling it out

1. Pool your interchangeable machines into groups by class of work, with speed factors for real differences.
2. Route flexible routing steps to the pools so the engine spreads the small jobs across the cluster.
3. Build a setup matrix on your busiest machines, grouping parts into families and pricing the total changeover per transition.
4. Run the schedule and read the plan, confirming the pool balances load and the setups charged are real.
5. Run the least-setup goal on a busy machine's queue, read the regrouped proposal, and accept it once the trade looks right.
6. Consider backward scheduling for due-date-committed jobs so small orders finish just in time.

Deciding which of those small jobs runs first is a separate question from where it runs, and it is answered in job shop mixed-priority scheduling, which covers rush, standard, and stock orders in one backlog.

Bring a week of small jobs, your machine list and a couple of real changeover times to a demo of machine shop scheduling software, and we will build the pools and the matrix with you.