Business Process Redesign Solman ALM © 2012 SAP AG. All rights reserved

Business Process Redesign in SAP Solution Manager Application Lifecycle Management

Business Process Major release Redesign

2

TABLE OF CONTENTS

1 INTRODUCTION ............................................................................................................................................ 4

2 GENERAL EXPLANATION ........................................................................................................................... 4 2.1 Projects and Solutions .............................................................................................................................. 4 2.2 Template Project ........................................................................................................................................ 4 2.3 Implementation Project ............................................................................................................................. 5 2.4 Maintenance Project .................................................................................................................................. 6 2.5 Upgrade Project for Existing Systems .................................................................................................... 6 2.6 Projects and Solutions Dependencies .................................................................................................... 7 2.7 Business Process Design ......................................................................................................................... 7 2.7.1 Definitions of Business Scenario, Process and Step ............................................................................... 7 2.7.2 End-to-End Oriented Business Process Design ....................................................................................... 8 2.7.3 Module-Oriented Business Process Design ............................................................................................. 8 2.7.4 Definition of End-to-End Business Scenarios based on modular business processes ............................ 9 2.7.5 Structure Attributes ................................................................................................................................. 10 2.8 Business Process Assignments ............................................................................................................ 11 2.9 Document Management .......................................................................................................................... 12 2.10 Procedures for Solution Documentation ............................................................................................ 13 2.10.1 Interface Scenarios ............................................................................................................................... 15

3 BUILDING MAJOR RELEASE PROJECTS ................................................................................................ 16 3.1 Document Management in a Major release Project ............................................................................. 17 3.2 Methodology for Major release Project (Roadmap) ............................................................................. 18 3.3 Testing in the Major release Project ...................................................................................................... 18 3.4 Training Materials .................................................................................................................................... 18 3.5 Go-Live and Maintenance ....................................................................................................................... 19

4 CHANGE REQUEST INTEGRATION .......................................................................................................... 20 4.1 ChaRM in a Maintenance Project ........................................................................................................... 20 4.1.1 Method .................................................................................................................................................... 20 4.1.2 Change Types ........................................................................................................................................ 20 4.1.3 Phase Change (Task List) ...................................................................................................................... 21 4.1.4 Business Process Integration for Document Management .................................................................... 21 4.2 ChaRM in Major release Project ............................................................................................................. 21 4.2.1 Method, Change Types and Phase changes (Task list)......................................................................... 21

5 ORGANIZATIONAL ASPECTS FOR MAJOR RELEASE PROJECTS ...................................................... 22

6 AUTHORIZATIONS ...................................................................................................................................... 23 6.1 Projects ..................................................................................................................................................... 23 6.2 Document Management .......................................................................................................................... 23

7 SETUP/CONFIGURATION AND PROCEDURES ....................................................................................... 24 7.1 General Configuration ............................................................................................................................. 24 7.1.1 Definition of System Landscape – SMSY ............................................................................................... 24 7.1.2 Project Standards .................................................................................................................................. 28 7.1.2.1 Definition of Document Types ............................................................................................................. 29

7.1.2.2 Definition of Status Schema ................................................................................................................ 31

7.1.2.3 Adjustments to Blueprint Document .................................................................................................... 35

7.1.2.4 Structure/Object Attributes .................................................................................................................. 37


3

7.1.2.5 Customer Attributes for Documents .................................................................................................... 40

7.2 Major release Project Creation .............................................................................................................. 43 7.2.1 Compare & Adjust: From Maintenance to Major release project ......................................................... 47 7.2.2 Testing in the Major release Project ...................................................................................................... 48 7.2.3 Learning Map ......................................................................................................................................... 49 7.2.4 Go-Live and Delta Adjustment to the Solution ...................................................................................... 51 7.2.5 Post Go-Live Maintenance .................................................................................................................... 52


4

1 INTRODUCTION

The SAP Solution Manager is positioned as an Application Management Platform for SAP centric solutions.

The major focus of SAP Solution Manager is on solution operation and optimization. It also functions as a collaborative infrastructure between the customer and SAP. This includes remote support as well as collaborative scenarios between the customer operation and the SAP service organizations.

Apart from solution operation, the SAP Solution Manager platform also provides an infrastructure for overall application management: from requirement/change request management, through design, build, test, deploy, and operation/optimization, with a major focus on change control.

Depending on the scope of the SAP Solution Manager processes being implemented and depending on the structure of the company, the SAP Solution Manager can be an easy setup or an implementation project by itself.

The following content describes one of the Application Lifecycle Management (ALM) possibilities in SAP Solution Manager for an example of a major release project (which performs changes to productively used business processes which are stored in a solution). This includes references to test capabilities, Business Process Monitoring, and Change Request Management (ChaRM). 2 GENERAL EXPLANATION

2.1 Projects and Solutions As shown in the picture below, projects and solutions are simply overviews of business process information. A project in SAP Solution Manager provides information on the future use of business processes: this includes business process redesign and new business process implementation.

Figure 2-1: Project and Solution

A solution, on the other hand, contains information on the current use of business processes in a productive environment. In the following chapters (2.2-2.5) the different project types are described. 2.2 Template Project A template project can be used to create and distribute a template. A template defines a project structure, or parts of it. Its assigned objects (documentation, test cases, IMG activities, development and training material) are available to other projects as templates.


5

Templates can be locked against changes, completely or partially, when used in several projects. In case several SAP Solution Manager systems are being used in parallel, templates can be transported from one central system (where the structures and assignments are defined) to another system. Additionally, the template project offers the possibility to translate the project structure (consisting of business scenarios, processes and business process steps). It is also possible to translate the content of the documents within the Knowledge Warehouse (KW) functionality in which they are stored. Template projects are especially suited to SAP Partner Solutions or Global Rollouts. 2.3 Implementation Project Implementation projects can be used to implement business processes in an SAP landscape. A project structure has to be created for the business processes. You can either create a new project structure, or base it on any one of the following:

one or several templates

existing project(s)

scenarios and configuration structures delivered by SAP (Business Process Repository)

an existing production solution landscape for major release changes to productively-used business scenarios

Typical Use Case in ALM: An implementation project can be used for two typical use cases: 1. Implementation of new business processes, where the scope can be defined, based on:

a. Predefined business processes from a template project. Predefined business processes can be changed according to global attributes defined in the template.

b. Normal implementation without template predefinitions (manual business process creation and documentation). Here, the business processes can be created and changed independently during the implementation.

2. Major release changes to productively used business processes stored in a solution. Those business processes can be redesigned in this project (without system upgrade) and afterwards all deltas are handed over to the solution.

Typical Use Case in ALM: A template project can be used for:

1. Definition and documentation of global business processes and their preparation for rollouts. The preparation of the global processes can comprise business process flow, transaction assignments, descriptions, documents, configuration and development assignments as well as predefinitions of test cases and training material. The more content prepared in the template, the easier the rollout from a documentation perspective.

2. As business process library connected to a modelling tool to manage changes and redesigns of business processes. Except for the business process flow, changes all other assignments like: documents, IMG objects. Test cases will be done in SAP Solution Manager. This use case can be combined with the rollout use case.


6

2.4 Maintenance Project The maintenance project can be used to keep track of changes in the productive environment (solution).

in Change Request Management. The project contains all maintenance activities and urgent corrections of a solution.

in Check Out/In for business processes, redocumentation/changes from the Solution Directory. These changes are then performed in a maintenance project linked directly to the solution.

Typical Use Case in ALM:

Assignment to a solution with activated Check Out/In functionality can be used to reflect all

changes made to productively used business processes and their documentation, during the maintenance cycles. These are typically small transactional corrections or configuration tasks.

Types of possible changes:

Urgent correction: errors and hot fixes; this usually does not have an impact on the business process documentation (back to designed behavior).

Normal corrections: pertains to all changes to a business process or a business process step which can be completed within a short of the maintenance cycle. This typically involves minor reconfiguration or additional small developments (no business process redesign). These changes are reflected in business process documentation.

2.5 Upgrade Project for Existing Systems In an upgrade project you can:

o upgrade the customization: upgrade existing functions and/or

o delta the customization: copy additional functions

Typical Use Case in ALM:

Redesign of business processes and their documentation caused by a technical upgrade of the system(s) on which they are running. The upgrade project is typically based on a solution with the

latest up-to-date process documentation.

http://help.sap.com/saphelp_sm40/helpdata/en/44/35882eba154cc4e10000000a11466f/content.htm


7

2.6 Projects and Solutions Dependencies Using application management in SAP Solution Manager creates information flow and data exchange between a project and its operational areas. The information flow is depicted in Figure 2-2, below.

Figure 2-2: Information Flow between different Projects and a Solution

The same content (business process and attached information) is reused and passed on to typical project phases, such as: design, realization, test, and go-live and also between the different project types and the solution. As such, the requirements on the business process design can be very complex. Please refer to the chapter Business Process Design. 2.7 Business Process Design Proper business process design and appropriate grouping into scenarios are key decisions when starting ALM in SAP Solution Manager. By choosing the wrong design, reusability is impaired. This affects future use of the content for purposes like testing or Business Process Monitoring. Business processes should be organized in business scenarios. Here, module-oriented scenarios can be used, or module-oriented business processes can be combined into end-to-end business scenarios. Below, two methods are described (SAP module- or End-to-End oriented), for designing business processes in SAP Solution Manager. Visibility and reporting capabilities can be improved through structure attributes. 2.7.1 Definitions of Business Scenario, Process and Step

A business process step is most commonly related to a transaction, a background job, a web UI or

similar system activities. Sometimes it makes sense to also document some activities within the

business process flow.

A business process is a collection of business process steps, grouped according to a certain

criterion like business content or SAP modules.

A business scenario is a collection of business processes to be executed one by one resulting in

the execution of an operational procedure. Scenarios can be organized by business unit, SAP

module or other kinds of grouping (e.g. template-related).

The SAP Note 1345599 describes the restrictions to size for business scenarios.


8

2.7.2 End-to-End Oriented Business Process Design In designing end-to-end business processes, you have to answer the question what “end-to-end” means for your business unit(s). This difficulty shows up at the start of business process documentation, and is mostly connected to organizational aspects (user access, organization of monitoring etc.). However, this is the most reusable business process model for documentation purposes, test capabilities, interface documentation and Business Process Monitoring. It is recommended to use structure attributes or custom attributes for documents when organizing the business process documentation in relation to SAP modules.

Figure 3-1: End-to-End Oriented Business Process Design

2.7.3 Module-Oriented Business Process Design In a module-oriented business process, business process steps which are executed one after the other in a single module are described, as shown in the graphic below.

Figure 3-2: Module-Oriented Business Process Design


9

Advantages:

Clear separation of processes by SAP Module (mostly combined with module-based business

scenarios)

Disadvantages:

Additional work to build test-related business processes

Without “interfaces” to other business processes no possibility to document system interfaces

To increase the quality and versatility of this model, it is strongly recommended to represent preceding and succeeding steps performed in different modules and to highlight the connections, as shown in the figure below. This allows documentation of interface scenarios.

Figure 3-3: Extended Module-Oriented Business Process Design

2.7.4 Definition of End-to-End Business Scenarios based on modular business processes For all customers who organize their solution documentation along SAP modules (Business Process responsibility, maintenance activities, projects) another business process model can be recommended. In this model you can combine modular build business processes (process flow within one SAP Module) to an End-to-End Business scenario (see figure 3-4).

