Model the cause, not the effect

David Huygens - October 5

Model cause and not effect

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

Blogpost

Convenient but dangerous

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.

Blogpost

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

Blogpost

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.

always model the cause, not the effect

Blogpost

Are you looking for brainteasing challenges?

David Huygens

Senior Functional Product Manager at OMP Belgium

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.

Related blogs