Supply Chain Management with SAP APO¿

For a long time the focus in logistics projects has been on the optimisation of certain logistic functions – e.g. the optimisation of the transportation and distribution structure – usually with small concern to the adjacent processes and to the complete product portfolio. The supply chain man agement approach differs from this by grouping products with similar properties (from a logistics point of view) to a supply chain and taking all the processes – in SCOR terminology: plan, source, make, deliver – per supply chain into account. Figure 1.1 visualises the different approaches to structure the logistics processes within a company.

The main differentiator for supply chains is the production strategy, that is if a product is created according to a specific customer demand (make to order) or anonymously (make to stock). Other criteria for separate supply chains might be different customer groups or product properties as the shelf life or the value.

The advantage of the supply chain approach is that the processes are examined from the point of view how they contribute to the targets of the supply chain management (e.g. low operating costs, flexibility and responsiveness or delivery performance). Therefore the integration between different logistical functions, for instance sales planning and production planning, is stronger within the focus of the supply chain management approach. In many cases the transparency between different logistical functions and between planning and execution offers already a significant potential for optimisation. The next step is to extend the supply chain approach beyond the limits of a single company and regard the entire value chain from the raw material to the finished product for the consumer. In this area the collaborative processes gain increasing importance.

The focus of this book is the SCM processes within a company. Though the possibilities of collaboration with customers and suppliers and the according processes are mentioned as well, the focus is on the SCM within a company, because to our experience in this area there is still the biggest potential for most companies. From a company’s point of view a supply chain usually consists of

There might be several levels for distribution (e.g. regional and local DCs) or several levels of production, if one plant produces the input material for another plant. Another characteristic of a supply chain is whether sourcing alternatives exist. Multiple sourcing is common for suppliers, and in many cases alternatives exist for production and distribution as well. Common variants in the distribution are direct shipments from the plant to the customer (instead from the local DC) depending on the order size. The most common supply chain processes cover the areas

SAP APO™ consists technically of three parts: the database, the SAP BI™ data mart and the live cache. The SAP BI™ data mart consists of info cubes. The live cache is basically a huge main memory where the planning and the scheduling relevant data are kept to increase the performance for complex calculations. Though there is technically only one live cache per installation, the data is stored in three different ways depending on the application:

We will refer to the according parts of the live cache as time series live cache, order live cache and ATP time series live cache.

Demand planning uses much of the SAP BI™ functionality and relies on the info cubes as data interface to any other system – SAP ERP™, SAP SEM™ or flat file. Therefore the historical data is always persistent in an info cube. For processing the data is written into the time series live cache. SNP and PP/DS use mainly the order live cache, though SNP is able to access the time series live cache as well, since there are many structural similarities between DP and SNP. ATP at last relies only on the ATP time series live cache. This way of data storage implies a certain redundancy, because orders are stored both in the order live cache and in the ATP time series live cache. The data model is however quite different, and the redundant data storage enables better performance for the applications. TP/VS finally uses the order live cache to reference other orders. Figure 3.1 shows how the SAP APO™ modules use the live cache and the data integration for transactional data from SAP ERP™ to SAP APO™.

The result of the demand planning process is the establishment of independent requirements which will trigger the planning activities as distribution, production and procurement planning. Usually a sales fore cast is the key input to the demand plan. This sales forecast is consolidated and checked regarding plausibility, probably checked against a statistical forecast and corrected according to the experience of the planner before releasing it for the subsequent planning steps. Figure 4.1 shows this process for a very simple supply chain with global demand planning and single-sourcing local production planning:

The monitoring of the forecast accuracy and a feasibility check against the planning constraints (e.g. capacity) are further common process steps. Depending on the business requirements there might be many others.

The classical production strategies are make-to-stock and make-to-order, which determine the planning to great extent. In a typical make-to-stock environment planning is triggered only by independent requirements and therefore demand planning has a great significance. Sales orders provide merely information to monitor whether the forecasted quantities are appropriate. Typical industries where make-to-stock strategy is applied are commodities and consumer goods, since the same products are usually sold to many customers and the lead time of the sales orders is usually very short. The order life cycle for make-to-stock is shown in figure 5.1. There is always a balanced situation shown as a result of a production planning run.