Figure 3-4: Business Scenario Execution

To do so, use the Graphic tab at scenario level to document the order in which the business processes are to be executed. Alternatively the Business Process Blueprinting tool can be used to detailed represent the End-to-End flow within the business scenario (see figure 3-4b). All used business process variants are included into the same business scenario and represent the regional or business unit specifics. By the use of structure attributes you can make visible which processes build together an end to end scenario variant. The figure 3-4a is showing the maximal number of business processes to cover the most important Order to Cash variants collected under one business scenario. By use of attributes “Scenario Variant” you can control the visibility of the Order to Cash variants.


10

Figure 3-4a: Business Scenario Execution

As shown in figure 3-4b the green arrows connect four business process steps from several modular business processes into a business process chain. In this chain some business process steps are not involved (part of blue line connected processes). However, if you recognize the modular process they play an important role to build an information flow within a modular business process. By use of attribute “End-to-End Test relevant” you can control the visibility of the End-to-End relevant business process steps in test environment.

Figure 3-4b: Business Scenario Test Execution

Further recommended attributes could be:

- Regional variants - Business Units - SAP Module - Priority

It is recommended to use prefixes in the business process hierarchy to highlight the sequence of their execution. Beside the graphical representation this will guaranty the direct reuse in test sequences for integration test. 2.7.5 Structure Attributes As of support package 15 (EHP 1) for SAP Solution Manager 7.0, it is possible to define and use structure and object attributes. Structure attributes can support all types of filtering or reporting capabilities during typical project phases like blueprint, configuration, testing, or maintenance (after go-live). The biggest advantage of structure and object attributes is that they can be copied together with the structure, whenever the structure is reused (template Rollout Solution Maintenance).

Modular Process Flow End-to-End Process Flow


11

Once assigned, structure attributes can be adjusted with the Compare & Adjust function using the transaction SA_PROJECT_UPGRADE. This ensures that all changes made to attributes and their assignment to the business processes or business process steps are current at all times throughout the entire business process lifecycle.

Figure 3-5: Business Scenario Execution

Show how this procedure is executed in SAP Solution Manager. 2.8 Business Process Assignments Apart from documenting the business process structure in the template project, you can also document technical objects like:

Transactions: the assignment of transaction information to the business process steps determines

which transaction(s) will be used to perform a certain business process step in the managed system.

This information is usually defined during the blueprint stage, and is reused for testing, Business

Process Monitoring, business process change analysis and other functions.

Configuration Objects: all objects assigned to the configuration tab of a business process or a

business process step record the customizing views. These have to be maintained to ensure that the

business process/step runs as designed during the blueprint stage.

Development Objects: all modifications are documented as an assignment of the developed object to

the business process/step for which the modification was created. Additionally, technical

documentation for the modifications and extensions can be assigned and connected to the

development object directly.

Test Case Descriptions: The testing prescriptions for a business process step are assigned to

appropriate structures (using the test object results in a transaction assigned to the business process

step). During the creation of a test plan, the test case descriptions can be selected and brought into

the test scope as a test case (together with assigned transactions).

Training Materials: The training documents, which describe how a transaction is to be used by end

users in the context of the business process, can be assigned to the business process step on the

Training tab. These documents can be used to create Learning Maps and distribute them to end

user groups.


12

End User Groups: To document which business process step is used by which group, predefined

end user groups can be assigned. This assignment can be used as a filtering criterion for Learning

Map creation.

2.9 Document Management Document management in SAP Solution Manager uses the Knowledge Management (KM) functionality with additional functions specific to SAP Solution Manager. All documents are physically organized in so-called KW Folders. This folder (folder group) is used to check the authorization for all documents stored inside. Please refer to the chapter “6.2 Document Management” (Authorization).

Document Types

SAP Solution Manager uses predefined document types to document business processes and steps. Reusable document types can be predefined centrally by uploading document templates into SAP Solution Manager. To this end, all relevant forms and templates can be uploaded into SAP Solution Manager to make them available for later documentation during the blueprint or configuration project phase. Recommendation: Define and use customer-specific document types created in a customer name space (Z* or Y*).

Show how this procedure is executed in SAP Solution Manager.

Status Schema

Some document types require specific status values assigned to the document for specific situations. This is enabled through the status schema. You can assign exactly one status schema to exactly one document type. Recommendation: All status schemas should end with a common released status. This simplifies the handover procedure to the solution after go-live of a rollout project.


Possible assignments

Using the structure of the document types, the documentation of business scenarios, processes or steps can start. To do so, you can create new documents on several tabs in transactions SOLAR01/02 based on the document types. The assignment of documents to structures and to a specific tab is customer specific. However, a few rules should be followed concerning document assignment:

The lower the level of the information the better. This means that the more granular a document the

better suited it is to be reused.

Use of a common final status value for all document types (documents). All document types use the

same or different status schema(s). Every status schema ends with the same common final status

value.

Reuse of documents by links. In order to decrease the number of documents, you can link documents

to the same business process steps used in different business processes (basic documentation).

Additional documents describing the differences can be assigned to the occurrence selectively.


13

Business Process Step Example: Create purchasing scheduling agreement (transaction ME31L) General Documentation Tab: contains documents describing the design of transaction

ME31L (in case template management was used, functional specification or additional documentation…)

Project Documentation Tab: project related documentation for ME31L Configuration Tab: document describing the configuration needed for transaction ME31L

(Configuration objects and descriptions, Authorization Roles…) Development Tab: All developments needed to run the transaction ME31L (Technical

specifications, development forms…) Test Case Tab: Test case descriptions. All types of functional tests can be represented by

different document types. Additionally, test data documents can be assigned at business process level.

Training Materials: All kinds of training documents which will be made available to end users (simulations, presentations)

Document

