Industry Applications (EDGEBIC)

Consumer Goods: Scheduling Through a Seasonal Peak

User Solutions TeamUser Solutions Team
|
9 min read

Seasonal capacity scheduling for consumer goods means telling the plan how many hours the peak really has, then loading the season's orders against that reality. A line that triples in volume for eight weeks needs its extra shift, its overtime days and its higher run rate reflected in the schedule, not assumed. EDGEBIC by User Solutions lets you add shifts, override a line's hours for a date range, and set exact capacity for specific days, so the finite-capacity engine shows whether the season fits before it arrives.

For the capability at the category level, see seasonal capacity planning. For the sector view, see consumer goods production scheduling, and pair this with consumer goods changeover sequencing. For the mechanics of running lines across multiple shifts, see multi-shift scheduling explained. The full map is at how different industries use EDGEBIC.

Why seasons break a static schedule

Consumer goods demand is rarely flat. A holiday gift set, a summer beverage, a back-to-school SKU: volume can double or triple for a defined window, then fall back. The plant meets the peak by adding hours, whether that is a night shift, weekend overtime, or simply pushing a line harder. The problem is that a static schedule, built on the off-season calendar, does not know any of that happened.

Two failures follow. If the schedule keeps the off-season hours, it will show the season overflowing far worse than reality, because it is loading peak orders against normal capacity. If a planner mentally "knows" the night shift is coming but never puts it in the plan, the schedule is optimistic by exactly one shift per day, and the overflow it does show is wrong in the other direction. Either way, the plan and the floor disagree, and the disagreement is largest in the weeks that matter most.

The answer is to make the peak's real hours part of the plan, then let the finite-capacity engine load orders against them.

Three ways to add hours for a season

EDGEBIC computes a line's capacity for each day from its shifts, minus downtime and partial holidays, multiplied by its instance count and its utilization percentage. Three levers change that number for a season, in order of how targeted they are.

Add a shift. For a sustained ramp, give the lines that run the seasonal SKUs a second or third shift for the peak window. The engine then loads work across every shift the line has, so a job can span the day and night shifts of the same line automatically. This is the right move when the whole season needs the hours.

Set a date-range capacity override. For a defined block of peak weeks, you can set a total capacity for a date range on a line, which the engine distributes across the available days and shifts in that block. This fits a ramp where you know the fortnight's total hours you are willing to fund and want the engine to spread them, rather than editing each day.

Set a daily capacity override. For specific days, such as the handful of Saturdays you actually run overtime, enter the exact capacity for that line on that day. A daily override takes priority over both the range override and the normal shift formula, so those days become available at exactly the hours you entered while the rest of the calendar stays untouched.

The three compose in a clear order: a daily override wins for its day, a range override applies across its block, and the normal shift-and-utilization formula runs everywhere else.

Utilization: how hard the line runs

There is a fourth lever, and it is a percentage. Each line carries a utilization figure that the engine multiplies against its raw shift hours before storing the day's capacity. A line at 85 percent reports 85 percent of its clock time as schedulable, leaving headroom the engine will not plan into.

Off-season, a conservative utilization leaves slack for changeovers, small stoppages and the normal friction of a line that is not pushed. For a peak, you can raise it toward full to reflect a line that is genuinely running flat out with a full crew and minimized changeovers, which you may be arranging with the setup matrix and sequencing. Utilization is applied when the schedule is built, so you set it deliberately for the season rather than expecting it to change mid-run.

A worked seasonal ramp

Consider a beverage line that runs one day shift off-season and triples for an eight-week summer peak. Base is Monday to Friday, 8 hours, one instance, utilization 90 percent, so the engine plans about 7.2 hours a day.

For the peak, the plant adds a night shift and works alternate Saturdays. In the plan:

  • Adding the night shift roughly doubles the weekday hours the engine sees, from about 7.2 to about 14.4 usable hours a day.
  • The Saturdays the plant actually runs get a daily capacity override at the hours the crew will work, so those specific days become available while other weekends stay closed.
  • Utilization is raised for the peak to reflect a line running with a full crew, lifting the usable share of each shift.

Now the engine loads the summer orders against this real capacity. If eight weeks of tripled demand fits, the plan shows it fitting, with the finish dates you can promise. If it does not fit even with the night shift and the Saturdays, the plan shows the overflow and which orders slip, because the finite-capacity engine will not stack two jobs on a line that can only run one. You learn that in time to add another weekend, move volume to a second line, or start building ahead.

Building ahead into the peak

