best practice business process redesign in solution manager

Business Process Redesign

in SAP Solution Manager

Application Lifecycle

Management

Business Process Long-Term Redesign

© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf

Title: Long-Term Implementation Version: 2.0

Date: 23.08.2011

of 59

Copyright

© 2011 by SAP AG.

Neither this document nor any part of it may be copied or reproduced in any form or by any means, or translated into another language, without the prior consent of SAP Active Global Support. All rights reserved. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, 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 S.A. in the United States and in other countries. Business Objects is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serve informational purposes only. National product specifications may vary. These materials are subject to change without notice. SAP AG and its affiliated companies („SAP Group“) provide these materials 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.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

Index

Copyright .............................................................................................................................................. 2

1 Introduction .................................................................................................................................... 5

2 General Explanation ..................................................................................................................... 5

2.1 Projects and Solutions ......................................................................................................... 5

2.2 Template Project ................................................................................................................... 6

2.3 Implementation Project ........................................................................................................ 6

2.4 Maintenance Project ............................................................................................................. 7

2.5 Upgrade Project for Existing Systems ............................................................................... 7

2.6 Projects and Solutions Dependencies ............................................................................... 8

2.7 Business Process Design .................................................................................................... 8

2.8 Business Process Assignments ....................................................................................... 12

2.9 Document Management .................................................................................................... 13

2.10 Procedures for Solution Documentation ......................................................................... 16

2.10.1 Interface Scenarios ..................................................................................................... 18

3 Building Long-Term Projects ..................................................................................................... 19

3.1 Document Management in a Long-Term Project ........................................................... 21

3.2 Methodology for Long-term Project (Roadmap) ............................................................ 21

3.3 Testing in the Long-Term Project ..................................................................................... 22

3.4 Training Materials ............................................................................................................... 22

3.5 Go-Live and Maintenance ................................................................................................. 23

4 Change Request Integration ..................................................................................................... 23

4.1 ChaRM in a Maintenance Project .................................................................................... 23

4.1.1 Method .......................................................................................................................... 23

4.1.2 Change Types ............................................................................................................. 24

4.1.3 Phase Change (Task List) ......................................................................................... 24

4.1.4 Business Process Integration for Document Management .................................. 25

4.2 ChaRM in Long-Term Project ........................................................................................... 25

4.2.1 Method, Change Types and Phase changes (Task list) ....................................... 25

5 Organizational Aspects for Long-Term Projects in SAP Solution Manager ...................... 25

6 Authorizations .............................................................................................................................. 27

6.1 Projects................................................................................................................................. 27


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

6.2 Document Management .................................................................................................... 27

7 Setup/Configuration and Procedures ...................................................................................... 29

7.1 General Configuration ........................................................................................................ 29

7.1.1 Definition of System Landscape – SMSY ............................................................... 29

7.1.2 Project Standards ....................................................................................................... 33

7.1.3 Definition of Document Types ................................................................................... 34

7.1.4 Definition of Status Schema ...................................................................................... 36

7.1.5 Adjustments to Blueprint Document ........................................................................ 40

7.1.6 Structure/Object Attributes ........................................................................................ 42

7.1.7 Customer Attributes for Documents ......................................................................... 45

7.2 Long-Term Project Creation .............................................................................................. 48

7.2.1 Compare & Adjust: From Maintenance to Long-Term project ............................ 53

7.2.2 Testing in the Long-Term Project ............................................................................. 54

7.2.3 Learning Map ............................................................................................................... 56

7.2.4 Go-Live and Delta Adjustment to the Solution ....................................................... 57

7.2.5 Post Go-Live Maintenance ........................................................................................ 58


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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 long-term 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


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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.

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:

o one or several templates o existing project(s) o scenarios and configuration structures delivered by SAP (Business Process

Repository) o an existing production solution landscape for long-term changes to

productively-used business scenarios

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.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59


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. Long term 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.

2.4 Maintenance Project

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

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

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


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:

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

o 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

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


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59


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.

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.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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.1 Definitions of Business Scenario, Process and Step

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

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