Type Description Structure Tab

ZBPD Business Process Description Business Process Gen/Project. Documentation

ZFSP Functional Specification Business Process/Step Gen./Project Documentation

ZCON Configuration Description Business Process/Step Configuration

ZAUT Authorization Business Process/Step Configuration

ZTSP Technical Specification Business Process/Step Development

ZTCD Test Case Description Step Test Cases

ZUT User Training Step Training Material

ZINT Interface Description Interface Step Gen./Project Documentation

Above document types are examples. Different document types can be created to suit different requirements.

Show how this procedure is executed in SAP Solution Manager. 2.10 Procedures for Solution Documentation The information about current productively used business processes can be collected centrally into an excel file (1) by business process owners or from existing documents. In this file, the business process structure is created. In addition, logical components (in which transactions are executed), assignments of transaction codes to business process steps, and links to all relevant documents which have to be migrated to SAP Solution Manager are created here. You can upload business process descriptions, specifications, and test cases to the appropriate tabs (please refer to the previous chapter “2.9 Document Management”). After all data relevant to migration have been collected into an excel file, the file has to be converted to an XML format. Afterwards, the data can be uploaded easily using report RS_SA_PROJECT_IMPORT (2) into an existing implementation or template project.


14

This conversion from excel into xml format is a consulting solution. In the 7.1 release of SAP Solution Manager, this possibility is provided in the standard version. After these steps have been performed, the data can be entered directly into SAP Solution Manager using SOLAR01/02 where additional data like development objects, configuration views, or structure / document attributes can be assigned to the structure.

Figure 4-1: Business Process migration

After the migration content has been uploaded into SAP Solution Manager and extended by additional assignments, you can start verifying it using the Solution Documentation Assistant (SDA). To do so, the business processes have to be copied into an SDA analysis project (3). This copy will take business process structures with all assigned transaction/report information from the Transaction tab. If no further checking rules are assigned to the business processes in the analysis, the system will analyze the business processes based on the statistics for actively used transactions in the managed systems. Since the business processes were created based on the experience of business process owners and/or on existing documents, no red alerts should appear (a red alert means that the transaction has not been executed). Once the verification is completed and has yielded positive results (which means that all transactions used for business process documentation are executed in managed systems), the content can be copied into a solution (4). A few tasks need to be performed during the content copy of the documentation project into a solution:

Creation of a Solution: The business processes and their entire documentation will be stored in the solution after go-live.

Content copy from Project into Solution: It is recommended to use the work center to copy the business processes from the rollout project into the solution. Once the content is copied, all documents will turn into “Copy of…” and will get initial document status. To fix this, you can use the BAdI interface IF_EX_SOLAR_DOCUMENTS. All other objects will be copied from the project directly into the solution (together with structure and document attributes). If necessary, the logical components can be replaced by those representing the maintenance landscape.



15

Content Maintenance: To perform planned changes to the productive content, it is recommended to create and assign a maintenance project to the solution. By activating Check In/Out, the business processes cannot be changed in a solution, but exclusively in the maintenance project assigned to it (5+6). Optionally, the Change Request functionality can be activated for this maintenance project. Before each maintenance cycle, the planned normal corrections can also be reflected in the checked out structures, where documentation and further assignments can be adjusted. However, business process flow changes cannot be performed in a maintenance project. These redesigns of productively used business processes can be performed in so-called major release projects.

Show how this procedure is executed in SAP Solution Manager. In case the maintenance project is also used for change request management purposes, all logical components collected in the solution have to follow the same maintenance cycle. 2.10.1 Interface Scenarios SAP Solution Manager provides the possibility to document interfaces between systems. Interfaces can be specified in a specific interface scenario structure. For each interface, you can specify the sending and receiving system; the type and technology. On the documentation tabs, the interfaces can be documented and described. Once the interfaces are documented, you can assign them to the appropriate business processes on the Graphics tab. This assignment of one interface can be done several times for several business processes. After this, evaluating which interface is used for which process becomes very easy. Once the interface is assigned to a business process in a documentation project, and the content is used to build a solution, the interface information is still represented on the Graphics tab. However, the original information is still in the documentation project. In this case, it is recommended to resolve the external interface thereby copying the original interface into the solution.


16

3 BUILDING MAJOR RELEASE PROJECTS

Once the business processes are documented in a solution, and the maintenance is in progress, you can start using the major release method to redesign business processes. To ensure that during the redesign, all changes to the business process documentation are also reflected in the major release project, the major release project should be created in a different KW enhancement. This demands a specific procedure for the creation of a major release project. Once this has been done, the business processes which are to be redesigned can be copied into the projects (1). Choose the option “Refer Documents” to ensure that changes to existing maintenance documents are reflected in the major release project.

Figure 5-1: Creation of Major release Project and Change Reflection

It could happen that during major release project redesign of the business process the same business process content is changed in the maintenance project (2 + 2). The changes to the documents available during the process copy are immediately reflected in the major release project documentation (because all documents are linked). In case new documents were created, or new assignments were made to the business process with a maintenance project, the Compare & Adjust should be performed on the major release project separately (3+3). In the SAP Solution Manager release 7.0 this has to be done manually, in the release 7.1 you can make use of an extended Compare & Adjust functionality which detects these changes automatically. After the maintenance cycle is finished, the content can be checked in into the solution (4) and all changes made during the maintenance cycle will become visible in the solution as well. While the maintenance cycles are being performed, the major release project changes the business processes by assigning new content (5) or by completely redesigning the business processes using the old content as a starting point.


17

Figure 5-2 Major release Go-Live

