General Business Process Management

Best Practice for Solution Management

Version Date: February 2002 The newest version of this Best Practice can always be obtained through the SAP Solution Manager or the SAP Service Marketplace.

Contents
Applicability, Goals, and Requirements .................................................................................... 2 Best Practice Procedure........................................................................................................... 3 1. Creating a Business Process Management Concept ..................................................... 3 2. Managing the Resulting Documentation ......................................................................... 6 3. Coordinating Management and Monitoring Activities...................................................... 7 4. Managing Procedure Handover and Rollout................................................................. 10 5. Coordinating Future Procedure Updates and Improvements ....................................... 11 Further Information................................................................................................................. 12

2001 SAP AG

Best Practice: General Business Process Management

Applicability, Goals, and Requirements

To ensure that this Best Practice is the one you need, consider the following goals and requirements.

Goal of Using this Service

This Best Practices will help you to develop and implement an all-inclusive concept for businessprocess management and monitoring for a solution landscape comprising mySAP components. This concept aims to: Define procedures for business-process oriented monitoring, error handling, and escalation management for a company's core business processes Establish the communication links between the business-department end users and the IT department Define the roles and responsibilities for all persons involved in the customers support and monitoring organization

These procedures ensure the smooth and reliable flow of the core business process in order to meet your business requirements. See also below under Further Information.

Alternative Practices
You can get SAP experts to deliver this Best Practice on-site if you order a Solution Management Optimization (SMO) service known as the SAP Business Process Management (BPM) service.

Staff and Skills Requirements

To implement this Best Practice, you require the following teams: Application Management Team The business process management concept (which this Best Practice aims to produce) should be created by the Application Management Team. This team combines experts from your companys: Business departments Solution Support Organization (for example, the IT department and the Help Desk) Implementation project team Execution Team The persons who will be responsible for applying the resulting procedures derived through using this Best Practice include: Persons designated to perform business-process monitoring and ensure that business processes run smoothly All parties in the customers Solution Support Organization and IT department involved in monitoring

System Requirements
None.

Duration and Timing

Duration Creating a business-process management concept depends on the complexity and number of your core business processes, and could take around one week per business process. Implementing the business-process management concept could take around one additional week.

2001 SAP AG

Best Practice: General Business Process Management Timing The best time to apply this Best Practice is during the planning phase or during the implementation phase of your mySAP solution.

Best Practice Procedure

1. Creating a Business Process Management Concept
1. Define a team for working on this Best Practice. This team should include a leader or moderator, as well as one or more persons from each of the following groups: Business department Solution support organization (for example, the IT department and the Help Desk) Implementation project team (experts in the different business processes) Choose your people so that the resulting team is competent to evaluate all technical and business aspects of your companys core business processes. 2. Determine the core business processes of your company. For each of these core business processes, perform the following steps (3-6). Note: A core business process is a process that is essential for business success. The sum of all core business processes is what generates the bulk of a company's revenue. An example of a core business process in a retail company might be sales order processing and billing. In this Best Practice, you begin by focusing on the core business processes in order to introduce priorities into business process management. Later, under "Coordinating Future Procedure Updates and Improvements" you extend these procedures to cover all other business processes. 3. Document the core business process from a general, functional viewpoint, including the following details: Short summary of the business process from the application viewpoint (around 10 lines). Describe how business-critical the core process is, that is, to what extent company revenue is endangered if this business process does not run smoothly. Document the business process by creating a flow chart. In the flow chart, list the process steps, any sub-processes, and all related functions such as ATP check, variant configuration, and so on. For each process step / sub-process: Mention the system or components in which the respective process steps occur, and which interfaces are involved. List the document volume for each type of document involved, and the time of day (or month or year) when processing occurs. Define the maximum processing duration. Name potentially critical areas. 4. Extend the above flow chart of the core business process to include the following technical details: Technical details of each process steps, for example names of programs, transactions, background jobs, and so on Details of any modifications to SAP-standard programs or transactions When background jobs run 2001 SAP AG

Best Practice: General Business Process Management