The initial situation – the demand of the sales order exceeds the forecast – is a result of inappropriate planning and should not occur. This situation is chosen for this example because it helps to clarify that sales orders are not relevant for production planning in a make-to-stock environment. The sales orders are excluded from pegging as well (and the sales order receives the flag ‘.pegging irrelevant’.).

The forecast is reduced by goods issue according to the forecast consump tion settings in the product master.

Order fulfilment contains the processes related to the customer from order taking, availability check and confirmation to the shipment to the customer. Figure 6.1 shows the process chain for order fulfilment processes.

The sales order entry is performed in SAP ERP™ either manually (i.e. for order per telephone) or per EDI, but the ATP check is carried out in SAP APO™ during the sales order entry. Backorder processing is performed in SAP ERP™ – usually as a background job – and the results are sent as updates to the sales order to SAP ERP™. The deliveries are created in SAP ERP™ – usually as a background job as well – several times per day. Again the ATP check is performed in SAP APO™. The transportation planning is performed in SAP APO™ based on the deliveries and sends shipments back to SAP ERP™.

There is an alternative way to perform transportation planning first based on sales orders and trigger the delivery creation from SAP APO™, but this has disadvantages in the flexibility if the ATP check turns out to be unsuccessful.

The main object for the order fulfilment is the sales order and the main functionality from a logistical point of view is the ATP check. The ATP check is performed during sales order entry, backorder processing and delivery processing to determine the available quantity. The criteria for the ATP check for the delivery is usually more restrictive than for the sales order since it is closer to execution. The order life cycle of a sales order is displayed in figure 6.2:

The sales order is the key document in the sales process. The sales order is created in SAP ERP™, and only the transportation and shipment scheduling and the ATP check are performed in SAP APO™. Other tasks during the sales order entry process that are performed on SAP ERP™-side is pricing and credit limit check. Figure 7.1 shows this process between SAP ERP™ and SAP APO™:

The decision whether the ATP check is carried out in SAP ERP™ or in SAP APO™ is made per material and plant by activation of the appropriate CIF model (see chapter 25).

Though the ATP check is usually triggered by SAP ERP™ (with the exception of backorder processing, see section 7.9), it is possible to carry out a simulative ATP check within SAP APO™ with the transaction /SAPAPO/AC04. The purpose of this simulation is to check the ATP settings which can be rather complex. The ATP check in SAP APO™ might be triggered as well from SAP CRM™ or from a BAPI. For the use of the BAPI from a legacy system there are however severe limitations.

Transportation planning is the second step for order fulfilment from a planning point of view. It is either executed in batch mode several times per day after creating the deliveries or in an interactive mode by the transportation planners. Both delivery creation and transport planning are usually responsibilities of the warehouse as explained in chapter 6, though there might be dedicated transportation planners for the latter task. The first step towards execution is the creation of the delivery. At this point in time an ATP check is carried out again – usually with a much more restricted scope (i.e. stock only). Optionally deliveries (and other documents as stock transfer orders and returns) might be grouped to a shipment to make the execution of the shipping easier. The objective of transportation planning is to group the deliveries into shipments. The challenge in creating the shipments is to minimise the effort – i.e. the number of the shipments and the length of the shipments – while taking

into consideration. To solve this problem TP/VS offers an optimisation tool. The result of the transportation planning is the creation of a shipment in SAP APO™. The shipment is a document which has a link to the included documents but does not replace them. Accordingly a shipment is not relevant for requirements planning and does not show up in the product view.

In many industries – e.g. consumer goods or chemicals – the same products are stored in different warehouses to reduce delivery times and optimise transports. In this case there is a supply network on finished product level and planning is required to supply the warehouses and to determine the appropriate safety stock levels.

Distribution planning between the plants and warehouses gains increasing importance since many companies change their processes from non co-ordinated local inventory management to a global inventory management in order to reduce their inventories. By concentrating safety stocks from multiple local DCs to a central DC and changing the responsibility for the inventories at the local warehouses combined with service level agreements and a VMI (vendor managed inventory) process for the local warehouses, significant stock reductions are achieved. The focus for distri17 bution and supply chain planning is on make-to-stock production.