When the old documents have to be adjusted (4), the system will create a copy (due to the different KW enhancement). Using this procedure ensures that current productive documentation is not changed unintentionally. Newly created documents can be signed additionally with document attributes which show in which project the document was created. After redesigning business processes, reconfiguration in the development system and testing of the content have to be prepared for deploy. The extended Compare & Adjust functionality can be run (Release 7.1) against the business process source: the solution. After the changes to the content have been detected, the appropriate business processes can be checked out into the maintenance project (6). In the maintenance project, the consolidation of the changes can be performed (7). All changes to documents can be merged into existing documents (this is the only way to ensure that the new information will be visible automatically in other projects which may run in parallel). This is also the case for process structures and their assignments (7). As soon as all deltas are adjusted, the business processes can be retested (in case of dual system landscape). Afterwards, all business processes can be checked in at the end of the maintenance cycle together with the normal maintenance content.


3.1 Document Management in a Major release Project Using a different KW Enhancement for the major release project than for the other projects/solutions has an important advantage: an initial link is established between the business process documentation (which was originally stored in the solution) and the documents available in the major release project. So, whenever the process documentation is changed in maintenance, the changes will be reflected automatically in the major release project as all documents are linked. For all business processes which have to be redesigned existing documentation can be reused. However, as soon as an existing document is clicked in change mode, it will cause the document to be copied automatically. This happens because the major release project was created in a different KW Enhancement (the system does not allow bidirectional links between two projects which are in different KW


18

Enhancements). You will be informed about the creation of the copy by a popup. The newly created copy will have the same content, but will be a physically independent object, where new information can be stored. To highlight all new documents, you can use the customer attributes for documents to assign the project ID, in which the document was created/changed. Additionally, the BAdI interface IF_EX_SOLAR_DOCUMENTS can be used to prevent the title changing to “Copy of…” and to pre-fill the document attributes for documents. During the go-live, all the redesigned processes have to be reflected in the solution content. In case other parallel projects are using the same business processes as those in consolidation, the documents are merged with the original documents. From now on, you can use the extended Compare & Adjust functionality to detect business process deltas and “new” documents. 3.2 Methodology for Major release Project (Roadmap) To document the methodology of a major release project, you can use the Roadmap functionality. Within transaction RMMAIN, you have access to standards like ASAP or Upgrade Roadmaps which SAP delivers. You can also define and create your own Roadmaps in SAP Solution Manager, using transactions RMDEF and RMAUTH. In this case, customer-specific phases, tasks, and activities can be described and customized, and accelerators can be provided (documentation on how to proceed with the phase, task or activity). Roadmaps, which are assigned at a later point in time to the major release project, can be used to store all document types which help to manage a project, such as meeting minutes. These documents will not be a part of ALM (will not be handed over to the solution).


3.3 Testing in the Major release Project As the test case descriptions were uploaded into SAP Solution Manager, they are already part of the solution. Thus, when taking the business processes into the major release project, the information is available there and is kept in sync with maintenance tasks. When redefining or redesigning a business process, the assigned test case descriptions have to be adjusted or rewritten after the new developments are implemented. You can build a test plan based on the corrected test case descriptions and the technical business process step information (transaction), tailor it into testable entities (test packages), and assign the entities to the tester. In so-called test sequences, you can rearrange the order in which test activities are to be performed, or you can rebuild business processes for specific test types. To this end, the structure attributes can easily be used to filter business processes which may be tested or regrouped separately.

Show how this procedure is executed in SAP Solution Manager. 3.4 Training Materials After successfully testing the implemented business scenarios, the end user needs to be trained. If the training information was assigned to the business processes in the solution, and if some business processes were redesigned during the major release project, the training materials can be adjusted and published/distributed using Learning Maps in SAP Solution Manager. The Learning Map functionality gives you the possibility to create end user group specific Learning Maps and distribute or publish them in a specific knowledge-transfer area.


19

The end user will get access to the documents provided in his Learning Map, without the necessity of having a user in the SAP Solution Manager. All training materials collated in the Learning Map will be shown to the end user in display mode.

Show how this procedure is executed in SAP Solution Manager. 3.5 Go-Live and Maintenance

Adjustments after Maintenance Cycles: All changes to the business scenario/process and step

content which were made during maintenance should also be reflected in the major release project.

To this end, the Compare & Adjust functionality can be used to roll all changes made in

maintenance cycles into the major release project.



20

4 CHANGE REQUEST INTEGRATION

To manage all changes made to all relevant development systems, you can use the Change Request functionality. This functionality can be used for the maintenance work and the appropriate landscape as well as for major release projects. Change Request Management in SAP Solution Manager consists of three main areas:

Change Administration: Management of all change requests, change categorization, approval

workflow, and status reporting.

Project Management: project planning, project documentation, like customizing or development

specifications and test management

Change Logistics: Customizing and Development realization, transport scheduling (seamless

integration into TMS) and transport tracking.

Combinations of these three topics allow full control over the landscape and all changes made to it. The following descriptions roughly explain the procedures of ChaRM use during maintenance and for major release projects. 4.1 ChaRM in a Maintenance Project Activating the ChaRM flag for your maintenance project allows the system to control all changes planned for the maintenance system landscape in so-called maintenance cycles. 4.1.1 Method After configuring and activating the standard ChaRM functionality in your system, you can use the workflow-based functionality. This means that when a change necessity is detected (possible integration into SAP Solution Manager service desk), the change can be requested using the Change Request. This transaction type is used for approval workflow tasks. During the workflow, the change is categorized (see 4.1.2 Change Types), and then approved or rejected by a change manager. Once the change has been approved, the system will create another transaction type (based on the categorization) called the change document. This type of document is used to perform all development activities aligned to the approved change request. Typical tasks are:

Creation of a transport request

Logon to relevant system to develop/test/validate the requested functionality

Testing

Organization of transport (depending on change type)

4.1.2 Change Types Four main Change Types, delivered in the standard version, can be used by default (as a copy of the SAP origin):