Dependencies of the process steps, for example, where one process step cannot be performed until another one is complete, or where some process steps require a special time frame. Technical details of all involved interfaces, such as input/output, synchronous/asynchronous post-processing. Conditions of restartability for the process, process, step, sub-process, or interface 5. In the flow chart, define the objects that need to be monitored. Monitoring procedures ensure that the technical processes meet the requirements for stability, performance, and completeness. Monitoring must cover three areas: errors; performance and throughput; and processing progress and completeness. For each process step: Determine the possible errors Define the relevant monitoring objects and monitors Define the error handling procedures (including how to correct the error, if possible), the persons to whom errors are to be reported, and the escalation paths To determine an appropriate strategy for each type of possible error, keep in mind the following questions: Do errors result in data inconsistency? Are the errors and their causes transparent to end-users and system administrators? Are reporting strategies and escalation paths completely defined and published to all concerned parties? If errors occur, are there alternative procedures or settings that enable users to avoid such errors? Can the error be prevented from reoccurring? 6. For each possible type of error, create a road map for analyzing and handling the error. 7. The flow chart including the monitoring objects and error/handling procedures defined in steps 1 to 6 constitute your concept for business process management. Now you need to implement this concept as follows: Specify the Business Process Champion (or owner) who is responsible for the overall smooth functioning of the respective core business process. Specify the roles and assign the persons responsible for 1st and 2nd level Application Support responsible for business-process monitoring, error handling, and escalation. (Note: Application Support is the general organization that performs application management tasks. One of these tasks is business process management as described in this Best Practice.) Specify the persons responsible for the following IT-department organizational units: System Monitoring, Software Monitoring, Development Support, and Program Scheduling Management. From the flow-chart documentation, create simplified monitoring and error-handling instructions for 1st level Application Support. Using the Task-Checklist Creation Guide below, include the above simplified procedures as well as the existing IT-department organizational units to create overall Task Checklists naming activities related to business process management, as well as the responsible persons or organizational units. Test and optimize these monitoring and error-handling instructions, and the communication paths between 1st and 2nd level Application Support in regard to business-process monitoring. Integrate the responsibilities for 1st and 2nd level Application Support with the existing IT-department organizational unit responsibilities. This may mean adding some or all of the application-support duties to existing IT-department roles, and, if necessary, training the respective employees to perform these new duties. 2001 SAP AG

Best Practice: General Business Process Management

8. Define procedures for the future updating or improvement of the above defined monitoring and error handling procedures in the course of time. This is a way of continuously ensuring smooth process flow, data consistency, and security against downtime. In particular, new procedures are required whenever the business process is changed or altered.

Process 1
Business Process Champion

Process 2
Business Process Champion

Process 3
Business Process Champion

Process 4
Business Process Champion

Application Support Development Support Program Scheduling Management Software Monitoring Team System Monitoring Team

Figure 1. Monitoring teams in the SAP-customer's overall Solution Support Organization.

Table 1. Monitoring roles and responsibilities. Role Business Process Champion Responsibilities In the Business Department Providing the central contact person for the Application Management Team Managing quality assurance for the entire process Adjusting the monitoring and escalation measures for modifications to the process Coordinating of all process activities in the system Defining the escalation path for problem resolution Maintaining the application-oriented process description Application Support In the Application Management Team Creating application-oriented documentation Documenting modifications to business processes Monitoring the running of business processes and interfaces Providing 1st and 2nd Level Application Support Ensuring high performance of the business processes 2001 SAP AG

Best Practice: General Business Process Management Role Development Support Responsibilities In the IT Department Implementing any changes required to optimize businessprocess design Implementing changes to programs as required to solve functional or technical problems Ensuring high performance for new developments Program Scheduling Management In the IT Department Documenting technical information on program scheduling Monitoring scheduled jobs and processes Immediately handling job terminations or other errors Managing restartability Triggering escalation in case of job termination or other errors Monitoring performance of background jobs Software Monitoring In the IT Department Monitoring the performance, error logs, and memory management of: o o Software such as EBP/BBP, CRM, SCM/APO, and ERP/OLTP Technical components such as the ITS, the Business Connector, the catalog server, IPC, and liveCache

Monitoring the database Monitoring response times Monitoring the interfaces from a technical viewpoint System Monitoring In the IT Department Performing system monitoring for, for example, the hardware, operating system, network, and external tools Ensuring high performance for the hardware

2. Managing the Resulting Documentation

1. Ensure that the documentation resulting from defining the business process management concept has three parts: Business process and business process step documentation. This includes monitoring, error handling, and escalation documentation. Simplified monitoring, error-handling, and escalation procedures Task Checklists of all related activities and the responsible persons or organizational units 2. Make this documentation available to all groups in the customers Solution Support Organization, such as: 1st and 2nd level Application Support (for business-process monitoring) IT organizational units: 2001 SAP AG

Best Practice: General Business Process Management i. System Monitoring Team ii. Software Monitoring Team iii. Program Scheduling Management iv. Development Support To make this documentation accessible, set up a know-how database and make this database and its folder structure known to the various teams.

