Business Process Redesign_SOLMANALM

7/25/2019 Business Process Redesign_SOLMANALM

1/54

Business Process Redesign in SAP Solution

Manager Application Lifecycle Management


2/54

Business Process Major release Redesign

2

TABLE OF CONTENTS

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

2 GENERAL EXPLANATION ........................................................................................................................... 42.1 Projects and Solutions .............................................................................................................................. 42.2 Template Project ........................................................................................................................................ 42.3 Implementation Project ............................................................................................................................. 52.4 Maintenance Project .................................................................................................................................. 62.5 Upgrade Project for Existing Systems .................................................................................................... 62.6 Projects and Solutions Dependencies .................................................................................................... 72.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 ....................................................................................... 82.7.3 Module-Oriented Business Process Design ............................................................................................. 82.7.4 Definition of End-to-End Business Scenarios based on modular business processes ............................ 92.7.5 Structure Attributes ................................................................................................................................. 102.8 Business Process Assignments ............................................................................................................ 112.9 Document Management .......................................................................................................................... 122.10 Procedures for Solution Documentation ............................................................................................ 132.10.1 Interface Scenarios ............................................................................................................................... 15

3 BUILDING MAJOR RELEASE PROJECTS ................................................................................................ 163.1 Document Management in a Major release Project ............................................................................. 173.2 Methodology for Major release Project (Roadmap) ............................................................................. 18

3.3 Testing in the Major release Project ...................................................................................................... 18

3.4 Training Materials .................................................................................................................................... 183.5 Go-Live and Maintenance ....................................................................................................................... 19

4 CHANGE REQUEST INTEGRATION .......................................................................................................... 204.1 ChaRM in a Maintenance Project ........................................................................................................... 204.1.1 Method .................................................................................................................................................... 204.1.2 Change Types ........................................................................................................................................ 204.1.3 Phase Change (Task List) ...................................................................................................................... 214.1.4 Business Process Integration for Document Management .................................................................... 214.2 ChaRM in Major release Project ............................................................................................................. 214.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 ..................................................................................................................................................... 236.2 Document Management .......................................................................................................................... 23

7 SETUP/CONFIGURATION AND PROCEDURES ....................................................................................... 247.1 General Configuration ............................................................................................................................. 247.1.1 Definition of System LandscapeSMSY ............................................................................................... 24 7.1.2 Project Standards .................................................................................................................................. 287.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/54


3

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

7.2 Major release Project Creation .............................................................................................................. 437.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 ......................................................................................................................................... 497.2.4 Go-Live and Delta Adjustment to the Solution ...................................................................................... 517.2.5 Post Go-Live Maintenance .................................................................................................................... 52


4/54


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 ascollaborative scenarios between the customer operation and the SAP service organizations.

Apart from solution operation, the SAP Solution Manager platform also provides an infrastructure for overallapplication 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 thestructure of the company, the SAP Solution Manager can be an easy setup or an implementation project byitself.

