manage operations for sap merchandise and assortment planning ( map)

Best Practice for Solution Operations

Manage Operations for SAP Merchandiseand Assortment Planning (MAP)

Dietmar-Hopp-Allee 16D-69190 Walldorf

CS STATUS

customer publishedDATE VERSION

April 2009 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 Practice for Solution OperationsManage Operations for SAP Merchandise and Assortment Planning (MAP)

© 2009 SAP AG - BP_Retail_MO_for_MAP_V30.doc page 2/46

Table of Contents1 Management Summary 4

1.1 Goal of Using this Best Practice 41.2 Alternative Practices 41.3 Staff and Skills Requirements 41.4 System Requirements 51.5 Duration and Timing 51.6 How to Use this Best Practice 51.7 Best Practice Procedure 6

1.7.1 Preliminary tasks 61.7.2 Monitoring concepts 61.7.3 Business Process Monitoring in SAP Solution Manager 61.7.4 Monitoring types for Business Process Monitoring in SAP Solution Manager 7

1.7.4.1 Application monitor 81.7.4.2 Background job 81.7.4.3 Monitoring objects 91.7.4.4 ABAP dump collector 91.7.4.5 Dialog performance 101.7.4.6 Update errors 111.7.4.7 Due list log 121.7.4.8 Application log 131.7.4.9 Other CCMS monitors 151.7.4.10 Analysis and monitoring tools 151.7.4.11 Monitoring activities 171.7.4.12 Notifications 17

1.7.5 Business Process Monitoring Process 191.7.6 Legend 19

2 Business Process Monitoring for a Merchandise and Assortment Planning 212.1 Business Processes 21

2.1.1 Business Process Strategic Planning 232.1.1.1 Monitoring requirements 242.1.1.2 Monitoring objects 24

2.1.2 Business Process Merchandise Planning 252.1.2.1 Monitoring Requirements 252.1.2.2 Monitoring objects 26

2.1.3 Business Process Store Planning 262.1.3.1 Monitoring requirements 272.1.3.2 Monitoring objects 27

2.1.4 Business Process Reconciliation Plan 272.1.4.1 Monitoring requirements 282.1.4.2 Monitoring objects 28

2.1.5 Business Process Assortment Planning Basics 292.1.5.1 Monitoring Requirements 302.1.5.2 Monitoring objects 30

2.1.6 Business Process Assortment Management Basics 312.1.6.1 Monitoring requirements 32



2.1.6.2 Monitoring objects (optional: in SAP Solution Manager) 322.1.6.3 How to find meaningful thresholds per monitoring object 33

2.1.7 Business Process Assortment Planning Fashion 332.1.7.1 Monitoring requirements 342.1.7.2 Monitoring objects 34

2.1.8 Business Process Assortment Management Fashion 352.1.8.1 Monitoring requirements 362.1.8.2 Monitoring objects 36

2.2 Monitoring Possibilities for Merchandise and Assortment Planning 372.2.1 Monitoring for retail planning within SAP BI 372.2.2 Monitoring for Release Workbench within SAP BI 382.2.3 Monitoring for Assortment Management Basics within SAP ECC 402.2.4 Monitoring for Assortment Management Fashion within SAP ECC 42

3 Further Information 443.1 Related Best Practice Documents 44

Index of Figures 45Index of Tables 45



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 Retail solution. Theconcept aims to define procedures for business process oriented monitoring and error handling andescalation procedures for your business process Merchandise and Assortment Planning (MAP). Theseprocedures intend to ensure a smooth and reliable flow of this core business process so that your businessrequirements 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 on-site by ordering an SAP Solution ManagementOptimization (SMO) service for SAP Business Process Management (BPM). This service is exclusivelyavailable within SAP’s support engagements SAP MaxAttention and SAP Safeguarding. If your companycurrently does not have any support engagement with SAP, it is also possible to get assistance by SAPexperts from SAP Consulting. If this case, please contact your local SAP Consulting representative.

1.3 Staff and Skills Requirements

To implement this Best Practice, you require the following teams:

Application Management team

This team creates the ERP Business Process Monitoring concept and consists of experts from several areasof your company: Business department Solution support organization (for example the Basis Support or the Application Support) Implementation project team

Business process operations team

The business process operations team will be responsible for applying the resulting procedures derived 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 who 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, quicklink /BPM.

Necessary or useful trainings

SM300 Business Process Management and MonitoringE2E300 End-to-end Business Process Integration and Automation Management

1.4 System Requirements

In order to monitor business processes running in your Sap Map solution via SAP Solution Manager, the SAPBasis Release of the systems to be monitored have to be at least 4.6C. To have all described monitoringobjects available in SAP Solution Manager, the add-on ST-A/PI01L has to be installed on the SAP for Retailand the SAP BI system.

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 Service

Marketplace. This document explains the procedures you should use to create a general BusinessProcess Management concept. This includes the definition and documentation of the core businessprocesses, definition of monitoring objects, definition of monitoring activities including error handlingprocedures, monitoring tools and monitoring frequencies, the definition of communication and escalationprocedures and the assignment of responsibilities.

At the beginning of chapter 2 you will find a typical flow chart of the core business process explained inthis Best 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 caseinformation from the generic part is relevant for a specific business process step in one of the scenariosyou will find a clear 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 monitoringrecommendations 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 that are implemented in a SAP MAP system or other software and operated bya company are of particular importance, and Business Process Monitoring is intended to ensure a smooth



and reliable operation of the business processes and, thereby, that the core business processes meet acompany’s business requirements in terms of stability, performance, and completeness. The SAP SolutionManager provides a graphic to visualize a company’s (distributed) system and solution landscape and allrelated business processes. By using Business Process Monitoring, it is possible to define and customizealert situations from a basic set of configurable alerts provided by the SAP Solution Manager. These alertsare then visualized by green, yellow, and red alert icons for each individual business process step in thegraphical business process representation. Business Process Monitoring is intended to detect and respond tocritical 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 Required periodic monitoring tasks

For further details on Business Process Monitoring please refer to http://service.sap.com/bpm.

