Technical challenge: APO ASSP assumes shortfall quantities are always on back order and can be delivered subsequently (i.e., there is no case of lost sales). This was true for the company’s tobacco business in which the company had almost a monopoly in the market. The distributors used to inflate the next order quantity with the additional shortfall quantity of the last order (if any). However, this was not entirely true for the company’s packaged foods and fast-moving consumer goods businesses in which any shortfall might mean loss of sales for the company as the customers picked up a competitor’s product. For this reason, the company introduced a manual control known as safety stock band. 

Technical challenge: Getting data on supply uncertainty was another challenge. The standard lead time of every supplier was maintained in the company’s ECC system. However, the actual lead time (i.e., the difference between the date the purchase order [or delivery schedule] was sent to the supplier and the date the material was received from the supplier) was never recorded in the system.

For certain items, the individual purchaser who was handling the particular item maintained this data in a separate Excel file. Supply variability was calculated from that Excel file. For other items for which no data was available, a reasonable assumption was made (for example, supply variability of 40 percent or 50 percent). During implementation, the company put a system in place to record the actual supply variability data for the future. Unavailability of data on supply variability is quite common for many companies.

Technical challenge: High forecast inaccuracy for certain products was an issue. Certain products in the company’s portfolio had a high forecast inaccuracy owing to reasons such as high month-to-month variation in sales, no properly cleaned history, or effects of promotion. APO ASSP usually proposed higher safety stock for these items as safety stock quantity calculation is directly proportional to forecast inaccuracy percentage. However, maintaining this much safety stock was not practical, keeping the company’s constraint on inventory budget in mind. This is another reason the company introduced a manual control known as safety stock band.

Technical challenge: A background job of a safety stock planning run took a long time, as it used to run for large product location combinations (i.e., more than 10,000 products and around 1,500 locations). The company had to do many iterations with its selection IDs to find the optimum runtime. 

The Concept of Safety Stock Band 

While the safety stock planning run used to provide optimal safety stock recommendations for most products, one of the challenges that the company had was that for certain products it used to give either very high or very low safety stock. Because the company was in business for many years, these numbers sometime looked absurd to company executives. This used to happen for many reasons, such as poor forecast accuracy for these products and sufficient history not being available. That’s why the company initially introduced the concept of a safety stock band.

Under a safety stock band, for each category, a beta service level with minimum and maximum safety stock bands were defined. For example, for a particular category such as tobacco, for a large seller, the beta service level can be 99.9 percent lower and a higher band of safety stock days can be two and six days. For any product under this category, if the background safety stock job gives the required safety stock days within this high and low band, system-generated safety stock is accepted. However, if the system-generated safety stock number is lower or higher than this defined band, then a macro corrects the value and brings it to the same value as the higher or lower band — whichever is closer.

For example, if the safety stock calculated by the system is three days, it is kept as it is because it is within the band (the band is a higher range of six days and a lower range of two days). However, if the safety stock value calculated by the system for any product in this category is nine days (by experience this looks to be too high), the macro corrects it to six days, which is the highest band value.

Table 1 is an example of how the company defined a service level with higher and lower band values for various categories of products in its portfolio. This was an interim solution. Before go-live, the company had to adopt this because even with several months of simulation, its statistical forecast results were not good for some stock-keeping units (SKUs). In my experience, at many companies, even when they have good data and the best forecast model selection effort, there is still no guarantee that statistical forecast numbers provided by the system for some SKUs are close to reality (i.e., actual sales). Often the system needs several months before it starts providing acceptable results.

The company also implemented a process of regularly reviewing these band values and, if necessary, making an adjustment. Introduction of the safety stock band was an innovative approach as it used a mix of a scientific approach of mathematically calculating the optimal safety stock level, but at the same time validating this with the planner’s experience in case the system-generated numbers are not logical because of inaccuracy of data.

Over time, and with better use of the APO system and gathering of more data, the system-generated safety stock numbers became more realistic, and the company became more confident in the APO system. After a few months of implementation, once the project became stabilized for many categories, the company removed the band concept and system-generated safety stock numbers were considered sacrosanct. 

Implementation of APO ASSP for this project needed master data setup and configuration steps. While most of it was standard APO, a few custom macros for writing the rules of safety stock bands were used. Let’s first start with master data setup. 

Master data settings maintained for APO ASSP for this project are shown in Figure 1. To reach this screen, execute product master transaction code /SAPAPO/MAT1 and follow menu path APO > Master Data > Product > Lot size tab. The safety stock method (the $$tk method field) maintained was BT. BT stands for beta service level and reorder cycle method. As explained earlier, the beta service level stands for quantity driven and the reorder cycle method was used as the company’s warehouses were replenishing its distribution centers based on the reorder cycle. In the service level (%) field, a service level value required for the location product combination was maintained. In this case for packaged foods, the service level maintained was 95.0.

