Manage Operations for SAP for Retail

Best Practice for Solution Operations

Manage Operations for SAP for Retail ERP Replenishment

Dietmar-Hopp-Allee 16 D-69190 Walldorf CS

customer DATE

June 10 2009 SOLUTION MANAGEMENT PHASE

STATUS

published VERSION

3.0 SAP SOLUTION

Operations & Continuous Improvement Best Practices for Solution Operations TOPIC AREA

SOLUTION MANAGER AREA

Application & Integration Management Business Process Operations

BP_ERP_Replenishment_V30.doc – 10.06.2009

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Table of Contents 1 Management Summary 1.1 Goal of Using This Best Practice 1.2 Alternative Practices 1.3 Staff and Skills Requirements 1.4 System Requirements 1.5 Duration and Timing 1.6 How to Use This Best Practice 1.7 Best Practice Procedure 1.7.1 Preliminary tasks 1.7.2 Monitoring concepts 1.7.3 Business Process Monitoring in SAP Solution Manager 1.7.4 Monitoring types for Business Process Monitoring in SAP Solution Manager 1.7.5 Business Process Monitoring process 1.7.6 Legend 2 Business Process Monitoring for ERP Replenishment 2.1 Sample Scenario 2.2 Business Process ERP Replenishment 2.2.1 Business process steps 1 to 5: POS inbound 2.2.2 Business process step 6: Execute store forecast 2.2.3 Business process step 7: Execute retail replenishment 2.2.4 Business process step 8: Create outbound deliveries 2.2.5 Business process step 9: Carry out warehouse processing 2.2.6 Business process step 10: Post goods issues in warehouse 2.2.7 Business process step 11: Post goods receipts in stores 3 Further Information 3.1 Related Best Practice Documents 3.2 Background Information and References Index of Figures Index of Tables

© 2009 SAP AG

3 3 3 3 4 4 5 5 5 5 6 7 19 19 20 20 21 22 22 25 28 31 36 38 40 40 40 41 41

page 2/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

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 for Retail solution. The concept aims at defining procedures for business process-oriented monitoring and error handling, and escalation procedures for your ERP Replenishment business process. These procedures intend to ensure a smooth and reliable flow of this core process so that your business requirements are met. This Best Practice gives orientation for defining suitable application-oriented monitoring objects in order to detect any irregularities or deviations from an ideal business process flow or to detect error situations concerning a core business process at an early stage. This Best Practice follows the recommended approach of SAP to use SAP Solution Manager for monitoring functionalities whenever possible. But even if you do not use SAP Solution Manager we recommend to follow the procedures described in this document as much as possible in order to ensure a smooth and reliable flow of your business processes as well as an appropriate response in case of unforeseen errors.

1.2

Alternative Practices

You can have SAP experts deliver this Best Practice on-site by ordering an SAP solution management optimization (SMO) service for SAP business process management (BPM). This service is exclusively available within SAP’s support engagements SAP MaxAttention and Safeguarding. If your company currently does not have any support engagement with SAP, it is also possible to get assistance by SAP experts from SAP Consulting. In this case, please contact your local SAP Consulting representative.

1.3

Staff and Skills Requirements

To implement this Best Practice, you require the following teams: Application management team This team creates the ERP Business Process Monitoring concept and consists of experts from several areas of your company: Business department Solution support organization (for example basis support or application support) Implementation project team Business process operations team The business process operations team will be responsible for applying the resulting procedures derived from implementing this Best Practice. It includes the following groups: Persons designated to perform business process-oriented monitoring and to 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)

© 2009 SAP AG

page 3/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

SAP technology operations team This team comprises all those in your solution support organization and IT department involved in monitoring focused on the system administration side (program scheduling management, software monitoring team, system administration team including the system administrator) Business process champion The business process champion is a person in the business department that is responsible for the successful execution of a given business process. He or she coordinates all activities necessary for the business process and, therefore, is usually responsible for the escalation paths in case of problems. Often this role serves as a second 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 Best Practice for General Business Process Management, which you can obtain through SAP Solution Manager or the SAP Service Marketplace, quick link /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 for Retail solution via SAP Solution Manager, the SAP Basis release of the systems to be monitored has to be at least 4.6C. To have all described monitoring objects available in SAP Solution Manager, the add-on ST-A/PI01L has to be installed on the SAP for Retail system.

1.5

Duration and Timing

Duration Creating a Business Process Monitoring concept can take approximately one week per business process. Implementing the Business Process Monitoring concept might take approximately another week. Timing The best time to apply this Best Practice is during the planning phase or during the implementation phase of your SAP solution.

© 2009 SAP AG

page 4/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

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 Best Practice for General Business Process Management, available on the SAP Service Marketplace. The document explains the procedures to be used to create a general Business Process Management concept. This includes the definition and documentation of the core business processes, definition of monitoring objects, definition of monitoring activities including error handling procedures, monitoring tools and monitoring frequencies, the definition of communication and escalation procedures and the assignment of responsibilities. At the beginning of chapter Error! Reference source not found. you will find a typical flow chart of the core business process explained in this Best Practice. It is intended to be used as a guideline for writing down your company-specific process documentation. In chapter 1.7.4 you will find further information relevant for more than one scenario. In case information from the generic part is relevant for a specific business process step in one of the scenarios, you will find a clear link to the corresponding chapter of 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 the system: 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. The monitoring procedures help you ensure that the technical processes meet the requirements for stability, performance and completeness. These procedures cover the monitoring for 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 in chapter 1.7.4. Recommendations for performance monitoring can also be found in this chapter. The

© 2009 SAP AG

page 5/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

performance of the most important steps of your core business processes should be monitored on a regular basis. The monitoring procedure for performance monitoring of all steps that are executed in an SAP for Retail solution is generally the same. Therefore, you will only find specific performance monitoring recommendations on selected business process steps. 1.7.3

Business Process Monitoring in SAP Solution Manager