Normal Correction: This process is used to make regular corrections in your maintenance landscape and to implement planned features into your development landscape. Normal correction workflow has a strong dependency on the maintenance cycle phase.

Urgent Correction: This process is used to make an urgent correction in your production system. This transaction is only permitted within a maintenance landscape. In contrast to normal correction, urgent correction gives you the possibility to implement the correction into your production system independently of the maintenance cycle.

Test Message (Defect Correction as of 7.1): This type is used during testing, for corrective development.

Administration Changes: This type is used for all system changes which cannot be included in a typical transport request. An example would be number range.


21

4.1.3 Phase Change (Task List) Maintenance cycles can be managed and switched in a task list. The task list is a collection of all typical activities during the maintenance cycle. Activating Change Request Management for the major release project on the ChaRM tab in the transaction SOLAR_PROJECT_ADMIN creates a task list in the background. This task list records, collects, and manages all changes made to the managed system(s) or clients. The task list can be used for:

Creating transport requests and tasks

Scheduled and/or on demand import

Transporting copies

Security functionalities like Cross System Object Lock and Critical Objects Check

Retrofit for n+1 landscape

Reporting capabilities

Transporting non-ABAP objects though the integration with CTS+

The Change Tracking function of Change Request Management allows you to track everything that relates to changes within the context of a Solution Manager or an IMG project. You can track all transport requests from the system where they are created to the systems/clients into which they are imported. Within the project context, all transport requests that belong to a particular project can be tracked across all the systems in the project landscape. You can navigate into the transport logs and import queue as well as into the corresponding service transaction or task list. You can also navigate into the Solution Manager project, the satellite IMG project, or the CTS project. 4.1.4 Business Process Integration for Document Management Change Request Management can be used not only in a maintenance project, but especially in connection to a solution embedded in a check out/in procedure. By using this variant, you create a change request which is directly related to a business process or its steps. So the information about existing change requests will be available not only in the business process structure, but also in “Change Request” and thus also in “Change Document” on the Context tab. This method allows you to combine the technical work with documentation tasks by linking the Change Request Management directly to the business process documentation. The Context tab can also be used to check out the business processes into the maintenance project (taking into maintenance) directly and to check it back after successful testing. Following this procedure ensures that the change documentation is always in sync with the technical realization. 4.2 ChaRM in Major release Project It is also possible to activate the Change Request Management for major release projects. For this project type, you can choose between three different change documents (normal change, admin change and test message). Urgent corrections are not necessary as you are implementing a new functionality (all fixes for production will be performed by maintenance). 4.2.1 Method, Change Types and Phase changes (Task list) All necessary redesign tasks will be reflected by normal corrections which take longer than the normal maintenance cycle. Once you decide to perform a major release project and you copy the necessary business processes into it, you will be able to assign the appropriate business process or business process step to the Context tab of the normal correction. In this way, the connection between the changes and the documentation is guaranteed. Please refer to the descriptions in the chapters 4.1.2 Change Types (not „urgent correction‟) and 4.1.3 Phase Change (Task list). It should be noted, however, that using Change Request Management requires additional configuration of SAP Solution Manager. This includes ChaRM-specific customizing (activation or standard ChaRM


22

customizing) as well as system landscape information in SAP Solution Manager, such as the definition of logical systems: the source, target, and production. 5 ORGANIZATIONAL ASPECTS FOR MAJOR RELEASE PROJECTS

Using SAP Solution Manager as an implementation tool requires ensuring the quality of all activities performed in this tool. A proven method is to establish a quality assurance team which ensures that all basic activities in SAP Solution Manager are performed correctly.

Governance is needed in several areas:

System Landscape: The system landscape information is the foundation for nearly all SAP Solution

Manager functionalities. The quality assurance team should have access to this area, be authorized

to create and change managed systems, and also be able to create all necessary RFCs for all

appropriate clients. The systems can then be grouped into logical components. These logical

components are used for all current and future projects.

Standard and Design Definitions: To ensure the consistency of all standards used in the projects,

like document types, status schemas, structures, and document attributes, the team should also

attend to design questions, decisions concerning building of the ALM in SAP Solution Manager, and

to the decisions on which non-SAP tools have to be used for ALM purposes.

The aim of this team should also be to ensure the correctness and quality of the business process

design. Business processes should be kept granular (please refer to the chapter “2.7 Business

Process design”) and correct assignment handling guaranteed.

Possible services for incoming projects:

Project Consulting (which processes, project type and so on). Before a new project starts, the

quality assurance team could discuss with their project management how to perform the project

and how SAP Solution Manager can support them for this purpose. Possible reuse of existing

business processes or documents should be discussed.

Project Creation. As a service to the project team, SAP can offer to take over central activities in

SAP Solution Manager, like creating a project or assigning a project landscape. This will also

ensure the quality of performed tasks.

Standards Review. Definition of quality control points (Quality Gate) and regular checks of

business processes and documentation quality.

Business Process Design Consulting. Assurance that all new projects have the same design and

follow the same procedures to allow reuse in ALM.

SAP Solution Manager Consulting. This central team is the main contact point for all requests

regarding SAP Solution Manager functionalities. All customizing and/or development activities

have to be approved and activated by this team.

Knowledge Transfer. Every new project team has to be trained on how to use SAP Solution

Manager functionalities: especially on how to handle documents, make developments, and

clarify customizing tasks.


23

6 AUTHORIZATIONS

6.1 Projects Concerning restrictions, you have two options: Restrictions between Projects: You could use the authorization object S_PROJECT. Depending on the number of implementation projects, you could: 1) Assign the authorization for specific projects to the object (PROJECT_ID Project name) to which the

user has access. 2) Work with a predefined name space for the projects (e.g., Implementation Projects begins with I;

template projects with T). Afterwards, you prepare the object S_PROJECT for several users (one group has PROJECT_ID = I* and the other PROJECT_ID =T*).

