Production Scheduling for Confectionery

Model multi-stage confectionery production with parallel cookers, shared cooling tunnels, and per-class routings that skip different stages for hard candy, chocolate bars, and starch-free gummy lines. This guide shows how to configure Schantt for a seven-stage hybrid flowshop, set directional changeover matrices across three product classes, and balance batch and flow stages in a single schedule.

This guide follows a fictional composite company built from industry research on confectionery; all names, parameters, and figures are illustrative.

Industry context

Confectionery production at the SMB-to-mid-market level typically involves cooking sugar syrups, tempering chocolate, forming individual pieces or bars, cooling them through a shared tunnel, demolding or releasing the items, and wrapping them at high speed. Each product class follows a distinct route through the plant: hard candy moves from cooking straight to depositing, cooling, and wrapping, while chocolate bars add a tempering and demolding step, and starch-free gummy products require depositing, cooling, demolding, a finishing drum, and finally wrapping. The shared cooling tunnel sits at the centre of the layout, creating a natural bottleneck that every product class must pass through.

The scheduling challenge is managing three divergent routings across a plant with parallel machines at the cooking stage (two vacuum batch cookers), three depositing machines serving one per product class, two demolding stations, and two wrapping lines. Process times are measured in minutes per batch, changeovers vary by product class transition and by machine, and the cooling tunnel operates as a continuous flow stage whose throughput rate depends on the product class passing through.

Crestwood Confections runs approximately 85 people at a roughly 4,000 m² facility, making three product classes across seven production stages, scheduled by a two-person planning team. The team manages about 35 SKUs with customer order sizes of 50 to 200 kg per SKU and typical lead times of two to five working days.

Process overview

flowchart LR
    Cooking["Cooking<br/>(BATCH)"] --> Depositing["Depositing<br/>(BATCH)"]
    Tempering["Tempering<br/>(BATCH)"] --> Depositing
    Depositing --> CoolingTunnel["Cooling Tunnel<br/>(FLOW)"]
    CoolingTunnel --> Wrapping["Wrapping<br/>(FLOW)"]
    CoolingTunnel --> Demolding["Demolding<br/>(BATCH)"]
    Demolding --> Wrapping
    Demolding --> Finishing["Finishing<br/>(BATCH)"]
    Finishing --> Wrapping

Seven production stages in sequence, with two entry points (Cooking and Tempering) and three per-class routings that skip different stages.

Hard Candy skips Tempering, Demolding, and Finishing. Chocolate Bar skips Cooking and Finishing. Starch-Free Gummy skips Tempering. All three converge at the shared Cooling Tunnel, then diverge again through Demolding and Finishing.

Scheduling challenges and how Schantt handles them

The schedule for this scenario is driven by customer orders: approximately 35 SKUs across three product classes, each with lot sizes of 50 to 200 kg and two- to five-day lead times. Schantt schedules forward from a start datetime and minimises total production time across the full order set. The practical horizon for this guide is a single week, though Schantt handles longer horizons with the same setup. Readers whose primary driver is make-to-stock replenishment rather than customer orders will still use the same configuration — the only difference is how order batches are grouped.

Schantt offers two scheduling modes for this scenario. Auto mode explores alternative sequences and machine assignments to find the schedule with the shortest total production time. Semi-Auto mode lets the planner fix the production sequence manually while Schantt assigns start times, machine choices, and resolves conflicts automatically. Both modes respect every configuration parameter — machines, routings, changeovers, calendars, and downtimes — and produce a validated Gantt chart.

What Schantt handles well

• Sequential multi-stage production with per-class routings — each product class passes through exactly its required stages in order, skipping the stages it does not use, with transfer times between each consecutive pair.
• Multi-machine stages with parallel cookers and lines — Auto and Semi-Auto modes explore machine assignments across each stage, distributing batches across the two vacuum batch cookers, three depositors, two demolding stations, and two wrappers.
• Mixed batch-and-flow pipelines — batch stages (Cooking, Tempering, Depositing, Demolding, Finishing) are configured with cycle duration and batch size, while flow stages (Cooling Tunnel, Wrapping) are configured with throughput in units per hour. Schantt reconciles both types in a single schedule.
• Multi-product routing with stage skipping — Hard Candy skips Tempering, Demolding, and Finishing; Chocolate Bar skips Cooking and Finishing; Starch-Free Gummy skips Tempering. Each class's routing is a simple per-class stage list with the unused stages omitted.
• Sequence-dependent directional changeovers — changeover durations are configured per product-class pair on each machine, and each pair can have different durations in each direction. Light-to-dark chocolate transitions take 25 minutes while dark-to-light takes 40 minutes on the same machine.
• Shift-aware availability with calendar exceptions and downtimes — weekly shift definitions (standard single shift, reduced hours), date-level exceptions for holidays and overtime, and machine-level planned maintenance slots. Schantt schedules production only within available time.