a certain criterion like business content or SAP modules.

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

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


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

2.7.1.3 Module-Oriented Business Process Design

In a module-oriented business process you typically describe business process steps that

belong together and that are executed one after the other in a single module. However, to

increase the quality and the number of further possibilities in SAP Solution Manager, it is

recommended to represent preceding or succeeding steps also (documentation of Interface

Scenarios) as shown in the following graphic.

Figure 3-2 Module-Oriented Business Process Design

Advantages:

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

business scenarios)

Disadvantages:

o Additional work to build test-related business processes

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

interfaces

Therefore, a better option is to document the connections to other business processes,

highlighting interfaces, as shown in the following Figure 3-3.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

Figure 3-3 Extended Module-Oriented Business Process Design

2.7.1.4 Business Scenario Definition

To combine both models, you can compose end-to-end business scenarios from a mixture of

module-oriented business processes. These are executed one after the other in order to

perform a business activity.

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.

How business scenarios are organized also determines how to roll them out using templates

(Template as Information Provider).

2.7.1.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 after go-live in maintenance. 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).

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


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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:

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

o Configuration Objects: all objects, assigned to the configuration tab of a business

process or a business process step, document the customizing views. These have to

be maintained to ensure that the business process/step runs, as designed during the

blueprint stage.

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

o 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).


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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

o 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*).


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:


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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

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)

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

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

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


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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

different requirements.



© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

2.10 Procedures for Solution Documentation

The information about current productively used business processes can be collected

centrally by business process owners or from existing documents into an excel file (1). In this

file, the business process structure is created. In the same file, an assignment of transaction

codes to business process steps, logical components (in which the transaction is executed),

and links to all relevant documents which have to be migrated to SAP Solution Manager are

created. Typically, you can upload business process descriptions, specifications, and test

cases to the appropriate tabs (please refer to the previous chapter “2.8.1 Document

Management”).

After all data relevant to migration have been collected into an excel file, the data have 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.

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


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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:

o Creation of a Solution: The business processes and their entire documentation will

be stored in the solution after go-live.

o 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 into the solution directly (together with

structure and document attributes). If necessary, the logical components can be

replaced by those representing the maintenance landscape.


o 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 long-term projects.



© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

3 Building Long-Term Projects

Once the business processes are documented in a solution, and the maintenance is in

progress, you can start using the long-term method to redesign business processes. To

ensure that during the redesign, all changes to the business process documentation are also

reflected in the long-term project, the long-term project should be created in a different KW

enhancement. This demands a specific procedure for the creation of a long-term 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 long-term project.

Figure 5-1 Creation of Long-term Project and Change Reflection

It could happen that during long-term 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 long-term

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 long-term 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 long-term 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.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

Figure 5-2 Long-Term 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.



© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

3.1 Document Management in a Long-Term Project

Using a different KW Enhancement for the long-term 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 long-term project. So, whenever the process documentation is

changed in maintenance, the changes will be reflected automatically in the long-term 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 long-term project was

created in a different KW Enhancement (the system does not allow bidirectional links

between two projects which are in different KW 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 Long-term Project (Roadmap)

To document the methodology of a long-term 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 long-term 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).



© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

3.3 Testing in the Long-Term 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 long-term 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.


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 long-term 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.

The end user will get access to the documents provided in his Learning Map, without

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



© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

3.5 Go-Live and Maintenance

o 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 long-term project. To this end, the Compare & Adjust functionality

can be used to roll all changes made in maintenance cycles into the long-term

project.

o


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 long-term 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 long-term 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


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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

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 long-term 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.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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 Long-Term Project

It is also possible to activate the Change Request Management for long-term 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 long-term 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 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 Long-Term Projects in SAP Solution

Manager The use of SAP Solution Manager as an implementation tool also brings about the need to

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

There are several areas where governance is needed:

o System Landscape: The system landscape information is the foundation for nearly

all SAP Solution Manager functionalities. The quality assurance team should have


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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.

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

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