The supply planning for the warehouses has a more requirements planning oriented part, where the focus lies to propagate the demands of the supply network to the procuring plant in order to trigger the production or the external procurement, and a more execution oriented part, where the focus is to make the best of the given supply and demand situation – which often differs more or less from the initially planned situation. The latter is accordingly a short term task.

In traditional logistics concepts distribution planning and production planning are carried out completely independent of each other. Though the idea of SCM implies no separation of the planning according to functions, in many cases, especially when single sourcing is given, a hierarchical step-by-step approach – first distribution planning and afterwards production planning – is sufficient.

Depending on the supply chain this hierarchical approach might not be appropriate to exhaust the optimisation potential. This is mainly the case in multi-sourcing environments with multiple production sites where sourcing decisions are made according to the available capacity. The more the bottleneck is located at the beginning of the material flow, the more complex become the sourcing decisions and the decisions where stock is kept (probably even at semi-finished stage).

The example in figure 10.1 contains a planning problem that might illustrate the potential for integrated distribution and production planning. The supply chain contains two DCs and two plants, where DC XXW1 delivers GIN and DC XXW2 GIN and KORN. GIN is produced in both plants XX01 and XX02, KORN is only produced in plant XX02. The key component for both products is ALC, which is produced only in plant XX01 and is either processed there or sent to plant XX02. The DC XXW1 is supplied from both plants.

The supply chain network is defined by locations and transportation lanes. The master data in this chapter focuses on locations, transportation lanes, calendars and transport resources. Table 11.1 provides an overview about the relevant master data for distribution planning.

Within the some of the master data some entries are mandatory for distribution planning. These entries listed in table 11.2.

The transportation lane defines the material flow between locations and is the prerequisite for any stock transfer. It is maintained with the transaction /SAPAPO/SCC_TL1 and contains the three views ‘product’, ‘means of transport’ and ‘product specific means of transport’ as shown in figure 11.1. Make sure to press enter before saving to prevent a loss of data.

In the ‘product’-view the transportation lane is restricted regarding the products and the lot sizes. It is even possible to lock a transportation lane, if it should temporarily not be used for distribution planning.

If the supply chain behaves exactly as planned – i.e. neither changes in the demand nor unpredicted deviations of the supply happen – deployment is not necessary. Since we are living in an imperfect world, both demand and supply will usually differ from the planned quantities when it comes to execution. If the demand exceeds the supply, it has to be decided which demands – in case of the supply chain network: which locations – will be covered and to what extent. This is exactly the scope of deployment.

Depending on the supply chain structure these decisions are more or less complex. In a hierarchical, single sourcing structure a simple fair share rule is sufficient. In a multi-sourcing structure however the decisions become more complex. This case is dealt with later on in this chapter concerning deployment optimisation.

The basic idea of deployment is to convert planned stock transfers into confirmed stock transfers (confirmed distribution requirements resp. receipts) according to the available supplies, the demands, the deployment strategy and the fair share rule. The available supplies are defined by the difference between the ATD (available-to-deploy) relevant receipts and issues. The ATD-receipts and the ATD-issues are category groups which are assigned to the location master and/or to the locationproduct master. If an entry exists for the locationproduct it is used, else the entry from the location is taken. Stock usually contributes to the ATD-receipts, whether other receipt elements as production orders or purchase orders are included in the ATD-receipts as well depends on the business scenario. Regarding the ATD-issues, deliveries and confirmed distribution requirements should be included in any case. If a location serves for the supply of warehouses as well as for the direct shipment to customers, an important issue is the question whether (third party) sales orders are included into the ATP-issues category group or not. Including sales orders means that they are prioritised over distribution requirements, since the available quantity for distribution is reduced by the confirmed quantity of the sales orders. On the other hand, an exclusion of the sales orders means that the total available quantity is used for distribution, i.e. sales orders have the lowest priority. Depending on the categories in the check mode for deliveries for the ATP check (cf. chapter 7), this leads either to a lower prioritisation of the sales orders or to conflicts because quantities are planned one way in deployment but handled ‘first come first serve’ for delivery. A workaround to handle both distribution requirements and sales orders with the same priority is described later on. Having the ATD-quantity defined, it is distributed according to the deployment settings defined in the locationproduct master. Safety stock is ignored by deployment (at least by the deployment heuristic). Since safety stock is modelled in SAP APO™ as a demand and not a supply element, this means that safety stock settings do not have any impact on the available quantity.