How Schantt handles each challenge

1. Balancing two parallel cookers with different product-class assignments.

• The Cooking stage has two vacuum batch cookers with the same 250 kg batch size and 45-minute cycle for hard candy. Cooker B also handles gummy batches (50-minute cycle). With 8 to 10 batches per shift, the planner must decide which cooker runs which product and when. Manually balancing two parallel cookers with one shared across two product classes requires constant attention to avoid idle time on one cooker while the other is overloaded.
• Each machine on the Cooking stage is configured with its permitted product classes and processing parameters. In Auto mode, the algorithm assigns each cooking batch to the earliest available cooker that supports the product class, distributing work across both machines. In Semi-Auto mode, the planner assigns the cooker manually on each batch, and Schantt fits the timing within the cooker's available time.

2. Managing the shared cooling tunnel as a single-machine bottleneck.

• The multi-zone cooling tunnel is 18 m long with three temperature zones (15 °C, 10 °C, 14 °C) and different dwell times per product class: hard candy 12 minutes, chocolate bars 20 minutes, and gummies 10 minutes. Every product class must pass through it, making it the single highest-contention resource in the plant. With only one tunnel, product classes queue behind each other. Manual scheduling commonly leaves the tunnel idle 15 to 20 percent of each shift as upstream stages produce unevenly.
• The cooling tunnel is modelled as a single flow-stage machine with a per-class throughput rate — 9,000 pieces per hour for hard candy, 1,200 bars per hour for chocolate, 8,000 pieces per hour for gummy. Because all three routings converge here, the schedule naturally serialises tunnel use. Auto mode sequences the incoming batches to minimise gaps between product-class transitions, reducing idle time. The planner inspects the Gantt to confirm each batch's tunnel entry time falls within the viable window after depositing — Schantt does not enforce a hard maximum wait, but the visual timeline makes delays easy to catch.

3. Configuring directional changeovers across three axes of variation.

• Changeovers at Crestwood vary by product-class transition, by machine, and by direction. On the cooking stage, switching from hard candy to gummy or back takes 60 minutes. On the cooling tunnel, transitions between any two product classes take only 5 minutes (belt-speed adjustment). On the flow-wrapper, changing between chocolate bars and gummy products takes 45 minutes. For chocolate tempering, light-to-dark transitions take 25 minutes while dark-to-light takes 40 minutes. Three axes of variation — class, direction, machine — create a combinatorial explosion that a rule-of-thumb blanket changeover cannot capture. Manual planners either overestimate every changeover (wasting capacity) or underestimate and cause schedule overruns.
• Changeover durations are set per machine as a matrix of from-class / to-class pairs, with each direction entered independently. On cooker A, for example, the entry hard-candy-to-gummy is 60 minutes and gummy-to-hard-candy is also 60 minutes, but the tempering machine's light-to-dark and dark-to-light entries differ. The algorithm reads the exact duration for every transition it evaluates, so the schedule reflects the real time each sequence decision consumes.

4. Sequencing a high-SKU mix with short lead times.

• Crestwood runs about 35 SKUs distributed across three product classes, with customer order sizes of 50 to 200 kg and lead times of two to five working days. The planning team currently spends six to eight hours per week constructing the production sequence manually, and any midweek order change forces a partial or full reschedule. High SKU count combined with short lead times means the sequence must be rebuilt frequently. Manual resequencing takes hours and tends to settle on familiar but suboptimal patterns that repeat the same long changeovers.
• In Auto mode, the algorithm explores sequence permutations and machine assignments to find the arrangement with the lowest total production time, accounting for every configured changeover. The weekly schedule is generated in minutes. In Semi-Auto mode, the planner locks the order of product-class blocks (for example, all hard candy in the morning, chocolate in the afternoon) and Schantt assigns detailed timings and machine choices. Midweek order changes are handled by editing the order list and re-running the schedule, which takes minutes rather than hours.

5. Handling allergen bracket sequencing without hard-constraint enforcement.

