Optimization, so good, so tough!

?(*) If you like this article, “Like” it, “Repost” it, “Comment” it, we grow by exchanging opinions!

Not only a title for a post to catch your attention, this is also what happens when an organization decides going on implementing an optimization engine for its Supply Chain Planning. In short, optimization algorithm provides the company with “Best of breed” results, against its constrained landscape. Price to get there is high and effort is tough.

?Let’s see that, although with a post format, don’t expect a comprehensive cookbook. Should you want this let me know so that I prepare a longer article.

So first I state optimization is GOOD, because when it is correctly designed and implemented, this calculation engine provides results that are based on your own selected constraints, not all of them, not none of them. In other words it calculates a feasible plan, respecting your selected limits, comparing out thousands of solutions, retaining one of the best calculated plans within a given and acceptable calculation runtime.

When I state GOOD, this is also with comparison to a reference, indeed! The base reference is the traditional MRP that each and every company, running an ERP, utilizes regularly. Its main treat being unlimited (infinite) capacity, hence provides only unfeasible plans.

When running MRP engines to build the MPS or DRP (Master Production Schedule / Distribution Requirement Plan), logic is going through a basic breakdown of demand against Bills of Material, Bill of Network, enventually converted into capacity requirement (CRP). In that logic, these resources are always available (infinite). Hence, results are unfeasible and require planners, in a subsequent phase, to smooth out overload and gaps, so as to obtain a feasible plan. This following activity is time consumming, leading to unoptimized results, although sometimes feasible. In best cases, company have a monthly MPS process that gives a little time to experiment several feasible scenario and select the best of them, for the months to come. That is happening less and less due to the big transformation in Supply Chain Planning over the last decades. The time’s challenge is now overwhelming planner’s capabilities to fit in a weekly cycle, the creation of a feasible and optimized plan, based on a MRP based starting point.

This is the case of S4 MRPLive, user managing data at very granular level (order based), representing a huge effort. This was the case in APO SNP heuristics and is still the case with IBP heurisitic, although data being period based, like week periods, this is easier.

In most of the cases, last infinite results are passed on to SOE (execution) even if they are NOT feasible yet. Starts then the never ending prioritization game, to decide which one production shall start first, which customer to deliver first etc.. In best case, if company’s capacity are oversized,?a Detailed Production Schedule engine, fade out the issues in short term.

That I am sure you know! Isn’t it?

At the opposite side of the planning engines possibilities, several options are possible. To those of you being DDMRP lovers, yes this is a genuine good option, but today I wish discussing the optimization one. So at the opposite of MRP you can use an optimizer engine to calculate your MPS/DRP.

The essential difference in operating an Optimizer, is that planning results are directly feasible, no need to reshuffle results.

Optimizer context requires you to define the constraints to be observed by the engine during calculation. You will also need to descibe the planning network to be embraced by the calculation, plant, DCs, Customers, Vendors. Before hitting the “Calculate” button, you need to configure the optimizer engine with the many parameters to finetune it. In the end, it runs and gives you a plan that respects things like production limitations, storage space limitations, minimum production to be done, transportation optimization, customer prioritization etc..

Resulting plan is GOOD and OPTIMIZED, which id the GOOD side of our topic

Well ! Where is the problem then? A bit everywhere in fact!

Let’s visit now the TOUGH side of it.

Often optimization means mathematical calculations like Simplex algorithm, so be prepared to have decimals where you would not expect in discrete manufacturing (planned production of 0.5 car ??) Be prepared not to understand the results, unless spending days and weeks anylyzing log files and application results. Be prepared to accept a plan by checking KPIs calculated by the engine (pseudo sevice level…). Be prepared not understanding the relations between planned order, between inventory levels individually. Be prepared to maintain many additional master data prior to any run. In fact be prepared to change your planning paradigm. Be prepared to trust results, as no doubt these are very valids and robusts.

From the Solution perspective, you may start your optimizer journey with Excel Solver at no cost. Easy to grab and run. Minimum skills level in optimization required, likely some VBA coding, but it is limited to 200 constraints, which is really too low compared to normal SCM projects with 1000s of SKUs and periods and Resources…

If you are a PHD, you may go with an alternate solution based on CPLEX or GUROBI or other engines. These calculation engines often require programming languages, like Json, not too complex to learn, to describe your supply chain context and limits, that you want the optimization to consider. This software segment is very developped as optimization is not only a Supply Chain item. It applies to any domain, science, eco, agro…

If your company runs SAP-IBP Supply & Response, here you have another good option, also based on GUROBI engine (for time series, and for order based planning), however repackaged by SAP so that you don’t need to program anything.

Everything about IBP context ?is converted into Optimizer configuration profile and many additionnal master data, so called costs & penalties.

The idea realized by SAP, in IBP and earlier in APO, is to convert the necessary coding in the optimization engine into cost prioritization defined in master data. Smart idea however not straight forward to implement as you must think your constraints in term of virtual costs and virtual penalties, all of them?being inter-dependent. There are 19 different costs defined by SAP, distributed in the network on SKU level, on transportations, on production resources, on production recipes etc.. This is excatly what makes an Optimizer implementation a TOUGH thing. Because you must define them individually, example taken from one of my previous customers, against 10000 SKUs, against 30 locations, against 1200 resources, sometimes with 1000s of customers. ?IBP flexibility through keyfigure formulas allows some simplifications about cost management, however creating the “Cost Model(s)” to support the business requirements about planning is a master piece to realize. There is a (s) to cost model as in most of the cases, you need to adjust it to represent different simulation scenario, or to support different markets or BUs….

So in short:

-???????Creating the cost model(s) during the design phase is TOUGH.

-???????Implementing it is NOT a 90 days option.

-???????Raising a supporting team with relevant skills is HARD.

-???????Anticipating business evolutions whereas keeping things running is SENSITIVE.

-???????BUT it does a very GOOD job which Heuristic CANNOT do!

Should you need a deeper awarness prior to go, feel free asking

#sap #ibp #optimization #supplychain