Figure 1

Master data maintained in the APO product master for ASSP

The reorder cycle period in days is entered in the Target Days’ Supply field in the Lot size tab of the product master. The reorder cycle describes the usual number of periods between two reorder planning runs. A value of 5.00 is entered here (i.e., the length of the reorder cycle is five days).

The safety stock band for each product is maintained in the APO product master as an additional field. To access the APO product master, execute transaction code /SAPAPO/MAT1 and follow menu path APO > Master Data > Product > Lot size tab. This product master is shown in Figure 2.

Figure 2

The safety band maintained in the product master

As shown in Figure 3, the next step was to review forecast history and actual history in the APO demand planning book. To access the APO Interactive Demand Planning book, execute transaction code /SAPAPO/SDP94 and follow menu path APO > Demand Planning > Planning > Interactive Demand Planning. From these two key figures, a forecast error percentage is calculated. This parameter is important in safety stock calculation because if the calculated forecast error percentage is 10, the system adjusts 10 percent more safety stock.  

Figure 3

History for calculating safety stock

The APO Safety Stock Planning background job for generating safety stock can be accessed by executing transaction code /SAPAPO/AC08 and following menu path APO > Planning > Safety Stock Planning in the background. The next safety stock background job was set up. This job was run for a selection profile that included all the product location combinations for which ASSP was in scope. 

APO provides two time-phased timeseries key figures: Safety Days Supply and Safety Stock (planned). Safety stock data book view of planning book (9ASNP_SSP) has these two key figures. Figure 4 shows some of the standard safety stock macros.  

Figure 4

Safety stock macros

SAFETY_CALC macro is used in safety stock background jobs for safety stock calculation. For setting up safety stock background jobs, here are few important tips:

1. From SCM 5.0, it is possible to set up a safety stock planning profile. This profile can be accessed using menu path APO > SNP > Environment > Current Settings -> Profiles and by using the transaction code /n/sapapo/snp_sft_prof
2. The BAdi /n/sapapo/SNP_ADV_SFT allows implementation of safety stock formula (CALC_SAFETY_STOCK), load a safety stock planning profile per location product (GET_PROFILE), provide forecast error for demand (GET_FORECAST_ERROR) and provide replenishment lead time (GET_LEADTIME)
3. As shown in Figure 5, the ASSP program does not have any parallel processing profile option (unlike other APO SNP jobs such as optimizer run that do have a parallel processing profile option). Therefore, if it is being run for large data volume, it needs to run multiple parallel jobs with different data selection. Designing the right selection IDs is important for running this job – otherwise, the job may have a very long run time.

Figure 5

The safety stock background job

Figure 6 shows the result after execution of the ASSP run and the run log. These results are reviewed now. If the safety stock calculated for a particular product is within the safety band, then the value remains as it is and the key figure for safety stock planning SAFETY is populated in the main APO planning book. However, if the value is higher or lower than the defined band values, then the background job runs a macro that changes the safety stock values to the upper or lower limit (as the case may be) and then populates the value to the SAFETY key figure. 

Figure 6

The safety stock run

Implementing APO ASSP helped the company reduce stock-out cases by 16 percent and lower its overall inventory of finished goods in its supply chain network by four percent over a period of 18 months post implementation. 

SmartOps EIO optimizes inventory for different nodes of an enterprise organization’s supply chain. The typical enterprise organization can be a company that deals with physical inventory, such as manufacturing, distribution, or retail, and different nodes of its supply chain can be locations such as a factory, a warehouse, or a distribution center. EIO ensures the desired product availability (as per a defined service level), while significantly reducing inventory and working capital. Although optimizing inventory, EIO can consider multiple constraints such as storage constraint at a warehouse, lot size for procurement and transportation, or lead time at different legs of the supply chain.

SmartOps has many applications, but I focus on the inventory optimization application of SmartOps known as Multistage Inventory Planning and Optimization (MIPO).

Most of the SmartOps users use ECC or APO applications as their primary transaction or planning systems. If SmartOps MIPO is implemented with ECC, it determines the inventory targets that are sent to the ECC materials management (MM) module. Companies that use APO use MIPO to determine optimal inventory days. These inventory targets are sent to the SAP Supply Network Planning (SNP) module for overall supply chain optimization. The application landscape also typically includes SAP Business Warehouse (BW) or BusinessObjects for all related inventory performance reporting.