• Allergen management requires that nut-free (or gluten-free) products run before nut-containing (or gluten-containing) products, with a 90-minute deep-clean changeover between brackets. The sequence order is determined by allergen policy, not by optimisation. The planner must ensure the bracket order is correct and that the deep clean is scheduled between brackets. This is a compliance step, not a scheduling optimisation.
• In Semi-Auto mode, the planner fixes the production order, which naturally places the allergen-free bracket first and the allergen-containing bracket after it. The 90-minute deep-clean duration is entered as a changeover between the two product-class groups on the relevant machines. Schantt schedules the deep-clean slot between the brackets. Compliance with the bracket order is confirmed by inspecting the Gantt — Schantt does not enforce allergen-policy rules as hard constraints, but the visual sequence makes order violations immediately visible.

What to model in Schantt

The following five entities are the first-class objects a planner creates in Schantt. All counts are drawn from the Crestwood Confections scenario.

Step-by-step setup

The setup order follows dependencies: stages and transfer times first, then machines, then product classes with their routings, then products, then machine-level capacity and changeovers, and finally calendars and downtimes.

1. Create the seven stages in order, then set the transfer times between them. Create each stage from first to last: Cooking, Tempering, Depositing, Cooling Tunnel, Demolding, Finishing, Wrapping. Set the production type — batch for Cooking, Tempering, Depositing, Demolding, and Finishing; flow for Cooling Tunnel and Wrapping. Then, on the Cooking stage's detail page, add the transfer times to the downstream stage that each product class uses:

• Cooking → Depositing: 15 minutes
• Tempering → Depositing: 5 minutes
• Depositing → Cooling Tunnel: 5 minutes
• Cooling Tunnel → Demolding: 5 minutes
• Cooling Tunnel → Wrapping: 5 minutes (bridge transfer for Hard Candy, which skips Demolding and Finishing)
• Demolding → Finishing: 5 minutes
• Demolding → Wrapping: 5 minutes (for Chocolate Bar, which skips Finishing)
• Finishing → Wrapping: 5 minutes

The Cooling Tunnel → Wrapping bridge transfer is essential — without it, Hard Candy batches would have no route from Cooling Tunnel to Wrapping.

2. Add the twelve machines to their stages. Assign each machine to the stage it belongs to:

• Cooking: Vacuum batch cooker A, Vacuum batch cooker B
• Tempering: Continuous tempering machine
• Depositing: Drop-roller former, Chocolate bar depositor, Starch-free depositor
• Cooling Tunnel: Multi-zone cooling tunnel
• Demolding: Chocolate knockout station, Gummy demolding roller
• Finishing: Polishing drum
• Wrapping: Twist-wrapper, Flow-wrapper

3. Create the three product classes and define each class's routing. Create Hard Candy, Chocolate Bar, and Starch-Free Gummy. On each product class's detail page, set the per-class routing by selecting the stages that class passes through:

• Hard Candy: Cooking → Depositing → Cooling Tunnel → Wrapping
• Chocolate Bar: Tempering → Depositing → Cooling Tunnel → Demolding → Wrapping
• Starch-Free Gummy: Cooking → Depositing → Cooling Tunnel → Demolding → Finishing → Wrapping

No stage in these routings uses partial transfers — each batch moves as a full unit from stage to stage.

4. Add one representative product per class. Create Lemon Drops under Hard Candy, Classic Milk Chocolate Bar under Chocolate Bar, and Pectin Fruit Jellies under Starch-Free Gummy. These three products are the planning units for the schedule — each represents a full product class's behaviour. When actual orders arrive for other SKUs within the same class, they inherit the class's routing, machine assignments, and changeover matrix.

5. Set each machine's capacity parameters and changeover matrix. On each machine's detail page, enter the processing parameters per product class and the changeover durations between classes.

Batch-stage parameters (cycle duration and batch size):

• Cooker A (Hard Candy): 45 minutes, 250 kg
• Cooker B (Hard Candy): 45 minutes, 250 kg
• Cooker B (Starch-Free Gummy): 50 minutes, 250 kg
• Tempering machine (Chocolate Bar): 20 minutes, 300 kg
• Drop-roller former (Hard Candy): 20 minutes, 50 pieces
• Chocolate bar depositor (Chocolate Bar): 10 minutes, 30 bars
• Starch-free depositor (Starch-Free Gummy): 30 minutes, 250 pieces
• Chocolate knockout station (Chocolate Bar): 10 minutes, 30 bars
• Gummy demolding roller (Starch-Free Gummy): 15 minutes, 250 pieces
• Polishing drum (Starch-Free Gummy): 15 minutes, 250 pieces

