Manufacturing Schedulers: What works and what doesn’t!

Subhashish Das, Vamsi Teja

Mr. Srinivasan Prabhu, the Head of Planning at a major pharma company, is having a frustrating day with his colleagues in the Production Planning department. Despite the implementation of a cutting-edge scheduling system over the past several months, his team’s workload has only increased. The company, which is heavily focused on exports, has been shelling out large amounts of money in penalties due to delayed deliveries to its customers. The primary objective behind the investment in the scheduling system was to improve the planning process and eradicate the issue of penalties altogether. However, Srini, as he is fondly called, is struggling to justify to the higher-ups why the expensive planning system has not delivered the expected results so far. Additionally, a recent audit of the operations team revealed that the tool’s schedule is not being followed either. Surface-level feedback suggests that change management and lack of proper training may be the issue. Still, Srini knows that if those were the issues, the planners wouldn’t be able to update the past altered production data in the scheduler to keep up pace with the actual progress.

During lunch, Srini discussed his frustrations with Mr. Madhur Seth, the Head of IT, who assuaged him of at least meeting the need of digitalisation of the Supply Chain. However, Srini needed to be more convinced about the benefits of digitalisation, as it had not resulted in any improvements in on-time performance, inventory reduction, operating expenses, or output. He also questioned the claim that digitalisation could reduce the dependency on people since the planning system was still heavily reliant on human inputs, rather than generating schedules that can be strictly adhered to.

Srini realises that there could be deeper, underlying issues at play preventing the scheduling tool from being used effectively. He feels that he needs to take a step back and re-evaluate the entire planning process to identify the root cause of the problem.

Seems like déjà vu?

Have you ever felt like you’ve hit a dead end with your planning system, despite investing a significant amount of resources into it? Don’t worry, you’re not alone! Keep reading to discover the core issues that impact such implementations and learn how to establish a planning system that will make you reliable and on-time.

Most advanced scheduling systems implemented in manufacturing plants lose relevance very quickly. Either the schedulers operate at a lag of a day or two as compared to the real-time situation on the shop floor, or the planners stop using it completely. And both of these situations have got nothing to do with any technical incapability of a scheduler to model unique rules or manage the complexity of master data. Let us understand why most scheduling systems are not able to survive for long in manufacturing organisations.

Mapping the shop floor – Is an exact replica a cause of concern?

The science of scheduling primarily focuses on maximizing the utilization of people and equipment, which requires a precise understanding of when resources are available and when they are occupied. Achieving this goal involves configuring a digital twin of the shop floor, where all system resources are mapped to their digital counterparts with identical parameters, including cycle time, set-up/set-down times, cleaning/maintenance schedules, and more.

The most highly touted feature of such advanced planning systems is the Gannt Chart view of orders on multiple work centers including their start and end times. This view can give the users an impression of control and precision. Hence, if the parameters do not match, then the expected start and end won’t match at any work centre which will kill the purpose of the implementation itself.


To generate this level of view, herculean efforts are required to configure the plethora of rules for scheduling, sequencing, batching, and routing at all work centres.

A research was conducted by Vector involving production planners from 40 Organizations across industries (Equipment manufacturing, Textile, Garment manufacturing, Pharma, Automobile, aluminum casting, etc) for understanding the implementation success and usability of such production schedulers. The study highlighted the various problems that planners were facing. 70% of the respondents expressed that they faced one or the other problem with the scheduler. While many of these unhappy planners had multiple issues with it, when picking the most dominant issue they had with their scheduler, 48% expressed that there is lack of dynamism in the tools, 33% said that the tool is complex to use and 19% claimed difficulties with master data management.



70% of these respondents in the survey Vector conducted by Vector was of the opinion that following the schedule generated by the system threatened either delivery commitments or capacity utilization of critical workcenters or both. So, they modified the schedule before implementation. A probing through personal interview into why some are comfortable with the system generated schedule while majority are not, clarified that these were companies that had fairly stable demand, little or no RM issues, and significant extra capacity to able to absorb any random variability. Essentially their ‘constraint’ or bottleneck consistently is in the market and not operations.

But in firms which have the constraint in operations, no plan survives first contact with the enemy called Variability.

Let us understand how variability attacks these very tenets of a successful production scheduler implementation.

In execution, there are two types of variabilities that hit the schedules– Inherent and Forced.

Inherent variabilities

