Manage operations for sap price optimization

BP_MO_for_SAP_Price_Optimization_V30.doc – 11.05.2009

Best Practice

Manage Operations forSAP Price Optimization

Dietmar-Hopp-Allee 16D-69190 Walldorf

CS STATUScustomer published

DATE VERSION

Dec-08 2008 3.0

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 PracticeManage Operations for SAP Price Optimization

© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 2/59

Table of Contents1 Management Summary 3

1.1 Goal of Using this Best Practice 31.2 Alternative Practices 31.3 Staff and Skills Requirements 31.4 System Requirements 41.5 Duration and Timing 41.6 How to Use this Best Practice 41.7 Best Practice Procedure 5

1.7.1 Preliminary tasks 51.7.2 Monitoring concepts 51.7.3 Business process monitoring in SAP Solution Manager 61.7.4 Monitoring types for business process monitoring in SAP Solution Manager 61.7.5 Business process monitoring process 191.7.6 Legend 19

2 Business Process Monitoring for Weekly Data Processing 202.1 Sample Scenario 202.2 Business Process: Weekly Processing 22

2.2.1 Business process step 1: Export master data 222.2.2 Business process step 2: Export weekly sales 262.2.3 Business process step 3: File transfer 282.2.4 Business process step 4: Load weekly data 292.2.5 Business process step 5: Data validation 312.2.6 Business process step 6: Product linking and data preparation 33

2.3 Business Process: Weekly Modeling 392.3.1 Business process step 1: Model 392.3.2 Business process step 2: Review and post models 43

2.4 Business Process: Price Optimization 452.4.1 Business process step 1: Optimization process 452.4.2 Business process step 2: Generate and review forecasts 50

2.5 Business Process: Price File Delivery 522.5.1 Business process step 1: Deliver price files 522.5.2 Business process step 2: File transfer 54

3 Further Information 573.1 Related Best Practice Documents 573.2 Solution Manager Setup Guides 57



1 Management Summary

1.1 Goal of Using This Best Practice

This Best Practice helps you set up a Business Process Monitoring concept for your SAP Price Optimizationsolution. The concept aims to define procedures for business process oriented monitoring and error handlingand escalation procedures for your business process “Optimize Regular Prices”. These procedures intend toensure a smooth and reliable flow of this core business process so your business requirements are met.

This Best Practice gives orientation for defining suitable application oriented monitoring objects in order todetect any irregularities or deviations from an ideal business process flow or to detect error situationsconcerning a core business process at an early stage.

This Best Practice contains the recommended approach from SAP which uses whenever possible the SAPSolution Manager for the Monitoring functionalities. But even if you do not use the SAP Solution Manager werecommend to follow the procedures described in this document as much as possible in order to ensure asmooth and reliable flow of your business processes as well as an appropriate response in case ofunforeseen errors.

1.2 Alternative Practices

You can have SAP experts deliver this Best Practice remotely or on-site by ordering an SAP SolutionManagement Optimization (SMO) service for SAP Business Process Management (BPM). This service isexclusively available within SAP’s support engagements SAP MaxAttention and SAP Safeguarding. If yourcompany currently does not have any support engagement with SAP, it is also possible to get assistance bySAP experts from SAP Consulting. In 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 Team

This team creates the Business Process Monitoring concept and consists of experts from several areas ofyour company: Business department Solution support organization (for example the Environment 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 fromimplementing this best practice. They include the following groups: Persons designated to perform business process oriented monitoring and ensure that the process runs

smoothly (e.g. 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, Job Scheduling Management)



SAP Technology Operations Team

All parties in your Solution Support Organization and IT department involved in monitoring focused on thesystem administration side (Program Scheduling Management, Software Monitoring Team, SystemAdministration Team including the System Administrator)

Business Process Champion

The Business Process Champion is the person in the business department that is responsible for thesuccessful execution of the business process. He coordinates all activities necessary for the businessprocess. Therefore, he is usually responsible for the escalation paths in case of problems. Often he is asecond level in the escalation procedure, if the application monitoring team 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 under http://service.sap.com/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

In order to monitor business processes running in your SAP Price Optimization solution via SAP SolutionManager, the SAP Basis Release of the systems to be monitored have to be at least 4.6C.

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.

Timing

The 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 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 ServiceMarketplace. This document explains the procedures you should use to create a general Business ProcessManagement 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 andthe assignment of responsibilities.

http://service.sap.com/bpm.



At the beginning of chapter 2 you will find a typical flow chart of the core business process explained in thisBest Practice. It is intended to be used as a guideline for writing down your company specific processdocumentation.

In chapter 1.7.4 you find further information that is relevant for more than one scenario. In case informationfrom the generic part is relevant for a specific business process step in one of the scenarios you will find aclear link to the corresponding chapter in the generic part.

1.7 Best Practice Procedure

1.7.1 Preliminary tasks

Before 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 download 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 concepts

The 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 inchapter 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 Retailsolution is generally the same. Therefore, you will only find specific performance monitoring recommend-dations 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 alltechnical and business application specific functions that are required for a steady and stable flow of thebusiness processes.

The core business processes implemented in an SAP Price Optimization system and operated by a companyare of particular importance, and business process monitoring is intended to ensure a smooth and reliableoperation of the business processes and, thereby, that the core business processes meet a company’sbusiness requirements in terms of stability, performance, and completeness.

Please note however that SAP Price Optimization solution is not yet fully integrated with the SAP SolutionManager. Some of the monitoring capabilities described in this document are available on SAP NetWeaverABAP systems only and do therefore not apply to SAP Price Optimization.

The SAP Solution Manager provides a graphic to visualize a company’s (distributed) system and solutionlandscape and all related business processes. By using business process monitoring, it is possible to defineand customize alert situations from a basic set of configurable alerts provided by the SAP Solution Manager.These alerts are then visualized by green, yellow, and red alert icons for each individual business processstep in the graphical business process representation. Business process monitoring is intended to detect andrespond to critical situations as early as possible in order to solve problems as fast as possible.

In addition, the 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 intothe company’s overall strategy for business process management and solution management within theirsolution support organization.

In general, a 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 etc.) Data transfer via interfaces between software components Data consistency Technical infrastructure and components which are required to run the business processes offered by

SAP Solution Manager DiagnosticsRequired 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 Manager

Monitoring Types are part of the functional scope of business process monitoring as it is available in the SAPSolution Manager. The below mentioned monitoring types are available: Application Monitor (Throughput and Backlog Indicators, Data Consistency Checks, Mass Activity

Monitors, Due List Log, MRP key figures, User Exit) Background Jobs (Jobs running on SAP Systems with an SAP Basis) Dialog Performance (Dialog transaction performance) Update Error (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) Interface Monitoring 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. In order to receive detailed information on how to set up the Monitoring Objects in the SAPSolution 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 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, please turn to(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 the Business ProcessMonitoring. The latest Monitoring objects are only provided if the latest ST-A/PI plug-in is installed on thesatellite 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.

Please ensure that the most current version of the ST-A/PI is installed on the SAP Solution Managersystem 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 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).

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 so called 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 Logistic the following monitors are available: Sales and Services (e.g. Sales Documents, Invoices) Warehouse Management (e.g. Transfer Requirements, Transfer Orders) Inventory Management (e.g. Goods Movements) Logistics Execution (e.g. Deliveries, Shipments) Procurement (e.g. Planned Orders, Purchase Requisitions, Purchase Orders)


http://help.sap.com)/

http://www.service.sap.com/



Manufacturing (e.g. Planned Orders, Production or Process Orders, Autom. Goods Movements postedwith error, Confirmation Pool errors)

Plant Maintenance (e.g. PM/CS Notifications, PM/CS Orders)