Authorization object S_PROJECTS and S_PROJECT can be found, for example, in the role SAP_SOLAR_PM. Please copy the role and set it up. Restrictions within a Project (Structure): The setting "Restrict changes to nodes in project to assigned team members" can be activated in SOLAR_PROJECT_ADMIN on the Team Members tab and allows changes to nodes in SOLAR01/02 where the user is assigned. All other nodes will only be in display mode. 6.2 Document Management Standard Solution: Restrictions within a Project This solution is based on a standard functionality of SAP Solution Manager which restricts the ability to change nodes in a project to assigned team members. This flag can be set in transaction SOLAR_PROJECT_ADMIN on the tab Project Member. If you check this box, only team members who are assigned in the Administration tab can work on the nodes of a project structure. Other team members can only open the tab in display mode. You need to change the authorization for the tab (authorization object AI_SA_TAB) to enable assigned team members to work in the tab. Using additional KW Folders

You can use different KW folders within one project. One KW Folder can be assigned to exactly one folder group. The authorization for all included documents is checked against this folder group. Please follow the description below to set these up in your system.

1) Please start transaction SI23, for the area SAP Solution Architect, and go to the menu Settings Folder Groups. In this view, you can create a folder group for the new folder.

2) Afterwards, start transaction SI80 and select the folder in which the folder group will be changed. Go to the menu Folder Attributes Change (the context where you currently are should be equal to the origin context in the attributes of the folder; otherwise, it will not be possible to change the folder group). Now you should be able to choose the folder group (created in step 1), using F4-help. Alternatively, you can create a new KW folder and assign the folder group to it.

3) The folder group can be assigned to the authorization object S_IWB. The parameter IWB_FLDGRP is usually equal to the project name of the folder created by the system during project creation. Afterwards, you should be able to move special "top secret" documents to the newly created folder, using the Attribute popup of the document and the button “Replace Folder”.

Alternatively, the assignment is also possible when saving the document in Method HANDLE_EXIT_BEFORE_SAVE in Class CL_SA_IO_DOC, using KW function modules.


24

7 SETUP/CONFIGURATION AND PROCEDURES

7.1 General Configuration

7.1.1 Definition of System Landscape – SMSY SAP Solution Manager is the central access point for your landscape. If a new Managed System is to be included, some basic configuration needs to be executed in transaction SMSY either manually or automatically. The following instructions describe how to create RFC connections between SAP Solution Manager and the Managed System. For details on how to maintain a system in SAP Solution Manager, please refer to the basic configuration guide of SMSP (Solution Manager Starter Pack).

What to do Screen Display

Select system and client from SMSY in SAP

Solution Manager

For a new client, no RFC connections are established. Select the client and click button „Generate RFC with Assistant‟.


25


Follow the wizard and use default values for creating RFC connections.

Select ‘Continue’.


26


Create users for RFC connection, select „Continue‟.

Create users for RFC connection, select „Continue‟.


27


Select „Continue‟.



28

7.1.2 Project Standards To use document management in SAP Solution Manager, some adjustments and customization is needed.



The system logon screen will appear. Input the user name and password to generate the RFC connection. Note: this user should have authorization for RFC creation as well as for Trusted RFC. (Please refer to SMSP configuration guide for details)


29

7.1.2.1 Definition of Document Types

At the least, the following document types should be available in the customer system (example):

ZBPD: Business Process Description

ZCON: Configuration Description

ZFSP: Functional Specification

ZTSP: Technical Specification

ZUT: User Training

ZUAT: User Acceptance Test

ZAUT: Authorization

Where to configure/how to do:


Document Types (transaction SOLAR_PROJECT_ADMIN menu Goto Project

Template Implementation Project, Template Project…)

Select Documentation Type Tab


30


Define Documentation Type (here: ZBPD)

Upload the template into the Documentation Type

New template has to be released in order to be available for later use


31

7.1.2.2 Definition of Status Schema

Document types are assigned to customer specific status schema(s). All status schemas contain customer defined status values like:

Z_NEW

Z_PROGRESS

Z_APPROVAL

Z_RELEASED Status value Z_RELEASED shall be included into the table for Read Authorization. Please create one common Release status value for all status schemas. Where to configure/how to do:


Possible corrections on the Documentation template

Further settings for the Documentation Type like: global availability, several assignments possible, relevance for Blueprint document or status schema assignment.


32


Status Value Definition (transaction SPRO)

Press “New Entries” and create Values

Save and record in a transport

Assign Status Values to Read Authorization


33


Select from the list of available Status Values

Definition of Status Schema

Create the Status Schema by pushing “New Entry”

Decide which entries shall be part of Status Schema


34

Return to topic content


Assign Status Schema to Documentation Types

Make Documentation Type available for project type


35

7.1.2.3 Adjustments to Blueprint Document

The functionality for creating the Business Blueprint is provided for all project types in SAP Solution Manager. Using it, you can create the blueprint document based on the content of all blueprint-relevant documents collected for the rollout project (process description, functional specification or similar). The template of the blueprint document can be adjusted in customizing as shown. Where to configure/how to do:


Download of SOLARBLUEPRINT.DOC and correction (replacement of Logo).


36


Change the template

Upload the template from the storage location, where it was changed

From now on the customer version will be used to create a blueprint document.


37

7.1.2.4 Structure/Object Attributes

Structure attributes are typically used for filtering purposes in templates, rollout projects, test plans and also as a reporting help, in a solution. For this, custom-defined tables can be used with a defined range of possible input values. Where to configure/how to do:


Customization in transaction SPRO

Creation of Structure/Object attribute “Area”


38


Decide which entries will be used for the attribute (table assignment)

Assign attribute Z_SAP_AREA to objects .