Inherent variabilities are factors that are always present in any manufacturing plant, for e.g. delays in the arrival of raw material or packaging material, machine breakdowns, unexpected quality issues, changes in customer schedules, delay or early arrival of 3rd party inspector, changes in container schedules etc.

These last minute variations cannot be modelled upfront on a scheduler, hence requiring additional modifications on the generated schedule to ensure proper utilisation levels.

Forced variabilities

Forced variabilities, on the other hand, are introduced by the participants themselves; for e.g., An escalation from the National Sales Manager for an order under execution ensures many batching/scheduling/sequencing/routing rules are forcefully set aside or modified, and the urgent order is expedited.

These inherent and forced variabilities result in a continuous change of schedules at all work centres.

This has got the following ramifications

▪ If a scheduler is set up to quote due dates against orders, those dates would shift frequently. As a result, the Customer Required Delivery Date (CRDD) itself is taken as the commitment. The only attempt will be to ensure that any new date re-casted due to variability and uncertainty is close to the CRDD. However, in cases when the load is higher than the available capacity, the likely readiness date will keep shifting away from the CRDD.
▪ On the other hand, if the scheduler is not ‘re-run’ based on the latest impact of variability, then all the Gantt Chart views of start and end dates lose their relevance, and the entire information becomes unusable within no time.
▪ And if time buffers are used in scheduling to protect against the variability, then the schedule /itself will not be precise enough to be shown at a minute level.
▪ Finite scheduling at all work centres seems necessary to arrive at deterministic start dates in any of them when work centres feed onto one another. But if schedules keep changing in all work centres, then promised benefits of ‘Visibility’ and ‘Control’ become meaningless. These two terms are often marketed as the key selling points. However, if what is visible today changes drastically in the next shift, then that ‘Visibility’ is non-actionable, which implies it will never give any ‘Control’.


The customers who were initially impressed by the Gantt Chart view of scheduled orders on workstations later realize that the sense of control and precision conveyed by the chart was an illusion, as the constantly changing schedules make it difficult to adhere to the planned timelines.

The frequently changing ETAs takes ownership of on-time performance away from the production teams. The scheduler is made the scapegoat. “We did what was best according to the scheduling software…. Sales team should be content with the new date as it is the best possible date given the circumstances…….” is one of the most common excuses.

A typical final state of scheduler implementation

What happens when a schedule is disrupted due to inherent and forced variabilities?

A few scheduling software’s make it easier to get back on track; provided there is hard coupling between the scheduling software and the legacy ERP on which the final production orders are created or in case the scheduling software doubles up as a manufacturing execution system. In such scenarios, for some time, given the high expenditure and management focus, the on-ground team will try to keep the scheduler updated by making entries on it post the event has happened. Lag of 1-3 days is usually noticed. But since a Murphy cannot be predicted, they soon realise that a dedicated team is required to keep the scheduler updated with the ground-level happenings.

It transforms from being a guiding lighthouse to a lagging shadow. It’s like having to manually enter your latitude and longitude every time you want to know your position on Google Maps.

What is the benefit of forcefully keeping the scheduler updated? The realization dawns upon eventually, more so when master and transaction data must be continually updated, and then finally, in many cases, the scheduler is reduced to a transaction recording system, while excel spreadsheets take over as the primary tool for scheduling.


The way ahead

An elegant solution has to accept the above realities. Let us understand the implications of the above:
▪ If we have to acknowledge the presence of uncertainty and variability, it becomes crucial to recognize that the only aspect that requires protection is the final due date committed to the customer. The schedule of start and end dates on individual work centres is not of great significance
▪ The above implies that we need to leave aside protective capacity while quoting due dates
▪ Since constraints control the output of the system, we need to focus on considering the scheduling needs of these work centres to ensure the overall plant is well levelled in terms of demand and capacity.

Using protective capacity to quote dates implies that the capacity may get wasted in the execution if the actual variability is less than what has been considered. So the way out is a 3 engine approach.

Engine 1 – Planning

Rather than accepting a customer-requested delivery date (CRDD), planning should actually plot the order on the key CCRs and check the feasibility of managing delivery on or before the CRDD. If not feasible, the customer should be informed about the possible due date based on the order load on relevant CCRs and a protective buffer time. The buffer time safeguards the order from Murphies and provides enough time for batching/sequence optimisation at critical work centres. In the case of Make to Stock scenarios in the legacy ERP where the WIP is not tagged to an order VectorFlow’s Planning Engine is able to dynamically allocate the WIP while keeping the load on downstream resources balanced and quotes the best possible due date for each order. This due date is the outer boundary which should not be crossed in execution. The batching/sequencing needs to happen in such a way that this date is never crossed. This enables a culture of an On- time delivery promise which is sacrosanct. A release date is derived to define the planned start date of an order on the first work centre. Releasing orders as per the release date prevents unwanted queueing on the shop floor.

