011000358700000398482010 e

Best Practice for Solution Operations

Manage Operations for Service PartsPlanning with SAP SCM

Dietmar-Hopp-Allee 16D-69190 Walldorf

CS STATUS

external finalDATE 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 OperationsManage Operations for SAP APO: Service Parts Planning

2010 SAP AG page 2/2

Table of ContentsManagement Summary 5

1.1 Goal of Using this Best Practice 51.2 Alternative Practices 51.3 Staff and Skills Requirements 51.4 System Requirements 61.5 Duration and Timing 61.6 How to Use this Best Practice 61.7 Best Practice Procedure 6

1.7.1 Preliminary Tasks 61.7.2 Monitoring Concepts 61.7.3 Business Process Monitoring in SAP Solution Manager 71.7.4 Monitoring Types for Business Process Monitoring in SAP Solution Manager 8

1.7.4.1 Application Monitor 81.7.4.2 Background Job 91.7.4.3 ABAP Dump Collector 101.7.4.4 Dialog Performance 101.7.4.5 Update Errors 111.7.4.6 Due List Log 121.7.4.7 Application Log 131.7.4.8 Other CCMS Monitors 141.7.4.9 Analysis and Monitoring Tools 151.7.4.10 Monitoring Activities 171.7.4.11 Notifications 17

1.7.5 Business Process Monitoring Process 182 Business Process Monitoring for Service Parts Planning 20

2.1 Sample Scenario 202.2 Business Process Service Parts Planning 20

2.2.1 Business Process Step 1: Capture Demand History 212.2.1.1 Description 212.2.1.2 Monitoring Requirements: 222.2.1.3 Monitoring Objects in SAP Solution Manager 232.2.1.4 Monitoring without SAP Solution Manager 252.2.1.5 How to Find Meaningful Thresholds for Each Monitoring Object 25

2.2.2 Business Process Step 2: Stocking and De-stocking 252.2.2.1 Description 252.2.2.2 Monitoring Requirements: 262.2.2.3 Monitoring Objects in SAP Solution Manager 262.2.2.4 Further Monitoring Objects 262.2.2.5 Monitoring without SAP Solution Manager 272.2.2.6 How to Find Meaningful Thresholds for Each Monitoring Object 27

2.2.3 Business Process Step 3: Manage Demand History 272.2.3.1 Description 272.2.3.2 Monitoring Requirements: 282.2.3.3 Monitoring Objects in SAP Solution Manager 282.2.3.4 Further Monitoring Objects 29



2.2.3.5 Monitoring without SAP Solution Manager 292.2.3.6 How to Find Meaningful Thresholds for Each Monitoring Object 29

2.2.4 Business Process Step 4: Forecasting 292.2.4.1 Description 292.2.4.2 Monitoring Requirements: 312.2.4.3 Monitoring Objects in SAP Solution Manager 312.2.4.4 Further Monitoring Objects 312.2.4.5 Monitoring without SAP Solution Manager 322.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 322.2.5.1 Description 322.2.5.2 Monitoring Requirements: 332.2.5.3 Monitoring Objects in SAP Solution Manager 332.2.5.4 Further Monitoring Objects 332.2.5.5 Monitoring without SAP Solution Manager 342.2.5.6 How to Find Meaningful Thresholds for Each Monitoring Object 34

2.2.6 Business Process Step 6: Surplus & Obsolescence Planning 342.2.6.1 Description 342.2.6.2 Monitoring Requirements: 352.2.6.3 Monitoring Objects in SAP Solution Manager 352.2.6.4 Further Monitoring Objects 362.2.6.5 Monitoring without SAP Solution Manager 372.2.6.6 How to Find Meaningful Thresholds for Each Monitoring Object 37

2.2.7 Business Process Step 7: Distribution Requirements Planning (DRP) 372.2.7.1 Description 37

2.2.7.2 Monitoring Requirements: 382.2.7.3 Monitoring Objects in SAP Solution Manager 382.2.7.4 Further Monitoring Objects 392.2.7.5 Monitoring without SAP Solution Manager 392.2.7.6 How to Find Meaningful Thresholds for Each Monitoring Object 39

2.2.8 Business Process Step 8: Procurement Approval (DRP Approval) 402.2.8.1 Description 402.2.8.2 Monitoring Requirements: 412.2.8.3 Monitoring Objects in SAP Solution Manager 412.2.8.4 Further Monitoring Objects 432.2.8.5 Monitoring without SAP Solution Manager 432.2.8.6 How to Find Meaningful Thresholds for Each Monitoring Object 43

2.2.9 Business Process Step 9: Deployment 442.2.9.1 Description 442.2.9.2 Monitoring Requirements: 452.2.9.3 Monitoring Objects in SAP Solution Manager 452.2.9.4 Further Monitoring Objects 462.2.9.5 Monitoring without SAP Solution Manager 472.2.9.6 How to Find Meaningful Thresholds for Each Monitoring Object 47

2.2.10 Business Process Step 10: Inventory Balancing 472.2.10.1 Description 47



2.2.10.2 Monitoring Requirements: 482.2.10.3 Monitoring Objects in SAP Solution Manager 482.2.10.4 Further Monitoring Objects 492.2.10.5 Monitoring without SAP Solution Manager 492.2.10.6 How to Find Meaningful Thresholds for Each Monitoring Object 50

3 Further Information 513.1 Troubleshooting 513.2 Related Best Practice Documents 513.3 Literature 513.4 Feedback and Questions 52

4 Appendix 534.1 Examples for recommended Monitoring Objects 53

4.1.1 Example Background Job Monitoring 534.1.2 Example Dialog Response Time Monitoring 544.1.3 Example Data Consistency 55

4.2 Available Monitoring Objects for scenario Procure-to-stock 574.2.1 Overview Procure-to-Stock 574.2.2 Monitoring Business Process Procure-to-Stock 584.2.3 Business Process Steps executed in SAP SCM APO Service Parts Planning and Monitoring

Objects 594.2.4 Business Process Steps executed in SNC and respective Monitoring Objects 594.2.5 Business Process Steps executed in ECC/ERP and Monitoring Objects 604.2.6 Business Process Steps executed in EWM and respective Monitoring Objects 614.2.7 Business Process Steps executed in the Supplier System and respective Monitoring Objects 63