Attribute will be available for structure nodes


39



Assign attribute Z_COMPONENT to object Project and Solution Node

Set the other options

Result: the attribute is

available for business process structures


40

7.1.2.5 Customer Attributes for Documents

To improve reporting of documents in the design or configuration phase of your project, it is possible to create customer attributes for documents. The advantage of these attributes is their ALM accomplishment. This means that those attributes will be passed to all document copies of the original documents. One possibility for such an attribute is the Project ID under which the document was created/changed. The information on who changed the attribute and when it was changed will be logged in the history of the document. The customization described below is done with the example of Project ID as an attribute. Where to configure/how to do:


Create an attribute through transaction SPRO

Create an attribute “Project ID”


41


Assignment of a table and field to which the attribute will relate

Activate the attribute

Record changes in a package .

Assign the newly created custom attribute to PHIO class SOLARGENSRC_V


42

After creating the attributes, it might be necessary to refresh the buffer on servers (transaction SE33 for context IWB_CLASS_PROPS). The same activities can also be performed for the attribute “SAP Component” to detect which documents belong to which SAP area.


New attribute has to be assigned to instance attributes

After saving, the new customization has to be

activated

Result in SOLAR01/02 for document


43

7.2 Major release Project Creation To use the major release project in SAP Solution Manager, there are several steps to be maintained in the system:

Project Creation in different KW Enhancement

System landscape maintenance

Business process structure copy

Behavior of assignments: - Document - Transactions - Configuration - Structure Attributes - Document Attributes


major release Project Creation

Enter the T-Code SOLAR_PROJECT_ADMIN and then

you will go to the project administration screen where you can start to create the project.

Maintain Mandatory Fields and Save

You can assign the solution to the project when the project deals with the same system landscape


44


During saving, the KW Enhancement has to be changed from KWCUST 620 to any other one

Business Process Assignment

a. Navigate to the business blueprint screen

a. Business processes will be copied into the project:


45


b. together with all assignments on all tabs

Document Management in a Major release Project

a. All Documents are linked from the solution into the project. The picture shows a change to a document in the maintenance project assigned to the solution. Document attributes are changed (project ID)

b. Changes made in maintenance will also be reflected in the major release project


46



c. As soon as the document is changed, the system will create a copy. Changes made to this document will not be reflected in the solution/ maintenance documentation.

At the end of the major release project, the document content is merged with the original document stored in the solution (through maintenance). This will be visible in all other potential major release projects


47

7.2.1 Compare & Adjust: From Maintenance to Major release project Use the Compare & Adjust procedure after every maintenance cycle:


New Documentation is created during maintenance

Start Compare & Adjust (transaction SA_PROJECT_UPGRADE) for the major release

project


48


7.2.2 Testing in the Major release Project During the project implementation phase, the test phase is prepared. Existing test cases (coming from the solution) can be reused or redesigned. Afterwards, test plans and test packages can be generated according to business processes and the progress of testing and reporting can be tracked. Test Case Assignment in a Project In a major release project, it is possible to assign or redesign test cases, ECATT scripts, or to assign test descriptions to business scenarios, business processes or business process steps. These test documents can be reused for test plan creation.


Results will be displayed in the implementation project.

Adjustment can be started. You can adjust all changes or select changes you want to take over (depending on global attributes). Afterwards, select „Copy’ and „Complete’.


49


7.2.3 Learning Map


Assign test documents to a business process step, on tab Test Case.

Test Workbench

Test Workbench is embedded in SAP Solution Manager for Test Management. After the assignment of test documents, a test plan can be generated in the Test Workbench and test packages can be created for different Testers.


Create a Learning Map using transaction SOLAR_LEARNING_MAP


50


Create Chapter and Units

Search for training material and assign these to the units.


51


7.2.4 Go-Live and Delta Adjustment to the Solution


Send to End User


For the handover of redesigned Business Processes, the extended Compare &Adjust can be used


52


7.2.5 Post Go-Live Maintenance A solution is created after go-live. From now on, all operations and maintenance are executed on the solution instead of the project.

Take over changes


Maintenance Project

To change the business process structure in a solution, it is recommended to use a maintenance project instead of making changes directly to the solution Assign a maintenance project to a solution, and then enable the „Check-out/Check-in‟ functionality.


53



Check-In / Check-Out

After the maintenance project is assigned to one solution, it is no longer possible to change the business structure, document, or landscape directly in the solution.

Any necessary changes will be checked-out into the maintenance project and checked-in after changes. The maintenance project for this solution can be checked in into the Solution Directory. Use the „Check-in/Check-out‟ button in the Solution Directory and maintenance project, to perform post go-live maintenance.

© 2012 SAP AG. All rights reserved.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP

BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP

products and services mentioned herein as well as their respective

logos are trademarks or registered trademarks of SAP AG in Germany

and other countries.

Business Objects and the Business Objects logo, BusinessObjects,

Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and

other Business Objects products and services mentioned herein as

well as their respective logos are trademarks or registered trademarks

of Business Objects Software Ltd. Business Objects is an SAP

company.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL

Anywhere, and other Sybase products and services mentioned herein

as well as their respective logos are trademarks or registered

trademarks of Sybase Inc. Sybase is an SAP company.

Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services are

registered trademarks of Crossgate AG in Germany and other

countries. Crossgate is an SAP company.

All other product and service names mentioned are the trademarks of

their respective companies. Data contained in this document serves

informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials

are provided by SAP AG and its affiliated companies ("SAP Group")

for informational purposes only, without representation or warranty of

any kind, and SAP Group shall not be liable for errors or omissions

with respect to the materials. The only warranties for SAP Group

products and services are those that are set forth in the express

warranty statements accompanying such products and services, if

any. Nothing herein should be construed as constituting an additional

warranty.

www.sap.com