Flow-stage parameters (throughput in units per hour):

• Cooling tunnel (Hard Candy): 9,000 pieces per hour
• Cooling tunnel (Chocolate Bar): 1,200 bars per hour
• Cooling tunnel (Starch-Free Gummy): 8,000 pieces per hour
• Twist-wrapper (Hard Candy): 48,000 pieces per hour
• Flow-wrapper (Chocolate Bar): 15,000 bars per hour
• Flow-wrapper (Starch-Free Gummy): 15,000 pieces per hour

Changeover matrix entries (set at least the transitions that occur in a typical week):

• Cooker A and B: Hard Candy ↔ Starch-Free Gummy — 60 minutes each direction
• Cooling tunnel: all class-to-class transitions (six pairs) — 5 minutes each
• Flow-wrapper: Chocolate Bar ↔ Starch-Free Gummy — 45 minutes each direction

6. Configure calendars, exceptions, and downtimes. Create the standard single-shift calendar (Monday to Friday, 06:00–14:00) and set it as the default. Create the reduced-hours calendar (Monday to Friday, 08:00–12:00) for low-demand periods or partial holiday weeks. Add date exceptions for public holidays and the year-end shutdown, and schedule recurring machine downtimes such as weekly cooker deep-cleaning and quarterly tunnel defrost.

For step-by-step instructions on configuring each of these in Schantt, see the Schantt documentation.

Common mistakes

1. Using a single blanket changeover duration for all transitions. Confectionery changeovers vary by product class, by machine, and by direction. A single value overestimates some transitions (wasting capacity) and underestimates others (causing schedule overruns).

Fix: Create per-pair, per-direction changeover entries on each machine's detail page. Enter the real duration for each from-class / to-class combination.

2. Creating one product class that covers hard candy, chocolate, and gummy routes. With three divergent routings that skip different stages, a single class forces every product through all seven stages, which blocks the scheduling algorithm from skipping unused stages.

Fix: Create one product class per distinct routing. Hard Candy, Chocolate Bar, and Starch-Free Gummy each get their own class with its own stage list.

3. Omitting the bridge transfer time for skipped stages. Hard Candy moves from Cooling Tunnel directly to Wrapping, skipping Demolding and Finishing. Without a transfer time entry from Cooling Tunnel to Wrapping, the schedule has no valid path for those batches.

Fix: On the Cooling Tunnel stage's detail page, add a transfer time to Wrapping. This bridge entry gives Hard Candy a complete route even though it skips intermediate stages.

4. Modelling the cooling tunnel as a batch stage instead of a flow stage. A batch stage with a cycle duration and batch size does not capture the continuous belt speed, variable throughput by product class, and short transition times that define a cooling tunnel.

Fix: Set the Cooling Tunnel's production type to flow. Enter the per-class throughput rate (pieces or bars per hour), not a batch cycle time.

5. Not accounting for the shared cooling tunnel as a single-flow-machine bottleneck. Adding a second cooling tunnel to avoid serialisation contradicts the physical layout. If the tunnel is a single physical unit, the model must reflect that.

Fix: Model the tunnel as exactly one flow-stage machine. The serialisation that emerges is realistic — the scheduling algorithm works with it, not around it.

What a good schedule looks like

Before this scenario was modelled in Schantt, the Crestwood planning team assembled the weekly production sequence manually. The results changed dramatically once the full configuration — seven stages, twelve machines, per-class routings, directional changeovers, and two calendars — was loaded and the schedule run in Auto mode.

Before (manual scheduling):

• The planner spent 6 to 8 hours each week assembling the production sequence by hand
• The cooling tunnel sat idle 15 to 20 percent of each shift because upstream stages could not be balanced against its throughput
• Changeovers consumed 15 to 20 percent of weekly production time, with no easy way to evaluate alternative sequences that might group similar products together
• A midweek order change or machine breakdown forced hours of manual reshuffling, often pushing the schedule past the end of the week

After (Schantt Auto mode):

• The weekly schedule is generated in minutes — the algorithm evaluates thousands of sequence and machine-assignment combinations against the configured parameters
• Cooling tunnel idle time is reduced as the algorithm balances batch-stage output against the tunnel's per-class throughput rates, keeping the tunnel fed more consistently
• Changeover time drops as the algorithm groups same-class batches together and selects the lowest-duration transitions between classes, using the directional changeover matrix
• A midweek order change takes minutes: update the order list and re-run the schedule, or switch to Semi-Auto mode to adjust the sequence while preserving the existing Gantt positions where possible