4.3 Background Jobs 64



Management Summary

1.1 Goal of Using this Best PracticeThis Best Practice will help you to set up a Business Process Monitoring concept for your SAP solution in theautomotive area. The concept aims to define procedures for business process oriented monitoring and errorhandling, and escalation procedures for Service Parts Planning with SAP SCM. These procedures areintended to ensure a smooth and reliable flow of this core business process so that your businessrequirements are met.This Best Practice offers guidance to define suitable application-oriented monitoring objects to detect anyirregularities or deviations from an ideal business process flow, or to detect error situations concerning a corebusiness process at an early stage.This Best Practice contains the recommended approach from SAP which uses the SAP Solution Manager forthe Monitoring functionalities whenever possible. However, even if you do not use the SAP Solution Managerwe recommend that you follow the procedures described in this document as much as possible in to ensure asmooth and reliable flow of your business processes as well as an appropriate response in case ofunforeseen errors.Additional information on how to monitor the end-to-end cross-system scenario Procure-to-stock can befound in the Appendix of this document.

1.2 Alternative PracticesYou can have SAP experts deliver this Best Practice on-site by ordering an SAP Solution ManagementOptimization (SMO) service for SAP Business Process Management (BPM). This service is exclusivelyavailable within SAPs support engagements SAP MaxAttention and SAP Safeguarding. If your companycurrently does not have any support engagement with SAP, it is also possible to get assistance by SAPexperts from SAP Consulting. If this case, please contact your local SAP Consulting representative.

1.3 Staff and Skills RequirementsTo implement this Best Practice, you require the following teams:Application Management TeamThis team creates the ERP Business Process Monitoring concept and consists of experts from several areasof your company:

? Business department? Solution support organization (for example the Basis Support or the Application Support)? Implementation project team

Business Process Operations TeamThe Business Process Operations team will be responsible for applying the resulting procedures derived fromimplementing this best practice. They include the following groups:

? Persons designated to perform business process-oriented monitoring and to ensure that the processruns smoothly (for example, the Business Process Champion for each business process)

? All parties in your Solution Support Organization and IT department involved in monitoring focusedon the application aspects (Application Support, Development Support, Job SchedulingManagement)

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 thebusiness process. Therefore, he/she is usually responsible for the escalation paths in case ofproblems. Often, he/she is a second level in the escalation procedure, if the application monitoringteam needs to escalate an issue.



More information about roles and responsibilities of these teams can be found in the super-ordinate BestPractice General Business Process Management, which you can obtain through SAP Solution Manager orthe 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 RequirementsTo monitor business processes running in your SAP solution via SAP Solution Manager, the SAP BasisRelease of the systems to be monitored have to be at least 4.6C. To have all described monitoring objectsavailable in SAP Solution Manager, the add-on ST-A/PI01L has to be installed on the SAP ECC systems.

1.5 Duration and TimingDurationCreating 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.TimingThe best time to apply this Best Practice is during the planning phase or during the implementation phase ofyour SAP solution.

1.6 How to Use this Best PracticeHere 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 generalBusiness Process Management concept. This includes the definition and documentation of the corebusiness processes, definition of monitoring objects, definition of monitoring activities including errorhandling procedures, monitoring tools and monitoring frequencies, the definition of communicationand 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 explainedin this Best Practice. It is intended to be used as a guideline for writing down your company specificprocess documentation.

? In section 1.7.4, you find further information that is relevant for more than one scenario. If informationfrom the generic part is relevant for a specific business process step in one of the scenarios, you willfind a clear link to the corresponding chapter in the generic part.

1.7 Best Practice Procedure1.7.1 Preliminary TasksBefore performing this Best Practice, ensure that you perform the following preliminary tasks or checks in thesystem:? 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 Monitoring ConceptsThe monitoring procedures proposed for each business process step are the core of this Best Practice. Themonitoring 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



? 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 monitoring requirements for the process step? Defined monitoring objects, 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 insection 1.7.4. Recommendations for performance monitoring can also be found in this chapter. Theperformance of the most important steps of your core business processes should be monitored on a regularbasis. The monitoring procedure for performance monitoring of all steps that are executed in an SAP solutionused for Spare Parts Management is generally the same. Therefore, you will only find specific performancemonitoring recommendations on selected business process steps.

1.7.3 Business Process Monitoring in SAP Solution ManagerBusiness 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 alltechnical and business application specific functions that are required for a steady and stable flow of thebusiness processes.

The core business processes that are implemented in an SAP system or other software and operated by acompany are of particular importance. Business Process Monitoring is intended to ensure a smooth andreliable operation of the business processes and, thereby, that the core business processes meet acompanys business requirements in terms of stability, performance, and completeness. SAP SolutionManager provides a graphical view to visualize a companys (distributed) system and solution landscape andall related business processes. By using Business Process Monitoring, it is possible to define and customizealert 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 businessprocess step in the graphical business process representation. The goal of Business Process Monitoring is todetect and respond to critical situations as early as possible so you can solve problems as quickly aspossible.

In addition, SAP Solution Manager offers extended functionality for error handling and problem resolution. Bythe definition of contact persons and escalation paths, Business Process Monitoring can be integrated intothe companys overall strategy for Business Process Management and Solution Management within theirSolution Support Organization.

