Just the other day, I was chatting with a customer who was preparing to roll out a new scheduling system across plants in several countries. Their IT department was all for implementing a standard system. Their plant managers weren’t so sure.
What, he asked, was my view?
There’s always been a certain tension between standardizing scheduling systems and supporting the unique business processes of individual plants or facilities.
Scheduling is intimately connected with operational details. If a standard scheduling system is implemented in the face of significant operational differences among regions or countries, the system won’t be used. Planners simply won’t be able to work with it. Even if the system is accepted, the results are bound to be disappointing: Planners will constantly be changing the schedules produced by the system.
Examples of significant local differences might include anything from labor regulations and union agreements, to the severity of traffic congestion and the flexibility of delivery time windows. It could even be the case that certain countries or operations have different machines and productivity levels.
So what do you do? Should you attempt to implement customized scheduling systems that reflect the unique operating procedures of each site? Or should you roll out a standard scheduling system and expect plant managers to learn to live with it?
Should you settle for the advantages of standardization or seek the operational benefits of reflecting local circumstances?
In most cases, neither of these extremes is ideal.
For example, if certain plants have different working time directives that limit the number of hours employees can work, those directives should certainly be taken into account.
That said, it’s crucial to know what you’re dealing with. Is a particular difference a preference (shifts must always start at 8:30 in the morning because that’s how it’s always been), or a hard constraint?
Which ‘business rules’ are just habits, and which are real constraints that cannot be circumvented?
This isn’t always easy to determine without asking probing questions such as:
Why do you always batch these product families together?
Why are certain driver-customer combinations fixed so that this driver is always scheduled to make deliveries to that customer? Is there a valid reason, such as the need for a particular kind of certification? Or is it just that the drivers prefer to make those deliveries?
Once you’ve arrived at a clear distinction between local habits and real constraints, the way forward is clear. While constraints and genuine business rules must be respected, local habits or preferences should yield to standardization.
Standardization not only lowers IT costs, it enables real business control. With a standardized system, an enterprise can swiftly move production across facilities or introduce new products.
For example, an express company with a global product may want to introduce a pre-eleven o’ clock delivery. With a standardized system, the change can be made centrally and rolled out automatically across the world. That’s a huge advantage. As Andrew McAfee and Erik Brynjolfsson noted in their Harvard Business review article (Investing in the IT that makes a competitive difference), ‘a company’s unique business processes can now be propagated with much higher fidelity across the organization by embedding it in enterprise information technology’.
Then again, there’s a clear win when best practices from across the enterprise are converted into rules that can be rolled out globally, thanks to a standardization.
So yes, standardize where possible, but don’t underestimate the importance of respecting local differences. What you’re looking for is balance. In practice, this means working with your solution provider to:
(1) Identify the core functionality that’s the same for all your plants or facilities.
(2) Create a configuration layer that allows local planners to take unavoidable differences into account. Details such as the maximum hours a person is allowed to work, or the duration of a break should be configurable by local planners.
(3) Use the final layer to reflect significant differences in business rules at the local level. If there are valid reasons why production or distribution should be conducted differently at a particular location, those business rules should be added to the system. This can be done centrally with a set of local business rules and constraints that are automatically applied when the relevant local user logs into the system. Alternatively, you could choose to have local instances of the system. This is more difficult to maintain from an IT perspective but is, nevertheless, possible.
DISCOVER MORE
Who’s sabotaging your optimization results?
Centralized supply chain planning: Busting the myths
Supply chain optimization: 3 tips you shouldn’t ignore