Manage operations for sap price optimization

1,988 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,988
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
62
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Manage operations for sap price optimization

  1. 1. Best Practice Manage Operations for SAP Price Optimization Dietmar-Hopp-Allee 16 D-69190 Walldorf CS STATUS customer published DATE VERSION Dec-08 2008 3.0 SOLUTION MANAGEMENT PHASE SAP SOLUTION Operations & Continuous Improvement Best Practices for Solution Operations TOPIC AREA SOLUTION MANAGER AREA Application & Integration Management Business Process OperationBP_MO_for_SAP_Price_Optimization_V30.doc – 11.05.2009
  2. 2. Best PracticeManage Operations for SAP Price OptimizationTable of Contents1 Management Summary 3 1.1 Goal of Using this Best Practice 3 1.2 Alternative Practices 3 1.3 Staff and Skills Requirements 3 1.4 System Requirements 4 1.5 Duration and Timing 4 1.6 How to Use this Best Practice 4 1.7 Best Practice Procedure 5 1.7.1 Preliminary tasks 5 1.7.2 Monitoring concepts 5 1.7.3 Business process monitoring in SAP Solution Manager 6 1.7.4 Monitoring types for business process monitoring in SAP Solution Manager 6 1.7.5 Business process monitoring process 19 1.7.6 Legend 192 Business Process Monitoring for Weekly Data Processing 20 2.1 Sample Scenario 20 2.2 Business Process: Weekly Processing 22 2.2.1 Business process step 1: Export master data 22 2.2.2 Business process step 2: Export weekly sales 26 2.2.3 Business process step 3: File transfer 28 2.2.4 Business process step 4: Load weekly data 29 2.2.5 Business process step 5: Data validation 31 2.2.6 Business process step 6: Product linking and data preparation 33 2.3 Business Process: Weekly Modeling 39 2.3.1 Business process step 1: Model 39 2.3.2 Business process step 2: Review and post models 43 2.4 Business Process: Price Optimization 45 2.4.1 Business process step 1: Optimization process 45 2.4.2 Business process step 2: Generate and review forecasts 50 2.5 Business Process: Price File Delivery 52 2.5.1 Business process step 1: Deliver price files 52 2.5.2 Business process step 2: File transfer 543 Further Information 57 3.1 Related Best Practice Documents 57 3.2 Solution Manager Setup Guides 57© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 2/59
  3. 3. Best PracticeManage Operations for SAP Price Optimization1 Management Summary1.1 Goal of Using This Best PracticeThis Best Practice helps you set up a Business Process Monitoring concept for your SAP Price Optimizationsolution. The concept aims to define procedures for business process oriented monitoring and error handlingand escalation procedures for your business process “Optimize Regular Prices”. These procedures intend toensure a smooth and reliable flow of this core business process so your business requirements are met.This Best Practice gives orientation for defining suitable application oriented monitoring objects in order todetect any irregularities or deviations from an ideal business process flow or to detect error situationsconcerning a core business process at an early stage.This Best Practice contains the recommended approach from SAP which uses whenever possible the SAPSolution Manager for the Monitoring functionalities. But even if you do not use the SAP Solution Manager werecommend to follow the procedures described in this document as much as possible in order to ensure asmooth and reliable flow of your business processes as well as an appropriate response in case ofunforeseen errors.1.2 Alternative PracticesYou can have SAP experts deliver this Best Practice remotely or on-site by ordering an SAP SolutionManagement Optimization (SMO) service for SAP Business Process Management (BPM). This service isexclusively available within SAP’s support engagements SAP MaxAttention and SAP Safeguarding. If yourcompany currently does not have any support engagement with SAP, it is also possible to get assistance bySAP experts from SAP Consulting. In this case, please contact your local SAP Consulting representative.1.3 Staff and Skills RequirementsTo implement this Best Practice, you require the following teams:Application Management TeamThis team creates the Business Process Monitoring concept and consists of experts from several areas ofyour company: Business department Solution support organization (for example the Environment Support or the Application Support) Implementation project teamBusiness Process Operations TeamThe Business Process Operations team will be responsible for applying the resulting procedures derived fromimplementing this best practice. They include the following groups: Persons designated to perform business process oriented monitoring and 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 - BP_MO_for_SAP_Price_Optimization_V30.doc page 3/59
  4. 4. Best PracticeManage Operations for SAP Price OptimizationSAP Technology Operations TeamAll 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 ChampionThe Business Process Champion is the person in the business department that is responsible for thesuccessful execution of the business process. He coordinates all activities necessary for the businessprocess. Therefore, he is usually responsible for the escalation paths in case of problems. Often he is asecond level in the escalation procedure, if the application monitoring team needs to escalate an issue.More information about roles and responsibilities of these teams can be found in the super-ordinate BestPractice General Business Process Management, which you can obtain through SAP Solution Manager orthe SAP Service Marketplace under http://service.sap.com/bpm.Necessary or Useful Trainings SM300 Business Process Management and Monitoring E2E300 End-to-end Business Process Integration and Automation Management1.4 System RequirementsIn order to monitor business processes running in your SAP Price Optimization solution via SAP SolutionManager, the SAP Basis Release of the systems to be monitored have to be at least 4.6C.1.5 Duration and TimingDurationCreating a Business Process Monitoring concept could take around one week per business process.Implementing the Business Process Monitoring concept might take approximately an additional week.TimingThe best time to apply this Best Practice is during the planning phase or during the implementation phase ofyour SAP solution.1.6 How to Use This Best PracticeHere you find a brief description of how you should proceed in using this document:Read through the General Business Process Management Best Practice, available on the SAP ServiceMarketplace. This document explains the procedures you should use to create a general Business ProcessManagement concept. This includes the definition and documentation of the core business processes,definition of monitoring objects, definition of monitoring activities including error handling procedures,monitoring tools and monitoring frequencies, the definition of communication and escalation procedures andthe assignment of responsibilities.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 4/59
  5. 5. Best PracticeManage Operations for SAP Price OptimizationAt the beginning of chapter 2 you will find a typical flow chart of the core business process explained in thisBest Practice. It is intended to be used as a guideline for writing down your company specific processdocumentation.In chapter 1.7.4 you find further information that is relevant for more than one scenario. In case informationfrom the generic part is relevant for a specific business process step in one of the scenarios you will find aclear link to the corresponding chapter in the generic part.1.7 Best Practice Procedure1.7.1 Preliminary tasksBefore performing this Best Practice, ensure that you perform the following preliminary tasks or checks in thesystem: Complete all installation and post-installation actions and procedures including customizing Ensure that the initial 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 availability1.7.2 Monitoring conceptsThe monitoring procedures proposed for each business process step are the core of this Best Practice. Themonitoring procedures help you to ensure that the technical processes meet the requirements for stability,performance and completeness. These procedures cover monitoring for the five areas: Error monitoring Performance monitoring Throughput monitoring Backlog monitoring Data Consistency MonitoringFor 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 restartabilityGeneral monitoring activities that are valid for all or most scenarios are described in the generic part inchapter 1.7.4. Recommendations for performance monitoring can also be found in this chapter. Theperformance of the most important steps of your core business processes should be monitored on a regularbasis. The monitoring procedure for performance monitoring of all steps that are executed in an SAP Retailsolution is generally the same. Therefore, you will only find specific performance monitoring recommend-dations on selected business process steps.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 5/59
  6. 6. Best PracticeManage Operations for SAP Price Optimization1.7.3 Business process monitoring in SAP Solution ManagerBusiness process monitoring (BPMon), as part of solution monitoring means the proactive and process-oriented monitoring of the most important or critical business processes including the observation of alltechnical and business application specific functions that are required for a steady and stable flow of thebusiness processes.The core business processes implemented in an SAP Price Optimization system and operated by a companyare of particular importance, and business process monitoring is intended to ensure a smooth and reliableoperation of the business processes and, thereby, that the core business processes meet a company’sbusiness requirements in terms of stability, performance, and completeness.Please note however that SAP Price Optimization solution is not yet fully integrated with the SAP SolutionManager. Some of the monitoring capabilities described in this document are available on SAP NetWeaverABAP systems only and do therefore not apply to SAP Price Optimization.The SAP Solution Manager provides a graphic to visualize a company’s (distributed) system and solutionlandscape and all related business processes. By using business process monitoring, it is possible to defineand customize alert situations from a basic set of configurable alerts provided by the SAP Solution Manager.These alerts are then visualized by green, yellow, and red alert icons for each individual business processstep in the graphical business process representation. Business process monitoring is intended to detect andrespond to critical situations as early as possible in order to solve problems as fast as possible.In addition, the SAP Solution Manager offers extended functionality for error handling and problem resolution.By the definition of contact persons and escalation paths, business process monitoring can be integrated intothe company’s overall strategy for business process management and solution management within theirsolution support organization.In general, a business process monitoring includes the solution-wide observation of: Business process performance (key performance indicators) Background jobs (job scheduling management tasks) Business application logs (such as any error log, general application log, due list logs etc.) Data transfer via interfaces between software components Data consistency Technical infrastructure and components which are required to run the business processes offered by SAP Solution Manager Diagnostics Required periodic monitoring tasksFor further details on business process monitoring please refer to http://service.sap.com/bpm.1.7.4 Monitoring types for business process monitoring in SAP Solution ManagerMonitoring Types are part of the functional scope of business process monitoring as it is available in the SAPSolution Manager. 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)© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 6/59
  7. 7. Best PracticeManage Operations for SAP Price Optimization Due List Log (messages for deliveries and billings) Application Log (messages from the Application Log SLG1) Document Volume (based on table call statistics in ST10) Interface Monitoring Other CCMS Monitor (all alerts that are configured in the CCMS Alert Monitor)Depending on what is executed during a specific business process step the relevant monitoring types mustbe selected. In order to receive detailed information on how to set up the Monitoring Objects in the SAPSolution Manager, please refer to the documentation that is available under http://service.sap.com/bpm.One prerequisite for setting up Business Process and Interface Monitoring in the SAP Solution Manager isthat all business processes and business process steps are maintained in the respective solution thatcontains all affected system components. If you want to learn more about how to set this up, please turn to(URL http://help.sap.com) SAP Solution Manager Basic Settings.1.7.4.1 Application monitorThe Application Monitor is just one of many different Monitoring Types within the Business ProcessMonitoring. The latest Monitoring objects are only provided if the latest ST-A/PI plug-in is installed on thesatellite system. The Service Tool for ST-A/PI is available via the SAP Service Marketplace Quick Link/installations Entry by Application Group -> Plug-Ins SAP Solution Tools ST-A/PI. Please ensure that the most current version of the ST-A/PI is installed on the SAP Solution Manager system and on the respective satellite system. In case of problems refer to SAP Note 915933. The Throughput and Backlog Indicator functionality available as of ST-A/PI 01J* is only working properly with ST-SER 700_2007_1. This is due to changes in the underlying architecture.More detailed information about the different Application Monitor functionalities and a detailed description onhow to define self-written monitoring collectors for the user exit are explained in the documents ‘Setup Guide– Application Monitoring ’ and ‘Setup Guide - User Exit’ respectively (URL http://www.service.sap.com/ AliasBPM Media Library).Throughput and Backlog Indicators (TBIs)As of ST-A/PI 01H a completely new set of Application Monitors has been introduced. While the alreadyestablished monitors are all evaluating specific logs or performance data these new monitors are considering(un-)processed documents in the SAP system and provide so called Throughput and Backlog Indicators.These TBIs should especially provide Automated and early detection of application error situations and backlogs in the core business processes Automated error and backlog analysis toolsFor 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)© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 7/59
  8. 8. Best PracticeManage Operations for SAP Price Optimization 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’(URL http://service.sap.com/bpm Media Library).1.7.4.2 Background jobThe background job monitoring should be part of a Job Scheduling Management concept (go tohttp://service.sap.com/solutionmanagerbp Topic Area “Business Process Operations” to find a BestPractice document ‘Job Scheduling Management’). Because of several restrictions regarding background jobscheduling, e.g. time restrictions, restriction of hardware resources (CPU, main memory, …) or existingdependencies between different activities (e.g. invoices can only be created after the corresponding goodsissue is posted, or Back Order Processing and Material Requirements Planning should not run at the sametime) it is very important to ensure the stable run of background jobs. A cancelled background job should beidentified as soon as possible in order to react as fast as possible. Therefore it is also necessary to definerestart procedures and escalation paths.1.7.4.3 Interface monitoringAn automated interface monitoring enables for a proactive monitoring and alerting of the data exchange. Thefollowing are the important aspects for interface monitoring: Errors: Detection of errors during data exchange or data processing. Backlogs: Detection of growing backlogs in the data processing. Interface performance and throughput: Detection of slow data processing resulting in a decreasing interface throughput.1.7.4.4 Monitoring objectsBefore setting up monitoring the monitoring objects must be clearly defined. A monitoring object is a singlebackground job or a group of background jobs. There are four different possibilities to identify a specialbackground job or a group of background jobs. This information needs to be maintained in the sub-node‘Background Job’ below a business process step.A more detailed description (than provided in this document) on the subject what kind of alerts make sense orwhat kind of alerts are possible are discussed in the Best Practice document Background Job Monitoring withSAP Solution Manager. You can find this document on the SAP Service Marketplace athttp://service.sap.com/solutionmanagerbp Topic Area Business Process Operation.1.7.4.5 ABAP dump collectorTo provide monitoring features for alerting on occurrences of ABAP dumps of specified runtime errors or tocollect statistical data of ABAP dumps for reporting reasons.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 8/59
  9. 9. Best PracticeManage Operations for SAP Price OptimizationMonitoring objectsThe monitoring object is an ABAP runtime error. This runtime error can be specified via the runtime errorname, the user who is responsible for the runtime error, the Client on which the runtime error occurs or theProgram which leads to the runtime error.Monitoring alertsPossible Alert Types are the Number of ABAP Dumps (Delta) – all dumps since the last collector run – andNumber of ABAP Dumps (Reporting) – all runtime errors of specified type, client and program for this day orfor the previous day.Figure 1: Alert types – Number of ABAP Dumps (Delta)1.7.4.6 Dialog performanceDialog Performance implies the monitoring of the dialog transaction performance of any transaction in theSAP System. This could be a standard transaction or an own developed transaction.Monitoring objectsThe monitoring object is the transaction itself. The customizing has to be done in node ‘Dialog Performance’.In table ‘Transactions’ all transactions that are already configured to that business process step are listed.The relevant transactions need to be selected for monitoring. It is also possible to add or to removetransactions within table ‘Add/Remove Transactions’. The monitoring can be performed per SAP instance.Therefore the respective instances have to be selected in table ‘SAP Instances’. All instances that aremaintained for a system are listed there. Table ‘Alert Types’ shows the dialog response time and all parts ofthe response time, like queue time, load and generation time, database request time and the front-endresponse time, that can be monitored. Those times that are relevant for monitoring have to be selected.After saving this node a sub-node ‘Performance Alerts’ will appear where the threshold values have to beentered.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 9/59
  10. 10. Best PracticeManage Operations for SAP Price OptimizationFigure 2: Monitoring objects – Dialog performanceMonitoring alertsEach table in the sub-node ‘Performance Alerts’ corresponds to an alert type chosen in the higher-level nodeand lists the combinations of specified transaction code and SAP instance.For each combination of transaction code and instance that should be included in the monitoring, thethreshold values resulting in alert messages for changes from GREEN to YELLOW, from YELLOW to RED,back from RED to YELLOW, and back from YELLOW to GREEN have to be specified.Since the Monitoring Object for Performance Monitoring is created on the satellite system, it might bepossible that the object already exists there. Therefore you can load the current threshold values from therespective systems via the button "Load thresholds from XYZ", whereas “XYZ” represents the SID.If successfully retrieved for an SAP instance, the values are filled in columns. If no active settings for thethreshold values were found for a certain transaction code, default values are set (indicated in column"Default"). To transfer the threshold values for a single line from right to left, the copy icon can be used. Totransfer all at once (all thresholds for all columns and tables) there is an additional button "Copy all".Figure 3: Monitoring alerts - Dialog performance© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 10/59
  11. 11. Best PracticeManage Operations for SAP Price Optimization1.7.4.7 Update errorsChanges to the data in an SAP system caused by a business process should be written to the database in fullor not at all. If the operation is canceled while the transaction is being executed, or if an error occurs, thetransaction should not make any changes to the database. These activities are handled by the SAP updatesystem.The SAP System makes a distinction between primary, time-critical (V1) and secondary, non-time-critical (V2)update errors. This distinction allows the system to process critical database changes before less criticalchanges.V1 modules describe critical or primary changes; these affect objects that have a controlling function in theSAP System, for example order creation or changes to material stock.V2 modules describe less critical secondary changes. These are pure statistical updates, for example, suchas result calculations.Monitoring objectsMonitoring 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© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 11/59
  12. 12. Best PracticeManage Operations for SAP Price OptimizationMonitoring alertsSince update errors are usually very critical the default configuration is to raise a yellow alert as soon as oneupdate error occurs. This is valid for V1 and for V2 update errors. To raise a red alert for a V1 or a V2 updateerror a threshold must be specified.1.7.4.8 Due list logA due list is a list that contains several entries (documents) depending on selection criteria. There aredifferent types of due lists in an SAP system of which the following three are most important: delivery (L),billing (F) and picking (K). The delivery due list can be 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 objectsThe monitoring object is the respective due list type. That can be ‘Delivery’, ‘Billing’ or ‘Picking’. If a certainuser is processing the due list, the name of the user can be specified here. If it is user independent a wildcard ‘*’ can be used. The aggregation level needs to be defined. This could be ‘per day’, ‘per hour’ or ‘perlog’.Monitoring alertsFor the monitoring of due list log messages, five different alert types can be used: ‘DocumentCreation’ refers to the status of the document creation itself. The alert rating (YELLOW or RED) will be raised if no documents were created during a Due List run. ‘MinQuantityDocs’ refers to a minimum number of documents that should be created during a Due List run. The threshold values for the number of documents that result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (or back) must be maintained. ‘TotalQuantityMsgs’refers to the total number of message created during a Due List run. The threshold values for the number of messages that result in a change from GREEN to YELLOW (or back) and from YELLOW to RED (or back) must be maintained. ‘DLLogMsgs’ refers to specific due list log messages. The message type, the message ID and the number can be specified. It is also possible to use wild cards. The threshold values for the number of 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 alerts - DocumentCreation© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 12/59
  13. 13. Best PracticeManage Operations for SAP Price Optimization1.7.4.9 Application logThe Application Log provides an infrastructure for collecting messages, saving them in the database anddisplaying them as a log. Situations can arise at runtime in application programs that must be brought to theattention of the user in some way. These are usually errors. It can also be useful to report a successfulcompletion. The information that arises is called a message. The set of messages is a log. A log usually alsohas header information (log type, creator, creation time, 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 AlertsThe 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 logIt is possible to monitor for the total number of messages belonging to an object. Therefore the number ofmessages that raises a YELLOW alert and the number of messages changing from a YELLOW to a REDalert must be maintained.It is also possible to monitor specific messages that are considered as critical in table CriticalMsgs. Toconfigure the monitoring of critical application log messages, the relevant object-sub object combinationsneed to be selected. For each of these combinations the message type, the message ID and the messagenumber as well as the threshold values for the number of critical messages that are supposed to result inchanges from GREEN to YELLOW and from YELLOW to RED can be specified. It is also possible to use wildcards.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 13/59
  14. 14. Best PracticeManage Operations for SAP Price OptimizationFigure 7: Monitoring alerts – Application log/critical messages1.7.4.10 Other CCMS monitorsWith Other CCMS Monitors it is possible to assign any CCMS monitoring tree element (MTE) to a businessprocess step or interface. Therefore it is necessary to call transaction RZ20 in the Satellite System and toopen a monitor that contains the required alert(s).The name of the monitoring tree element (MTE) can be found by choosing F1. The MTE name needs to becopied into the corresponding column of the table below (See screenshot “Other CCMS Monitors” below).Under column Monitor Name it is possible to assign an individual name. The MTE used for monitoring should be a MTE on the lowest leaf-level, i.e. on attribute level. If a MTE of a higher branch-level (collective MTE) is chosen then the current and open view in the graphics will show the right alerts but it isn’t possible to work on these alerts within the Business Process Monitoring session as the alerts are not replicated there.In order to load the threshold values that are currently valid in the corresponding system, the button can be used.If successfully retrieved, the values are filled in the right-hand columns. If no active settings for the 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.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 14/59
  15. 15. Best PracticeManage Operations for SAP Price OptimizationFigure 8: Other CCMS monitors Unlike all other Monitoring Types the Other CCMS Monitoring provides the opportunity to assign MTEs from other Systems than the one system the actual business process step is assigned to.As an example you could be interested in monitoring the availability from a Portal system that possesses noCCMS but is included as one business process step in your business process. Now you could use one MTEin the CCMS of the SAP Solution Manager to monitor the heartbeat of the Portal. You could then assign thecorresponding alert via Other CCMS Monitoring to business process step running on the Portal system.1.7.4.11 Analysis and monitoring toolsIt is possible to specify analysis transactions or URL addresses (including file directories) per monitoringobject. In case of analysis transactions these should be used to analyze errors or problems either locally inthe SAP Solution Manager system itself (Call Option “1”) or directly in the respective satellite systems (CallOption “2”). Per default some standard transactions are maintained, e.g. transaction SM37, that provides ajob overview in an SAP System, is maintained for Background Jobs or transaction SLG1 to have a look intothe application log.It is also possible to add new transactions; this could be standard transactions or customer self-writtentransactions.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 15/59
  16. 16. Best PracticeManage Operations for SAP Price OptimizationFigure 9: Analysis & monitoring transactionsOn 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 file servers specify the full file path, using the nomenclature: file://<server>..., e.g. file://server1operations_documentsoperations-handbook.txtFigure 10: Analysis & monitoring URLThe 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 thesebuttons (e.g. ), the user will jump directly into the corresponding transactioneither in SAP Solution Manager (here: SAT) or the connected satellite system (here: CT1) for further analysis.For URLs the push-button (e.g. ) contains the Short text (limited to 20 characters)from the Set-up session and leads the user to the defined URL in a newly opened browser window.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 16/59
  17. 17. Best PracticeManage Operations for SAP Price Optimization1.7.4.12 Monitoring activitiesMonitoring activities should be defined for every monitoring object within a business process step. Allmonitoring objects defined within a business process step are listed here. To ensure effective monitoring andefficient problem resolution the responsibilities should be assigned and problem resolution procedures shouldbe defined as described in the following table. Some information is taken from the previous node ‘SolutionSupport Organization’. Monitoring Team Defines the team that is responsible for monitoring the relevant Monitoring Object. Use value help [F4]. Person Resp. Defines the Person who is responsible for monitoring the Monitoring Object. 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/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.Table 1: Monitoring activities – Responsibilities and problem resolution proceduresAdditional information related to this business process step can be entered in the tables ‘MonitoringActivities’, ‘Error Handling’, ‘Restart of Step’ and ‘Escalation Path’. Those information would be valid for thewhole business process step and helps users who have to carry out the monitoring and who are not sofamiliar with that particular business process.1.7.4.13 NotificationsNotifications can be set up for the whole business process or for each business process step individually.There are two types of notifications: Workflow notifications and Support notifications. Workflow notificationsallow sending messages in case of alerts to a specified Recipient. This could be an e-mail or 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.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 17/59
  18. 18. Best PracticeManage Operations for SAP Price OptimizationNotifications defined on business process step level will overrule the configuration made on business processlevel for this particular step.Workflow notification Sender Must be a user within in the monitoring client of SAP Solution Manager. This user can be even a system user without any roles or profiles, but the user must have a valid e-mail address that is known by the used mail-server Recipient Address Depending on the Recipient Type the recipient name is required. This could be any e-mail 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:<cell phone or pager number>” Reci. Type There are currently 5 different Recipient Types: U (e-mail), K (for SMS and Pager), B (SAP user name), R (Remote SAP name) and C (shared distribution list). No. of YELLOW Number of YELLOW alerts that may occur before an automatic notification is Alerts triggered No. of RED Alerts Number of RED alerts that may occur before an automatic notification is triggered Max Wait Time [h] Once the maximum wait time [hours] has elapsed, a notification is created, even if the thresholds are not exceeded RED Only To restrict this mechanism only to red alerts the flag in column RED Only must be set. Detailed Triggers a long text for e-mails or SAPOffice mails, e.g. name of the solution, name of the business process step, …)Table 2: Workflow notificationSupport 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 who is 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.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 18/59
  19. 19. Best PracticeManage Operations for SAP Price Optimization Reporter Necessary when service desk messages are created automatically. Must be a SAP user name who is defined as a Business Partner with role “General”. No. of YELLOW Necessary when service desk messages are created automatically, e.g. after 10 Alerts yellow alerts a service desk message should be created. No. of RED Alerts Necessary when service desk messages are created automatically, e.g. after 5 red alerts a service desk message should be created.Table 3: Support notification If in addition to queue, processor, priority and reporter either one of the columns “Num of 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 either exist more than 9 yellow alerts OR more than 4 red alerts for which no Support Notification has been created yet.1.7.5 Business process monitoring processFor 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 this document for more detailed information on a topic. This symbol indicates you 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 - BP_MO_for_SAP_Price_Optimization_V30.doc page 19/59
  20. 20. Best PracticeManage Operations for SAP Price Optimization2 Business Process Monitoring for Weekly Data ProcessingThis chapter will show you by four example processes, how business process monitoring for SAP PriceOptimization could possibly look like. It will introduce you to generic thoughts and ideas how to identify abusiness process step you could keep an eye on and makes you familiar with how to choose the mostpromising monitoring possibilities from the available ones.To make this most visible to you, we have situated the four example processes in a fictional company.2.1 Sample ScenarioPC Express is a midsize company. Its main business is selling PC components at their retail stores. Thestores are divided into regions across the United States geographically. Each region is divided further bydemand patterns, store with similar sales patterns and demographic characteristics are grouped together forthe purposes of pricing.Prices are established by a centralized pricing department located at Company Headquarters where pricingdecisions are made by a team of Merchants and Pricing Analysts.To be able to do this they use the following core business processes.1. Weekly Processing2. Weekly Modeling3. Price Optimization4. Price File DeliveryThe following chapter takes you step by step through these four core business processes, explaining whereand how you can identify focus points for Business Process Monitoring. For each business process step themost effective ways for Business Process Monitoring in the context of the example are highlighted.The overall process flow is shown below. The sections following will describe each process contained in thisoverall view in more detail. These are labeled P01 to P04 in the diagram below.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 20/59
  21. 21. Best PracticeManage Operations for SAP Price Optimization SAP BI System SAP Demand Management File Transfer Export Weekly Sales P01 Load Weekly Data Import Tables Data Prep Data Validation SAP ERP Retail P02 System Model SAP PI DM Database Review & Post Models P03 Generate & Review Export Master Data Optimization Process Forecasts P04 Deliver Price Files Receive Price Changes File TransferFigure 11: SAP Price Optimization – Overall process flow© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 21/59
  22. 22. Best PracticeManage Operations for SAP Price Optimization2.2 Business Process: Weekly ProcessingIn order for SAP Price Optimization to stay current, data must be loaded into the system each week. The dataformats and processes for the transmission of the data will have been established during the implementationof the application so this document will only describe the steps necessary to perform the weekly loads intoSAP Price Optimization. SAP BI System SAP Demand Management File Transfer Export Weekly Sales P01 Load Weekly Data Import Tables Data Prep Data Validation SAP ERP Retail System SAP PI DM Database Export Master DataFigure 12: SAP Price Optimization – Weekly processing2.2.1 Business process step 1: Export master data2.2.1.1 DescriptionDuring the Master Data Export step data will be exported from an SAP ERP Retail system using the standardinterfaces to SAP Price Optimization. This process step extracts the necessary weekly data from the ERPsystem and provides the data for a seamless file transfer in an integrated environment. This data transfer canbe triggered by transaction RDMCHG which extracts updates for the stores, products, prices, zones, storeinventories, distribution centers, distribution center inventories and store - distribution center assignments.The extracted data is sent to SAP PI which converts the data into the target file structure and places the fileson a shared folder. From this shared folder, SAP Price Optimization can seamlessly pick up all files usingSQL Loader.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 22/59
  23. 23. Best PracticeManage Operations for SAP Price OptimizationScenario-specific samplePC Express has determined that the weekly change load (transaction RDMCHG) will run in background of thedata. Therefore no person has to run any specific transaction manually.2.2.1.2 Monitoring requirementsError monitoringThe file transfer should be monitored after the estimated end of transaction run RDMCHG to ensure that allfollowing process can run. This monitoring can be done immediately after the transaction has finished with alog view of the processed data in job log. If an error arises the operator can jump into every message whichhas been created and get detailed information for the error cause.The lowest level of detail is the XML messages which are created and transferred to PI and can be monitoredin transaction SXMB_MONI or the Runtime Workbench on Java. Additionally, the file adapter placing the filesshould be monitored.The monitoring should follow these steps: To review all logs which got created during the outbound processing of the data on the ERP side – the logs can be easy accessed by the Easy Access Menu for the SAP ERP Retail system: Retailing -> Distributed Retailing -> Demand Management Integration -> Outbound -> Logs To check the processing of XML messages between ERP and PI TA SXMB_MONI should be used. To check end-to-end communication e.g. including the communication with the file adapter use the Runtime workbench of SAP Exchange Infrastructure.Scenario-specific sampleThe operator of PC Express will run the transaction RDMCHG and after a successful execution he can reviewthe log view of transaction RDMCHG and jump from there into the xml messages to make some randomchecks for data consistency.Performance monitoringDepending on the data which is taken into account via the pre-selection and the changes which occur fromweek to week the execution time of the transaction is very individual. Therefore in every project theperformance data export schedules should be defined accordingly to the customer requirements.Scenario-specific sampleDuring the operation of SAP Price Optimization the operator should get active regarding performance whenusers acknowledge bigger performance issues as measured during the implementation phase of the project.The operator can use the tools provided by SAP for performance measurement like transaction STAD.Throughput monitoringFor the success of the business process execution the throughput of data records for each message type iscritical. It has to be ensured that enough data records can be created in a specific manner of time to completethe weekly processing in the planned amount of time.Scenario-specific sample© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 23/59
  24. 24. Best PracticeManage Operations for SAP Price OptimizationIf the system is generation data records to slow the operator of PC Express will evaluate statistical datarecords in STAD.Backlog monitoringAll change pointers should be processed during the time window which is predefined for each change load atafter completion of the change load all change pointer should be reset.Scenario-specific sampleIn PC Express the status of the change pointer after the change load should be checked and if there is a bigamount unprocessed – a warning should be send out to the operator.2.2.1.3 Monitoring objectsMonitoring Selection Criteria Alert Analysis Tool on MonitoringObject Satellite System Frequency / Data CollectionStatus of Job By Jobname/Program Program Job canceled SM37 Weeklyrunning RDM_OPT_CHANGE_REQUtransaction / ESTprogramRuntime of Job Program Program SM37 Weekly RDM_OPT_CHANGE_REQU ESTJoblog Message type Warnings SM37 Weekly occurredApplication Log Object Warning RDM_SLG1_CHG_O Weekly occurred UT (Yellow lights)© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 24/59
  25. 25. Best PracticeManage Operations for SAP Price OptimizationMessage status Message types: Empty SXMB_MONI in ERP Weekly payloads RDMViewOfMaterialTransmiss ionRequestMessage_async_In , RDMViewOfLocationStoreTran smissionRequestMessage_asy nc_In, RDMViewOfSalesPriceSpecTr ansmissionReqMsg_async_In, RDMViewOfPriceZoneTransmi ssionRequestMessage_async _In, RDMViewOfStoreInventoryBy MaterialAndLocTransReqMsg_ async_In, RDMViewOfLocationDCTrans missionRequestMessage_asy nc_In, RDMViewOfDCInventoryByMa terialAndLocTransReqMsg_as ync_InMessage status Message types: Empty SXMB_MONI in PI or Weekly payloads Runtime Workbench MaterialRetailDemandManage mentBulkRequest_Out,StoreR etailDemandManagementBulk Request_Out,SalesPriceInform ationBulkRequest_Out, StorePriceLevelBulkRequest_ Out, StoreSupllyingBranchBulkReq uest_Out, InventoryBulkRequest_Out, LocationBulkRequest_Out, InventoryBulkRequest_OutNumber of Message types for changeUnprocessed pointers: Article, Site, Price,change pointers Pricelist, Store Inventory, Distribution Center, Distribution Center Inventory, Supplying DC for StoreFile Adapter File Adapter to Shared Folder Adapter Runtime Workbench -Status for SAP Price Optimization shows error > Component Monitoring -> Adapter Engine -> Communication Channel MonitoringTable 4: Export master data – Monitoring objects© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 25/59
  26. 26. Best PracticeManage Operations for SAP Price Optimization2.2.1.4 How to find meaningful thresholds per monitoring objectMeaningful thresholds should be defined during the implementation phase of each project because thesethresholds differ depending on the amount of data and hardware a customer is using. Therefore aperformance check for the customer system should be done and updated frequently.2.2.1.5 Error handling per monitoring objectThe schedule of this process is weekly based so all monitoring objects should be observed weekly after theprocess should have finished.Background Job RDMCHG Check Job Log for cancellations. Check Application log for warnings and errors. Check Message status for wrong mappings and empty xml messages.2.2.2 Business process step 2: Export weekly sales2.2.2.1 DescriptionWeekly sales are typically stored in SAP BI and are used by Price Optimization for updating the productspecific demand models. The export process of sales data is defined customer specific aligned to the definedprocessing schedules. The export of the weekly sales is defined during the setup of the process chain in theSAP BI system, as described in the configuration manuals.Scenario-specific sampleWeekly sales are stored in SAP BI and are exported automatically as defined in the business blueprint ofeach specific customer.2.2.2.2 Monitoring requirements:Error monitoringTo monitor the data load in SAP BI (extraction from source systems into BI, outbound of sales data to OpenHub Destination) the standard tools of the Data Warehousing Workbench can be used. More information isprovided via the SAP help portal:Open page http://help.sap.com. Choose SAP Solutions SAP Netweaver SAP Netweaver 7.0 (2004s) inyour favorite language. Navigate to SAP Netweaver by Key Capabilty Information Integration BusinessIntelligence Data Warehousing Data Warehousing Workbench.Performance monitoringTo ensure a high performance of the sales data export, it can be useful to regularly check the systemperformance during the upload execution. For further details please refer to the generic Run SAP - BestPractices for Solution Management documentation ‘Periodic Jobs and Tasks in SAP BI’ underhttps://service.sap.com/solutionmanagerbp.Scenario-specific sample© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 26/59
  27. 27. Best PracticeManage Operations for SAP Price OptimizationAn operator checks regularly as determined in the implementation phase of project the system log andstatistics.Backlog monitoringTo get a good overview over the data staging and database performance situation of the system, the usageof monitoring tools additional to the already described ones are available.Scenario-specific sampleCheck the database tune summary of the delta queue and PSA table of DataSource0RT_SALES_DATA_SAPDM.The following basis monitoring tool is available: Tune Summary (transaction ST02)Scenario-specific sampleDuring the sales data export run an operator observes the system behavior in ST02.2.2.2.3 Monitoring objectsMonitoring Selection Criteria Alert Analysis Tool MonitoringObject on Satellite Frequency / System Data CollectionTune summary, ST02 WeeklyMemoryManagementABAP Runtime Error Name, Exception ST22 WeeklyErrorsSystem Log Object Warning, Errors SM21 WeeklyBI Process Chain Chain containing Data Processing Source status 0RT_SALES_DATA_SAPDMTable 5: Export weekly sales – Monitoring objects2.2.2.4 How to find meaningful thresholds per monitoring objectMeaningful thresholds have to be determined in scope of the project depending on the requirements of thecustomer.2.2.2.5 Error handling per monitoring objectFurther details about monitoring tools in SAP BI are available as generic SAPBest Practices for SolutionManagement documentation in https://service.sap.com/solutionmanagerbp under ‘Monitoring for BIBasis (ABAP and Java)’, ‘Monitoring for BI Reporting’ and ‘Background Job monitoring with SAP SolutionManager’.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 27/59
  28. 28. Best PracticeManage Operations for SAP Price Optimization2.2.3 Business process step 3: File transfer2.2.3.1 DescriptionThe export of the data from SAP ERP/BI places the files in the correct location for SAP DM.Scenario-specific samplePC Express is a current SAP ERP/BI customer and as such does not need to be concerned with any filetransfer. The weekly data export places the data in the correct folders on server for the DM application. Inaddition, PC Express hosts their hardware so no encryption needs to occur.2.2.3.2 Monitoring requirementsFile monitoring with SAP Solution ManagerIn order to monitor the files created by PI, the SPACCMSR agent is available. This agent allows you tomonitor e.g. File availability at a certain point in time, File Size, File Age etc. This information can also beforwarded to local CCMS and be read by SolMan from there. See SetupGuide for IFMon(http://service.sap.com/bpm -> Technical Information -> Setup Guide Interface Monitoring)Error monitoringAll files transfers will need to complete successfully before the following processes can begin.Scenario-specific sampleAn operator will need to monitor the file transfer process to make sure all files are present before beginningthe ‘Load Weekly’ process.Performance monitoringFile transfer should take place according to a predetermined schedule so the SAP-DM load processing canbe scheduled. The next step of processing (Load Weekly) is generally kicked off manually, which requires auser to verify all files are present.Scenario-specific sampleAll files coming from PC Express will be in the correct server location by 18.00 Sunday.Throughput monitoringIt is vital that all files can be transferred in a reasonable amount of time. The file transfer process should takeno more than 12 hours to complete for very large clients.Scenario-specific sampleIf any issues occur that will cause the transfer to complete later than this time, an IT representative from PCExpress will inform the SAP-DM team as to when the transfer will be complete. If files are not present on19.00 Sunday, a representative from SAP will contact PC Express.Backlog monitoringNot applicable.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 28/59
  29. 29. Best PracticeManage Operations for SAP Price Optimization2.2.3.3 Monitoring objectsMonitoring Selection Alert Analysis Tool on MonitoringObject Criteria Satellite System Frequency / Data CollectionFile presence Files not present Manual step or complete at the desired timeTable 6: File transfer – Monitoring objects2.2.3.4 How to find meaningful thresholds per monitoring objectA predetermined deadline is agreed to by the client for expected delivery of all weekly files.2.2.3.5 Error handling per monitoring objectIf it is determined that the files are not present by the deadline, the operator will contact the appropriate clientpersonnel to investigate and provide a suitable workaround.2.2.4 Business process step 4: Load weekly data2.2.4.1 DescriptionThis step will move the weekly master and sales data into the import tables using SQL Loader to prepare forfurther processing. This process verifies that the expected files are present.Scenario-specific sampleIt has been decided that SAP will be responsible for weekly processing in the PC Express environment. TheLoad Weekly process is started by an operator using the PC Express production UI.2.2.4.2 Monitoring requirements:Error monitoringError notification is provided in the processing screen within the SAP-DM application. Verifying the processhas completed successfully requires a refresh of the processing screen. The status will indicate whether theprocess is running, has completed, or has failed.Scenario-specific sampleFrom the processing screen, the analyst will validate that the Load Weekly process has completedsuccessfully. If an error occurs, the analyst researches the error using the methods described in the ErrorHandling per Monitoring Object section.Performance monitoringStarting this process takes a single key stroke and an operator should receive feedback in less than onesecond.Scenario-specific sample© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 29/59
  30. 30. Best PracticeManage Operations for SAP Price OptimizationFor PC Express, the feedback occurs in less than one second.Throughput monitoringThis process should take no more than a couple of hours for the largest clients and should be determined perclient. It is possible to verify the count of the number of records in the import tables by querying the databasetables directly or by reviewing the SQL Loader log files. This information is not visible through the UI.However, if the Load Weekly process completes successfully, this step is not necessary.Scenario-specific sampleThe operator checks the status of this process approximately one hour after manually starting the LoadWeekly process.Backlog monitoringNot applicable2.2.4.3 Monitoring objectsMonitoring Selection Alert Analysis Tool on MonitoringObject Criteria Satellite System Frequency / Data CollectionLoad Weekly Screen = Process Each time weekly Processing terminates with an data is loaded ‘Error’ status. Activity = Regular Group = Import and Cleanse Process = Load WeeklyTable 7: Load weekly data – Monitoring objects2.2.4.4 How to find meaningful thresholds per monitoring objectThe Load Weekly process must complete without error before subsequent steps can be started in the weeklyprocess. This process typically completes within 30 minutes depending on the size of the files. Thresholdsshould be determined per client based on hardware size and file size.2.2.4.5 Error handling per monitoring objectSome possible problems in this process are: Data files in the incorrect format Data files did not transfer properly Data file were not decrypted properlyIt may be necessary for the operator to connect to the UNIX server via PuTTY or another UNIX interface toolto review the SQL Loader log files to obtain more information on the files in error and the type of error© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 30/59
  31. 31. Best PracticeManage Operations for SAP Price Optimizationencountered. If a file format is incorrect or a file was not received from the client, it may be necessary tocontact the appropriate client personnel to retransmit a corrected file or provide a workaround.As explained above, the solution manager allows carrying out a file monitoring.2.2.5 Business process step 5: Data validation2.2.5.1 DescriptionData validation is run against the data once it is stored in the import tables to ensure its suitability for use inoptimization. This process will validate that all columns in all import files meet the import standards definedwithin SAP-DM.Scenario-specific sampleThe analyst starts the Clean Weekly process for PC Express once the Load Weekly process has completedsuccessfully.2.2.5.2 Monitoring requirementsError monitoringError notification is provided in the processing screen within the SAP-DM application. Verifying the processhas completed successfully requires a refresh of the processing screen. The status will indicate whether theprocess is running, has completed, or has failed. If a fatal error is encountered, further investigation may berequired. Even though the process may complete without error, the operator must review the completionstatistics for any data exceptions.Scenario-specific sampleFrom the processing screen, the analyst will validate that the Clean Weekly process has completedsuccessfully. If an error occurs, the analyst researches the error using the methods described in the ErrorHandling per Monitoring Object sectionPerformance monitoringStarting this process takes a single key stroke and an operator should receive feedback in less than onesecond.Scenario-specific sampleFor PC Express, the feedback occurs in less than one second.Throughput monitoringThis process may take up to 12 hours depending on the client data set and available resources. The analystcan verify the results of this process once it has a ‘Completed’ status in the Import Review Screen of theSAP-DM UI. This screen reports on the number of records rejected for each file based on specific validationcriteria. If the Clean Weekly process terminates with an ‘Error’ status, further investigation is required by theanalyst.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 31/59
  32. 32. Best PracticeManage Operations for SAP Price OptimizationScenario-specific sampleThis process should take eight hours in the PC Express environment. The analyst verifies that the CleanWeekly process has completed successfully on Monday morning and provides feedback to PC Express onany rejected records.Backlog monitoringNot applicable2.2.5.3 Monitoring objectsMonitoring Selection Alert Analysis Tool on MonitoringObject Criteria Satellite System Frequency / Data CollectionClean Weekly Screen = Process Each time weekly Processing terminates with data is loaded ‘Error’ status Activity = Regular Group = Import and Cleanse Process = Clean WeeklyData Existence Check Process Each time weeklyManagement -> Failed completes data is loadedImport Review successfully. Validate rejected records.Data Invalid action Process Each time weeklyManagement -> type. completes data is loadedImport Review successfully. Validate exception count within thresholdData Specified key is Process Each time weeklyManagement -> null. completes data is loadedImport Review successfully. Validate rejected recordsData Failed Update. Process Each time weeklyManagement -> Update record in completes data is loadedImport Review target table does successfully. not exist. Validate exception count within threshold© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 32/59
  33. 33. Best PracticeManage Operations for SAP Price OptimizationMonitoring Selection Alert Analysis Tool on MonitoringObject Criteria Satellite System Frequency / Data CollectionData Duplicate Key. Process Each time weeklyManagement -> completes data is loadedImport Review successfully. Validate rejected recordsData Duplicate Row. Process Each time weeklyManagement -> completes data is loadedImport Review successfully. Validate exception count within thresholdData Data validation Process Each time weeklyManagement -> error. completes data is loadedImport Review successfully. Validate exception count within thresholdTable 8: Data validation – Monitoring objects2.2.5.4 How to find meaningful thresholds per monitoring objectThe Import Review screen gives detailed information about each file, and what records were ignored as partof the SAP-DM cleansing processes. Although it is recommended that all files are error-free, it is understoodthat some files may have some rejected records. No file should have more than 5% of all records inexception. If all files have less than 5% exceptions then processing can continue, however, all exceptionsshould be reported back to host system administrators.2.2.5.5 Error handling per monitoring objectFor the Clean Weekly process, the user will need to locate the ‘Clean Weekly’ process within the processingscreen of SAP-DM. This process is required to finish with a status of ‘Complete’ before subsequentprocesses can be started. If the process terminates with a status of ‘Error’, select the error message on theProcessing screen (double clicking) to provide more information to help an operator troubleshoot the problem.The ‘Clean Weekly’ process should always complete successfully. Any erroneous data from this process willbe inserted into the error tables. A summary for review is provided in the Data Management Import Reviewscreen.2.2.6 Business process step 6: Product linking and data preparation2.2.6.1 DescriptionThe preparation for modeling includes product linking, association of the linking information to the markethierarchy and posting that information to the system.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 33/59
  34. 34. Best PracticeManage Operations for SAP Price OptimizationThe second process that needs to be run prior to optimization is CSO Prep. This process moves the mostrecent price, cost, competitor data, and price constraint information into the tables used by optimization.Scenario-specific samplePC Express has decided to allow the SAP-DM team to infer product linking using the processes in the UI.Once the inferring has been done, business users from PC Express can manually review the linking andmake any changes through the UI.Because PC Express uses competitive data as well as specific price rules all processes under CSO Prepmust be run.2.2.6.2 Monitoring requirementsError monitoringError Checking and correction for Product Linking is performed through the UI in the rules tab of the productlinking screen.Validation of completion of CSO Prep processes is performed through the UI in the processing screen. Thestatus will indicate whether the process is running, has completed, or has failed.Scenario-specific sampleOnce the product linking has been inferred and reviewed, the analyst will check for specific errors, correctingthem as they are found. This is an iterative process until all errors are resolved.From the processing screen, the analyst will validate that the CSO Prep processes have completedsuccessfully.Performance monitoringProduct linking and error checking is an interactive process within the SAP-DM UI. No performancemonitoring should be needed.CSO Prep processing is run and validated through the Processing screen in the UI.Scenario-specific sampleFrom the processing screen, the analyst will validate that the CSO Prep processes have completedsuccessfully.Throughput monitoringProduct linking throughput should be determined per client based on the modeling schedule of that client.Scenario-specific sampleIn the PC Express environment all CSO Prep processes will be started manually and should complete withinone hour.Backlog monitoringNot applicable© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 34/59
  35. 35. Best PracticeManage Operations for SAP Price Optimization2.2.6.3 Monitoring objectsMonitoring Selection Criteria Alert Analysis Tool on MonitoringObject Satellite System Frequency / Data CollectionData Select level at Done on aManagement – > which Demand schedule agreedProduct Linking -> Group will be set upon by theDemand Group from drop down customer.tab menu and press Products only ‘Infer’ become available for optimization once this process occurs.Data Select the number Done on aManagement – > of characters to use schedule agreedProduct Linking -> to identify product upon by theProduct Line tab lines and press customer. ‘Infer’ Products only become available for optimization once this process occurs.Data Select the criteria to Done on aManagement – > be used to schedule agreedProduct Linking -> determine price upon by thePrice Family tab family (price, cost or customer. effective size) and Products only press ‘Infer’ become available for optimization once this process occurs.Data Press ‘Reset Error Check for specific Done on aManagement – > Codes’ and press Error Codes and schedule agreedProduct Linking -> ‘Apply’ make corrections. upon by theRules tab customer. Products only become available for optimization once this process occurs.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 35/59
  36. 36. Best PracticeManage Operations for SAP Price OptimizationMonitoring Selection Criteria Alert Analysis Tool on MonitoringObject Satellite System Frequency / Data CollectionAssociate Linking Screen = System Done on ato Market Configuration – schedule toHierarchy Market Hierarchy support Product Associations Linking. Auto Associate All – Demand Groups/Micro Markets Tab Auto Associate All – Zones/MicroMarkets TabValidate Screen = System Severe Errors inAssociations Configuration – the Hierarchy Market Hierarchy Validation Log Associations Validate Associations button Hierarchy Validation Log TabPublish Linking Screen = Process Done on a Processing terminates with schedule agreed ‘Error’ status upon by the Activity = Regular customer. Group = Import and Products only Cleanse become available for optimization Process = Publish once this process Market Hierarchy occurs. and Linking InformationCSO Prep Screen = Process Each time weekly Processing terminates with data is loaded ‘Error’ status Activity = Regular Group = CSO Prep Process = Process CurrentCSO Prep Screen = Process Each time weekly Processing terminates with data is loaded ‘Error’ status Activity = Regular Group = CSO Prep Process = Process Competitor© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 36/59
  37. 37. Best PracticeManage Operations for SAP Price OptimizationMonitoring Selection Criteria Alert Analysis Tool on MonitoringObject Satellite System Frequency / Data CollectionCSO Prep Screen = Process Each time weekly Processing terminates with data is loaded ‘Error’ status Activity = Regular Group = CSO Prep Process = Process ConstraintCSO Prep Screen = Process Each time weekly Processing terminates with data is loaded ‘Error’ status Activity = Regular Group = CSO Prep Process = Process AssociatedTable 9: Product linking and data preparation – Monitoring objects2.2.6.4 How to find meaningful thresholds per monitoring objectProduct Linking is conducted based on a predefined schedule. The user performs the product linking andmay review the results with the client. This may take several days depending on the number ofproducts/categories being addressed.Once the Product Linking is error free and approved by the client, an operator will use the SAP-DM UI(system configuration) to ‘Auto Associate’ the linking information to the market hierarchy and validate theassociations by reviewing the validation log. The association processes run interactively when invoked.Then the Publish Market Hierarchy and Linking Information process is run from the processing screen. This processnormally runs within 30 minutes.Each of the CSO Prep processes runs fairly quickly (several minutes) with the exception of Process Currentwhich may take up to an hour. Large history tables are maintained during this process to record pricechanges and cost changes over time.2.2.6.5 Error handling per monitoring objectAll product linking errors must be corrected in order to proceed with modeling using the latest productinformation. The following errors can occur: 701 - Same Price Family - Different Effective Size 703 - Product Lines Crossing Demand Groups 704 - Price Families crossing Product Lines 706 - Same PL and Size, different PF 707 - No DG, PL, or PF 711 - Demand Group Crossing Hierarchy Levels© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 37/59
  38. 38. Best PracticeManage Operations for SAP Price OptimizationEach of these errors can be reviewed and corrected in the Data Management Product Linking screens. Theaction to be taken depends on the error returned. The error description given indicates the correction needed.The ‘Auto Associate’ process should be performed each time new linking data is introduced. This includes astep to validate the associations and review the validation log. These steps are performed from the SAP-DMUI and are interactive. Records with a severity of Error in the validation log must be corrected before movingon to the next step. The error description will indicate the cause. Most errors are caused by faulty linking andwill have to be corrected through the product linking screen.The Publish Market Hierarchy and Linking Information process is required to finish with a status of ‘Complete’ inorder for the latest product linking information to be available to modeling as well as optimization/price filegeneration. If this process terminates with a status of ‘Error’, further investigation is required. Selecting theerror message on the Processing screen (double clicking) will provide more information to help an operatortroubleshoot the problem. The only time this type of error will occur is if the errors encountered during theprevious step are not corrected.The CSO Prep processes are required to finish with a status of ‘Complete’ before optimization/price filegeneration, using the newest data, can begin. If any of these processes terminates with a status of ‘Error’,further investigation is required. Selecting the error message on the Processing screen (double clicking) willprovide more information to help the operator troubleshoot the problem. This process should not fail as alldata has completed through the ‘Clean Weekly’ process.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 38/59
  39. 39. Best PracticeManage Operations for SAP Price Optimization2.3 Business Process: Weekly ModelingTo continue to produce satisfactory results the demand models used by Price Optimization must continue tobe refined as new sales are collected. This process is accomplished by executing modeling jobs. Becausethe time required to model the entire enterprise can be very large, a modeling schedule is established duringthe implementation which determines what portion of the enterprise is remodeled each week. This section willdescribe the steps necessary to carry out this remodeling. The creation of the modeling schedule is notcovered by this document. SAP BI System SAP Demand Management SAP ERP Retail P02 System Model SAP PI Review & Post ModelsFigure 13: SAP Price Optimization – Weekly modeling2.3.1 Business process step 1: Model2.3.1.1 DescriptionCreating the demand models necessary for optimization is accomplished by several different processes.Each process is completed at a level where the product hierarchy intersects with a zone (also known as amicro market). There are three major steps in this process and they are: The first process determines the promotional calendar by looking at the sales data. This process is vital to make sure that un-realistic lifts are not placed on products. The second process aggregates sales information by zone. The aggregation process can help the model when there are holes in store level data. The final process is modeling, which uses the aggregated sales information to calculate modeling 2 information including elasticity and r values. These values will later be used in optimization.© 2009 SAP AG - BP_MO_for_SAP_Price_Optimization_V30.doc page 39/59

×