Finite-capacity planning also lets you answer the classic seasonal question: how early do we start? Because the engine loads the whole horizon against real capacity, you can pull the peak SKU's build earlier into the off-season slack, where the lines have room, and stage the output. For SKUs where the commitment is a shelf date, backward scheduling pulls the build to finish just in time; for smoothing a peak into quieter weeks, forward scheduling from an earlier start fills the available hours. Either way the plan is loading against capacity that exists, not a hope.

This is where a plan earns its keep as a decision tool rather than a printout. If loading the season shows the peak overflowing even with the added shift and Saturdays, you have several levers and the plan lets you test each one before committing crew and overtime dollars. You can raise a specific line's hours further, move volume to a second line that has room, or start building the least date-sensitive SKUs earlier into the quiet weeks ahead of the peak. Each option is a change to the plan you can run and read: the overflow either clears or it does not. Deciding in the off-season, when you can still add a weekend or shift volume, is worth far more than discovering the shortfall when the peak is already underway and the only remaining lever is disappointing a customer.

Common mistakes with seasonal capacity

The extra shift lives in the planner's head, not the plan. If the night shift is real on the floor but absent from the line's calendar, the schedule is optimistic by a full shift a day. Add the shift to the plan before you trust its dates.

A range override left in place after the season. A date-range capacity override that outlives the peak keeps offering hours the plant is no longer funding, and the off-season plan silently overloads. Remove or expire seasonal overrides when the peak ends.

Utilization changed mid-run and nothing moved. Utilization is baked in when the schedule is built, so changing it does not update an existing plan until the next run. Set it, then reschedule.

Overriding capacity on a line that is not the constraint. Adding hours to a line that was never the bottleneck does not help the season fit; find the constraint first and add hours there.

Rolling it out

  1. Identify the seasonal SKUs and the lines that run them, and the peak window's start and end dates.
  2. Add shifts to those lines for the peak if the whole season needs the hours.
  3. Set a date-range override across the peak block if you are funding a known total of extra hours to spread.
  4. Set daily overrides on the specific overtime days you will actually run, and remove them when the peak passes.
  5. Raise utilization for the peak to reflect lines running flat out, then reschedule so the change takes effect.
  6. Load the season and read the plan: confirm the peak either fits or shows its overflow honestly, in time to act.

Plants where the seasonal build-ahead competes with configured, date-driven orders on the same machines have a second problem on top of this one, worked through in scheduling HVAC equipment manufacturing through the season.

Bring one seasonal SKU, its peak forecast and a line's normal calendar to a demo of consumer goods production planning, and we will build the peak plan with you.

You raise the line's available hours for the peak window and let the finite-capacity engine load the season's orders against that real capacity. In EDGEBIC you can add a shift, set a date-range capacity override for the peak weeks, or enter an exact daily capacity for specific days such as weekend overtime. The engine then loads every order against the hours that actually exist in each week, so you can see before the season whether the plan fits or which orders overflow.

A date-range capacity override sets a total capacity for a block of days on a work center, which the engine distributes across the available days and shifts in that block. It fits a seasonal ramp cleanly: you tell the line it has, say, extra total hours across a peak fortnight, and the engine spreads that capacity over the days rather than making you edit each one. A single-day daily override takes priority over both the range override and the normal shift formula for that day.

Utilization is a percentage the engine multiplies against a line's raw shift hours, so a line at 85 percent reports 85 percent of its clock time as schedulable capacity. Off-season you might run a conservative number that leaves slack for changeovers and small stoppages. For a peak you can raise it toward full to reflect a line that is genuinely running flat out. It changes on the next scheduling run, so you set it deliberately for the season rather than mid-run.

Expert Q&A: Deep Dive

Q: Our seasonal SKU triples in volume for eight weeks before the holidays. Every year we add a night shift and it still feels like guesswork. How does finite-capacity planning make that concrete?

A: It replaces the guess with a loaded plan. Add the night shift to the lines that run the seasonal SKU so the engine sees the extra hours, then load the season's real orders. Because the engine respects finite capacity, a line can only run one job at a time, so if eight weeks of tripled demand does not fit even with the night shift, the plan shows the overflow and the dates that slip rather than pretending everything squeezes in. You learn in August whether the added shift is enough, which is when you can still add a weekend or move volume to another line, not in November when it is too late.

Q: We run weekend overtime only on the busiest peak days, not the whole season. Do we have to add a permanent weekend shift?

A: No. Use a daily capacity override on the specific Saturdays you are running, which sets the exact hours for that line on that day and takes priority over the normal shift formula. The engine then treats those Saturdays as available at the capacity you entered and loads work onto them, while the rest of the weekends stay closed. When the peak passes you remove the overrides and the line returns to its normal calendar. It is targeted overtime the plan actually reflects, without changing the standing shift pattern.

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