For further information on the different TBIs refer to the document ‘Setup Guide - Application Monitoring’(URL http://service.sap.com/bpm Media Library).

1.7.4.2 Background job

The 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, e.g. time restrictions, restriction of hardware resources (CPU, main memory, …) or existingdependencies between different activities (e.g. invoices can only be created after the corresponding goodsissue is posted, or Back Order Processing and Material Requirements Planning should not run at the sametime) it is very important to ensure the stable run of background jobs. A cancelled background job should beidentified as soon as possible in order to react as fast as possible. Therefore it is also necessary to definerestart procedures and escalation paths.

1.7.4.3 Interface monitoring

An automated interface monitoring enables for a proactive monitoring and alerting of the data exchange. Thefollowing are the important aspects for interface monitoring: Errors: Detection of errors during data exchange or data processing. Backlogs: Detection of growing backlogs in the data processing. Interface performance and throughput: Detection of slow data processing resulting in a decreasing

interface throughput.

1.7.4.4 Monitoring objects

Before 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-node‘Background Job’ below a business process step.

A more detailed description (than provided in this document) on the subject what kind of alerts make sense orwhat kind of alerts are possible are discussed in the Best Practice document Background Job Monitoring withSAP Solution Manager. You can find this document on the SAP Service Marketplace athttp://service.sap.com/solutionmanagerbp Topic Area Business Process Operation.

1.7.4.5 ABAP dump collector

To provide monitoring features for alerting on occurrences of ABAP dumps of specified runtime errors or tocollect statistical data of ABAP dumps for reporting reasons.

http://service.sap.com/bpm

http://service.sap.com/solutionmanagerbp

http://service.sap.com/solutionmanagerbp



Monitoring objects

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

Monitoring alerts

Possible Alert Types are the Number of ABAP Dumps (Delta) – all dumps since the last collector run – andNumber of ABAP Dumps (Reporting) – all runtime errors of specified type, client and program for this day orfor the previous day.

Figure 1: Alert types – Number of ABAP Dumps (Delta)

1.7.4.6 Dialog performance

Dialog Performance implies the monitoring of the dialog transaction performance of any transaction in theSAP System. This could be a standard transaction or an own developed transaction.

Monitoring objects

The monitoring object is the transaction itself. The customizing has to be done in node ‘Dialog Performance’.In 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 removetransactions within table ‘Add/Remove Transactions’. The monitoring can be performed per SAP instance.Therefore the respective instances have to be selected in table ‘SAP Instances’. All instances that aremaintained for a system are listed there. Table ‘Alert Types’ shows the dialog response time and all parts ofthe response time, like queue time, load and generation time, database request time and the front-endresponse time, that 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 beentered.



Figure 2: Monitoring objects – Dialog performance

Monitoring alerts

Each table in the sub-node ‘Performance Alerts’ corresponds to an alert type chosen in the higher-level nodeand lists the combinations of specified transaction code and SAP instance.

For each combination of transaction code and instance that should be included in the monitoring, thethreshold 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", whereas “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".

Figure 3: Monitoring alerts - Dialog performance



1.7.4.7 Update errors

Changes 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, suchas result calculations.

Monitoring objects

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

Figure 4: Monitoring objects – Update errors



Monitoring alerts

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.8 Due list log

A 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 directly accessed via transaction V_SA, the billing duelist via transaction V.21. In case of a billing due list, the list contains e.g. a number of sales documents thatneed to be billed. If the billing due list was processed previously and it is important to know which billingdocuments were created from this billing due list, it can be displayed in the due list log for this billing run.

Monitoring objects

The 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’.

Monitoring alerts

For the monitoring of due list log messages, five different alert types can be used: ‘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. ‘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.

‘TotalQuantityMsgs’refers to the total number of message created during a Due List run. 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. ‘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 messagesthat result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (or back) must bemaintained.

Figure 5: Monitoring alerts - DocumentCreation



1.7.4.9 Application log

The 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, etc.). A transaction can generate several logs.The Application Log is not written consecutively but as a whole at one point in time.

Monitoring Objects and Alerts

The Application Log allows an application- or object-oriented recording of events. An object and any sub-object 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.

Figure 6: 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. Toconfigure 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 and the messagenumber as well as the threshold values for the number of critical messages that are supposed to result inchanges from GREEN to YELLOW and from YELLOW to RED can be specified. It is also possible to use wildcards.



Figure 7: Monitoring alerts – Application log/critical messages

1.7.4.10 Other CCMS monitors

With Other CCMS Monitors it is possible to assign any CCMS monitoring tree element (MTE) to a businessprocess step or interface. Therefore it is necessary to call transaction RZ20 in the Satellite System and toopen 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 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 a MTE on the lowest leaf-level, i.e. on attribute level. If aMTE of a higher branch-level (collective MTE) is chosen then the current and open view in thegraphics will show the right alerts but it isn’t possible to work on 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 on the copy icon.



Figure 8: Other CCMS monitors

Unlike all other Monitoring Types the Other CCMS Monitoring provides the opportunity to assignMTEs 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.11 Analysis and monitoring tools

It is possible to specify analysis transactions or URL addresses (including file directories) per monitoringobject. In case of analysis transactions these should be used to analyze errors or problems either locally inthe SAP Solution Manager system itself (Call Option “1”) or directly in the respective satellite systems (CallOption “2”). Per default some standard transactions are maintained, e.g. transaction SM37, that provides ajob overview in an SAP System, is maintained for Background Jobs or transaction SLG1 to have a look intothe application log.

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



Figure 9: Analysis & monitoring transactions

On the second tab strip it is possible to specify an URL which should be called in order to further analyze thegiven problem. This is especially interesting if you have some knowledge documents linked to a portal. Youdefine a Short text and the URL to be called.

For web pages to be called, specify the full URL, e.g. http://help.sap.com. For content available on fileservers specify the full file path, using the nomenclature: file://\\\<server>\..., e.g.file://\\\server1\operations_documents\operations-handbook.txt

Figure 10: 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 (e.g. ), the user will jump directly into the corresponding transactioneither in SAP Solution Manager (here: SAT) or the connected satellite system (here: CT1) for further analysis.

For URLs the push-button (e.g. ) 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.

http://help.sap.com./



1.7.4.12 Monitoring activities

Monitoring activities should be defined 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 procedures shouldbe defined as described in the following table. Some information is taken from the previous node ‘SolutionSupport 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. Usevalue 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 the requiredmonitoring activity.

Problem Indicator A description about what indicates a problem.

Error Handling Describes how to react on problems or errors, i.e. how to solve the problem/correctthe error.

Escalation Path Describes the escalation path in case that the person responsible could not solvethe problem. Persons who can be contacted should be maintained here.

Table 1: Monitoring activities – Responsibilities and problem resolution procedures

Additional information related to this business process step can be entered in the tables ‘MonitoringActivities’, ‘Error Handling’, ‘Restart of Step’ and ‘Escalation Path’. Those 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.13 Notifications

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 notificationsallow sending messages in case of alerts to a specified Recipient. This could be an e-mail or SAPOffice mail.Support notifications allow setting up a service desk message in case of an alert. The information entered forthe service desk message serves as a template. The service desk message can be created manually orautomatically.

On business process level it is possible to define notifications for the whole business process i.e. as soon asthe business process gets an alert status, notifications will be triggered. Alternative notifications can bedefined for every Monitoring Type individually, e.g. all alerts related to all background jobs of the businessprocess 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.

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 user musthave a valid e-mail address that is known by the used mail-server

Recipient Address Depending on the Recipient Type the recipient name is required. This could beany e-mail address, an SAP user name in the same system, a Remote SAPname or a shared distribution list. In 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 andPager), B (SAP user name), R (Remote SAP name) and C (shared distributionlist).

No. of YELLOWAlerts

Number of YELLOW alerts that may occur before an automatic notification istriggered

No. of RED Alerts 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, evenif the thresholds are not exceeded

RED Only To restrict this mechanism only to red alerts the flag in column 'RED Only' mustbe set.

Detailed Triggers a long text for e-mails or SAPOffice mails, e.g. name of the solution,name of the business process step, …)

Table 2: Workflow notification

Support notifications

Priority Defines the priority of the Support Notification.

Queue Defines the support component on which the message is put. This componentmust exist within the service desk.

