Model the cause, not the effect
David Huygens - May 20, 2021
A joker on the internet recently came up with a creative solution to that old which-one-came-first riddle. “I ordered a chicken and an egg from Amazon,” he said. “I’ll let you know which came first.”
Do I wish my life were as simple as that? No, I actually enjoy identifying the root cause of events and the deeper reasons behind habits and practices. As a matter of fact, it’s part of my job: I design supply chain planning solvers.
Convenient but dangerous
Blog post
Here’s an example. In some industries it is common practice not to produce every SKU every day. Planners instead define an ‘ideal’ production frequency for each SKU, for example every three, seven or fourteen days, based on some product characteristic. From a planner’s point of view, this is a very convenient way to generate predictable planning patterns.
However, it’s pretty dangerous to model such a rule in an optimization solver. The primary purpose of a solver is to dynamically balance capacity, stock, and demand. When you force the solver to stick to the fixed frequency rule, you are likely to induce negative effects on inventory and load KPIs, especially when dealing with unforeseen circumstances like COVID-19. Faced with sudden changes in demand, it can be better to diverge from a predefined frequency.
Blog post
Finding the underlying reasons
Of course, planners insist on keeping this production frequency constraint on board. That’s okay, but it should be understood as the consequence of the planning problem at hand, not the deeper reason or cause. Typically, such a planning practice would have been put in place in response to some underlying constraint, such as the limited availability of experts on the shop floor on particular days of the week, or heavy cleaning time between different SKUs being produced on the same machine. Who would want their perfect vanilla yogurt to have some unexpected pieces of strawberry in it?
Modeling the primary requirements
Blog post
These are the primary requirements we should look for when building a solver. If we model these requirements, the solver will be able to dynamically react to any change. Sudden increases in demand, additional flexibility in personnel availability, or more efficient cleaning equipment will then be taken into account to optimize the plan for all KPIs.
That’s why at OMP we have a motto: always model the cause, not the effect. And we use brains—our own and our customers’—to figure out what comes first, not Amazon.
David Huygens
Senior Product Manager at OMP BE
Biography
With 15 years of experience at OMP, David is a Senior Functional Product Manager in the planning cycle team, focusing on optimizing our planning solutions and adding value for our customers in a variety of industries.