From the process point of view the production planning scenario consists mainly of the production planning itself, i.e. the creation of planned orders resp. purchase requisitions for the demand, the detailed scheduling to create a sequence for the orders which is sufficiently feasible (usually in the shortterm) and the execution of the production order. In many cases it is desired to have at least a rough feasibility check of the production plan in the mid-term as well. Figure 13.1 shows the process chain for a make-to-stock production without any distribution planning, starting with a forecast from Demand Planning.

Sometimes there is an organisational separation between production planning – i.e. the determination of the quantities which have to be produced (and externally procured) – and the detailed scheduling, where the sequence of the orders and operations is determined. In other cases – especially if the scheduling tasks are more complicated – both processes are performed by the same organisation. The detailed scheduling is usually only performed for the short term horizon. Traditionally both roles – production planning and scheduling – are limited to the plant level. If a supply chain contains alternative production possibilities the process becomes more complex and usually an integrated distribution and production planning is required – at least for the rough-cut plan, cf. chapters 10 and 14.

The application for rough-cut production planning in SAP APO™ is SNP. The basic properties of SNP – e.g. the bucket-oriented planning and the planning book – are described in chapter 9. The objectives of rough-cut production planning in general are

Within SNP the three applications SNP heuristic, SNP optimisation and CTM (with SNP master data) exist. The key question for deciding which one to apply is whether the information about the capacity load and some basic manual capacity levelling possibilities is sufficient or whether finite planning is really required. In the first case the SNP heuristic should be the appropriate application, else either SNP optimisation or CTM have to be considered. Each of these have a different approach to production planning including the scheduling of the orders. The common properties are described in the following.

The preferred tool to visualise the SNP results and perform interactive planning is the SNP planning book as described in section 9.5. Figure 14.1 shows the production planning specific part of the SNP planning book. Note that the SNP planning horizon which is blocked for SNP planning is highlighted for the key figure ‘production (planned)’.

The respective key figures and the according categories are listed in table 14.1.

PP/DS focuses on the detailed production planning and scheduling and is therefore mainly concerned with planned orders and production orders. Creating an order contains the steps of calculating the component quantities and the operation durations, and scheduling the operations in the live cache. The prerequisites to create an order are the master data for the products, the resources and the PPMs. In contrast to SAP ERP™ planned orders and production orders (and – if PP-PI is used on SAP ERP™ side – process orders) are not different objects but one object with different categories. Therefore no change in the structure happens when the order type changes.

The order life cycle of a planned order is the conversion to a production order resp. a process order (triggered from SAP APO™ or in SAP ERP™), the release of the production order in SAP ERP™ and its confirmation in SAP ERP™, as shown in figure 15.1.

The order is deleted in SAP APO™ as soon as it is technically completed.

There is no order history in SAP APO™.

The properties of an SAP APO™ order are its category, its fixing indicators, its scheduling status and other flags reflecting the order status in SAP ERP™. Tables 15.1 and 15.2 provide an overview about the order statuses for planned and production orders.

Usually ATP is looking at existing or planned receipts. In a make-to-order environment there are no receipts per definition. The idea of an ATP check is therefore not to check whether there are receipts for the requested product but whether there is enough available capacity to produce the product and/or whether the required components are available. In SAP APO™ there are mainly three approaches to tackle these tasks, depending on the business requirements:

17 Figure 16.1 provides an overview about the approaches and their properties.

If neither capacity nor components are a bottleneck, it might be appropriate to use a checking horizon for the ATP check instead.