3. Ensure that the business process documentation serves as a link to the documentation of technical details and is used to help new employees in application support understand a given business process from the application viewpoint. 4. Add to this documentation references to related documents, such as guides and planning documents created by the business department or the implementation project team. 5. Ensure that the business process documentation is very detailed and oriented to the technical side of the process steps. It should be used as a basis for troubleshooting for 2nd-Level Application Support. 6. Ensure that the interfaces are adequately covered in all parts of the documentation. These interfaces are the interfaces between the SAP and/or external components running the core business processes. The documentation should be technically oriented and indicate all the business-critical aspects of the interfaces.

3. Coordinating Management and Monitoring Activities

1. For business processes involving more than one system or component, to perform monitoring set up more than one monitoring team (as shown below in figure 2).

Process 1

Process 2

Process 3

Process 4

Documentation

Program Scheduling Management

Business Process Monitoring

Software Monitoring

System Monitoring

Figure 2. Monitoring tasks. There are four layers of monitoring affecting all business processes; each layer uses several types of documentation.

2001 SAP AG

Best Practice: General Business Process Management 2. If appropriate, divide monitoring into 1st and 2nd Level monitoring (as shown in figure 3 for Software Monitoring). 3. To create Monitoring or Task Checklists, use the Task-Checklist Creation Guide below. The Guide summarizes the recommended contents of the procedures in the various monitoring levels. This provides you with a starting point for creating your own Task Checklists of monitoring, error handling, and escalation procedures. An example for a Monitoring or Task Checklist is shown in table 3.

Software Monitoring 1st Level

Software Monitoring 2nd Level

Persons Responsible for Monitoring Concept Component Monitoring SAP Monitoring Checklists: Checklists:
1. Bulletin Board 1st-Level 2. Monitoring 1. Bulletin Board 2nd-Level 2. Short dump List 3. Update Error List 4. Sys Log Entries 5. R/3 Lock Entries

Performance Monitoring

1st and 2nd Level Support Escalation Paths

1st Level
Training

2nd Level
Training

Figure 3. Example of elements of a software-monitoring concept.

Table 2. Task-Checklist Creation Guide. To define monitoring, error handling, and escalation procedures, use the guide in the following table. Monitoring Level System Monitoring Contents of Task Checklist Monitoring objects Monitoring periodicity/timing Error handling Escalation paths Reference documents Monitoring Areas Hardware, operating system, database, network, and external tools

2001 SAP AG

Best Practice: General Business Process Management Monitoring Level Software Monitoring Contents of Task Checklist Monitoring objects Monitoring periodicity/timing Error handling Escalation paths Restartability Performance Reference documents Monitoring Areas Performance, error logs, memory management of: Software such as EBP/BBP, CRM, SCM/APO, and ERP/OLTP Technical components such as the ITS, the Business Connector, the catalog server, IPC, and liveCache Interfaces from the technical viewpoint Business Process Monitoring Monitoring objects Monitoring periodicity/timing Program runtime/dependencies Error handling Restartability Escalation paths Reference documents Performance Program Scheduling Management Background jobs Restartability Performance Business Department Business Process Champions Error logs Processes Process steps Problems/causes Error handling Reference documents Timing of background jobs and other programs, for example, during peak business periods. User operations Business processes and interfaces

Table 3. Example of a Monitoring or Task Checklist for a particular business process step. For practical purpose, the lists should be issued per Responsibility or corresponding monitoring team.
Monitoring Monitor Object TA/Tool Program RH BAUPAT SM37 Monitor Freque. every 2 hours Monitor Indicator Monitoring Activity or Time or Error Error Handling Procedure Start at status 8:00 am active check if job is within timeframe (dependencies?) cancelled check for dependencies and restart job exceeding indicator value report to system administrator and manager Responsibility Application monitoring team Escalation Procedure Contact the program scheduling management ph. 911 Contact the system administrator ph. 912

Dialog response time of TA BBPPU99

ST03

daily

9:00 am < 2 sec

System monitoring team

2001 SAP AG

Best Practice: General Business Process Management

10

4. Integrate the Application Support tasks that are related to business process management and monitoring in your overall Solution Support Organization. For end-users, Application Support is responsible for the problem-free, error-free, and high performance functions of the processes. 5. To ensure the smooth running of core business processes across the entire system landscape, set up the Solution Support Organization in a business process-oriented manner. 6. Define reporting strategies and escalation paths for each monitoring level that must be used if specified or unusual errors or problems occur. The following figure sketches an example of reporting and escalation paths within a reporting strategy. You must define the form of communication to be used, and the conditions under which communication is required.

Solution Support Organization

Business Process Champion

Application Management Team