The following content describes one of the Application Lifecycle Management (ALM) possibilities in SAPSolution Manager for an example of a major release project (which performs changes to productively usedbusiness 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: thisincludes 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 productiveenvironment.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, orparts of it. Its assigned objects (documentation, test cases, IMG activities, development and training material)are available to other projects as templates.


5/54


5

Templates can be locked against changes, completely or partially, when used in several projects. In caseseveral SAP Solution Manager systems are being used in parallel, templates can be transported from onecentral system (where the structures and assignments are defined) to another system.

Additionally, the template project offers the possibility to translate the project structure (consisting ofbusiness scenarios, processes and business process steps). It is also possible to translate the content of thedocuments 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 projectstructure has to be created for the business processes. You can either create a new project structure, orbase 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 businessscenarios

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 businessprocesses can be changed according to global attributes defined in the template.

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

2. Major release changes to productively used business processes stored in a solution. Thosebusiness processes can be redesigned in this project (without system upgrade) andafterwards 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 developmentassignments as well as predefinitions of test cases and training material. The morecontent prepared in the template, the easier the rollout from a documentationperspective.

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


6/54


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. inCheck Out/In forbusiness processes,redocumentation/changes from the Solution

Directory. These changes are then performed in a maintenance project linked directly tothe 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 themaintenance 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 processstep which can be completed within a short of the maintenance cycle. This typicallyinvolves minor reconfiguration or additional small developments (no business processredesign). 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 functionsand/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 thesystem(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.htmhttp://help.sap.com/saphelp_sm40/helpdata/en/44/35882eba154cc4e10000000a11466f/content.htmhttp://help.sap.com/saphelp_sm40/helpdata/en/44/35882eba154cc4e10000000a11466f/content.htmhttp://help.sap.com/saphelp_sm40/helpdata/en/44/35882eba154cc4e10000000a11466f/content.htmhttp://help.sap.com/saphelp_sm40/helpdata/en/44/35882eba154cc4e10000000a11466f/content.htmhttp://help.sap.com/saphelp_sm40/helpdata/en/44/35882eba154cc4e10000000a11466f/content.htmhttp://help.sap.com/saphelp_sm40/helpdata/en/44/35882eba154cc4e10000000a11466f/content.htm


7/54


7

2.6 Projects and Solutions Dependencies

Using application management in SAP Solution Manager creates information flow and data exchangebetween 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 thesolution. As such, the requirements on the business process design can be very complex. Please refer to thechapterBusiness Process Design.

2.7 Business Process Design

Proper business process design and appropriate grouping into scenarios are key decisions when startingALM in SAP Solution Manager. By choosing the wrong design, reusability is impaired. This affects future useof the content for purposes like testing or Business Process Monitoring. Business processes should beorganized in business scenarios. Here, module-oriented scenarios can be used, or module-oriented businessprocesses 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 throughstructure attributes.

2.7.1 Definit ion s of Bu sin ess Scenario, Process and Step

Abusiness process stepis 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.

Abusiness processis 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/54


8

2.7.2 End-to-End Oriented Bu siness Pro cess Design

In designing end-to-end business processes, you have to answer the question what end-to-endmeans foryour 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 mostreusable business process modelfor documentation purposes, test capabilities, interface documentation andBusiness Process Monitoring. It is recommended to usestructure attributesorcustom attributes fordocumentswhen 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 Busin ess Process Design

In a module-oriented business process, business process steps which are executed one after the other in asingle module are described, as shown in the graphic below.

Figure 3-2: Module-Oriented Business Process Design


9/54


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 andsucceeding steps performed in different modules and to highlight the connections, as shown in the figurebelow. This allows documentation of interface scenarios.

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

2.7.4 Def in i tion o f End-to-End Business Scenar ios based on m odular bus iness proc esses

For all customers who organize their solution documentation along SAP modules (Business Processresponsibility, maintenance activities, projects) another business process model can be recommended. Inthis model you can combine modular build business processes (process flow within one SAP Module) to anEnd-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 tobe 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 regionalor business unit specifics. By the use of structure attributes you can make visible which processes buildtogether an end to end scenario variant.

The figure 3-4a is showing the maximal number of business processes to cover the most important Order toCash variants collected under one business scenario. By use of attributes Scenario Variantyou can controlthe visibility of the Order to Cash variants.


10/54


10

Figure 3-4a: Business Scenario Execution

As shown in figure 3-4b the green arrowsconnect four business process steps from several modularbusiness processes into a business process chain. In this chain some business process steps are notinvolved (part of blue line connectedprocesses). However, if you recognize the modular process they playan important role to build an information flow within a modular business process. By use of attribute End-to-End Test relevantyou can control the visibility of the End-to-End relevant business process steps in testenvironment.

Figure 3-4b: Business Scenario Test Execution

Further recommended attributes could be:- Regional variants

- Business Units- SAP Module- Priority

It is recommended to use pref ixes in the business process hierarchyto highlight the sequence of theirexecution. Beside the graphical representation this will guaranty the direct reuse in test sequences forintegration test.

2.7.5 Structure A ttr ibutes

As of support package 15 (EHP 1) for SAP Solution Manager 7.0, it is possible to define and use structureand object attributes. Structure attributes can support all types of filtering or reporting capabilities duringtypical 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, wheneverthe structure is reused (template Rollout SolutionMaintenance).

Modular Process Flow

End-to-End Process Flow


11/54


11

Once assigned, structure attributes can be adjusted with the Compare & Adjustfunction using thetransaction SA_PROJECT_UPGRADE. This ensures that all changes made to attributes and theirassignment to the business processes or business process steps are current at all times throughout theentire business process lifecycle.

Figure 3-5: Business Scenario Execution

Show how thisprocedureis executed in SAP Solution Manager.

2.8 Business Process Assignments

Apart from documenting the business process structure in the template project, you can also documenttechnical 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 ofthe developed object tothe 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 fora 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, thetest case descriptionscan 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/54


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 withadditional functions specific to SAP Solution Manager. All documents are physically organized in so-calledKW 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 SolutionManager. To this end, all relevant forms and templates can be uploaded into SAP Solution Manager to makethem available for later documentation during the blueprint or configuration project phase.

Recommendat ion: 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 isenabled through the status schema. You can assign exactly one status schema to exactly one documenttype.

Recommendat ion: 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 canstart. To do so, you can create new documents on several tabs in transactions SOLAR01/02 based on thedocument types.

The assignment of documents to structures and to a specific tab is customer specific. However, a few rulesshould 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/54


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 Documentat ion Tab: project related documentation for ME31LConf igurat ion 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 beassigned at business process level.

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

Document

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


2.10 Procedures for Solution Documentation

The information about current productively used business processes can be collected centrally into an excelfile (1) by business process owners or from existing documents. In this file, the business process structure iscreated. In addition, logical components (in which transactions are executed), assignments of transactioncodes to business process steps, and links to all relevant documents which have to be migrated to SAPSolution Manager are created here. You can upload business process descriptions, specifications, and testcases to the appropriate tabs (please refer to the previous chapter2.9Document Management).

After all data relevant to migration have been collected into an excel file, the file has to be converted to anXML format. Afterwards, the data can be uploaded easily using report RS_SA_PROJECT_IMPORT (2) intoan existing implementation or template project.


14/54


14

This conversion from excel into xml format is a consulting solution. In the 7.1 release of SAP SolutionManager, 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/02where additional data like development objects, configuration views, or structure / documentattributes 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 additionalassignments, you can start verifying it using the Solution Documentation Assistant (SDA). To do so, thebusiness 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 checkingrules are assigned to the business processes in the analysis, the system will analyze the business processesbased on the statistics for actively used transactions in the managed systems. Since the business processeswere created based on the experience of business process owners and/or on existing documents, no redalerts 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 asolution (4). A few tasks need to be performed during the content copy of the documentation project into asolution:

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

Content copy from Project into Solution: It is recommended to use the work center to copy thebusiness processes from the rollout project into the solution. Once the content is copied, alldocuments will turn into Copy of and will get initialdocument status. To fix this, you can use theBAdI interface IF_EX_SOLAR_DOCUMENTS. All other objects will be copied from the projectdirectly into the solution (together with structure and document attributes). If necessary, the logicalcomponents can be replaced by those representing the maintenance landscape.



15/54


15

Content Maintenance: To perform planned changes to the productive content, it is recommended tocreate and assign a maintenance project to the solution. By activating Check In/Out, the businessprocesses 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 checkedout structures, where documentation and further assignments can be adjusted.

However, business process flow changes cannot be performed in a maintenance project. Theseredesigns of productively used business processes can be performed in so-called major releaseprojects.


In case the maintenance project is also used for change request management purposes, all logicalcomponents 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 bespecified in a specific interface scenario structure. For each interface, you can specify the sending andreceiving system; the type and technology. On the documentation tabs, the interfaces can be documentedand described.

Once the interfaces are documented, you can assign them to the appropriate business processes on theGraphics 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 tobuild a solution, the interface information is still represented on the Graphics tab. However, the originalinformation is still in the documentation project. In this case, it is recommended to resolve the externalinterface thereby copying the original interface into the solution.


16/54


16

3 BUILDING MAJOR RELEASE PROJECTS

Once the business processes are documented in a solution, and the maintenance is in progress, you canstart using the major release method to redesign business processes. To ensure that during the redesign, allchanges to the business process documentation are also reflected in the major release project, the majorrelease project should be created in a different KW enhancement. This demands a specific procedure for thecreation of a major release project.

Once this has been done, the business processes which are to be redesigned can be copied into theprojects (1). Choose the option Refer Documents to ensure that changes to existing maintenancedocuments 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 businessprocess 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 alldocuments are linked). In case new documents were created, or new assignments were made to thebusiness process with a maintenance project, the Compare & Adjust should be performed on the majorrelease project separately (3+3). In the SAP Solution Manager release 7.0 this has to be done manually, inthe release 7.1 you can make use of an extended Compare & Adjust functionality which detects thesechanges automatically. After the maintenance cycle is finished, the content can be checked in into thesolution (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 businessprocesses by assigning new content (5)or by completely redesigning the business processes using the oldcontent as a starting point.


17/54


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 KWenhancement). Using this procedure ensures that current productive documentation is not changedunintentionally.

Newly created documents can be signed additionally with document attributes which show in which projectthe document was created.

After redesigning business processes, reconfiguration in the development system and testing of the contenthave 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, theappropriate business processes can be checked out into the maintenance project (6). In the maintenanceproject, the consolidation of the changes can be performed (7). All changes to documents can be mergedinto existing documents (this is the only way to ensure that the new information will be visible automatically inother 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 systemlandscape). Afterwards, all business processes can be checked in at the end of the maintenance cycletogether 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 animportant advantage: an initial link is established between the business process documentation (which wasoriginally stored in the solution) and the documents available in the major release project. So, whenever theprocess documentation is changed in maintenance, the changes will be reflected automatically in the majorrelease 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 copiedautomatically. 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/54


18

Enhancements). You will be informed about the creation of the copy by a popup. The newly created copy willhave the same content, but will be a physically independent object, where new information can be stored. Tohighlight all new documents, you can use the customer attributes for documents to assign the project ID, inwhich the document was created/changed. Additionally, the BAdI interface IF_EX_SOLAR_DOCUMENTS