The planning board is the central tool for detailed scheduling where operations, orders and the resource load are displayed. Figure 17.1 shows a planning board configuration with the resource chart (Gantt chart) and the order chart. Other available charts are e.g. the operation chart and the resource load chart. Charts are displayed on request using the menu path ‘extras’, if the according flag is set in the planning table profile. The planning board is called with the transaction /SAPAPO/CDPS0.

The customising of the planning board offers many configuration possibilities. In the example above production orders and planned orders are displayed in a different colour, and properties as fixing and de-allocation are displayed with coloured bars in the middle of the respective object. Generally it is possible to change the layout of the graphical object depending on properties of the according operation, order, product or resource. The information, which is displayed within the objects, is customised as well. By placing the mouse on the object, the information is enlarged as a banner.

The conversion of planned orders into production orders is either triggered in SAP APO™ or in SAP ERP™. The conversion itself is in any case performed in SAP ERP™. To trigger the order conversion in SAP APO™, the two alternatives exits: Either with the transaction /SAPAPO/RRP7 or by setting the conversion indicator interactively for the individual order.

Since the planned order and the production order are different objects in SAP ERP™, at the time of the order conversion the planned order is deleted in SAP ERP™ and a production order is created, including the BOM explosion, the explosion of the routing and a scheduling of each operation. If the conversion is triggered in SAP ERP™, simply the information about the deletion of the planned order and the creation of the production order is transferred, so that the scheduling of the planned order is lost, figure 18.1.

Triggering the order conversion from SAP APO™ has the advantage that the connection between the deleted planned order and the new production order is considered, so that the production order is matched with the planned order and the operation dates are kept as shown in figure 18.2.

Alternative resources can be modelled either as alternative modes within one PPM resp. PDS or as alternative PPM resp. PDS. Since the selection of the plan takes place during production planning and not in scheduling, changes of the plan in scheduling are not supported by the scheduling applications but have to be performed interactively. Therefore alternative resources should be modelled as alternative modes if the resource selection is supposed to take place during scheduling.

If alternative resources are modelled using alternative PPM resp. PDS (i.e. alternative production versions), the possibilities to change the resources in PP/DS are limited. The advantages and disadvantages resp. the properties of the different ways of modelling alternative resources – either using alternative modes within one plan or using alternative plans with only one mode – are listed in table 19.1.

The focus for this book is on operative procurement and not on strategic procurement. Strategic procurement selects the suppliers and negotiates the conditions and quantities. As a result a contract or a scheduling agreement might arise, and often there are costs of scale to be calculated. Operative procurement on the other hand is usually carried out by the planner and allows to choose between alternative suppliers.

Since sometimes components do have a long lead time, their procurement has to be triggered quite early. Another question is triggering procurement based on a feasible plan to save storage costs or to have the components early enough in place, if the production must take place in advance.

The idea of subcontracting is to outsource production steps. Differing from normal procurement, the subcontractor receives the required components from the customer, processes those and sends the new product back to the customer. Examples for subcontracting are products with irregular demand (e.g. displays resp. kits for promotions in the consumer products industry), production steps which require costly equipment or specialised knowledge (e.g. hardening or electroplating) or production steps with high manual efforts, which can be performed cheaper in countries with a lower wage standard.

Therefore the subcontracting process contains the procurement of an assembled (or otherwise produced) product from the subcontractor and the supply of the required components to the subcontractor. To model this, a purchase requisition resp. purchase order for subcontracting causes a demand for the components.

In some cases the components for the subcontractor are not produced by the customer but externally procured. In this case it might be favourable to send the component immediately from the supplier to the subcontractor. Another variant is a multi-level subcontracting, when the component for the subcontractor is produced by another subcontractor. Figure 21.1 shows the material flow for the normal subcontracting process and the two process variants.

The subcontracting is not supported by all applications in the same way. The limitations are listed at the end of the chapter..

Different kinds of stock are represented in SAP APO™ by different ATP categories. The standard stock categories in SAP APO™ are listed in table 22.1. Whether a stock category is relevant for planning or not depends on its order type in the live cache.

Note 487166 describes how to change the order type of a stock category, if it is required that certain stock categories change their relevance for planning.