Processor Defines a default processor who should process the message. The processormust be known within the service desk and must be SAP user name who isdefined as a Business Partner with 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 be aSAP user name who is defined as a Business Partner with role “General”.

No. of YELLOWAlerts

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

No. of RED Alerts Necessary when service desk messages are created automatically, e.g. after 5red alerts a service desk message should be created.

Table 3: Support notification

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. In case that both columns are filled with a value the automatic Support Notification creationworks with a logical OR operation. Hence, with the figures in the table above the system would create a.Support Notification if there either exist more than 9 yellow alerts OR more than 4 red alerts for whichno Support Notification has been created yet.

1.7.5 Business process monitoring process

For a successful and efficient Business Process Monitoring concept, a process for the execution of themonitoring concept has to be defined. This includes the definition of the roles and responsibilities involved. Ithas to be defined who is supposed to carry out which activity within the process and how communicationbetween 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. 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 contained within these processes are adequate to support theBusiness Process Monitoring concept. This includes the final communication of open alert 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.

1.7.6 Legend

This symbol indicates you a paragraph from where you can navigate to another chapter of thisdocument for more detailed information on a topic.

This symbol indicates you a paragraph from where you can navigate to another document within theSAP Service Marketplace for more detailed information on a topic.



2 Business Process Monitoring for Weekly Data Processing

This chapter will show you by four example processes, how business process monitoring for SAP PriceOptimization could possibly look like. It will introduce you to generic thoughts and ideas how to identify abusiness process step you could keep an eye on and makes you familiar with how to choose the mostpromising monitoring possibilities from the available ones.

To make this most visible to you, we have situated the four example processes in a fictional company.

2.1 Sample Scenario

PC Express is a midsize company. Its main business is selling PC components at their retail stores. Thestores are divided into regions across the United States geographically. Each region is divided further bydemand patterns, store with similar sales patterns and demographic characteristics are grouped together forthe purposes of pricing.

Prices are established by a centralized pricing department located at Company Headquarters where pricingdecisions are made by a team of Merchants and Pricing Analysts.

To be able to do this they use the following core business processes.1. Weekly Processing2. Weekly Modeling3. Price Optimization4. Price File Delivery

The following chapter takes you step by step through these four core business processes, explaining whereand how you can identify focus points for Business Process Monitoring. For each business process step themost effective ways for Business Process Monitoring in the context of the example are highlighted.

The overall process flow is shown below. The sections following will describe each process contained in thisoverall view in more detail. These are labeled P01 to P04 in the diagram below.



SAP PI

SAP ERP RetailSystem

SAP BI System SAP Demand Management

DM Database

Load Weekly Data

Export Weekly Sales

Export Master Data

Receive Price Changes

ImportTables

Data Validation

Model

Review & Post Models

Deliver Price Files

Data Prep

Optimization Process

File Transfer

P01

File Transfer

Generate & ReviewForecasts

P04

P02

P03

Figure 11: SAP Price Optimization – Overall process flow



2.2 Business Process: Weekly Processing

In order for SAP Price Optimization to stay current, data must be loaded into the system each week. The dataformats and processes for the transmission of the data will have been established during the implementationof the application so this document will only describe the steps necessary to perform the weekly loads intoSAP Price Optimization.

SAP PI



DM Database

Load Weekly Data

Export Weekly Sales

Export Master Data

ImportTables

Data ValidationData Prep

File TransferP01

Figure 12: SAP Price Optimization – Weekly processing

2.2.1 Business process step 1: Export master data

2.2.1.1 Description

During the Master Data Export step data will be exported from an SAP ERP Retail system using the standardinterfaces to SAP Price Optimization. This process step extracts the necessary weekly data from the ERPsystem and provides the data for a seamless file transfer in an integrated environment. This data transfer canbe triggered by transaction RDMCHG which extracts updates for the stores, products, prices, zones, storeinventories, distribution centers, distribution center inventories and store - distribution center assignments.The extracted data is sent to SAP PI which converts the data into the target file structure and places the fileson a shared folder. From this shared folder, SAP Price Optimization can seamlessly pick up all files usingSQL Loader.



Scenario-specific sample

PC Express has determined that the weekly change load (transaction RDMCHG) will run in background of thedata. Therefore no person has to run any specific transaction manually.

2.2.1.2 Monitoring requirements

Error monitoring

The file transfer should be monitored after the estimated end of transaction run RDMCHG to ensure that allfollowing process can run. This monitoring can be done immediately after the transaction has finished with alog view of the processed data in job log. If an error arises the operator can jump into every message whichhas been created and get detailed information for the error cause.

The lowest level of detail is the XML messages which are created and transferred to PI and can be monitoredin transaction SXMB_MONI or the Runtime Workbench on Java. Additionally, the file adapter placing the filesshould be monitored.

The monitoring should follow these steps: To review all logs which got created during the outbound processing of the data on the ERP side – the

logs can be easy accessed by the Easy Access Menu for the SAP ERP Retail system: Retailing ->Distributed Retailing -> Demand Management Integration -> Outbound -> Logs

To check the processing of XML messages between ERP and PI TA SXMB_MONI should be used. To check end-to-end communication e.g. including the communication with the file adapter use the

Runtime workbench of SAP Exchange Infrastructure.


The operator of PC Express will run the transaction RDMCHG and after a successful execution he can reviewthe log view of transaction RDMCHG and jump from there into the xml messages to make some randomchecks for data consistency.

Performance monitoring

Depending on the data which is taken into account via the pre-selection and the changes which occur fromweek to week the execution time of the transaction is very individual. Therefore in every project theperformance data export schedules should be defined accordingly to the customer requirements.


During the operation of SAP Price Optimization the operator should get active regarding performance whenusers acknowledge bigger performance issues as measured during the implementation phase of the project.The operator can use the tools provided by SAP for performance measurement like transaction STAD.

Throughput monitoring

For the success of the business process execution the throughput of data records for each message type iscritical. It has to be ensured that enough data records can be created in a specific manner of time to completethe weekly processing in the planned amount of time.




If the system is generation data records to slow the operator of PC Express will evaluate statistical datarecords in STAD.

Backlog monitoring

All change pointers should be processed during the time window which is predefined for each change load atafter completion of the change load all change pointer should be reset.


In PC Express the status of the change pointer after the change load should be checked and if there is a bigamount unprocessed – a warning should be send out to the operator.


MonitoringObject

Selection Criteria Alert Analysis Tool onSatellite System

MonitoringFrequency /DataCollection

Status of Jobrunningtransaction /program

By Jobname/Program ProgramRDM_OPT_CHANGE_REQUEST

Job canceled SM37 Weekly

Runtime of Job Program Program

RDM_OPT_CHANGE_REQUEST

SM37 Weekly

Joblog Message type Warningsoccurred

SM37 Weekly

Application Log Object Warningoccurred(Yellowlights)

RDM_SLG1_CHG_OUT

Weekly



Message status Message types:

RDMViewOfMaterialTransmissionRequestMessage_async_In,RDMViewOfLocationStoreTransmissionRequestMessage_async_In,RDMViewOfSalesPriceSpecTransmissionReqMsg_async_In,RDMViewOfPriceZoneTransmissionRequestMessage_async_In,RDMViewOfStoreInventoryByMaterialAndLocTransReqMsg_async_In,RDMViewOfLocationDCTransmissionRequestMessage_async_In,RDMViewOfDCInventoryByMaterialAndLocTransReqMsg_async_In

Emptypayloads

SXMB_MONI in ERP Weekly

Message status Message types:

MaterialRetailDemandManagementBulkRequest_Out,StoreRetailDemandManagementBulkRequest_Out,SalesPriceInformationBulkRequest_Out,StorePriceLevelBulkRequest_Out,StoreSupllyingBranchBulkRequest_Out,InventoryBulkRequest_Out,LocationBulkRequest_Out,InventoryBulkRequest_Out

Emptypayloads

SXMB_MONI in PI orRuntime Workbench

Weekly

Number ofUnprocessedchange pointers

Message types for changepointers: Article, Site, Price,Pricelist, Store Inventory,Distribution Center,Distribution Center Inventory,Supplying DC for Store