Engine 2 – Execution

During execution, the arrival of raw materials, packaging materials and other bought- out components may not follow the exact plan. Some might be received early, and some might be delayed. VectorFlow’s Execution Engine first creates an unconstrained sequence of orders on the few key CCRs assuming all inputs are available. It then generates the list of the preferred inputs required for executing the orders. Many times there are alternate inputs which can be used in place of the exact input defined in the BOM. The planner filters the orders based on input availability. This revised order list is input to the sequencer engine to generate the final execution sequence. An intelligent algorithm ensures the most optimal sequence/batch while ensuring an apt percentage of the protective buffer time is left intact for the complete execution in the remaining work centres. Each order has a revised estimated completion date which is earlier or the same as the original delivery due date. A colour priority system ensures if an order is delayed, it gets expedited at all remaining work centres to meet the due date. The sales team is made aware of the latest readiness date of the order in case the order is getting read much earlier than the promised due date.

Engine 3 – Pull based Dynamic Release Management

A typical order can get executed via multiple routes available within the plant. From time to time, the order load of released orders on certain routes can increase if the rate of output at the key CCRs drop while fresh input is being released as per the calculated release dates. Similarly, order load on certain routes can go down also if there are large amounts of rejections/rate of output at the key CCRs increases. To avoid starvation and over queueing on the routes, VectorFlow’s Pull based Dynamic Release Management Engine keeps a tab on the released load at each and every route and suggests early/late order releases depending on the status of the released load as compared to a threshold. The threshold is decided such that key CCRs will not experience starvation / over- queueing. This dynamic release control ensures WIP on the shop floor is maintained at a healthy level which key CCRs get utilised properly.

The only input from the Planning Engine to the Execution Engine is the committed due dates. Execution Engine run handles finite scheduling/sequencing/batching in critical work centres based on a rule of remaining duration to the committed due dates. In all other work centres, instead of a schedule, people get a sequence of orders that the work centres should follow to ensure due date adherence.

Visibility and Control in the 3 engine approach:

In this new way of working, instead of a Gannt view, a future load chart on each key work centre will depict the cumulative pending order load in a horizon. Planners can take a call on whether to accept an urgency or plan preventive maintenance based on the utilisation of that work centre in that horizon. Lower priority orders can be parked for urgent orders /preventive maintenance.

The above 3 engine approach also requires paradigm changes in decision-making both in Sales and Operations. They are as follows:

▪ Acceptance of the fact that a detailed schedule does not give control. What is required is a pending load in front of any work centre. This gives much better control. If you want to understand where you are in a specific road journey and the likely time of reaching the destination, what you need is queuing information at key nodes and not the precise schedule of every vehicle, along with your vehicle at every node on the road.
▪ Due dates need to be committed perpetually to an incoming order as and when the order arrives. The date should be subordinated to during the execution engine run. The pending order bank should not be re-cast as the typical monthly planning process. The committed due date of an order cannot change. The monthly re-casting leads to desynchronization and loss of capacity in many plants.
▪ Forcing a new customer due date within a packed schedule of previous orders should not be allowed. If that is a regular occurrence and there is a need to serve the urgent orders, then a separate configuration of capacities should be done accordingly to avoid conflicts with running orders.
▪ Material release schedules based on pull signals of WIP should never be violated for want of local efficiency improvement at a non-constraint work centre.

Impact on implementation

▪ Since constraining work centres will always be fewer than the complete manufacturing set-up, the master data management will require far lesser efforts.
▪ The scheduling in Execution Engine is localized, and based on the available load, it is much more likely to be closer to reality.
▪ The sales team and customers are committed to only one Due Date, which doesn’t change and planning subordinates to deliver the order on or before that due date.


Talk to Us

Related Articles

Get in touch

Registered Office:
Vector Management Consulting Pvt. Ltd.
10th floor, Thane One, DIL Complex,
Ghodbunder Road, Majiwada,
Thane (West), Maharashtra - 400610, India.
022 6230 8800, 022 6230 8801

Corporate Identity Number:
For any queries, contact:
Mr. Hemal Bhuptani
[email protected]