can be used to prevent the title changing toCopy 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 otherparallel projects are using the same business processes as those in consolidation, the documents aremerged with the original documents. From now on, you can use the extended Compare & Adjust functionalityto 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. Withintransaction 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 RMDEFand 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 oractivity).

Roadmaps, which are assigned at a later point in time to the major release project, can be used to store alldocument types which help to manage a project, such as meeting minutes. These documents will not be apart 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 thesolution. Thus, when taking the business processes into the major release project, the information isavailable there and is kept in sync with maintenance tasks.

When redefining or redesigning a business process, the assigned test case descriptions have to be adjustedor rewritten after the new developments are implemented. You can build a test plan based on the correctedtest case descriptions and the technical business process step information (transaction), tailor it into testableentities (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 youcan 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 thetraining information was assigned to the business processes in the solution, and if some business processeswere redesigned during the major release project, the training materials can be adjusted andpublished/distributed using Learning Maps in SAP Solution Manager.

The Learning Map functionality gives you the possibility to create end user group specific Learning Maps anddistribute or publish them in a specific knowledge-transfer area.


19/54


19

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


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 & Adjustfunctionality can be used to roll all changes made in

maintenance cycles into the major release project.



20/54


20

4 CHANGE REQUEST INTEGRATION

To manage all changes made to all relevant development systems, you can use the Change Requestfunctionality. 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 threemain 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. Thefollowing 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 forthe maintenance system landscape in so-called maintenance cycles.

4.1.1 Metho d

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 SAPSolution Manager service desk), the change can be requested using the Change Request. This transactiontype 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, thesystem will create another transaction type (based on the categorization) called the change document. Thistype 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 Chang e 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 correctionworkflow 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 systemindependently of the maintenance cycle.

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

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


