Best Practice: SCM /APO Sizing

SCM / APO Sizing

Best Practice for Solution Management
Version Date: January 2004 The newest version of this Best Practice can always be obtained through the SAP Solution Manager Contents Applicability, Goals and Requirements.................................................................................................... 2 Best Practice Procedure and Verification................................................................................................ 3 Quick Sizer...................................................................................................................................... 3 liveCache Requirements................................................................................................................. 3 Optimizer Requirements ................................................................................................................. 3 Hardware Requirements................................................................................................................. 4 Best Practice Procedure ..................................................................................................................... 4 How to Use Quick Sizer.................................................................................................................. 4 Quick Sizer Results ........................................................................................................................ 6 CPU and Memory Requirements.................................................................................................... 7 Using SAPS for Sizing .................................................................................................................. 10 Verification......................................................................................................................................... 10 Plausibility Constraints on Input Data........................................................................................... 10 Further Information ................................................................................................................................ 12

2002 SAP AG

Best Practice: SCM /APO Sizing

Applicability, Goals and Requirements

A Best Practice may not be applicable in some situations. To ensure that this Best Practice is the one that is needed in your situation, consider the following goals and requirements.

Goal of Using this Best Practice

This Best Practice document includes all the information that you need to perform an SAP Advanced Planner and Optimizer (SAP APO) hardware sizing. The document provides information about: Handling the Quick Sizer Hardware requirements for an SAP APO system SAP APO sizing constraints The methods used to fill out the APO GoingLive Analysis Check Questionnaire

Staff and Skills Requirements

The persons who perform the sizing should be familiar with the mySAP Supply Chain Management (mySAP SCM) solution and the SAP APO component. To implement this Best Practice, two teams are required for the sizing project. These are: Technical Team The IT persons responsible for the hardware sizing and your hardware vendor should estimate the hardware requirements with the assistance of the Application Team. Application Team The Application Team delivers the input data for the Quick Sizer. They should already know the APO business processes and what your company wants to implement. The needed hardware is calculated using this information. The application members need to take care with the APO data. The input data for the Quick Sizer has various influences on the hardware sizing. Detailed information about the influences can be found in section CPU and Memory Requirements.

