Production Scheduling in D365: Finite Capacity, Resource Groups, and Scheduling Percentages

I promised after the BOM line types article that I would come back to production scheduling, and specifically to the three things that decide whether your schedule is a plan or a fiction: the finite versus infinite capacity choice, how resource groups and resources relate, and the percentages hiding in resources and calendars that quietly stretch or shrink every operation time.

TWO ENGINES: OPERATIONS SCHEDULING AND JOB SCHEDULING

D365 schedules production with two distinct engines and people mix them up constantly.

Operations scheduling works at the resource group level and in day buckets. It answers "which days will this order occupy the machining group" without choosing a specific machine or sequencing jobs within the day. It is fast, stable, and the right granularity for order promising and medium-term capacity views.

Job scheduling breaks each operation into jobs (setup, process, transport and so on), assigns specific resources, and sequences to the minute. It is what the shop floor sees on the job list, and what Gantt-level decisions run on.

A pattern that serves most plants well: master planning and order creation run operations scheduling; job scheduling happens closer to execution, for a short horizon (days, not weeks), where the data is real enough to deserve minute-level precision. Job scheduling a six-week horizon produces beautiful schedules that are wrong by Thursday.

FINITE VERSUS INFINITE: WHAT THE FLAG ACTUALLY DOES

Infinite capacity scheduling places operations at their ideal dates and lets resources overload. Finite capacity makes the schedule respect available capacity: if the machining group is full on Tuesday, the operation moves.

The instinct of every new implementation is to turn finite capacity on everywhere, because it sounds more accurate. Resist it. Finite everywhere means every disturbance ripples through the whole schedule; one late material receipt reshuffles three weeks of work, and planners stop trusting the system because the plan changes every time they look at it.

The pattern that works is finite capacity only where capacity is genuinely scarce:

• Identify the true bottleneck resources (usually one or two per value stream, and everyone on the floor already knows which they are).

• Mark only those as finite; leave the rest infinite. Non-bottleneck overloads are noise; the bottleneck schedule is the plant schedule.

• Use the capacity scheduling time fence in master planning so finite logic only applies inside a horizon where the data deserves it; beyond that, infinite is honest about being an estimate.

One more flag people forget: finite capacity has to be enabled both on the resource and respected by the scheduling run's parameters. If schedules look overloaded despite finite resources, check which side is off; it is usually the run parameters on a batch job someone copied years ago.

RESOURCE GROUPS, RESOURCES, AND CAPABILITIES

Routes should almost never name specific resources. The route operation points at requirements; the scheduler picks the resource. The clean hierarchy:

• Resource groups organize resources that share a calendar and broadly interchangeable purpose (a work cell, a line, a labor pool). Operations scheduling books at this level.

• Resources are the individual machines, tools, or people inside the group. Job scheduling picks among them.

• Capabilities describe what a resource can do (weld stainless, hold tolerance X, lift 5 tons). Requirements expressed as capabilities let the scheduler choose any qualified resource, including ones added after the route was written.

The maintenance argument decides this design: hard-code a resource in a hundred routes and the day that machine is replaced you edit a hundred routes. Express the requirement as a capability and you edit one resource card. Use specific-resource requirements only where regulation or physics genuinely binds the operation to one machine.

THE PERCENTAGES THAT BEND TIME

Now the part from the title that most people have never deliberately configured. Operation times in the route are theoretical. Two percentages scale them in scheduling, and a third controls loading:

• Resource efficiency percentage: a resource at 80 percent efficiency turns a 60-minute process time into 75 scheduled minutes; at 120 percent, into 50. This is the right place to model an old machine versus a new one running the same route, or a training-period labor pool. Because it sits on the resource, the same route schedules differently across resources, which is exactly what you want and exactly what surprises people comparing two plants' schedules.

• Calendar efficiency: working time slots in the calendar carry their own efficiency property, scaling capacity for the periods they cover. A 100 percent eight-hour shift offers eight capacity hours; the same shift at 50 percent offers four. Useful for ramp-up periods, summer crewing, or planned maintenance windows without rebuilding calendars.

• Load percentage on the operation: how much of the resource's capacity the operation consumes while it runs. An operator minding two machines, a furnace that takes batches: load under 100 percent lets the scheduler book parallel work onto the same capacity.

The reason these matter more than people think: they compound silently. A route time of 60 minutes on an 80 percent resource inside a 90 percent calendar slot is not a 60-minute plan, and when actuals consistently miss the schedule, the answer is usually not "the route times are wrong" but "nobody has looked at the efficiency settings since go-live." When the floor says the schedule is unrealistic, audit the percentages before you let anyone pad route times; padded routes poison costing as well as scheduling, because route times feed the standard cost roll-up I covered in the costing article.

A SANE STARTING CONFIGURATION

For a plant implementing this fresh: operations scheduling for planning, job scheduling for a two-to-five day execution horizon. Finite capacity on declared bottlenecks only, inside a capacity time fence of a few weeks. Routes pointing at resource groups or capabilities, never individual machines unless forced. Efficiencies at honest values measured from history, reviewed quarterly, owned by someone by name. Every one of those choices is reversible, so start simple and add precision where the plan demonstrably fails, not where it might.

TAKEAWAYS

Scheduling quality in D365 is mostly configuration honesty. Use the two engines at the granularity they were built for; reserve finite capacity for real bottlenecks so the schedule stays stable enough to trust; let capabilities, not hard-coded resources, drive resource selection; and audit the efficiency and load percentages, because they silently scale every minute of every operation. A schedule the floor trusts beats a schedule that is theoretically optimal.

Next time: shop floor execution, the production floor execution interface, and what good job feedback discipline does for both scheduling accuracy and costing.

In this series: previous article BOM Changes and Standard Cost in D365 · next article Shop Floor Execution in D365