With such a title, you must be saying – “Are you kidding, Daniel? In our company, we are currently investing a big budget for implementing an APS, taking one year and more to realize, with a lot of transformations, to help our company optimize its inventory positions.”
The answer is Yes! I is possible with a touch of good sense and pragmatism.
This article shall help readers, especially supply chain managers and BPOs, to understand the idea, which is not a trick! This is a concept that can be easily developed to support the specific process of matching demand and supply, also known as ATP or Response.
Before going into details, let’s describe the usual business situation with the above figure. The supply chain team goes over a complex monthly process to establish the planning to cover the demand in each and every inventory position. This is the basis of the MRP2 concept.
At the beginning of the execution cycle, the figure is green almost everywhere, as the plan was established at the product/location level. Time goes by and gradually orange and red colors are appearing in the grid denoting supply issues, although it may still be good at the aggregated level on the right. Typical situation, with situation being roughly good, however precisely wrong!
In reporting management, this is known as a ‘Watermelon KPI’, green outside and red inside.
What does this mean? A simple fact. The operations never fit precisely with planning unless you have a demand plan accuracy of 100%, no replenishment issues, no machine breakdowns and no transportation failure. Frankly, this will never happen.
To cover this gradually increasing mismatch situation between local demand and local supplies until the next planning cycle tries to re-establish a better and more controlled situation, supply chain planning can adopt various strategies.
- Run a WDSR (Weekly Demand and Supply Review) meeting focusing on issues. This is time consuming. It repeats every week and involves manual expediting. It generates conflicts and politics, and does not provide an optimized situation. The priorities are set by those who speak the loudest.
- Iterate faster in S&OP – but this spoils the basic idea of S&OP to focus on mid to long term. Not recommended!
- Implement an allocation logic in selling to limit excess demand to what is planned. Seems okay as you would not overcommit to customers preserving your OTIF, however you may loose opportunities. Better than nothing. To do so in an SAP world, this means you run “aATP” (advanced ATP) in S4, in association with an engine that helps decide on the allocated quantity per dimension (customer, product, region, priorities…), typically a constrained forecast planning would help, like in IBP Response.
- Implement a Response engine that links demands and supplies according to demand priorities. This kind of engine is available in APS like Kinaxis, SAP IBP Response etc.. It takes 12 months to implement and costs hundreds of thousand of Euros.
- Run a better planning engine, like IBP Optimizer, on a weekly basis to quickly adapt with short- term evolutions on the inventory position. One of the best available system propositions, which, however, calls for a complex IT project, support etc. (see my previous articles on optimization).
- Adpopt a DDMRP replenishment processing. Certainly the best of the above propositions. However, DDMRP is not easily adopted in organizations, leading to major transformations.
- That’s it! At least in an SAP solution portfolio.
The Other Solution
Now let’s get to the core proposition of this article. Once we have assessed the potential solutions, and their implications in terms of investment and transformation, we may still be looking for something a little magic. The trick that does not involve transformation, does not cost a harmful lot, is flexible enough to cover most of our requirements and – cherry on the cake! – can be implemented in a couple of weeks!
This option my team and I designed in the past, with very successful implementations, for instance, for a major European customer, which saved them about 20m Euros within the first six months of operation. Don’t search in the SAP platform, this is not a standard from our favorite software editor. It was coded and implemented on a project basis only, in an APO landscape and later with other customers in an S4 landscape.
The base concept considers that planning never matches reality. Planning does not spin fast enough to accommodate change. Major known issues in supply chain that disrupt material flow are either demand wrongly calculated or demand not being distributed against the proper inventory point, or many other reasons like MRP is not the best at reacting to shortfall situations and finding solutions.
In short, the current solution is flexible enough to react quickly to multiple situations. It can be run against different rules, covering different scenarios you are facing. It is easy to refine the scope to known issues without replanning all. It analyzes in real-time the planning situations, then proposes action plans to close arising gaps. It is able to work on operational situations as well as planned ones in the future. Last but not least, the actions are very simple elements anyone is used to managing!
See below a typcial situation with demand sitting in the wrong location and the available inventory or supply plan sitting in a low demand location. In the end, MRP propagates a requirement in the source, triggering production and possible replenishments on lower components.
Let’s agree that against this situation, the wise action plan is either to relocate the demand on the bottom network point (DC), or transfer goods from the bottom DC to the upper one (called re-deployment by customer). Obviously limits apply, like demand relocation is not an option because of delivery cost, or re-deploying goods crunches the supply chain margin because of transport.
Let’s consider a similar situation, however, in the future. What stops operation because of too high execution and transportation cost, is not anymore the case at planned order level. That means detecting the situation ahead of execution and using the solution would help to relocate demand correctly, at no cost!
The Solution in Detail
The solution was developed as an SAP ABAP code, running on S4, ECC, or APO. It requires a few extensions of master data (product, transportation lanes, rule definitions). Technical implementation takes less than one day. Maintaining the master data extensions depends on the scope. Maintaining the selection criteria to run the engine is 5’. Project implementation takes less than a single month as, in fact, it consists of setting the appropriate rules versus the targeted scenario, then a lot of testing to check the results and order creation.
From the internal logic of this engine, the program selects product locations to be optimized, according to flexible sources and destination locations (plants), using flexible criteria like planner, country, category, hierarchy. Once selected, the engine reads each product/location planning situation using the stock requirement list BAPI. What you interactively already do for sure. Then, based on these real-time data, the engine creates two time-phased matrices (day, week, or month).
The first matrix is called ATB (Available to Balance). Note the ATB quantity calculated by the engine is freely defined in rules. You may say in scenario 1, my ATB is only excess stock, whereas in scenario 2, you want to balance in future, therefore also include planned production. The rule definition lets you select any from the MRP segments provided by MD04 transaction like safety stock, firmed production, planned etc..
The second matrix is called requirement. Again, it can be selectively built based on rules with, for instance, in scenario 1 only considering the sales orders, whereas in scenario 2, you want to include forecast and dependent transport and production demand. Here, you also define a priority of demand that helps decide which demand to serve first.
Thirdly, the engine uses the rule to explore and distribute available quantity from ATB matrix to cover the requirement from the requirements matrix. While doing so, the engine starts with line 1 of the rules. If the requirement is satisfied, it goes to the next product, if not, it goes again to line 2 of the rule. Imagine line 1 defines that you want to cover demand with potential excess stock, then in line 2 you allow the engine to use safety stock at source etc.. During this demand and supply matching step, the engine can also consider location distance, transportation cost, margin, and priority. Anytime a demand is partially or completely served the engine creates a proposal.
Finally, all proposals are proposed to the planner, valuated in cost. The planner can then adopt one or many of the proposals, that become stock transport requisitions or stock transport order (STOs), or PIRs corrections (Planned Independent Requirements).
The below screenshots are taken from the Excel-based UI of the solution, presenting the master data extensions (stored in S4), the global results (scenarios), and the details actions. The engine runs on the SAP server, obviously.
Each run is identified as a session, also called scenario, that includes selected SKU calculated against a business rule. When calculated, the results will not yet get published to operation. They remain in validation phase.
Each scenario is being calculated, leading to many proposals. The planner can validate or refuse any proposal. The ribbon allows converting a proposal into orders (PREQs, STRs. PIRs) or navigating to S4/ECC.
From a master data perspective, the below screenshots show material sourcing as transportation lanes and business rule.
Last Words to Optimizing Inventory Positions
To conclude this long article, the solution is nothing complex to implement like an APS. It is compact and easy to install, enhance, and operate. The kinds of scenario you can cover are countless, from a base re-deployment engine prior to each MRP run it can calculate a deployment plan in S4/ECC from factory to DCs, it can also help to return obsolete goods from shops to platform, to simulate options to cover an explicit product, and even to perform a planning run on a rule-based basis, not like MRP.
Pointless to say, the ROI of such a solution is achieved very, very quickly. If you are pragmatic and if you like common sense, you may have thought of such a solution or even developed a similar solution if you have some coding skills. However, if not, get in touch with us!