Program Scheduling Management

2nd Level Support

System Monitoring

Software Monitoring

Business Process Monitoring

Figure 4. Example of reporting strategy showing various escalation paths that must be formalized.

4. Managing Procedure Handover and Rollout

To facilitate going live with the procedures in your business process management and monitoring concept (within the framework of the overall solution management concept) proceed as follows: 1. Define the persons that are to be responsible for rolling out the procedures and ensuring that they are implemented. 2. Set up a know-how database for all procedures and make this database and its file structure known to all teams that are part of the Solution Support Organization (see above, under "Managing the Resulting Documentation"). 3. Implement the tasks of the Solution Support Organization as defined in the Task-Checklist Creation Guide. In addition, train the employees for the new procedures. You should have already assigned the Application Support tasks related to business process management and

2001 SAP AG

Best Practice: General Business Process Management monitoring to the various teams comprising your overall Solution Support Organization (as described above under " Coordinating Management and Monitoring Activities"). 4. If other companies are part of your Solution Support Organization, arrange a formal and defined handover of tasks. This will apply if, for example, the IT department or hardware are hosted or outsourced.

11

Planning, Documentation Development, Handover, Training, Rollout

Business Process Management Concept Development of Procedures and Task Check Lists

Training of Solution Support Organization

Procedures Rollout and Implementation

Ongoing Process Analysis

Development of Procedures and Task Check Lists

Training of Solution Support Organization

Procedures Rollout and Implementation

time

Figure 5. Managing planning, documentation, handover, training, and rollout.

5. Coordinating Future Procedure Updates and Improvements

System landscapes and business processes change over time, and this results in changes to the documentation derived in this Best Practice for business process management and monitoring. In addition, monitoring, error handling, and escalation procedures can be revised, expanded, and improved. To incorporate both types of documentation changes in the business process management concept, the following strategy is recommended. 1. Set up a team to plan, review, and rollout all changes to the documentation for the business process management concept. This would normally be a part of the Application Management Team. The tasks of this team include: Changing any of the documentation resulting from this Best Practice. (The three forms of this documentation are described above under "Managing the Resulting Documentation"). The changes should reflect both application-related changes and underlying technical changes. Your general procedures for software changemanagement should include guidelines for adding changes to the documentation resulting from this Best Practice. 2001 SAP AG

Best Practice: General Business Process Management Releasing the changes: Ensure that any changed documentation is released in due time and forwarded to: i. The persons involved in the execution of these procedures, for example, Application Support, the Software Monitoring Team, and the System Monitoring Team. For example, after updating the documentation, send a Monitoring-Change Notification to the respective monitoring teams, describing both the changes and their implications for the Solution Support Organization. ii. All other areas of the Solution Support Organization Archiving changes:

12

i. For smaller changes to a document, you do not need to create a new version. Instead, keep a change log. This describes what, how, when, and by whom the business process management and monitoring concept was changed. ii. For larger changes it is recommended that you create a new version. 2. To improve the completeness of all procedures, in addition to the core business processes analyzed above, over time, all other business processes should be analyzed and documented. These include periodic processes such as archiving, and month-end closing.

Further Information
Business process management is one important part of Application Management, which aims to provide a bridge between the existing support functions of IT departments and the respective business departments in an SAP-customer's solution management environment. Business process management is a substantial part of an overall solution management concept.

How Business Process Management Fits into Solution Management

The primary goals of a solution management concept are to: Ensure that the daily running of systems, interfaces, and core business processes is reliable and smooth Enable extensive monitoring and uniform maintenance of a (possibly distributed) production system landscape To create a solution management concept, you must first perform a comprehensive analysis of the current status of the system landscape, interfaces, and core business processes. The documentation resulting from this analysis can also be used to communicate solution management procedures to all employees, and enables new support employees to learn solution management techniques within a short time. An important part of solution management is the monitoring concept. Monitoring aims to ensure the high availability of all systems and components involved both general availability and system performance. Good performance is an important requirement for the smooth running of core business processes. When IT and application managers plan the overall solution management concept, this means considering all of the topics in the following list. You will see that the issues related to business process management and monitoring are part of points 1 through 6.

2001 SAP AG

Best Practice: General Business Process Management

13

Ingredients of an Overall Solution Management Concept

