Business Process Redesign in SAP Solution Manager Application

Transcription

Business Process Redesign in SAP Solution
Manager Application Lifecycle Management
Business Process Major release Redesign
TABLE OF CONTENTS
1 INTRODUCTION ............................................................................................................................................ 4
2 GENERAL EXPLANATION ........................................................................................................................... 4
2.1 Projects and Solutions .............................................................................................................................. 4
2.2 Template Project ........................................................................................................................................ 4
2.3 Implementation Project ............................................................................................................................. 5
2.4 Maintenance Project .................................................................................................................................. 6
2.5 Upgrade Project for Existing Systems .................................................................................................... 6
2.6 Projects and Solutions Dependencies .................................................................................................... 7
2.7 Business Process Design ......................................................................................................................... 7
2.7.1 Definitions of Business Scenario, Process and Step ............................................................................... 7
2.7.2 End-to-End Oriented Business Process Design ....................................................................................... 8
2.7.3 Module-Oriented Business Process Design ............................................................................................. 8
2.7.4 Definition of End-to-End Business Scenarios based on modular business processes ............................ 9
2.7.5 Structure Attributes ................................................................................................................................. 10
2.8 Business Process Assignments ............................................................................................................ 11
2.9 Document Management .......................................................................................................................... 12
2.10 Procedures for Solution Documentation ............................................................................................ 13
2.10.1 Interface Scenarios ............................................................................................................................... 15
3 BUILDING MAJOR RELEASE PROJECTS ................................................................................................ 16
3.1 Document Management in a Major release Project ............................................................................. 17
3.2 Methodology for Major release Project (Roadmap) ............................................................................. 18
3.3 Testing in the Major release Project ...................................................................................................... 18
3.4 Training Materials .................................................................................................................................... 18
3.5 Go-Live and Maintenance ....................................................................................................................... 19
4 CHANGE REQUEST INTEGRATION .......................................................................................................... 20
4.1 ChaRM in a Maintenance Project ........................................................................................................... 20
4.1.1 Method .................................................................................................................................................... 20
4.1.2 Change Types ........................................................................................................................................ 20
4.1.3 Phase Change (Task List) ...................................................................................................................... 21
4.1.4 Business Process Integration for Document Management .................................................................... 21
4.2 ChaRM in Major release Project ............................................................................................................. 21
4.2.1 Method, Change Types and Phase changes (Task list)......................................................................... 21
5 ORGANIZATIONAL ASPECTS FOR MAJOR RELEASE PROJECTS ...................................................... 22
6 AUTHORIZATIONS...................................................................................................................................... 23
6.1 Projects ..................................................................................................................................................... 23
6.2 Document Management .......................................................................................................................... 23
7 SETUP/CONFIGURATION AND PROCEDURES ....................................................................................... 24
7.1 General Configuration ............................................................................................................................. 24
7.1.1 Definition of System Landscape – SMSY ............................................................................................... 24
7.1.2 Project Standards .................................................................................................................................. 28
7.1.2.1 Definition of Document Types ............................................................................................................. 29
7.1.2.2 Definition of Status Schema ................................................................................................................ 31
7.1.2.3 Adjustments to Blueprint Document .................................................................................................... 35
7.1.2.4 Structure/Object Attributes .................................................................................................................. 37
2
7.1.2.5 Customer Attributes for Documents .................................................................................................... 40
7.2 Major release Project Creation .............................................................................................................. 43
7.2.1 Compare & Adjust: From Maintenance to Major release project ......................................................... 47
7.2.2 Testing in the Major release Project ...................................................................................................... 48
7.2.3 Learning Map ......................................................................................................................................... 49
7.2.4 Go-Live and Delta Adjustment to the Solution ...................................................................................... 51
7.2.5 Post Go-Live Maintenance .................................................................................................................... 52
3
1 INTRODUCTION
The SAP Solution Manager is positioned as an Application Management Platform for SAP centric solutions.
The major focus of SAP Solution Manager is on solution operation and optimization. It also functions as a
collaborative infrastructure between the customer and SAP. This includes remote support as well as
collaborative scenarios between the customer operation and the SAP service organizations.
Apart from solution operation, the SAP Solution Manager platform also provides an infrastructure for overall
application management: from requirement/change request management, through design, build, test, deploy,
and operation/optimization, with a major focus on change control.
Depending on the scope of the SAP Solution Manager processes being implemented and depending on the
structure of the company, the SAP Solution Manager can be an easy setup or an implementation project by
itself.
The following content describes one of the Application Lifecycle Management (ALM) possibilities in SAP
Solution Manager for an example of a major release project (which performs changes to productively used
business processes which are stored in a solution). This includes references to test capabilities, Business
Process Monitoring, and Change Request Management (ChaRM).
2 GENERAL EXPLANATION
2.1 Projects and Solutions
As shown in the picture below, projects and solutions are simply overviews of business process information.
A project in SAP Solution Manager provides information on the future use of business processes: this
includes business process redesign and new business process implementation.
Figure 2-1: Proje ct and Solution
A solution, on the other hand, contains information on the current use of business processes in a productive
environment.
In the following chapters (2.2-2.5) the different project types are described.
2.2 Template Project
A template project can be used to create and distribute a template. A template defines a project structure, or
parts of it. Its assigned objects (documentation, test cases, IMG activities, development and training material)
are available to other projects as templates.
4
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.
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.
2.3 Implementation Project
Implementation projects can be used to implement business processes in an SAP landscape. A project
structure has to be created for the business processes. You can either create a new project structure, or
base it on any one of the following:




one or several templates
existing project(s)
scenarios and configuration structures delivered by SAP (Business Process Repository)
an existing production solution landscape for major release changes to productively-used business
scenarios
An implementation project can be used for two typical use cases:
1. Implementation of new business processes, where the scope can be defined, based on:
a. Predefined business processes from a template project. Predefined business
processes can be changed according to global attributes defined in the template.
b. Normal implementation without template predefinitions (manual business process
creation and documentation). Here, the business processes can be created and
changed independently during the implementation.
2. Major release changes to productively used business processes stored in a solution. Those
business processes can be redesigned in this project (without system upgrade) and
afterwards all deltas are handed over to the solution.
5
2.4 Maintenance Project
The maintenance project can be used to keep track of changes in the productive environment (solution).
 in Change Request Management. The project contains all maintenance activities and
urgent corrections of a solution.
 in Check Out/In for business processes, redocumentation/changes from the Solution
Directory. These changes are then performed in a maintenance project linked directly to
the solution.
Assignment to a solution with activated Check Out/In functionality can be used to reflect all
changes made to productively used business processes and their documentation, during the
maintenance cycles. These are typically small transactional corrections or configuration tasks.
Types of possible changes:

Urgent correction: errors and hot fixes; this usually does not have an impact on the
business process documentation (back to designed behavior).

Normal corrections: pertains to all changes to a business process or a business process
step which can be completed within a short of the maintenance cycle. This typically
involves minor reconfiguration or additional small developments (no business process
redesign). These changes are reflected in business process documentation.
2.5 Upgrade Project for Existing Systems
In an upgrade project you can:
o upgrade the customization: upgrade existing functions
and/or
o delta the customization: copy additional functions
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.
6
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 betw een different Pro jects and a Solution
The same content (business process and attached information) is reused and passed on to typical project
phases, such as: design, realization, test, and go-live and also between the different project types and the
solution. As such, the requirements on the business process design can be very complex. Please refer to the
chapter Business Process Design.
2.7 Business Process Design
Proper business process design and appropriate grouping into scenarios are key decisions when starting
ALM in SAP Solution Manager. By choosing the wrong design, reusability is impaired. This affects future use
of the content for purposes like testing or Business Process Monitoring. Business processes should be
organized in business scenarios. Here, module-oriented scenarios can be used, or module-oriented business
processes can be combined into end-to-end business scenarios.
Below, two methods are described (SAP module- or End-to-End oriented), for designing business processes
in SAP Solution Manager. Visibility and reporting capabilities can be improved through structure attributes.
2.7.1 Definitions of Business Scenario, Process and Step



A business process step is most commonly related to a transaction, a background job, a web UI or
similar system activities. Sometimes it makes sense to also document some activities within the
business process flow.
A business process is a collection of business process steps, grouped according to a certain
criterion like business content or SAP modules.
A business scenario is a collection of business processes to be executed one by one resulting in
the execution of an operational procedure. Scenarios can be organized by business unit, SAP
module or other kinds of grouping (e.g. template-related).
The SAP Note 1345599 describes the restrictions to size for business scenarios.
7
2.7.2 End-to-End Oriented Business Process Design
In designing end-to-end business processes, you have to answer the question what “end-to-end” means for
your business unit(s). This difficulty shows up at the start of business process documentation, and is mostly
connected to organizational aspects (user access, organization of monitoring etc.). However, this is the most
reusable business process model for documentation purposes, test capabilities, interface documentation and
Business Process Monitoring. It is recommended to use structure attributes or custom attributes for
documents when organizing the business process documentation in relation to SAP modules.
Figure 3-1: End-to-End Ori ented Bu siness Process Design
2.7.3 Module-Oriented Business Process Design
In a module-oriented business process, business process steps which are executed one after the other in a
single module are described, as shown in the graphic below.
Figure 3-2: M odule-Oriented Business Process Desig n
8
Advantages:

Clear separation of processes by SAP Module (mostly combined with module-based business
scenarios)
Disadvantages:


Additional work to build test-related business processes
Without “interfaces” to other business processes no possibility to document system interfaces
To increase the quality and versatility of this model, it is strongly recommended to represent preceding and
succeeding steps performed in different modules and to highlight the connections, as shown in the figure
below. This allows documentation of interface scenarios.
Figure 3-3: Extended M odule -Oriented Business Process Design
2.7.4 Definition of End-to-End Business Scenarios based on modular business processes
For all customers who organize their solution documentation along SAP modules (Business Process
responsibility, maintenance activities, projects) another business process model can be recommended. In
this model you can combine modular build business processes (process flow within one SAP Module) to an
End-to-End Business scenario (see figure 3-4).
Figure 3-4: Business Scen ario Execution
To do so, use the Graphic tab at scenario level to document the order in which the business processes are to
be executed. Alternatively the Business Process Blueprinting tool can be used to detailed represent the Endto-End flow within the business scenario (see figure 3-4b).
All used business process variants are included into the same business scenario and represent the regional
or business unit specifics. By the use of structure attributes you can make visible which processes build
together an end to end scenario variant.
The figure 3-4a is showing the maximal number of business processes to cover the most important Order to
Cash variants collected under one business scenario. By use of attributes “Scenario Variant” you can control
the visibility of the Order to Cash variants.
9
Figure 3-4a: Business Scenario Execution
As shown in figure 3-4b the green arrows connect four business process steps from several modular
business processes into a business process chain. In this chain some business process steps are not
involved (part of blue line connected processes). However, if you recognize the modular process they play
an important role to build an information flow within a modular business process. By use of attribute “End-toEnd Test relevant” you can control the visibility of the End-to-End relevant business process steps in test
environment.
Modular Process Flow
End-to-End Process Flow
Figure 3-4b: Business Scenario Test Execution
Further recommended attributes could be:
- Regional variants
- Business Units
- SAP Module
- Priority
It is recommended to use prefixes in the business process hierarchy to highlight the sequence of their
execution. Beside the graphical representation this will guaranty the direct reuse in test sequences for
integration test.
2.7.5 Structure Attributes
As of support package 15 (EHP 1) for SAP Solution Manager 7.0, it is possible to define and use structure
and object attributes. Structure attributes can support all types of filtering or reporting capabilities during
typical project phases like blueprint, configuration, testing, or maintenance (after go-live). The biggest
advantage of structure and object attributes is that they can be copied together with the structure, whenever
the structure is reused (template  Rollout  Solution  Maintenance).
10
Once assigned, structure attributes can be adjusted with the Compare & Adjust function using the
transaction SA_PROJECT_UPGRADE. This ensures that all changes made to attributes and their
assignment to the business processes or business process steps are current at all times throughout the
entire business process lifecycle.
Figure 3-5: Business S cen ario Execution
Show how this procedure is executed in SAP Solution Manager.
2.8 Business Process Assignments
Apart from documenting the business process structure in the template project, you can also document
technical objects like:





Transactions: the assignment of transaction information to the business process steps determines
which transaction(s) will be used to perform a certain business process step in the managed system.
This information is usually defined during the blueprint stage, and is reused for testing, Business
Process Monitoring, business process change analysis and other functions.
Configuration Objects: all objects assigned to the configuration tab of a business process or a
business process step record the customizing views. These have to be maintained to ensure that the
business process/step runs as designed during the blueprint stage.
Development Objects: all modifications are documented as an assignment of the developed object to
the business process/step for which the modification was created. Additionally, technical
documentation for the modifications and extensions can be assigned and connected to the
development object directly.
Test Case Descriptions: The testing prescriptions for a business process step are assigned to
appropriate structures (using the test object results in a transaction assigned to the business process
step). During the creation of a test plan, the test case descriptions can be selected and brought into
the test scope as a test case (together with assigned transactions).
Training Materials: The training documents, which describe how a transaction is to be used by end
users in the context of the business process, can be assigned to the business process step on the
Training tab. These documents can be used to create Learning Maps and distribute them to end
user groups.
11

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:

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.
12
Business Process Step Example: Create purchasing scheduling agreement (transaction ME31L)
General Documentation Tab: contains documents describing the design of transaction
ME31L (in case template management was used, functional specification or additional documentation…)
Project Documentation Tab:
project related documentation for ME31L
Configuration Tab:
document describing the configuration needed for transaction ME31L
(Configuration objects and descriptions, Authorization Roles…)
Development Tab:
All developments needed to run the transaction ME31L (Technical
specifications, development forms…)
Test Case Tab:
Test case descriptions. All types of functional tests can be represented by
different document types. Additionally, test data documents can be
assigned at business process level.
Training Materials:
All kinds of training documents which will be made available to end users
(simulations, presentations)
Document
Type
Description
Structure
Tab
ZBPD
Business Process Description
Business Process
Gen/Project. Documentation
ZFSP
Functional Specification
Business Process/Step
Gen./Project Documentation
ZCON
Configuration Description
Configuration
ZAUT
Authorization
Configuration
ZTSP
Technical Specification
Development
ZTCD
Test Case Description
Step
Test Cases
ZUT
User Training
Step
Training Material
ZINT
Interface Description
Interface Step
Gen./Project Documentation
Above document types are examples. Different document types can be created to suit different
requirements.
2.10 Procedures for Solution Documentation
The information about current productively used business processes can be collected centrally into an excel
file (1) by business process owners or from existing documents. In this file, the business process structure is
created. In addition, logical components (in which transactions are executed), assignments of transaction
codes to business process steps, and links to all relevant documents which have to be migrated to SAP
Solution Manager are created here. You can upload business process descriptions, specifications, and test
cases to the appropriate tabs (please refer to the previous chapter “2.9 Document Management”).
After all data relevant to migration have been collected into an excel file, the file has to be converted to an
XML format. Afterwards, the data can be uploaded easily using report RS_SA_PROJECT_IMPORT (2) into
an existing implementation or template project.
13
This conversion from excel into xml format is a consulting solution. In the 7.1 release of SAP Solution
Manager, this possibility is provided in the standard version.
After these steps have been performed, the data can be entered directly into SAP Solution Manager using
SOLAR01/02 where additional data like development objects, configuration views, or structure / document
attributes can be assigned to the structure.
Figure 4-1: Business Process migration
After the migration content has been uploaded into SAP Solution Manager and extended by additional
assignments, you can start verifying it using the Solution Documentation Assistant (SDA). To do so, the
business processes have to be copied into an SDA analysis project (3). This copy will take business process
structures with all assigned transaction/report information from the Transaction tab. If no further checking
rules are assigned to the business processes in the analysis, the system will analyze the business processes
based on the statistics for actively used transactions in the managed systems. Since the business processes
were created based on the experience of business process owners and/or on existing documents, no red
alerts should appear (a red alert means that the transaction has not been executed).
Once the verification is completed and has yielded positive results (which means that all transactions used
for business process documentation are executed in managed systems), the content can be copied into a
solution (4). A few tasks need to be performed during the content copy of the documentation project into a
solution:


Creation of a Solution: The business processes and their entire documentation will be stored in the
solution after go-live.
Content copy from Project into Solution: It is recommended to use the work center to copy the
business processes from the rollout project into the solution. Once the content is copied, all
documents will turn into “Copy of…” and will get initial document status. To fix this, you can use the
BAdI interface IF_EX_SOLAR_DOCUMENTS. All other objects will be copied from the project
directly into the solution (together with structure and document attributes). If necessary, the logical
components can be replaced by those representing the maintenance landscape.
14

Content Maintenance: To perform planned changes to the productive content, it is recommended to
create and assign a maintenance project to the solution. By activating Check In/Out, the business
processes cannot be changed in a solution, but exclusively in the maintenance project assigned to it
(5+6). Optionally, the Change Request functionality can be activated for this maintenance project.
Before each maintenance cycle, the planned normal corrections can also be reflected in the checked
out structures, where documentation and further assignments can be adjusted.
However, business process flow changes cannot be performed in a maintenance project. These
redesigns of productively used business processes can be performed in so-called major release
projects.
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.
15
3 BUILDING MAJOR RELEASE PROJECTS
Once the business processes are documented in a solution, and the maintenance is in progress, you can
start using the major release method to redesign business processes. To ensure that during the redesign, all
changes to the business process documentation are also reflected in the major release project, the major
release project should be created in a different KW enhancement. This demands a specific procedure for the
creation of a major release project.
Once this has been done, the business processes which are to be redesigned can be copied into the
projects (1). Choose the option “Refer Documents” to ensure that changes to existing maintenance
documents are reflected in the major release project.
Figure 5-1: Cre ation of M ajor release Project and Ch ange Reflection
It could happen that during major release project redesign of the business process the same business
process content is changed in the maintenance project (2 + 2). The changes to the documents available
during the process copy are immediately reflected in the major release project documentation (because all
documents are linked). In case new documents were created, or new assignments were made to the
business process with a maintenance project, the Compare & Adjust should be performed on the major
release project separately (3+3). In the SAP Solution Manager release 7.0 this has to be done manually, in
the release 7.1 you can make use of an extended Compare & Adjust functionality which detects these
changes automatically. After the maintenance cycle is finished, the content can be checked in into the
solution (4) and all changes made during the maintenance cycle will become visible in the solution as well.
While the maintenance cycles are being performed, the major release project changes the business
processes by assigning new content (5) or by completely redesigning the business processes using the old
content as a starting point.
16
Figure 5-2
M ajor release Go-Live
When the old documents have to be adjusted (4), the system will create a copy (due to the different KW
enhancement). Using this procedure ensures that current productive documentation is not changed
unintentionally.
Newly created documents can be signed additionally with document attributes which show in which project
the document was created.
After redesigning business processes, reconfiguration in the development system and testing of the content
have to be prepared for deploy. The extended Compare & Adjust functionality can be run (Release 7.1)
against the business process source: the solution. After the changes to the content have been detected, the
appropriate business processes can be checked out into the maintenance project (6). In the maintenance
project, the consolidation of the changes can be performed (7). All changes to documents can be merged
into existing documents (this is the only way to ensure that the new information will be visible automatically in
other projects which may run in parallel). This is also the case for process structures and their assignments
(7). As soon as all deltas are adjusted, the business processes can be retested (in case of dual system
landscape). Afterwards, all business processes can be checked in at the end of the maintenance cycle
together with the normal maintenance content.
3.1 Document Management in a Major release Project
Using a different KW Enhancement for the major release project than for the other projects/solutions has an
important advantage: an initial link is established between the business process documentation (which was
originally stored in the solution) and the documents available in the major release project. So, whenever the
process documentation is changed in maintenance, the changes will be reflected automatically in the major
release project as all documents are linked.
For all business processes which have to be redesigned existing documentation can be reused. However, as
soon as an existing document is clicked in change mode, it will cause the document to be copied
automatically. This happens because the major release project was created in a different KW Enhancement
(the system does not allow bidirectional links between two projects which are in different KW
17
Enhancements). You will be informed about the creation of the copy by a popup. The newly created copy will
have the same content, but will be a physically independent object, where new information can be stored. To
highlight all new documents, you can use the customer attributes for documents to assign the project ID, in
which the document was created/changed. Additionally, the BAdI interface IF_EX_SOLAR_DOCUMENTS
can be used to prevent the title changing to “Copy of…” and to pre-fill the document attributes for documents.
During the go-live, all the redesigned processes have to be reflected in the solution content. In case other
parallel projects are using the same business processes as those in consolidation, the documents are
merged with the original documents. From now on, you can use the extended Compare & Adjust functionality
to detect business process deltas and “new” documents.
3.2 Methodology for Major release Project (Roadmap)
To document the methodology of a major release project, you can use the Roadmap functionality. Within
transaction RMMAIN, you have access to standards like ASAP or Upgrade Roadmaps which SAP delivers.
You can also define and create your own Roadmaps in SAP Solution Manager, using transactions RMDEF
and RMAUTH. In this case, customer-specific phases, tasks, and activities can be described and
customized, and accelerators can be provided (documentation on how to proceed with the phase, task or
activity).
Roadmaps, which are assigned at a later point in time to the major release project, can be used to store all
document types which help to manage a project, such as meeting minutes. These documents will not be a
part of ALM (will not be handed over to the solution).
3.3 Testing in the Major release Project
As the test case descriptions were uploaded into SAP Solution Manager, they are already part of the
solution. Thus, when taking the business processes into the major release project, the information is
available there and is kept in sync with maintenance tasks.
When redefining or redesigning a business process, the assigned test case descriptions have to be adjusted
or rewritten after the new developments are implemented. You can build a test plan based on the corrected
test case descriptions and the technical business process step information (transaction), tailor it into testable
entities (test packages), and assign the entities to the tester.
In so-called test sequences, you can rearrange the order in which test activities are to be performed, or you
can rebuild business processes for specific test types. To this end, the structure attributes can easily be used
to filter business processes which may be tested or regrouped separately.
3.4 Training Materials
After successfully testing the implemented business scenarios, the end user needs to be trained. If the
training information was assigned to the business processes in the solution, and if some business processes
were redesigned during the major release project, the training materials can be adjusted and
published/distributed using Learning Maps in SAP Solution Manager.
The Learning Map functionality gives you the possibility to create end user group specific Learning Maps and
distribute or publish them in a specific knowledge-transfer area.
18
The end user will get access to the documents provided in his Learning Map, without the necessity of having
a user in the SAP Solution Manager. All training materials collated in the Learning Map will be shown to the
end user in display mode.
3.5 Go-Live and Maintenance