A large food company faced a challenge of high inventory in its supply chain. The company also had a challenge with its frequently promoted products that often had a stock-out. Another challenge for the company had been high level of obsolescence. Being in the food industry, most of its products had expiration (i.e., use before) dates after which they need to be discarded. Wrong placement of inventory often caused stock to sit in a distribution center or factory for a long time and eventually to not be sold to the customer before the expiration date. The company wanted to deploy a specialized application for inventory optimization to solve the following problems:

• Scientifically decide different components of inventory (i.e., the number of days of stock the company needs as safety stock, cycle stock, pipeline stock etc.): Safety stock means the stock needed to hedge against risk and uncertainty. Cycle stock is needed to meet current demand until the next order is placed. Pipeline stock is the stock in transit between two physical locations.
• Decide overall target inventory holding days in the supply chain: From a budgeting perspective, the company wanted to decide how many days of overall inventory it needed to hold in the supply chain, taking all stocking points together (factory, warehouse, distributor). 
• Decide optimal placement of stock: After the company decided on the overall target of inventory holding days in the supply chain, the next objective was to decide where it should hold how many days of inventory (i.e., how many days of stock at the factory, what is the optimal number of days of stock in the warehouse, and in the distribution center). This is again decided based on service level requirement (i.e., where it made sense to hold the stock for a particular SKU to maintain a certain service level and which reduced the overall inventory carrying cost).  

SmartOps as a solution was selected for a number of reasons, including the number of reference customers in a similar industry, the number of successful implementations in a similar geography, and the number of successful demonstrations that convinced the business that the solution could meet the requirements for them.

Solution Architecture and Process Flow 

Figure 7 diagrams the high-level solution architecture for the project. The company used SmartOps MIPO  for inventory optimization, SAP Demand Planning, and SAP Supply Network Planning (SNP) for overall supply chain planning and ECC for supply chain execution.

Figure 7

Solution architecture with SmartOps, APO, and ECC

The overall process flow works as follows:

• SAP Demand Planning does a weekly forecast of end product demand, and this forecast is sent to both MIPO and SNP. SAP Demand Planning also sends historical data to MIPO. MIPO uses this forecast and history data for demand uncertainty calculation. SNP uses the forecast for downstream supply planning.
• Master data from ECC (such as plants or locations) and APO (such as transportation lanes with means of transport and duration or holding cost for inventories) move to MIPO. Required transaction data from ECC and APO (such as process orders, vendor purchase orders, replenishment orders, and actual sales) also move to MIPO. Master and transaction data from ECC and APO are first stored in a staging database from where it is moved to APO.

SmartOps MIPO provides safety stock quantities per week that are loaded into SAP SNP planning book as a safety stock (planned) key figure. 

For modeling the inventory optimization solution, a number of inputs were necessary. A few of them were static inputs for a location, such as target service level, cost of holding inventory, storage capacity, or lead time of replenishment from the upstream location. A few of them are dynamic (or time varying) inputs such as forecast mean and standard deviation that is calculated from the data provided to the system and goes into the calculation of inventory quantity. On-hand inventory position and planned receipts expected are also input into the system.

As an output, SmartOps delivered a set of static and time-varying outputs. An example of static output can be calculated service levels at different nodes of the supply chain. Although the overall service level to be maintained at the customer level is an input provided to the application, the system determined the internal service levels at different nodes of the supply chain. The system also delivered a set of time-varying outputs such as number of days of safety stock, cycle stock, prebuild stock, and merchandising stocks to be maintained along with total pipeline stock. The target inventory position is also an output from the system.

Lessons Learned from This Implementation 

Here are a few of the key lessons learned from this implementation:

• SmartOps supply chain structure (i.e., different nodes of the supply chain and their connections) can be set up using APO transportation lane master data. APO provides a standard BAPI (BAPI_TRLSRVAPS_REQUESTLIST2) to extract this information from APO.
• SmartOps MIPO implementation needs a basic setup of SmartOps Demand Intelligence Module (DIM) that includes the Demand Intelligence processor. This runs during the preprocessing phase of MIPO optimization. This process uses historical forecasts and historical sales data to determine demand standard deviation by item, location, and period at all customer-facing stocking points for periods in the MIPO data horizon.
• SmartOps needs actual distribution lead time (from factory to distribution center or between distribution centers) for calculating optimal inventory quantities. This information is sometimes difficult to get as often it is not recorded in the ECC system that records the planned lead times. In this project, this data was consolidated from multiple Excel files and sent to MIPO using SAP Business Warehouse.
• Another input in which there were challenges in the project was getting data on the ranking of the material inside the sales organization. SmartOps needs this data as input. A separate mapping table was created in ECC to get this data and send it to MIPO.

