Professional Documents
Culture Documents
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
Business Process Major release Redesign
3
Business Process Major release Redesign
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
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.
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
Business Process Major release Redesign
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.
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:
5
Business Process Major release Redesign
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.
6
Business Process Major release Redesign
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.
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.
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
Business Process Major release Redesign
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.
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.
8
Business Process Major release Redesign
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.
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).
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
Business Process Major release Redesign
As shown in figure 3-4b the green arrows connect four business process steps from several modular
business processes into a business process chain. In this chain some business process steps are not
involved (part of blue line connected processes). However, if you recognize the modular process they play
an important role to build an information flow within a modular business process. By use of attribute End-to-
End Test relevant you can control the visibility of the End-to-End relevant business process steps in test
environment.
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.
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
Business Process Major release Redesign
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.
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
Business Process Major release Redesign
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.
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 Major release Redesign
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)
Document
Description Structure Tab
Type
Above document types are examples. Different document types can be created to suit different
requirements.
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
Business Process Major release Redesign
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.
14
Business Process Major release Redesign
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.
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
Business Process Major release Redesign
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
Business Process Major release Redesign
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.
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
Business Process Major release Redesign
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.
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).
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.
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
Business Process Major release Redesign
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.
Show how this procedure is executed in SAP Solution Manager.
19
Business Process Major release Redesign
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:
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.
Activating the ChaRM flag for your maintenance project allows the system to control all changes planned for
the maintenance system landscape in so-called maintenance cycles.
4.1.1 Method
After configuring and activating the standard ChaRM functionality in your system, you can use the workflow-
based functionality. This means that when a change necessity is detected (possible integration into SAP
Solution Manager service desk), the change can be requested using the Change Request. This transaction
type is used for approval workflow tasks. During the workflow, the change is categorized (see 4.1.2 Change
Types), and then approved or rejected by a change manager. Once the change has been approved, the
system will create another transaction type (based on the categorization) called the change document. This
type of document is used to perform all development activities aligned to the approved change request.
Typical tasks are:
Creation of a transport request
Logon to relevant system to develop/test/validate the requested functionality
Testing
Organization of transport (depending on change type)
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
Business Process Major release Redesign
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 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.
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.
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).
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
Business Process Major release Redesign
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
Business Process Major release Redesign
6 AUTHORIZATIONS
6.1 Projects
Concerning restrictions, you have two options:
You could use the authorization object S_PROJECT. Depending on the number of implementation projects,
you could:
1) Assign the authorization for specific projects to the object (PROJECT_ID Project name) to which the
user has access.
2) Work with a predefined name space for the projects (e.g., Implementation Projects begins with I;
template projects with T). Afterwards, you prepare the object S_PROJECT for several users (one group
has PROJECT_ID = I* and the other PROJECT_ID =T*).
Authorization object S_PROJECTS and S_PROJECT can be found, for example, in the role
SAP_SOLAR_PM. Please copy the role and set it up.
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.
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.
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
Business Process Major release Redesign
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).
24
Business Process Major release Redesign
Select Continue.
25
Business Process Major release Redesign
26
Business Process Major release Redesign
Select Continue.
Select Continue.
27
Business Process Major release Redesign
Select Continue.
To use document management in SAP Solution Manager, some adjustments and customization is needed.
28
Business Process Major release Redesign
At the least, the following document types should be available in the customer system (example):
Document Types
(transaction
SOLAR_PROJECT_ADMI
N menu Goto Project
Template
Implementation Project,
Template Project)
Select Documentation
Type Tab
29
Business Process Major release Redesign
Define Documentation
Type (here: ZBPD)
30
Business Process Major release Redesign
Possible corrections on
the Documentation
template
Document types are assigned to customer specific status schema(s). All status schemas contain customer
defined status values like:
Z_NEW
Z_PROGRESS
Z_APPROVAL
Z_RELEASED
Status value Z_RELEASED shall be included into the table for Read Authorization.
Please create one common Release status value for all status schemas.
Where to configure/how to do:
31
Business Process Major release Redesign
32
Business Process Major release Redesign
Definition of Status
Schema
33
Business Process Major release Redesign
34
Business Process Major release Redesign
The functionality for creating the Business Blueprint is provided for all project types in SAP Solution
Manager. Using it, you can create the blueprint document based on the content of all blueprint-relevant
documents collected for the rollout project (process description, functional specification or similar). The
template of the blueprint document can be adjusted in customizing as shown.
Download of
SOLARBLUEPRINT.DOC
and correction
(replacement of Logo).
35
Business Process Major release Redesign
36
Business Process Major release Redesign
Structure attributes are typically used for filtering purposes in templates, rollout projects, test plans and also
as a reporting help, in a solution. For this, custom-defined tables can be used with a defined range of
possible input values.
Customization in
transaction SPRO
Creation of
Structure/Object attribute
Area
37
Business Process Major release Redesign
Assign attribute
Z_SAP_AREA to objects
.
38
Business Process Major release Redesign
Assign attribute
Z_COMPONENT to object
Project and Solution Node
39
Business Process Major release Redesign
To improve reporting of documents in the design or configuration phase of your project, it is possible to
create customer attributes for documents. The advantage of these attributes is their ALM accomplishment.
This means that those attributes will be passed to all document copies of the original documents. One
possibility for such an attribute is the Project ID under which the document was created/changed. The
information on who changed the attribute and when it was changed will be logged in the history of the
document. The customization described below is done with the example of Project ID as an attribute.
Create an attribute
Project ID
40
Business Process Major release Redesign
Record changes in a
package .
41
Business Process Major release Redesign
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
Business Process Major release Redesign
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
43
Business Process Major release Redesign
a. Navigate to
the business
blueprint screen
a. Business
processes will
be copied into
the project:
44
Business Process Major release Redesign
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
Business Process Major release Redesign
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
Business Process Major release Redesign
Use the Compare & Adjust procedure after every maintenance cycle:
New Documentation is
created during
maintenance
47
Business Process Major release Redesign
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.
48
Business Process Major release Redesign
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.
49
Business Process Major release Redesign
50
Business Process Major release Redesign
51
Business Process Major release Redesign
A solution is created after go-live. From now on, all operations and maintenance are executed on the solution
instead of the project.
Maintenance Project
To change the business
process structure in a
solution, it is
recommended to use a
maintenance project
instead of making changes
directly to the solution
Assign a maintenance
project to a solution, and
then enable the Check-
out/Check-in functionality.
52
Business Process Major release Redesign
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
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.