The master for all material movements is SAP ERP™ and the inventory information is merely transferred to SAP APO™ (except for returns). This is a one way procedure. A major difference regarding the modelling of special stocks in SAP APO™ and SAP ERP™ is that these stocks are assigned to their physical location in SAP APO™, whereas in SAP ERP™ the ownership is decisive for the location assignment. Figure 22.1 visualises the assignment of the stocks in SAP APO™ and SAP ERP™.

The prerequisite to keep the subcontracting stock at the supplier location and the consignment stock at the customer location is that the according product masters exist in these locations. If this is not the case, they are assigned to the plant like in SAP ERP™.

There are two different cases for interchangeability: One is the discontinuation of a product or component and thus related to the product life cycle. Two options exist for the discontinuation, the simple forward interchangeability (i.e. product A is substituted by product B) and the full interchangeability (i.e. for a transition period A is substituted by B, but A may also substitute B). The other case is the form-fit-function class, where planning is performed only for one product, but any product within the form-fit-function class is technically identical. These form-fit-function classes are used to group inventory managed manufacturer parts. Though interchangeability is supported by all modules except TP/VS, there are restriction regarding the extent. Table 23.1 gives a rough classification about the interchangeability functionality per module.

Additional limitations apply as described in the following paragraphs – e.g. that interchangeability is not compatible with the use of product configuration and characteristic based planning. Another important restriction is that the interchangeability supports only a one-to-one relationship – i.e. no parallel or dependent discontinuation is possible (in contrast to SAP ERP™). In the following we concentrate on the discontinuation since this is the far more frequent case.

Alerts notify the planner about situations which require his attention or interference. A shortage situation caused by higher demand due to increased sales or caused by production shortfall due to increased scrap is a typical example where an alert (in this case of the type ‘order has undercoverage’) helps the planner to act as early as possible.

Alerts are displayed either in the alert monitor as a stand alone application or are integrated into other planning functionalities. The alert monitor is called with the transaction /SAPAPO/AMON1, figure 24.1:

The alert monitor is structured into two parts: In the area above the objects for the alerts are selected. In the alert view below only those alerts for the objects are shown, which had been selected in the alert profiles and for which current alerts exist. The navigation becomes clearer after regarding the structure of the alert monitor configuration (with the transaction /SAPAPO/AMON_SETTING) in figure 24.2:

The core interface (CIF) is the standard interface between SAP ERP™ and SAP APO™ for the order related applications PP/DS, SNP and ATP. On SAP ERP™ side the ‘plug-in’ has to be implemented to use the CIF, on SAP APO™ side it is always included. The CIF enables the integration of master data from SAP ERP™ to SAP APO™ (one way only) and the integration of transactional data both ways, from SAP ERP™ to SAP APO™ and from SAP APO™ to SAP ERP™. The basic idea of the integration is to write events for each planning relevant change – e.g. the creation of an order – and use these as trigger for the transfer. Technically the transfer is performed via qRFC. Which objects (i.e. planned orders, stock, …) are transferred is controlled by the integration models, which could be regarded as something like the master data of the CIF.

The usual way to load data into SAP APO™ for Demand Planning is using the info cubes. The info cube consists of the info objects ‘key figures’, ‘characteristics’ and ‘time characteristics’, figure 26.1. The info cube is therefore the analogue to the combination of the planning object structure and the planning area. In SAP APO™ the characteristics 9ALOCNO, 9AMATNR and 9AVERSION are mandatory for the info cube. The info area is merely an entity to group info cubes.

The central transaction for the SAP BI™ related structure set up is the administrator workbench (transaction RSA1), figure 26.2. Here the info objects, the info cubes and further entities which are described later in this chapter are defined.

The time characteristics, e.g. months, days or weeks (0CALMONTH, 0CALWEEK, 0CALDAY), are provided as standard objects and should not be changed. Own key figures and characteristics can be created if there is no appropriate standard object.

The processing of the objects in the administrator workbench requires in most cases the right mouse click. When creating an info cube, a pop-up asks whether you want to create an info cube for APO or BW. The right answer is BW.