Adjustments after Maintenance Cycles: All changes to the business scenario/process and step
content which were made during maintenance should also be reflected in the major release project.
To this end, the Compare & Adjust functionality can be used to roll all changes made in
maintenance cycles into the major release project.

19
4 CHANGE REQUEST INTEGRATION
To manage all changes made to all relevant development systems, you can use the Change Request
functionality. This functionality can be used for the maintenance work and the appropriate landscape as
well as for major release projects. Change Request Management in SAP Solution Manager consists of three
main areas:



Change Administration: Management of all change requests, change categorization, approval
workflow, and status reporting.
Project Management: project planning, project documentation, like customizing or development
specifications and test management
Change Logistics: Customizing and Development realization, transport scheduling (seamless
integration into TMS) and transport tracking.
Combinations of these three topics allow full control over the landscape and all changes made to it. The
following descriptions roughly explain the procedures of ChaRM use during maintenance and for major
release projects.
4.1 ChaRM in a Maintenance Project
Activating the ChaRM flag for your maintenance project allows the system to control all changes planned for
the maintenance system landscape in so-called maintenance cycles.
4.1.1 Method
After configuring and activating the standard ChaRM functionality in your system, you can use the workflowbased functionality. This means that when a change necessity is detected (possible integration into SAP
Solution Manager service desk), the change can be requested using the Change Request. This transaction
type is used for approval workflow tasks. During the workflow, the change is categorized (see 4.1.2 Change
Types), and then approved or rejected by a change manager. Once the change has been approved, the
system will create another transaction type (based on the categorization) called the change document. This
type of document is used to perform all development activities aligned to the approved change request.
Typical tasks are:
 Creation of a transport request
 Logon to relevant system to develop/test/validate the requested functionality
 Testing
 Organization of transport (depending on change type)