1.7.4 Monitoring types for Business Process Monitoring in SAP Solution 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)

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.

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

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

http://help.sap.com)/



1.7.4.1 Application monitor

The application monitor is just one of many different monitoring types within the Business Process Monitoring.The latest monitoring objects are only provided if the latest ST-A/PI plug-in is installed on the satellite system.The service tool for ST-A/PI is available via the SAP Service Marketplace Quick Link /installations Entry byApplication Group Plug-Ins SAP Solution Tools ST-A/PI.

Please ensure that the ST-A/PI is installed on the SAP Solution Manager system and on the respectivesatellite. In case of problems refer to SAP Note 915933.

The throughput and backlog indicator functionality available as of ST-A/PI 01J* is only working properlywith ST-SER 700_2007_1. This is due to changes in the underlying architecture.

More detailed information about the different application monitor functionalities and a detailed description onhow to define self-written monitoring collectors for the user exit are explained in the documents Setup Guide– Application Monitoring and Setup Guide – User Exit respectively (URL http://www.service.sap.com/ AliasBPM Media Library).

1.7.4.1.1 Throughput and backlog indicators (TBIs)

As of ST-A/PI 01H a completely new set of application monitors has been introduced. While the alreadyestablished monitors are all evaluating specific logs or performance data these new monitors are considering(un-)processed documents in the SAP system and provide 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) Manufacturing (e.g. planned orders, production or process orders, autom. goods movements posted with

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 (URLhttp://www.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 Best Practicedocument 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 be

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

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

http://service.sap.com/solutionmanagerbp



identified 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 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 on the subject what kind of alerts make sense or what kind of alerts are possibleare discussed in the Best Practice document Background Job Monitoring with SAP Solution Manager whichcan be found on the SAP Marketplace http://service.sap.com/solutionmanagerbp, topic area BusinessProcess Operation.

1.7.4.4 ABAP dump collector

The dump collector provides monitoring features for alerting on occurrences of ABAP dumps of specifiedruntime errors and collects statistical data of ABAP dumps for reporting reasons.

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

1.7.4.4.2 Monitoring alerts

Possible Alerts 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 type Number of ABAP Dumps (Delta)

http://service.sap.com/solutionmanagerbp



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

1.7.4.5.1 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. Aftersaving this node a sub-node Performance Alerts will appear where the threshold values have to be entered.

Figure 2: Monitoring objects – Dialog performance

1.7.4.5.2 Monitoring Alerts

Each table in the sub-node Performance Alerts corresponds to an alert type chosen in the higher-level node,and 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 be possiblethat the object already exists there. Therefore you can load the current threshold values from the respectivesystems 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 columnDefault). 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 Copy all button.

Figure 3: Monitoring alerts – Dialog performance

1.7.4.6 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.7 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 certain user isprocessing the due list, the name of the user can be specified here. If it is user independent a wild card ‘*’ canbe used. The aggregation level needs to be defined. This could be per day, per hour or per log.

Monitoring alerts

For the monitoring of due list log messages, four different alert types can be used:1. DocumentCreation refers to the status of the document creation itself. The alert rating (YELLOW or RED)

will be raised if no documents were created during a due list run.



2. MinQuantityDocs refers to a minimum number of documents that should be created during a Due List run.The threshold values for the number of documents that result in a change from GREEN to YELLOW (orback) and from YELLOW to RED (or back) must be maintained.

3. TotalQuantityMsgs refers to the total number of message created during a due list run.4. The threshold values for the number of messages that result in a change from GREEN to YELLOW (or

back) and from YELLOW to RED (or back) must be maintained.5. DLLogMsgs refers to specific due list log messages. The message type, the message ID and 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 objects – Due list log

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

1.7.4.8.1 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 usewild cards.

Figure 7: Monitoring alerts – Application log/critical messages



1.7.4.9 Other CCMS monitors

With other CCMS monitors it is possible to assign any CCMS monitoring tree element (MTE) to a businessprocess step. Therefore it is necessary to call transaction RZ20 in the satellite system and to open a monitorthat contains the required alert(s).

The name of the monitoring tree element (MTE) can be found by choosing F1. The MTE name needs to becopied into the corresponding column of the table below (See screenshot “Other CCMS Monitors” below).Under column Monitor Name it is possible to assign an individual name.

The MTE used for monitoring should be an MTE on the lowest leaf-level, i.e. on attribute level. If anMTE of a higher branch-level (collective MTE) is chosen then the current and open view in the

graphics will show the right alerts but it isn’t possible to work on these alerts within the Business ProcessMonitoring 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 assign MTEsfrom 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.10 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 (Call



Option 2). Per default some standard transactions are maintained, e.g. transaction SM37, that provides a joboverview in an SAP system, is maintained for background jobs or transaction SLG1 to have a look into theapplication 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

http://help.sap.com./



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 the SAP Solution Manager system (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 20characters) from the set-up session and leads the user to the defined URL in a newly opened browserwindow.

1.7.4.11 Monitoring activities

Monitoring activities should be set up for every monitoring object within a business process step. Allmonitoring objects defined within a business process step are listed here. To ensure effective monitoring andefficient problem resolution the responsibilities should be assigned and problem resolution 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 required monitoringactivity.

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

Additional information related to this business process step can be entered in the tables Monitoring Activities,Error Handling, Restart of Step and Escalation Path. Those information would be valid for the whole businessprocess step and helps users who have to carry out the monitoring and who are not so familiar with thatparticular business process.

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

1.7.4.12.1 Workflow Notification

Sender Must be a user within in the monitoring client of SAP Solution Manager. Thisuser can be even a system user without any roles or profiles, but the usermust have a valid e-mail address that is known by the used mail-server

Recipient 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 enterSMS:<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 (shareddistribution list).

No. of Yellow Alerts 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,even if the thresholds are not exceeded

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

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

1.7.4.12.2 Support Notifications

Priority Defines the priority of the support notification.

Queue Defines the support component on which the message is put. Thiscomponent must exist within the service desk.

Processor Defines a default processor who should process the message. Theprocessor must be known within the service desk and must be SAP user



name that is defined 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 bea SAP user name that is defined as a business partner with role general.

Num. of YELLOWAlerts

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

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

If in addition to queue, processor, priority and reporter either one of the columns Num of YELLOWAlerts or Num of RED Alerts is filled with a value, the automatic support notification creation isconfigured. 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 asupport notification if there either exist more than 9 yellow alerts or more than 4 red alerts for which nosupport 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 withinthe SAP Service Marketplace for more detailed information on a topic.



2 Business Process Monitoring for a Merchandise and AssortmentPlanning

The business scenario Merchandise and Assortment Planning includes different common retail businessprocesses. In general these business processes build an integrated business scenario by using joinedplanning levels and key figures. Which processes are put to practical use is also customer specific as the

concrete process steps and implementation of the business processes.

Merchandise and Assortment Planning is characterized by business process steps with manually maintainedkey figures or key figures calculated by planning functions. Based on the planning requirements integratedplanning and the retail specific Master Data Planning (MDP) can be implemented. Master data planning(MDP) is prerequisite to create new specific retail master data within the planning.

As the business processes are implemented based on the same technical features, the different processeshave the same possibilities for business process monitoring. Therefore this chapter is divided in twosubchapters. One subchapter describes the business processes and lists the monitoring objects available forthe process steps. The next subchapter then explains these monitoring possibilities then in greater detail.

Please note that particularly in MAP implementations due to deviating assortment and categorymanagement practices, the Business Processes realized are most of the time project specific. The usedbusiness processes, key figures and master data for planning and reporting as well as the implemented InfoCubes and the implemented data flows etc. differ from company to company. This guide contains somegeneral aspects common to most MAP implementations.

Please note also that a proper BI implementation and a proper MDP configuration are of particularimportance for a stable operating of a Merchandise and Assortment Planning.

2.1 Business Processes

The following images provide an overview about the common retail planning processes. The first imageshows the process flow for strategic planning, store planning, merchandise planning and plan reconciliation.



© SAP 2008 / Project RunSAP for Retail / 4

Merchandise and Assortment Planning -Process flow for Planning Processes


SAP BI System

Store Markdown Planning

Store Sales Planning

Store Gross Margin Planning

Store analytics

Store Inventory & ReceiptsPanning

Store Planning

Markdown Planning

Sales Planning

Gross Margin Planning

Merchandise analytics

Inventory & Receipts Panning

Merchandise Planning

Strategic Division planning

Strategic Planning DistributionChain

Strategic analytics

Strategic Planning

Plan Reconcilation

Plan Reconcilation

Figure 11: Process flow for planning processes

These planning processes are usually performed once or twice a year. The results of the planning processesare usually used as input for the subsequent processes. These processes can be divided in fashion andbasics based on the merchandise characteristics and its specific requirements. The following image showsthe process flow for Fashion Merchandise.

SAP BI System


Assortment Planning and Assortment Managementfor Fashion Merchandise (Integrated Scenario)


Assortment Planning Fashion

Store Segmentation (optional)

Capacity Planning (optional)

Assortment Definition

Create Planned Article (optional)

Target Planning

Execute Quantity Planning(optional)

Create Prepack GenerationInformation (optional)

Release to Merchandise System

SAP ERP for Retail

Assortment Management Fashion

Perform quantity planning

Add articles to purchase list

Perform detailed article planning

Perform Prepack Planning

Release

Figure 12: Process flow for Fashion Merchandise



The process flow for basic merchandise is shown by the next image. Please note that the image shows theprocess including the optional integration of an external Shelf Optimization Program (SOP).

SAP BI System


Assortment Planning and Assortment Managementfor Basic Merchandise (Integrated Scenario)


Assortment Planning Basics




Create assortment version(optional)

Create planned article (optional)

Add article to assortment version

Release assortment version toSOP (optional)

Check optimized assortmentversion (optional)

Release to merchandisingsystem

SAP ERP for Retail

Assortment Management Basics

Assign articles

Create and maintain layoutmodules and layout module

versions

Assign Stores

Release layout module versions

External SOP System


Optimize planogram (assortmentversion)

Request for assortment versionout of SOP (optional)

Release optimized planogram tpPlanning

Figure 13: Process flow for Basic Merchandise

2.1.1 Business Process Strategic Planning

The goal of this business process is to create strategic objectives for the company and to pass those targetsdown through the organization.

The strategic planning process sets high-level financial plans for e.g. sales, markdowns (markdowns onlyapply to RMA planning layouts), gross margin, average inventory and turnover. The strategic plan is usuallydeveloped once a year by the executive in an organization. The result of the strategic planning usuallyprovides input values to the subsequent processes like e.g. merchandise or store planning.

More information regarding the business process Strategic Planning and Merchandise and AssortmentPlanning is available within the SAP Knowledge Warehouse under SAP for Retail: Business ScenarioDescriptions Merchandise and Assortment Planning.






SAP BI System




Store analytics


Store Planning

Markdown Planning

Sales Planning







Strategic analytics

Strategic Planning

Plan Reconcilation

Plan Reconcilation

Figure 14: Process flow for Planning Processes – Strategic Planning

2.1.1.1 Monitoring requirements

To implement this planning process usually the planning functionality of integrated planning and theretail specific Master Data Planning (MDP) is used. For more information regarding monitoring ofIntegrated Planning and Master Data Planning please see subchapter 2.2.1 Monitoring for retail

planning within SAP BI.


MonitoringObject

SelectionCriteria

Alert Analysis Tool onSatellite System

Monitoring Frequency/ Data Collection

Data extractionfrom SAP forRetail

Datasources,Process Chains ,Cubes requiredfor the planningprocess

Canceled processchains

RSAx Defined by uploadingfrequency

WebDynproPerformance

UsedWebdynpros

Runtime aboveSLA

On a regular basis inplanning phase

QueryPerfomance

Selected queriesused

Runtime aboveSLA

On a regular basis

Table 2: Business Process Strategic Planning – Monitoring objects



2.1.2 Business Process Merchandise Planning

The objective of creating merchandise plans is to meet the objectives of the company goals and targets, e.g.sales and gross margin. The merchandise planning process requires planners to develop detailed plans toachieve the company goals. The merchandise plan is usually developed once or twice a year by themerchants in an organization.

The merchant plans an extended set of key performance indicators (KPIs) and time horizon to match thecompany goals. Once the merchant is satisfied with the plans, the merchant’s manager approves the plansso they can be incorporated into the reconciliation process.

More information regarding the business process Merchandise Planning and Merchandise and AssortmentPlanning is available within the SAP Knowledge Warehouse under SAP for Retail: Business ScenarioDescriptions Merchandise and Assortment Planning.




SAP BI System




Store analytics


Store Planning

Markdown Planning

Sales Planning







Strategic analytics

Strategic Planning

Plan Reconcilation

Plan Reconcilation

Figure 15: Process flow for Planning Process – Merchandise Planning

2.1.2.1 Monitoring Requirements

Also for the implementation of this business process the planning functionality of Integrated Planningand the retail specific Master Data Planning (MDP) is usually used. For information regardingmonitoring of Integrated Planning and Master Data Planning please see subchapter 2.2.1 Monitoring

for retail planning within SAP BI.




MonitoringObject

SelectionCriteria


Monitoring Frequency/Data Collection



Canceledprocess chains



UsedWebdynpros

Runtime aboveSLA


QueryPerfomance


Runtime aboveSLA

On a regular basis

Table 3: Business Process Merchandise Planning – Monitoring objects

2.1.3 Business Process Store Planning

The objective of store planning is to create store plans to meet the company goals and targets. Previously tothis process the strategic planning and distribution of the relevant key figures down to the store plan is usuallyperformed by a planner.

The business process Store Planning designs the strategic plan in detail, taking into account the differentelements in the store hierarchy (company, region, district and store). The store plan is usually developedonce or twice a year by the store planner in an organization. The store planner plans an extended set of keyperformance indicators (KPIs), e.g. Sales, Receipts, Margin, Inventory or Shrinkage, and time horizon tomatch the company goals, e.g. year/season/month/week.

More information regarding the business process Store Planning and Merchandise and Assortment Planningin general is available within the SAP Knowledge Warehouse under SAP for Retail: Business ScenarioDescriptions Merchandise and Assortment Planning.






SAP BI System




Store analytics


Store Planning

Markdown Planning

Sales Planning







Strategic analytics

Strategic Planning

Plan Reconcilation

Plan Reconcilation

Figure 16: Process flow for Planning Process – Store Planning


To implement the business process Store Planning the planning functionality of Integrated Planning and theretail specific Master Data Planning (MDP) is usually used. For information regarding monitoring of IntegratedPlanning and Master Data Planning please see subchapter 2.2.1 Monitoring for retail planning within SAP BI.


MonitoringObject

SelectionCriteria








UsedWebdynpros

Runtime aboveSLA


QueryPerfomance


Runtime aboveSLA

On a regular basis

Table 4: Business Process Store Planning – Monitoring objects

2.1.4 Business Process Reconciliation Plan

The objective of the reconciliation plan is to reconciling the strategic, merchandise and store plans. When themerchandise and store plans are completed and the results are rolled back to the reconciliation plan, they



need to be compared to the original strategic objectives. The merchandise and store plans are reviewed tosee if changes need to be made before final authorization and “lock-down” of the plans.

More information regarding the business process Reconciliation Plan and Merchandise and AssortmentPlanning is available within the SAP Knowledge Warehouse under SAP for Retail: Business ScenarioDescriptions Merchandise and Assortment Planning.




SAP BI System




Store analytics


Store Planning

Markdown Planning

Sales Planning







Strategic analytics

Strategic Planning

Plan Reconcilation

Plan Reconcilation

Figure 17: Process flow for Planning Process – Plan Reconciliation


Also for the implementation of the business process Reconciliation Plan the planning functionality ofIntegrated Planning and the retail specific Master Data Planning (MDP) is usually used. For

information regarding monitoring of Integrated Planning and Master Data Planning please see subchapter2.2.1 Monitoring for retail planning within SAP BI.


MonitoringObject

SelectionCriteria




Datasources,Process Chains ,Cubes requiredfor the planningprocess,Beispiele?




UsedWebdynpros

Runtime aboveSLA




MonitoringObject

SelectionCriteria



QueryPerfomance


Runtime aboveSLA

On a regular basis

Table 5: Business Process Reconciliation Plan – Monitoring objects

2.1.5 Business Process Assortment Planning Basics

The objective of Assortment Planning Basics is to plan the structure of assortments and their presentation instores at the merchandise area level and for one planning period. This business process allows to createassortments and assortment versions and to plan them. Assortment versions model the different designs ofan assortment with the articles to be presented over time. Additionally the placement data of the articleassignments can be optimized by an external shelf optimization program (SOP). Also the assignment ofassortments to stores can be planned and restricted temporarily in order to plan the presentation ofassortments in stores.

The process ends with the transfer of the planning results to the business process Assortment Managementin SAP ECC.

More information regarding the business process Assortment Planning Basics and Merchandise andAssortment Planning is available within the SAP Knowledge Warehouse under SAP for Retail: BusinessScenario Descriptions Merchandise and Assortment Planning Assortment Planning AssortmentPlanning Basics.

SAP BI System














SAP ERP for Retail


Assign articles


versions

Assign Stores


External SOP System





Figure 18: Assortment Planning Basics (External SOP system, SAP BI system)



2.1.5.1 Monitoring Requirements

The planning functionality of Integrated Planning and the retail specific Master Data Planning (MDP)is usually used to implement this business process. Also the retail specific Release Workbench isused to implement this business process. For information regarding monitoring of Integrated

Planning and Master Data Planning please see subchapter 2.2.1 Monitoring for retail planning within SAP BI.For information regarding the release of the planning data and the connection with an external SOP pleasesee subchapter 2.2.2 Monitoring for Release Workbench within SAP BI


Monitoring Objects based on Retail Planning within SAP BI are listed in the table below:

MonitoringObject

SelectionCriteria








UsedWebdynpros

Runtime aboveSLA


QueryPerfomance


Runtime aboveSLA

On a regular basis

Table 6: Business Process Assortment Planning Basics – Monitoring objects

Monitoring objects based on the Release Workbench within SAP BI are listed in the table below. For detailsplease see subchapter 2.2.2 Monitoring for Release Workbench within SAP BI

MonitoringObject

SelectionCriteria



BI Outbound

(applicationissues (includingpush scenario toSOP), RFCconnectionissues)

Object:W

Subobject:MAP_RELEASE

(optional) ExternalID: technicalname of messagetype

Error status SLG1 Defined by releasefrequency for eachmessage type

BI Outbound

(XI or SOAconnectionissues, issuesregarding pullscenario to SOP)

Message status SXMB_MONI,qRFC, SMQ1,SMQ2

Depending on thetransfer frequency



MonitoringObject

SelectionCriteria



BI Inbound

(XI or SOAconnection issuesregarding datareceive fromSOP),

Object: W

Subobject::MAP_INBOUND

Error status SXMB_MONI Defined by inboundfrequency from SOP

BI Inbound

(applicationissues regardingdata receive fromSOP)

Object: W

Subobject::MAP_INBOUND

Error status SLG1 Defined by inboundfrequency from SOP

Release Job inthe Background

Error status SM37 Defined by releasefrequency for eachmessage type

SAP for RetailInbound

(applicationissues)

Object:WRF_MAPINB

SLG1 Defined by releasefrequency

Table 7: Monitoring objects based on the Release Workbench within SAP BI

2.1.6 Business Process Assortment Management Basics

The objective of the business process Assortment Management Basics is to create and maintain layoutmodules and layout module versions.

A layout module contains articles that will be presented together (products from one merchandise area, forexample). Layout module versions let you model the different designs of a layout module with the articles topresent over time. The maintenance of layout module versions consists of assigning articles and entering theplacement data for these articles. Articles can be assigned by criteria such as merchandise area (category orsubcategory, for example). Also an external space management program can be used to assign articles andmaintain the placement data.

The process concludes by releasing the layout module versions. This is usually followed by the creation oflisting conditions and the transfer of specific articles to a purchasing list.

More information regarding the business process Assortment Management Basics and Merchandise andAssortment Planning in general is available within the SAP Knowledge Warehouse under SAP for Retail:Business Scenario Descriptions Merchandise and Assortment Planning Assortment ManagementAssortment Management Basics.



SAP BI System














SAP ERP for Retail


Assign articles


versions

Assign Stores


External SOP System





Figure 19: Assortment Management Basics (SAP ERP for Retail)


The Layout functionality of SAP ECC is usually used to implement this business process. Forinformation regarding monitoring of Assortment Management Basics please see subchapter 2.2.3

Monitoring for Assortment Management Basics within SAP ECC.

2.1.6.2 Monitoring objects (optional: in SAP Solution Manager)

MonitoringObject

Selection Criteria Alert Analysis Tool onSatellite System


Listing conditioncreation job

WSML, program Job in error SM37 Depending on the listingfrequency, usually daily.

Listing conditioncreation

Object: W

Subobject::W_SORT_I1

Transaction:WSM4L

Error codes SLG1 Depending on the listingfrequency, usually daily.

Size ofreorganizationtables

Data base tablesWRF_WRSZ_DEL,WRF_WRS1_DEL,WRF_WLMV_DEL,WRF_ASGMT_DELandWRF_MALG_DEL

Data base tablesize

Depending on thefrequency of the deletion



MonitoringObject

Selection Criteria Alert Analysis Tool onSatellite System


ABAP Dumps Relevanttransactions

Occurrence ofdumps

ST22 Daily

Performance Depending onanalysis tool, e.g.relevanttransactions

Performanceindicatorsdetermined byproject team

As needed:

ST03N

STAD

ST05

ST12

Depending on projectrequirements

Table 8: Monitoring Objects (optional: in SAP Solution Manager)

2.1.6.3 How to find meaningful thresholds per monitoring object

Does not apply to this process.

2.1.7 Business Process Assortment Planning Fashion

The objective of the business process Assortment Planning Fashion is to create assortments by strategicperspectives, assign them to stores in the BI system, and then release this information for operational use inSAP ECC. This business process considers the characteristics of fashion merchandise as the planningaspect is much more important for assortment creation than for other types of merchandise. Where fashionmerchandise is involved, assortment planning is much more dependent on creativity, the analysis of fashiontrends, and the ability to modify existing plans as quickly as possible. Therefore next to the strategic tasks(like defining assortments, planning of objectives) also operational tasks (e.g. determiningarticles/colors/sizes, planning of quantities, and determining prepack information) can take place withinAssortment Planning Fashion in SAP BI.

The business process Assortment Planning Fashion ends with the release of the assortments, storeassignments and targets planned in SAP BI via the Release Workbench to SAP ECC. Within SAP ECC theassortment handling of fashion merchandise can be continued and supplemented with the business processAssortment Management Fashion.

More information regarding the business process Assortment Planning Fashion and Merchandise andAssortment Planning in general is available within the SAP Knowledge Warehouse under SAP for Retail:Business Scenario Descriptions Merchandise and Assortment Planning Assortment PlanningAssortment Planning Fashion.



SAP BI System









Target Planning




SAP ERP for Retail






Release

Figure 20: Assortment Planning Fashion (SAP BI system)


The planning functionality of Integrated Planning and the retail specific Master Data Planning (MDP)is usually used to implement this business process. Also the retail specific Release Workbench isused to implement this business process. For information regarding monitoring of Integrated

Planning and Master Data Planning please see subchapter 2.2.1 Monitoring for retail planning within SAP BI.For information regarding the release of the planning data please see subchapter 2.2.2 Monitoring forRelease Workbench within SAP BI


Monitoring objects based on Retail Planning within SAP BI are listed in the table below:

MonitoringObject

SelectionCriteria








UsedWebdynpros

Runtime aboveSLA


QueryPerfomance


Runtime aboveSLA

On a regular basis

Table 9: Business Process Assortment Planning Fashion – Monitoring objects



Monitoring objects based on the Release Workbench within SAP BI are listed in the table below. For detailsplease see subchapter 2.2.2 Monitoring for Release Workbench within SAP BI

MonitoringObject

SelectionCriteria



BI Outbound

(applicationissues, RFCconnectionissues)

Object:W

Subobject:MAP_RELEASE

(optional) ExternalID: technicalname of messagetype

Error status SLG1 Defined by releasefrequency for eachmessage type

BI Outbound

(XI or SOAconnectionissues)

Message status SXMB_MONI,qRFC, SMQ1,SMQ2

Depending on thetransfer frequency

Release Job inthe Background

Error status SM37 Defined by releasefrequency for eachmessage type

SAP for RetailInbound

(applicationissues)

Object: WRFAPC

Subobject:PLINBOUND

Error codes SLG1 Defined by releasefrequency

Table 10: Monitoring objects based on the Release Workbench within SAP BI

2.1.8 Business Process Assortment Management Fashion

The objective of the business process Assortment Management Fashion is to detail and adjust the planningresults of the previous business process Assortment Planning Fashion.

This includes operative tasks like determining articles/colors/sizes, planning of quantities and determining ofprepack information. At the end of this business process the necessary information for the creation ofpurchase orders are available.

The business process Assortment Management Fashion ends with the release of purchase list items to theoperational follow-on processes (such as ordering, for example).

More information regarding the business process Assortment Management Fashion and Merchandise andAssortment Planning in general is available within the SAP Knowledge Warehouse under SAP for Retail:Business Scenario Descriptions Merchandise and Assortment Planning Assortment ManagementAssortment Management Fashion.



SAP BI System









Target Planning




SAP ERP for Retail






Release

Figure 21: Assortment Management for Fashion Merchandise (SAP ERP for Retail)


The functionality of purchasing lists within SAP ECC is usually used to implement this businessprocess. For information regarding monitoring of Assortment Management Fashion please see

subchapter 2.2.4 Monitoring for Assortment Management Fashion within SAP ECC.


MonitoringObject

Selection Criteria Alert Analysis Toolon SatelliteSystem

MonitoringFrequency/ DataCollection

Release ofplanned articles(applicationissues)

Object: WRF_APC

Subobject: PARELEASE

Error codes SLG1 Defined byreleasefrequency

Release ofpurchase listitems (applicationissues)

Object: WRF_APC

Subobject: PLRELEASE

Error codes SLG1 Defined byreleasefrequency

Release Job forplanned articlesin theBackground

ReportRWRF_APC_POST_ART

Error status SM37 Defined byreleasefrequency

Release Job forpurchase listitems in theBackground

ReportRWRF_APC_POST_PLITEM

Error status SM37 Defined byreleasefrequency



MonitoringObject

Selection Criteria Alert Analysis Toolon SatelliteSystem

MonitoringFrequency/ DataCollection

ABAP Dumps Relevant transactions Occurrence ofdumps

ST22 Daily

Performance Depending on analysis tool,e.g. relevant transactions

Performanceindicatorsdetermined byproject team

As needed:

ST03N

STAD

ST05

ST12

Depending onprojectrequirements

Table 11: Business Process Assortment Management Fashion – Monitoring objects

2.2 Monitoring Possibilities for Merchandise and Assortment Planning

2.2.1 Monitoring for retail planning within SAP BI

In order to perform the business process steps for planning, master data and transactional data needs to beextracted from SAP for Retail. This data needs to be extracted and processed on a regular basis. Errors indata load and data staging should be followed. Incomplete or invalid data reflect a wrong situation and cancause wrong planning data. This can have an influence on depending operative decisions, e.g. like orderquantities of purchase orders. In order to guarantee an availability of correct data the reasons for the errorsneed be corrected immediately.

For monitoring of BI data transfer processes please refer to the generic BI documentation Periodic Jobs andTasks in SAP BW under https://service.sap.com/solutionmanagerbp.

The planning layouts of the retail specific Master Data Planning (MDP) are Web Dynpro applications.Therefore the response time of the portal should be monitored. The values are implementation specific asthey depend e.g. on the hardware capabilities of the used systems. Therefore average values need to bedetermined for an implementation to monitor deviations from these values.

If planning includes BI queries, the query performance can be monitored. For monitoring of queryperformance please refer to the generic BI documentation Monitoring for SAP BI Reporting underhttps://service.sap.com/solutionmanagerbp.

Please note that the runtime of reporting and input-ready queries may be considerable different in the runtimedue to the effort required to ensure the planning model is consistent. SAP Note 1056259 contains anoverview of how you can significantly improve the system performance by using a suitable customizing anddesign for BI Integrated Planning

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




2.2.2 Monitoring for Release Workbench within SAP BI

Specific planning results can be released to an ERP system for Merchandise and Assortment Planning, e.g.new assortments or new store assignments to assortments. This can be done with the Release Workbench.The processing of the specific planning results within the release workbench is handled by message types.

The connection from SAP BI to an ERP system can be set up via RFC connection, XI or SOA service(s). TheRelease Workbench can be used in a dialog mode and an offline mode. Furthermore the Release Workbenchprovides the possibilities Release Online/Release Messages Immediately or Release Batch/ReleaseMessages in a Job for the release.

Monitoring of the release is necessary. If problems prevent the release of retail specific planning results, thedata are not available on ERP side. The subsequent processes within ERP can not be performed withoutthese data or have the risk of being performed with incomplete data. This can end in e.g. wrong orderquantities or out of stock situations in the stores and therefore and a loss of sales in the affected stores. Asthese data problems are only visible or pursuable with limitations for the user, the release should be closelymonitored.

The problems can be structured as connection problems, application problems or background job problems.Please note that some problems may occur on BI side and on ERP side. Therefore it is necessary to monitoron both sides.

Connection problems

If XI or SOA is used to connect BI and ERP for the release, it needs to be differentiated if the data are sentsynchronously or a synchronously. For synchronous messages the XI log (transaction SXMB_MONI) shouldbe monitored. For asynchronous messages the XI log (transaction SXMB_MONI) and the qRFC Monitor(transactions SMQ1 and SMQ2) should be monitored.

Please note that the SXMB_MONI log on BI and on ERP side are replicated from the XI server. If a logcannot be replicated or is only available on the XI server, please monitor the XI log (transactionSXMB_MONI) on the XI server

If RFC is used to connect BI and ERP for the release, the data sent using the release workbench is sentsynchronously. If the connection to the ERP system cannot be made, the Release Workbench writes an entryin the application log (transaction SLG1). The application log can be monitored with the following selection:

Object: W

Subobject: MAP_RELEASE

Additionally please refer for monitoring of RFC connections to the generic documentation RFC Monitoringunder https://service.sap.com/solutionmanagerbp.

Application problems

For application problems on BI side the application log (transaction SLG1) can be monitored. Please not thatin general this can be done by the user manually within the Release Workbench.




If necessary due to implementation specific requirements, e.g. Release Workbench is called in offline modeor user is not allowed to access the Release Workbench, the application log can be monitored with thefollowing selection:

Object: W

Subobject: MAP_RELEASE

The selection can be restricted furthermore to select the results of single message types. For this enteradditionally the technical name of the message type as external ID for the selection. The available messagetypes and their technical names are:

Technical Name Message Type Description

ALLOCPO Allocation and PO

ASRTPLN Assortment Plan

ASRTPRD Assortment Product

ASRTPRDVRSM Assortment Product Version Merchandising

ASRTPRDVRSO Assortment Product Version Optimization

LOCGRP Location Group / Assortment

MDPROP Markdown Proposals

OTB Open To Buy (OTB)

PRODUCT Product

RTLPURPLN Retail Purchasing Plan

Table 12: Technical name/ Message type description

If a shelf optimization program (SOP) is connected with SAP BI, the connection can be set up as push or pullscenario. The push scenario is handled via the Release Workbench, therefore a monitoring can be processedas described in the previous paragraph. The pull scenario needs to differentiate between the data requestfrom SOP and data reception from SOP. For the data request from SOP the log can be viewed viatransaction SXMB_MONI as mentioned above. For the data received from SOP the log in the confirmationpart of the service can be viewed via transaction SXMB_MONI to know, for example, why some data could beposted and some not. If data could only be partially posted in MAP/BI, messages describing what happenedare written in the application log (transaction SLG1). The application log can be monitored with the followingselection:

Object:W

Subobject: MAP_INBOUND



For application problems on ERP side the application log (transaction SLG1) should be monitored for thegeneric log of the MAP Inbound and the applications specific log entries (specific inbound processing for themessage types). To access the generic log for the MAP Inbound select:

Object: WRF_MAPINB

To monitor the applications specific log, enter the corresponding criteria for result selection within SLG1. Tomonitor the release of the retail purchasing plan the application log can be accessed with the followingselection:

Object: WRFAPC

Subobject: PLINBOUND

Background job problems

If the release is performed as background job on a regular basis, this job can be monitored with thetransaction SM37. Additionally please refer to the documentation Background Job monitoring with SAPSolution Manager under https://service.sap.com/solutionmanagerbp for the monitoring of background jobs.

If the monitoring reported a problem, which stopped the processing of the release, the data are not availablewithin the ERP system.

The necessary step to restart the data release after resolving the problem depends on the status of the datawithin SAP MAP. The status of the data within SAP MAP is handled by the release workbench. Based on theselection criteria within the Release Workbench the data are collected and then handed over to the XI, SOAor RFC connection. The processing within the Release Workbench closes with an update of the data statusfrom ‘planned’ to ‘released’. This means that any problems in the release process later than this do notchange the status of the data back to ‘planned’.

If the data have still the status ‘planned’ within SAP MAP, the normal release process can be started again. Ifthe data have the status ‘released’ and are not available within the ERP system, the following procedure canbe performed:

In the Release Workbench the necessary selection criteria for the relevant message type need to be entered.Additionally the field Re-release needs to be flagged. Then the release can be started again.

This procedure needs to be processed carefully. Please note that all data corresponding to theselection criteria will be transferred to ERP. Therefore also all data which already exist within SAP ERP willbe transferred from SAP MAP to SAP ERP. This means that all changes done on SAP ERP side after the lastdata extraction from SAP ERP to SAP MAP will be overwritten by the values rereleased from SAP MAP.

Therefore it is necessary to enter carefully and detailed your selection criteria to re-release the smallestnecessary amount of data.

2.2.3 Monitoring for Assortment Management Basics within SAP ECC

It is important that based on released layout module versions listing conditions will be created. Without listingconditions the delivery of articles to the stores is not possible. This can end in out-of-stock situations and a

https://service.sap.com/solutionmanagerbp



loss of sales in the affected store. Therefore it is necessary to monitor the processing of the creation of listingconditions.

Listing conditions are created by transaction WSM4L which is usually processed within a regular scheduledjob. Therefore it is necessary to monitor this transaction. The result of the release is updated in theapplication log SLG1 for the following selection:

Object: W

Subobject: W_SORT_I1

Transaction: WSM4L

It is necessary to reorganize the layout objects. Therefore a report (available via tranaction WLOR) can beused to delete the entries of the deletion tables for the WRF_WLAY objects. The deletion of the objects canonly be processed after it has been transferred to SAP BI. Without the deletion of the objects the tables willget larger and may influence the performance. Therefore the size of the deletion tables WRF_WRSZ_DEL,WRF_WRS1_DEL, WRF_WLMV_DEL, WRF_ASGMT_DEL and WRF_MALG_DEL can be monitored.Please note that the values for the table size are implementation specific as they depend on the businessprocess implementation (e.g. data volume, peak from time to time due to regular assortment rework).

Articles can be marked in the layout workbench to be transferred to the purchase functionality of thepurchasing list. If these articles are not transferred to the purchasing list, they can not be purchased. This cancause a delay in the purchase of these articles and end in out-of-stock situations and a loss of sales in theaffected stores. Therefore the transfer from the layout workbench to the purchasing lists can be monitored.The result of the transfer is updated in the application log SLG1 for the following selection:

Object: WRF_APC

Subobject: PLIST

Program: CL_WRF_LWB_OSPS_SERVICE=======CP

ABAP dumps indicate application errors e.g. after SPS installation or implementation of SAP notes based ona lack of suitability with enhancements. Therefore the transactions and reports may be monitored. Therelevant transactions and reports for the ABAP Dump Collector are WLWB, WLMV, WPLG, WSOA6,WSOA1, WSOA2, WLMM, WAREPL, WMSBA, WSM4L and WLOR. Please note that it is implementationspecific which selection of the transactions is in use.

The performance of the transactions and reports can be monitored. The values for the performance indicatorsare implementation specific as they depend on the hardware capabilities of the used systems and on thebusiness process implementation (e.g. data volume and number of selected layout module versions in thelayout workbench, available time-window). Therefore average values need to be determined for animplementation to monitor deviations from these values. The relevant transactions and reports for theperformance are WLWB, WLMV, WPLG, WSOA6, WSOA1, WSOA2, WLMM, WAREPL, WMSBA, WSM4Land WLOR. Please note that it is implementation specific which selection of the transactions is in use.



2.2.4 Monitoring for Assortment Management Fashion within SAP ECC

The monitoring for Assortment Management Fashion can be divided in the two parts monitoring of theapplication and monitoring of the release.

Monitoring of the application

The user adds items to a purchasing list (PL) and plans these PL items (e.g. quantity planning, detailed articleplanning and prepack planning). Purchasing list items can be existing generic/single articles and also creatednew, planned generic/single articles (article shells) as well as PRICAT article data. In case of limitedserviceableness of the application the purchase of articles in time and therefore the availability in time in thestores is endangered. This can cause a loss of sales or increase purchase costs.

The dialog performance can be monitored. The values for the performance indicators are implementationspecific as they depend on the hardware capabilities of the used systems and on the business processimplementation (e.g. data volume of a purchase list). Therefore average values need to be determined for animplementation to monitor deviations from these values. The relevant transactions for dialog performance areWRFAPC01 and WRFAPC02.

ABAP dumps indicate application errors e.g. after SPS installation or implementation of SAP notes based ona lack of suitability with enhancements. Therefore the transactions may be monitored. The relevanttransactions for the ABAP Dump are again WRFAPC01 and WRFAPC02.

Monitoring of the release

The business process includes the release of purchasing list items and the release of planned articles. PLitems and planned articles can be marked for release by the user, the release itself can be performed byreports in a daily background job. The business approach is to purchase articles as late as possible andensure the availability of the articles in time in the stores. It is important that the released purchasing list itemsand planned articles are fully transferred to the follow-on processes and are processed on time in the SAPERP. Missing or delayed data could cause the delayed purchase of articles in the follow-on processes. Thiscan end in stock-out situations and a loss of sales in the affected store or increase purchase costs.

Therefore it is necessary to monitor the processing of the release reports and the result of the release. Theresult of the release is written into an application log which can be viewed using TA SLG1.

Release of planned articles:

Report for daily batch job: RWRF_APC_POST_ART

Object for result selection within SLG1: WRF_APC

Subobject for result selection within SLG1: PARELEASE

Release of purchase list item:

Report for daily batch job: RWRF_APC_POST_PLITEM

Object for result selection within SLG1: WRF_APC

Subobject for result selection within SLG1: PLRELEASE



The performance of the reports can be monitored. The values for the performance indicators areimplementation specific as they depend on the hardware capabilities of the used systems and on thebusiness process implementation (e.g. data volume of a released purchase list items). Therefore averagevalues need to be determined for an implementation to monitor deviations from these values. The relevantreports for performance are RWRF_APC_POST_ART and RWRF_APC_POST_PLITEM.

ABAP Dumps indicate application errors e.g. after SPS installation or implementation of SAP Notes based ona lack of suitability with enhancements. Therefore the reports may be monitored. The relevant reports for theABAP Dump Collector are RWRF_APC_POST_ART and RWRF_APC_POST_PLITEM.



3 Further Information

3.1 Related Best Practice Documents

There are several other Best Practice documents available on the SAP 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.

https://service.sap.com/solutionmanagerbp



Index of FiguresFigure 1: Alert type Number of ABAP Dumps (Delta) 9Figure 2: Monitoring objects – Dialog performance 10Figure 3: Monitoring alerts – Dialog performance 11Figure 4: Monitoring objects – Update errors 12Figure 5: Monitoring objects – Due list log 13Figure 6: Monitoring objects and alerts – Application log 14Figure 7: Monitoring alerts – Application log/critical messages 14Figure 8: Other CCMS monitors 15Figure 9: Analysis & monitoring transactions 16Figure 10: Analysis & monitoring URL 16Figure 11: Process flow for planning processes 22Figure 12: Process flow for Fashion Merchandise 22Figure 13: Process flow for Basic Merchandise 23Figure 14: Process flow for Planning Processes – Strategic Planning 24Figure 15: Process flow for Planning Process – Merchandise Planning 25Figure 16: Process flow for Planning Process – Store Planning 27Figure 17: Process flow for Planning Process – Plan Reconciliation 28Figure 18: Assortment Planning Basics (External SOP system, SAP BI system) 29Figure 19: Assortment Management Basics (SAP ERP for Retail) 32Figure 20: Assortment Planning Fashion (SAP BI system) 34Figure 21: Assortment Management for Fashion Merchandise (SAP ERP for Retail) 36

Index of TablesTable 1: Monitoring activities 17Table 2: Business Process Strategic Planning – Monitoring objects 24Table 3: Business Process Merchandise Planning – Monitoring objects 26Table 4: Business Process Store Planning – Monitoring objects 27Table 5: Business Process Reconciliation Plan – Monitoring objects 29Table 6: Business Process Assortment Planning Basics – Monitoring objects 30Table 7: Monitoring objects based on the Release Workbench within SAP BI 31Table 8: Monitoring Objects (optional: in SAP Solution Manager) 33Table 9: Business Process Assortment Planning Fashion – Monitoring objects 34Table 10: Monitoring objects based on the Release Workbench within SAP BI 35Table 11: Business Process Assortment Management Fashion – Monitoring objects 37Table 12: Technical name/ Message type description 39



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