Industry Applications (EDGEBIC)

Contract Manufacturers: One Schedule Across Many Customers

User Solutions TeamUser Solutions Team
|
10 min read

Contract manufacturer scheduling works when many customers share one finite plan: steps route to machine pools, jobs carry a priority, and the engine loads every customer against real capacity. A job shop's mills and presses serve dozens of accounts, and pinning each customer's routing to one machine leaves the rest idle. EDGEBIC by User Solutions routes steps to work center groups so the scheduler shops the whole pool, and weights lateness by job priority so the key accounts come first without starving the rest.

This is scheduling proven across the kind of multi-site, multi-customer operations that run at Cummins' 33 locations. For machine pools at the mechanism level, see work center groups explained. For the sector view, see contract manufacturing scheduling, and pair this with make-to-order backward scheduling and high-mix low-volume scheduling. The full map is at how different industries use EDGEBIC.

The contract manufacturer's scheduling problem

A contract manufacturer sells capacity. The same mills, lathes, presses and finishing lines run parts for many customers, and the mix changes weekly. Two pressures pull against each other constantly. Every customer wants their date, and a few key accounts want to jump the queue when it counts. Underneath both, the shop has a fixed set of machines that can only run one job at a time.

Two habits make this harder than it needs to be. The first is pinning routings to specific machines: a customer's job always runs on Mill-2, so Mill-2 backs up while Mill-1 and Mill-3 sit idle. The second is managing priority by hand, moving jobs up and down a list based on which customer called last, with no way to see what that does to everyone else's dates.

The answer is to let the shop's real capacity be the pool of interchangeable machines, and to let priority be a weighting the engine balances rather than a manual reshuffle.

Route steps to machine pools, not single machines

In EDGEBIC a routing step can target a work center group: a named pool of interchangeable machines. Instead of "this milling step runs on Mill-2," you route it to the MILLING group, and the scheduler picks the best member on every run.

The pick is capacity-aware. By default the engine chooses the member that completes the step earliest, evaluating each machine against live shift capacity, including the reservations from steps already placed in the same run. So a customer's job takes whichever mill will finish it soonest, not a machine someone pinned it to months ago. If the machines differ in speed, you give each member a factor in the pool, and the engine applies it to run time, so a faster mill's shorter time is reflected in the choice.

The maintenance win is real for a shop with dozens of routings. Define the pool once, bind any number of steps to it, and add or retire a machine in one place. Add a fourth mill to the pool and every job that uses milling considers it on the next run, with no BOR edits. For the concept on its own, see what a work center group is.

You also choose the pool's selection rule. The default picks earliest completion, which minimizes each job's lead time. You can instead prefer a designated primary machine and only spill to others when it is full, which gives predictable routing, or prefer the member that can start earliest. Each pool carries its own rule, so your fast-turn cell and your steady workhorse cell can behave differently.

Weight the plan by customer priority

Sharing machines across customers means deciding whose work gives when capacity is tight. EDGEBIC handles this with a priority on each job and an optimizer that weights lateness by it.

Every job carries a priority, and the engine weights tardiness so a top-priority job's lateness counts most: a priority-1 job's lateness weighs full, a priority-2 job's weighs less, and so on down the scale with a floor so nothing weighs nothing. The default optimizer goal protects due dates first, then this weighted tardiness, then overall finish. The practical effect is a plan that works hardest to hit every date, and where something genuinely must slip, slips the lower-priority work rather than the key account.

This is deliberately not a blunt "this customer always wins" rule. Hard-coding one account to the front would starve the rest and blow their dates. Weighting tells the engine whose lateness hurts most and lets it balance the whole book against that, which is what a contract shop actually needs: the key account protected, everyone else as on-time as the capacity allows. The optimizer proposes; you accept before anything commits, and the result is guaranteed not to be worse than the plan you started from on the goals you ranked. For the optimizer in full, see mathematical schedule optimization.

A worked multi-customer run

Consider a week where three customers' jobs all need the milling pool of three mills, one of them faster.

  • Customer A's job is priority 1, due Thursday.
  • Customer B's job is priority 2, due Friday.
  • Customer C's job is priority 3, due the following Monday.

With the steps routed to the pool, the engine shops all three mills for each job and places each on the member that finishes it earliest, accounting for the fast mill's speed factor. Because the mills are pooled, the three jobs run in parallel across the cluster rather than queuing on one pinned machine, and all three dates are met with capacity to spare.

Now add a rush: Customer A drops in a second priority-1 job midweek that also needs milling. Capacity tightens. The weighted plan keeps both priority-1 jobs on their dates and, if something must give, slips Customer C's priority-3 job into the following week rather than letting a key account go late. You see that trade in the plan and decide before it commits. The whole book stays as on-time as the mills allow, and no machine sat idle while another jammed.