File AdapterStatus

File Adapter to Shared Folderfor SAP Price Optimization

Adaptershows error

Runtime Workbench -> ComponentMonitoring -> AdapterEngine ->CommunicationChannel Monitoring

Table 4: Export master data – Monitoring objects



2.2.1.4 How to find meaningful thresholds per monitoring object

Meaningful thresholds should be defined during the implementation phase of each project because thesethresholds differ depending on the amount of data and hardware a customer is using. Therefore aperformance check for the customer system should be done and updated frequently.

2.2.1.5 Error handling per monitoring object

The schedule of this process is weekly based so all monitoring objects should be observed weekly after theprocess should have finished.

Background Job RDMCHG

Check Job Log for cancellations. Check Application log for warnings and errors. Check Message status for wrong mappings and empty xml messages.

2.2.2 Business process step 2: Export weekly sales

2.2.2.1 Description

Weekly sales are typically stored in SAP BI and are used by Price Optimization for updating the productspecific demand models. The export process of sales data is defined customer specific aligned to the definedprocessing schedules. The export of the weekly sales is defined during the setup of the process chain in theSAP BI system, as described in the configuration manuals.


Weekly sales are stored in SAP BI and are exported automatically as defined in the business blueprint ofeach specific customer.

2.2.2.2 Monitoring requirements:

Error monitoring

To monitor the data load in SAP BI (extraction from source systems into BI, outbound of sales data to OpenHub Destination) the standard tools of the Data Warehousing Workbench can be used. More information isprovided via the SAP help portal:

Open page http://help.sap.com. Choose SAP Solutions SAP Netweaver SAP Netweaver 7.0 (2004s) inyour favorite language. Navigate to SAP Netweaver by Key Capabilty Information Integration BusinessIntelligence Data Warehousing Data Warehousing Workbench.


To ensure a high performance of the sales data export, it can be useful to regularly check the systemperformance during the upload execution. For further details please refer to the generic Run SAP - BestPractices for Solution Management documentation ‘Periodic Jobs and Tasks in SAP BI’ under

https://service.sap.com/solutionmanagerbp.


http://help.sap.com./

https://service.sap.com/solutionmanagerbp.



An operator checks regularly as determined in the implementation phase of project the system log andstatistics.

Backlog monitoring

To get a good overview over the data staging and database performance situation of the system, the usageof monitoring tools additional to the already described ones are available.


Check the database tune summary of the delta queue and PSA table of DataSource0RT_SALES_DATA_SAPDM.

The following basis monitoring tool is available: Tune Summary (transaction ST02)


During the sales data export run an operator observes the system behavior in ST02.


MonitoringObject

Selection Criteria Alert Analysis Toolon SatelliteSystem

MonitoringFrequency /Data Collection

Tune summary,MemoryManagement

ST02 Weekly

ABAP RuntimeErrors

Error Name, Exception ST22 Weekly

System Log Object Warning, Errors SM21 Weekly

BI Process Chain Chain containing DataSource0RT_SALES_DATA_SAPDM

Processingstatus

Table 5: Export weekly sales – Monitoring objects


Meaningful thresholds have to be determined in scope of the project depending on the requirements of thecustomer.


Further details about monitoring tools in SAP BI are available as generic SAPBest Practices for SolutionManagement documentation in https://service.sap.com/solutionmanagerbp under ‘Monitoring for BI

Basis (ABAP and Java)’, ‘Monitoring for BI Reporting’ and ‘Background Job monitoring with SAP SolutionManager’.

https://service.sap.com/solutionmanagerbp



2.2.3 Business process step 3: File transfer

2.2.3.1 Description

The export of the data from SAP ERP/BI places the files in the correct location for SAP DM.


PC Express is a current SAP ERP/BI customer and as such does not need to be concerned with any filetransfer. The weekly data export places the data in the correct folders on server for the DM application. Inaddition, PC Express hosts their hardware so no encryption needs to occur.


File monitoring with SAP Solution Manager