To define this concept, you must document the following: 1. Business Requirements Documenting your business requirements is the prerequisite and input for a solution management concept. The documentation should mention you requirements for: General availability of business processes and systems Requirements for high availability General impact on business (input for disaster and recovery planning) Workaround solutions in case systems are not available Implementation status (explaining what has been completed and what must still be done): Project milestones Roll-out waves Future IT projects 2. Solution Support Organization and Communication Describe the customer's Solution Support Organization that is responsible for managing daily running of the solution: Organizations involved Roles and responsibilities Per process Per system and software component Per interface Service level agreements (internal and with partners) Communication and escalation paths User help desk 3. Business Process Management To establish a business-process management concept, you must properly understand and document various aspects of the business processes: General description Process steps and document volumes Interfaces Process responsibilities (business process champion) Availability requirements, the impact of the process on business Performance requirements/constraints 4. System and Solution Landscape Document various aspects of the system and solution landscape: Hardware components Software components such as EBP/BBP, CRM, SCM/APO, and OLTP Technical components such as the ITS, business connector, catalog server, IPC, and liveCache Availability and maintenance windows 5. Application and Integration Management Business-process oriented monitoring concept: 2001 SAP AG

Best Practice: General Business Process Management

14

Definition of monitoring objects (what has to be monitored, how often, by whom, for which purpose, and so on) Error handling procedures Process restartability Escalation paths Interfaces and integration management Monitoring Restartability Data consistency Availability Program-scheduling management Master data maintenance Data management and archiving 6. System Management These are typical topics, particularly concerned with changes to EBP/BBP, CRM, SCM/APO: Technical software monitoring (software related) Backup and recovery strategy Storage management Performance management Spool administration System administration procedures Facilities management Hardware management Operating system administration Basis administration Database administration System monitoring for EBP/BBP, CRM, SCM/APO components such as the ITS, business connector, catalog server, IPC, and liveCache Third-party monitoring tools, such as Tivoli, Patrol, and Realtech 7. Network and Frontend Management Network monitoring (lines, switches, hubs, routers and so on) Upgrade of frontends (SAPGUI, browser, mobile clients) 8. Change Management Code ownership Responsibilities (sign-off) Procedures regarding transports in to the production system System landscape and client strategy (DEV, QAS, PRD) Upgrade procedures taking into account: Availability and maintenance windows Software components EBP/BBP, CRM, SCM/APO, OLTP and so on 2001 SAP AG

Best Practice: General Business Process Management Technical components ITS, business connector, catalog server, IPC, liveCache and so on Implementation of support packages and core patches Application of notes 9. Quality Assurance Procedures Document your strategy and procedures for: Functional testing Integration testing (data quality) Stress testing (mass data) Going live and cut-over strategy System/operation handover 10. Security Document your strategy for security at the following levels: Application, for example, user authorization profiles Operating system Database Network (intranet/Internet)

15

Roles in Defining and Applying the Solution Management Concept

In order to achieve a steadily and reliably running application and system, solution management requires the following persons or groups to take appropriate action: 1. Business Department: Business departments must operate the application in accordance with defined operating procedures. 2. Application Management Team: A major part of the application management teams responsibilities is to define and follow the business-process management procedures described in this Best Practice. This includes business process monitoring, error handling procedures, escalation paths, and program scheduling management from an application viewpoint. These procedures ensure that business processes run smoothly from a technical viewpoint. 3. IT Department: The IT department must define and apply monitoring procedures including: System Management and Monitoring of, for example, the hardware, operating system, database, network, and external tools Software Management and Monitoring for the system landscape. This includes, for example, monitoring the performance, error logs, and memory management of: Software such as EBP/BBP, CRM, SCM/APO, and ERP/OLTP Technical components such as the ITS, the Business Connector, the catalog server, IPC, and liveCache Program Scheduling Management and Monitoring The present Best Practice advises the application management team on how to define the procedures it needs in order to fulfill the business-process related requirements of a comprehensive solution management concept.

Feedback and Questions

Send any feedback by composing an SAP customer message to component SV-GST-SMC at http://service.sap.com/message.

2001 SAP AG

Best Practice: General Business Process Management Copyright 2001 SAP AG. All rights reserved.

16

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, NT, EXCEL, Word, PowerPoint and SQL Server are registered trademarks of Microsoft Corporation. IBM, DB2, OS/2, DB2/6000, Parallel Sysplex, MVS/ESA, RS/6000, AIX, S/390, AS/400, OS/390, and OS/400 are registered trademarks of IBM Corporation. ORACLE is a registered trademark of ORACLE Corporation. TM INFORMIX-OnLine for SAP and Informix Dynamic Server are registered trademarks of Informix Software Incorporated. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. HTML, DHTML, XML, XHTML are trademarks 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. SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies. Disclaimer: SAP AG assumes no responsibility for errors or omissions in these materials. These materials are provided as is without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. 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.

2001 SAP AG