4.1.2 Change Types
Four main Change Types, delivered in the standard version, can be used by default (as a copy of the SAP
origin):
 Normal Correction: This process is used to make regular corrections in your maintenance
landscape and to implement planned features into your development landscape. Normal correction
workflow has a strong dependency on the maintenance cycle phase.
 Urgent Correction: This process is used to make an urgent correction in your production system.
This transaction is only permitted within a maintenance landscape. In contrast to normal correction,
urgent correction gives you the possibility to implement the correction into your production system
independently of the maintenance cycle.
 Test Message (Defect Correction as of 7.1): This type is used during testing, for corrective
development.
 Administration Changes: This type is used for all system changes which cannot be included in a
typical transport request. An example would be number range.
20
4.1.3 Phase Change (Task List)
Maintenance cycles can be managed and switched in a task list. The task list is a collection of all typical
activities during the maintenance cycle.
Activating Change Request Management for the major release project on the ChaRM tab in the transaction
SOLAR_PROJECT_ADMIN creates a task list in the background. This task list records, collects, and
manages all changes made to the managed system(s) or clients.
The task list can be used for:
 Creating transport requests and tasks
 Scheduled and/or on demand import
 Transporting copies
 Security functionalities like Cross System Object Lock and Critical Objects Check
 Retrofit for n+1 landscape
 Reporting capabilities
 Transporting non-ABAP objects though the integration with CTS+
The Change Tracking function of Change Request Management allows you to track everything that relates to
changes within the context of a Solution Manager or an IMG project. You can track all transport requests
from the system where they are created to the systems/clients into which they are imported. Within the
project context, all transport requests that belong to a particular project can be tracked across all the systems
in the project landscape. You can navigate into the transport logs and import queue as well as into the
corresponding service transaction or task list. You can also navigate into the Solution Manager project, the
satellite IMG project, or the CTS project.
4.1.4 Business Process Integration for Document Management
Change Request Management can be used not only in a maintenance project, but especially in connection
to a solution embedded in a check out/in procedure. By using this variant, you create a change request
which is directly related to a business process or its steps. So the information about existing change requests
will be available not only in the business process structure, but also in “Change Request” and thus also in
“Change Document” on the Context tab. This method allows you to combine the technical work with
documentation tasks by linking the Change Request Management directly to the business process
documentation. The Context tab can also be used to check out the business processes into the maintenance
project (taking into maintenance) directly and to check it back after successful testing. Following this
procedure ensures that the change documentation is always in sync with the technical realization.
4.2 ChaRM in Major release Project
It is also possible to activate the Change Request Management for major release projects. For this project
type, you can choose between three different change documents (normal change, admin change and test
message). Urgent corrections are not necessary as you are implementing a new functionality (all fixes for
production will be performed by maintenance).
4.2.1 Method, Change Types and Phase changes (Task list)
All necessary redesign tasks will be reflected by normal corrections which take longer than the normal
maintenance cycle. Once you decide to perform a major release project and you copy the necessary
business processes into it, you will be able to assign the appropriate business process or business process
step to the Context tab of the normal correction. In this way, the connection between the changes and the
documentation is guaranteed.
Please refer to the descriptions in the chapters 4.1.2 Change Types (not „urgent correction‟) and 4.1.3 Phase
Change (Task list).
It should be noted, however, that using Change Request Management requires additional configuration of
SAP Solution Manager. This includes ChaRM-specific customizing (activation or standard ChaRM
21
customizing) as well as system landscape information in SAP Solution Manager, such as the definition of
logical systems: the source, target, and production.
5 ORGANIZATIONAL ASPECTS FOR MAJOR RELEASE PROJECTS
Using SAP Solution Manager as an implementation tool requires ensuring the quality of all activities
performed in this tool. A proven method is to establish a quality assurance team which ensures that all basic
activities in SAP Solution Manager are performed correctly.
Governance is needed in several areas:

System Landscape: The system landscape information is the foundation for nearly all SAP Solution
Manager functionalities. The quality assurance team should have access to this area, be authorized
to create and change managed systems, and also be able to create all necessary RFCs for all
appropriate clients. The systems can then be grouped into logical components. These logical
components are used for all current and future projects.