Keeping customer work visible

A contract shop also needs to see whose work is where. Because jobs carry their customer and the schedule loads them all into one finite plan, you can read the plan by customer, by machine, or by date. A machine that a customer's job resolved onto shows the actual machine after scheduling, not the pool name, so a supervisor knows exactly what runs where. When a reschedule moves a pooled job to a different member because capacity shifted, that change surfaces as a clear before-and-after so nobody is surprised.

Common mistakes in a contract shop

Pooling machines that are not really interchangeable. A group should hold machines that can genuinely run the same class of work. Putting a machine in a pool it cannot actually do produces a plan that assigns work it cannot run. Keep pools honest, and use speed factors for real differences.

Managing priority by phone instead of in the plan. If priority lives in who called last rather than on the jobs, the engine cannot balance it and the plan drifts from the real order of importance. Set priorities on the jobs and let the weighting do the sorting.

Treating one customer as an absolute front-of-line. Forcing a customer always first starves the rest and blows their dates. Use priority weighting, which protects the key account while keeping everyone else as on-time as capacity allows.

Leaving pinned routings in place after building pools. A step still pinned to one machine will not use the pool. Route the step to the group so the scheduler can shop it.

Rolling it out

  1. Group your interchangeable machines into pools by the class of work: milling, turning, finishing.
  2. Route each job's steps to the pools instead of single machines, and give faster members a speed factor.
  3. Pick each pool's selection rule: earliest completion for fastest turnaround, primary-first for predictable routing.
  4. Set a priority on every job so the engine knows whose lateness matters most.
  5. Run the schedule and read it by customer, confirming the pool spreads load and the priority weighting protects your key accounts.
  6. Reschedule when the mix changes and confirm pooled jobs re-shop to the best available machine, with moves shown clearly.

Bring a week of multi-customer orders and your machine list to a demo of job shop scheduling software, and we will build the pools and the weighted plan with you.

You route each job's steps to machine pools rather than single machines, and the engine picks the best available member for every job on every run. A contract shop's mills or presses serve dozens of customers, so pinning a customer's routing to one machine idles the others. A work center group lets a step target the whole pool, and the scheduler shops it against live capacity, so one customer's rush job takes whichever machine frees up first instead of queuing behind another customer's work.

You set a priority on each job, and the optimizer weights lateness by that priority so a top-priority job's tardiness counts more than a lower one's. The default goal protects due dates first, then weighted tardiness, so the plan pushes to hit every date and, where something must slip, slips the lower-priority work. It is not a blunt 'this customer always wins' rule that starves everyone else; it is a weighting that keeps the whole book of business as on-time as the capacity allows.

A work center group is a named pool of interchangeable machines that a routing step can target instead of one machine. It fits contract manufacturing because a job shop's real capacity for a class of work is the whole cluster of similar machines, not any single one. Define the pool once, route steps to it, and the scheduler picks the member with the earliest completion on each run. Add a machine to the pool and every job that uses it considers it immediately, with no routing edits.

Expert Q&A: Deep Dive

Q: We run 40-plus customers through the same set of mills and lathes. Planners pin jobs to specific machines and half of them sit idle while one is jammed. How do we spread the load?

A: Stop pinning and start pooling. Group your interchangeable mills into a milling pool and your lathes into a turning pool, then route every job's milling and turning steps to the pool instead of a named machine. On each scheduling run the engine evaluates the pool against live capacity and puts each job on the member that finishes it earliest, so a customer's job takes whichever mill is free rather than queuing behind another customer's on a pinned machine. If one machine runs faster, you give it a speed factor in the pool and the engine accounts for it. The idle-while-jammed pattern goes away because the plan uses the whole cluster as one capacity.

Q: A key account needs their jobs to jump the queue, but our other customers still have real due dates. How do we handle both?

A: Give the key account's jobs a higher priority and let the weighted optimizer sort it out. Lateness on a priority-1 job counts more than lateness on a priority-2 or 3 job, so the plan works hardest to keep the key account on time while still protecting everyone else's dates. Where the capacity genuinely cannot hold every promise, the plan slips the lower-priority work rather than the key account. You are not hard-coding one customer to always win, which would starve the rest; you are telling the engine whose lateness hurts most, and it balances the whole book against that.

Frequently Asked Questions

Ready to Transform Your Production Scheduling?

User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.

User Solutions Team

User Solutions Team

Manufacturing Software Experts

User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.

Let's Solve Your Challenges Together