In general, Business Process Monitoring includes the solution-wide observation of:? Business process performance (Key Performance Indicators)? Background jobs (Job 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.



1.7.4 Monitoring Types for Business Process Monitoring in SAP Solution ManagerMonitoring Types are part of the functional scope of Business Process Monitoring as it is available in the SAPSolution Manager. This chapter provides a short overview of available monitoring types for referencepurposes 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 Jobs (Jobs 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 mustbe selected. To receive detailed information on how to set up the Monitoring Objects in SAP SolutionManager, 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 isthat all business processes and business process steps are maintained in the respective solution thatcontains all affected system components. If you want to learn more about how to set this up, see (URLhttp://help.sap.com)? SAP Solution Manager ? Basic Settings.

1.7.4.1 Application MonitorThe 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 ? Entryby 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 satellitesystem. In case of problems, refer to SAP Note 915933.

The Throughput and Backlog Indicator functionality available as of ST-A/PI 01J* is only workingproperly 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 onhow 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/ AliasBPM? Media Library).

1.7.4.1.1 Throughput and Backlog Indicators (TBIs)As of ST-A/PI 01H, a completely new set of Application Monitors has been introduced. While the alreadyestablished 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



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 ChecksThe DCC collectors are a subset of the Application Monitors used to retrieve a stored comparison result fromdata 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 orinto the spool, but can also permanently store a summary in database tables. Corresponding monitoringobjects can be configured to retrieve the number of found inconsistencies out of the stored summaryinformation 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 (URLhttp://www.service.sap.com/ -> Technical Information).

1.7.4.2 Background JobThe background job monitoring should be part of a Job Scheduling Management concept (go tohttp://service.sap.com/solutionmanagerbp ? Topic Area Business Process Operations to find a BestPractice document Job Scheduling Management). Because of several restrictions regarding background jobscheduling, for example, time restrictions, restriction of hardware resources (CPU, main memory, ) orexisting dependencies between different activities (for example, invoices can only be created after thecorresponding goods issue is posted, or Back Order Processing and Material Requirements Planning shouldnot run at the same time) it is very important to ensure the stable running of background jobs. A cancelledbackground job should be identified as soon as possible so you can react as quickly as possible. Therefore, itis also necessary to define restart procedures and escalation paths.

1.7.4.2.1 Monitoring Objects and AlertsBefore setting up monitoring, the monitoring objects must be clearly defined. A monitoring object is a singlebackground job or a group of background jobs. There are four different possibilities to identify a specialbackground job or a group of background jobs. This information needs to be maintained in the sub-nodeBackground Job below a business process step.

A more detailed description (than provided in this document) on the subject of what kind of alerts make senseor what kind of alerts are possible are discussed in the Best Practice document Background Job Monitoringwith SAP Solution Manager, which can be found on the SAP Marketplacehttp://service.sap.com/solutionmanagerbp ? Topic Area Business Process Operation.



1.7.4.3 ABAP Dump CollectorThis provides monitoring features for alerting on occurrences of ABAP dumps of specified runtime errors or tocollect statistical data of ABAP dumps for reporting reasons.

1.7.4.3.1 Monitoring Objects and AlertsThe monitoring object is an ABAP runtime error. This runtime error can be specified via the runtime errorname, the user who is responsible for the runtime error, the Client on which the runtime error occurs, or theProgram 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 orfor the previous day)

1.7.4.4 Dialog PerformanceDialog Performance implies the monitoring of the dialog transaction performance of any transaction in theSAP System. This could be a standard transaction or a self-developed transaction.

1.7.4.4.1 Monitoring Objects and AlertsThe monitoring object is the transaction itself. The customizing has to be done in the node DialogPerformance. In the table Transactions, all transactions that are already configured to that business processstep are listed. The relevant transactions need to be selected for monitoring. It is also possible to add or toremove transactions within table Add/Remove Transactions. The monitoring can be performed for each SAPinstance. Therefore, the respective instances have to be selected in table SAP Instances. All instancesthat are maintained for a system are listed there. Table Alert Types shows the dialog response timeand all parts of the response time, like queue time, load and generation time, database request time, and thefront-end response time, which can be monitored. Those times that are relevant for monitoring have to beselected.After saving this node, a sub-node Performance Alerts will appear where the threshold values have to beentered.

Monitoring Objects Dialog 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



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 bepossible that the object already exists there. Therefore, you can load the current threshold values from therespective 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 thethreshold 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. Totransfer all at once (all thresholds for all columns and tables), there is an additional button "Copy all".

Monitoring Alerts - Dialog Performance

1.7.4.5 Update ErrorsChanges to the data in an SAP system caused by a business process should be written to the database in fullor not at all. If the operation is canceled while the transaction is being executed, or if an error occurs, thetransaction should not make any changes to the database. These activities are handled by the SAP updatesystem.

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 criticalchanges.

V1 modules describe critical or primary changes; these affect objects that have a controlling function in theSAP System, for example, order creation or changes to material stock.V2 modules describe less critical secondary changes. These are pure statistical updates, for example, resultcalculations.

1.7.4.5.1 Monitoring Objects and AlertsMonitoring of Update Errors can be configured for online transactions and/or ABAP programs relevant in abusiness process. This is the object type. The name of the object is the name of a transaction or the name ofthe 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.



Monitoring Objects - Update Errors

Since update errors are usually very critical, the default configuration is to raise a yellow alert as soon as oneupdate error occurs. This is valid for V1 and for V2 update errors. To raise a red alert for a V1 or a V2 updateerror, a threshold must be specified.

1.7.4.6 Due List LogA due list is a list that contains several entries (documents) depending on selection criteria. There aredifferent 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 billingdue list via transaction V.21. In the case of a billing due list, the list contains, for example, a number of salesdocuments that need to be billed. If the billing due list was processed previously and it is important to knowwhich billing documents were created from this billing due list, it can be displayed in the due list log for thisbilling run.

1.7.4.6.1 Monitoring Objects and AlertsThe monitoring object is the respective due list type. That can be Delivery, Billing, or Picking. If a certainuser is processing the due list, the name of the user can be specified here. If it is user independent, a wildcard * can be used. The aggregation level needs to be defined. This could be per day, per hour or perlog.

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 toYELLOW (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.



5. DLLogMsgs refers to specific due list log messages. The message type, the message ID and thenumber can be specified. It is also possible to use wild cards. The threshold values for the number ofmessages that result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (orback) must be maintained.

1.7.4.7 Application LogThe Application Log provides an infrastructure for collecting messages, saving them in the database anddisplaying them as a log. Situations can arise at runtime in application programs that must be brought to theattention of the user in some way. These are usually errors. It can also be useful to report a successfulcompletion. The information that arises is called a message. The set of messages is a log. A log usually alsohas 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 Monitoring Objects and AlertsThe Application Log allows an application-oriented or object-oriented recording of events. An object, and anysubobject 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 otherspecific information to that log.

Monitoring Objects and Alerts - Application Log

It is possible to monitor for the total number of messages belonging to an object. Therefore, the number ofmessages that raises a YELLOW alert and the number of messages changing from a YELLOW to a REDalert must be maintained.

It is also possible to monitor specific messages that are considered as critical in table CriticalMsgs. To



configure the monitoring of critical application log messages, the relevant object-sub object combinationsneed to be selected. For each of these combinations, the message type, the message ID, the messagenumber and the threshold values for the number of critical messages that are supposed to result in changesfrom GREEN to YELLOW and from YELLOW to RED can be specified. It is also possible to use wild cards.

Monitoring Alerts - Application Log / Critical Messages

1.7.4.8 Other CCMS MonitorsWith other CCMS Monitors, it is possible to assign any CCMS monitoring tree element (MTE) to a businessprocess step. Therefore, it is necessary to call transaction RZ20 in the Satellite System and to open a monitorthat contains the required alert(s).

The name of the monitoring tree element (MTE) can be found by choosing F1. The MTE name needs to becopied 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. Ifan MTE of a higher branch-level (collective MTE) is chosen, then the current and open view in thegraphics will show the right alerts but it isnt possible to process these alerts within the BusinessProcess 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 thresholdvalues were found these columns remain empty.

To transfer the thresholds values for a single line from right to left, double-click the copy icon.



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 noCCMS but is included as one business process step in your business process. Now, you could use one MTEin the CCMS of the SAP Solution Manager to monitor the heartbeat of the Portal. You could then assign thecorresponding alert via Other CCMS Monitoring to business process step running on the Portal system.

1.7.4.9 Analysis and Monitoring ToolsIt is possible to specify analysis transactions or URL addresses (including file directories) per monitoringobject. In the case of analysis transactions, these should be used to analyze errors or problems either locallyin the SAP Solution Manager system itself (Call Option 1), or directly in the respective satellite systems (CallOption 2). By default, some standard transactions are maintained, for example, transaction SM37, thatprovides a job overview in an SAP System, is maintained for Background Jobs or transaction SLG1 to have alook into the application log.

It is also possible to add new transactions; this could be standard transactions or customer self-writtentransactions.



Analysis & Monitoring Transactions

On the second tab strip, it is possible to specify a URL which should be called to further analyze the givenproblem. This is especially interesting if you have some knowledge documents linked to a portal. You define aShort text and the URL to be called.

For web pages to be called, specify the full URL, for example, http://help.sap.com. For contentavailable on file servers specify the full file path, using the nomenclature: file://\\\\..., forexample, 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 stepwhen using the monitoring later on inside the Business Process Monitoring Session. By pressing these

buttons (for example, ), the user will jump directly into the correspondingtransaction 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 openedbrowser window.



1.7.4.10 Monitoring ActivitiesMonitoring activities should be set up for every Monitoring Object within a business process step. Allmonitoring objects defined within a business process step are listed here. To ensure effective monitoring andefficient problem resolution, the responsibilities should be assigned and problem resolution proceduresshould be defined as described in the following table. Some information is taken from the previous nodeSolution Support Organization.

Monitoring Team Defines the team that is responsible for monitoring the relevantMonitoring Object. Use value help [F4].

Person Resp. Defines the Person who is responsible for monitoring the MonitoringObject. Use value help [F4].

Frequency Describes how often the responsible person should process the requiredmonitoring activity.

Start Time Describes at which time the responsible person should process therequired 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 bemaintained here.

Additional information related to this business process step can be entered in the tables MonitoringActivities, Error Handling, Restart of Step and Escalation Path. This information would be valid for thewhole business process step and helps users who have to carry out the monitoring and who are not sofamiliar with that particular business process.

1.7.4.11 NotificationsNotifications 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 notificationsallow sending messages in case of alerts to a specified Recipient. This could be an e-mail or an SAPOfficemail.Support notifications allow the setting up of a service desk message in case of an alert. The informationentered for the service desk message serves as a template. The service desk message can be createdmanually or automatically.

On business process level, it is possible to define notifications for the whole business process, that is, assoon as the business process gets an alert status, notifications will be triggered. Alternative notifications canbe defined for every Monitoring Type individually, for example, all alerts related to all background jobs of thebusiness process are forwarded to a defined e-mail address.

Notifications defined on business process step level will overrule the configuration made on business processlevel 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. Thisuser can be even a system user without any roles or profiles, but the usermust 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



Address be any e-mail address, an SAP user name in the same system, a RemoteSAP name or a shared distribution list. In the case of an SMS, you need toenter SMS:

Reci. Type There are currently 5 different Recipient Types: U (e-mail), K (for SMS andPager), B (SAP user name), R (Remote SAP name) and C (shareddistribution list).

No. of YellowAlerts

The number of YELLOW alerts that may occur before an automaticnotification is triggered

No. of Red Alerts The number of RED alerts that may occur before an automatic notification istriggered

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 thesolution, 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 username 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 deskmessages manually created for alerts.

Automatic Support Notifications will be created automatically depending on the alertthresholds.

Reporter Necessary when service desk messages are created automatically. Must bean SAP user name who is defined as a Business Partner with the roleGeneral.

Num. of YELLOWAlerts

Necessary when service desk messages are created automatically, forexample, after 10 yellow alerts a service desk message should be created.

Num. of REDAlerts

Necessary when service desk messages are created automatically, forexample, 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 YELLOWAlerts or Num of RED Alerts is filled with a value the automatic Support Notification creation isconfigured. If both columns are filled with a value, the automatic Support Notification creation workswith a logical OR operation. Hence, with the figures in the table above the system would create aSupport Notification if either more than 9 yellow alerts OR more than 4 red alerts exist, for which noSupport 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 theexecution of the monitoring concept has to be defined. This includes the definition and assignment of the



roles and responsibilities involved. It has to be defined who is supposed to carry out which activity within theprocess and how communication between the different roles within the support organization is supposed totake place.

A Business Process Monitoring concept has to be tightly integrated with the support organization. Thisincludes the integration with the Incident/Problem Management process and the Change Managementprocess. These processes have to be adjusted to the Business Process Monitoring concept so thatcommunication and escalation procedures are adequate to support the Business Process Monitoring conceptincluding the final communication of open alerts to SAP.

Wherever communication connected with Business Process Monitoring happens outside these supportprocesses, separate communication and escalation paths and procedures have to be defined.Please see the above mentioned separate Best Practice for General Business Process Management forfurther details.



2 Business Process Monitoring for Service Parts Planning

Service Parts Management (SPM) is a comprehensive, end-to-end solution for supporting and managing theextended 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 ServiceParts Planning (SPP) with SAP SCM APO should look like. It will introduce you to generic thoughts and ideashow to identify a business process step you could keep an eye on and makes you familiar with how to choosethe 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 ScenarioAutoMan is a car service parts provider. Its main business is to sell service parts of cars. AutoMan getsservice parts from different suppliers, distributes them through its supply chain network warehouses atdiverse 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 itsservice 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 bystep through the 10 core business processes steps, explaining where and how you can identify focus pointsfor Business Process Monitoring. For each business process step, the most effective way for BusinessProcess Monitoring in the context of the example is highlighted.

2.2 Business Process Service Parts PlanningThe 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 maintainedas demand history in the BI (Business Intelligence) part of APO. It is used to plan inventory for products atlocations (step 2 and step 5) and to calculate forecasts (step 4). With these results, SPP can evaluate surplusor obsolete stocks (step 6). Further, DRP run (step 7) organizes replenishment planning within a bill ofdistribution (BOD) distribution network for a product. The planned procurement will then be approved andsent 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 forexecution.

In SPP, Planning Service Manager (PSM) is used for planning in background in general. Users can schedulethe planning services, which are needed for a business process, in a planning profile. The PSM then runs thisplanning 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).



Note: Each section about a business step will be structured in the following way, where the X stands for theBusiness Process Step number:2.2.X.1 Description2.2.X.2 Monitoring Requirements2.2.X.3 Monitoring Objects in SAP Solution Manager2.2.X.4 Further Monitoring Objects (if applicable)2.2.X.5 Monitoring without SAP Solution Manager2.2.X.6 How to Find Meaningful Thresholds per Monitoring Object2.2.X.7 Background Job Scheduling Requirements (if applicable)

SPP Business process

Please note that this chapter only focuses on describing Business Process Monitoring for the steps carriedout in SAP APO as shown in the graphic above. Business Process Monitoring for the steps executed in SAPCRM or SAP ECC is not part of it.

Available Monitoring objects for the scenario Procure-to-stock (using further solutions like SNC, EWM andERP) 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 DescriptionGeneral Information:AutoMan uses SAP CRM to manage customers. With the BI workbench (transaction: RSA1) in APO, thesystem extracts SAP CRM sales order data to SAP APO BI and saves it in the DataStore object0CRM_SALO. The InfoSource 80CRM_SALO takes its data from this DataStore object. This data transferbetween 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 TransferExecution

ProcurementExecution

SAP CRM SAP ECC

(2) Stocking and De-Stocking

(3) Manage Demand History

(4) Forecasting

(5) Economic Order Quantity& Safety Stock

(6) Surplus & ObsolescencePlanning

(7) DistributionRequirements Planning

(8) Procurement Approval

(9) Deployment

(10) Inventory Balancing



process and check the data, and saves it as demand history in the InfoCube 9ADEMAND, together with theraw 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 ateach entry location. However, the system only uses the demand history of the stockholding location forforecasting.The system creates the yearly demand history that both phase-out planning and surplus and obsolescenceplanning require. To do so, the system uses the data in the InfoCube 9ADEMAND and extracts it into theInfoCube 9ADEMANN.

Specific InformationAs 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 CSVfile, 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, theprocesses can be scheduled as background job.

2.2.1.2 Monitoring Requirements:Error Monitoring:It is important to monitor if the data from CRM are loaded to APO BI successfully. That means if the dataloaded 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 dependson 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 bemuch shorter.

Data Consistency Requirements:The data loaded to APO BI should be consistent to the original data in CRM.



2.2.1.3 Monitoring Objects in SAP Solution Manager

MonitoringObject

SelectionCriteria

Alert Analysis Tool onSatellite System

MonitoringFrequency / Data

CollectionIDoc Monitoring(IMIDOC01)(For data exchangebetween CRM andAPO BI via IDoc)

On object level:Direction, Port,Partner number,Partner type,Partner function,Message type,Basic type,Message code,Message function,IDoc age. (in hours)

On key-figurelevel:Status number(s),Status messagequalifier, Statusmessage ID, Statusmessage number,Status age (in min)

(IDoc types areRSREQ, RSSENDand RSINFO)

Delta monitor:number of suitableIDocs since the lastdata collection

Total numbermonitor: number ofsuitable IDocs forthe last x days

BD87, WE05 Delta Check: everytwo hours

Total Check forerroneous Idocs:Daily before dataprocessing in BIstarts with aconsiderable timeframe between theData Collector runand the start of dataprocessing in BI inorder to haveenough time tosolve any errorsMonitoring mightdetect

qRFC Monitor(IMQRFCMO)(Status Monitoringof the queue set upfor data exchangebetween the CRMsystem and the BI-part of SAP APO)(The queue namesstart with CF*)

qRFC direction,RFC destination,Queue group,Command string ofSMD qRFC backlogcoll., Commandstring of SMD qRFCstatus coll.

Number of entrieswith critical status ingroup Age of oldestcritical status ingroup Combination of"Entries" and "Age"in critical state Number of entrieswith interim status ingroup Age of oldestinterim status ingroup Combination of"Entries" and "Age"in interim state

SMQ1, SMQ2,SM59

Hourly (or evenmore often)



qRFC Monitor(IMQRFCMO)(Backlog Monitoringof the queue set upfor data exchangebetween the CRMsystem and the BI-part of SAP APO)(The queue namesstart with CF*)

qRFC direction,RFC destination,Queue group,Command string ofSMD qRFC backlogcoll., Commandstring of SMD qRFCstatus coll.

Number ofindividual queues ingroup Total number ofentries in all queuesof group Average number ofentries per queue ingroup Maximum numberof entries per queuein group Age of oldest entryin group Combination of"Total entries" and"Oldest age"

SMQ1, SMQ2,SM59

Hourly (or evenmore often)

BI Query AlertCollector - KPI in BIQuery (BOBIQUAC)(To check datastored in APO BI)

RFC Destination(from managedsystem to BIsystem), InfoProvider (of BIsystem), BI queries(of that Infoprovider),Description of the BIquery

KPI in BI Query(single value), KPIin BI Query (max.values), KPI in BIQuery (# of values)

Once per day

BI ConsistencyCheck ResultCollector(DBICCRC)

Compare ResultDSO, Fieldnameand Select-Optionsfor Filter 1 - 3

Differences in resultcolumn 1,Differences in resultcolumn 2,Differences in resultcolumn 3,Differences in resultcolumn 4,Differences in resultcolumn 5,Age of lastconsistency checkresult

Once per day

File Monitoring(BOFILMON)(If flat files are usedto load sales orderdata into APO BI)

File Path, FileName, Pattern, User(File Creator)

Creation Time ofFile, File Size, FileAge (in min)

AL11 Once per day (ormore frequentlydepending on thebusinessrequirements howoften data from flatfiles is imported)

Background JobMonitoring for allprocessesscheduled intransaction RSA1 inthe APO BI system(Job names startingwith BI_*)

Background JobName, Variant,Event Parameterand Event ID (incase process chainsare used)

Start Delay, EndDelay, MaximumDuration, JobCancellation, JobLog Messages, JobLog Content

SM37 Data Collectors tobe scheduled to runonly duringtimeframe ofplanned JobExecution and torun every 5 minutesduring this timeframe



2.2.1.4 Monitoring without SAP Solution ManagerIf IDoc transfer is used, you should use transactions BD87 and WE05 to check for erroneous messages atleast every two hours.

The status, runtime, and job logs of Background Jobs can be analyzed using transaction code SM37 in themanaged system.

If you are using qRFC for data transfer, the status of your qRFC queues can be monitored using transactioncodes SMQ1 or SMQ2. In case of problems with the setup of your qRFC connection, use transaction SM59 tocheck 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 thefiles directories on your SAP system.

2.2.1.5 How to Find Meaningful Thresholds for Each Monitoring ObjectThe definition of meaningful thresholds for each Monitoring Object needs to be done in close cooperation withyour business department. It is important that you clearly define what data the data collectors measure, howoften 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 setaccording to the business requirements that might change over time.

2.2.2 Business Process Step 2: Stocking and De-stocking

2.2.2.1 DescriptionGeneral Information:

The planning services Stocking and Destocking make a to stock or not to stock decision for each locationproduct at the start of inventory planning. The result of these planning services is to set a replenishmentindicator on each location product. According to the indicator, the system orientates itself in the furtherplanning: 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 highdemand, 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 locationproduct. If so, the Destocking decision does not perform any more checks and sets the Not Stocked, Lockedindicator, as well as the blocking indicator for the corresponding location product. This means that the systemcannot build up stock of this location product, and the Destocking service cannot change the replenishmentindicator.? The system checks the entries in the decision tables. Based on these entries, the system then decideswhether to plan stocking or Destocking for each location product.? For the locations for which the system plans stocking according to the decision tables, the stockingservice 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 tothe corresponding parent locations.

These planning services are carried out in PSM - either in background or interactively. A planning profileneeds to be defined for the service.



Specific Information:Additional triggers for the stocking service can be demanded at a non-stock location or changes to the virtuallocations for consolidated ordering.

Important settings:Service 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 Monitoring Requirements:Error Monitoring:It is necessary to check if these planning services run successfully in PSM. The results of these planningservices can be seen in the PSM application log (transaction: /SAPAPO/PE_LOG_DISP). And the run statusof 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 ofcorresponding PSM run.In our experience, the access to historical data in APO BI takes quite a long time.


MonitoringObject

SelectionCriteria



CollectionDialog PerformanceMonitor(BOPERFMO)(For Monitoringresponse time oftransaction code/SAPAPO/PE_RUN)

Transaction Code(Value 1), FunctionCode (Value 2), CallType, User Pattern,Instances

Total ResponseTime, DatabaseResponse Time,Total ResponseTime (Data vol.-depend.)

STAD, ST03N Every two hours

Background JobMonitoring forprogram/SAPAPO/PE_EXEC

Background JobName, Variant, User(Note: The planningprofile is visible inthe job log)

Start Delay, EndDelay, Out of TimeWindow, MaximumDuration, JobCancellation, JobLog Messages, JobLog Content

SM37 Daily (or morefrequently in casethis job is executedmore than once perday), DataCollectors to runevery 5 minutesduring job execution

2.2.2.4 Further Monitoring Objects

MonitoringObject

SelectionCriteria



CollectionResults of planningservices in PSMapplication log

Subobjects(Services), Date andTime of PlanningRun, User thattriggered Log

PSM ApplicationLog Content

Transaction Code/SAPAPO/PE_LOG_DISP

Daily



2.2.2.5 Monitoring without SAP Solution ManagerThe Dialog Response Time of transaction code /SAPAPO/PE_RUN can be checked in transaction codeSTAD or ST03N.



2.2.3 Business Process Step 3: Manage Demand History

2.2.3.1 Description

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 historyautomatically when various events occur and realigns the data.The system initiates data realignment of the demand history either with triggers or you have to havescheduled it as a regular service in the Planning Service Manager (PSM). The following table provides anoverview of the events for which data realignment is necessary and which planning services perform thisrealignment:

Event Planning Service Technical Name of Planning Service Triggered by

Change tolocationdeterminationprocedure

SPP: DataRealignment forLoc.Det.Schema

SPP_PDEM_SERPAT_RLG ---

Stocking orDestockingdecision

SPP: Data Real. ForStocking/Destocking

SPP_PDEM_STOCKING_RLG SPP_REPL_INDI_CHANGE

Change toTPOP status

SPP: DataRealignment forTPOP

SPP_PDEM_TPOP_RLG SPP_NON_TPOPandSPP_TPOP

Assignment offuture BOD toproduct

SPP: Create DemandHistory Future BOD

SPP_PDEM_BOD_ASSIGN SPP_NEW_BOD_ASSIGN

Deletion offuture BODassignment

SPP: Delete DemandHistory Future BOD (

SPP_PDEM_BOD_DELETE SPP_BOD_DELETE



Future BODbecomes valid

SPP: DataRealignment for BODChange

SPP_PDEM_BOD_VALID ---

Suppression SPP: DataRealignment forSuppression

SPP_PDEM_SUPERSESSION_RLG ---

Promotion SPP: DataRealignment forPromotion

SPP_PDEM_PROMOTION_RLG ---

Change to finaldemand

SPP: Adjustment ofDemand History

SPP_PDEM_OVR_RLG

2.2.3.2 Monitoring Requirements:Error Monitoring:It is necessary to check the results of the realignment. The status of the realignment can be reviewed withtransaction /SAPAPO/PDEM_RLGSTEP, and the process of realignment can be reviewed in PSM applicationlog 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 andthe fixed time window.

Data Consistency Requirements:The update of the demand history only takes place in SCM APO, the original data in SCM CRM do not needto be updated accordingly.

Monitoring 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 demandhistory creation (SPP_RLG_DONE, SPP_RLG_DONE)


Monitoring Object SelectionCriteria



CollectionDialog PerformanceMonitor (BOPERFMO)(For Monitoringresponse time oftransaction code/SAPAPO/SPPDMDH)




Application Log(Transaction CodeSLG1) for Object /SAPAPO/PE andcorresponding sub-objects

Object, Sub-Object,User, Transaction,Program

Total number ofmessages, numberof critical messages,Runtime, PlanningScope, PlanningResults

SLG1 Every two hours




MonitoringObject

SelectionCriteria



CollectionResults and statusof realignment

Info Provider,Realignment Status,Validity Date,Author, LastChanged by,GeneratedRealignment Step,Generation Program

Status ofrealignment steps

Transaction Code/SAPAPO/PDEM_RLGSTEP

Every two hours

Realignmentprocessing

Subobjects(Services), Dateand Time ofPlanning Run, Userthat triggered Log



Daily

2.2.3.5 Monitoring without SAP Solution ManagerThe Dialog Response Time of transaction code /SAPAPO/SPPDMDH can be checked in transaction codeSTAD 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 ObjectThe definition of meaningful thresholds for each Monitoring Object needs to be done in close cooperation withyour business department. It is important that you clearly define what data the data collectors measure, howoften 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 setaccording to the business requirements that might change over time.

2.2.4 Business Process Step 4: Forecasting

2.2.4.1 DescriptionGeneral 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. Theforecasting service is flexible in reacting to changing demand, and uses various forecast models to planindividually 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 onthe Interactive Forecasting screen (transaction: /SAPAPO/SPPFCST). During the forecast run, the systemcalculates the forecasting results at location product level. If you are not satisfied with the results, you canmake 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).



Composite 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 fixedsequence. This is called composite forecasts. AutoMan uses composite forecasts.

Its functions include:?Model Evaluation (Automatic Model Evaluation): consists of Triggs tracking signal and tripping. Triggstracking signal checks whether the forecast model is still optimal or whether there is a systematicforecasting error. Tripping reinitializes basic values and the deviation of an existing forecast model andshortens the demand history used for forecast creation.?Model Selection (Automatic Model Selection): You can use it to automatically determine the forecastmodel best suited to a specific location product.?Smoothing Parameter Tuning (Rough Tuning): For the forecast models that consider smoothing factorsduring forecast creation, you can automatically optimize these smoothing factors by this function.?Forecast Calculation (Forecast Approval): calculates the final forecast for each location product andchecks which forecast results require manual approval according to rules that you define. The systemautomatically approves all other forecast results and provides these results to other SPP planningservices. Forecast approval is realized as a PSM planning service. However, the system also performsforecast 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 ashistorical forecasts. You can also schedule the PSM planning service Recalculation of the Forecast inthe Past. If the forecast model changes, the system triggers this planning service so that it createshistorical 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 thatdo 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.



2.2.4.2 Monitoring 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, planningparameters and forecast models can be modified, and further forecasts run can be started manually orscheduled via PSM.

Performance Monitoring:Whether the performance of forecasting needs to be monitored depends on the frequency of these servicesand the fixed time window. Especially for composite forecast includes several services and it run time shouldbe controlled strictly.


Monitoring Object SelectionCriteria



CollectionBackground JobMonitoring for program/SAPAPO/PE_EXEC




Dialog PerformanceMonitor (BOPERFMO)(For Monitoring responsetime of transaction code/SAPAPO/SPPFCST)




Dialog PerformanceMonitor (BOPERFMO)(For Monitoring responsetime of transaction code/SAPAPO/SPPFCSTPRF)





MonitoringObject

SelectionCriteria



CollectionForecast results inPSM application log




Daily

Forecast results inInteractiveForecasting Screen

Detailed forecastresults

Transaction Code/SAPAPO/SPPFCST

Daily



2.2.4.5 Monitoring without SAP Solution Manager

The Dialog Response Time of transaction codes /SAPAPO/SPPFCST and /SAPAPO/SPPFCSTPRF can bechecked in transaction code STAD or ST03N respectively.



2.2.5 Business Process Step 5: Economic Order Quantity & Safety Stock

2.2.5.1 Description

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. Thisplanning can either be carried out manually in transaction /SAPAPO/SPPINVP, or planned as a service inPSM (service name: SPP_EOQSFT_SERVICE). The results are stored in key figures economic orderquantity 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 foreach location product depending on its sales behavior. Normal distribution is suitable for products withconstant demand and Poisson distribution is suitable for products with intermittent demand. The modelselection 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 thecombined calculation of EOQ and SFT. For Poisson distribution, the system uses the forecast values for thenumber of order items as the basis, and then calculates the demand in pieces using the average demandsize 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 thatresults vary for each period. This is defined in customizing.

Important settings:Service Profile Service profile for EOQ/SFT calculation.Forecast Strategy Forecast types and decides whether they are to follow constant or non-constantplanningMaster 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 thestatistical calculation model for the combined calculation of EOQ and safety stockFix EOQ Period field: you can choose between EOQ Manually Locked, EOQ POD Manually Locked, andUnlockedMin. EOQ Per. and Max. EOQ Per. Fields: to indicate the minimum and maximum number of days that anEOQ period may last.Safety Stock field: the system considers your manual entry until the next planning run, otherwise this isautomatically filled



SFT Parent Loc. Field: the inventory planning service enters the proportion of safety stock of the parentlocation that is to be forwarded to the locationAddl. Safety Stock field: number of days of demand for which the system is to schedule additional safetystock.OT-Dep. Sfty St. % field: proportion of safety stock that must be reserved for emergenciesMinimum 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 Monitoring 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 monitoring:Whether the performance of EOD and SFT planning needs to be monitored depends on the frequency ofthese services and the fixed time window.


MonitoringObject

SelectionCriteria



CollectionDialog PerformanceMonitor(BOPERFMO)(For Monitoringresponse time oftransaction code/SAPAPO/SPPINVP)









MonitoringObject

SelectionCriteria



CollectionResults of service inPSM application log




Daily

Results of EOD andSFT planning

Detailed results ofEOD and SFTplanning

Transaction Code/SAPAPO/SPPINVP

Daily



2.2.5.5 Monitoring without SAP Solution ManagerThe Dialog Response Time of transaction code /SAPAPO/SPPINVP can be checked in transaction codeSTAD or ST03N.


2.2.5.6 How to Find Meaningful Thresholds for Each Monitoring ObjectThe definition of meaningful thresholds for each Monitoring Object needs to be done in close cooperation withyour business department. It is important that you clearly define what data the data collectors measure, howoften 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 setaccording to the business requirements that might change over time.

2.2.6 Business Process Step 6: Surplus & Obsolescence Planning

2.2.6.1 Description

General Information:During surplus and obsolescence planning, the system identifies surplus and obsolete stock within a bill ofdistribution (BOD). If the warehouse stock and the stock in transit of a product within a BOD are greater thanthe probable demand during a certain time period, this part of the stock of a product is described as surplusstock. If a product fulfils the following conditions, it is described as obsolete stock: The product is a servicepart of a product that you no longer produce and whose mandatory retention period has elapsed, and thedemand for this product is below a certain limit value.

The planning process is consisted of following steps in sequence:

1. Surplus Determination ServiceThis service determines the products within a bill of distribution (BOD) that could be surplus. It firstly selectsproducts according to whether or not it is to perform surplus determination for them. The system thendetermines the total surplus quantity as well as the surplus quantities per location. Based on the surplusquantities per location, the system suggests surplus quantities and retention quantities, and checks whether itcan automatically approve these surplus quantities for scrapping, or whether it must forward them for manualapproval.

You can either schedule this service regularly, for example every year or every six months, as a planningservice via PSM (service name: SPP_SOS_SURPLUS_DETERMINATION), or process it manually, forexample if you need more warehouse space or if you want to reduce the stock value in your warehouse(transaction /SAPAPO/SPPMSP).

2. Surplus ApprovalFollowing the surplus determination service, the planner can then approve each of these surplus quantitiesmanually 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 surplusquantity 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 ServiceThis service checks whether the stock of a product marked as obsolete is completely used-up, if yes, it marksthe product with the Obsolete indicator and sends an alert (in Alert Monitor) to inform planner, and changesthe replenishment indicator according to your settings in Customizing. You can only remove the product fromyour assortment if this is the case.



You can schedule the obsolescence check service as a regular planning service, for example monthly in thePSM (service name: SPP_SOS_OBSOLESCENCE_CHECK).

4. Surplus ReportingYou can generate reporting for each surplus quantity and surplus value for which you have approvedscrapping or another follow-on activity. These quantities and values are entered in the report for both thewhole BOD and the individual locations.Surplus reporting is an automated process initiated by approving surplus quantities. The Infocube 9ASORPLis a virtual Infocube for surplus reporting, so you can use this to display reporting data in BI (TransactionRSA1), or you can create some queries for Business Explorer.

Important settings:Customizing Implementation Guide (IMG) for Advanced Planning and Optimization ? Supply ChainPlanning? Service Parts Planning (SPP)? Surplus and Obsolescence Planning:Make General Settings for Surplus and Obsolescence PlanningDefine Surplus Decision CodeDefine Surplus Decision Reason CodeDefine Service Profile for Surplus and Obsolescence PlanningMaster 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; andlocation master data, on the SPP tab.

2.2.6.2 Monitoring Requirements:Error Monitoring:To fulfill the service function it is necessary to make sure that all the relevant settings in customizing andmaster 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 onlyallows short time window for this step, the performance should be monitored.


MonitoringObject

SelectionCriteria



CollectionDialog PerformanceMonitor(BOPERFMO)(For Monitoringresponse time oftransaction code/SAPAPO/SPPMSP)



STAD, ST03N Daily

Dialog PerformanceMonitor(BOPERFMO)(For Monitoringresponse time oftransaction code/SAPAPO/SPPSOR)



STAD, ST03N Daily




(For both theSurplusDeterminationService as well asfor theObsolescenceCheck Service.)



SM37 Monthly (or evenless frequent incase this job isexecuted less thanonce per month),Data Collectors torun every 5 minutesduring jobexecution.

BI Query AlertCollector - KPI in BIQuery (BOBIQUAC)(To check datautilized in theSurplus Reporting)

RFC Destination(from managedsystem to BIsystem), InfoProvider (of BIsystem), BI queries(of that Infoprovider),Description of the BIquery

KPI in BI Query(single value), KPIin BI Query (max.values), KPI in BIQuery (# of values)

Daily

BI ConsistencyCheck ResultCollector(DBICCRC)

Compare ResultDSO, Fieldnameand Select-Optionsfor Filter 1 - 3

Differences in resultcolumn 1,Differences in resultcolumn 2,Differences in resultcolumn 3,Differences in resultcolumn 4,Differences in resultcolumn 5,Age of lastconsistency checkresult

Daily

Background JobMonitoring for allprocessesscheduled intransaction RSA1 inthe APO BI system(Job names startingwith BI_*)

Background JobName, Variant,Event Parameterand Event ID (incase process chainsare used)

Start Delay, EndDelay, MaximumDuration, JobCancellation, JobLog Messages, JobLog Content

SM37 Data Collectors tobe scheduled to runonly duringtimeframe ofplanned JobExecution and torun every 5 minutesduring this timeframe


MonitoringObject

SelectionCriteria



CollectionResults of planningservices in PSMapplication log

Subobjects(Services), Dateand Time ofPlanning Run,User thattriggered Log



Monthly

Best Practice for