Building a Work Center List When Your ERP Has None

When your ERP has no work center or resource master, build the list yourself: one entry per group of interchangeable capacity, each with an identifier, an honest instance count, a shift assignment, and a default setup, then import it through the work center mask. Most shops need between eight and thirty entries, which is an afternoon of work rather than a data project. The list is the single highest-leverage piece of scheduling data you will create, because it is what turns a routing into a finite capacity plan.

EDGEBIC by User Solutions has been building this list with shops since 1991, and across 35+ years of scheduling for the US Navy, GE, BAE Systems, and Cummins, the pattern holds: ERPs built around orders and financials frequently have no usable resource master, and the ones that do often model departments rather than machines.

Why the ERP usually cannot help

Plenty of manufacturing ERPs record which department an operation belongs to and what it costs, without ever recording how many machines that department holds or what hours they run. Those are accounting facts, not capacity facts. Some ERPs, particularly the order-and-inventory ones common in smaller shops, have no resource concept at all.

That gap is exactly why a finite capacity layer sits beside the ERP. The general case is in finite versus infinite capacity scheduling, and the related case where routings are missing too is in scheduling when your ERP has no routing data.

What a work center actually needs

A scheduling-grade work center carries a short list of facts. Everything else is optional refinement.

The identifier is the one to get right on day one, because routings reference it by name and matching is case-insensitive. MILL-2 finds mill-2, but it will not find Mill 2. Pick a convention, write it down, and use it in both files.

Granularity: pool, do not split

The most common modeling mistake is one work center per physical machine.

The correct unit is a group of interchangeable capacity. Three identical mills that any job can run on are one center with three instances, not three centers. Two mills with genuinely different capabilities are two centers.

The test: if a planner would not care which of them a job lands on, they belong together. Pooling gives the scheduler load balancing across the instances for free. Splitting forces every routing to name a specific machine, which is more data to maintain and a worse plan.

Where machines are interchangeable but not identical, a work center group models the pool with a per-member factor, so a slower member stretches the run time while remaining a valid choice. Use that rather than splitting.

Start with the constraints

You do not need all 40 machines on day one. In most shops, eight to twelve resources decide when work finishes and the rest have enough slack that modeling them changes nothing.

Build in this order:

1. The obvious constraints. The machines with a queue in front of them, the ones the floor complains about, the ones overtime gets scheduled on.
2. Anything a hot job routes through. Even if it is not busy, it appears on every critical path.
3. One catch-all center for miscellaneous operations, so routings stay complete without inventing thirty entries.
4. Everything else, later, driven by where the schedule disagrees with what the floor knows.

Identifying the constraints is worth doing deliberately rather than by memory. Production bottleneck identification covers the general method.

Instance counts: be honest, not optimistic

The instance count is the number that most directly controls whether the schedule is believable. Two rules keep it honest:

• Count machines a job could really run on, not machines that exist. A mill down for a rebuild is not an instance this quarter.
• Do not use instances to model operators. If a cell has four machines and two people, the machine count is four and the labor constraint belongs in operator scheduling, where a person's available hours are modeled explicitly.

Inflating instance counts is how a schedule ends up promising dates the floor cannot hit, and it is very hard to spot afterward because nothing looks wrong.

Two ways to get the list in

Build the file, then import it. A spreadsheet with one row per center, mapped through the work center mask. This is the right order, because the routing import then matches existing centers instead of creating new ones.

Let the routing import seed it. The routing pass auto-creates any work center it names that does not exist. That is genuinely useful on day one: import routings and you get a complete center list instantly, matched exactly to what the routings reference.

The catch is that auto-created centers arrive empty. No shifts, no instance count, no default setup. They will still schedule, against defaults, and the resulting dates will look plausible and be wrong. Treat auto-created centers as a to-do list: sort by shift assignment and complete every center that has none. The import reconciliation checklist covers the check.

A hybrid works well: let routings create the list, export it, fill in instances and shifts in a spreadsheet, then re-import through the work center mask as an update run. Blank cells on an update keep existing values, so a partial file is safe.

Shifts come next, and they do most of the work

A work center list without shifts is a list of names. The shift calendar is what turns an instance count into available hours per day, including weekends off, holidays, and any center that runs different hours from the plant standard.

Start with one standard shift applied to everything, schedule, and then override the centers that differ. That order gets you a working plan on day one and refines it from evidence rather than from a survey.

Validate against a week you already know

The fastest way to prove the list is right: schedule a week that has already happened, and compare. If the plan says a center was at 70 percent and the floor worked Saturday to finish, the instance count or the shift hours are wrong. If the plan shows a center swamped that nobody noticed, a routing is pointing at the wrong center.

Every correction you make from a real week is worth ten made from a spreadsheet review. The first week checklist builds this validation into day four.

Then the engine takes over

With honest centers, instances, and shifts, the full engine applies: finite capacity across multiple shifts and machine instances, sequence-dependent setups, lot streaming with transfer batches, operator skills, and mathematical optimization with a proven optimality gap. The EDGEBIC product overview maps it, and the ERP integration architecture shows how the same import layer feeds every ERP, including the ones with nothing to export.

Build yours in an hour

Bring a machine list, even a handwritten one, to a demo. Turning it into a scheduling-grade work center list live usually takes under an hour, and you leave with a mask that keeps it current.