21/54


21

4.1.3 Phase Chang e (Task List)

Maintenance cycles can be managed and switched in a task list. The task list is a collection of all typicalactivities during the maintenance cycle.

Activating Change Request Management for the major release project on the ChaRM tab in the transactionSOLAR_PROJECT_ADMINcreates a task list in the background. This task list records, collects, andmanages 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 tochanges within the context of a Solution Manager or an IMG project. You can track all transport requestsfrom the system where they are created to the systems/clients into which they are imported. Within theproject context, all transport requests that belong to a particular project can be tracked across all the systemsin the project landscape. You can navigate into the transport logs and import queue as well as into thecorresponding service transaction or task list. You can also navigate into the Solution Manager project, thesatellite IMG project, or the CTS project.

4.1.4 Business Proc ess Integration for Docum ent 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 requestwhich is directly related to a business process or its steps. So the information about existing change requestswill be available not only in the business process structure, but also in Change Request and thus also inChange Document on the Context tab. This method allows you to combine the technical work withdocumentation tasks by linking the Change Request Management directly to the business processdocumentation. The Context tab can also be used to check out the business processes into the maintenanceproject (taking into maintenance) directly and to check it back after successful testing. Following thisprocedure 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 projecttype, 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 forproduction will be performed by maintenance).

4.2.1 Method, Change Typ es and Phase ch anges (Task list)

All necessary redesign tasks will be reflected by normal corrections which take longer than the normalmaintenance cycle. Once you decide to perform a major release project and you copy the necessarybusiness processes into it, you will be able to assign the appropriate business process or business processstep to the Context tab of the normal correction. In this way, the connection between the changes and thedocumentation is guaranteed.

Please refer to the descriptions in the chapters4.1.2 Change Types(not urgent correction) and4.1.3 PhaseChange (Task list).