business process design. While keeping the business processes granular (please

refer to the chapter “Business Process design”), correct assignment handling has to

be guaranteed as well.

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


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

Follow the wizard

and use default

values for

creating RFC

connections.

Select „Continue‟.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

Create users for

RFC connection,

select „Continue‟.

Create users for

RFC connection,

select „Continue‟.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59




© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59


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)

7.1.2 Project Standards

To use document management in SAP Solution Manager, some adjustments and

customization is needed.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

7.1.3 Definition of Document Types

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

o ZBPD: Business Process Description

o ZCON: Configuration Description

o ZFSP: Functional Specification

o ZTSP: Technical Specification

o ZUT: User Training

o ZUAT: User Acceptance Test

o ZAUT: Authorization

Where to configure/how to do:


Document

Types

(transaction

SOLAR_PROJ

ECT_ADMIN

menu Goto

Project

Template

Implementation

Project,

template

project…)

Select

Documentation

Type Tab


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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.

7.1.4 Definition of Status Schema

Document types are assigned to customer specific status schema(s). All status schemas

contain customer defined status values like:

o Z_NEW

o Z_PROGRESS

o Z_APPROVAL

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



© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59


Status Value

Definition

(transaction

SPRO)

Press “New

Entries” and

create Values

Save and record

in a transport

Assign Status

Values to Read

Authorization


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

Select from the

list of available

Status Values

Definition of

Status Schema

Create the Status

Schema by

pushing “New

Entry”


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

Decide which

entries shall be

part of Status

Schema

Assign Status

Schema to

Documentation

Types

Make

Documentation

Type available for

project type

Return to topic content


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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



Download of

SOLARBLUEPRINT

.DOC and

correction

(replacement of

Logo).


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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



Customization in

transaction SPRO

Creation of

Structure/Object

attribute “Area”


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

Assign attribute

Z_COMPONENT to

object Project and

Solution Node

Set the other

options

Result: the

attribute is

available for

business process

structures



© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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



Create an

attribute through

transaction SPRO

Create an

attribute “Project

ID”


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

New attribute has

to be assigned to

instance

attributes

After saving, the new

customization has

to be activated

Result in

SOLAR01/02 for

document

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.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

7.2 Long-Term Project Creation

To use the long-term project in SAP Solution Manager, there are several steps to be

maintained in the system:

o Project Creation in different KW Enhancement

o System landscape maintenance

o Business process structure copy

o Behavior of assignments:

- Document - Transactions - Configuration - Structure Attributes - Document Attributes


long-term Project Creation

Enter the T-Code

SOLAR_PROJEC

T_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


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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

b. Go to the

structure tab,

select the Source: “Solution” and

use F4 Help to copy business

scenarios or

processes from the solution


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

Choose the

option: “Refer to

Documents”

System landscape

will be copied

from the solution into the long-term

project

Business Process Assignments

a. Business

processes will be copied into the

project:


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

b. together with

all assignments

on all tabs

Document Management in a long-term 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)


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

b. Changes made in maintenance

will also be reflected in the

long-term project

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

long-term project,

the document

content is merged

with the original

document stored

in the solution

(through

maintenance).

This will be visible

in all other

potential long-

term projects



© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

7.2.1 Compare & Adjust: From Maintenance to Long-Term 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 long-

term project


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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


7.2.2 Testing in the Long-Term 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 long-term 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.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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.



© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

7.2.3 Learning Map


Create a Learning Map

using transaction

SOLAR_LEARNING_

MAP

Create Chapter and

Units

Search for training

material and assign

these to the units.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

Send to End User


7.2.4 Go-Live and Delta Adjustment to the Solution


For the handover of

redesigned Business

Processes, the

extended Compare

&Adjust can be used


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

Take over changes


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.

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.


© 2011 SAP AG

Dietmar Hopp 16

D-69190 Walldorf


Date: 23.08.2011

of 59

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.


best practice business process redesign in solution manager

Documents

business process

common final

business process

term implementation

business process

business process

badi interface

term redesignselect