In order to monitor the files created by PI, the SPACCMSR agent is available. This agent allows you tomonitor e.g. File availability at a certain point in time, File Size, File Age etc. This information can also beforwarded to local CCMS and be read by SolMan from there. See SetupGuide for IFMon(http://service.sap.com/bpm -> Technical Information -> Setup Guide Interface Monitoring)

Error monitoring

All files transfers will need to complete successfully before the following processes can begin.


An operator will need to monitor the file transfer process to make sure all files are present before beginningthe ‘Load Weekly’ process.


File transfer should take place according to a predetermined schedule so the SAP-DM load processing canbe scheduled. The next step of processing (Load Weekly) is generally kicked off manually, which requires auser to verify all files are present.


All files coming from PC Express will be in the correct server location by 18.00 Sunday.


It is vital that all files can be transferred in a reasonable amount of time. The file transfer process should takeno more than 12 hours to complete for very large clients.


If any issues occur that will cause the transfer to complete later than this time, an IT representative from PCExpress will inform the SAP-DM team as to when the transfer will be complete. If files are not present on19.00 Sunday, a representative from SAP will contact PC Express.

Backlog monitoring

Not applicable.





MonitoringObject

SelectionCriteria

Alert Analysis Tool onSatellite System

MonitoringFrequency / DataCollection

File presence Files not presentor complete at thedesired time

Manual step

Table 6: File transfer – Monitoring objects


A predetermined deadline is agreed to by the client for expected delivery of all weekly files.


If it is determined that the files are not present by the deadline, the operator will contact the appropriate clientpersonnel to investigate and provide a suitable workaround.

2.2.4 Business process step 4: Load weekly data

2.2.4.1 Description

This step will move the weekly master and sales data into the import tables using SQL Loader to prepare forfurther processing. This process verifies that the expected files are present.


It has been decided that SAP will be responsible for weekly processing in the PC Express environment. TheLoad Weekly process is started by an operator using the PC Express production UI.

2.2.4.2 Monitoring requirements:

Error monitoring

Error notification is provided in the processing screen within the SAP-DM application. Verifying the processhas completed successfully requires a refresh of the processing screen. The status will indicate whether theprocess is running, has completed, or has failed.


From the processing screen, the analyst will validate that the Load Weekly process has completedsuccessfully. If an error occurs, the analyst researches the error using the methods described in the ErrorHandling per Monitoring Object section.


Starting this process takes a single key stroke and an operator should receive feedback in less than onesecond.




For PC Express, the feedback occurs in less than one second.


This process should take no more than a couple of hours for the largest clients and should be determined perclient. It is possible to verify the count of the number of records in the import tables by querying the databasetables directly or by reviewing the SQL Loader log files. This information is not visible through the UI.However, if the Load Weekly process completes successfully, this step is not necessary.


The operator checks the status of this process approximately one hour after manually starting the LoadWeekly process.

Backlog monitoring

Not applicable


MonitoringObject

SelectionCriteria



Load Weekly Screen =Processing

Activity = Regular

Group = Importand Cleanse

Process = LoadWeekly

Processterminates with an‘Error’ status.

Each time weeklydata is loaded

Table 7: Load weekly data – Monitoring objects


The Load Weekly process must complete without error before subsequent steps can be started in the weeklyprocess. This process typically completes within 30 minutes depending on the size of the files. Thresholdsshould be determined per client based on hardware size and file size.


Some possible problems in this process are: Data files in the incorrect format Data files did not transfer properly Data file were not decrypted properly

It may be necessary for the operator to connect to the UNIX server via PuTTY or another UNIX interface toolto review the SQL Loader log files to obtain more information on the files in error and the type of error



encountered. If a file format is incorrect or a file was not received from the client, it may be necessary tocontact the appropriate client personnel to retransmit a corrected file or provide a workaround.

As explained above, the solution manager allows carrying out a file monitoring.

2.2.5 Business process step 5: Data validation

2.2.5.1 Description

Data validation is run against the data once it is stored in the import tables to ensure its suitability for use inoptimization. This process will validate that all columns in all import files meet the import standards definedwithin SAP-DM.


The analyst starts the Clean Weekly process for PC Express once the Load Weekly process has completedsuccessfully.


Error monitoring

Error notification is provided in the processing screen within the SAP-DM application. Verifying the processhas completed successfully requires a refresh of the processing screen. The status will indicate whether theprocess is running, has completed, or has failed. If a fatal error is encountered, further investigation may berequired. Even though the process may complete without error, the operator must review the completionstatistics for any data exceptions.


From the processing screen, the analyst will validate that the Clean Weekly process has completedsuccessfully. If an error occurs, the analyst researches the error using the methods described in the ErrorHandling per Monitoring Object section


Starting this process takes a single key stroke and an operator should receive feedback in less than onesecond.


For PC Express, the feedback occurs in less than one second.


This process may take up to 12 hours depending on the client data set and available resources. The analystcan verify the results of this process once it has a ‘Completed’ status in the Import Review Screen of theSAP-DM UI. This screen reports on the number of records rejected for each file based on specific validationcriteria. If the Clean Weekly process terminates with an ‘Error’ status, further investigation is required by theanalyst.




This process should take eight hours in the PC Express environment. The analyst verifies that the CleanWeekly process has completed successfully on Monday morning and provides feedback to PC Express onany rejected records.

Backlog monitoring

Not applicable


MonitoringObject

SelectionCriteria



Clean Weekly Screen =Processing

Activity = Regular

Group = Importand Cleanse

Process = CleanWeekly

Processterminates with‘Error’ status


DataManagement ->Import Review

Existence CheckFailed

Processcompletessuccessfully.Validate rejectedrecords.



Invalid actiontype.

Processcompletessuccessfully.Validate exceptioncount withinthreshold



Specified key isnull.

Processcompletessuccessfully.Validate rejectedrecords



Failed Update.Update record intarget table doesnot exist.





MonitoringObject

SelectionCriteria




Duplicate Key. Processcompletessuccessfully.Validate rejectedrecords



Duplicate Row. Processcompletessuccessfully.Validate exceptioncount withinthreshold



Data validationerror.



Table 8: Data validation – Monitoring objects


The Import Review screen gives detailed information about each file, and what records were ignored as partof the SAP-DM cleansing processes. Although it is recommended that all files are error-free, it is understoodthat some files may have some rejected records. No file should have more than 5% of all records inexception. If all files have less than 5% exceptions then processing can continue, however, all exceptionsshould be reported back to host system administrators.


For the Clean Weekly process, the user will need to locate the ‘Clean Weekly’ process within the processingscreen of SAP-DM. This process is required to finish with a status of ‘Complete’ before subsequentprocesses can be started. If the process terminates with a status of ‘Error’, select the error message on theProcessing screen (double clicking) to provide more information to help an operator troubleshoot the problem.The ‘Clean Weekly’ process should always complete successfully. Any erroneous data from this process willbe inserted into the error tables. A summary for review is provided in the Data Management Import Reviewscreen.

2.2.6 Business process step 6: Product linking and data preparation

2.2.6.1 Description

The preparation for modeling includes product linking, association of the linking information to the markethierarchy and posting that information to the system.



The second process that needs to be run prior to optimization is CSO Prep. This process moves the mostrecent price, cost, competitor data, and price constraint information into the tables used by optimization.


PC Express has decided to allow the SAP-DM team to infer product linking using the processes in the UI.Once the inferring has been done, business users from PC Express can manually review the linking andmake any changes through the UI.

Because PC Express uses competitive data as well as specific price rules all processes under CSO Prepmust be run.


Error monitoring

Error Checking and correction for Product Linking is performed through the UI in the rules tab of the productlinking screen.

Validation of completion of CSO Prep processes is performed through the UI in the processing screen. Thestatus will indicate whether the process is running, has completed, or has failed.


Once the product linking has been inferred and reviewed, the analyst will check for specific errors, correctingthem as they are found. This is an iterative process until all errors are resolved.

From the processing screen, the analyst will validate that the CSO Prep processes have completedsuccessfully.


Product linking and error checking is an interactive process within the SAP-DM UI. No performancemonitoring should be needed.

CSO Prep processing is run and validated through the Processing screen in the UI.


From the processing screen, the analyst will validate that the CSO Prep processes have completedsuccessfully.


Product linking throughput should be determined per client based on the modeling schedule of that client.


In the PC Express environment all CSO Prep processes will be started manually and should complete withinone hour.

Backlog monitoring

Not applicable




MonitoringObject



DataManagement – >Product Linking ->Demand Grouptab

Select level atwhich DemandGroup will be setfrom drop downmenu and press‘Infer’

Done on aschedule agreedupon by thecustomer.Products onlybecome availablefor optimizationonce this processoccurs.

DataManagement – >Product Linking ->Product Line tab

Select the numberof characters to useto identify productlines and press‘Infer’


DataManagement – >Product Linking ->Price Family tab

Select the criteria tobe used todetermine pricefamily (price, cost oreffective size) andpress ‘Infer’


DataManagement – >Product Linking ->Rules tab

Press ‘Reset ErrorCodes’ and press‘Apply’

Check for specificError Codes andmake corrections.




MonitoringObject



Associate Linkingto MarketHierarchy

Screen = SystemConfiguration –Market HierarchyAssociations

Auto Associate All –DemandGroups/MicroMarkets Tab

Auto Associate All –Zones/MicroMarketsTab

Done on aschedule tosupport ProductLinking.

ValidateAssociations

Screen = SystemConfiguration –Market HierarchyAssociations

ValidateAssociations button

Hierarchy ValidationLog Tab

Severe Errors inthe HierarchyValidation Log

Publish Linking Screen =Processing

Activity = Regular

Group = Import andCleanse

Process = PublishMarket Hierarchyand LinkingInformation



CSO Prep Screen =Processing

Activity = Regular

Group = CSO Prep

Process = ProcessCurrent




Activity = Regular

Group = CSO Prep

Process = ProcessCompetitor





MonitoringObject




Activity = Regular

Group = CSO Prep

Process = ProcessConstraint




Activity = Regular

Group = CSO Prep

Process = ProcessAssociated



Table 9: Product linking and data preparation – Monitoring objects


Product Linking is conducted based on a predefined schedule. The user performs the product linking andmay review the results with the client. This may take several days depending on the number ofproducts/categories being addressed.

Once the Product Linking is error free and approved by the client, an operator will use the SAP-DM UI(system configuration) to ‘Auto Associate’ the linking information to the market hierarchy and validate theassociations by reviewing the validation log. The association processes run interactively when invoked.

Then the Publish Market Hierarchy and Linking Information process is run from the processing screen. This process

normally runs within 30 minutes.

Each of the CSO Prep processes runs fairly quickly (several minutes) with the exception of Process Currentwhich may take up to an hour. Large history tables are maintained during this process to record pricechanges and cost changes over time.


All product linking errors must be corrected in order to proceed with modeling using the latest productinformation. The following errors can occur: 701 - Same Price Family - Different Effective Size 703 - Product Lines Crossing Demand Groups 704 - Price Families crossing Product Lines 706 - Same PL and Size, different PF 707 - No DG, PL, or PF 711 - Demand Group Crossing Hierarchy Levels



Each of these errors can be reviewed and corrected in the Data Management Product Linking screens. Theaction to be taken depends on the error returned. The error description given indicates the correction needed.

The ‘Auto Associate’ process should be performed each time new linking data is introduced. This includes astep to validate the associations and review the validation log. These steps are performed from the SAP-DMUI and are interactive. Records with a severity of Error in the validation log must be corrected before movingon to the next step. The error description will indicate the cause. Most errors are caused by faulty linking andwill have to be corrected through the product linking screen.

The Publish Market Hierarchy and Linking Information process is required to finish with a status of ‘Complete’ inorder for the latest product linking information to be available to modeling as well as optimization/price filegeneration. If this process terminates with a status of ‘Error’, further investigation is required. Selecting theerror message on the Processing screen (double clicking) will provide more information to help an operatortroubleshoot the problem. The only time this type of error will occur is if the errors encountered during theprevious step are not corrected.

The CSO Prep processes are required to finish with a status of ‘Complete’ before optimization/price filegeneration, using the newest data, can begin. If any of these processes terminates with a status of ‘Error’,further investigation is required. Selecting the error message on the Processing screen (double clicking) willprovide more information to help the operator troubleshoot the problem. This process should not fail as alldata has completed through the ‘Clean Weekly’ process.



2.3 Business Process: Weekly Modeling

To continue to produce satisfactory results the demand models used by Price Optimization must continue tobe refined as new sales are collected. This process is accomplished by executing modeling jobs. Becausethe time required to model the entire enterprise can be very large, a modeling schedule is established duringthe implementation which determines what portion of the enterprise is remodeled each week. This section willdescribe the steps necessary to carry out this remodeling. The creation of the modeling schedule is notcovered by this document.

SAP PI



Model

Review & Post Models

P02

Figure 13: SAP Price Optimization – Weekly modeling

2.3.1 Business process step 1: Model

2.3.1.1 Description

Creating the demand models necessary for optimization is accomplished by several different processes.Each process is completed at a level where the product hierarchy intersects with a zone (also known as amicro market). There are three major steps in this process and they are: The first process determines the promotional calendar by looking at the sales data. This process is vital to

make sure that un-realistic lifts are not placed on products. The second process aggregates sales information by zone. The aggregation process can help the model

when there are holes in store level data. The final process is modeling, which uses the aggregated sales information to calculate modeling

information including elasticity and r2 values. These values will later be used in optimization.




The PC Express production system is small enough that modeling will not need a schedule as the entireenterprise can be modeled within a few hours.


Error monitoring

Each process needs to complete successfully before the next step can begin. Each step requires a user tomonitor for completion and to submit dependent processes. Verifying that the Model processes havecompleted successfully requires a refresh of the processing screen. The status will indicate whether theprocess is running, has completed, or has failed. If an error is encountered, further investigation will berequired.


The operator will perform the modeling processing for PC Express. Each step will be run and monitoredmanually.


Performance metrics are determined on a per client basis. Performance is based on several things includingproduct count, zone count, database sizing, number of process servers, etc. Starting each step requires onlyone key stroke and the feedback to the operator will be instantaneous.


Based on all the aspects mentioned above, the PC Express environment will take approximately two hours tomodel the entire enterprise.


The time required for each step involved in the Model processing is dependent on a number of factorsincluding the complexity of the client’s environment as well as the number of middle tier processes that canrun simultaneously.


The PC Express environment has 25 micro markets and two middle tiers which allow the processes to runquickly.

Backlog monitoring

Once the modeling jobs are submitted, they will remain in a ‘requested’ status until there is a middle tieravailable to pick up each submitted job. The jobs submitted are queued up for processing and automaticallyexecuted as resources become available.


The analyst monitors the queue makes sure all processes have completed successfully before starting thenext process in modeling.




MonitoringObject

SelectionCriteria



Demand Modeling Screen =Processing

Activity = Regular

Group = DemandModeling andForecasting

Processes = RegPCB Prep


Performed everytime customerwants newdemand models


Activity = Regular


Processes = BuildPromo Calendar(PCB)




Activity = Regular


Processes =Analyze tablesbefore SAM




Activity = Regular


Processes = SAM






Activity = Regular


Processes =MOD2 Modeler




Activity = Regular


Processes = PostModeling Parmsto CSO



Table 10: Model – Monitoring objects


Modeling jobs are run on a predefined schedule for each client. Identified portions of the market hierarchymay be modeled each week in preparation for the following week’s optimization. The time involved for anindividual micro market per individual process is, typically, several minutes. These jobs are multi-threadedbased on the system resources allocated to the client environment. The more process servers allocated tothe environment, the more simultaneous processes being run. Dependent processes are manually submittedso the flow is controlled by the operator submitting and monitoring the processes.


Each Model processing job is required to finish with a status of ‘Complete’ in order to submit the nextdependent process for that micro market. If a process terminates with a status of ‘Error’, further investigationis required. Selecting the error message on the Processing screen (double clicking) will provide moreinformation to help an operator troubleshoot the problem. For PCB, SAM, and MOD2 there are log files thatcan be viewed using a UNIX windows session such as PuTTY. These log files may provide a moremeaningful error message. When viewing log files, operators should begin reading from the end of the log fileas the error will occur as one of the last entries in the log. Errors related to underlying product linking issuesmay need to be corrected so that the job can be resubmitted and dependent processes can move forward. Insome cases it may be necessary to contact client personnel to discuss the issue and determine anappropriate workaround.

Alternatively, as explained above, the solution manager allows carrying out a file monitoring.



2.3.2 Business process step 2: Review and post models

2.3.2.1 Description

At least one time each quarter, models should be reviewed by a scientific consultant to make certain thatmodel parameters are set correctly. After this optional step is completed, the models are posted to theproduction tables where they are used by the optimization process. Once modeling parameters are posted,optimization will use the most up to date sales information when calculating optimal prices.


PC Express has contracted with SAP to provide the model evaluation services. Once per quarter the modelsare reviewed and adjustments are made based on the scientific consultant’s recommendation.

The analyst posts the modeling parameters to the production system after completing the modeling process.


Error monitoring

The ‘Post Modeling Parms to CSO’ process is run for each micro market that is newly modeled. This processneeds to complete successfully before the modeling results are available to optimization. Verifying that the‘Post Modeling Parms to CSO’ processes have completed successfully requires a refresh of the processingscreen. The status will indicate whether the process is running, has completed, or has failed. If a fatal error isencountered, further investigation may be required.


The analyst monitors the ‘Post Modeling Parms to CSO’ process.


Negligible time and machine resources are required for the ‘Post Parms to CSO’ step of processing. Thisprocess does require an operator to manually submit each request via the Processing screen within the SAP-DM UI. Feedback to the operator should take no more than 2 seconds.


The operator submits each job and monitors to completion.


Generally this process takes only seconds for each micro market level job to complete. The overallthroughput and associated timeframes will depend on the number of micro markets and the number of middletier processes that can run simultaneously.


Based on PC Express’ environment, the posting of modeling parameters should take two minutes tocomplete.



Backlog monitoring

Submitted processes remain in a requested status until there are system resources available to process eachjob request. The number of requested jobs posted will depend on the number of micro markets in theenvironment. Jobs should move from requested status into running status every few seconds. If no jobs havechanged status in five minutes, it is possible that an error has occurred that is not allowing jobs to process.


The analyst monitors the queue and makes sure all processes have completed successfully.


MonitoringObject

SelectionCriteria



Post Modeling toCSO

Screen =Processing

Activity = Regular


Processes = PostModeling Parmsto CSO



Table 11: Review and post models – Monitoring objects


Throughput will have to be determined on a per client basis. The ‘Post Modeling Parms to CSO’ process isrun for each micro market that has been successfully modeled. The time involved for an individual micromarket is negligible. These jobs are multi-threaded based on the system resources allocated to the clientenvironment. The more process servers allocated to the environment, the more simultaneous processesbeing run. The submission of these jobs is controlled manually by an operator submitting and monitoring theprocesses.


The ‘Post Modeling Parms to CSO’ process must complete successfully in order for the latest modeling datato be used in optimization. If any of these processes terminates with a status of ‘Error’, further investigation isrequired. Selecting the error message on the Processing screen (double clicking) will provide moreinformation to help the operator troubleshoot the problem. Typically the only reason that this step will result inan error is when the prerequisite steps did not complete successfully.



2.4 Business Process: Price Optimization

Once the weekly data has been loaded and the models updated and posted to CSO, the system is availablefor optimization. Optimization is executed via the Price File Creation Wizard. A price file is a group of productsand zones that are chosen by the customer to be optimized together. Within a price file, the optimizationengine uses the relationships between the products and zones to generate the most value for the client.

The optimization process is the means of generating price recommendations for part of the organization andvaries widely by retailer. The business process used is not the subject of this document but the means ofprocessing the data necessary to produce the price file is.

SAP PI



Optimization Process Generate & ReviewForecasts

P03

Figure 14: SAP Price Optimization – Optimize

2.4.1 Business process step 1: Optimization process

2.4.1.1 Description

The creation of a price file is done by an end-user. The user chooses locations and products for whichoptimized prices are desired through the user interface. The pricing strategy to be employed is set and theoptimization process is launched. The jobs which are executed may be monitored but if there are no unusualhappenings the price file creation is automatic. The price recommendations may be reviewed and changed bythe user until the set of prices are acceptable to the business. This review process can take several hours ordays depending on the business procedures employed by the client.



At a set time period after the price file is created or on a specific day of the week, determined duringimplementation, the ‘approved’ price file is ‘closed’ and can be delivered to the client’s price executionsystem. This step is covered in the next section.

During price optimization, forecasts for price changes are made and updated as the user makes changes.Again, the execution of these jobs is automated and can be monitored.


A merchant at PC Express is creating a price file for the Hard Drive category and will be reviewing andapproving the file over the course of a week. The file is created on Monday, reviewed Tuesday andWednesday, and ‘approved’ for delivery on Thursday.


Error monitoring

Each process needs to complete successfully before the next step can begin. Monitoring of these processesis not required; however, monitoring of the optimization steps can occur through the Processing screen in theUI. Within the Price Activity Calendar the price file will display as ‘Unavailable’ status while it is beinggenerated. Once complete the price file status will be ‘Open’. Updates to the price file status require a refreshof the Price Activity Calendar screen.


The PC Express merchant generates the price file and waits for the optimization process to complete onMonday. The price file is then viewable through the Price Activity Calendar. The merchant takes Tuesday andWednesday to review the prices and make any changes necessary.


Performance of a price file needs to be determined on a per client basis. The performance will depend on thesize of the price file, the capacity of the hardware as well as any other processes that may be running in theenvironment that could be taking up optimization resources (other price files, modeling, etc). Submitting aprice file requires an operator to use the Price Activity Wizard in the UI. Once products, stores and strategiesare selected the ‘Finish’ button is clicked. The feedback to the operator that the job was submitted will takeone second.


PC Express has decided that price files will be run at a category level and as such, should take approximately10 minutes to complete.


When a price file remains in an ‘unavailable’ status for an unusually long period of time, an An operator mayneed to review the background processes that are executed as part of price file generation via the Processingscreen to determine if any process has terminated with an ‘Error’ status. The amount of time a price file takesto run will be dependent by client.




Users of the PC Express application will generate the price file. If the price file has not completed in 20minutes, the user will alert SAP. The indication for a completed price file is the status changing from ‘NotAvailable’ to ‘Open’. The operator will monitor the process steps and verify none have failed. If an erroroccurs, the analyst researches the error using the methods described in the Error Handling per MonitoringObject section.

Backlog monitoring

Not applicable


MonitoringObject

SelectionCriteria



Optimization Screen =Processing

Activity = Regular

Group = CSOProcessing Group

Processes = CSOEntry Point


Occurs every timea price file iscreated


Activity = Regular


Processes = CSOApply BusinessRules and RunMM MSF




Activity = Regular


Processes = CSORun Market MSF





MonitoringObject

SelectionCriteria




Activity = Regular


Processes = CSOPrice ChangeLogic




Activity = Regular


Processes = CSORun MarketTarget




Activity = Regular


Processes = RunMM Target




Activity = Regular


Processes = CSOSet Price ChangeCost




Activity = Regular


Processes = RunMM MSF





MonitoringObject

SelectionCriteria




Activity = Regular


Processes = CSORun MarketMSF/MarketTarget forEnterprise




Activity = Regular


Processes = CSORun MarketTarget




Activity = Regular


Processes = CSOASP




Activity = Regular


Processes = CSORun MM Targetand Updateopt_wb_table





MonitoringObject

SelectionCriteria




Activity = Regular


Processes = CSOUpdate PF Statusand send alerts



Table 12: Optimization process – Monitoring object


This will be done on a per client basis. Thresholds will be dependent on price file size, hardware sizing andany other processes running that may take resources from the process servers.


When an operator is asked to investigate a price file that has been ‘unavailable’ for an unusually long periodof time, they will review the CSO Processing Group processes in the Processing Screen of the UI. If aprocess has terminated with an ‘Error’ status, double clicking on the error message will provide moreinformation that may help diagnose the problem. The most common issue that causes a price file failure isrelated to a conflict in business rules or the absence of a rule set for the portion of the hierarchy that is beingoptimized. If the process ‘CSO Apply Business Rules and Run MM MSF ‘ has an error the price file should bedeleted, the business rules should be corrected, and the price file should be recreated. An operator will workwith the client personnel when this happens to make certain that the client understands the source of theproblem. If any other process returns an error, SAP Research will have to be involved to determine thecause.

2.4.2 Business process step 2: Generate and review forecasts

Within the application, a seasonal forecast can be generated for the client to use. In order for forecastinginformation to be displayed a separate process needs to run. This process is typically run during the modelingprocess. A user is able to edit how the forecast is displayed in the UI.


A merchant at PC Express would like to see the seasonal weekly forecast for the next quarter. The merchantmust request the process to be run. Once the process is run, forecasts will be available in UI.




Error monitoring

There is only one process (Forecast) that needs to be run in order for forecasts to be generated. This processmust successfully complete in order for forecast information to be displayed. The monitoring of this process isdone in the processing screen in the UI.


The analyst monitors the forecasting process in the UI.


The forecast process is submitted with one key stroke in the UI. The feedback to the operator that theprocess was submitted successfully will occur in one second.


An operator will submit the forecast process for the desired micro market and receive confirmation of thesubmitted process within one second.


The time required for the forecasting process will be determined per client.


In the PC Express environment, forecasting a category will take 20 minutes.

Backlog monitoring

Not applicable


MonitoringObject

SelectionCriteria



Forecast Screen =Processing

Activity = Regular

Group = DemandModeling andForecast

Processes =Forecast


Process is runmanually

Table 13: Generate and review forecasts – Monitoring objects




This will be done on a per client basis. Thresholds will be dependent on number of products being forecast,hardware sizing and any other processes running that may take resources from the process servers.


The ‘Forecast’ process must complete successfully in order for the forecasted data to be displayed in the UI.If this process terminates with a status of ‘Error’, further investigation is required. Selecting the error messageon the Processing screen (double clicking) will provide more information to help an operator troubleshoot theproblem. Typically the SAP Research team will be required to determine the cause for the error.

2.5 Business Process: Price File Delivery

Once a price file has been reviewed and is acceptable to the client it must be delivered, or exported from theSAP Price Optimization system to a price execution system. This is accomplished as a file transfer.

SAP PI



Receive Price Changes

Deliver Price Files

File Transfer

P04

Figure 15: SAP Price Optimization – Price file delivery

2.5.1 Business process step 1: Deliver price files

2.5.1.1 Description

At a point in time, established during the implementation, any ‘open’ price files with an ‘approve by’ date in acertain range are processed for delivery to a price execution system.




PC Express would like prices to be delivered on Friday afternoons for implementation into the stores onSunday.


Error monitoring

There is only one process (Output text file with prices) that needs to be run in order for the text file to begenerated so it can be placed on a server where the client can retrieve it. This process must successfullycomplete in order for the text file to be created. The monitoring of this process is done in the processingscreen in the UI.


An operator manually runs the process and monitors it until completion.


Due to the criticality of price file delivery; this process should be monitored by the operator running the client’senvironment.


The operator manually runs the process and monitors it until completion.


The creation of the text file should only take a few minutes. In order to get an updated status a refresh of theprocessing screen will be needed. If the process has terminated with an ‘Error’ status, double clicking on theerror message will provide more information that may help diagnose the problem.


Based on the PC Express environment, the creation of the text file takes two minutes.

Backlog monitoring

Not applicable




MonitoringObject

SelectionCriteria



Price File Delivery Screen =Processing

Activity = Regular

Group = BuildClient Price File

Processes =Output Text Filewith Prices


Predeterminedschedule agreedto by the client.

Table 14: Deliver price file – Monitoring objects


This will be done on a per client basis. Thresholds will be dependent on number of price recommendations,hardware sizing and any other processes running that may take resources from the process servers.


The user can monitor the ‘Build Client Price File’ process within the processing screen of SAP-DM. Thisprocess is required to finish with a status of ‘Complete’ before the text price file is transferred to the client forprocessing in their price execution system. If the process terminates with a status of ‘Error’, furtherinvestigation is required. Selecting the error message on the Processing screen (double clicking) will providemore information to help the operator troubleshoot the problem.

2.5.2 Business process step 2: File transfer

2.5.2.1 Description

Once the price file has been created it will be picked up automatically by SAP PI and processedautomatically.


The processing schedules are defined for PC Express during the business blueprint phase. The inboundprocessing will work completely automatically – the operator has just to monitor all involved system (ERP, PI)to ensure the correct data flow.


Error monitoring

For ERP inbound processing the corresponding logs have to get checked periodically depending of thescenario that is used if prices, promotions or allocation tables have been created successfully. Thecorresponding logs can be accessed by the easy access menu of the ERP Retail system:



Retailing -> Distributed Retailing -> Demand Management Integration -> Inbound -> Logs

PI Monitor: Transaction SXMB_MONI within ERP and Runtime workbench within PI system

To check the processing of XML messages between ERP and PI TA SXMB_MONI should be used.

To check end-to-end communication e.g. including the communication with the file adapter use the Runtimeworkbench of SAP Exchange Infrastructure. More information is provided under the link:

Help portal at help.sap.com and follow the path SAP NetWeaver SAP NetWeaver 7.0-> SAP NetWeaverby Key Capability -> Process Integration by Key Capability SAP NetWeaver Exchange Infrastructure ->Runtime -> Central Monitoring

Also PI Message Processing can be monitored with SolMan. Prerequisite: PI local customizing with MessageBased Alerting. See IFMon Setup Guide under http://service.sap.com/bpm -> Technical Information -> SetupGuide Interface Monitoring


To ensure that this automatic process run as expected the application log in the ERP part should be checkedweekly and also the xml messages should be checked by spot checks.


The inbound processing should be done and completed error free in the time frame which has to be definedduring the blueprinting phase of a project. Therefore the performance should be checked to ensure correctfollow on processes.


The operator of PC Express monitors weekly the process runtimes and checks the created numbers of xmlmessages.


Does not apply for SAP Price Optimization.

Backlog monitoring

Does not apply for SAP Price Optimization.


MonitoringObject

Selection Criteria Alert Analysis Toolon SatelliteSystem

MonitoringFrequency /DataCollection

ApplicationLog

Object RDM_OPT_IMPORT andsubobject PRICING as displayedas default

Warning or Error RDM_SLG1_PRICE

Weekly




Messagestatus

Message types

SalesPriceSpecificationCalculationCreateRequest_In,RetailAllocationCreateRequest_In,RetailEventCreateRequest_In

Empty payloads,Mapping issues

SXMB_MONI inERP or viaSolMan

Weekly

Messagestatus

Message types

SalesPriceSpecificationCalculationCreateRequest_In,RetailAllocationCreateRequest_In,RetailEventCreateRequest_In

Empty payloads,Mapping issues

SXMB_MONI inPI or via SolMan

Weekly

Table 15: File transfer – Monitoring objects


Thresholds should be defined individually for each installation, depending on the data scope based on thespecifics of the implementation.


Job log issues – check for job cancellations, continuing finding causes more detailed in the application log.

Application log issues – jump into RDM_SLG1_PRICE and start here the error determination with findings inthe log.

Message status first in the part of PI and later in ERP to identify mapping errors (ERP) or data issues indelivered text files (SXMB_MONI in PI).



3 Further Information

3.1 Related Best Practice Documents

There are several other Best Practice documents available on the Service Marketplace underhttps://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 tocreate a general Business Process Management concept. This includes the definition and documentationof the core business processes, definition of monitoring objects, definition of monitoring activities includingerror handling procedures, monitoring tools, monitoring frequencies, the definition of communication andescalation procedures and the assignment of responsibilities.ALE Monitoring: This Best Practice helps you set up an Interface Monitoring concept with the focus onALE Monitoring for your SAP solution. This document will outline possibilities on how to optimally monitorALE-based interfaces manually as well as automated by using SAP Solution Manager. Both monitoringapproaches 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 recommendsas a standardized formal process to support a job request process, including an end user job request formand an approval process. This integrated process will avoid error-prone and time intensive manualprocesses of copying redundant data from one data source to another (for example, MS excel to MS Excelor MS Excel to job scheduling tool).SAP Business Process Management for ERP Logistics: This Best Practice helps you set up a BusinessProcess Monitoring concept for your SAP ERP solution. The concept aims to define procedures forbusiness process oriented monitoring and error handling and escalation procedures for your company’sERP core business processes. These procedures intend to ensure a smooth and reliable flow of the corebusiness processes so that your business requirements are met.Background Job monitoring with SAP Solution Manager: This Best Practice will help you to set upbackground job monitoring properly in the framework of Business Process Monitoring in the SAP SolutionManager.

Please note that these documents are also available in the SAP Service Marketplace using alias “RunSAP” RunSAP Best Practices.

3.2 Solution Manager Setup Guides

Several Setup Guides are available under the link http://service.sap.com/bpm.

https://service.sap.com/solutionmanagerbp




Index of FiguresFigure 1: Alert types – Number of ABAP Dumps (Delta) 9Figure 2: Monitoring objects – Dialog performance 10Figure 3: Monitoring alerts - Dialog performance 10Figure 4: Monitoring objects – Update errors 11Figure 5: Monitoring alerts - DocumentCreation 12Figure 6: Monitoring objects and alerts – Application log 13Figure 7: Monitoring alerts – Application log/critical messages 14Figure 8: Other CCMS monitors 15Figure 9: Analysis & monitoring transactions 16Figure 10: Analysis & monitoring URL 16Figure 11: SAP Price Optimization – Overall process flow 21Figure 12: SAP Price Optimization – Weekly processing 22Figure 13: SAP Price Optimization – Weekly modeling 39Figure 14: SAP Price Optimization – Optimize 45Figure 15: SAP Price Optimization – Price file delivery 52

Index of TablesTable 1: Monitoring activities – Responsibilities and problem resolution procedures 17Table 2: Workflow notification 18Table 3: Support notification 19Table 4: Export master data – Monitoring objects 25Table 5: Export weekly sales – Monitoring objects 27Table 6: File transfer – Monitoring objects 29Table 7: Load weekly data – Monitoring objects 30Table 8: Data validation – Monitoring objects 33Table 9: Product linking and data preparation – Monitoring objects 37Table 10: Model – Monitoring objects 42Table 11: Review and post models – Monitoring objects 44Table 12: Optimization process – Monitoring object 50Table 13: Generate and review forecasts – Monitoring objects 51Table 14: Deliver price file – Monitoring objects 54Table 15: File transfer – Monitoring objects 56



© Copyright 2009 SAP AG. All Rights ReservedNo 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, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries,zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBMCorporation.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 MultiWin are trademarks or registered trademarks of CitrixSystems, Inc.HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, MassachusettsInstitute of Technology.Java is a registered trademark of Sun Microsystems, Inc.JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented byNetscape.MaxDB is a trademark of MySQL AB, Sweden.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as theirrespective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. Allother product and service names mentioned are the trademarks of their respective companies. Data contained in this document servesinformational purposes only. National product specifications may vary.

The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any formor for any purpose without the express prior written permission of SAP AG.This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This documentcontains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP toany particular course of business, product strategy, and/or development. Please note that this document is subject to change and maybe changed by SAP at any time without notice.SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of theinformation, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind,either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages thatmay result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you mayaccess through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide anywarranty whatsoever relating to third-party Web pages.