It should be noted, however, that using Change Request Management requires additional configuration ofSAP Solution Manager. This includes ChaRM-specific customizing (activation or standard ChaRM


22/54


22

customizing) as well as system landscape information in SAP Solution Manager, such as the definition oflogical 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 activitiesperformed in this tool. A proven method is to establish a quality assurance team which ensures that all basicactivities 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 logicalcomponents 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 servicesfor 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/54


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 theuser 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 grouphas PROJECT_ID = I* and the other PROJECT_ID =T*).

Authorization object S_PROJECTS and S_PROJECT can be found, for example, in the roleSAP_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 inSOLAR_PROJECT_ADMINon the Team Memberstab and allows changes to nodes in SOLAR01/02wherethe 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 tochange nodes in a project to assigned team members. This flag can be set in transactionSOLAR_PROJECT_ADMINon the tab Project Member. If you check this box, only team members who areassigned in the Administration tab can work on the nodes of a project structure. Other team members canonly open the tab in display mode.

You need to change the authorization for the tab (authorization object AI_SA_TAB) to enable assigned teammembers 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 foldergroup. The authorization for all included documents is checked against this folder group. Please follow thedescription 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 SI80and select the folder in which the folder group will be changed. Go tothe menu Folder Attributes Change(the context where you currently are should be equal to theorigin 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, youcan 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 isusually 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 MethodHANDLE_EXIT_BEFORE_SAVE in Class CL_SA_IO_DOC, using KW function modules.


24/54


24

7 SETUP/CONFIGURATION AND PROCEDURES

7.1 General Configuration

7.1.1 Definit ion of Sys tem Land scape SMSY

SAP Solution Manager is the central access point for your landscape. If a new Managed System is to beincluded, some basic configuration needs to be executed in transaction SMSYeither manually orautomatically.

The following instructions describe how to create RFC connections between SAP Solution Manager and theManaged System. For details on how to maintain a system in SAP Solution Manager, please refer to thebasic configuration guide of SMSP (Solution Manager Starter Pack).

What to do Screen Display

Select system and clientfrom SMSYin SAPSolution Manager

For a new client, no RFCconnections areestablished. Select theclient and click buttonGenerate RFC with

Assistant.


25/54


25


Follow the wizard and usedefault values for creatingRFC connections.

Select Continue.


26/54


26


Create users for RFCconnection, selectContinue.

Create users for RFCconnection, selectContinue.


27/54


27


Select Continue.

Select Continue.


28/54


28

7.1.2 Project Standard s

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


Select Continue.

The system logon screenwill appear.

Input the user name andpassword to generate theRFC connection. Note: thisuser should haveauthorization for RFCcreation as well as forTrusted RFC. (Pleaserefer to SMSPconfiguration guide fordetails)


29/54


30/54


30


Define DocumentationType (here: ZBPD)

Upload the template intothe Documentation Type

New template has to bereleased in order to beavailable for later use


31/54


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 comm on Release status value for all status sc hemas.

Where to configure/how to do:


Possible corrections onthe Documentationtemplate

Further settings for theDocumentation Type like:global availability,several assignmentspossible, relevance forBlueprint document orstatus schemaassignment.


32/54


32


Status Value Definition(transaction SPRO)

Press New Entries andcreate Values

Save and record in atransport

Assign Status Values toRead Authorization


33/54


33


Select from the list ofavailable Status Values

Definition of StatusSchema

Create the Status Schema

by pushing NewEntry

Decide which entries shallbe part of Status Schema


34/54


34

Returnto topic content


Assign Status Schema toDocumentation Types

Make Documentation Typeavailable for project type


35/54


35

7.1.2.3 Adjustments to Blueprint Document

The functionality for creating the Business Blueprint is provided for all project types in SAP SolutionManager. 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). Thetemplate of the blueprint document can be adjusted in customizing as shown.



Download ofSOLARBLUEPRINT.DOCand correction(replacement of Logo).


36/54


36


Change the template

Upload the template fromthe storage location,where it was changed

From now on the customerversion will be used tocreate a blueprintdocument.


37/54


37

7.1.2.4 Structure/Object Attributes

Structure attributes are typically used for filtering purposes in templates, rollout projects, test plans and alsoas a reporting help, in a solution. For this, custom-defined tables can be used with a defined range of

possible input values.



Customization intransaction SPRO

Creation ofStructure/Object attributeArea


38/54


38


Decide which entries willbe used for the attribute(table assignment)

Assign attributeZ_SAP_AREA to objects.

Attribute will be availablefor structure nodes


