Planni ng with SAP SCM Dietmar-Hopp-Allee 16 D-69190 Walldorf CS STATUS external final DATE VERSION August 5th, 2009 1.1 SOLUTION MANAGEMENT PHASE SAP SOLUTION Operations & Continuous Improvement Best Practices for Solution Operations TOPIC AREA SOLUTION MANAGER AREA Application & Integration Management Business Process Operation Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 2/2 Table of Contents Management Summary 5 1.1 Goal of Using this Best Practice 5 1.2 Alternative Practices 5 1.3 Staff and Skills Requirements 5 1.4 System Requirements 6 1.5 Duration and Timing 6 1.6 How to Use this Best Practice 6 1.7 Best Practice Procedure 6 1.7.1 Preliminary Tasks 6 1.7.2 Monitoring Concepts 6 1.7.3 Business Process Monitoring in SAP Solution Manager 7 1.7.4 Monitoring Types for Business Process Monitoring in SAP Solution Manager 8 1.7.4.1 Application Monitor 8 1.7.4.2 Background J ob 9 1.7.4.3 ABAP Dump Collector 10 1.7.4.4 Dialog Performance 10 1.7.4.5 Update Errors 11 1.7.4.6 Due List Log 12 1.7.4.7 Application Log 13 1.7.4.8 Other CCMS Monitors 14 1.7.4.9 Analysis and Monitoring Tools 15 1.7.4.10 Monitoring Activities 17 1.7.4.11 Notifications 17 1.7.5 Business Process Monitoring Process 18 2 Business Process Monitoring for Service Parts Planning 20 2.1 Sample Scenario 20 2.2 Business Process Service Parts Planning 20 2.2.1 Business Process Step 1: Capture Demand History 21 2.2.1.1 Description 21 2.2.1.2 Monitoring Requirements: 22 2.2.1.3 Monitoring Objects in SAP Solution Manager 23 2.2.1.4 Monitoring without SAP Solution Manager 25 2.2.1.5 How to Find Meaningful Thresholds for Each Monitoring Object 25 2.2.2 Business Process Step 2: Stocking and De-stocking 25 2.2.2.1 Description 25 2.2.2.2 Monitoring Requirements: 26 2.2.2.3 Monitoring Objects in SAP Solution Manager 26 2.2.2.4 Further Monitoring Objects 26 2.2.2.5 Monitoring without SAP Solution Manager 27 2.2.2.6 How to Find Meaningful Thresholds for Each Monitoring Object 27 2.2.3 Business Process Step 3: Manage Demand History 27 2.2.3.1 Description 27 2.2.3.2 Monitoring Requirements: 28 2.2.3.3 Monitoring Objects in SAP Solution Manager 28 2.2.3.4 Further Monitoring Objects 29 Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 3/3 2.2.3.5 Monitoring without SAP Solution Manager 29 2.2.3.6 How to Find Meaningful Thresholds for Each Monitoring Object 29 2.2.4 Business Process Step 4: Forecasting 29 2.2.4.1 Description 29 2.2.4.2 Monitoring Requirements: 31 2.2.4.3 Monitoring Objects in SAP Solution Manager 31 2.2.4.4 Further Monitoring Objects 31 2.2.4.5 Monitoring without SAP Solution Manager 32 2.2.4.6 How to Find Meaningful Thresholds for Each Monitoring Object 32 2.2.5 Business Process Step 5: Economic Order Quantity & Safety Stock 32 2.2.5.1 Description 32 2.2.5.2 Monitoring Requirements: 33 2.2.5.3 Monitoring Objects in SAP Solution Manager 33 2.2.5.4 Further Monitoring Objects 33 2.2.5.5 Monitoring without SAP Solution Manager 34 2.2.5.6 How to Find Meaningful Thresholds for Each Monitoring Object 34 2.2.6 Business Process Step 6: Surplus & Obsolescence Planning 34 2.2.6.1 Description 34 2.2.6.2 Monitoring Requirements: 35 2.2.6.3 Monitoring Objects in SAP Solution Manager 35 2.2.6.4 Further Monitoring Objects 36 2.2.6.5 Monitoring without SAP Solution Manager 37 2.2.6.6 How to Find Meaningful Thresholds for Each Monitoring Object 37 2.2.7 Business Process Step 7: Distribution Requirements Planning (DRP) 37 2.2.7.1 Description 37 2.2.7.2 Monitoring Requirements: 38 2.2.7.3 Monitoring Objects in SAP Solution Manager 38 2.2.7.4 Further Monitoring Objects 39 2.2.7.5 Monitoring without SAP Solution Manager 39 2.2.7.6 How to Find Meaningful Thresholds for Each Monitoring Object 39 2.2.8 Business Process Step 8: Procurement Approval (DRP Approval) 40 2.2.8.1 Description 40 2.2.8.2 Monitoring Requirements: 41 2.2.8.3 Monitoring Objects in SAP Solution Manager 41 2.2.8.4 Further Monitoring Objects 43 2.2.8.5 Monitoring without SAP Solution Manager 43 2.2.8.6 How to Find Meaningful Thresholds for Each Monitoring Object 43 2.2.9 Business Process Step 9: Deployment 44 2.2.9.1 Description 44 2.2.9.2 Monitoring Requirements: 45 2.2.9.3 Monitoring Objects in SAP Solution Manager 45 2.2.9.4 Further Monitoring Objects 46 2.2.9.5 Monitoring without SAP Solution Manager 47 2.2.9.6 How to Find Meaningful Thresholds for Each Monitoring Object 47 2.2.10 Business Process Step 10: Inventory Balancing 47 2.2.10.1 Description 47 Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 4/4 2.2.10.2 Monitoring Requirements: 48 2.2.10.3 Monitoring Objects in SAP Solution Manager 48 2.2.10.4 Further Monitoring Objects 49 2.2.10.5 Monitoring without SAP Solution Manager 49 2.2.10.6 How to Find Meaningful Thresholds for Each Monitoring Object 50 3 Further Information 51 3.1 Troubleshooting 51 3.2 Related Best Practice Documents 51 3.3 Literature 51 3.4 Feedback and Questions 52 4 Appendix 53 4.1 Examples for recommended Monitoring Objects 53 4.1.1 Example Background J ob Monitoring 53 4.1.2 Example Dialog Response Time Monitoring 54 4.1.3 Example Data Consistency 55 4.2 Available Monitoring Objects for scenario Procure-to-stock 57 4.2.1 Overview Procure-to-Stock 57 4.2.2 Monitoring Business Process Procure-to-Stock 58 4.2.3 Business Process Steps executed in SAP SCM APO Service Parts Planning and Monitoring Objects 59 4.2.4 Business Process Steps executed in SNC and respective Monitoring Objects 59 4.2.5 Business Process Steps executed in ECC/ERP and Monitoring Objects 60 4.2.6 Business Process Steps executed in EWM and respective Monitoring Objects 61 4.2.7 Business Process Steps executed in the Supplier System and respective Monitoring Objects 63 4.3 Background J obs 64 Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 5/5 Management Summary 1.1 Goal of Using this Best Practice This Best Practice will help you to set up a Business Process Monitoring concept for your SAP solution in the automotive area. The concept aims to define procedures for business process oriented monitoring and error handling, and escalation procedures for Service Parts Planning with SAP SCM. These procedures are intended to ensure a smooth and reliable flow of this core business process so that your business requirements are met. This Best Practice offers guidance to define suitable application-oriented monitoring objects to detect any irregularities or deviations from an ideal business process flow, or to detect error situations concerning a core business process at an early stage. This Best Practice contains the recommended approach from SAP which uses the SAP Solution Manager for the Monitoring functionalities whenever possible. However, even if you do not use the SAP Solution Manager we recommend that you follow the procedures described in this document as much as possible in to ensure a smooth and reliable flow of your business processes as well as an appropriate response in case of unforeseen errors. Additional information on how to monitor the end-to-end cross-system scenario Procure-to-stock can be found in the Appendix of this document. 1.2 Alternative Practices You can have SAP experts deliver this Best Practice on-site by ordering an SAP Solution Management Optimization (SMO) service for SAP Business Process Management (BPM). This service is exclusively available within SAPs support engagements SAP MaxAttention and SAP Safeguarding. If your company currently does not have any support engagement with SAP, it is also possible to get assistance by SAP experts from SAP Consulting. If this case, please contact your local SAP Consulting representative. 1.3 Staff and Skills Requirements To implement this Best Practice, you require the following teams: Application Management Team This team creates the ERP Business Process Monitoring concept and consists of experts from several areas of your company: Business department Solution support organization (for example the Basis Support or the Application Support) Implementation project team Business Process Operations Team The Business Process Operations team will be responsible for applying the resulting procedures derived from implementing this best practice. They include the following groups: Persons designated to perform business process-oriented monitoring and to ensure that the process runs smoothly (for example, the Business Process Champion for each business process) All parties in your Solution Support Organization and IT department involved in monitoring focused on the application aspects (Application Support, Development Support, J ob Scheduling Management) SAP Technology Operations Team All parties in your Solution Support Organization and IT department involved in monitoring focused on the system administration side (Program Scheduling Management, Software Monitoring Team, System Administration Team including the System Administrator) Business Process Champion The Business Process Champion is the person in the business department who is responsible for the successful execution of the business process. He/she coordinates all activities necessary for the business process. Therefore, he/she is usually responsible for the escalation paths in case of problems. Often, he/she is a second level in the escalation procedure, if the application monitoring team needs to escalate an issue. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 6/6 More information about roles and responsibilities of these teams can be found in the super-ordinate Best Practice General Business Process Management, which you can obtain through SAP Solution Manager or the SAP Service Marketplace, quicklink /BPM. Necessary or Useful Trainings SM300 Business Process Management and Monitoring E2E300 End-to-end Business Process Integration and Automation Management 1.4 System Requirements To monitor business processes running in your SAP solution via SAP Solution Manager, the SAP Basis Release of the systems to be monitored have to be at least 4.6C. To have all described monitoring objects available in SAP Solution Manager, the add-on ST-A/PI01L has to be installed on the SAP ECC systems. 1.5 Duration and Timing Duration Creating a Business Process Monitoring concept could take around one week per business process. Implementing the Business Process Monitoring concept might take approximately an additional week in total. Timing The best time to apply this Best Practice is during the planning phase or during the implementation phase of your SAP solution. 1.6 How to Use this Best Practice Here you find a brief description of how you should proceed in using this document: Read through the General Business Process Management Best Practice, available on the SAP Service Marketplace. This document explains the procedures you should use to create a general Business Process Management concept. This includes the definition and documentation of the core business processes, definition of monitoring objects, definition of monitoring activities including error handling procedures, monitoring tools and monitoring frequencies, the definition of communication and escalation procedures and the assignment of responsibilities. At the beginning of section 2, you will find a typical flow chart of the core business process explained in this Best Practice. It is intended to be used as a guideline for writing down your company specific process documentation. In section 1.7.4, you find further information that is relevant for more than one scenario. If information from the generic part is relevant for a specific business process step in one of the scenarios, you will find a clear link to the corresponding chapter in the generic part. 1.7 Best Practice Procedure 1.7.1 Prel iminary Tasks Before performing this Best Practice, ensure that you perform the following preliminary tasks or checks in the system: Complete all installation and post-installation actions and procedures including customizing Ensure that the initial data load has been successfully executed Apply all SAP recommendations from SAP Service Sessions and any SAP recommendations resulting from customer problem messages Implement all current SAP Support Packages upon availability 1.7.2 Monitori ng Concepts The monitoring procedures proposed for each business process step are the core of this Best Practice. The monitoring procedures help you to ensure that the technical processes meet the requirements for stability, performance, and completeness. These procedures cover monitoring for the five areas: Error monitoring Performance monitoring Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 7/7 Throughput monitoring Backlog monitoring Data Consistency Monitoring For each of the business process steps, you will find the following information: A detailed functional description of the process step Identified monitori ng requirements for the process step Defined moni toring obj ects, alerts and selection criteria Description of error handling procedures and restartability General monitoring activities that are valid for all or most scenarios are described in the generic part in section 1.7.4. Recommendations for performance monitoring can also be found in this chapter. The performance of the most important steps of your core business processes should be monitored on a regular basis. The monitoring procedure for performance monitoring of all steps that are executed in an SAP solution used for Spare Parts Management is generally the same. Therefore, you will only find specific performance monitoring recommendations on selected business process steps. 1.7.3 Business Process Monitoring in SAP Solution Manager Business Process Monitoring (BPMon), as part of Solution Monitoring means the proactive and process- oriented monitoring of the most important or critical business processes including the observation of all technical and business application specific functions that are required for a steady and stable flow of the business processes. The core business processes that are implemented in an SAP system or other software and operated by a company are of particular importance. Business Process Monitoring is intended to ensure a smooth and reliable operation of the business processes and, thereby, that the core business processes meet a companys business requirements in terms of stability, performance, and completeness. SAP Solution Manager provides a graphical view to visualize a companys (distributed) system and solution landscape and all related business processes. By using Business Process Monitoring, it is possible to define and customize alert situations from a basic set of configurable monitoring objects provided by the SAP Solution Manager. These resulting alerts are then visualized by green, yellow, and red alert icons for each individual business process step in the graphical business process representation. The goal of Business Process Monitoring is to detect and respond to critical situations as early as possible so you can solve problems as quickly as possible. In addition, SAP Solution Manager offers extended functionality for error handling and problem resolution. By the definition of contact persons and escalation paths, Business Process Monitoring can be integrated into the companys overall strategy for Business Process Management and Solution Management within their Solution Support Organization. In general, Business Process Monitoring includes the solution-wide observation of: Business process performance (Key Performance Indicators) Background jobs (J ob Scheduling Management tasks) Business application logs (such as any error log, general application log, due list logs, and so on) Data transfer via interfaces between software components Data consistency Technical infrastructure and components which are required to run the business processes Required periodic monitoring tasks For further details on Business Process Monitoring please refer to http://service.sap.com/bpm. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 8/8 1.7.4 Monitori ng Types for Business Process Monitoring in SAP Solution Manager Monitoring Types are part of the functional scope of Business Process Monitoring as it is available in the SAP Solution Manager. This chapter provides a short overview of available monitoring types for reference purposes only. The available Monitoring Types are: Application Monitor (Throughput and Backlog Indicators, Data Consistency Checks, Mass Activity Monitors, Due List Log, MRP key figures, User Exit, Interface Monitoring) Background J obs (J obs running on SAP Systems with an SAP Basis) Dialog Performance (Dialog transaction performance) Update Errors (V1 and V2 update errors from SM13 for specific transactions and programs) Due List Log (messages for deliveries and billings) Application Log (messages from the Application Log SLG1) Document Volume (based on table call statistics in ST10) Other CCMS Monitor (all alerts that are configured in the CCMS Alert Monitor) Depending on what is executed during a specific business process step, the relevant Monitoring Types must be selected. To receive detailed information on how to set up the Monitoring Objects in SAP Solution Manager, please refer to the documentation that is available under http://service.sap.com/bpm. One prerequisite for setting up Business Process and Interface Monitoring in the SAP Solution Manager is that all business processes and business process steps are maintained in the respective solution that contains all affected system components. If you want to learn more about how to set this up, see (URL http://help.sap.com) SAP Solution Manager Basic Settings. 1.7.4.1 Application Monitor The Application Monitor is just one of many different Monitoring Types within Business Process Monitoring. The latest monitoring objects are only provided if the latest ST-A/PI plug-in is installed on the satellite system. The Service Tool for ST-A/PI is available via the SAP Service Marketplace Quick Link /installations Entry by Application Group -> Plug-Ins SAP Solution Tools ST-A/PI. Ensure that the ST-A/PI is installed on the SAP Solution Manager system and on the respective satellite system. In case of problems, refer to SAP Note 915933. The Throughput and Backlog Indicator functionality available as of ST-A/PI 01J * is only working properly with ST-SER 700_2007_1. This is due to changes in the underlying architecture. More detailed information about the different Application Monitor functionalities and a detailed description on how to define self-written monitoring collectors for the user exit are explained in the documents Setup Guide Application Monitoring and Setup Guide - User Exit respectively (URL http://www.service.sap.com/ Alias BPM Media Library). 1.7.4.1.1 Throughput and Backlog Indi cators (TBIs) As of ST-A/PI 01H, a completely new set of Application Monitors has been introduced. While the already established monitors are all evaluating specific logs or performance data these new monitors are considering (un-)processed documents in the SAP system and provide Throughput and Backlog Indicators. These TBIs should especially provide Automated and early detection of application error situations and backlogs in the core business processes Automated error and backlog analysis tools Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 9/9 For ERP Logistics, the following monitors are available: Sales and Services (for example, Sales Documents, Invoices) Warehouse Management (for example, Transfer Requirements, Transfer Orders) Inventory Management (for example, Goods Movements) Logistics Execution (for example, Deliveries, Shipments) Procurement (for example, Planned Orders, Purchase Requisitions, Purchase Orders) Manufacturing (for example, Planned Orders, Production or Process Orders, Autom. Goods Movements posted with error, Confirmation Pool errors) Plant Maintenance (for example, PM/CS Notifications, PM/CS Orders) For further information on the different TBIs refer to the document Setup Guide - Application Monitoring (URL http://www.service.sap.com/BPM Media Library). 1.7.4.1.2 Data Consistency Checks The DCC collectors are a subset of the Application Monitors used to retrieve a stored comparison result from data comparison check reports for SAP systems. There are certain consistency check programs that are able to not only output their check result to a list or into the spool, but can also permanently store a summary in database tables. Corresponding monitoring objects can be configured to retrieve the number of found inconsistencies out of the stored summary information and display them as alerts within the SAP Solution Manager Business Process Monitoring (Consistency Monitoring). For further information, refer to the document Setup Guide Data Consistency Monitoring (URL http://www.service.sap.com/ ->Technical Information). 1.7.4.2 Background Job The background job monitoring should be part of a J ob Scheduling Management concept (go to http://service.sap.com/solutionmanagerbp Topic Area Business Process Operations to find a Best Practice document Job Scheduling Management). Because of several restrictions regarding background job scheduling, for example, time restrictions, restriction of hardware resources (CPU, main memory, ) or existing dependencies between different activities (for example, invoices can only be created after the corresponding goods issue is posted, or Back Order Processing and Material Requirements Planning should not run at the same time) it is very important to ensure the stable running of background jobs. A cancelled background job should be identified as soon as possible so you can react as quickly as possible. Therefore, it is also necessary to define restart procedures and escalation paths. 1.7.4.2.1 Monitori ng Objects and Alerts Before setting up monitoring, the monitoring objects must be clearly defined. A monitoring object is a single background job or a group of background jobs. There are four different possibilities to identify a special background job or a group of background jobs. This information needs to be maintained in the sub-node Background J ob below a business process step. A more detailed description (than provided in this document) on the subject of what kind of alerts make sense or what kind of alerts are possible are discussed in the Best Practice document Background J ob Monitoring with SAP Solution Manager, which can be found on the SAP Marketplace http://service.sap.com/solutionmanagerbp Topic Area Business Process Operation. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 10/10 1.7.4.3 ABAP Dump Collector This provides monitoring features for alerting on occurrences of ABAP dumps of specified runtime errors or to collect statistical data of ABAP dumps for reporting reasons. 1.7.4.3.1 Monitori ng Objects and Alerts The monitoring object is an ABAP runtime error. This runtime error can be specified via the runtime error name, the user who is responsible for the runtime error, the Client on which the runtime error occurs, or the Program which leads to the runtime error. The following alerts are available: - Number of ABAP Dumps (Delta) (all dumps since the last collector run) - Number of ABAP Dumps (Reporting) (all runtime errors of specified type, client and program for this day or for the previous day) 1.7.4.4 Dialog Performance Dialog Performance implies the monitoring of the dialog transaction performance of any transaction in the SAP System. This could be a standard transaction or a self-developed transaction. 1.7.4.4.1 Monitoring Objects and Alerts The monitoring object is the transaction itself. The customizing has to be done in the node Dialog Performance. In the table Transactions, all transactions that are already configured to that business process step are listed. The relevant transactions need to be selected for monitoring. It is also possible to add or to remove transactions within table Add/Remove Transactions. The monitoring can be performed for each SAP instance. Therefore, the respective instances have to be selected in table SAP Instances. All instances that are maintained for a system are listed there. Table Alert Types shows the dialog response time and all parts of the response time, like queue time, load and generation time, database request time, and the front-end response time, which can be monitored. Those times that are relevant for monitoring have to be selected. After saving this node, a sub-node Performance Alerts will appear where the threshold values have to be entered. Monitoring Objects Di alog Performance Each table in the sub-node Performance Alerts corresponds to an alert type chosen in the higher-level node, and lists the combinations of the specified transaction code and SAP instance. For each combination of transaction code and instance that should be included in the monitoring, the Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 11/11 threshold values resulting in alert messages for changes from GREEN to YELLOW, from YELLOW to RED, back from RED to YELLOW, and back from YELLOW to GREEN have to be specified. Since the Monitoring Object for Performance Monitoring is created on the satellite system, it might be possible that the object already exists there. Therefore, you can load the current threshold values from the respective systems via the button "Load thresholds from XYZ", where XYZ represents the SID. If successfully retrieved for an SAP instance, the values are filled in columns. If no active settings for the threshold values were found for a certain transaction code, default values are set (indicated in column "Default"). To transfer the threshold values for a single line from right to left, the copy icon can be used. To transfer all at once (all thresholds for all columns and tables), there is an additional button "Copy all". Monitoring Alert s - Dialog Perf ormance 1.7.4.5 Update Errors Changes to the data in an SAP system caused by a business process should be written to the database in full or not at all. If the operation is canceled while the transaction is being executed, or if an error occurs, the transaction should not make any changes to the database. These activities are handled by the SAP update system. The SAP System makes a distinction between primary, time-critical (V1) and secondary, non-time-critical (V2) update errors. This distinction allows the system to process critical database changes before less critical changes. V1 modules describe critical or primary changes; these affect objects that have a controlling function in the SAP System, for example, order creation or changes to material stock. V2 modules describe less critical secondary changes. These are pure statistical updates, for example, result calculations. 1.7.4.5.1 Monitori ng Objects and Alerts Monitoring of Update Errors can be configured for online transactions and/or ABAP programs relevant in a business process. This is the object type. The name of the object is the name of a transaction or the name of the ABAP program itself. If desired a user executing the transaction or the ABAP program can be specified. If no user is specified explicitly, all users (represented by '*') will be considered in monitoring data evaluation. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 12/12 Monitoring Objects - Update Errors Since update errors are usually very critical, the default configuration is to raise a yellow alert as soon as one update error occurs. This is valid for V1 and for V2 update errors. To raise a red alert for a V1 or a V2 update error, a threshold must be specified. 1.7.4.6 Due List Log A due list is a list that contains several entries (documents) depending on selection criteria. There are different types of due lists in an SAP system, of which the following three are most important: delivery (L), billing (F) and picking (K). The delivery due list can be accessed directly via transaction V_SA, and the billing due list via transaction V.21. In the case of a billing due list, the list contains, for example, a number of sales documents that need to be billed. If the billing due list was processed previously and it is important to know which billing documents were created from this billing due list, it can be displayed in the due list log for this billing run. 1.7.4.6.1 Monitori ng Objects and Alerts The monitoring object is the respective due list type. That can be Delivery, Billing, or Picking. If a certain user is processing the due list, the name of the user can be specified here. If it is user independent, a wild card * can be used. The aggregation level needs to be defined. This could be per day, per hour or per log. For the monitoring of due list log messages, four different alert types can be used: 1. DocumentCreation refers to the status of the document creation itself. The alert rating (YELLOW or RED) will be raised if no documents were created during a Due List run. 2. MinQuantityDocs refers to a minimum number of documents that should be created during a Due List run. The threshold values for the number of documents that result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (or back) must be maintained. 3. TotalQuantityMsgs refers to the total number of message created during a Due List run. 4. The threshold values for the number of messages that result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (or back) must be maintained. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 13/13 5. DLLogMsgs refers to specific due list log messages. The message type, the message ID and the number can be specified. It is also possible to use wild cards. The threshold values for the number of messages that result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (or back) must be maintained. 1.7.4.7 Application Log The Application Log provides an infrastructure for collecting messages, saving them in the database and displaying them as a log. Situations can arise at runtime in application programs that must be brought to the attention of the user in some way. These are usually errors. It can also be useful to report a successful completion. The information that arises is called a message. The set of messages is a log. A log usually also has header information (log type, creator, creation time, and so on). A transaction can generate several logs. The Application Log is not written consecutively but as a whole at one point in time. 1.7.4.7.1 Monitori ng Objects and Alerts The Application Log allows an application-oriented or object-oriented recording of events. An object, and any subobject that belongs to it, classify each event. The analysis of the logs is similarly object (or sub-object) oriented. The name of an object (and/or subobject) can be found in transaction /nSLG1 together with all other specific information to that log. Monitoring Objects and Alert s - Applicati on Log It is possible to monitor for the total number of messages belonging to an object. Therefore, the number of messages that raises a YELLOW alert and the number of messages changing from a YELLOW to a RED alert must be maintained. It is also possible to monitor specific messages that are considered as critical in table CriticalMsgs. To Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 14/14 configure the monitoring of critical application log messages, the relevant object-sub object combinations need to be selected. For each of these combinations, the message type, the message ID, the message number and the threshold values for the number of critical messages that are supposed to result in changes from GREEN to YELLOW and from YELLOW to RED can be specified. It is also possible to use wild cards. Monitoring Alert s - Applicati on Log / Crit ical Messages 1.7.4.8 Other CCMS Monitors With other CCMS Monitors, it is possible to assign any CCMS monitoring tree element (MTE) to a business process step. Therefore, it is necessary to call transaction RZ20 in the Satellite System and to open a monitor that contains the required alert(s). The name of the monitoring tree element (MTE) can be found by choosing F1. The MTE name needs to be copied into the corresponding column of the table below (See screenshot Other CCMS Monitors below). Under column Monitor Name, it is possible to assign an individual name. The MTE used for monitoring should be an MTE on the lowest leaf-level, that is, on attribute level. If an MTE of a higher branch-level (collective MTE) is chosen, then the current and open view in the graphics will show the right alerts but it isnt possible to process these alerts within the Business Process Monitoring session as the alerts are not replicated there. In order to load the threshold values that are currently valid in the corresponding system, the button can be used. If successfully retrieved, the values are filled in the right-hand columns. If no active settings for the threshold values were found these columns remain empty. To transfer the thresholds values for a single line from right to left, double-click the copy icon. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 15/15 Other CCMS Monitors Unlike all other Monitoring Types the Other CCMS Monitoring provides the opportunity to assign MTEs from other systems than the one system the actual business process step is assigned to. As an example, you could be interested in monitoring the availability from a Portal system that possesses no CCMS but is included as one business process step in your business process. Now, you could use one MTE in the CCMS of the SAP Solution Manager to monitor the heartbeat of the Portal. You could then assign the corresponding alert via Other CCMS Monitoring to business process step running on the Portal system. 1.7.4.9 Analysis and Monitoring Tools It is possible to specify analysis transactions or URL addresses (including file directories) per monitoring object. In the case of analysis transactions, these should be used to analyze errors or problems either locally in the SAP Solution Manager system itself (Call Option 1), or directly in the respective satellite systems (Call Option 2). By default, some standard transactions are maintained, for example, transaction SM37, that provides a job overview in an SAP System, is maintained for Background J obs or transaction SLG1 to have a look into the application log. It is also possible to add new transactions; this could be standard transactions or customer self-written transactions. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 16/16 Analysis & Monitoring Transacti ons On the second tab strip, it is possible to specify a URL which should be called to further analyze the given problem. This is especially interesting if you have some knowledge documents linked to a portal. You define a Short text and the URL to be called. For web pages to be called, specify the full URL, for example, http://help.sap.com. For content available on file servers specify the full file path, using the nomenclature: file://\\\<server>\..., for example, file://\\\server1\operations_documents\operations-handbook.txt Analysis & Monitoring URL The specified transactions or URLs will be available in the form of buttons within a business process step when using the monitoring later on inside the Business Process Monitoring Session. By pressing these buttons (for example, ), the user will jump directly into the corresponding transaction either in the SAP Solution Manager system (here: SAT) or the connected satellite system (here: CT1) for further analysis. For URLs, the button (for example, ) contains the short text (limited to 20 characters) from the set-up session and leads the user to the defined URL in a newly opened browser window. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 17/17 1.7.4.10 Monitori ng Acti viti es Monitoring activities should be set up for every Monitoring Object within a business process step. All monitoring objects defined within a business process step are listed here. To ensure effective monitoring and efficient problem resolution, the responsibilities should be assigned and problem resolution procedures should be defined as described in the following table. Some information is taken from the previous node Solution Support Organization. Monitoring Team Defines the team that is responsible for monitoring the relevant Monitoring Object. Use value help [F4]. Person Resp. Defines the Person who is responsible for monitoring the Monitoring Object. Use value help [F4]. Frequency Describes how often the responsible person should process the required monitoring activity. Start Time Describes at which time the responsible person should process the required monitoring activity. Problem Indicator A description about what indicates a problem. Error Handling Describes how to react on problems or errors, that is, how to solve the problem/correct the error. Escalation Path Describes the escalation path in case that the person responsible could not solve the problem. Persons who can be contacted should be maintained here. Additional information related to this business process step can be entered in the tables Monitoring Activities, Error Handling, Restart of Step and Escalation Path. This information would be valid for the whole business process step and helps users who have to carry out the monitoring and who are not so familiar with that particular business process. 1.7.4.11 Noti ficati ons Notifications can be set up for the whole business process or for each business process step individually. There are two types of notifications: Workflow notifications and Support notifications. Workflow notifications allow sending messages in case of alerts to a specified Recipient. This could be an e-mail or an SAPOffice mail. Support notifications allow the setting up of a service desk message in case of an alert. The information entered for the service desk message serves as a template. The service desk message can be created manually or automatically. On business process level, it is possible to define notifications for the whole business process, that is, as soon as the business process gets an alert status, notifications will be triggered. Alternative notifications can be defined for every Monitoring Type individually, for example, all alerts related to all background jobs of the business process are forwarded to a defined e-mail address. Notifications defined on business process step level will overrule the configuration made on business process level for this particular step. 1.7.4.11.1 Workflow Notification Sender Must be a user within in the monitoring client of SAP Solution Manager. This user can be even a system user without any roles or profiles, but the user must have a valid e-mail address that is known by the used mail-server Recipient Depending on the Recipient Type the recipient name is required. This could Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 18/18 Address be any e-mail address, an SAP user name in the same system, a Remote SAP name or a shared distribution list. In the case of an SMS, you need to enter SMS:<cell phone or pager number> Reci. Type There are currently 5 different Recipient Types: U (e-mail), K (for SMS and Pager), B (SAP user name), R (Remote SAP name) and C (shared distribution list). No. of Yellow Alerts The number of YELLOW alerts that may occur before an automatic notification is triggered No. of Red Alerts The number of RED alerts that may occur before an automatic notification is triggered Max Wait Time [h] Once the maximum wait time [hours] has elapsed, a notification is created, even if the thresholds are not exceeded RED Only To restrict this mechanism only to red alerts, the flag in column 'RED Only' must be set. Detailed Triggers a long text for e-mails or SAPOffice mails, for example, name of the solution, name of the business process step, ) 1.7.4.11.2 Support Notifications Priority Defines the priority of the Support Notification. Queue Defines the support component on which the message is put. This component must exist within the service desk. Processor Defines a default processor who should process the message. The processor must be known within the service desk and must be an SAP user name that is defined as a Business Partner with the role Employee. Text Template Text templates can be defined that will then be available for service desk messages manually created for alerts. Automatic Support Notifications will be created automatically depending on the alert thresholds. Reporter Necessary when service desk messages are created automatically. Must be an SAP user name who is defined as a Business Partner with the role General. Num. of YELLOW Alerts Necessary when service desk messages are created automatically, for example, after 10 yellow alerts a service desk message should be created. Num. of RED Alerts Necessary when service desk messages are created automatically, for example, after 5 red alerts a service desk message should be created. If, in addition to queue, processor, priority, and reporter, either one of the columns Num of YELLOW Alerts or Num of RED Alerts is filled with a value the automatic Support Notification creation is configured. If both columns are filled with a value, the automatic Support Notification creation works with a logical OR operation. Hence, with the figures in the table above the system would create a Support Notification if either more than 9 yellow alerts OR more than 4 red alerts exist, for which no Support Notification has been created yet. 1.7.5 Business Process Monitoring Process For a successful and efficient implementation of a Business Process Monitoring concept, a process for the execution of the monitoring concept has to be defined. This includes the definition and assignment of the Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 19/19 roles and responsibilities involved. It has to be defined who is supposed to carry out which activity within the process and how communication between the different roles within the support organization is supposed to take place. A Business Process Monitoring concept has to be tightly integrated with the support organization. This includes the integration with the Incident/Problem Management process and the Change Management process. These processes have to be adjusted to the Business Process Monitoring concept so that communication and escalation procedures are adequate to support the Business Process Monitoring concept including the final communication of open alerts to SAP. Wherever communication connected with Business Process Monitoring happens outside these support processes, separate communication and escalation paths and procedures have to be defined. Please see the above mentioned separate Best Practice for General Business Process Management for further details. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 20/20 2 Business Process Monitoring for Servi ce Parts Planning Service Parts Management (SPM) is a comprehensive, end-to-end solution for supporting and managing the extended service parts network. It encompasses the entire range of service parts management activities, including planning, procurement, warehousing, order fulfillment, collaboration and analytics. The SAP solution for service parts management was developed in a system landscape containing SAP ECC, SAP CRM, SAP SCM (including SAP Advanced Planning and Optimization (APO) Service Parts Planning (SPP)), SAP Supply Network Collaboration (SNC), and SAP Extended Warehouse Management (EWM)), SAP GRC Global Trade Services (GTS) and SAP NetWeaver (including SAP Process Integration (SAP PI) and SAP Business Information Warehouse (SAP BI)). This section will show you, based on an example scenario, what business process monitoring for Service Parts Planning (SPP) with SAP SCM APO should look like. It will introduce you to generic thoughts and ideas how to identify a business process step you could keep an eye on and makes you familiar with how to choose the most promising monitoring possibilities from the available ones. To make this clearer to you, we have situated the example process in the fictional company AutoMan. 2.1 Sample Scenario AutoMan is a car service parts provider. Its main business is to sell service parts of cars. AutoMan gets service parts from different suppliers, distributes them through its supply chain network warehouses at diverse levels, and provides them finally to customers car dealers. To improve the service level and optimize its operation costs, AutoMan needs a planning tool to enable its service parts distribution network: to forecast parts demand to derive optimal stocking levels for each location based on installed base and service levels to plan parts replenishment and to rebalance the inventory within the network The planning tool AutoMan uses is Service Parts Planning (SPP). The following chapter takes you step by step through the 10 core business processes steps, explaining where and how you can identify focus points for Business Process Monitoring. For each business process step, the most effective way for Business Process Monitoring in the context of the example is highlighted. 2.2 Business Process Service Parts Planning The graphic below shows the standard 10 steps in SPP process. SPP is a component of SAP SCM APO. It receives sales order data from SAP CRM. This data is maintained as demand history in the BI (Business Intelligence) part of APO. It is used to plan inventory for products at locations (step 2 and step 5) and to calculate forecasts (step 4). With these results, SPP can evaluate surplus or obsolete stocks (step 6). Further, DRP run (step 7) organizes replenishment planning within a bill of distribution (BOD) distribution network for a product. The planned procurement will then be approved and sent to SAP ECC, where the procurement can be executed. The results return to SPP and then deployment (step 9) controls the distribution of incoming goods within the BOD on the basis of current demand. Afterwards, inventories within a BOD are balanced. The planned stock transfers are sent to ECC for execution. In SPP, Planning Service Manager (PSM) is used for planning in background in general. Users can schedule the planning services, which are needed for a business process, in a planning profile. The PSM then runs this planning profile in the background according to the settings. The program for PSM is /SAPAPO/PE_EXEC, transaction /SAPAPO/PE_RUN, the results can be reviewed in PSM application log (transaction: /SAPAPO/PE_LOG_DISP). Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 21/21 Note: Each section about a business step will be structured in the following way, where the X stands for the Business Process Step number: 2.2.X.1 Description 2.2.X.2 Monitoring Requirements 2.2.X.3 Monitoring Objects in SAP Solution Manager 2.2.X.4 Further Monitoring Objects (if applicable) 2.2.X.5 Monitoring without SAP Solution Manager 2.2.X.6 How to Find Meaningful Thresholds per Monitoring Object 2.2.X.7 Background J ob Scheduling Requirements (if applicable) SPP Business process Please note that this chapter only focuses on describing Business Process Monitoring for the steps carried out in SAP APO as shown in the graphic above. Business Process Monitoring for the steps executed in SAP CRM or SAP ECC is not part of it. Available Monitoring objects for the scenario Procure-to-stock (using further solutions like SNC, EWM and ERP) are briefly described in section 4.2 in the Appendix of this document. 2.2.1 Business Process Step 1: Capture Demand History 2.2.1.1 Descripti on General Information: AutoMan uses SAP CRM to manage customers. With the BI workbench (transaction: RSA1) in APO, the system extracts SAP CRM sales order data to SAP APO BI and saves it in the DataStore object 0CRM_SALO. The InfoSource 80CRM_SALO takes its data from this DataStore object. This data transfer between CRM and APO uses standard IDOCS with RFC connection. Then the system uses update rules to SAP APO (1) Capture Demand History Host - MOBILE Sales Orders Stock Transfer Execution Procurement Execution SAP CRM SAP ECC (2) Stocking and De- Stocking (3) Manage Demand History (4) Forecasting (5) Economic Order Quantity & Safety Stock (6) Surplus & Obsolescence Planning (7) Distribution Requirements Planning (8) Procurement Approval (9) Deployment (10) Inventory Balancing Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 22/22 process and check the data, and saves it as demand history in the InfoCube 9ADEMAND, together with the raw data in the DataStore object 9ARAWDAT (also see step 3). The system captures the demand history in the InfoCube 9ADEMAND as follows: - The system aggregates the demand in weeks. - The system aggregates the demand in months. - The system aggregates the demand in posting periods. - The system aggregates the demand along the BOD. In doing so, the system captures both the demand history of a product at each stockholding location and at each entry location. However, the system only uses the demand history of the stockholding location for forecasting. The system creates the yearly demand history that both phase-out planning and surplus and obsolescence planning require. To do so, the system uses the data in the InfoCube 9ADEMAND and extracts it into the InfoCube 9ADEMANN. Specifi c Information As an alternative to the process described above, you can also load sales order data from other sources, such as from a flat file or a CSV file, or from SAP ECC. If the sales orders come from an external flat or CSV file, the InfoSource 9A_SPP_CD_CSV_LOAD is used instead of 80CRM_SALO. AutoMan processes sales orders loading at a monthly base, always at the beginning of a month. In RSA1, the processes can be scheduled as background job. 2.2.1.2 Monitori ng Requirements: Error Monitoring: It is important to monitor if the data from CRM are loaded to APO BI successfully. That means if the data loaded is complete and if all data is correct. Performance Monitoring: The data load should be finished in a timely manner. Whether performance monitoring is necessary depends on the individual business requirements. It depends on the data volume and the time window for the load. Usually, the initial load takes the most time. Later, if the data load only aims to update, the load time could be much shorter. Data Consistency Requi rements: The data loaded to APO BI should be consistent to the original data in CRM. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 23/23 2.2.1.3 Monitoring Objects in SAP Solution Manager Monitori ng Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection IDoc Monitoring (IMIDOC01) (For data exchange between CRM and APO BI via IDoc) On obj ect l evel: Direction, Port, Partner number, Partner type, Partner function, Message type, Basic type, Message code, Message function, IDoc age. (in hours) On key-fi gure l evel : Status number(s), Status message qualifier, Status message ID, Status message number, Status age (in min) (IDoc types are RSREQ, RSSEND and RSINFO) Delta monitor: number of suitable IDocs since the last data collection Total number monitor: number of suitable IDocs for the last x days BD87, WE05 DeltaCheck: every two hours Total Check for erroneous Idocs: Daily before data processing in BI starts with a considerable time frame between the Data Collector run and the start of data processing in BI in order to have enough time to solve any errors Monitoring might detect qRFC Monitor (IMQRFCMO) (Status Monitoring of the queue set up for data exchange between the CRM system and the BI- part of SAP APO) (The queue names start with CF*) qRFC direction, RFC destination, Queue group, Command string of SMD qRFC backlog coll., Command string of SMD qRFC status coll. Number of entries with critical status in group Age of oldest critical status in group Combination of "Entries" and "Age" in critical state Number of entries with interim status in group Age of oldest interim status in group Combination of "Entries" and "Age" in interim state SMQ1, SMQ2, SM59 Hourly (or even more often) Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 24/24 qRFC Monitor (IMQRFCMO) (Backlog Monitoring of the queue set up for data exchange between the CRM system and the BI- part of SAP APO) (The queue names start with CF*) qRFC direction, RFC destination, Queue group, Command string of SMD qRFC backlog coll., Command string of SMD qRFC status coll. Number of individual queues in group Total number of entries in all queues of group Average number of entries per queue in group Maximum number of entries per queue in group Age of oldest entry in group Combination of "Total entries" and "Oldest age" SMQ1, SMQ2, SM59 Hourly (or even more often) BI Query Alert Collector - KPI in BI Query (BOBIQUAC) (To check data stored in APO BI) RFC Destination (from managed system to BI system), Info Provider (of BI system), BI queries (of that Info provider), Description of the BI query KPI in BI Query (single value), KPI in BI Query (max. values), KPI in BI Query (#of values) Once per day BI Consistency Check Result Collector (DBICCRC) Compare Result DSO, Fieldname and Select-Options for Filter 1 - 3 Differences in result column 1, Differences in result column 2, Differences in result column 3, Differences in result column 4, Differences in result column 5, Age of last consistency check result Once per day File Monitoring (BOFILMON) (If flat files are used to load sales order data into APO BI) File Path, File Name, Pattern, User (File Creator) Creation Time of File, File Size, File Age (in min) AL11 Once per day (or more frequently depending on the business requirements how often data from flat files is imported) Background J ob Monitoring for all processes scheduled in transaction RSA1 in the APO BI system (J ob names starting with BI_*) Background J ob Name, Variant, Event Parameter and Event ID (in case process chains are used) Start Delay, End Delay, Maximum Duration, J ob Cancellation, J ob Log Messages, J ob Log Content SM37 Data Collectors to be scheduled to run only during timeframe of planned J ob Execution and to run every 5 minutes during this time frame Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 25/25 2.2.1.4 Monitoring without SAP Solution Manager If IDoc transfer is used, you should use transactions BD87 and WE05 to check for erroneous messages at least every two hours. The status, runtime, and job logs of Background J obs can be analyzed using transaction code SM37 in the managed system. If you are using qRFC for data transfer, the status of your qRFC queues can be monitored using transaction codes SMQ1 or SMQ2. In case of problems with the setup of your qRFC connection, use transaction SM59 to check the setup of the respective RFC Connection. If you use Flat Files to import data into your system, you can also use transaction code AL11 to check the files directories on your SAP system. 2.2.1.5 How to Find Meaningful Thresholds for Each Monitoring Object The definition of meaningful thresholds for each Monitoring Object needs to be done in close cooperation with your business department. It is important that you clearly define what data the data collectors measure, how often they run, and what the business requirements are for the analyzed part of the business process step. Furthermore, it is important to review the defined thresholds on a regular basis to ensure that they are set according to the business requirements that might change over time. 2.2.2 Business Process Step 2: Stocking and De-stocking 2.2.2.1 Descripti on General Information: The planning services Stocking and Destocking make a to stock or not to stock decision for each location product at the start of inventory planning. The result of these planning services is to set a replenishment indicator on each location product. According to the indicator, the system orientates itself in the further planning: to keep stock or not. During these planning services: The system checks the demand of all customer-facing locations. If a customer-facing location has a high demand, it is advisable to make a Stocking decision. For low demand, a Destocking decision is advisable. The Destocking decision service checks if there is an exclusion reason for the corresponding location product. If so, the Destocking decision does not perform any more checks and sets the Not Stocked, Locked indicator, as well as the blocking indicator for the corresponding location product. This means that the system cannot build up stock of this location product, and the Destocking service cannot change the replenishment indicator. The system checks the entries in the decision tables. Based on these entries, the system then decides whether to plan stocking or Destocking for each location product. For the locations for which the system plans stocking according to the decision tables, the stocking service checks whether this stocking is also allowed according to the exception rules. The system transfers the Stocking and Destocking decisions made for the customer-facing locations to the corresponding parent locations. These planning services are carried out in PSM - either in background or interactively. A planning profile needs to be defined for the service. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 26/26 Specifi c Information: Additional triggers for the stocking service can be demanded at a non-stock location or changes to the virtual locations for consolidated ordering. Important settings: Servi ce Profiles control the definition of the stocking and de-stocking decisions (in Customizing) Decision tables define criteria according to which the system decides to either stock or to de-stock (transaction: /SAPAPO/SPPINVPDEC) Location exclusion rules responsible for the exclusion reasons for the locations (in customizing & transaction: /SAPAPO/PINV_EX_MAIN ) 2.2.2.2 Monitori ng Requirements: Error Monitoring: It is necessary to check if these planning services run successfully in PSM. The results of these planning services can be seen in the PSM application log (transaction: /SAPAPO/PE_LOG_DISP). And the run status of a run in PSM can be seen in background job log. Performance Monitoring: If a fixed time window is defined for these planning services, you need to monitor the performance of corresponding PSM run. In our experience, the access to historical data in APO BI takes quite a long time. 2.2.2.3 Monitoring Objects in SAP Solution Manager Monitori ng Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Dialog Performance Monitor (BOPERFMO) (For Monitoring response time of transaction code /SAPAPO/PE_RUN) Transaction Code (Value 1), Function Code (Value 2), Call Type, User Pattern, Instances Total Response Time, Database Response Time, Total Response Time (Data vol.- depend.) STAD, ST03N Every two hours Background J ob Monitoring for program /SAPAPO/PE_EXEC Background J ob Name, Variant, User (Note: The planning profile is visible in the job log) Start Delay, End Delay, Out of Time Window, Maximum Duration, J ob Cancellation, J ob Log Messages, J ob Log Content SM37 Daily (or more frequently in case this job is executed more than once per day), Data Collectors to run every 5 minutes during job execution 2.2.2.4 Further Monitoring Obj ects Monitori ng Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Results of planning services in PSM application log Subobjects (Services), Date and Time of Planning Run, User that triggered Log PSM Application Log Content Transaction Code /SAPAPO/PE_LOG_DISP Daily Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 27/27 2.2.2.5 Monitoring without SAP Solution Manager The Dialog Response Time of transaction code /SAPAPO/PE_RUN can be checked in transaction code STAD or ST03N. The status, runtime, and job logs of Background J obs can be analyzed using transaction code SM37 in the managed system. 2.2.2.6 How to Find Meaningful Thresholds for Each Monitoring Object The definition of meaningful thresholds for each Monitoring Object needs to be done in close cooperation with your business department. It is important that you clearly define what data the data collectors measure, how often they run, and what the business requirements are for the analyzed part of the business process step. Furthermore, it is important to review the defined thresholds on a regular basis to ensure that they are set according to the business requirements that might change over time. 2.2.3 Business Process Step 3: Manage Demand History 2.2.3.1 Descripti on In this step, the system adjusts the captured demand history according to the requirements of SPP. The manual adjustment of demand history can be executed in the system with transaction /SAPAPO/SPPDMDH. To ensure that the demand history reflects changes, the system also adjusts the demand history automatically when various events occur and realigns the data. The system initiates data realignment of the demand history either with triggers or you have to have scheduled it as a regular service in the Planning Service Manager (PSM). The following table provides an overview of the events for which data realignment is necessary and which planning services perform this realignment: Event Pl anning Service Technical Name of Pl anning Servi ce Triggered by Change to location determination procedure SPP: Data Realignment for Loc.Det.Schema SPP_PDEM_SERPAT_RLG --- Stocking or Destocking decision SPP: Data Real. For Stocking/Destocking SPP_PDEM_STOCKING_RLG SPP_REPL_INDI_CHANGE Change to TPOP status SPP: Data Realignment for TPOP SPP_PDEM_TPOP_RLG SPP_NON_TPOP and SPP_TPOP Assignment of future BOD to product SPP: Create Demand History Future BOD SPP_PDEM_BOD_ASSIGN SPP_NEW_BOD_ASSIGN Deletion of future BOD assignment SPP: Delete Demand History Future BOD ( SPP_PDEM_BOD_DELETE SPP_BOD_DELETE Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 28/28 Future BOD becomes valid SPP: Data Realignment for BOD Change SPP_PDEM_BOD_VALID --- Suppression SPP: Data Realignment for Suppression SPP_PDEM_SUPERSESSION_RLG --- Promotion SPP: Data Realignment for Promotion SPP_PDEM_PROMOTION_RLG --- Change to final demand SPP: Adjustment of Demand History SPP_PDEM_OVR_RLG 2.2.3.2 Monitori ng Requirements: Error Monitoring: It is necessary to check the results of the realignment. The status of the realignment can be reviewed with transaction /SAPAPO/PDEM_RLGSTEP, and the process of realignment can be reviewed in PSM application log or with general application log list (transaction SLG1). Performance Monitoring: If the performance of data realignment needs to be monitored depends on the frequency of this services and the fixed time window. Data Consistency Requi rements: The update of the demand history only takes place in SCM APO, the original data in SCM CRM do not need to be updated accordingly. Monitori ng Objects: Triggers need to be activated for regeneration of the demand history (SPP_BOD_DELETE, SPP_NEW_BOD_ASSIGN, SPP_REPL_INDI_CHANGE) and for setting the planning services for demand history creation (SPP_RLG_DONE, SPP_RLG_DONE) 2.2.3.3 Monitoring Objects in SAP Solution Manager Monitoring Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Dialog Performance Monitor (BOPERFMO) (For Monitoring response time of transaction code /SAPAPO/SPPDMDH) Transaction Code (Value 1), Function Code (Value 2), Call Type, User Pattern, Instances Total Response Time, Database Response Time, Total Response Time (Data vol.- depend.) STAD, ST03N Every two hours Application Log (Transaction Code SLG1) for Object /SAPAPO/PE and corresponding sub- objects Object, Sub-Object, User, Transaction, Program Total number of messages, number of critical messages, Runtime, Planning Scope, Planning Results SLG1 Every two hours Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 29/29 2.2.3.4 Further Monitoring Obj ects Monitori ng Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Results and status of realignment Info Provider, Realignment Status, Validity Date, Author, Last Changed by, Generated Realignment Step, Generation Program Status of realignment steps Transaction Code /SAPAPO/PDEM_RLGSTEP Every two hours Realignment processing Subobjects (Services), Date and Time of Planning Run, User that triggered Log PSM Application Log Content Transaction Code /SAPAPO/PE_LOG_DISP Daily 2.2.3.5 Monitoring without SAP Solution Manager The Dialog Response Time of transaction code /SAPAPO/SPPDMDH can be checked in transaction code STAD or ST03N respectively. The general application log can be viewed in transaction code SLG1. 2.2.3.6 How to Find Meaningful Thresholds for Each Monitoring Object The definition of meaningful thresholds for each Monitoring Object needs to be done in close cooperation with your business department. It is important that you clearly define what data the data collectors measure, how often they run and what the business requirements are for the analyzed part of the business process step. Furthermore it is important to review the defined thresholds on a regular basis to ensure that they are set according to the business requirements that might change over time. 2.2.4 Business Process Step 4: Forecasti ng 2.2.4.1 Descripti on General Information: The forecasting service covers the whole life cycle of a product from phase-in planning for new products, through various types of product interchangeability, to phase-out planning for products in discontinuation. The forecasting service is flexible in reacting to changing demand, and uses various forecast models to plan individually for future demand for products that have differing sales behavior. You can either schedule the forecast run as a regular PSM planning service or you can start it manually on the Interactive Forecasting screen (transaction: /SAPAPO/SPPFCST). During the forecast run, the system calculates the forecasting results at location product level. If you are not satisfied with the results, you can make manual corrections or adjustments to the demand history, forecast profiles (transaction /SAPAPO/SPPFCSTPRF), and PSM service profiles, and then restart the forecast run. The results of forecasting are stored in key figure Final forecasts in TSDM (database). Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 30/30 Composi te Forecast There are various functions available within the forecast service. If you want to use several of these functions, you must schedule the forecast service more than once and assign a different service profile each time. To achieve a better quality for the forecasts, PSM can execute the functions in figure above in a fixed sequence. This is called composite forecasts. AutoMan uses composite forecasts. Its functions include: Model Evaluation (Automatic Model Evaluation): consists of Triggs tracking signal and tripping. Triggs tracking signal checks whether the forecast model is still optimal or whether there is a systematic forecasting error. Tripping reinitializes basic values and the deviation of an existing forecast model and shortens the demand history used for forecast creation. Model Selection (Automatic Model Selection): You can use it to automatically determine the forecast model best suited to a specific location product. Smoothing Parameter Tuning (Rough Tuning): For the forecast models that consider smoothing factors during forecast creation, you can automatically optimize these smoothing factors by this function. Forecast Calculation (Forecast Approval): calculates the final forecast for each location product and checks which forecast results require manual approval according to rules that you define. The system automatically approves all other forecast results and provides these results to other SPP planning services. Forecast approval is realized as a PSM planning service. However, the system also performs forecast approval when you save the forecast results on the Interactive Forecasting screen manually. Additional information: Besides the above mentioned functions, forecast services also include the following functions: Historical Forecasts: to ensure an exact planning, the system records all calculated forecast results as historical forecasts. You can also schedule the PSM planning service Recalculation of the Forecast in the Past. If the forecast model changes, the system triggers this planning service so that it creates historical forecasts for the new combination of location product and forecast model. Phase-In Planning: uses values based on experience to calculate forecast values for new products that do not yet have any historical data. Phase-in planning is realized as a PSM planning service. Phase-Out Planning: calculates forecast values at entry location level for products in discontinuation. Phase-out planning is realized as a PSM planning service. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 31/31 2.2.4.2 Monitori ng Requirements: Error Monitoring: It is important to check the results of forecasts. They can be reviewed in the Interactive Forecasting screen (transaction: /SAPAPO/SPPFCST) or application log of PSM. If the results are not satisfying, planning parameters and forecast models can be modified, and further forecasts run can be started manually or scheduled via PSM. Performance Monitoring: Whether the performance of forecasting needs to be monitored depends on the frequency of these services and the fixed time window. Especially for composite forecast includes several services and it run time should be controlled strictly. 2.2.4.3 Monitoring Objects in SAP Solution Manager Monitoring Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Background J ob Monitoring for program /SAPAPO/PE_EXEC Background J ob Name, Variant, User (Note: The planning profile is visible in the job log) Start Delay, End Delay, Out of Time Window, Maximum Duration, J ob Cancellation, J ob Log Messages, J ob Log Content SM37 Daily (or more frequently in case this job is executed more than once per day), Data Collectors to run every 5 minutes during job execution Dialog Performance Monitor (BOPERFMO) (For Monitoring response time of transaction code /SAPAPO/SPPFCST) Transaction Code (Value 1), Function Code (Value 2), Call Type, User Pattern, Instances Total Response Time, Database Response Time, Total Response Time (Data vol.- depend.) STAD, ST03N Every two hours Dialog Performance Monitor (BOPERFMO) (For Monitoring response time of transaction code /SAPAPO/SPPFCSTPRF) Transaction Code (Value 1), Function Code (Value 2), Call Type, User Pattern, Instances Total Response Time, Database Response Time, Total Response Time (Data vol.- depend.) STAD, ST03N Every two hours 2.2.4.4 Further Monitoring Obj ects Monitori ng Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Forecast results in PSM application log Subobjects (Services), Date and Time of Planning Run, User that triggered Log PSM Application Log Content Transaction Code /SAPAPO/PE_LOG_DISP Daily Forecast results in Interactive Forecasting Screen Detailed forecast results Transaction Code /SAPAPO/SPPFCST Daily Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 32/32 2.2.4.5 Monitoring without SAP Solution Manager The Dialog Response Time of transaction codes /SAPAPO/SPPFCST and /SAPAPO/SPPFCSTPRF can be checked in transaction code STAD or ST03N respectively. The status, runtime, and job logs of Background J obs can be analyzed using transaction code SM37 in the managed system. 2.2.4.6 How to Find Meaningful Thresholds for Each Monitoring Object The definition of meaningful thresholds for each Monitoring Object needs to be done in close cooperation with your business department. It is important that you clearly define what data the data collectors measure, how often they run, and what the business requirements are for the analyzed part of the business process step. Furthermore, it is important to review the defined thresholds on a regular basis to ensure that they are set according to the business requirements that might change over time. 2.2.5 Business Process Step 5: Economi c Order Quantity & Safety Stock 2.2.5.1 Descripti on General information: In this step, the system plans the economic order quantity (EOQ) purchase order, and safety stock (SFT) together, to optimize the stockholding and purchasing costs, as well as to ensure target service level. This planning can either be carried out manually in transaction /SAPAPO/SPPINVP, or planned as a service in PSM (service name: SPP_EOQSFT_SERVICE). The results are stored in key figures economic order quantity and Locations own safety stock in TSDM. The system calculates the EOQ and SFT with mutual dependence. As a basis for the combined calculation, the system chooses whether to use normal distribution or Poisson distribution as the calculation model for each location product depending on its sales behavior. Normal distribution is suitable for products with constant demand and Poisson distribution is suitable for products with intermittent demand. The model selection for a location product is made with transaction /SAPAPO/PINV_MS_MAIN. For normal distribution, the system uses the forecast values for demand in pieces as the basis for the combined calculation of EOQ and SFT. For Poisson distribution, the system uses the forecast values for the number of order items as the basis, and then calculates the demand in pieces using the average demand size per order item. The system also decides whether to plan the stock of each location product constantly or not constantly. Constantly means that the planned EOQ and SFT are the same for each period. Not constantly means that results vary for each period. This is defined in customizing. Important settings: Servi ce Profile Service profile for EOQ/SFT calculation. Forecast Strategy Forecast types and decides whether they are to follow constant or non-constant planning Master Data In the location product master data on the SPP Inventory Planning tab: EOQ/SFT Calculation field: indicates whether the system is to use Normal or Poisson distribution as the statistical calculation model for the combined calculation of EOQ and safety stock Fix EOQ Period field: you can choose between EOQ Manually Locked, EOQ POD Manually Locked, and Unlocked Min. EOQ Per. and Max. EOQ Per. Fields: to indicate the minimum and maximum number of days that an EOQ period may last. Safety Stock field: the system considers your manual entry until the next planning run, otherwise this is automatically filled Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 33/33 SFT Parent Loc. Field: the inventory planning service enters the proportion of safety stock of the parent location that is to be forwarded to the location Addl. Safety Stock field: number of days of demand for which the system is to schedule additional safety stock. OT-Dep. Sfty St. % field: proportion of safety stock that must be reserved for emergencies Minimum PO Quantity field: minimum purchase order quantity of the supplier (in pieces) - In the location product master data on the SPP Inventory Balancing tab: Maximum RP (Days) field, reorder point range of coverage 2.2.5.2 Monitori ng Requirements: Error Monitoring: It is important to check the results of EOD and SFT planning. They can be reviewed with transaction /SAPAPO/SPPINVP or application log of PSM. Performance moni toring: Whether the performance of EOD and SFT planning needs to be monitored depends on the frequency of these services and the fixed time window. 2.2.5.3 Monitoring Objects in SAP Solution Manager Monitori ng Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Dialog Performance Monitor (BOPERFMO) (For Monitoring response time of transaction code /SAPAPO/SPPINVP) Transaction Code (Value 1), Function Code (Value 2), Call Type, User Pattern, Instances Total Response Time, Database Response Time, Total Response Time (Data vol.- depend.) STAD, ST03N Every two hours Background J ob Monitoring for program /SAPAPO/PE_EXEC Background J ob Name, Variant, User (Note: The planning profile is visible in the job log) Start Delay, End Delay, Out of Time Window, Maximum Duration, J ob Cancellation, J ob Log Messages, J ob Log Content SM37 Daily (or more frequently in case this job is executed more than once per day), Data Collectors to run every 5 minutes during job execution 2.2.5.4 Further Monitoring Obj ects Monitori ng Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Results of service in PSM application log Subobjects (Services), Date and Time of Planning Run, User that triggered Log PSM Application Log Content Transaction Code /SAPAPO/PE_LOG_DISP Daily Results of EOD and SFT planning Detailed results of EOD and SFT planning Transaction Code /SAPAPO/SPPINVP Daily Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 34/34 2.2.5.5 Monitoring without SAP Solution Manager The Dialog Response Time of transaction code /SAPAPO/SPPINVP can be checked in transaction code STAD or ST03N. The status, runtime, and job logs of Background J obs can be analyzed using transaction code SM37 in the managed system. 2.2.5.6 How to Find Meaningful Thresholds for Each Monitoring Object The definition of meaningful thresholds for each Monitoring Object needs to be done in close cooperation with your business department. It is important that you clearly define what data the data collectors measure, how often they run and what the business requirements are for the analyzed part of the business process step. Furthermore, it is important to review the defined thresholds on a regular basis to ensure that they are set according to the business requirements that might change over time. 2.2.6 Business Process Step 6: Surplus & Obsolescence Pl anning 2.2.6.1 Descripti on General Information: During surplus and obsolescence planning, the system identifies surplus and obsolete stock within a bill of distribution (BOD). If the warehouse stock and the stock in transit of a product within a BOD are greater than the probable demand during a certain time period, this part of the stock of a product is described as surplus stock. If a product fulfils the following conditions, it is described as obsolete stock: The product is a service part of a product that you no longer produce and whose mandatory retention period has elapsed, and the demand for this product is below a certain limit value. The planning process is consisted of following steps in sequence: 1. Surplus Determi nation Service This service determines the products within a bill of distribution (BOD) that could be surplus. It firstly selects products according to whether or not it is to perform surplus determination for them. The system then determines the total surplus quantity as well as the surplus quantities per location. Based on the surplus quantities per location, the system suggests surplus quantities and retention quantities, and checks whether it can automatically approve these surplus quantities for scrapping, or whether it must forward them for manual approval. You can either schedule this service regularly, for example every year or every six months, as a planning service via PSM (service name: SPP_SOS_SURPLUS_DETERMINATION), or process it manually, for example if you need more warehouse space or if you want to reduce the stock value in your warehouse (transaction /SAPAPO/SPPMSP). 2. Surplus Approval Following the surplus determination service, the planner can then approve each of these surplus quantities manually by assigning a surplus decision code to the corresponding location product (transaction: /SAPAPO/SPPSOR). Each planner has a product-specific budget for the approval. If the value of the surplus quantity exceeds this budget, a planner that has a higher budget must then issue the approval to proceed. The system triggers a scrapping for the approved surplus quantities in the ECC and EWM systems. 3. Obsolescence Check Servi ce This service checks whether the stock of a product marked as obsolete is completely used-up, if yes, it marks the product with the Obsolete indicator and sends an alert (in Alert Monitor) to inform planner, and changes the replenishment indicator according to your settings in Customizing. You can only remove the product from your assortment if this is the case. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 35/35 You can schedule the obsolescence check service as a regular planning service, for example monthly in the PSM (service name: SPP_SOS_OBSOLESCENCE_CHECK). 4. Surplus Reporting You can generate reporting for each surplus quantity and surplus value for which you have approved scrapping or another follow-on activity. These quantities and values are entered in the report for both the whole BOD and the individual locations. Surplus reporting is an automated process initiated by approving surplus quantities. The Infocube 9ASORPL is a virtual Infocube for surplus reporting, so you can use this to display reporting data in BI (Transaction RSA1), or you can create some queries for Business Explorer. Important settings: Customizing Implementation Guide (IMG) for Advanced Planning and Optimization Supply Chain Planning Service Parts Planning (SPP) Surplus and Obsolescence Planning: Make General Settings for Surplus and Obsolescence Planning Define Surplus Decision Code Define Surplus Decision Reason Code Define Service Profile for Surplus and Obsolescence Planning Master Data Surplus and Obsolescence Service area fields at: product master data, on the Properties SPP tab; location product master data, on the SPP Inv. Balancing/Surplus tab; and location master data, on the SPP tab. 2.2.6.2 Monitori ng Requirements: Error Monitoring: To fulfill the service function it is necessary to make sure that all the relevant settings in customizing and master data are correct for the planning purpose. Performance Monitoring: Normally there should be no problem with the performance of this service. But if the business situation only allows short time window for this step, the performance should be monitored. 2.2.6.3 Monitoring Objects in SAP Solution Manager Monitori ng Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Dialog Performance Monitor (BOPERFMO) (For Monitoring response time of transaction code /SAPAPO/SPPMSP) Transaction Code (Value 1), Function Code (Value 2), Call Type, User Pattern, Instances Total Response Time, Database Response Time, Total Response Time (Data vol.- depend.) STAD, ST03N Daily Dialog Performance Monitor (BOPERFMO) (For Monitoring response time of transaction code /SAPAPO/SPPSOR) Transaction Code (Value 1), Function Code (Value 2), Call Type, User Pattern, Instances Total Response Time, Database Response Time, Total Response Time (Data vol.- depend.) STAD, ST03N Daily Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 36/36 Background J ob Monitoring for program /SAPAPO/PE_EXEC (For both the Surplus Determination Service as well as for the Obsolescence Check Service.) Background J ob Name, Variant, User (Note: The planning profile is visible in the job log) Start Delay, End Delay, Out of Time Window, Maximum Duration, J ob Cancellation, J ob Log Messages, J ob Log Content SM37 Monthly (or even less frequent in case this job is executed less than once per month), Data Collectors to run every 5 minutes during job execution. BI Query Alert Collector - KPI in BI Query (BOBIQUAC) (To check data utilized in the Surplus Reporting) RFC Destination (from managed system to BI system), Info Provider (of BI system), BI queries (of that Info provider), Description of the BI query KPI in BI Query (single value), KPI in BI Query (max. values), KPI in BI Query (#of values) Daily BI Consistency Check Result Collector (DBICCRC) Compare Result DSO, Fieldname and Select-Options for Filter 1 - 3 Differences in result column 1, Differences in result column 2, Differences in result column 3, Differences in result column 4, Differences in result column 5, Age of last consistency check result Daily Background J ob Monitoring for all processes scheduled in transaction RSA1 in the APO BI system (J ob names starting with BI_*) Background J ob Name, Variant, Event Parameter and Event ID (in case process chains are used) Start Delay, End Delay, Maximum Duration, J ob Cancellation, J ob Log Messages, J ob Log Content SM37 Data Collectors to be scheduled to run only during timeframe of planned J ob Execution and to run every 5 minutes during this time frame 2.2.6.4 Further Monitoring Obj ects Monitori ng Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Results of planning services in PSM application log Subobjects (Services), Date and Time of Planning Run, User that triggered Log PSM Application Log Content Transaction Code /SAPAPO/PE_LOG_DISP Monthly Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 37/37 Alerts in Alert Monitor Alerts pointing to products marked with the Obsolete indicator Alert Monitor in Shortage Analysis Interface (Transaction Code /SAPAPO/SPP_CUSTOMER) Monthly 2.2.6.5 Monitoring without SAP Solution Manager The Dialog Response Time of transaction codes /SAPAPO/SPPSMP and /SAPAPO/SPPSOR can be checked in transaction code STAD or ST03N. The status, runtime, and job logs of Background J obs can be analyzed using transaction code SM37 in the managed system. 2.2.6.6 How to Find Meaningful Thresholds for Each Monitoring Object The definition of meaningful thresholds for each Monitoring Object needs to be done in close cooperation with your business department. It is important that you clearly define what data the data collectors measure, how often they run and what the business requirements are for the analyzed part of the business process step. Furthermore, it is important to review the defined thresholds on a regular basis to ensure that they are set according to the business requirements that might change over time. 2.2.7 Business Process Step 7: Distribution Requi rements Pl anning (DRP) 2.2.7.1 Description General Information: Distribution requirements planning (DRP) organizes replenishment planning within bills of distribution (BODs). DRP determines the new demands of all locations in BOD, rounds them, and aggregates them along the BOD to the entry location. On this basis, it creates scheduling agreement releases and purchase requisitions. DRP also allows for efficient checking of the planning results and a multilevel release process as required. The detailed DRP steps are as following, these steps can be run in sequence as a DRP service in PSM (SPP: DRP Service (SPP_DRP): 1. The system calculates the not-rounded net demand for a location product. The results for a location product can be displayed with DRP matrix (transaction /SAPAPO/SPPDRPM) which contains key figures with the demand, supply and inventory information. It is possible to simulate the DRP run, but the result cannot be saved - it is not possible to perform an interactive planning in the DRP matrix. 2. Then, the system rounds the net demand calculated in step 1. The rounding rules are defined in rounding profile via customizing. 3. Then, the system aggregates the net demands along the BOD from the child locations via the parent locations to the entry location. The net demands of the child locations are thus dependent demands of the parent location. 4. Afterwards, the system performs backwards scheduling over the procurement lead time. 5. The system checks whether it can perform product group procurement for the product to optimize the total ordering and stockholding costs. 6. The system then creates DRP stock transport requisitions, scheduling agreement delivery schedule lines, and purchase requisitions, these values are stored as orders in liveCache. Important settings: Customizing Implementation Guide (IMG) for Advanced Planning and Optimization under Supply Chain Planning Service Parts Planning (SPP) Distribution Requirements Planning (DRP) Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 38/38 Planning profile: Definition in Customizing for SCM Basis under Planning Service Manager Define Planning Profile: the planning profile should contain planning service SPP: DRP Service (SPP_DRP). Packaging Speci fi cation Define packaging specifications for rounding: SAP Easy Access Advanced Planning and Optimization Service Parts Planning (SPP) Environment Packaging Specification Maintain Packaging Specification. Master Data In the location product master data on the SPP Inventory Planning tab: Procurement Lead times - Different time spans that are defined between certain planning times in Service Parts Planning (SPP). DRP Stability rules - determine the conditions between the individual DRP Horizons, and which activities are allowed during them. Consolidated Ordering - for location products whose locations are geographically close and that have a low demand. Pre-Season Safety Stock Shift - shift the safety stock for location products with seasonal demand. Supplier Shutdown - considers supplier shutdowns, such as vacation times, during planning. Stockholding Costs - calculated by the procurement costs multiplied by this factor. Planning-Relevance/Planning Lock - DRP does (or not) consider this location product during planning. Rounding - special rounding rules to avoid internal costs that are higher than the value of the purchase order. Anticipated Demand Coverage - to smooth seasonal demand patterns. 2.2.7.2 Monitori ng Requirements: Error Monitoring: It is important to check the results of DRP, if the stock transport requisitions, scheduling agreement delivery schedule lines, and purchase requisitions are generated correctly. Performance Monitoring: It is important to make sure that the DRP service finishes within the defined time window, so that further business processes can go on, and the supplier can receive the orders timely. 2.2.7.3 Monitoring Objects in SAP Solution Manager Monitoring Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Dialog Performance Monitor (BOPERFMO) (For Monitoring response time of transaction code /SAPAPO/SPPDRPM) Transaction Code (Value 1), Function Code (Value 2), Call Type, User Pattern, Instances Total Response Time, Database Response Time, Total Response Time (Data vol.- depend.) STAD, ST03N Every two hours Background J ob Monitoring for program /SAPAPO/PE_EXEC Background J ob Name, Variant, User (Note: The planning profile is visible in the job log) Start Delay, End Delay, Out of Time Window, Maximum Duration, J ob Cancellation, J ob Log Messages, J ob Log Content SM37 Daily (or more frequently in case this job is executed more than once per day), Data Collectors to run every 5 minutes during job execution Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 39/39 Application Monitoring (Throughput and Backlog indicators) for Purchase Requisitions (KSPUR001) Location, Prod.Planner, Product ID, Planned / Unplanned, Start (x days past), End (x days future), Older than x days PR Items created, PR Items open, PR Items overdue for conversion Daily Consistency Check LiveCache APO DB (For Procurement Scheduling Agreements and for user-defined key figures) User performing analysis, Execution mode of the analysis No of inconsistent Procurement Scheduling Agreements, User defined key figure, Age of last consistency check result /SAPAPO/OM17 Daily 2.2.7.4 Further Monitoring Obj ects Monitori ng Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Results of planning services in PSM application log Subobjects (Services), Date and Time of Planning Run, User that triggered Log PSM Application Log Content Transaction Code /SAPAPO/PE_LOG_DISP Daily Detailed results of the DRP-Service DRP Run Detailed results of the DRP-Service Transaction Code /SAPAPO/SPPDRPAPPR Daily 2.2.7.5 Monitoring without SAP Solution Manager The Dialog Response Time of transaction code /SAPAPO/PE_RUN can be checked in transaction code STAD or ST03N. The status, runtime, and job logs of Background J obs can be analyzed using transaction code SM37 in the managed system. The status of qRFC queues can be monitored using transaction codes SMQ1 or SMQ2. In case of problems with the setup of the qRFC connection, use transaction SM59 to check the setup of the respective RFC- Connection. Specific to the CIF-Interface between APO and ECC, you can also use the transactions /SAPAPO/CQ (SCM Queue Manager), /SAPAPO/CW (qRFC Monitoring for Outbound Queues) and /SAPAPO/CQINW. 2.2.7.6 How to Find Meaningful Thresholds for Each Monitoring Object The definition of meaningful thresholds for each Monitoring Object needs to be done in close cooperation with your business department. It is important that you clearly define what data the data collectors measure, how often they run, and what the business requirements are for the analyzed part of the business process step. Furthermore, it is important to review the defined thresholds on a regular basis to ensure that they are set according to the business requirements that might change over time. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 40/40 2.2.8 Business Process Step 8: Procurement Approval (DRP Approval) 2.2.8.1 Descripti on General Information: The process procurement approval is also called DRP Approval. It approves the scheduling agreement delivery schedule lines, purchase requisitions, and purchase orders suggested by Distribution Requirements Planning (DRP). Based on approval rules, the system either forwards the results of the DRP run after the mass approval to the supplier automatically via CIF, or it creates an alert. In the case of an alert, the DRP planner can change the planning results and then release or reject them manually. The system prepares the DRP results to be evaluated by the DRP planner in SAP Business Intelligence in the "Ad Hoc Reporting". The DRP planner can then view the results of the last DRP run for which he or she is responsible at location and product level, for example, via transaction /SAPAPO/SPPDRPAPPR. With the same transaction, the DRP planner can either approve or reject the planning results for which he or she is responsible. If the planner rejects the results, a new DRP run is triggered. There are two possibilities to schedule the DRP mass approval: 1. Scheduled the "SPP: DRP Approval Service" (SPP_DRP_APPROVAL) planning service in the Planning Service Manager (PSM). 2. Define DRP approval as part of the DRP service. To do so, you need to choose the Integrated DRP Approval entry in the DRP Appr. field in Customizing for the DRP service profile. In this case, you do not have to schedule the "SPP: DRP Approval" planning service; it is sufficient to schedule the "SPP: DRP Service" (SPP_DRP) planning service. At regular intervals, the system automatically transfers all approved scheduling agreement releases and purchase requisitions, and triggers the creation of scheduling agreement releases and purchase orders to ECC via CIF. In addition to automatic transfer, you can also create scheduling agreement releases and purchase orders manually. Important settings: Master Data In the location product master data on the SPP Inventory Planning tab: Approval/Releasing - system either forwards the results of the DRP run after the mass approval to the supplier automatically, or it creates an alert. Business Intelligence You have selected and activated the Business Content for DRP approval in the Business Intelligence system for SAP Advanced Planning and Optimization (SAP APO). The Business Content for DRP approval is located in the SPP: DRP Approval InfoArea (9ADRPA). You have selected and activated the following objects in this InfoArea: InfoCube SPP: DRP Run Ad Hoc Analysis (9ADRPA) with the corresponding InfoObjects The following queries: DRP Results (Active Version) (9ADRPA_Q0000) DRP Results (All Versions) (9ADRPA_Q0001) DRP Results (Acc. To Selection) (9ADRPA_Q0002) DRP: Biggest Deviations (Active Version) (9ADRPA_Q0010) DRP: Biggest Deviations (All Version) (9ADRPA_Q0011) DRP: Biggest Deviations (Acc. to Selection) (9ADRPA_Q0012) Customizing You have activated the required approval rules in Customizing for Advanced Planning and Optimization under Supply Chain Planning Service Parts Planning (SPP) Distribution Requirements Planning (DRP) DRP Approval Define DRP Approval Rules Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 41/41 2.2.8.2 Monitori ng Requirements: Error Monitoring: In the case of mass approval, it is important to make sure that the DRP approval runs successfully and the stock transport requisitions, scheduling agreement delivery schedule lines and purchase requisitions are transported to suppliers correctly. Performance Monitoring: It is important to make sure that the DRP approval finishes within the defined time window, and the stock transport requisitions, scheduling agreement delivery schedule lines and purchase requisitions are transported to suppliers timely. Data Consistency Requi rements: You should ensure the consistency of stock transport requisitions, scheduling agreement delivery schedule lines and purchase requisitions at both SPP and supplier side. 2.2.8.3 Monitoring Objects in SAP Solution Manager Monitoring Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Application Monitoring (Throughput and Backlog indicators) for Purchase Requisitions (KSPUR001) Location, Prod.Planner, Product ID, Planned / Unplanned, Start (x days past), End (x days future), Older than x days PR Items created, PR Items open, PR Items overdue for conversion Daily BI Query Alert Collector - KPI in BI Query (BOBIQUAC) (To check data stored in APO BI) RFC Destination (from managed system to BI system), Info Provider (of BI system), BI queries (of that Info provider), Description of the BI query KPI in BI Query (single value), KPI in BI Query (max. values), KPI in BI Query (#of values) Once per day BI Consistency Check Result Collector (DBICCRC) Compare Result DSO, Fieldname and Select-Options for Filter 1 - 3 Differences in result column 1, Differences in result column 2, Differences in result column 3, Differences in result column 4, Differences in result column 5, Age of last consistency check result Once per day Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 42/42 Background J ob Monitoring for program /SAPAPO/PE_EXEC Background J ob Name, Variant, User (Note: The planning profile is visible in the job log) Start Delay, End Delay, Out of Time Window, Maximum Duration, J ob Cancellation, J ob Log Messages, J ob Log Content SM37 Daily (or more frequently if this job is executed more than once per day), Data Collectors to run every 5 minutes during job execution Dialog Performance Monitor (BOPERFMO) (For Monitoring response time of transaction code /SAPAPO/SPPDRPAPPR) Transaction Code (Value 1), Function Code (Value 2), Call Type, User Pattern, Instances Total Response Time, Database Response Time, Total Response Time (Data vol.- depend.) STAD, ST03N Every two hours Background J ob Monitoring for program /SAPAPO/RDMCPPROCESS (Data transfer from APO to ECC via CIF-Interface) Background J ob Name, Variant, User (Note: The planning profile is visible in the job log) Start Delay, End Delay, Out of Time Window, Maximum Duration, J ob Cancellation, J ob Log Messages, J ob Log Content SM37 Daily (or more frequently if this job is executed more than once per day), Data Collectors to run every 5 minutes during job execution qRFC Monitor (IMQRFCMO) (Status Monitoring of the CIF- queues between ECC and APO) (The queue names start with CF* For example: CFEP* for purchase orders, CFHE* for release schedules, CFTO* for stock transport orders) qRFC direction, RFC destination, Queue group, Command string of SMD qRFC backlog coll., Command string of SMD qRFC status coll. Number of entries with critical status in group Age of oldest critical status in group Combination of "Entries" and "Age" in critical state Number of entries with interim status in group Age of oldest interim status in group Combination of "Entries" and "Age" in interim state SMQ1, SMQ2, SM59, /SAPAPO/CQ, /SAPAPO/CW, /SAPAPO/CQINW Hourly (or even more often) qRFC Monitor (IMQRFCMO) (Backlog Monitoring of the CIF-queues between ECC and APO) (The queue names start with CF* For example: CFEP* for purchase orders, CFHE* for release schedules, CFTO* for stock transport orders) qRFC direction, RFC destination, Queue group, Command string of SMD qRFC backlog coll., Command string of SMD qRFC status coll. Number of individual queues in group Total number of entries in all queues of group Average number of entries per queue in group Maximum number of entries per queue in group Age of oldest entry in group Combination of "Total entries" and "Oldest age" SMQ1, SMQ2, SM59, /SAPAPO/CQ, /SAPAPO/CW, /SAPAPO/CQINW Hourly (or even more often) Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 43/43 CIF Comparison/Reconciliation for Transaction Data (Data Consistency Monitoring between APO and ECC) Name for Save Number of inconsistent scheduling agreements, Number of inconsistent purchase requistions, Age of last consistency check result /SAPAPO/CCR Daily 2.2.8.4 Further Monitoring Obj ects Monitori ng Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Results of planning services in PSM application log Subobjects (Services), Date and Time of Planning Run, User that triggered Log PSM Application Log Content Transaction Code /SAPAPO/PE_LOG_DISP Daily Alerts in Alert Monitor Alerts generated during Mass Approval Alert Monitor in Shortage Analysis Interface (Transaction Code /SAPAPO/SPP_CUSTOMER) Daily Results of the Mass Approval DRP Run Transaction Code /SAPAPO/SPPDRPAPPR Daily 2.2.8.5 Monitoring without SAP Solution Manager The Dialog Response Time of transaction code /SAPAPO/SPPDRPAPPR can be checked in transaction code STAD or ST03N respectively. The status, runtime, and job logs of Background J obs can be analyzed using transaction code SM37 in the managed system. The status of qRFC queues can be monitored using transaction codes SMQ1 or SMQ2. In case of problems with the setup of the qRFC connection, use transaction SM59 to check the setup of the respective RFC Connection. Specific to the CIF-Interface between APO and ECC, you can also use the transactions /SAPAPO/CQ (SCM Queue Manager), /SAPAPO/CW (qRFC Monitoring for Outbound Queues) and /SAPAPO/CQINW. The consistency check between SAP APO and SAP ECC can be executed using transaction code /SAPAPO/CCR. 2.2.8.6 How to Find Meaningful Thresholds for Each Monitoring Object The definition of meaningful thresholds for each Monitoring Object needs to be done in close cooperation with your business department. It is important that you clearly define what data the data collectors measure, how often they run, and what the business requirements are for the analyzed part of the business process step. Furthermore, it is important to review the defined thresholds on a regular basis to ensure that they are set according to the business requirements that might change over time. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 44/44 2.2.9 Business Process Step 9: Deployment 2.2.9.1 Descripti on General Information: In this process, the system determines the distribution of goods within a bill of distribution (BOD). Based on the current demands determined by distribution requirements planning (DRP), deployment decides how to distribute the available goods and, if necessary, initiates this within the BOD. Goods that are not distributed by deployment stay at the parent location. Deployment is either triggered by goods receipt at a parent location (push deployment), or by current demand during the replenishment lead time of a child location (pull deployment). You can schedule the following services in the Planning Service Manager (PSM) for deployment: - SPP: Deployment Service (SPP_DEPL), this service makes decisions about the stock transfer of goods within a bill of distribution (BOD). - SPP: Push Deployment from Supplier (SPP_DEPL_FROM_SUPPLIER), this service plans that the supplier does not ship the goods to the entry location, but to the second level of the BOD. During the deployment service, the system mainly performs the following steps: 1. The system adds up the net demand of the locations during the replenishment lead time and checks whether the demand is greater or less than the distributable quantity. 2. If the net demand is greater than the distributable quantity, the system distributes this quantity according to priority tiers that you can define in Customizing. The system then performs fair-share distribution. If the distributable quantity is greater than the net demands of the locations, the system immediately performs fair-share distribution. 3. The system rounds to pack sizes during demand determination. In doing so, it determines the demand while considering the smallest permissible pack size. After fair-share distribution, the system rounds once again. The aims of rounding are to obtain order and delivery quantities that make processing easier at the supplier, when packaging, during transportation, and for storage, and to achieve pack sizes that are as large as possible. 4. The system distributes the remaining quantities. If rounding to a certain pack size occurred, remaining quantities may be left over. 5. Finally the system creates stock transport requisitions store them as orders in liveCache. The results of deployment can be reviewed with the transaction /SAPAPO/SPPDEPL under Deployment Log. With the same transaction under STO Approval, you can also release stock transport requisitions to ECC via CIF, if you have defined manual approval for them in the master data. Important settings: Configuration for DRP Servi ces refer to Business Process step 7 (above) Customizing Implementation Guide (IMG) for Advanced Planning and Optimization under Supply Chain Planning Service Parts Planning (SPP) Deployment and SCM Basis, under Planning Service Manager Define Planning Profile/ Make General Settings for Deployment/ Define Priority Tiers and Sequence Rules Master Data In the location product master data: Deployment Indicators - control the location product that pushes or pulls deployment is to consider during planning. Express Shipment - to prevent backorders, deployment can decide to deliver certain location products by express shipment. Stock Transport Orders - define how many stock transport orders can be issued per day. Procurement Lead Times - number of days that the review time and the time between deployment runs should be. Remaining Quantities controls what to do with potential remaining quantities at push deployment. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 45/45 Time-Related Supply Limit (TSL) - limits the goods quantity that you can deliver to one location. Virtual Child Location controls whether a location is also a virtual child location. 2.2.9.2 Monitori ng Requirements: Error Monitoring: It is important to make sure that the deployment runs successfully and the stock transport requisitions are generated and released correctly. Performance Monitoring: It is important to make sure that the deployment run finishes within the defined time window, and the stock transport requisitions are released in a timely manner. Throughput Monitoring: In the master data of location product, Stock Transport Orders define how many stock transport orders can be issued per day. Data Consistency Requi rements: It is important to make sure that the data keeps consistent before and after the deployment run. 2.2.9.3 Monitoring Objects in SAP Solution Manager Monitoring Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Dialog Performance Monitor (BOPERFMO) (For Monitoring response time of transaction code /SAPAPO/PE_RUN) Transaction Code (Value 1), Function Code (Value 2), Call Type, User Pattern, Instances Total Response Time, Database Response Time, Total Response Time (Data vol.- depend.) STAD, ST03N Every two hours Background J ob Monitoring for program /SAPAPO/PE_EXEC Background J ob Name, Variant, User (Note: The planning profile is visible in the job log) Start Delay, End Delay, Out of Time Window, Maximum Duration, J ob Cancellation, J ob Log Messages, J ob Log Content SM37 Daily (or more frequently in case this job is executed more than once per day), Data Collectors to run every 5 minutes during job execution Dialog Performance Monitor (BOPERFMO) (For Monitoring response time of transaction code /SAPAPO/SPPDEPL) Transaction Code (Value 1), Function Code (Value 2), Call Type, User Pattern, Instances Total Response Time, Database Response Time, Total Response Time (Data vol.- depend.) STAD, ST03N Every two hours Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 46/46 qRFC Monitor (IMQRFCMO) (Status Monitoring of the CIF-queues between ECC and APO) (The queue names start with CF*) qRFC direction, RFC destination, Queue group, Command string of SMD qRFC backlog coll., Command string of SMD qRFC status coll. Number of entries with critical status in group Age of oldest critical status in group Combination of "Entries" and "Age" in critical state Number of entries with interim status in group Age of oldest interim status in group Combination of "Entries" and "Age" in interim state SMQ1, SMQ2, SM59, /SAPAPO/CQ, /SAPAPO/CW, /SAPAPO/CQINW Hourly (or even more often) qRFC Monitor (IMQRFCMO) (Backlog Monitoring of the CIF-queues between ECC and APO) (The queue names start with CF*) qRFC direction, RFC destination, Queue group, Command string of SMD qRFC backlog coll., Command string of SMD qRFC status coll. Number of individual queues in group Total number of entries in all queues of group Average number of entries per queue in group Maximum number of entries per queue in group Age of oldest entry in group Combination of "Total entries" and "Oldest age" SMQ1, SMQ2, SM59, /SAPAPO/CQ, /SAPAPO/CW, /SAPAPO/CQINW Hourly (or even more often) 2.2.9.4 Further Monitoring Obj ects Monitori ng Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Deployment results in PSM application log Subobjects (Services), Date and Time of Planning Run, User that triggered Log PSM Application Log Content Transaction Code /SAPAPO/PE_LOG_DISP Daily Deployment log Detailed log of the deployment run Transaction Code /SAPAPO/SPPDEPL -> Click section Deployment log Daily Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 47/47 2.2.9.5 Monitoring without SAP Solution Manager The Dialog Response Time of transaction code /SAPAPO/PE_RUN can be checked in transaction code STAD or ST03N respectively. The status, runtime, and job logs of of Background J obs can be analyzed using transaction code SM37 in the managed system. The status of qRFC queues can be monitored using transaction codes SMQ1 or SMQ2. In case of problems with the setup of the qRFC connection, use transaction SM59 to check the setup of the respective RFC- Connection. Specific to the CIF-Interface between APO and ECC, you can also use the transactions /SAPAPO/CQ (SCM Queue Manager), /SAPAPO/CW (qRFC Monitoring for Outbound Queues) and /SAPAPO/CQINW. 2.2.9.6 How to Find Meaningful Thresholds for Each Monitoring Object The definition of meaningful thresholds for each Monitoring Object needs to be done in close cooperation with your business department. It is important that you clearly define what data the data collectors measure, how often they run, and what the business requirements are for the analyzed part of the business process step. Furthermore, it is important to review the defined thresholds on a regular basis in order to ensure that they are set according to the business requirements that might change over time. 2.2.10 Business Process Step 10: Inventory Balancing 2.2.10.1 Descripti on General Information: The inventory balancing service calculates excess and shortage of a product for all locations in the BOD in the existing areas, and corrects the stock imbalance. However, inventory balancing only occurs if the benefits of a stock transfer are greater than the costs. In this way the inventory balancing service ensures that existing stock is evenly distributed. The system can decide to balance stock within an inventory balancing area only. An inventory balancing area is part of a bill of distribution (BOD) and consists of locations that can balance stock with one another. One location can thus belong to several inventory balancing areas. However, within an inventory balancing area, parent locations cannot release stock to their direct or indirect child locations. Inventory balancing from a child location to a parent location is possible. The system sorts the recommended stock transfer requisitions in descending order according to quantity and checks the maximum number of stock transfer orders per day from every location that releases stock. The system then creates stock transfer orders and releases them to ECC immediately or forwards them for manual release to ECC via interface CIF. Inventory balancing can be executed as a service in PSM. The following triggers also lead to inventory balancing: Suppression, De-stocking, Reduction of storage space at a location, unfulfilled pull deployment requisition, increased demand within the limited freeze horizon. Important settings: - Create inventory balancing areas by creating a location of type Geographic Area (1031) in the location master data. - Define packaging specifications for rounding in the SAP Easy Access menu under Advanced Planning and Optimization Service Parts Planning (SPP) Environment Packaging Specification Maintain Packaging Specification . Customizing Implementation Advanced Planning and Optimization Customizing, under Supply Chain Planning Service Parts Planning (SPP) Inventory Balancing and SCM Basis, under Planning Service Manager Define Planning Profile Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 48/48 2.2.10.2 Monitori ng Requirements: Error Monitoring: It is important to check the results of inventory balancing, if the stock transfer orders are generated and release successfully. Performance Monitoring: It is important to make sure that the inventory balancing service finish within the defined time window, and the stock transfer orders are released timely. 2.2.10.3 Monitori ng Objects in SAP Solution Manager Monitoring Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection qRFC Monitor (IMQRFCMO) (Status Monitoring of the CIF-queues between ECC and APO) (The queue names start with CF* For example: CFEP* for purchase orders, CFHE* for release schedules, CFTO* for stock transport orders) qRFC direction, RFC destination, Queue group, Command string of SMD qRFC backlog coll., Command string of SMD qRFC status coll. Number of entries with critical status in group Age of oldest critical status in group Combination of "Entries" and "Age" in critical state Number of entries with interim status in group Age of oldest interim status in group Combination of "Entries" and "Age" in interim state SMQ1, SMQ2, SM59, /SAPAPO/CQ, /SAPAPO/CW, /SAPAPO/CQINW Hourly (or even more often) qRFC Monitor (IMQRFCMO) (Backlog Monitoring of the CIF-queues between ECC and APO) (The queue names start with CF* For example: CFEP* for purchase orders, CFHE* for release schedules, CFTO* for stock transport orders) qRFC direction, RFC destination, Queue group, Command string of SMD qRFC backlog coll., Command string of SMD qRFC status coll. Number of individual queues in group Total number of entries in all queues of group Average number of entries per queue in group Maximum number of entries per queue in group Age of oldest entry in group Combination of "Total entries" and "Oldest age" SMQ1, SMQ2, SM59, /SAPAPO/CQ, /SAPAPO/CW, /SAPAPO/CQINW Hourly (or even more often) Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 49/49 CIF Comparison/Reconcili ation for Transaction Data (Data Consistency Monitoring between APO and ECC) Name for Save Number of inconsistent scheduling agreements, Number of inconsistent purchase requisitions, Number of inconsistent purchase orders, Age of last consistency check result /SAPAPO/CCR Daily Consistency Check LiveCache APO DB (For Procurement Scheduling Agreements and for user-defined key figures) User performing analysis, Execution mode of the analysis No of inconsistent Procurement Scheduling Agreements, User defined key figure, Age of last consistency check result /SAPAPO/OM17 Daily Dialog Performance Monitor (BOPERFMO) (For Monitoring response time of transaction code /SAPAPO/PE_RUN) Transaction Code (Value 1), Function Code (Value 2), Call Type, User Pattern, Instances Total Response Time, Database Response Time, Total Response Time (Data vol.- depend.) STAD, ST03N Every two hours Background J ob Monitoring for program /SAPAPO/PE_EXEC Background J ob Name, Variant, User (Note: The planning profile is visible in the job log) Start Delay, End Delay, Out of Time Window, Maximum Duration, J ob Cancellation, J ob Log Messages, J ob Log Content SM37 Daily (or more frequently in case this job is executed more than once per day), Data Collectors to run every 5 minutes during job execution 2.2.10.4 Further Monitoring Obj ects Monitori ng Object Sel ecti on Criteri a Alert Analysis Tool on Satellite System Monitori ng Frequency / Data Collection Deployment results in PSM application log Subobjects (Services), Date and Time of Planning Run, User that triggered Log PSM Application Log Content Transaction Code /SAPAPO/PE_LOG_DISP Daily 2.2.10.5 Monitoring without SAP Solution Manager The Dialog Response Time of transaction code /SAPAPO/PE_RUN can be checked in transaction code STAD or ST03N. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 50/50 The status, runtime, and job logs of Background J obs can be analyzed using transaction code SM37 in the managed system. The status of qRFC queues can be monitored using transaction codes SMQ1 or SMQ2. In case of problems with the setup of the qRFC connection, use transaction SM59 to check the setup of the respective RFC- Connection. Specific to the CIF-Interface between APO and ECC, you can also use the transactions /SAPAPO/CQ (SCM Queue Manager), /SAPAPO/CW (qRFC Monitoring for Outbound Queues) and /SAPAPO/CQINW. The consistency check between SAP APO and SAP ECC can be executed using transaction code /SAPAPO/CCR. The consistency between Live Cache and the SAP APO database can be checked using transaction /SAPAPO/OM17. 2.2.10.6 How to Find Meaningful Thresholds for Each Monitoring Object The definition of meaningful thresholds for each Monitoring Object needs to be done in close cooperation with your business department. It is important that you clearly define what data the data collectors measure, how often they run, and what the business requirements are for the analyzed part of the business process step. Furthermore, it is important to review the defined thresholds on a regular basis to ensure that they are set according to the business requirements that might change over time. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 51/51 3 Further Information 3.1 Troubleshooting If executing this Best Practice did not produce the desired results Search for related notes in the SAP Service Marketplace. Open an SAP Customer Message describing your problem (please see the respective component in section Error Handling, Restartability and Escalation of every step). 3.2 Related Best Practice Documents There are several other Best Practice documents available on the Service Marketplace under https://service.sap.com/solutionmanagerbp that relate to this Best Practice document. These documents are: General Business Process Management: This document explains the procedures you should use to create a general Business Process Management concept. This includes the definition and documentation of the core business processes, definition of monitoring objects, definition of monitoring activities including error handling procedures, monitoring tools, monitoring frequencies, the definition of communication and escalation procedures and the assignment of responsibilities. ALE Monitoring: This Best Practice helps you set up an Interface Monitoring concept with the focus on ALE Monitoring for your SAP solution. This document will outline possibilities on how to optimally monitor ALE-based interfaces manually as well as automated by using SAP Solution Manager. Both monitoring approaches aim to detect any irregularities or deviations or to detect error situations at an early stage. Job Scheduling Management: This Best Practice provides a detailed description what SAP recommends as a standardized formal process to support a job request process, including an end user job request form and an approval process. This integrated process will avoid error-prone and time intensive manual processes of copying redundant data from one data source to another (for example, MS excel to MS Excel or MS Excel to job scheduling tool). SAP Business Process Management for ERP Logistics: This Best Practice helps you set up a Business Process Monitoring concept for your SAP ERP solution. The concept aims to define procedures for business process oriented monitoring and error handling and escalation procedures for your companys ERP core business processes. These procedures intend to ensure a smooth and reliable flow of the core business processes so that your business requirements are met. Background Job monitoring with SAP Solution Manager: This Best Practice will help you to set up background job monitoring properly in the framework of Business Process Monitoring in the SAP Solution Manager. Note that these documents are also available in the SAP Service Marketplace using alias RunSAP RunSAP Best Practices. 3.3 Literature For detailed information on how to administer an SAP R/3 system, see the book: Liane Will, SAP R/3 System Administration, 2003 For information on how to monitor and tune the general system performance, see the book: Thomas Schneider, SAP Performance Optimization Guide, 2006 For information on how to monitor your business processes using the SAP Solution Manager, see the book: Thomas Schroeder, Business Process Monitoring mit dem SAP Solution Manager, 2009 (currently only available in German) Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 52/52 For information on how to set up general system monitoring using the SAP Solution Manager, see the book: Corinna Weidmann, Lars Teuber, Konzeption und Einrichtung des Systemmmonitorings mit dem SAP Solution Manager, 2009 (currently only available in German) 3.4 Feedback and Questions Send any feedback by formulating an SAP customer message to component SV-SMG-MON-BPM. You can do this at http://service.sap.com/message. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 53/53 4 Appendix In the following section you find examples on how you can set up the Monitoring within the SAP Solution Manager. 4.1 Examples for recommended Monitoring Objects 4.1.1 Example Background Job Monitoring This section shows how to set up Background J ob Monitoring for Background J ob /SAPAPO/PE_RUN in SAP Solution Manager. The setup for the other J obs is quite similar - except for the J ob specific parameters. 1. Call the SAP Solution Manager (trx DSWP or SOLUTION_MANAGER). 2. Choose your solution. 3. Go to 'Operation Setup' and navigate to 'Solution Monitoring' =>'Business Process Monitoring'. 4. Choose Setup Business Process Monitoring. 5. Check 'Business Processes': select a business process for application monitoring. 6. Check for your chosen business process: choose process steps to monitor. 7. Check for your chosen step: Choose type of monitor, here 'Background J ob'. 8. Enter the information to be used to identify the job in this case the J ob Name S_PRD001_UK_STOCKING_/SAPAPO/PE_RUN_1000_M 9. Choose the key figures J ob Cancellation and Maximum Duration to monitor the runtime of the job. 10. In check Maximum Duration you can enter thresholds that would raise a yellow or a red alert respectively when exceeded. 11. In check J ob Cancellation you can decide whether a yellow or a red alert should be raised when the job is cancelled. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 54/54 12. Once you have entered all relevant information for the monitoring objects, generate the monitoring customizing and activate the monitoring within the Business Process Monitoring session. 4.1.2 Example Dialog Response Time Monitoring The Dialog Response Time of transaction code /SAPAPO/PE_RUN can be monitored utilizing the respective Data Collector. 1. Call the SAP Solution Manager (trx DSWP or SOLUTION_MANAGER) 2. Choose your solution. 3. Go to Operation Setup and navigate to Solution Monitoring ->Business Process Monitoring. 4. Choose Setup Business Process Monitoring 5. Check Business Processes: Select a business process for Application Monitoring. 6. Check for your chosen business process: Choose process steps to monitor 7. Check for your chosen step: Choose type of monitor; here Application Monitor. 8. In the next check Application Monitoring, choose the Dialog Performance Monitor (BOPERFMO) in column Monitor Name. You can additionally enter a short text in column Monitoring Object Name 9. In the next check that carries your entered short text as name choose the key figures that you want to monitor for example, DB Response Time and Total Response Time and also enter the Monitoring Schedule. 10. The following procedure is the same for all key figures set up for this data collector: On tab <key figure> (for example, DB Response Time), double-click the field in column Counter and enter data as follows: Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 55/55 In addition, you can also enter a function code you want to monitor in field Value 2 and a User Pattern (for example, US* for all user IDs starting with US) in field User Pattern. If you are interested in certain instances, you can also enter their names in field Instances. The field Proc.Intervals refers to the process of data collection from the managed system. Refer to the instruction text in the Business Process Monitoring Setup Session for more details. 11. Now you can enter thresholds values in the fields Threshold for YELLOW (ms) and Threshold for RED (ms). 12. Once you have entered all relevant information for the monitoring objects, generate the monitoring customizing and activate the monitoring within the Business Process Monitoring session. 4.1.3 Example Data Consistency You can monitor the consistency between the SCM system and the ECC system using the CIF Delta Report, which can be scheduled and run in transaction /SAPAPO/CCR in the APO-system. The setup example described here has as a prerequisite that a variant of the CIF Delta Report is scheduled in the managed system. 1. Call the SAP Solution Manager (trx DSWP or SOLUTION_MANAGER) 2. Choose your solution. 3. Go to Operation Setup and navigate to Solution Monitoring ->Business Process Monitoring. 4. Choose Setup Business Process Monitoring 5. Check Business Processes: Select a business process for Application Monitoring. 6. Check for your chosen business process: Choose process steps to monitor Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 56/56 7. Check for your chose step: Choose type of monitor; here Application Monitor 8. In the next check Application Monitoring, choose the CIF Comparison/Reconciliation for Transaction Data (DCAPOCCR) in column Monitor Name. You can additionally enter a short text in column Monitoring Object Name 9. In the next check that carries your entered short text as name on tab Key Figures choose the key figures that you want to monitor for example, Number of inconsistent purchase requisitions. Also enter the Monitoring Schedule on tab Monitoring Schedule. On tab Detail Information, double-click field 001 in column counter. A pop-up appears where you should enter a Name for Save. This Name for Save is similar to a variant name and is the name for the setup variant of the CIF Delta Report in the managed system. 10. In the next check that carries the name of your key figure enter the threshold values for YELLOW and RED. 11. Once you have entered all relevant information for the monitoring objects, generate the monitoring customizing and activate the monitoring within the Business Process Monitoring session. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 57/57 4.2 Available Monitoring Objects for scenario Procure-to-stock 4.2.1 Overview Procure-to-Stock SCM-EWM - Q1P Create InboundDelivery NotificationNotification (24) Create InboundDelivery (25) Putaway (31.6) SCM-ICH - Q1P Update ASN / SDPR / Inbound Monitor (21) Alert Handlingwith Notification(18) Create, Change andsend ASN (15) Create SA Release, Update SDPR/Inbound Monitor (8) Update ASN / Inbound Monitor (33) Update ASN / SDPR / Inbound Monitor (29) Receive ASN (20) ECC 6.0 - Q4L Receive/Validate ASN (17) Create OutboundDelivery (13) Create Stock Transport Order (12) Create SA Release / PO (9) Update Document Flowof InboundDelivery (37) PostingChange from ROD to AFS (35) Update InboundDelivery +Post Goods Receipt (32) Update PO (30) Update InboundDelivery (28) Create InboundDelivery (19) SCM-APO- Q1P Receive InboundDelivery (22) Extract forecast relevant (historical) data (2) Issue SA Release (6) Update Planning(36) Update Planning(34) Update PlanningData (23) PlanningService Management Run(3) SPM Supplier - SUP SendASN (16) Create Customer Order (11a+11b) CRM OM / GTS - Q5U Extract forecast relevant (historical) data (1) Generate andApprove SA Schedule Lines (4) Create Purchase Order(7) Create Pos (10) Create Confirmation Create Confirmation Create Putaway warehouse task and execute inboundprocess usingprocess oriented storage control (31) Create POs Set Status inYard(27) Create Stock Transport Order IM Update Create SA Release (5) <Followonactions> Receive SA conf. Create vehicle (26) Move HU to work center and performdeconsolidation Move HU to work center and performvalue added Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 58/58 General Description: Procure-to-Stock includes processes such as Parts Demand Planning, Parts Inventory Planning, Parts Supply Planning, Parts Distribution Planning, Parts Monitoring and External Procurement either with purchase orders or schedule releases. These processes help companies maximize their return on assets by matching service parts demand with all types of supply and increase collaboration by linking various business partners across the entire service network Service parts planning enables the service parts network to forecast parts demand, derive optimal stocking levels for each location, plan parts replenishment, and rebalance the inventory within the network. To be replenished parts are ordered from suppliers for example, using the Supply Network Collaboration solution for communication of relevant information (critical parts, confirmations, ASNs). The physical goods receipts and the follow-on processes like put away are supported with SAP SCM Extended Warehouse Management. General Remark: All qRFC errors that might appear in this process appear in inbound queues. Business Process Description: The business process has two possible starting points. One is the Create/Update/Delete Sales Order on CRM, the other one is the Upload Sales History, inventory and open order on APO. REMARK: In case that the PPF or any other automatic monitoring is used it needs to be ensured that the next enforced monitoring step can close open steps of the same instance. 4.2.2 Monitori ng Business Process Procure-to-Stock Monitoring APO: Please turn to chapter 2 of this document to receive detailed information. Monitoring SNC (Supply Network Collaboration): For guidance on monitoring Business Process Steps executed in SNC/ICH, please turn to the respective sections for PI in the Setup Guide Interface Monitoring with SAP Solution Manager that can be accessed in the SAP Service Marketplace under http://service.sap.com/bpm ->Business Process Management ->Media Library ->Technical Information Monitoring ECC/ERP: Please turn to the document SAP Business Process Management for ERP Logistics that is available under https://service.sap.com/solutionmanagerbp. Additional information on Monitoring the Business Process Steps in ECC/ERP described here can be found in the SAP Service Marketplace under http://service.sap.com/bpm ->Business Process Management ->Media Library ->Technical Information in document Setup Guide Application Monitoring and in the section Customer Information in document Business Process and Interface Monitoring Part 2, that contains a list of all available Monitoring Objects. Monitori ng EWM: Information on Monitoring the Business Process Steps in EWM described can be found in the SAP Service Marketplace under http://service.sap.com/bpm ->Business Process Management ->Media Library -> Customer Information in document Business Process and Interface Monitoring Part 2, that contains a list of all available Monitoring Objects. In addition to the monitoring objects suggested in section 4.2.5 the following monitoring objects are available for EWM: Alert Type Selection-Options Waves # of overdue waves Warehouse Number, Wave Type, Wave Category, Overdue in hours Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 59/59 Warehouse Orders # of overdue warehouse orders Warehouse Number, Queue, Activity Area, Overdue in hours Warehouse Tasks # of overdue warehouse tasks # of overdue replenishment tasks Warehouse Number, Warehouse Process Type, Warehouse Process category, Overdue in hours Inbound Deliveries # of inbound deliveries overdue without Warehouse Task # of inbound deliveries overdue without Goods Receipt Warehouse Number, Document Type, Overdue in hours Outbound Deliveries # of outbound deliveries overdue without Warehouse Task # of outbound deliveries overdue without Goods Issue Warehouse Number, Document Type, Overdue in hours Monitori ng the SUPPLIER system: In the detailed description below IDoc Monitoring is mentioned when it comes to monitoring the SUPPLIER system. To obtain information on IDoc Monitoring, see the respective sections in the Setup Guide Interface Monitoring with SAP Solution Manager that can be accessed in the SAP Service Marketplace under http://service.sap.com/bpm ->Business Process Management ->Media Library ->Technical Information 4.2.3 Business Process Steps executed in SAP SCM APO Servi ce Parts Pl anning and Monitoring Objects See section 2 of this document to receive detailed information describing steps 1-7 of the Procure-to-Stock scenario 4.2.4 Business Process Steps executed in SNC and respective Monitoring Obj ects Step 8: Create SA Release / Update SDRP/Inbound Monitor (SNC) The released scheduling agreements are replicated to the SNC system. This system is available for smaller suppliers that do not have their own EDI server. These suppliers can access the SNC and check whether new requests have come in. The data is transferred via IDOC using XI. The IDOC type is DELINS/DELFOR02 XML outbound in XI/PI: DeliveryScheduleNotification_In Monitoring: IDOC monitoring in SCM and XI inbound. XML Monitoring in XI outbound. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 60/60 Step 15: Change and send ASN (SNC) The supplier who can satisfy the request for the customer can now send an advanced shipping notification (ASN) to the ECC system. If this is a small supplier without its own EDI sever, this happens via Supply Network Collaboration (SNC). This is done via transaction /SCA/ICH and /SAPAPO/SPP. The data transfer happens via XML, which XI converts into an IDOC of type DESADV.DELVRY05 (Despatched Delivery Notification) Monitoring: Response time and update error for transactions /SCA/ICH and /SAPAPO/SPP, XI monitoring Step 18: Alert Handling with Notification (SNC) A notification is sent in any case. If the ASN has been rejected on ECC side or if there are problems with the processing of the ASN, this is indicated in the IDoc. Monitoring: IDOC DELINF/DELVRY05 Step 29: Update ASN/SDPR/Inbound Monitor (SNC) With the arrival of the material in the yard the Inbound Monitor on SNC is updated again (as it is every time the delivery on ECC is updated). This happens via IDOC DELINF via XI. Monitoring: IDOC DELINF (monitored at several places in this process) Step 33: Update ASN/Inbound Moni tor (SNC) The ASN/SDPR/Inbound Monitor is again updated on SNC (as it is every time the delivery on ERP is updated). This happens via IDOC DELINF via XI. Monitoring: IDOC DELINF (monitored at several places in this process) 4.2.5 Business Process Steps executed in ECC/ERP and Monitori ng Objects Step 9: Create SA Release and Purch. Req (ECC) The release of the scheduling agreement is replicated to ERP. The data transfer to ERP happens via qRFC in queues CFHE* (Note 786446 contains the queue names). Monitoring: qRFC monitoring in queues CFHE* Step 10: Create Purchase Order (ECC) Created purchase orders are replicated to ERP. The data transfer to ERP happens via qRFC in queues CFEP* (Note 786446 contains the queue names). NOTE: For PO (incl. STOs) creation, 2 queues are triggered (PReq & PO =1 LUW). Monitoring: qRFC monitoring in queues CFEP* Step 12: Create Stock Transfer Order (ECC) As a result of Deployment runs STOs might be created in APO. Via qRFC queues CFTO*, the Stock Transfer Order is created in the ECC system. Monitoring: qRFC monitoring for queues CFTO* Step 13: Create Outbound Delivery (ECC) The outbound delivery creation for STOs can be triggered automatically (depending on Customizing): Monitoring: Transaction Code v_sa Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 61/61 Step 17: Recei ve/Validate ASN (ECC) The IDoc is received in ERP and automatically processed. Validation here can reject the IDoc if, for instance, there is a wrong material in the IDoc. If the IDoc is accepted, the inbound delivery is created. Monitoring: inbound monitoring of IDOC DESADV.DELVRY05 Step 28: Update Inbound Delivery (ECC) The Inbound Delivery with status In Yard is updated on ERP via qRFC DLVS*. Monitoring: qRFC monitoring for inbound queue DLVS* Step 30: Update Purchase Order (ECC) With the update of the delivery in ECC the Purchase Order is also updated in ECC. Monitoring: -- Step 32: Update Inbound Delivery and post Goods Receipt (ERP) With posting GR in EWM the GR in ECC is replicated and the Inbound delivery in ECC is updated. This happens via inbound queue DLVS*. Monitoring: Inbound qRFC monitoring for DLVS*. Step 35: Posting Change from Received on Dock (ROD) to Available for Sal es (AFS) (ERP) With the posting change in EWM from stock type F1 (ROD) to stock type F2 (AFS =available for sales) the stock in ERP will be posted from storage location ROD to storage location AFS (incl. IM Update). This happens via inbound queue DLVS*. Monitoring: Inbound qRFC monitoring for DLVS*. Step 37: Update document flow of Inbound Delivery (ERP) After the final putaway, the document flow in the Inbound Delivery is updated in ERP again via qRFC DLVS*. If the delayed delivery update has been configured this is not done immediately. Monitoring: RFC inbound queue DLVS* 4.2.6 Business Process Steps executed in EWM and respective Monitoring Obj ects Step 24: Create Inbound Deli very Notifi cation (EWM) The inbound delivery in ERP is also replicated to EWM via qRFC DLVMSAVEREPLICA*_7* or DLVS* as an inbound delivery notification Monitoring: Inbound monitoring of RFC queues DLVMSAVEREPLICA*_7* or DLVS* Step 25: Create Inbound Deli very (EWM) The inbound delivery notification could be converted into an inbound delivery manually or via PPF action. Monitoring: PPF Monitoring, Action: /SCDL/IDR_TRANSFER Step 26: Create vehicl e (EWM) With creating the ID in EWM, a vehicle can be created manually or via PPF action. Monitoring: PPF Monitoring, Action: /SCWM/PRD_CREATE_VEH Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 62/62 Based on customizing settings (MTR) the relevant number of transport units will be created. Step 27: Set Status In Yard (EWM) Once the transportation unit arrives it is registered as IN YARD manually via transaction /SCWM/PRDI or automatically PPF action. Monitoring: PPF Monitoring, Action: /SCWM/MSG_PRD_SEND Step 31: Create Putaway Warehouse Task and execute Inbound Process using process oriented storage control (EWM) (For example: Sub-Step 1: Unloading Sub-Step 2: Move HU to work center for deconsolidation Sub-Step 3: Deconsolidation Sub-Step 4: move HU to work center for performing value added services Sub-Step 5: Value Added Service Sub-Step 6: Putaway) If using process-oriented storage control, the system determines for which step the first HU warehouse task will be created. If unloading will be processed with warehouse tasks (complex unloading) the first step in process oriented storage control could be unloading. Also, an inactive product warehouse task can be created including the final destination bin (point of time can be defined in customizing). Step 31.1: Unloading (EWM) HU Warehouse Tasks are created for Unloading (in case of complex unloading). The confirmation of the unloading warehouse tasks is executed via transaction /n/SCWM/TO_CONF in a paper driven environment or via transaction /SCWM/RFUI in RF driven environment. With the confirmation of the last unloading warehouse task the status UNLOADED will be set. With the confirmation of each unloading HU WH task partial goods receipt can be posted (Customizing). Monitori ng of warehouse task creation for unloading: PPF Monitoring, Dialog Performance Monitoring, Update Error. PPF Action: /SCWM/PRD_IN_TO_CREATE (Action Profile: /SCDL/PRD_IN) =>Unloading WT Monitoring possible using inbound qRFC WRCF*. Monitori ng of warehouse task confirmati on for unloading: Using desktop: Performance and update errors for transaction /SCWM/TO_CONF. Using RF: Performance and update errors for transaction /SCWM/RFUI Monitoring of posting goods receipt after unloading: Performance and Update Errors for /SCWM/UNLOAD, PPF SCDL/MSG_PRD_IN_GR_SEND The relevant stock will be posted GR to stock type =F1 (ROD=received on dock). Step 31.2: Move HU to Work Center for Deconsolidation (EWM) Deconsolidation could be needed and the relevance will be determined via customizing. Deconsolidation takes place at specific work centers in the warehouse. With confirming the WT for unloading, it is possible to create WT to the Deconsolidation work center automatically (customizing). Monitoring: Using desktop: performance and update for transaction /SCWM/TO_CONF or Using RF: Performance and update errors for transaction /SCWM/RFUI and for monitoring creation of HU-WT from staging area to WC using queue monitoring EWMP* Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 63/63 Step 31.3: Deconsolidation (EWM) The user performs deconsolidation by using the transaction /SCWM/DCONS. The deconsolidation step will be confirmed by closing the relevant HUs. Monitoring: Using desktop: performance and update for transaction /SCWM/DCONS or Using RF: Performance and update errors for transaction /SCWM/RFUI and for monitoring creation of Product-WT for deconsolidation using queue monitoring EWMTP_* Step 31.4: Move HU to Work Center for Value-Added Servi ces (EWM) Value added services (VAS) could be needed, for example, some anti-rust protection is necessary to prepare the product suitable for storage. The process is designed that value added services are performed at a special work center. The HU warehouse task to move the HU from deconsolidation work center to VAS work center can be created automatically via customizing in process oriented storage control or manually with transaction /SCWM/ADHU. Monitoring: Using desktop: performance and update for transaction /SCWM/TO_CONF or Using RF: Performance and update errors for transaction /SCWM/RFUI and for monitoring creation of HU-WT from WC for Decons. to WC for VAS using queue monitoring EWMP* Step 31.5: Value-Added-Services (EWM) The relevant VAS Order can be generated with creation of the ID (see point 21) (Customizing). The value added service activities regarding to VAS order will be confirmed, for example, using transaction /SCWM/VASEXEC. Monitoring: performance and update for transactions /SCWM/VASEXEC Step 31.6: Putaway (EWM) In our example, the last step in process-oriented storage control is the putaway step. With confirmation of the value added service activities the inactive product warehouse task for putaway will be activated for execution to move the product to the final destination bin. With confirmation of the warehouse task a posting change will be executed (customizing) for the relevant stock from ROD to AFS (available for sale). Monitoring: Using desktop: performance and update for transaction /SCWM/TO_CONF or Using RF: Performance and update errors for transaction /SCWM/RFUI and for monitoring activation of Product-WT for putaway using queue monitoring EWMP* 4.2.7 Business Process Steps executed in the Suppli er System and respective Monitoring Objects Step 11a: Create Customer Order (SUPPLIER) For larger suppliers the SA release is sent directly to the suppliers EDI server. This happens directly via IDoc (no usage of XI) of type DELINS (basic type DELFOR02). Monitoring: IDoc monitoring Step 11b: Create Customer Order (SUPPLIER) For larger suppliers the PO is sent directly to the suppliers EDI server. This happens directly via IDoc (no usage of XI) of type ORDINT.ORDNTF01. Monitoring: IDoc monitoring Step 16: Send ASN (SUPPLIER) Bigger suppliers who have their own EDI server can send their advanced shipping notifications directly (not via XI) to the ERP system. IDOC type is again DELINF. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 64/64 Monitoring: n.a. 4.3 Background Jobs Certain jobs must run periodically in any production system - for example, deleting obsolete jobs or spool objects. If these periodic jobs do not run, system performance may get worse over time. Unfortunately, there is currently no easy-to-use support for such jobs in Basis Customizing. Therefore, the jobs must be scheduled manually. For more information, see SAP Note 16083. Note that a daily monitoring of the job log using Solution Manager is recommended. Error Handling Procedures for Batch Jobs In case one of the scheduled jobs fails, if one of the necessary jobs is not scheduled, or even if a scheduled job has finished, check for the current job status (refer to the SAP ECC documentation, component BC-CCM, chapter background processing) and proceed as follows: In the case of status scheduled, the job steps have already been defined, but the start condition has not yet been defined. Contact the program scheduling management in order to clarify when the job will be fully defined. In the case of status released, the job has been fully defined including a start condition and waits for the condition to fulfill. In the case of status ready, the start condition of a released job has been met. A job scheduler has put the job in line to wait for an available background work process. In the case of status acti ve, the job is currently running and cannot be modified or deleted anymore. Check if the job is within the given timeframe, depending on the data volume to be processed. Check for particular dependencies on other jobs. If the job exceeded the given timeframe, contact the software monitoring team. In the case of status fi nished, all steps that make up this job have completed successfully. Program scheduling management has to check whether the job ran in the given timeframe, and software monitoring team and/ or application support have to check the respective job results (such as spool output lists, message logs, updates, etc.). In the case of status cancelled, the job has terminated abnormally, which can happen in two ways. If an administrator intentionally cancelled the job, clarify why he did so and whether (and if, when) the job has to be re-run. If a program in a job step produced an error such as issuing an E or A error message, contact the software monitoring team and investigate why the error occurred. In case of an SAP standard program search for appropriate notes in the SAP Service Marketplace and create a customer message if you cannot solve the problem. Job Restartability In case of the cancellation of a background job, possible succeeding jobs or dependencies on other jobs must be considered when restarting the aborted job. The start of succeeding jobs might be also delayed due to the restart of the aborted job. Escalati on Procedures If it is not possible for any of your support levels to provide a solution for a particular problem, it is recommended to open an SAP customer problem message. Best Practice for Solution Operations Manage Operations for SAP APO: Service Parts Planning 2010 SAP AG page 65/65 2010 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, Excel, Outlook, and PowerPointare registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWinare trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C
, World Wide Web Consortium, Massachusetts Institute
of Technology. J ava is a registered trademark of Sun Microsystems, Inc. J avaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, Clear Enterprise, SAP BusinessObjects Explorer and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP France in the United States and in other countries. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.