Standard and Design Definitions: To ensure the consistency of all standards used in the projects,
like document types, status schemas, structures, and document attributes, the team should also
attend to design questions, decisions concerning building of the ALM in SAP Solution Manager, and
to the decisions on which non-SAP tools have to be used for ALM purposes.

The aim of this team should also be to ensure the correctness and quality of the business process
design. Business processes should be kept granular (please refer to the chapter “2.7 Business
Process design”) and correct assignment handling guaranteed.

Possible services for incoming projects:
 Project Consulting (which processes, project type and so on). Before a new project starts, the
quality assurance team could discuss with their project management how to perform the project
and how SAP Solution Manager can support them for this purpose. Possible reuse of existing
business processes or documents should be discussed.
 Project Creation. As a service to the project team, SAP can offer to take over central activities in
SAP Solution Manager, like creating a project or assigning a project landscape. This will also
ensure the quality of performed tasks.
 Standards Review. Definition of quality control points (Quality Gate) and regular checks of
business processes and documentation quality.
 Business Process Design Consulting. Assurance that all new projects have the same design and
follow the same procedures to allow reuse in ALM.
 SAP Solution Manager Consulting. This central team is the main contact point for all requests
regarding SAP Solution Manager functionalities. All customizing and/or development activities
have to be approved and activated by this team.
 Knowledge Transfer. Every new project team has to be trained on how to use SAP Solution
Manager functionalities: especially on how to handle documents, make developments, and
clarify customizing tasks.
22
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:
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*).
1)
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)
2)
3)
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.
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.
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.
23
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‟.
24
What to do
Screen Display
Follow the wizard and use
default values for creating
RFC connections.
Select ‘Continue’.
25
What to do
Screen Display
Create users for RFC
connection, select
„Continue‟.
Create users for RFC
connection, select
„Continue‟.
26
What to do
Screen Display
Select „Continue‟.
27
What to do
Screen Display
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.
28
7.1.2.1 Definition of Document Types
At the least, the following document types should be available in the customer system (example):







ZBPD:
ZCON:
ZFSP:
ZTSP:
ZUT:
ZUAT:
ZAUT:
Business Process Description
Configuration Description
Functional Specification
Technical Specification
User Training
User Acceptance Test
Authorization
Where to configure/how to do:
What to do
Screen Display
Document Types
(transaction
SOLAR_PROJECT_ADMI
N menu Goto  Project
Template 
Implementation Project,
Template Project…)
Select Documentation
Type Tab
29
What to do
Screen Display
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
30
What to do
Screen Display
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.2.2 Definition of Status Schema
Document types are assigned to customer specific status schema(s). All status schemas contain customer
defined status values like:




Z_NEW
Z_PROGRESS
Z_APPROVAL
Z_RELEASED
Status value Z_RELEASED shall be included into the table for Read Authorization.
Please create one common Release status value for all status schemas.
31
What to do
Screen Display
Status Value Definition
(transaction SPRO)
Press “New Entries” and
create Values
Save and record in a
transport
Assign Status Values to
Read Authorization
32
What to do
Screen Display
Select from the list of
available Status Values
Definition of Status
Schema
Create the Status Schema
by pushing “New Entry”
Decide which entries shall
be part of Status Schema
33
What to do
Screen Display
Assign Status Schema to
Documentation Types
Make Documentation Type
available for project type
Return to topic content
34
7.1.2.3 Adjustments to Blueprint Document
The functionality for creating the Business Blueprint is provided for all project types in SAP Solution
Manager. Using it, you can create the blueprint document based on the content of all blueprint-relevant
documents collected for the rollout project (process description, functional specification or similar). The
template of the blueprint document can be adjusted in customizing as shown.
What to do
Screen Display
Download of
SOLARBLUEPRINT.DOC
and correction
(replacement of Logo).
35
What to do
Screen Display
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.
36
7.1.2.4 Structure/Object Attributes
Structure attributes are typically used for filtering purposes in templates, rollout projects, test plans and also
as a reporting help, in a solution. For this, custom-defined tables can be used with a defined range of
possible input values.
What to do
Screen Display
Customization in
transaction SPRO
Creation of
Structure/Object attribute
“Area”
37
What to do
Screen Display
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
38
What to do
Screen Display
Assign attribute
Z_COMPONENT to object
Project and Solution Node
Set the other options
Result: the attribute is
available for business
process structures
39
7.1.2.5 Customer Attributes for Documents
To improve reporting of documents in the design or configuration phase of your project, it is possible to
create customer attributes for documents. The advantage of these attributes is their ALM accomplishment.
This means that those attributes will be passed to all document copies of the original documents. One
possibility for such an attribute is the Project ID under which the document was created/changed. The
information on who changed the attribute and when it was changed will be logged in the history of the
document. The customization described below is done with the example of Project ID as an attribute.
What to do
Screen Display
Create an attribute through
transaction SPRO
Create an attribute
“Project ID”
40
What to do
Screen Display
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
41
What to do
Screen Display
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.
42
7.2 Major release Project Creation
To use the major release project in SAP Solution Manager, there are several steps to be maintained in the
system:
 Project Creation in different KW Enhancement
 System landscape maintenance
 Business process structure copy
 Behavior of assignments:
- Document
- Transactions
- Configuration
- Structure Attributes
- Document Attributes
What to do
Screen Display
major release Project Creation
Enter the T-Code
SOLAR_PROJECT
_ADMIN and then
you will go to the
project
administration
screen where you
can start to create
the project.
Maintain Mandatory Fields and Save
You can assign the
solution to the
project when the
project deals with
the same system
landscape
43
What to do
Screen Display
During saving, the
KW Enhancement
has to be changed
from KWCUST 620
to any other one
Business Process Assignment
a. Navigate to
the business
blueprint screen
a. Business
processes will
be copied into
the project:
44
What to do
Screen Display
b. together with
all assignments
on all tabs
Document Management in a Major release Project
a. All
Documents are
linked from the
solution into the
project. The
picture shows a
change to a
document in the
maintenance
project
assigned to the
solution.
Document
attributes are
changed
(project ID)
b. Changes
made in
maintenance
will also be
reflected in the
major release
project
45
What to do
Screen Display
c. As soon as
the document is
changed, the
system will
create a copy.
Changes made
to this
document will
not be reflected
in the solution/
maintenance
documentation.
At the end of
the major
release project,
the document
content is
merged with the
original
document
stored in the
solution
(through
maintenance).
This will be
visible in all
other potential
major release
projects
46
7.2.1 Compare & Adjust: From Maintenance to Major release project
Use the Compare & Adjust procedure after every maintenance cycle:
What to do
Screen Display
New Documentation is
created during
maintenance
Start Compare & Adjust
(transaction
SA_PROJECT_UPGRAD
E) for the major release
project
47
What to do
Screen Display
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 Major release Project
During the project implementation phase, the test phase is prepared. Existing test cases (coming from the
solution) can be reused or redesigned. Afterwards, test plans and test packages can be generated according
to business processes and the progress of testing and reporting can be tracked.
Test Case Assignment in a Project
In a major release project, it is possible to assign or redesign test cases, ECATT scripts, or to assign test
descriptions to business scenarios, business processes or business process steps.
These test documents can be reused for test plan creation.
48
What to do
Screen Display
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.
7.2.3 Learning Map
What to do
Screen Display
Create a Learning Map
using transaction
SOLAR_LEARNING_MA
P
49
What to do
Screen Display
Create Chapter and Units
Search for training
material and assign these
to the units.
50
What to do
Screen Display
Send to End User
7.2.4 Go-Live and Delta Adjustment to the Solution
What to do
Screen Display
For the handover of
redesigned Business
Processes, the extended
Compare &Adjust can be
used
51
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.
What to do
Screen Display
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 „Checkout/Check-in‟ functionality.
52
What to do
Screen Display
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/Checkout‟ button in the Solution
Directory and maintenance
project, to perform post
go-live maintenance.
53
www.sap.com
© 2012 SAP AG. All rights reserved.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP
BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP
products and services mentioned herein as well as their respective
logos are trademarks or registered trademarks of SAP AG in Germany
and other countries.
Business Objects and the Business Objects logo, BusinessObjects,
Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and
other Business Objects products and services mentioned herein as
well as their respective logos are trademarks or registered trademarks
of Business Objects Software Ltd. Business Objects is an SAP
company.
Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL
Anywhere, and other Sybase products and services mentioned herein
as well as their respective logos are trademarks or registered
trademarks of Sybase Inc. Sybase is an SAP company.
Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services are
registered trademarks of Crossgate AG in Germany and other
countries. Crossgate is an SAP company.
All other product and service names mentioned are the trademarks of
their respective companies. Data contained in this document serves
informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials
are provided by SAP AG and its affiliated companies ("SAP Group")
for informational purposes only, without representation or warranty of
any kind, and SAP Group shall not be liable for errors or omissions
with respect to the materials. The only warranties for SAP Group
products and services are those that are set forth in the express
warranty statements accompanying such products and services, if
any. Nothing herein should be construed as constituting an additional
warranty.

Business Process Redesign in SAP Solution Manager Application

Transcription

Similar documents

Record of Achievement

Formerly, Zygen Technology

unit 5: financials - [email protected]

Efficient project management – Although employees are

Supply Chain Through Mobility

High Voltage Maintenance

Record of Achievement

Codescan Brochure

Hallmark: Transforming Retail Merchandising and Field

Halfords` SAP Upgrade and Migration to the Cloud