39/54


39



Assign attributeZ_COMPONENT to objectProject and Solution Node

Set the other options

Result: the attribute isavailable for businessprocess structures


40/54


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 tocreate 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. Onepossibility for such an attribute is the Project IDunder which the document was created/changed. Theinformation on who changed the attribute and when it was changed will be logged in the history of thedocument. The customization described below is done with the example of Project ID as an attribute.



Create an attribute throughtransaction SPRO

Create an attributeProject ID


41/54


41


Assignment of a table andfield to which the attributewill relate

Activate the attribute

Record changes in apackage .

Assign the newly createdcustom attribute to PHIOclass SOLARGENSRC_V


42/54


42

After creating the attributes, it might be necessary to refresh the buffer on servers (transaction SE33forcontext IWB_CLASS_PROPS).

The same activities can also be performed for the attribute SAP Component to detect which documentsbelong to which SAP area.


New attribute has to beassigned to instanceattributes

After saving, the newcustomization has to be

activated

Result in SOLAR01/02 fordocument


43/54


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 thesystem:

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

_ADMINand thenyou will go to theprojectadministrationscreen where youcan start to createthe project.

Maintain Mandatory Fields and Save

You can assign thesolution to theproject when theproject deals with

the same systemlandscape


44/54


44


During saving, theKW Enhancementhas to be changedfrom KWCUST 620to any other one

Business Process Assignment

a. Navigate tothe businessblueprint screen

a. Businessprocesses willbe copied intothe project:


45/54


45


b. together withall assignmentson all tabs

Document Management in a Major release Project

a. AllDocuments arelinked from thesolution into theproject. Thepicture shows a

change to adocument in themaintenanceprojectassigned to thesolution.Documentattributes arechanged(project ID)

b. Changesmade inmaintenancewill also bereflected in themajor releaseproject


46/54


46



c. As soon asthe document ischanged, thesystem willcreate a copy.Changes madeto thisdocument willnot be reflectedin the solution/maintenancedocumentation.

At the end ofthe majorrelease project,the documentcontent ismerged with theoriginaldocumentstored in thesolution(through

maintenance).This will bevisible in allother potentialmajor releaseprojects


47/54


47

7.2.1 Compare & Adju st: From Maintenance to Major release proj ect

Use the Compare & Adjust procedure after every maintenance cycle:


New Documentation iscreated duringmaintenance

Start Compare & Adjust(transactionSA_PROJECT_UPGRADE) for the major releaseproject


48/54


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 thesolution) can be reused or redesigned. Afterwards, test plans and test packages can be generated accordingto business processes and the progress of testing and reporting can be tracked.

Test Case Assignment in a ProjectIn a major release project, it is possible to assign or redesign test cases, ECATT scripts, or to assign testdescriptions to business scenarios, business processes or business process steps.

These test documents can be reused for test plan creation.


Results will be displayed inthe implementationproject.

Adjustment can be started.

You can adjust all changesor select changes youwant to take over(depending on globalattributes). Afterwards,select CopyandComplete.


49/54


49


7.2.3 L earnin g Map


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

Test Workbench

Test Workbench isembedded in SAP SolutionManager for TestManagement. After theassignment of testdocuments, a test plan canbe generated in the TestWorkbench and testpackages can be createdfor different Testers.


Create a Learning Mapusing transaction

SOLAR_LEARNING_MAP


50/54


50


Create Chapter and Units

Search for trainingmaterial and assign theseto the units.


51/54


51


7.2.4 Go-Live and Delta Ad justm ent to the Solut ion


Send to End User


For the handover ofredesigned BusinessProcesses, the extendedCompare &Adjust can beused


52/54


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 solutioninstead of the project.

Take over changes


Maintenance Project

To change the businessprocess structure in asolution, it isrecommended to use amaintenance projectinstead of making changes

directly to the solutionAssign a maintenanceproject to a solution, andthen enable the Check-out/Check-in functionality.


53/54


53



Check-In / Check-Out

After the maintenanceproject is assigned to onesolution, it is no longerpossible to change thebusiness structure,document, or landscapedirectly in the solution.

Any necessary changeswill be checked-out intothe maintenance projectand checked-in afterchanges.

The maintenance projectfor this solution can bechecked in into theSolution Directory.

Use the Check-in/Check-out button in the SolutionDirectory and maintenanceproject, to perform postgo-live maintenance.


54/54

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

www.sap.com

Business Process Redesign_SOLMANALM

Documents

Transcript of Business Process Redesign_SOLMANALM