Business Process Monitoring (BPMon), as part of Solution Monitoring means the proactive and processoriented monitoring of the most important or critical business processes, including the observation of all technical and business application-specific functions that are required for a steady and stable flow of the business processes. The core business processes that are implemented in an SAP for Retail system or other software and operated by a 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 a company’s business requirements in terms of stability, performance, and completeness. SAP Solution Manager provides a graphic to visualize a company’s (distributed) system- and solution landscape and all related business processes. By using Business Process Monitoring, it is possible to define and customize alert situations from the basic set of configurable alerts provided by SAP Solution Manager. These alerts are then visualized as green, yellow and red alert icons for each individual business process step in the graphical business process representation. Business Process Monitoring is intended to detect critical situations and respond to them as early as possible in order to solve problems as fast as possible. SAP Solution Manager also offers extended functionality for error handling and problem resolution. By the definition of contact persons and escalation paths, Business Process Monitoring can be integrated into the company’s overall strategy for business process management and solution management within their solution support organization. In general, Business Process Monitoring includes the solution-wide observation of: Business process performance (key performance indicators) Background jobs (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 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.

© 2009 SAP AG

page 6/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

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 SAP Solution Manager. The below mentioned monitoring types are available: Application monitor (throughput and backlog indicators, interface monitoring, 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 must be selected. In order to receive detailed information on how to set up the monitoring objects in SAP Solution Manager, please refer to the documentation available at http://service.sap.com/bpm. One prerequisite for setting up Business Process and Interface Monitoring in SAP Solution Manager is that all business processes and business process steps are maintained in the respective solution that contains all affected system components. If you want to learn more about how to set this up, please turn to http://help.sap.com 1.7.4.1

SAP Solution Manager

Basic Settings.

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 by Application Group

Plug-Ins

SAP Solution Tools

ST-A/PI.

Please ensure that ST-A/PI is installed on the SAP Solution Manager system and on the respective satellite. In case of problems refer to SAP Note 915933. The throughput and backlog indicator functionality available as of ST-A/PI 01J* is only working properly with ST-SER 700_2007_1. This is due to changes in the underlying architecture. More detailed information about the different application monitor functionalities and details on how to define self-written monitoring collectors for the user exit are explained in the documents Setup Guide – Application Monitoring and Setup Guide – User Exit, respectively (http://www.service.sap.com/ alias BPM

Media

Library). Throughput and backlog indicators More detailed information about the different application monitor functionalities and details on how to define self-written monitoring collectors for the user exit are explained in the Throughput and Backlog Indicators (TBIs).

© 2009 SAP AG

page 7/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

As of ST-A/PI 01H, a completely new set of application monitors has been introduced. While the already established monitors evaluate specific logs or performance data, these new monitors consider (un-) processed documents in the SAP system and provide so-called throughput and backlog indicators. These TBIs shall 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 (http://www.service.sap.com/ BPM

Media Library).

Data consistency checks Data consistency checks offer a unique possibility to check the consistency mainly of separate systems after data replication tasks have been carried out. As the processes described in this document take place in one central SAP for Retail system, data consistency checks are not offered. Oher data consistency checks are described in detail in Setup Guide – Data Consistency Monitoring (http://www.service.sap.com/ 1.7.4.2

Technical Information).

Background job

The background job monitoring should be part of a Job Scheduling Management concept. Go to http://service.sap.com/solutionmanagerbp, topic area Business Process Operations to find the Best Practice for Job Scheduling Management. Because of several restrictions regarding background job scheduling, e. g. time restrictions, restriction of hardware resources (CPU, main memory, …), or existing dependencies between different activities (e.g. invoices can only be created after the corresponding goods issue is posted, or backorder processing and material requirements planning should not run at the same time) it is very important to ensure the stable run of background jobs. A cancelled background job should be identified as soon as possible in order to react as fast as possible. Therefore it is also necessary to define restart procedures and escalation paths. Monitoring objects Before setting up monitoring, the monitoring objects must be clearly defined. A monitoring object is a single background job or a group of background jobs. There are four different possibilities to identify a special background job or a group of background jobs. This information needs to be maintained in the sub-node Background Job below a business process step.

© 2009 SAP AG

page 8/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

A detailed description of what kinds of alerts make sense or what kinds of alerts are possible is provided in the Best Practice for Background Job Monitoring with SAP Solution Manager document, which can be found on the SAP Marketplace http://service.sap.com/solutionmanagerbp, topic area Business Process Operation. 1.7.4.3

ABAP dump collector

The dump collector provides monitoring features for alerting on occurrences of ABAP dumps of specified runtime errors and collects statistical data of ABAP dumps for reporting reasons. Monitoring objects The monitoring object is an ABAP runtime error. This runtime error can be specified via the runtime error name, the user who is responsible for the runtime error, the client on which the runtime error occurs or the program that leads to the runtime error. Monitoring alerts Possible alert types are the Number of ABAP Dumps (Delta) – all dumps since the last collector run – and Number of ABAP Dumps (Reporting) – all runtime errors of specified type, client and program for this day or for the previous day.

Figure 1: Alert type Number of ABAP Dumps (Delta)

1.7.4.4

Dialog performance

Dialog performance implies the monitoring of the dialog transaction performance of any transaction in the SAP system. This can be a standard transaction or a custom-developed transaction. Monitoring objects The monitoring object is the transaction itself. The customizing has to be done in the Dialog Performance node. The Transactions table lists all transactions that are already configured to that business process step. The relevant transactions need to be selected for monitoring. It is also possible to add or to remove

© 2009 SAP AG

page 9/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

transactions within the Add/Remove Transactions table. The monitoring can be performed per SAP instance. To this end, select the respective instances in the SAP Instances table, which lists all instances that are maintained for a system. The Alert Types table shows the dialog response time and all parts of the response time that can be monitored, like queue time, load and generation time, database request time and the front-end response time. Select those times that are relevant for monitoring. After saving this node, a subnode Performance Alerts will appear where you can enter the threshold values.

Figure 2: Monitoring objects – Dialog performance

Monitoring alerts Each table in the Performance Alerts sub-node 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 you want to include in the monitoring, specify the threshold values resulting in alert messages for GREEN to YELLOW, YELLOW to RED, RED to YELLOW, and YELLOW to GREEN. Since the monitoring object for performance monitoring is created on the satellite system, it might be possible that the object already exists there. Therefore you can load the current threshold values from the respective systems via the Load thresholds from button, with representing the SID. If successfully retrieved for an SAP instance, the values are filled in columns. If no active settings for the threshold values were found for a certain transaction code, default values are set (indicated in column Default). To transfer the threshold values for a single line from right to left, the Copy icon can be used. To transfer all at once (all thresholds for all columns and tables) there is an additional Copy all button.

© 2009 SAP AG

page 10/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Figure 3: Monitoring alerts – Dialog performance

1.7.4.5

Update errors

Changes to the data in an SAP system caused by a business process should be written to the database in full or not at all. If the operation is canceled while the transaction is being executed or if an error occurs, the transaction should not make any changes to the database. These activities are handled by the SAP update system. The SAP system makes a distinction between primary, time-critical (V1), and secondary, non-time-critical (V2), update errors. This distinction allows the system to process critical database changes prior to less critical changes. V1 modules describe critical or primary changes, that affect objects with a controlling function in the SAP system, for example order creation or changes to material stock. V2 modules describe less critical secondary changes. These are pure statistical updates, for example, such as result calculations. Monitoring objects You can configure the monitoring of update errors for online transactions and/or ABAP programs relevant in a business process. This is the object type. The name of the object is the name of a transaction or the name of the ABAP program itself. If desired, you can specify a user executing the transaction or the ABAP program. If no user is specified explicitly, all users (represented by '*') will be considered in monitoring data evaluation.

© 2009 SAP AG

page 11/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

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 one update error occurs. This is valid for V1 and for V2 update errors. To raise a red alert for a V1 or a V2 update error, a threshold must be specified. 1.7.4.6

Due list log

A due list is a list that contains several entries (documents) depending on selection criteria. There are different types of due lists in an SAP system of which the following three are the most important: Delivery (L), Billing (F) and Picking (K). The delivery due list can be directly accessed via transaction V_SA, the billing due list via transaction V.21. In case of a billing due list, the list contains e. g. a number of sales documents that need to be billed. If the billing due list was processed previously and it is important to know which billing documents were created from this billing due list, you can display it 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. You can specify the name of the user that is responsible to process the due list. If it is user-independent, you can use the wildcard ‘*’. You also need to define the aggregation level needs to be defined, which can be per day, per hour or per log.

© 2009 SAP AG

page 12/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Monitoring alerts For the monitoring of due list log messages, you can use four different alert types: 1. DocumentCreation refers to the status of the document creation itself. The alert rating (YELLOW or RED) will be raised if no documents were created during a due list run. 2. MinQuantityDocs refers to a minimum number of documents that should be created during a due list run. The threshold values for the number of documents that result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (or back) must be maintained. 3. TotalQuantityMsgs refers to the total number of message created during a due list run. 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. 4. 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 wildcards. 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.

Figure 5: Monitoring objects – Due list log

1.7.4.7

Application log

The application log provides an infrastructure for collecting messages, saving them in the database and displaying them as a log. At runtime, situations can arise in application programs that must be brought to the attention of the user. These are usually errors. It can also be useful to report a successful completion. The information that arises is called a message. A set of messages is a log. A log usually also has 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 subobject that belongs to it classify each event. The analysis of the logs is similarly object- (or sub-object-) oriented. The name of an object (or sub-object) can be found in transaction /nSLG1 together with all other information specific to that log.

© 2009 SAP AG

page 13/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Figure 6: Monitoring objects – Application log

It is possible to monitor the total number of messages belonging to an object. For each object, the number of messages that raise a YELLOW alert and the number of messages changing from YELLOW to RED must be maintained. It is also possible to monitor specific messages that are considered as critical in the N° of Critical Messages tab. To configure the monitoring of critical application log messages, select the relevant object-sub object combinations. For each of these combinations, you can specify the message type, the message ID and the message number as well as the threshold values for the number of critical messages that are supposed to result in changes from GREEN to YELLOW and from YELLOW to RED can be specified. It is also possible to use wildcards.

Figure 7: Monitoring alerts – Application log/critical messages

1.7.4.8

Other CCMS monitors

With other CCMS monitors it is possible to assign any CCMS monitoring tree element (MTE) to a business process step. Therefore it is necessary to call transaction RZ20 in the satellite system and to open a monitor that contains the required alert(s). The name of the MTE can be found by choosing F1. The MTE name needs to be copied into the corresponding column (see Figure 8). Under column Monitor Name you can assign an individual name.

© 2009 SAP AG

page 14/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

The MTE used for monitoring should be an MTE on the lowest leaf-level, i. e. on attribute level. If an MTE of a higher branch-level (collective MTE) is chosen, then the current and open view in the graphics will show the right alerts but without the possibility to process these alerts within the Business Process Monitoring session as the alerts are not replicated there. In order to load the threshold values that are currently valid in the corresponding system, use the button . If successfully retrieved, the values are filled in the right-hand columns. If no active settings for the threshold values were found, these columns remain empty. To transfer the thresholds values for a single line from right to left, double-click the Copy icon.

Figure 8: Other CCMS monitors

Unlike all other monitoring types, Other CCMS Monitors provides the opportunity to assign MTEs from other systems than the system the actual business process step is assigned to. Example: If you are interested in monitoring the availability from a Portal system that possesses no CCMS but is included as one business process step in your business process, you can use one MTE in the CCMS of SAP Solution Manager to monitor the heartbeat of the portal. You can then assign the corresponding alert via Other CCMS Monitors to business process step running on the portal system. 1.7.4.9

Analysis and monitoring tools

It is possible to specify analysis transactions or URL addresses (including file directories) per monitoring object. In case of analysis transactions these should be used to analyze errors or problems either locally in SAP Solution Manager system (Call Option “1”) or directly in the respective satellite systems (Call Option “2”). Per default some standard transactions are maintained. For instance, transaction SM37, that provides a job overview in an SAP system, is maintained for background jobs, and transaction SLG1, which is used to have a look into the application log. It is also possible to add new transactions. These can be standard transactions or transactions written by the customer.

© 2009 SAP AG

page 15/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Figure 9: Analysis and monitoring transactions

On the second tab, you can specify an URL that should be called in order to further analyze the given problem. This is especially interesting if you have knowledge documents that are linked to a portal. You can define a short text and the URL. For Web pages to be called, specify the full URL, e.g. http://help.sap.com. For content available on file servers specify the full file path, using the nomenclature: file://\\\\..., for instance, file://\\\server1\operations_documents\operations-handbook.txt

Figure 10: Analysis and monitoring URL

When using the monitoring during a Business Process Monitoring session, the specified transactions or URLs are available as buttons within a business process step. When you press these buttons, for instance , you jump directly into the corresponding transaction, either in SAP Solution Manager (here: SAT) or the connected satellite system (here: CT1), for further analysis. In case of URLs, the button (e.g.

) contains the short text (limited to 20 characters)

from the setup session and opens the defined URL in a new browser window.

© 2009 SAP AG

page 16/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

1.7.4.10

Monitoring activities

Monitoring activities should be set up for every monitoring object within a business process step. All monitoring objects defined within a business process step are listed there. To ensure effective monitoring and efficient problem resolution, assign responsibilities and define problem resolution procedures as described in the following table. Some information has been taken from the previous Solution Support Organization node. Monitoring Team

Defines the team that is responsible for monitoring the relevant monitoring object. Use value help F4.

Person Resp.

Defines the person who is responsible for monitoring the monitoring object. Use value help F4.

Frequency

Describes how often the responsible person should process the required monitoring activity.

Start Time

Describes at which time the responsible person should process the required monitoring activity.

Problem Indicator

A description about what indicates a problem.

Error Handling

Describes how to react on problems or errors, i.e. how to solve the problem or correct the error.

Escalation Path

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

You can enter additional information related to this business process step in the tables Monitoring Activities, Error Handling, Restart of Step and Escalation Path. That information is valid for the whole business process step and helps users who have to carry out the monitoring and who are not familiar with that particular business process. 1.7.4.11

Notifications

You can set up notifications for the whole business process or for each business process step individually. There are two types of notifications: Workflow notifications and support notifications. Workflow notifications allow sending messages to a specified recipient in case of alerts, for instance, an e-mail or SAPOffice mail. Support notifications allow setting up a service desk message in case of an alert. The information entered for the service desk message serves as a template. The service desk message can be created manually or automatically. On business process level, you can define notifications for the whole business process, i.e. as soon as the business process gets an alert status, notifications will be triggered. Alternatively, notifications can be defined for every monitoring type individually, e.g. all alerts related to background jobs of the business process are forwarded to a defined e-mail address. Notifications defined on business process step level will overrule the configuration made on business process level for this particular step.

© 2009 SAP AG

page 17/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Workflow notification Sender

Must be a user within in the monitoring client of SAP Solution Manager. This user can even be a system user without any roles or profiles, but the user must have a valid e-mail address which the used mail server knows.

Recipient Address

Depending on the recipient type, the recipient name is required. This can be any email address, an SAP user name in the same system, a remote SAP name or a shared distribution list. In case of an SMS you need to enter “SMS:”.

Reci. Type

There are currently five different recipient types: U (e-mail), K (for SMS and pager), B (SAP user name), R (remote SAP name) and C (shared distribution list).

No. of Yellow Alerts

Number of YELLOW alerts that can occur before an automatic notification is triggered

No. of Red Alerts

Number of RED alerts that can occur before an automatic notification is triggered

Max Wait Time [h]

Once the maximum wait time [hours] has elapsed, a notification is created even if the thresholds are not exceeded.

RED Only

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

Detailed

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

Support notifications Priority

Defines the priority of the support notification.

Queue

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

Processor

Defines a default processor who should process the message. The processor must be known within the service desk and must be SAP user name defined as a business partner with role employee.

Text Template

Text templates can be defined that will then be available for service desk messages manually created for alerts.

Automatic

Support notifications will be created automatically depending on the alert thresholds.

Reporter

Necessary if service desk messages are created automatically. Must be a SAP user name defined as a business partner with role general.

Num of YELLOW Alerts

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

Num of RED Alerts

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

© 2009 SAP AG

page 18/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

If in addition to Queue, Processor, Priority and Reporter either one of the columns Num of YELLOW Alerts or Num of RED Alerts is filled with a value, the automatic support notification creation is configured. In case that both columns are filled with a value, the automatic support notification creation works with a logical OR operation. Hence, with the figures in the table above the system would create a support notification if there are either more than nine yellow alerts or more than four red alerts for which no support notification has been created yet. 1.7.5

Business Process Monitoring process

For a successful and efficient Business Process Monitoring, you have to define a process for implementing your monitoring concept. This includes the definition of the roles and responsibilities involved. You need to define who is supposed to carry out which activity within the process, and how communication between the different roles within the support organization is supposed to take place. A Business Process Monitoring concept has to be tightly integrated with the support organization. This includes the integration with the Incident- and Problem Management processes and the Change Management process. These processes have to be adjusted to the Business Process Monitoring concept so that communication and escalation procedures defined within these processes support the Business Process Monitoring concept. This includes the final communication of open alerts to SAP. Wherever communication connected with Business Process Monitoring happens outside these support processes, separate communication and escalation paths and procedures have to be defined. Please see the separate Best Practice for General Business Process Management for further details. 1.7.6

Legend This symbol indicates a paragraph from where you can navigate to another chapter of this document for more detailed information on a topic. This symbol indicates a paragraph from where you can navigate to another document within the SAP Service Marketplace for more detailed information on a topic.

© 2009 SAP AG

page 19/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

2

Business Process Monitoring for ERP Replenishment

This chapter will show you how business process monitoring for an SAP for Retail system can look like. It will introduce you to the process ERP Replenishment as one of the most critical retail processes. It provide some generic thoughts and ideas on how to identify the business process steps you need to keep an eye on and makes you familiar with how to choose the most promising monitoring possibilities from the available ones. We will take you step by step through this core business process, explaining where and how you can identify focus points for Business Process Monitoring. For each business process step, the most effective ways for Business Process Monitoring in the context of the example are highlighted. To make this most visible to you, we provide a sample process of a fictional company.

2.1

Sample Scenario

Grocery Food Inc. is a midsize company in grocery retailing. Spread over two European countries, Grocery Food Inc has a total of 400 stores. The size of the stores differs from larger supermarkets to small corner shops organized in two distribution chains. Grocery Food Inc. decided to implement SAP for Retail in order to manage the retail processes. The daily business of Grocery Food Inc. is to sell food and non-food products and to replenish the stores through three warehouses spread across the country as well as per direct vendor delivery. The range of products sold in the stores and the layout of the stores have been optimized according to the size categories of the stores. A point-of-sales (POS) solution records the sales activities during the day and sends the data to a central SAP for Retail system. Based on these consumption values, the updated stock levels in the store and potentially forecast values, the system calculates the required amount of articles to be sent to the retail outlets before the stores open on the next morning.

© 2009 SAP AG

page 20/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

2.2

Business Process ERP Replenishment

Figure 11 shows the typical store replenishment process. The process begins with the POS Inbound process in which sales data collected at a POS is transferred to the central system and processed, and stock levels are updated. Based on the changes in stock levels, on calculated forecast data and on parameters like minimum stock levels, the replenishment is carried out.

Figure 11: ERP replenishment – Process flow

The replenishment run results in the creation of purchase requisitions and/or purchase orders. These documents then contain the articles and the quantities that are required in the stores. Based on purchasingand replenishment configuration the system decides, based on the supply source determination, whether these items are ordered at the warehouse or whether the orders need to be sent to external vendors. In the case of purchase requisitions resulting from the replenishment run, these have to be converted to purchase orders with the help of a background program. In order to trigger the delivery to the stores from the warehouses, outbound deliveries are created. If lean warehouse management is used, transport orders are created in order to pick the goods and move them to the shipping points within the warehouse(s). These picking requests are then confirmed with the exact quantities. When the goods leave the warehouse(s), warehouse goods issues have to be posted in order to update the inventories at the warehouse(s) and to update the statuses of the orders and deliveries. When the goods arrive at the stores, store goods receipts are posted to update the store inventories.

© 2009 SAP AG

page 21/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Alternative practices exist, where the warehouses processes are not managed within the SAP ECC system, but in a separate warehouse management system. These scenarios involve the SAP EWM solution, a separate SAP system as separate warehouse management system, or a third-party warehouse management system. In these cases, the deliveries are usually replicated to a separate system via IDocs, using RFC techniques or a Web service integration. Once the external warehouse management system has finished the processes required to ship the required goods, the deliveries in the SAP ECC system are updated with the actual quantities, and the goods issues are posted. 2.2.1

Business process steps 1 to 5: POS inbound

2.2.1.1

Description

Today’s best practice is to upload sales data to a POS DM solution. Within this solution, the POS data is validated with the help of configured rules and integrated master data. Through a flexible infrastructure the consolidated data is then transferred to follow-on systems according to their requirements. In POS DM different tasks are defined to create payment type IDocs (message type WPUTAB), financial IDocs (message type WPUFIB), and aggregated sales IDocs (message type WPUUMS) or non-aggregated IDocs (message type WPUBON) to treat special cases. These IDocs are generated at the end of the business day when the stores are closed and all data have been sent to POS DM. When the IDocs are created, they are sent across to ERP for further processing. Once received the IDocs are posted to SAP for Retail using the IDoc dispatcher. These process steps are covered in the Best Practice for SAP for Retail document for POS inbound. You can find this document at http://service.sap.com/solutionmanagerbp. 2.2.2

Business process step 6: Execute store forecast

2.2.2.1

Description

With the help of the forecast run, the system calculates the projected requirements for the next period(s), based on configured rules for an article/site combination. The available forecast types range from constant models where a future consumption is projected based on the average historical consumption of an article, to seasonal models where the future consumption is calculated based on the average sales values from the previous year or season. A forecast is usually executed on a weekly basis during the weekend. Scenario-specific sample Grocery Food Inc. runs a forecast every Sunday evening for most of their articles. For food articles, like yoghurts, milk and meat, they chose a constant model; for non-food articles they use a seasonal model for special assortments and a constant model for every-day assortments. 2.2.2.2

Monitoring requirements

Error monitoring As the forecast runs usually on a weekday, when the usual night window processing is not carried out, the runtime is not as critical as for other days. Nevertheless it is important that the forecast run is completed before the users log on to the system and before the next replenishment run is carried out.

© 2009 SAP AG

page 22/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

In order to accelerate the forecast execution, the program RMPROG01 is usually executed with several instances in parallel, where for each instance a disjoint set of stores is configured. In order to keep the runtime within the allowed time frame, you need to balance the work packages as equally as possible. Therefore the runtime of the individual jobs needs to be compared to the average runtime of the jobs to identify the bottlenecks on the critical path. Errors detected during the forecast run are logged, and the articles for errors occurred are marked for problem resolution processing. Then you can subsequently process these retained articles with transaction MP33. Scenario specific sample Grocery Food Inc. executes the forecast on an afternoon after their weekly downtime on Sunday morning. The forecast runs need to finish before 4 a.m. on Monday morning. In order to automate this step, a dynamic load balancing tool has been implemented by SAP Consulting. The load balancing tool distributes the workload in small packages and controls the execution of the jobs. The workload is restricted by a configured maximum number of jobs carried out in parallel. Performance monitoring The forecast execution runtime depends on the package size processed, the number of article/site combinations to be processed and the available hardware. In order to check and potentially optimize the performance of the forecast run, you have to carry out a performance test prior to the go-live. Once the forecast is executed on a regular basis in a productive environment, you need to track the runtime and, in the event of an increase of the runtime, alert the application team. This way, you can repeat a performance test and analysis and identify improvement potentials. Throughput monitoring In order to assure that the runtime is as short as possible, you need to equally balance the workload. Therefore, you should monitor the runtime distribution over the involved job instances. Backlog monitoring For the forecast process step, backlog monitoring does not apply. 2.2.2.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Job runtime

Program RMPROG01 / transaction MPBT

Start delay, maximum duration exceeded, overall runtime

SM37

During/after weekly job execution

Job status

Program RMPROG01

Job canceled

SM37

During and after weekly job execution

© 2009 SAP AG

page 23/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Articles with errors during the forecast run

Plants to be reprocessed

If articles are shown after the selection, errors occurred

MP33

After weekly job execution

Job log

Job with program RMPROG01

Errors contained in the job log

SM37

After weekly job execution

Spool list

Job with program RMPROG01

Errors contained in the spool list

SM37

After weekly job execution

Table 1: Business process step 6 – Monitoring objects in SAP Solution Manager

2.2.2.4

How to find meaningful thresholds per monitoring object

The maximum runtime and the maximum of allowed delay depend on the project implementation and the allowed time frame. These thresholds therefore need to be defined in the project. 2.2.2.5

Error handling per monitoring object

Errors or exceptional situations that occur during the total forecast are recorded in the exception messages and are allocated to a certain error class. If an error occurs in a material forecast, then the system marks the material for which the error occurs for reprocessing. Check transaction MP33 for problem resolution.

Figure 12: Business process step 6 – Error handling per monitoring object

© 2009 SAP AG

page 24/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

The faulty articles are shown. Within this transaction, you can get more detailed information about the errors occurred. 2.2.2.6

Scheduling of background jobs

As described above, in order to accelerate the forecast execution, the program RMPROG01 is usually executed with several instances in parallel, where for each instance a disjoint set of stores is configured. Recommended or Generated Job Name

ABAP Report

Variant

Scheduling

S_DE_R_R MPROG01_ W_xxxx

RMPROG01

STORE _xxxx

Weekly

Predecessor Job

Successor Job

Scheduling Restriction

Replenishm ent

After POS Inbound

Error Handling in Case of Cancellation

Table 2: Business process step 6 – Job scheduling requirements

2.2.3

Business process step 7: Execute retail replenishment

2.2.3.1

Description

Replenishment can be considered as the main process of the process chain. It is in this step where the requirements are turned into order information based on the forecasted requirements and the current stock information considering planned goods issues and goods receipts. The replenishment consists of two main steps Requirements calculation Creation of follow-on documents In general, transaction WRP1 (program RWRPLPRO) is used for replenishment, the type of follow-on document generated by this process depends on the customizing of the Store Order. Depending on the process and its customizing settings, purchase requisitions and/or purchase orders result from the replenishment run. If purchase requisitions are generated, the additional program RM06B20 is used to turn the purchase requisitions into purchase orders. Scenario-specific sample Grocery Food Inc. runs replenishment every night after the POS inbound for every article where a relevant stock movement has happened using the netchange flag in the variant. They create purchase requisitions as they want to use the regrouping capabilities and to execute the source of supply determination in a separate step. The purchasing department has time until noon to check the created purchase requisition before they are turned into purchase orders by a background process.

© 2009 SAP AG

page 25/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

2.2.3.2

Monitoring requirements

Error monitoring If the job fails, the replenishment of sold articles is not carried out. This may result in out-of-stock situations and lost sales. The root cause of an error needs to be analyzed in order prevent the error from reoccurring. Performance monitoring The runtime of the replenishment run is critical and needs to fit into the available time frame. A delay in the process completion might result in a delay in the follow-on processes and cut-off times in the distribution center are missed. Throughput monitoring The overall runtime of the job is important. The number of documents created and the number of processed articles might be an indicator to predict runtimes on days with exceptionally high data volumes. Backlog monitoring No backlog monitoring applies to this process step. 2.2.3.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Job runtime

RWRPLPRO

Start delay, maximum duration

SM37

Every 5 minutes during every job execution

Job status

RWRPLPRO

Job status

SM37

Every 5 minutes during every job execution

Job log

Job for program RWRPLPRO

Job status

SM37

After job execution

Transaction SE16 on table WRPT

Prior to job execution

After completion of the job

Number or articles to be processed Number of documents/line items created

Job step user, creation date, document type

Significant reduction in number of resulting documents

Transaction SE16 on tables EBAN or EKKO/EKPO

Errors and warnings in replenishment monitor

Date and store

Errors displayed in the monitor

WRMO or table WRPE

Table 3: Business process step 7 – Monitoring objects in SAP Solution Manager

© 2009 SAP AG

page 26/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

2.2.3.4

How to find meaningful thresholds per monitoring object

The runtime of the job is usually time-critical. The throughput should be regularly calculated and corrective measures need to be taken if a decrease in the throughput is detected. The threshold values depend on the available time frame and the document volume to be processed. 2.2.3.5

Error handling per monitoring object

When using WRMO, enter the date(s) and the store(s) to be checked and press the Execute button.

Figure 13: Business process step 7 – Error handling per monitoring object 1

The system will display a list of all articles for which errors occurred during the replenishment run via transaction WRP1.

Figure 14: Business process step 7 – Error handling per monitoring object 2

2.2.3.6

Scheduling of background jobs

As described above, in order to accelerate the replenishment execution, the program RWRPLPRO is usually executed with several instances in parallel, where for each instance a disjoint set of stores is configured. In order to increase the throughput of the processing, the operation modes are usually set up to increase the number of batch processes available during the night processing.

© 2009 SAP AG

page 27/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Recommended or Generated Job Name

ABAP Report

Variant

Scheduling

Predecessor Job

S_DE_R_ RWRPLPR O_D_xxxx

RWRPLPRO

STORE_ xxxx

Daily

Forecast

S_DE_R_R M06BB20

RM06BB20

STORE_ xxxx

Daily

S_DE_R_ RWRPLPR O_D_xxxx

Successor Job

Scheduling Restriction

Error Handling in Case of Cancellation

After POS Inbound

Table 4: Business process step 7 – Job scheduling requirements

2.2.4

Business process step 8: Create outbound deliveries

2.2.4.1

Description

While purchase orders (vendor orders) are fulfilled by external orders, stock transfer orders are fulfilled by the retailer’s warehouse(s). In order to initiate the goods distribution process, use transaction VL10BATCH to create outbound deliveries with reference to the stock transfer orders. The transaction selects orders with an assigned requirement date from the delivery due list, and generates the deliveries for the assigned warehouse(s). Scenario-specific sample After having created all required stock transfer orders, deliveries are created in order to trigger the goods distribution from the warehouse to the stores. 2.2.4.2

Monitoring requirements

Error monitoring This process step is executed as part of the critical time frame. Errors need to be handled immediately. Use the delivery monitor accessible through transaction V_SA and WF80_DEL to analyze errors in processing. Performance monitoring The runtime of the job needs to fit into the available time frame. This program is enabled for parallel processing. Depending on the amount of data to be processed, parallel processing must be configured with a sufficient number of parallel processes. In order to guarantee the availability of required dialog processes during the day, a dedicated dialog instance might be configured for parallel processes during the day. Throughput monitoring The number of deliveries created during processing indicates the current throughput. A decrease in throughput will lead to an increasing runtime, especially on days with a high data volume.

© 2009 SAP AG

page 28/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Backlog monitoring After processing, in most cases no deliveries due for the current day should exist. Use the delivery due list tables (VEPVG for sales orders, VETVG for purchase and stock transfer orders) to analyzed this. Depending on the process setup and the number of delivery runs executed during the day, it can be normal that documents due for delivery exist. In this case a valid logic for backlog monitoring will be more complex to create. 2.2.4.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency / Data Collection

Job runtime

RVV50R10C

Start delay, maximum duration

SM37

Every 5 minutes during every job execution

Job status

RVV50R10C

Job canceled

Delivery monitor

Current date, job step user

Many documents in error

After job execution V_SA, WF80_DEL

After job execution

Table 5: Business process step 8 – Monitoring objects in SAP Solution Manager

2.2.4.4

How to find meaningful thresholds per monitoring object

The number of errors resulting from the monitor should be monitored. Note that depending on the realized process, errors during delivery creation might be part of the process and do not need to be escalated. If, for instance, the warehouse receives goods various times during the day and delivery creation runs are executed several times per day, it can be normal that deliveries are not created in the first run but in one of the next executions. 2.2.4.5

Error handling per monitoring object

In order to check the collective processing logs, call transaction VL10B and press the Collective Processing Logs button, or use transaction V_SA (program SDSAMPRO) directly.

Figure 15: Business process step 8 – Check the collective processing logs

© 2009 SAP AG

page 29/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

In the following selection screen, you can define restrictions for users and dates.

Figure 16: Business process step 8 – Define restrictions for users and dates

The system lists the output for each user and date, and group number.

Figure 17: Business process step 8 – Display runs

To display the details, click on the line item and press the Notes button.

© 2009 SAP AG

page 30/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

The system will then show the error and warnings which occurred during the creation of outbound deliveries.

Figure 18: Business process step 8 – Display errors and warnings

2.2.4.6

Scheduling of background jobs

The delivery creation is usually run as a job with parallel processing configured. The job has to be executed after the follow-on documents from replenishment have been released. Make sure that sufficient dialog processes exist. Recommended or Generated Job Name

ABAP Report

Variant

Scheduling

Predecessor Job

S_DE_R_R VV50R10C _D

RVV50R10 C

ALL_DAY

Daily

Replenishment and follow-on documents

Successor Job

Scheduling Restriction

Error Handling in Case of Cancellation

Table 6: Business process step 8 – Job scheduling requirements

2.2.5

Business process step 9: Carry out warehouse processing

2.2.5.1

Description

There are several ways to carry out warehouse processing with SAP for Retail: With EWM, the extended warehouse management solution With a third-party warehouse management solution With Lean WM inside SAP for Retail With LES-WM implemented on SAP for Retail or as a satellite system For all process variants where the core warehouse processes are executed on a separate system, the interface is more or less the same. Within SAP for Retail, outbound deliveries are created as explained in the preceding chapter. These deliveries are then replicated to an external system, where the logistic processes are carried out. Once they are finished, the deliveries are confirmed in the WM system and confirmed to the SAP for Retail system where the delivered quantities are updated. Based on these updates, the goods issues in the DC are posted. This process flow is shown in Figure 19.

© 2009 SAP AG

page 31/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Figure 19: Business process step 9 – Process flow

2.2.5.2

Monitoring requirements

The monitoring requirements and the adequate monitoring tool vary depending on the warehouse management solution chosen. For the examples given above, the monitoring requirements are as follows. For EWM, the extended warehouse management solution Deliveries are replicated based on changes using the ALE distribution model. Between SAP for Retail and the EWM solution, qRFCs are used to replicate the deliveries. From SAP for Retail to EWM, the function module to do this replication is called “/SCWM/OUTB_DLV_SAVEREPLICA”. In order to confirm quantities from the distributed delivery, use the function module BAPI_OUTB_DELIVERY_CONFIRM_DECENTRAL. For monitoring queues, use transaction SMQ1/2. For details, refer to the Interface Monitoring with SAP Solution Manger guide available at http://service.sap.com/bpm. Also, the usual backlog and performance monitoring requirements are described there. For the monitoring of the EWM processes, a dedicated document will be made available under http://service.sap.com/solutionmanagerbp. For third-party decentralized warehouse management solution Deliveries are usually replicated using IDocs. Between SAP for Retail and the warehouse management system, the SHP_OBDLV_SAVE_REPLICA05 iDoc is used. Deliveries are confirmed with the IDoc SHP_OBDLV_CONFIRM_DECENTRAL04. For this process variant, the IDoc status needs to be followed.

© 2009 SAP AG

page 32/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

With other third-party warehouse management solution Deliveries can also be replicated using DELVRY05 IDocs. From SAP for Retail to the warehouse management system, IDoc DELVRY05 is used to send the delivery details. Deliveries are then processed by the external WM solution and changes to the deliveries are again confirmed with IDoc DELVRY05 as an inbound IDoc. For this process variant, the IDoc statuses need to be followed. For Lean WM inside SAP for Retail The monitoring requirements are listed in the following chapters. For LES-WM implemented on SAP for Retail or as a satellite system If LES-WM is implemented on SAP for Retail, the process steps and the monitoring tools of the Lean WM scenario apply. For the usage of a satellite system, the monitoring requirements equal those of a third-party connection. 2.2.5.3

Create transport orders

When using Lean WM, stock transport orders are created with reference to the outbound deliveries using transaction VL06P (program WS_MONITOR_OUTB_DEL_PICK). Scenario-specific sample In order to initiate the goods issue processing, stock transport orders are created for the deliveries created in the previous step. 2.2.5.4

Monitoring requirements

Error monitoring After this process step, all deliveries due for picking should be updated with a current status (see below). Performance monitoring Depending on the amount of data to be processed and the time frame restrictions, the processing needs to finish within a given time frame. Throughput monitoring The throughput needs to respond to the time frame restrictions. You can analyze the amount of data to be processed by selecting deliveries due for picking. Backlog monitoring The amount of deliveries still due for picking after the job has been executed indicates a backlog.

© 2009 SAP AG

page 33/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

2.2.5.5

Monitoring objects

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency / Data Collection

Job runtime

S_DE_R_WS_OUTB_DEL_PICK _D_DEL1

Start delay, maximum duration

SM37

Every 5 minutes during every job execution

Job status

S_DE_R_WS_OUTB_DEL_PICK _D_DEL1

Job cancelation

SM37

Table 7: Business process step 9 – Monitoring objects

2.2.5.6

How to find meaningful thresholds per monitoring object

The thresholds for throughput and processing time depend on the project requirements. 2.2.5.7

Error handling per monitoring object

When it comes to monitoring the results, you can check the line items of the outbound deliveries.

Figure 20: Business process step 9 – Error handling per monitoring object 1

© 2009 SAP AG

page 34/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

If the business process requires that transport orders are created, then the WM status field in the delivery line item is set to A when a corresponding transport order line item is generated. If the business process does not require transport orders to be generated, the WM status field is blank.

Figure 21: Business process step 9 – Error handling per monitoring object 2

The WM status field has four different possible values: : not relevant A: Not yet processed B: Partially processed C: Completely processed However, the Pick.stat field is always updated, regardless of whether transport orders are compulsory or not. The four possible values of this field are: : not relevant A: Not yet processed B: Partially processed C: Completely processed

© 2009 SAP AG

page 35/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Due to the high volumes normally involved, checking the status of each delivery line item individually is not practical. In this case, you can check table VBUP. Whenever a transport order for an outbound delivery is created for warehouse management, the field LVSTA has the value A. Similarly, the field VBUP-KOSTA for the pick status is updated whenever the goods have been picked and moved to the shipping point. In addition to the status in table VBUP, you can use transaction SLG1 (program SBAL_DISPLAY) to check application logs for possible entries. 2.2.5.8

Scheduling of background jobs

Note that VL06P has no built-in parallel processing option. If parallel processing is required, you need a custom program to pre-select the deliveries due for picking, use the delivery document numbers to populate variants of VL06P dynamically and to kick off parallel batch jobs. Recommended or Generated Job Name

ABAP Report

Variant

Scheduling

Predecessor Job

S_DE_R_ WS_DEL_PI CK _D_DEL1

WS_MONIT OR_OUTB_ DEL_PICK

DelRang e_01

Daily

S_DE_R _RVV50 R10C_D

Successor Job

Scheduling Restriction

Error Handling in Case of Cancellation

Table 8: Business process step 9 – Job scheduling requirements

2.2.6

Business process step 10: Post goods issues in warehouse

2.2.6.1

Description

When the goods leave the warehouse, warehouse goods issues are posted in order to update the inventory at the warehouse and to update the status of the outbound deliveries and the preceding stock transfer orders. The posting of warehouse goods issues is done with transaction VL06G. Depending on the definition of the business process, the goods issues can also be done via IDocs. Unlike the posting of warehouse goods issues via IDocs using program RBDAPP01, report WS_MONITOR_OUTB_DEL_GDSI does not have a built-in parallel processing option. In order to run warehouse goods issues in parallel with this program, you need to create a custom program to pre-select the deliveries, populate variants with the delivery numbers and spawn parallel batch processes. 2.2.6.2

Monitoring requirements

Error monitoring To monitor the results of the warehouse goods issues, you have to access table VBUP. If the status of a goods movement for a line item is completed, the WBSTA field has status C. The field FKSTA is only relevant if billing is involved. The field GBSTA is the overall status of the delivery. If this field is set to C for a particular delivery, it means that the delivery is completed and no further processing is possible.

© 2009 SAP AG

page 36/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Performance monitoring The runtime of the job needs to fit into the available time frame. The runtime should therefore be monitored and the runtime evolution over time tracked. Throughput monitoring You can determine the throughput based on the amount of deliveries due for goods issue and the runtime of the job(s). Backlog monitoring The number of deliveries still due for goods issue indicates a backlog. 2.2.6.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency / Data Collection

Job runtime

S_DE_R_WS_OUTB_DEL_GDSI _D_xxxx

Start delay, maximum duration

SM37

Every 5 minutes during every job execution

Job status

S_DE_R_WS_OUTB_DEL_GDSI _D_xxxx

Table 9: Business process step 10 –Monitoring objects in SAP Solution Manager

2.2.6.4

How to find meaningful thresholds per monitoring object

The number of open deliveries can indicate a problem in processing. You should monitor the number and take corrective measures if the number exceeds a certain reasonable limit. 2.2.6.5

Error handling per monitoring object

To monitor the results of the warehouse goods issues, you have to access table VBUP.

Figure 22: Business process step 10 – Error handling per monitoring object

If the status of a goods movement for a line item is completed, the WBSTA field has status C. The field FKSTA is only relevant if billing is involved. The field GBSTA is the overall status of the delivery. If this field is set to C for a particular delivery, it means that the delivery is completed and no further processing is possible.

© 2009 SAP AG

page 37/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

2.2.6.6

Scheduling of background jobs

In order to accelerate the job execution, the program WS_ MONITOR_OUTB_DEL_GDSI is usually executed with several instances in parallel, where for each instance a disjoint set of deliveries is configured. Recommended or Generated Job Name

ABAP Report

Variant

Scheduling

S_DE_R_

WS_MONIT OR_OUTB_ DEL_GDSI

STORE _xxxx

Daily

WS_OUTB_DE L_GDSI _D_xxxx

Predecessor Job

Successor Job

Scheduling Restriction

Error Handling in Case of Cancellation

After POS Inbound

Table 10: Business process step 10 – Job scheduling requirements

2.2.7

Business process step 11: Post goods receipts in stores

2.2.7.1

Description

When the goods arrive at the stores, store goods receipts are posted. Store goods receipts can be carried out via transaction MIGO. Depending on the business process, goods receipts can also be posted via IDocs, using program RBDAPP01. These IDocs are sent from the stores after the goods receipts took place. Scenario-specific sample When the goods arrive in the early morning hours in the stores, the delivery documents are scanned and the contained article quantities approved. In this process, the goods receipts in the stores are posted. 2.2.7.2

Monitoring requirements

Error monitoring Errors in the processing have to be corrected. Otherwise, the stock levels are incorrect. When IDocs are used to execute the goods entry posting, you can monitor the IDoc status. To monitor the results of the store goods receipts, you can use transaction SLG1 to check for possible entries in the application log tables. Further checks can be done in the purchase order line items. There, if the goods have been completely delivered, the Delivery Completed Indicator should be set. However, due to the large number of line items, it is not practical to check the line items of each purchase order on an individual basis. You can check the purchase order line item table EKPO. There, the field ELIKZ should be set to X for all line items that were fully delivered. Performance monitoring The runtime of the transaction is critical as the users might have to wait for the posting to be finished. Throughput monitoring Maximum allowed response time in transaction processing.

© 2009 SAP AG

page 38/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Backlog monitoring Unprocessed IDocs in status 64 should be processed in a reasonable response time. If several IDocs remain unprocessed, you need to analyze the situation. 2.2.7.3

Monitoring objects in SAP Solution Manager

Monitoring Object

Selection Criteria

Alert

Analysis Tool on Satellite System

Monitoring Frequency/ Data Collection

Job runtime

RBDAPP01 for IDoc processing, SAPMM07M for the goods entry posting

Start delay, maximum duration

SM37

Every 5 minutes during every job execution

Job status

RBDAPP01 for IDoc processing

SM37

After job execution

IDoc status

WPUWBW or MBGMCR IDocs

Idocs in error

WE05

After job execution

POS IDocs in error

WPUWBW

IDocs in error

WPER

After job execution

Table 11: Business process step 10 – Monitoring objects in SAP Solution Manager

2.2.7.4

How to find meaningful thresholds per monitoring object

The maximum duration depends on the available processing time and the document volume to be processed. 2.2.7.5

Error handling per monitoring object

Check job log for cancellations. 2.2.7.6

Scheduling of background jobs

RBDAPP01 is enabled for parallel processing. Recommended or Generated Job Name

ABAP Report

Variant

Scheduling

S_DE_R_R BDAPP01_ W_xxxx

RBDAPP01

STORE _xxxx

Daily or several times a day

Predecessor Job

Successor Job

Scheduling Restriction

Error Handling in Case of Cancellation

Table 12: Business process step 10 – Job scheduling requirements

© 2009 SAP AG

page 39/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

3

Further Information

3.1

Related Best Practice Documents

There are several other Best Practice documents that relate to this Best Practice document. They are available on SAP Service Marketplace at https://service.sap.com/solutionmanagerbp. These documents are: Best Practice General Business Process Management: This document explains the procedures you should use to create a general Business Process Management concept. This includes the definition and documentation of the core business processes, definition of monitoring objects, definition of monitoring activities including error handling procedures, monitoring tools, monitoring frequencies, the definition of communication and escalation procedures and the assignment of responsibilities. ALE Monitoring: This Best Practice helps you set up an Interface Monitoring concept with the focus on ALE monitoring for your SAP solution. This document will outline possibilities on how to optimally monitor ALE-based interfaces manually as well as automated by using SAP Solution Manager. Both monitoring approaches aim to detect any irregularities or deviations or to detect error situations at an early stage. Job Scheduling Management: This Best Practice provides a detailed description of what SAP recommends as a standardized formal process to support a job request process, including an end user job request form and an approval process. This integrated process will avoid error-prone and time-intensive manual processes of copying redundant data from one data source to another (for example, MS Excel to job scheduling tool). SAP Business Process Management for ERP Logistics: This Best Practice helps you set up a Business Process Monitoring concept for your SAP ERP solution. The concept aims at defining procedures for business process-oriented monitoring and error handling and escalation procedures for your company’s ERP core business processes. These procedures intend to ensure a smooth and reliable flow of the core business processes so that your business requirements are met. Background Job Monitoring with SAP Solution Manager: This Best Practice will help you to set up background job monitoring properly in the Business Process Monitoring framework of SAP Solution Manager. Please note that these documents are also available in the SAP Service Marketplace using alias RunSAP Run SAP Best Practices.

3.2

Background Information and References

For more details on monitoring of heterogeneous landscape scenarios, please refer to the Interface Monitoring with SAP Solution Manager guide available at http://service.sap.com/bpm.

© 2009 SAP AG

page 40/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

Index of Figures Figure 1: Alert type Number of ABAP Dumps (Delta) Figure 2: Monitoring objects – Dialog performance Figure 3: Monitoring alerts – Dialog performance Figure 4: Monitoring objects – Update errors Figure 5: Monitoring objects – Due list log Figure 6: Monitoring objects – Application log Figure 7: Monitoring alerts – Application log/critical messages Figure 8: Other CCMS monitors Figure 9: Analysis and monitoring transactions Figure 10: Analysis and monitoring URL Figure 11: ERP replenishment – Process flow Figure 12: Business process step 6 – Error handling per monitoring object Figure 13: Business process step 7 – Error handling per monitoring object 1 Figure 14: Business process step 7 – Error handling per monitoring object 2 Figure 15: Business process step 8 – Check the collective processing logs Figure 16: Business process step 8 – Define restrictions for users and dates Figure 17: Business process step 8 – Display runs Figure 18: Business process step 8 – Display errors and warnings Figure 19: Business process step 9 – Process flow Figure 20: Business process step 9 – Error handling per monitoring object 1 Figure 21: Business process step 9 – Error handling per monitoring object 2 Figure 22: Business process step 10 – Error handling per monitoring object

9 10 11 12 13 14 14 15 16 16 21 24 27 27 29 30 30 31 32 34 35 37

Index of Tables Table 1: Business process step 6 – Monitoring objects in SAP Solution Manager Table 2: Business process step 6 – Job scheduling requirements Table 3: Business process step 7 – Monitoring objects in SAP Solution Manager Table 4: Business process step 7 – Job scheduling requirements Table 5: Business process step 8 – Monitoring objects in SAP Solution Manager Table 6: Business process step 8 – Job scheduling requirements Table 7: Business process step 9 – Monitoring objects Table 8: Business process step 9 – Job scheduling requirements Table 9: Business process step 10 –Monitoring objects in SAP Solution Manager Table 10: Business process step 10 – Job scheduling requirements Table 11: Business process step 10 – Monitoring objects in SAP Solution Manager Table 12: Business process step 10 – Job scheduling requirements

© 2009 SAP AG

24 25 26 28 29 31 34 36 37 38 39 39

page 41/42

Best Practice for Solution Operations Manage Operations for SAP for Retail ERP Replenishment

© Copyright 2009 SAP AG. All Rights Reserved No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered tradem arks 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 IBM Corporation. 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 Citrix Systems, Inc. HTML, XML, XHTML and W3C are tradem arks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. 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 their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or 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 agreem ent with SAP. This document contains only intended strategies, developments, and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may be 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 the information, 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 noninfringem ent. SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may 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 may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.

© 2009 SAP AG

page 42/42