• The safety stock method needs to be MB. MB stands for manual time dependent safety stock planning. MB allows you to maintain data directly in the interactive planning table of SNP. For products for which SmartOps calculates the safety stock data, this is the method to be used. This method ensures that APO extended safety stock planning does not do planning for these items. It also ensures that SmartOps calculated safety stock numbers are populated in APO SNP planning tables in APO for product-location combinations with data provided by SmartOps. There is an SAP BW transformation carried out to populate the safety stock method as MB in a custom SAP BW InfoObject ZMATPLANT. Further, there is a master data enhancement that is used to check safety stock method by BAPI BAPI_PRDSRVAPS_GETLIST2 and then update with BAPI_PRDSRVAPS_SAVEMULTI2 if the value is different from MB.

An Overview of ECC Dynamic Stock Planning 

ECC dynamic stock planning is a procedure that dynamically changes the planned or required stock quantity based on a stock-on-hand situation. During every material requirement planning (MRP) run, the system checks whether the available quantity is below the minimum stock level. If stock falls below the minimum stock level, the system creates a procurement proposal and calculates a procurement quantity so that the available quantity is replenished up to the target stock level. If the available quantity is above the target or maximum stock level, then the system does not create any procurement proposal.

Therefore, in ECC dynamic stock planning, there are three important stock levels based on which the system determines whether it needs to create a procurement proposal or not and the quantity of the procurement proposal. These three stock levels are minimum stock level, maximum stock level, and target stock level. The aim of dynamic stock planning is always to maintain target stock level in the supply chain. The dynamic safety stock adapts automatically to the changed requirements.

Dynamic safety stock is calculated by this formula:

DSS (dynamic safety stock) = average daily requirement * range of coverage

Average daily requirement is calculated by this formula:

(Requirements in the specified periods)/(number of days in the total period length)

Similarities and Differences Between SAP Inventory Planning Applications

In this section I compare and contrast functionalities of various SAP inventory planning applications.

Similarities Between APO ASSP and SmartOps MIPO 

There are many similarities between the way the APO ASSP and SmartOps MIPO applications operate, including the following examples:

• Both consider demand and supply variability for calculating safety stock.
• The customer service level is an important input for safety stock calculation for both the applications.
• Both applications calculate safety stock levels at a particular location that can be taken as an input for downstream planning. For example, APO safety stock planning fixes the safety stock requirement at a location. This location is considered during the next planning cycle in APO in SAP Supply Network Planning. Similarly, MIPO fixes safety stock requirements at a location that can be considered in further downstream planning in ECC MRP or APO SNP.

Differences Between APO ASSP and SmartOps MIPO 

Following are a few major differences between APO ASSP and SmartOps MIPO:

• MIPO supports multi-echelon inventory optimization, whereas APO safety stock planning does not support this type of inventory optimization. This means MIPO can simultaneously plan for optimal inventory at various stocking locations for every finished product and raw material component in a multitier distribution or manufacturing supply chain. For APO, the safety stock planning always is one location at a time (i.e., for planning multiple nodes in the network, the planning is always sequential, not simultaneous).
• MIPO can plan inventory strategy across the supply chain (i.e., whether it makes sense to keep more stock at a distribution center and less at factory or if it makes more sense to carry more at the factory level and less at the distribution center to meet an overall service level for the supply chain). This planning helps in keeping optimal stock at a location and in keeping the overall supply chain objective in mind, not only the target service level for that particular location. APO cannot suggest whether it makes sense to keep more stock at a factory and less at a warehouse or more stock at factory and less at warehouse. This is because an APO safety stock planning run is location-wise and keeps a location service level target in mind. The service level required for a location needs to be defined by a user as an input. This is the place where the MIPO engine is different in that the service level required at the end node only needs to be defined by the user. The service level for all internal nodes is calculated by the system automatically, and depending on the service level at the final node, the service level requirements at internal nodes can be different.
• For APO safety stock planning, the service level for a location needs to be given by the planner and safety stock calculation occurs based on that. For example, if you want to do a safety stock calculation at a distribution center, factory, and warehouse, you need to provide service level inputs for all these locations separately (for example, 99.9 percent each at every level). For MIPO, the service level for the overall supply chain is given as an input. However, all internal service levels are calculated by the system itself. For example, the overall supply chain service level defined can be 99.9 percent and that’s the service level expected at the customer-facing distribution center. The MIPO engine may calculate that to maintain this service level at the distribution center, the internal optimal service level required at the warehouse can be 99 percent and at the factory it can be even lower, at 97 percent. The engine also may suggest that it makes more sense to carry more stock at a factory in this case than at the distribution center to reduce the overall inventory carrying cost for the supply chain.  

The main difference between ECC DSP and APO ASSP is that unlike APO ASSP, ECC DSP can not consider service level and demand supply variability. Stock planning in ECC DSP is solely based on three stock levels (minimum, maximum, and target). In APO ASSP, the required service level is a manual input given to the system.