Professional Documents
Culture Documents
Business Process Redesign - SOLMANALM
Business Process Redesign - SOLMANALM
Business Process Redesign - SOLMANALM
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
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.
A solution, on the other hand, contains information on the current use of business processes in a productive
environment.
In the following chapters (2.2-2.5) the different project types are described.
2.2 Template Project
A template project can be used to create and distribute a template. A template defines a project structure, or
parts of it. Its assigned objects (documentation, test cases, IMG activities, development and training material)
are available to other projects as templates.
Templates can be locked against changes, completely or partially, when used in several projects. In case
several SAP Solution Manager systems are being used in parallel, templates can be transported from one
central system (where the structures and assignments are defined) to another system.
Additionally, the template project offers the possibility to translate the project structure (consisting of
business scenarios, processes and business process steps). It is also possible to translate the content of the
documents within the Knowledge Warehouse (KW) functionality in which they are stored.
Template projects are especially suited to SAP Partner Solutions or Global Rollouts.
Urgent correction: errors and hot fixes; this usually does not have an impact on the
business process documentation (back to designed behavior).
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.
Advantages:
Clear separation of processes by SAP Module (mostly combined with module-based business
scenarios)
Disadvantages:
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.
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
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.
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.
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.
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.
Show how this procedure is executed in SAP Solution Manager.
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
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
Step
Test Cases
ZUT
User Training
Step
Training Material
ZINT
Interface Description
Interface Step
Gen./Project Documentation
Above document types are examples. Different document types can be created to suit different
requirements.
Show how this procedure is executed in SAP Solution Manager.
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.
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.
Show how this procedure is executed in SAP Solution Manager.
14
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
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
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.
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).
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.
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
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
customizing) as well as system landscape information in SAP Solution Manager, such as the definition of
logical systems: the source, target, and production.
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.
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
What to do
Screen Display
24
What to do
Screen Display
Select Continue.
25
What to do
Screen Display
26
What to do
Screen Display
Select Continue.
Select Continue.
27
What to do
Screen Display
Select Continue.
28
ZBPD:
ZCON:
ZFSP:
ZTSP:
ZUT:
ZUAT:
ZAUT:
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)
30
What to do
Screen Display
Possible corrections on
the Documentation
template
Z_NEW
Z_PROGRESS
Z_APPROVAL
Z_RELEASED
Status value Z_RELEASED shall be included into the table for Read Authorization.
Please create one common Release status value for all status schemas.
Where to configure/how to do:
31
What to do
Screen Display
32
What to do
Screen Display
Definition of Status
Schema
33
What to do
Screen Display
34
What to do
Screen Display
Download of
SOLARBLUEPRINT.DOC
and correction
(replacement of Logo).
35
What to do
Screen Display
36
What to do
Screen Display
Customization in
transaction SPRO
Creation of
Structure/Object attribute
Area
37
What to do
Screen Display
Assign attribute
Z_SAP_AREA to objects
.
38
What to do
Screen Display
Assign attribute
Z_COMPONENT to object
Project and Solution Node
39
What to do
Screen Display
Create an attribute
Project ID
40
What to do
Screen Display
Record changes in a
package .
41
What to do
Screen Display
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
What to do
Screen Display
43
What to do
Screen Display
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
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
What to do
Screen Display
New Documentation is
created during
maintenance
47
What to do
Screen Display
48
What to do
Screen Display
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.
What to do
Screen Display
49
What to do
Screen Display
50
What to do
Screen Display
What to do
Screen Display
51
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.
53
www.sap.com