System Requirements
To perform the APO sizing, you need online access to SAP Service Marketplace, alias Quick Sizer (http://service.sap.com/quicksizer).

2002 SAP AG

Best Practice: SCM /APO Sizing

Best Practice Procedure and Verification

Quick Sizer
The SAP tool Quick Sizer can be found in SAP Service Marketplace, alias QuickSizer. Quick Sizer is a Web-based tool that enables you to perform the sizing quickly and easily. It has been developed by SAP in close cooperation with all platform partners and is free of charge. Quick Sizer provides only a guideline, because as mentioned in the disclaimer, it is based on a SAP standard application benchmark. More exact sizing is the responsibility of SAP's hardware partners. In the current release, Quick Sizer estimates the memory consumption and CPU requirements not only for liveCache but also for the application server(s) and the database for the modules Demand Planning (DP), SNP, GATP, and for CIF load. For CIF load, it even calculates the additional CPU load on a backend system. In addition, the Quick Sizer takes into account users who work in parallel during a planning run. The duration of a planning run in PP/DS depends strongly on the customizing, so liveCache only performs memory sizing. Quick Sizer does not calculate the CPU requirements for liveCache, application server, and database server, or the memory requirements for application and database server. However, Quick Sizer does size the liveCache memory consumption for each component. In the current release, for DP, only one planning area is taken into account, and for the components CTM, VMI, ND, and Automotive, database and application server hardware sizing are not available. Also, for Automotive, sizing for the rapid planning matrix is not available. In addition to the standard SAP components SAP instance and RDBMS, Quick Sizer deals with components such as liveCache and several optimizers.

liveCache Requirements
Up to SAP APO 2.0A, all APO modules except Demand Planning (DP) use liveCache. As of SAP APO 3.0A /3.10, all modules use liveCache. During the sizing process, you need to decide whether you can use a 32-bit operating system (OS) or you need to use a 64-bit OS for liveCache. This is because liveCache uses an 'in memory' concept and the address space is limited in a 32-bit OS. For liveCache, the only available 32-bit OS is Windows NT (Windows 2000), where at most 3 GB can be addressed by liveCache. Approximately 300 MB is needed by the liveCache kernel, user tasks, and so on. Therefore, 2.7 GB is left to be shared between data cache and heap memory. In a 64-bit environment, a maximum memory of 18.41018 byte (18.4 EB) can be addressed. This is more than enough for currently available hardware, and the only limit is that paging should be avoided. It is important to know in advance which operating system is required to handle the planned workload. A migration from an NT liveCache to a UNIX liveCache requires sufficient testing.

Optimizer Requirements
SAP APO modules SNP, CTM, PP/DS (DPS and SEQ optimizers), ND, and VSR use additional standalone programs called optimizers, some of which also communicate with liveCache. These programs provide sophisticated optimization algorithms. Some applications can be used without an optimizer. For example, in DP there is no optimizer, and in PP/DS or in SNP you can use the heuristic planning run instead of using an optimizer. For CTM, ND, PP/DS (SEQ), and TP/VS (VSR) optimizers, SAP recommends a minimum of 512 MB of memory and one CPU, as these optimizers can only make use of one CPU. In this case, optimizer runs can be performed in parallel, leading to a higher grade of optimization in the same timeframe. Notice that 'optimizer' means an optimizer process. If the business process allows you to split the optimizer model in to smaller parts then you can perform the optimizer runs in parallel and therefore make use of more than one CPU. The SNP optimizer also can use only one CPU but memory consumption may be higher, depending on the data volume. The necessary optimization time and the results of the optimization run need to be verified with a realistic data sample 4-8 weeks in advance of going live. The DPS optimizer for PP/DS can be configured to make use of more than one CPU.

2002 SAP AG

Best Practice: SCM /APO Sizing

Hardware Requirements
Figure 1 shows the availability of hardware sizing and estimations of memory consumption or CPU requirements as fully (marked with an 'X'), partially ('X / '), or not ('') available. In some cases, it is only available for 'heuristic' calculations or not applicable (n/a). Abbreviations are: DP SNP PP/DS TP/VS GATP CTM VMI ND CIF Component Name
DP SNP PP/DS TP/VS GATP CTM VMI ND CIF Automotive

Demand Planning Supply Network Planning Production Planning / Detailed Scheduling Transport Planning / Vehicle Scheduling Global Available to Promise Capable to Match Vendor Managed Inventory Network Design Core Interface

liveCache liveCache Application Application Database Database Optimizer Optimizer CPU Memory CPU Memory CPU Memory CPU Memory
X heuristic X/ X X X X X X X X X n/a n/a X/ X heuristic X/ X X X heuristic X/ X X X heuristic X/ X X X heuristic X/ X X n/a X/ X/ X/ n/a X/ n/a X/ n/a n/a n/a X/ X/ X/ n/a X/ n/a X/ n/a n/a

Figure 1 Note: Some data is stored in the liveCache in time series, for example, in DP and sometimes in SNP. If a time series is less than 30% filled, it is compressed automatically in liveCache. However, the Quick Sizer considers the time series to be 100% filled; therefore, the estimate is an upper limit.

Best Practice Procedure How to Use Quick Sizer

You can use the SAP tool Quick Sizer to estimate your mySAP SCM / SAP APO hardware requirements. You can access Quick Sizer free of charge in SAP Service Marketplace under alias /quicksizer. 1. Choose Start Quick Sizing. 2. In the initial form (Figure 2), below the disclaimer text, enter the customer number and the project name. The buttons enable you to display a project, change it, or create a new one. For security reasons, it is not possible to list the projects that already exist.

2002 SAP AG

Best Practice: SCM /APO Sizing

Figure 2 3. If you have chosen to change an existing project or to create a new one, you are guided to a form where you need to choose SAP Advanced Planner and Optimizer. Figure 3 shows how the form displays the corresponding questions.

2002 SAP AG

Best Practice: SCM /APO Sizing

Figure 3 4. After entering all relevant data, choose Result. Note: Before you perform a sizing in Quick Sizer, check whether the input values are plausible. For detailed information, refer to section Plausibility Constraints on Input Data.

Quick Sizer Results

Figure 4 shows the recommendations that Quick Sizer provides regarding CPU requirements and memory consumption for: Application server(s) Database server liveCache - with detailed memory information Additional load of the backend system Hard disk space needed for liveCache Hard disk space needed for the database

The values provided for the optimizer are fixed values. They do not depend on optimizer type or on the size of the optimization model (variables or constraints). For details, in SAP Service Marketplace, alias SCM (http://service.sap.com/scm), choose mySAP SCM Technology mySAP SCM DB & OS Platforms and System Requirements Supported DB & OS Platforms & System Requirements: SAP APO System Requirements for SAP APO 3.0A and SAP APO 3.1 System Requirements for the SAP APO Optimize

2002 SAP AG

Best Practice: SCM /APO Sizing

APO Sizing Results (Release 3.0)

CPU Category Application Server Database Server liveCache 4 2 4 SAPS 827 187 897

Additional Load due to Integration to R/3 in SAPS Application Server Database Server 130 56 Memory in MB Application Server Database Server liveCache Details of liveCache Memory in MB Master Data Demand Planning Supply Network Planning time series Order network ATP Heap memory liveCache System Management Database liveCache 102 1728 274 990 305 2719 933 Disk category 1 2 Disk size in MB 24821 27868 1915 912 7051

Figure 4

CPU and Memory Requirements

These estimations of CPU requirements and memory consumption are based on benchmarks, except that the liveCache memory estimate is derived from the exact memory allocation for each item of the Quick Sizer input data. Quick Sizer also calculates the requirements for heap and liveCache management memory. The amount of heap memory depends on the data volume. If the evaluated data volume is below 4 GB, 80% is added for heap. If it is greater than 20 GB, 20% is added for heap. In the data interval between 4 and 20 GB, heap rises smoothly from 3.2 to 4 GB.

2002 SAP AG

Best Practice: SCM /APO Sizing

Some assumptions are made for the calculation. These assumptions are intended to simplify the Quick Sizer input form. They are: All planning runs proceed at different times without overlap. In DP and SNP time series, 10% are fixed key figures, which claim 3.5 times more memory than ordinary ones. In DP, there is an excess of 5% for aggregates.

The input data items have different influences on the hardware sizing. Some of them, such as the execution period, only affect the CPU requirements. Others, such as the number of key figures, only affect memory consumption. Others in turn affect both. Figure 5 gives an overview. If an increase of the input increases the result, it is marked with 'X'; if it decreases the result, it is marked with 'Y'. The Global ATP input items are related in an unusual way to the liveCache memory (marked with 'S'). If at least one of the items is greater than zero, the liveCache memory is increased by a value that depends on the master data and transactional data. The magnitude of the GATP input items has no impact. The last column, DB Hard Disk, shows which items influence the disk size of the APO OLTP database server. The disk size of the liveCache server depends on the size of the liveCache memory, as shown in column LC Memory. LC CPU
Demand Planning Total number of characteristic combinations Total number of key figures Number of key figures in liveCache (in %) Total number of periods in planning horizon Total number of periods in historical horizon Total number of planning versions stored in the InfoCube Total number of planning versions stored in the liveCache Retention period for data records in InfoCube in months Characteristic combinations used for planning run in % of question 1 above Execution period of planning run Users of Demand Planning (as additional load) Master Data Number of location products Total number of resources Number of warehouse stocks Average Number of Sales orders Average Number of Purchase orders or purchase requisitions Average Number of Transfer orders Average Number of Forecast orders Average Number of Planned orders with SNP production process models (PPMs) Average Number of planned orders and manufacturing orders with PP-PPMs
2002 SAP AG

LC Memory
X X X X X

App/DB CPU

App/DB Memory

DB Hard disk
X X

X X X

X X X Y X X X X X X X X X X X X X X X X Y X X Y X X

Different Types of Orders or Requisitions Used for Planning (subcomponents not mentioned)

Best Practice: SCM /APO Sizing

Time Series liveCache in SNP Number of location products No. of key figures No. of time buckets Supply Network Planning Number of location products planned in heuristic planning run Execution period of the planning runs Users of Supply Network Planning (as additional load) Production Planning - Detailed Scheduling Users of Planning Table (as additional load) Available-To-Promise (ATP) Number of ATP requests against warehouse stocks per hour Number of rule-based ATP requests per hour Number of CTP requests per hour Number of sales orders Number of manufacturing orders Number of purchase requisitions Miscellaneous Number of planning versions (including active version) X X X X X X X S S S X X X X X X X X X X X X X X X X Y X X Y X X Y X X X X

Integration of orders transferred to and from APO per hour

Figure 5 Keep in mind that the Quick Sizer handles only one demand planning area and assumes that all planning runs are at different times with no overlap. The evaluated CPU requirements are compared with your hardware as shown in Figure 6. The values in column SAPS are mean values. The correlation between CPU type and category relies on data from SAP's hardware partners. The result is only an indication: hardware sizing is the responsibility of SAP's hardware partners. Category
0 A B C D E F

SAPS
40 60 90 135 200 300 450

Upper limit
50 75 113 168 250 375 563

Figure 6

2002 SAP AG

Best Practice: SCM /APO Sizing

10

Using SAPS for Sizing

The SAP Application Performance Standard (SAPS) is a hardware-independent unit that describes the performance of a system configuration in the SAP environment. It is derived from the SD Standard Application benchmark, where 100 SAPS are defined as 2000 fully business processed order line items per hour. In technical terms, this throughput is achieved by processing 6000 dialog steps (screen changes), 2000 postings per hour in the SD benchmark, or 2400 SAP transactions. Fully business processed in the SD benchmark means the full business process of an order line item: creating the order, creating a delivery note for this order, displaying the order, changing the delivery, posting a goods issue, listing orders, and creating an invoice.

For example, if a sizing table for a portal suggests a configuration of 1000 SAPS, you can check the SD benchmark table for a sample configuration. If you set the sort order in the SAPS column, you will see a number of benchmark tests that can give you an idea about which configurations are likely to fulfill your requirements.

Verification Plausibility Constraints on Input Data

Before you perform a sizing for a project in Quick Sizer, you need to check whether the input values are plausible. You can distinguish between: Hard constraints (HC) these correspond to combinations of input values that make no sense or are incomplete Soft constraints (SC) these correspond to conditions that fit in general but represent an unusual business scenario Dependent constraints (DC) these correspond to your business scenario

At the very beginning, check the entered values in each section corresponding to the module you use. For example, if you carry out Demand Planning, the corresponding section must be filled with values, at least partially (HC). Some of the input data is interconnected and should be treated as blocks; meaning that either all fields are filled or all are empty (HC). Constraints: Number of characteristic combinations, number of key figures and the percentage in liveCache, number of periods in planning horizon, number of periods in historical horizon, and number of planning versions stored in liveCache are interconnected. For the horizons, at most one of the fields can be empty. The InfoCube retention period and the number of planning versions in InfoCubes only contribute to the hard disk sizing. Characteristic combinations are used for planning and execution period. The timeframe must be at least one hour. Quick Sizer displays an error message if not all fields are filled. Location products in heuristic run and execution time in the SNP section. The timeframe must be at least one hour. Quick Sizer displays an error message if not all fields are filled. In the SNP and PP/DS section, there are objects with subcomponents like sales orders and delivery schedules or planned orders in SNP PPMs together with components, operations, and operation steps. The data belonging to time series in SNP forms a single block. The number of planning versions belongs to SNP transactional data but in the Quick Sizer is set under 'Miscellaneous'. This number must be at least 1 if transactional data is present. Quick Sizer automatically sets it to 1 if you enter no value or zero.

2002 SAP AG

Best Practice: SCM /APO Sizing

11

If the characteristic combinations that are used for planning runs in DP as well as the execution period are empty, this indicates that you are not performing any batch forecast runs. This can mean that either planning happens interactively or that the data is only stored for other purposes. Check if you really do not perform batch forecast runs. In the case of interactive planning, take care that you have entered the number of users of demand planning (as additional load, even if they are not an additional load). Check the same for the number of location products planned in heuristic planning runs in conjunction with the respective execution period in SNP. There is a strong dependency between the following data (HC): Although it makes no sense, you can enter a value higher than 100 for the number of key figures in liveCache (in %). Quick Sizer does not check this value before calculating, so you should check that this ratio does not exceed 100%. One forecast order per location product is expected at the most, so the number of forecast orders should be at least as high as the number of location products. The number of location products planned in a heuristic planning run cannot be higher than the total number of location products.

Most questions appear in connection with Global ATP. Even if only Global ATP is performed, you need to enter more than just the data in the GATP section. If you check against warehouse stocks, so that the number of ATP requests against warehouse stocks per hour is greater than zero, the corresponding field in the master data for the number of warehouse stocks must also be greater than zero. (HC). CTP is only possible in conjunction with PP/DS. Therefore, if you enter a number of CTP request per hour, you must also enter PP/DS data (HC). The number of warehouse stocks and the number of sales orders is expected to be greater than zero (DC). If you are not a retailer or in a related business, the same applies to the average number of planned orders and manufacturing orders with PP-PPMs (DC). This kind of business is not impossible but unusual, meaning that you check only against forecast orders or product allocation. If so, you cannot make CTP or product checks. If no sales orders are specified, backorder processing is also impossible (DC). If you perform those checks or processes, you cannot leave these fields empty.

There is a corresponding field in the SNP or PP/DS section for each field in the CIF section. If a value is entered in 'Number of sales orders,' there must be a corresponding value in 'Sales orders' (SC). There is no fixed ratio between the two, but as a general rule, if the number of sales orders is 1000 times higher than the CIF throughput, you would store them for 100 days (about 3 months, assuming 10 hours per working day). On the other hand, if the ratio is lower than 10, this means most of them are processed within one day. You should check the values if the ratio is over 1000 or less than 10. The same applies for manufacturing orders and purchase requisitions (SC). Keep in mind that this is only a very rough estimation and the values given in the CIF section are peak values. Some other points are worth mentioning: If you perform only PP/DS, there is an outcome for the liveCache memory. For CPU requirements only the number of users contributes. As the CPU requirements in PP/DS depend highly on the customizing, they can vary over a wide range. Therefore, we do not give a recommendation about the CPU requirements. If you use at least batch jobs for DP or SNP, SAP experience is that the sizing for this scenario in most cases results in sufficient CPU for PP/DS. Normally, the number of resources is expected to be greater than zero. A value of zero is possible if you perform SNP with heuristic or interactive planning, but this reflects a particular business scenario (SC). If you use an optimizer for planning, it must be greater than zero (HC).

2002 SAP AG

Best Practice: SCM /APO Sizing

12

Further Information
Background Information
In SAP Service Marketplace, alias SCM (http://service.sap.com/scm), choose: mySAP SCM Technology DB & OS Platforms & System Requirements Supported DB & OS Platforms & System Requirements: SAP APO Choose the support matrix that corresponds to your SAP APO release.

Feedback and Questions

Send any feedback by creating a SAP customer message for component SV-GST-SMC. You can do this at http://service.sap.com/message.

Volume of Documents GoingLive Analysis Questionnaire

It is not easy to determine the structure and volume of the documents in a system before GoLive. Some of the figures can be calculated from known factors, some have to be estimated. This documentation gives you detailed information about the methods you should use to fill out the GoingLive Analysis Check Questionnaire as accurately as possible. The information provided here is accompanied with a detailed example for the calculation or estimation of each figure in the questionnaire. Example: Plastic Inc., located in Bigcity, Nowhereland produces 2 billion toothbrushes each year. These toothbrushes are produced in 80 variants, which are set up in their R/3-system as 80 individual products. For the production of these 80 product variants a total of 320 different components have also been set up in the R/3-system. Sales in Nowhereland consist of 45% domestic sales and 55% sales to 15 Plastic Inc. affiliates outside Nowhereland (export sales). Plastic Inc. has one legal entity in Nowhereland which runs one production plant in Bigcity and six distribution centers located in different regions of the country. The six distribution centers carry out regular deliveries to a customer base of 1200 local customers. Quick Sizer
Did you start a QuickSizer project in SAPNet ?

You can use the alias QuickSizer in SAPNet in order to access the QuickSizer. If you have not yet started a QuickSizer project in SAPNet, please verify if your hardware partner has set up a QuickSizer project for you. Please answer this question with yes or no. If your hardware partner has set up a project please enter the name of the hardware partner. Example: Plastic Inc. has not set up a QuickSizer project on its own. A request at the local office of their hardware partner IBM reveals that the partner has setup a project for Plastic Inc. The correct answer in this case is IBM.
Which name does your QuickSizer project have ?

Each QuickSizer project is set up for a specific customer number and with a name of your choice. The name of the Project acts as a password, so please make sure that you enter the name with correct spelling and upper/lower case. For security reasons, the generic search (with an asterix *) for existing projects is not allowed. Example: The consultant from hardware partner IBM has used the customer number of Plastic Inc. to set up a QuickSizer project in SAPNet. As name for the project he has chosen APOSIZING. In this case the correct answer in this field is APOSIZING.

2002 SAP AG

Best Practice: SCM /APO Sizing

13

Are the values specified in your QuickSizer project still up to date ?

Please use this documentation for the calculation of the figures requested in the questionnaire. After the completion of the Volume of Documents section of the questionnaire you can access the QuickSizer in SAPNet and open your project. Now you are able to verify the figures in your QuickSizer project with the new figures from the questionnaire. We do not recommend updating the figures in the QuickSizer project, especially if your hardware partner created the project. If you find that one or more of the figures which were calculated by following this documentation differ from the corresponding entries in the QuickSizer project please answer with No. Data Volume for Demand Planning
Number of characteristic combinations

A characteristic is a planning object. Examples for characteristics are: Product, Customer, and Distribution Center. Example: If every customer of Plastic Inc. obtains every available product from the company and the delivery can take place from every distribution center or even directly from the production plant, the number of characteristic combinations is: 80 products * (1200 customers + 15 affiliates) * (6 distribution centers + 1 plant) = 680400 characteristic combinations. A detailed analysis of the situation at Plastic Inc. reveals that local customers only obtain an average of 20 different products from Plastic Inc. and none of them obtains the full range of available products. The deliveries to a customer always take place from one fixed distribution center, deliveries from other distribution centers or direct deliveries from the production plant never occur. As opposed to that the affiliates obtain all available products from Plastic Inc. and they always receive direct deliveries from the production plant. With reference to this new, additional information, the calculation for local customers is: 20 products * 1200 customers * 1 distribution center = 24000 characteristic combinations. The new calculation for the affiliates is: 80 products * 15 affiliates * 1 production plant = 1200 characteristic combinations which leads to a total number of 25200 characteristic combinations for Plastic Inc. Please also discuss this figure with your DP implementation consultant, as you should check how the creation of characteristic combination is defined. For example, if your implementation consultant is using a simple method for setup, which leads to the creation of the maximum of all product-customer combinations, you should consider these figures for the correct calculation of the characteristic combinations.
Number of key figures in the liveCache

A key figure is a feature of a planning object that carries a parameter value. Typically the key figures that are stored for a planning object take part in the planning process. Here follow examples for typical key figures and their interaction in the demand planning process: A typical key figure for Demand Planning is the Invoiced Sales Quantity, which can be used as the basis for statistical forecast runs. Another typical key figure is Promotion1, which contains a manually entered or automatically calculated correction quantity. The computation of the Invoiced Sales Quantity with the Promotion1 key figure can be stored in the Corrected History. The Corrected History is a more accurate basis for the creation of statistical forecasts. The forecast result can be stored in the key figure Forecast. You can look up the number of key figures for your planning area in your APO system. Please use the command /n/sapapo/msdp_admin to start the DP and SNP Administration in APO. Double-click on the name of your planning area in the tree on the left side. Answer Continue and Yes to the questions if you receive one or more PopUp-Windows on your screen. Choose folder Keyfigs on the following
2002 SAP AG

Best Practice: SCM /APO Sizing

14

screen. The key figures in your planning area are displayed in the table on the left. Click on the Details button in the middle of the screen. Now the details of your key figures are displayed. If there is an entry in column Infocube then this key figure is not stored in the liveCache. If this field is blank then the key figure is stored in the liveCache. Please add the number of key figures with column Infocube = blank and enter this number into the questionnaire.
Planning horizon: Number of periods

The planning horizon is defined as the time you want to plan ahead. For example, Plastic Inc. wants to plan ahead the demand for finished products on customer-location level for two years. The number of periods is defined by the storage buckets profile assigned to your planning area. First you have to look up the storage buckets profile assigned to your planning area: For this please use the transaction and navigation described in the documentation for Number of key figures in the liveCache. Choose folder Info instead of Keyfigs. In the field Stor.Bckts Prfl the identifier for the storage buckets profile is displayed. Now you have to find out about the granularity of this storage buckets profile: Use command /n/sapapo/tr32 to start the maintenance of periodicity. Use the F4-Help for field Stor.Bckts Prfl to select the correct storage buckets profile. Press enter. Now the granularity of the selected storage buckets profile is displayed. The smallest period selected defines the granularity. Example: The storage buckets profile assigned to the planning area of Plastic Inc. has the identifier 9ADP. The smallest period selected in profile 9ADP is week. The planning horizon of two years contains 104 weeks, thus the correct answer to this question is 104 periods. Please note: The number of periods is not affected by the way you display periods in the planning table. For example: If Plastic Inc. displays the planning results in months they are still stored in weekly buckets according to the settings in the storage buckets profile.
Historical horizon: Number of periods

The historical horizon is defined as the period of time you want to use as historical data for the initialization of your statistical or other forecasting methods. For example, Plastic Inc. wants to use the historical data from the last 2, 5 years for the initialization of their seasonal-trend forecasting model. In order to calculate the number of periods you have to refer once again to the storage buckets profile assigned to your planning area: The historical horizon of 2, 5 years contains 130 weeks, thus the correct answer to this question is 130 periods. Additional information: If you already have a test- or productive system where historical data has been uploaded and demand planning takes place, you can verify these figures in the DP and SNP Administration in APO: Use command /n/sapapo/msdp_admin to start, then right-click on your planning area which is displayed in the left table on the screen. Select Created time series objects from the context menu. Now check the horizons displayed with the horizons expected. The start date up to the date of today should correspond with your historical horizon, the date of today up to the end date with your planning horizon. If the created time series objects do not correspond with the horizons you expect, please contact your implementation consultant for clarification.
Number of planning versions in liveCache

Please fill in the number of planning versions, which are going to be available for your planning area. If you already have a test- or productive system you can check the number of existing versions in the system: Use command /n/sapapo/tscopy to start the Copy/Version Management. Place the cursor in field Planning Area and use the F4-Help to select the planning area from the list. After that place your cursor in field Planning Version and press F4-Help again. Now all planning versions for your planning area are listed in the F4-Help PopUp-window.

2002 SAP AG

Best Practice: SCM /APO Sizing

15

Char. comb. relevant for planning run in %

If you use parallel batch jobs for demand planning, the percentage share of characteristic combinations for the biggest job is the correct answer to this question. Example: If you use three parallel jobs for demand planning and two of these jobs cover the planning for 30% of all customer locations in the system and the third one is planning the rest (= 40% of all customer locations), then the correct answer to this question is 40%. Plastic Inc. is using an overnight batch job for demand planning. Because there are no problems with the memory consumption or runtime of this job, all customer locations are planned with this single job. In this case the correct answer to the question is 100%.
Start of available timeframe

This question asks for the time when you are able to start the batch jobs scheduled for demand planning. Example: The batch job of Plastic Inc. is scheduled to start at two oclock in the morning. In this case the correct answer to this question is 02.
End of available timeframe

This question asks for the time when all batch-planning activities have to be finished. Example: Plastic Inc. opens the gate at six oclock in the morning, and from this time the demand planners can come in, log on and continue their work in interactive demand planning. In order to ensure that the planners are working with updated, consistent data, all overnight planning jobs have to be finished. In this case the correct answer to this question is 06.
Users of Demand Planning (as additional load)

If your batch jobs are running during normal office hours or on a global APO installation where no real night break (= timeframe without dialog users) exists, please fill in the average number of dialog users who are using functions of the demand planning module during the batch job execution time. Example: The facilities of Plastic Inc. are closed during the nighttime; this means that no one is logged on during the night between 20.00 h and 06.00 h in the morning. All batch job activities are started 15 minutes after midnight and all of them finish within one hour. In this case the correct answer to this question is 0. Data Volume for SNP and PP/DS Master Data
Number of location products

A location product is the combination of a location and a product that has been set up in the APOsystem. A location is an entity that can hold stock of finished goods or components. Examples are: production plants, distribution centers, customers. A product is a finished product or any component material that has been set up in the APO system. Example: If all customers of Plastic Inc. as well as every plant, distribution center and affiliate are able to store every finished product as well as every component in their location, then the calculation for the number of product locations leads to the maximum of product locations possible: (80 products + 320 components) * (1200 customers + 15 affiliates + 6 distribution centers + 1 plant) = 400 * 1222 = 488.800 location products. A detailed analysis of the situation of Plastic Inc. reveals that local customers only store the finished products they obtain, which is an average of 20 different products produced by Plastic Inc. None of them stores components. The distribution centers as well as the affiliates store all finished products
2002 SAP AG

Best Practice: SCM /APO Sizing

16

from Plastic Inc., but no components. The production plant is the only place where all finished products as well as all components are stored. With reference to this new, additional information the calculation for product locations is for customer locations: 20 products * 1200 customers = 24000. For distribution centers and affiliates: 80 products * (6 distribution center +15 affiliates) = 1680. For the production plant: (80 products + 320 components) * 1 production plant = 400. This leads to a sum of 24.000 + 1680 + 400 = 26.080 product locations.
Total number of resources, i.e. work center, production lines, tools to be planned in APO

You can check the total number of resources relevant for this sizing verification questionnaire in your APO system. Use command /n/sapapo/res01 to start transaction Resources. In order to select all different types of resources in the system set up a multiple selection of single values for field Resource Type. Insert the resource types P, T, S and H in the multi-selection Popup window. Additionally, you have to specify a selection range for the field planning version. Place your cursor in the first field and select the first planning version from the list in the F4-Help. Then place the cursor in the second field and select the last planning version from the list in the F4-Help. Click on button Display resources in the transaction specific button bar to start the selection. The execution of this transaction can take a few minutes. The results are displayed in a header data screen with 11 different tab pages, each one of them for a different type of resource. Please add the number displayed on each tab in order to calculate the total number of resources. Please enter the result into the corresponding field in the questionnaire.
Total number of warehouse stocks to be planned in APO

The number of warehouse stocks is the sum of all detailed stock locations used in planning. If sub locations and batches are not used in planning, the total is the number of facilities used in the active model multiplied with the number of products, which is typically on stock in these locations. Example: The calculation of the total number of warehouse stocks to be planned in APO is comparable to the calculation of the number of characteristic combinations in Demand Planning. One major difference between both figures is that this time you do not have to calculate the multiplication of all relevant attributes for planning. This time multiply the number of customers with the average number of products for each customer, and then add the number of warehouse stocks stored in the production plant and all other affiliates: 1200 customers obtain an average of 20 products from Plastic. Inc., which leads to the number of 24000 warehouse stocks. In the production plant as well as the distribution centers and all other affiliates the total of 80 products is in stock which leads to the number of (1 production plant + 6 distribution centers + 15 affiliates) * 80 products = 1760 stocks. In this case, where no batches or sub locations are used, the total number of warehouse stocks is 24000 + 1280 = 25760 warehouse stocks. For each facility you have to decide whether sub locations will be included in the planning process. These can be as detailed as shelf and bin locations e.g. in a warehouse. Also, batches can be separated in product planning. If either sub locations or batches are not used (but the other type is used), the multiplying factor for the category not used is set to 1. Multiply the number of sub locations by the number of batches for each facility. Sum the totals for the facilities used in the active model in order to get the correct total number of warehouse stocks used in APO. Enter this sum into the field for the Total number of warehouse stocks to be planned in APO in the GoingLive Check Questionnaire.

2002 SAP AG

Best Practice: SCM /APO Sizing

17

Data Volume for SNP and PP/DS Transactional Data

Average number of sales orders used for planning

If you want to determine the correct number of sales orders used for planning in APO please contact your implementation consultant in order to get to know the details of your integration model for sales orders. If all sales orders are included in your integration model, then all sales orders in the backend system that are not fulfilled yet are present in the APO system. Be aware that the sales orders where the shipment already took place but the payment for the order did not take place yet have to be filtered out. These sales orders are still open and present in R/3, but they are not present in the APO system any more. If only part of your sales orders are in the integration model you have to find out what percentage of the total number of orders are in the integration model. You can use the standard SD reporting functionality in your backend system to identify all not completed orders and use filters to determine the orders, which are part of your integration model. For example: If you start transaction SD01 in the backend system you are able to select all sales orders which were entered during a certain period of time. You can then filter the completed orders from the list. Apply a special filter in order to filter out orders which have been fulfilled already but the payment is still missing. If necessary, you can filter out all orders that are not part of your integration model for sales orders. Pick option List status from the Settings menu to see the number of orders in the list and the number of orders, which were filtered out.
Average number of delivery schedules per sales order

If you do not know the average number of delivery schedules per sales order you can use one of the following procedures to support you with working out a proper estimation: If all sales orders are included in your integration model please log on to your R/3 backend system and start transaction SE16. Transaction SE16 enables you to select and view the content of data- and customizing tables directly. On the first screen you have to enter the name of table VBAK that holds the header information of all sales orders in your system. Press enter in order to proceed to the selection screen. If a Popup window appears please confirm it without any changes and proceed to the selection screen. On the selection screen do not enter any selection criteria. Click on the button Number of entries in the transaction specific button bar. You may have to wait for several minutes to receive the result. After the transaction has finished correctly a PopUp window with the total number of datasets in table VBAK will appear. Please write down this number for reference. Re-start transaction SE16 and repeat all steps for data table VBAP. In table VBAP the details of schedule lines from sales orders are stored. Write down the total number of datasets in table VBAP as well. Now you are able to calculate the average number of delivery schedules per sales order: The number of entries in table VBAP divided by the number of entries in VBAK leads to the result of the average number of delivery schedules per sales order. Please note that you are not allowed to enter a rational number but only a whole number as a valid answer to this question. Please apply a corresponding rounding rule. If only a part of your sales orders is included in your integration model then the procedure described above may not lead to accurate results. In this case try to identify sales orders, which are part of your integration model and use transaction VA03 or transaction SE16 and table VBAP to get the number of schedule lines, which belong to these sales orders. We recommend that you look up a large number of (e.g. twenty) sales order to create a stable average number of schedule lines for sales orders that are representatives of your integration model.

2002 SAP AG

Best Practice: SCM /APO Sizing

18

Average number of purchase orders or purchase requisitions

If you do not know the average number of purchase orders or purchase requisitions you can use one of the following procedures to support you with working out a proper estimation: If all Purchase requisitions are included in your integration model please log on to your R/3 backend system and start transaction SE16. Transaction SE16 enables you to select and view the content of data- and customizing tables in your R/3 system. On the first screen you have to enter the name of table EBAN that holds the information of all purchase requisitions in your system. Press enter in order to proceed to the selection screen. If a Popup window appears please confirm it without any changes and proceed to the selection screen. On the selection screen set a filter, which excludes purchase requisitions of type B, because these are already converted to purchase orders. Then click on the button Number of entries in the transaction specific button bar. You may have to wait for several minutes to receive the result. After the transaction has finished correctly a PopUp window with the total number of datasets in your selection for table EBAN appears. This is the total number of purchase requisition positions. If you need to know the number of purchase order requisitions you have to set up a selection that shows how many individual entries are in field BANF in table EBAN. If you want to find out how many planning relevant purchase orders are in the system you can start transaction ME23N and switch on the document overview. In the selection screen for purchase orders you can click on the button dynamic selections. Use the selection options available to identify the number of open purchase order positions and the number of purchase orders which were not fulfilled yet. Be aware that the requisitions and purchase orders where the goods receipt already took place but the payment for the order did not take place yet have to be filtered out. These objects are still open and present in R/3, but they are not present in the APO system any more.
Average number of delivery schedules per purchase order or purchase requisition

If you are working with purchase requisitions the information from table EBAN should be sufficient to calculate the average number of delivery schedules. If you divide the total number of entries in EBAN by the number of individual entries in field EBAN-BANFN you should receive this figure. Please note that you are not allowed to enter a rational number but only a whole number as a valid answer to this question. Please apply a corresponding rounding rule. If you are working with purchase orders you can calculate the average number of delivery schedules by the division of the total number of entries in table EKPO by the total number of entries in table EKKO. If only a part of your purchase requisitions or orders are included in your integration mode,l then the procedure described above may not lead to accurate results. You should then follow a strategy, which is equivalent to the procedure for the calculation of the average number of delivery schedules for sales orders. We recommend that you look up a large number (e.g. twenty) of requisitions or orders to create a stable average number of schedule lines for requisitions/orders that are representatives of your integration model.
Average number of transfer orders

The transfer orders are for internal stock transfers and were generated by the APO SNP planning process. If you have a productive system you can look up the number of transfer orders created during a planning run. If you use the optimizer or CTM logic you can use transaction /sapapo/opt11 and retrieve the information from the job log. If you are using Heuristics for planning please schedule your planning activity as a background job and then analyze spool and job log after the job has finished. If you do not yet have a productive system you can use the following formula for the calculation of a rough estimate: Multiply the number of forecast time buckets with the number of your key account warehouses multiplied with the number of customers. Key account warehouses: From key account warehouses you carry out transports to your customers.

2002 SAP AG

Best Practice: SCM /APO Sizing

19

Example: Using the data from former examples, the calculation for Plastic Inc is: 120 forecast time buckets in SNP x 6 key account warehouses x 1200 customers = 864000 transfer orders. Expect the real number of transfer orders to be smaller than this estimate. The real number depends on the order- and delivery frequency of the customers: If customers get one delivery per week and half of the customers receive a delivery only every second week the estimation should be corrected as follows: High frequency customers: 432000 (max) transfer orders divided by 5 is 86400 transfer orders. Low frequency customers: 432000 (max) transfer orders divided by 10 is 43200 transfer orders. This leads to a total of 86400 + 43200 = 129600 estimated transfer orders.
Average number of products (materials) per transfer order

If you are working with transfer orders in a way that you transfer finished products, e.g. from your production plant to your distribution center(s) in order to fulfill the demand there, then the average number of products per transfer order is 1. If you use transfer orders to settle secondary demand from production planning, e.g. if you transfer components for production to your production plant you have to consider the BOM-structure of your SNP Production Process Models (PPMs). In this case choose the average number of components within your SNP-PPMs as the correct average number of products (materials) per transfer order. If you can find both types of use in your solution you should think about the average number as a figure between the average number of components within your SNP-PPMs and 1. Example: SNP is creating production orders in daily buckets, which mans that there are typically 5 production orders for each material in a week. The demand from the distribution centers as well as the affiliates is typically settled with one replenishment delivery per product per week. This means that the transfer orders for the settlement of the production demand have a share of 5 days * 80 products = 400 transfer orders in a week. The transfer orders for the settlement of demand in the distribution centers and affiliates have a share of (6 DCs +15 Affiliates) * 80 products * 1 transfer order per week = 1680 transfer orders in a week. The BOM of a typical SNP-PPM contains 4 components. Now the calculation of the average number of products (materials) per transfer order works like this: (share of production component transfers 400 * 4 components) + (share of replenishment deliveries 1680 * 1 product) / total number of transfer orders 2080 = 1, 58 Average number of products (materials) per transfer order. It is only possible to enter integer figures in the questionnaire. This means that the correct, rounded answer to this question is 2.

2002 SAP AG

Best Practice: SCM /APO Sizing

20

Copyright 2002 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint and SQL Server are registered trademarks of Microsoft Corporation. IBM , DB2 , OS/2 , DB2/6000 , Parallel Sysplex , MVS/ESA , RS/6000 , AIX , S/390 , AS/400 , OS/390 , and OS/400 are registered trademarks of IBM Corporation. ORACLE is a registered trademark of ORACLE Corporation. TM INFORMIX -OnLine for SAP and Informix Dynamic Server are registered trademarks of Informix Software Incorporated. UNIX , X/Open , OSF/1 , and Motif are registered trademarks of the Open Group. HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C , World Wide Web Consortium, Massachusetts Institute of Technology. JAVA is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies. Disclaimer: SAP AG assumes no responsibility for errors or omissions in these materials. These materials are provided as is without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party Web pages nor provide any warranty whatsoever relating to third party Web pages.

2002 SAP AG