Scheduling people, not FTEs: a multi-line API site's path to 20% capacity unlock
A multi-line API manufacturing site moved from static Excel scheduling to operator-level allocation on Bodhee — naming the operator, honouring per-shift compliance limits, and using the same model to surface a 20% capacity unlock via what-if scenarios.
Capacity unlock (modelled)
Capacity unlock (modelled)
Capacity unlock identified by the site team through what-if scenarios run on the Bodhee scheduling foundation — workforce reorganisation paths in particular. A simulation output validating a deployment direction, not a delivered-schedule outcome.
Throughput uplift (modelled)
At this site, throughput-uplift paths were surfaced through what-if scenario modelling of workforce reorganisation on the live scheduling foundation — a modelled direction, not a delivered-schedule outcome.
Per-operator shift-utilisation limits honoured in every schedule
Maximum per-shift utilisation per operator is encoded as a hard scheduling constraint. The scheduler cannot produce a plan that over-allocates an individual operator, so compliance is honoured by construction rather than enforced after the fact.
SCADA-driven live task status feeding the schedule
Real-time task status from equipment SCADA flows into Bodhee, so the schedule reflects live execution rather than retrospective reports. Delays and completions trigger dependency-aware rescheduling in the same pass.
The objective
Take a multi-line API site from overall-capacity Excel scheduling to operator-level allocation on Bodhee Production Scheduling — naming the operator, area, and week, honouring per-shift compliance limits as hard constraints, and turning the same model into a what-if surface the site team can ask counterfactual questions of.
The challenge
Where the previous approach fell short
01
Capacity-level scheduling, not people
The Excel plan said “we need 14 operators on Tuesday”, not “Anna is on Line 02 in Room 3 from 06:00 to 14:00” — leaving the actual people-and-rooms allocation to informal shift-handover conversations.
02
Operator assignments lived in supervisors' heads
Turning the capacity plan into named people happened informally between supervisors at the start of each shift; when a delay landed, the rebuild was manual and the operator assignments behind it weren't written down.
03
A single product crosses multiple lines
A batch starts on Line 01, transfers to Line 02, and returns to Line 03 to finish, so the equipment, the operators, and the schedule all have to follow the material across the lines within a building.
04
Compliance enforced after the fact
A maximum per-operator shift-utilisation limit had to hold, but with scheduling at overall-capacity level the limit could only be checked against the plan rather than built into it.
The full constraint universe
Campaign-based demand
Input is a campaign — a list of products with required number of batches and a tentative start date — linked to the SFG and raw-material batches that must be scheduled alongside it.
Multi-line cross-flow
A single product moves across lines within a building, so the schedule has to coordinate Line 01, Line 02, and Line 03 around the same batch.
Task-level master data
Every material carries a detailed task list with FTE, standard duration, skill, and dependency master data.
Operator allocation by task
Scheduling happens at the individual operator level, not as a capacity pool against a headcount target.
Skill matrix
Each task has required skills; each operator has skills at specific proficiency levels. Allocation has to match.
Per-operator shift-utilisation limit
Compliance requires a maximum utilisation per operator per shift; the scheduler cannot over-allocate an individual.
Area continuity
One operator per area per shift, and the same operator across an area for the campaign week, to avoid handovers mid-batch.
Movement minimisation
Gowning time and inter-area transit are modelled as unproductive overhead the scheduler is asked to reduce.
SCADA-driven task status
Real-time task progress comes from equipment SCADA; the schedule has to react to live execution, not week-old assumptions.
Operational dimensions an off-the-shelf scheduler doesn't hold
At a multi-line API manufacturing site of a major European API manufacturer, four Autonomous Production Units operate from dedicated buildings — three of them inside the scope of this deployment. Each APU runs its own production lines and product families, but a single product moves across lines within a building: a batch starts on Line 01, transfers to Line 02, and returns to Line 03 to finish. The equipment, the operators, and the schedule have to follow the material.
That scheduling problem carries multiple operational dimensions an off-the-shelf scheduler does not naturally hold:
- Campaign-based demand — input is a campaign (list of products with required number of batches and a tentative start date) linked to the SFG and raw-material batches that have to be scheduled alongside it.
- Multi-line cross-flow — a single product moves across lines within a building, so the schedule has to coordinate Line 01, Line 02, and Line 03 around the same batch.
- Task-level master data — every material carries a detailed task list with FTE, standard duration, skill, and dependency master data.
- Operator allocation by task — scheduling happens at the individual operator level, not as a capacity pool against a headcount target.
- Skill matrix — each task has required skills; each operator has skills at specific proficiency levels. Allocation has to match.
- Per-operator shift-utilisation limit — compliance requires a maximum utilisation per operator per shift; the scheduler cannot over-allocate an individual.
- Area continuity — one operator per area per shift, and the same operator across an area for the campaign week, to avoid handovers mid-batch.
- Movement minimisation — gowning time and inter-area transit are modelled as unproductive overhead the scheduler is asked to reduce.
- SCADA-driven task status — real-time task progress comes from equipment SCADA; the schedule has to react to live execution, not week-old assumptions.
Before Bodhee, the schedule lived in Excel. Each material had a detailed task list with FTE, durations, and dependencies expressed as sequence numbers. Scheduling worked at overall capacity level — the plan said “we need 14 operators on Tuesday”, not “Anna is on Line 02 in Room 3 from 06:00 to 14:00 on Tuesday.” The work of turning the capacity plan into actual people-and-rooms happened informally, in conversations between supervisors at the start of each shift. When a delay landed, the rebuild was manual and the operator assignments behind it were carried in supervisors' heads.
What Bodhee did
How Bodhee rebuilt the plan
Four moves that took the site from capacity scheduling to operator-aware scheduling
Bodhee Production Scheduling took the site from overall-capacity Excel scheduling to operator-level allocation, and the same foundation became a scenario-modelling surface the site team built on top.
Captured operator-level planning as a live operating model. Equipment, materials, dependencies, operators, skills, and constraints became the scheduler's source of truth. Bodhee Production Scheduling accepts process orders, campaigns, or planned orders as demand input — at this site, the input is a campaign (a list of products with required number of batches and a tentative start date) which Bodhee links to the required SFG and raw-material batches. Each material's task list — FTE, standard duration, skill, and dependency master data — feeds the scheduler. The operator skill matrix, area-continuity rules, weekly-continuity preference, gowning and inter-area transit overheads, and the per-operator shift-utilisation compliance limit are all first-class constraints. The scheduler cannot produce a plan that over-allocates an individual operator or sends one through three areas in a shift.
Coordinated production across lines and buildings. Within a building, a single product moves Line 01 → Line 02 → Line 03; Bodhee schedules the batch across those lines as one continuous flow rather than three handoffs.
Closed the loop with SCADA. Real-time task status from equipment SCADA flows into Bodhee through the integration layer. When a task completes early or a delay propagates, the schedule reacts on live data, not retrospective reports. SAP MII carries inventory state so the schedule respects what's actually on the floor.
Unlocked what-if as a planning surface. Once daily scheduling was solved, the site team used the same Bodhee model to run scenario simulations. Workforce reorganisation and upskilling paths were modelled against the live scheduling foundation, surfacing a 20% capacity unlock as a deployment direction. Bottleneck-analysis scenarios on centrifuge cycle time modelled a 30% reduction by varying RPM and adjacent parameters. Cleaning-schedule optimisation scenarios modelled a 30% reduction in cleaning cycle time and faster batch relaunch. These are scenarios on the Bodhee scheduling foundation, not delivered schedule outcomes — but they exist because the model is rich enough to be asked counterfactual questions.
01
Captured operator-level planning
Equipment, materials, dependencies, operators, skills, area-continuity rules, and the per-shift compliance limit became the scheduler's source of truth — at the individual-operator level, not a capacity pool.
02
Coordinated production across lines
A single product moving Line 01 → Line 02 → Line 03 within a building is scheduled as one continuous flow rather than three handoffs across the lines.
03
Closed the loop with SCADA
Real-time task status from equipment SCADA flows into Bodhee; SAP MII carries inventory state, so the schedule reacts to live execution rather than week-old assumptions.
04
Unlocked what-if as a planning surface
The same model runs scenario simulations — workforce reorganisation, bottleneck, and cleaning-cycle scenarios — surfacing a 20% capacity unlock direction on the live foundation.
The outcome
What changed on the ground
Capacity unlock (modelled)
Throughput uplift (modelled)
Operator continuity by default
The schedule names the operator, the area, and the week — and keeps them aligned across the campaign. Operators stop being a capacity pool reconciled at shift handover; movement overhead from gowning and inter-area transit drops as the scheduler keeps an operator in one area.
Compliance honoured in-schedule
Per-operator shift-utilisation limits are not enforced after the schedule is built — they are constraints the scheduler cannot violate while building it. Compliance and the plan stop being two different conversations.
What-if on the same foundation
The daily scheduling tool became a scenario surface the site team built on. Workforce-reorganisation modelled a 20% capacity-unlock direction; bottleneck and cleaning-cycle scenarios modelled 30% reductions. These are scenarios on the Bodhee foundation, not delivered outcomes.
Why this matters beyond one site
Operator-aware scheduling is not the same problem as capacity scheduling. A plant that schedules to a headcount target is still asking supervisors to do the operator allocation informally — and is still losing time to gowning, transit, and handovers between people who don't know they were supposed to overlap. A plant that schedules to individual operators, with skill, area, continuity, and compliance held in the same model, asks the schedule to do the work the supervisors used to do at shift start.
The same shape of deployment applies wherever production is multi-line, operator-intensive, and compliance-bound: API and intermediates manufacturing, sterile and biotech processing, specialty chemicals with regulated worker-protection regimes. Once the foundation is in place, the same model can be asked counterfactual questions — workforce reorganisation, bottleneck removal, cleaning-cycle compression — without leaving the system the floor already trusts.
Related case studies
Customer anonymised at customer request. Metrics validated by the Neewee delivery team. Ranges observed across Bodhee deployments in regulated process manufacturing — directional, not a guarantee.