Business Process Redesign in SAP Solution Manager Application Lifecycle Management
Oct 24, 2014
Business Process Redesign
in SAP Solution Manager
Application Lifecycle
Management
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 2 of 59
Copyright
© 2011 by SAP AG.
Neither this document nor any part of it may be copied or reproduced in any form or by any means, or translated into another language, without the prior consent of SAP Active Global Support. All rights reserved. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects, products and services mentioned herein, as well as their respective logos, are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serve informational purposes only. National product specifications may vary. These materials are subject to change without notice. SAP AG and its affiliated companies („SAP Group“) provide these materials for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 3 of 59
Index
Copyright .............................................................................................................................................. 2
1 Introduction .................................................................................................................................... 5
2 General Explanation ..................................................................................................................... 5
2.1 Projects and Solutions ......................................................................................................... 5
2.2 Template Project ................................................................................................................... 6
2.3 Implementation Project ........................................................................................................ 6
2.4 Maintenance Project ............................................................................................................. 7
2.5 Upgrade Project for Existing Systems ............................................................................... 7
2.6 Projects and Solutions Dependencies ............................................................................... 8
2.7 Business Process Design .................................................................................................... 8
2.8 Business Process Assignments ....................................................................................... 12
2.9 Document Management .................................................................................................... 13
2.10 Procedures for Solution Documentation ......................................................................... 16
2.10.1 Interface Scenarios ..................................................................................................... 18
3 Building Long-Term Projects ..................................................................................................... 19
3.1 Document Management in a Long-Term Project ........................................................... 21
3.2 Methodology for Long-term Project (Roadmap) ............................................................ 21
3.3 Testing in the Long-Term Project ..................................................................................... 22
3.4 Training Materials ............................................................................................................... 22
3.5 Go-Live and Maintenance ................................................................................................. 23
4 Change Request Integration ..................................................................................................... 23
4.1 ChaRM in a Maintenance Project .................................................................................... 23
4.1.1 Method .......................................................................................................................... 23
4.1.2 Change Types ............................................................................................................. 24
4.1.3 Phase Change (Task List) ......................................................................................... 24
4.1.4 Business Process Integration for Document Management .................................. 25
4.2 ChaRM in Long-Term Project ........................................................................................... 25
4.2.1 Method, Change Types and Phase changes (Task list) ....................................... 25
5 Organizational Aspects for Long-Term Projects in SAP Solution Manager ...................... 25
6 Authorizations .............................................................................................................................. 27
6.1 Projects................................................................................................................................. 27
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 4 of 59
6.2 Document Management .................................................................................................... 27
7 Setup/Configuration and Procedures ...................................................................................... 29
7.1 General Configuration ........................................................................................................ 29
7.1.1 Definition of System Landscape – SMSY ............................................................... 29
7.1.2 Project Standards ....................................................................................................... 33
7.1.3 Definition of Document Types ................................................................................... 34
7.1.4 Definition of Status Schema ...................................................................................... 36
7.1.5 Adjustments to Blueprint Document ........................................................................ 40
7.1.6 Structure/Object Attributes ........................................................................................ 42
7.1.7 Customer Attributes for Documents ......................................................................... 45
7.2 Long-Term Project Creation .............................................................................................. 48
7.2.1 Compare & Adjust: From Maintenance to Long-Term project ............................ 53
7.2.2 Testing in the Long-Term Project ............................................................................. 54
7.2.3 Learning Map ............................................................................................................... 56
7.2.4 Go-Live and Delta Adjustment to the Solution ....................................................... 57
7.2.5 Post Go-Live Maintenance ........................................................................................ 58
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 5 of 59
1 Introduction
The SAP Solution Manager is positioned as an Application Management Platform for SAP centric solutions.
The major focus of SAP Solution Manager is on solution operation and optimization. It also functions as a collaborative infrastructure between the customer and SAP. This includes remote support as well as collaborative scenarios between the customer operation and the SAP service organizations.
Apart from solution operation, the SAP Solution Manager platform also provides an infrastructure for overall application management: from requirement/change request management, through design, build, test, deploy, and operation/optimization, with a major focus on change control.
Depending on the scope of the SAP Solution Manager processes being implemented and depending on the structure of the company, the SAP Solution Manager can be an easy setup or an implementation project by itself.
The following content describes one of the Application Lifecycle Management (ALM) possibilities in SAP Solution Manager for an example of a long-term project (which performs changes to productively used business processes which are stored in a solution). This includes references to test capabilities, Business Process Monitoring, and Change Request Management (ChaRM).
2 General Explanation
2.1 Projects and Solutions
As shown in the picture below, projects and solutions are simply overviews of business
process information. A project in SAP Solution Manager provides information on the future
use of business processes: this includes business process redesign and new business
process implementation.
Figure 2-1 Project and Solution
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 6 of 59
A solution, on the other hand, contains information on the current use of business processes
in a productive environment.
In the following chapters (2.2-2.5) the different project types are described.
2.2 Template Project
A template project can be used to create and distribute a template. A template defines a project structure, or parts of it. Its assigned objects (documentation, test cases, IMG activities, development and training material) are available to other projects as templates.
Templates can be locked against changes, completely or partially, when used in several projects. In case several SAP Solution Manager systems are being used in parallel, templates can be transported from one central system (where the structures and assignments are defined) to another system.
Additionally, the template project offers the possibility to translate the project structure (consisting of business scenarios, processes and business process steps). It is also possible to translate the content of the documents within the Knowledge Warehouse (KW) functionality in which they are stored.
Template projects are especially suited to SAP Partner Solutions or Global Rollouts.
2.3 Implementation Project
Implementation projects can be used to implement business processes in an SAP landscape. A project structure has to be created for the business processes. You can either create a new project structure, or base it on any one of the following:
o one or several templates o existing project(s) o scenarios and configuration structures delivered by SAP (Business Process
Repository) o an existing production solution landscape for long-term changes to
productively-used business scenarios
Typical Use Case in ALM:
A template project can be used for:
1. Definition and documentation of global business processes and their preparation for rollouts. The preparation of the global processes can comprise business process flow, transaction assignments, descriptions, documents, configuration and development assignments as well as predefinitions of test cases and training material. The more content prepared in the template, the easier the rollout from a documentation perspective.
2. As business process library connected to a modelling tool to manage changes and redesigns of business processes. Except for the business process flow, changes all other assignments like: documents, IMG objects. Test cases will be done in SAP Solution Manager. This use case can be combined with the rollout use case.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 7 of 59
Typical Use Case in ALM:
An implementation project can be used for two typical use cases:
1. Implementation of new business processes, where the scope can be defined, based on:
a. Predefined business processes from a template project. Predefined business processes can be changed according to global attributes defined in the template.
b. Normal implementation without template predefinitions (manual business process creation and documentation). Here, the business processes can be created and changed independently during the implementation.
2. Long term changes to productively used business processes stored in a solution. Those business processes can be redesigned in this project (without system upgrade) and afterwards all deltas are handed over to the solution.
2.4 Maintenance Project
The maintenance project can be used to keep track of changes in the productive environment (solution).
o in Change Request Management. The project contains all maintenance activities and urgent corrections of a solution.
o in Check Out/In for business processes, redocumentation/changes from the Solution Directory. These changes are then performed in a maintenance project linked directly to the solution.
Typical Use Case in ALM:
Assignment to a solution with activated Check Out/In functionality can be used to reflect all changes made to productively used business processes and their documentation, during the maintenance cycles. These are typically small transactional corrections or configuration tasks.
Types of possible changes:
o Urgent correction: errors and hot fixes; this usually does not have an impact on the business process documentation (back to designed behavior).
o Normal corrections: pertains to all changes to a business process or a business process step which can be completed within a short of the maintenance cycle. This typically involves minor reconfiguration or additional small developments (no business process redesign). These changes are reflected in business process documentation.
2.5 Upgrade Project for Existing Systems
In an upgrade project you can:
o upgrade the customization: upgrade existing functions
and/or
o delta the customization: copy additional functions
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 8 of 59
Typical Use Case in ALM:
Redesign of business processes and their documentation caused by a technical upgrade of the system(s) on which they are running. The upgrade project is typically based on a solution with the latest up-to-date process documentation.
2.6 Projects and Solutions Dependencies
Using application management in SAP Solution Manager creates information flow and data
exchange between a project and its operational areas. The information flow is depicted in
Figure 2-2, below.
Figure 2-2 Information Flow between different Projects and a Solution
The same content (business process and attached information) is reused and passed on to
typical project phases, such as: design, realization, test, and go-live and also between the
different project types and the solution. As such, the requirements on the business process
design can be very complex. Please refer to the chapter Business Process Design.
2.7 Business Process Design
Proper business process design and appropriate grouping into scenarios are key decisions
when starting ALM in SAP Solution Manager. By choosing the wrong design, reusability is
impaired. This affects future use of the content for purposes like testing or Business Process
Monitoring. Business processes should be organized in business scenarios. Here, module-
oriented scenarios can be used, or module-oriented business processes can be combined
into end-to-end business scenarios.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 9 of 59
Below, two methods are described (SAP module- or End-to-End oriented), for designing
business processes in SAP Solution Manager. Visibility and reporting capabilities can be
improved through structure attributes.
2.7.1.1 Definitions of Business Scenario, Process and Step
o A business process step is most commonly related to a transaction, a background
job, a web UI or similar system activities. Sometimes it makes sense to also
document some activities within the business process flow.
o A business process is a collection of business process steps, grouped according to
a certain criterion like business content or SAP modules.
o A business scenario is a collection of business processes to be executed one by
one resulting in the execution of an operational procedure. Scenarios can be
organized by business unit, SAP module or other kinds of grouping (e.g. template-
related).
The SAP Note 1345599 describes the restrictions to size for business scenarios.
2.7.1.2 End-to-End Oriented Business Process Design
In designing end-to-end business processes, you have to answer the question what “end-to-
end” means for your business unit(s). This difficulty shows up at the start of business process
documentation, and is mostly connected to organizational aspects (user access, organization
of monitoring etc.). However, this is the most reusable business process model for
documentation purposes, test capabilities, interface documentation and Business Process
Monitoring. It is recommended to use structure attributes or custom attributes for documents
when organizing the business process documentation in relation to SAP modules.
Figure 3-1 End-to-End Oriented Business Process Design
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 10 of 59
2.7.1.3 Module-Oriented Business Process Design
In a module-oriented business process you typically describe business process steps that
belong together and that are executed one after the other in a single module. However, to
increase the quality and the number of further possibilities in SAP Solution Manager, it is
recommended to represent preceding or succeeding steps also (documentation of Interface
Scenarios) as shown in the following graphic.
Figure 3-2 Module-Oriented Business Process Design
Advantages:
o Clear separation of processes by SAP Module (mostly combined with module-based
business scenarios)
Disadvantages:
o Additional work to build test-related business processes
o Without “interfaces” to other business processes, no possibility to document system
interfaces
Therefore, a better option is to document the connections to other business processes,
highlighting interfaces, as shown in the following Figure 3-3.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 11 of 59
Figure 3-3 Extended Module-Oriented Business Process Design
2.7.1.4 Business Scenario Definition
To combine both models, you can compose end-to-end business scenarios from a mixture of
module-oriented business processes. These are executed one after the other in order to
perform a business activity.
Figure 3-4 Business Scenario Execution
To do so, use the Graphic tab at scenario level to document the order in which the business
processes are to be executed.
How business scenarios are organized also determines how to roll them out using templates
(Template as Information Provider).
2.7.1.5 Structure Attributes
As of support package 15 (EHP 1) for SAP Solution Manager 7.0, it is possible to define and use structure and object attributes. Structure attributes can support all types of filtering or reporting capabilities during typical project phases like blueprint, configuration, testing, or after go-live in maintenance. The biggest advantage of structure and object attributes is that they can be copied together with the structure, whenever the structure is reused (template Rollout Solution Maintenance).
Once assigned, structure attributes can be adjusted with the Compare & Adjust function using the transaction SA_PROJECT_UPGRADE. This ensures that all changes made to
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 12 of 59
attributes and their assignment to the business processes or business process steps are current at all times throughout the entire business process lifecycle.
Figure 3-5 Business Scenario Execution
Show how this procedure is executed in SAP Solution Manager.
2.8 Business Process Assignments
Apart from documenting the business process structure in the template project, you can also
document technical objects, like:
o Transactions: the assignment of transaction information to the business process
steps determines which transaction(s) will be used to perform a certain business
process step, in the managed system. This information is usually defined during the
blueprint stage, and is reused for testing, Business Process Monitoring, business
process change analysis and other functions.
o Configuration Objects: all objects, assigned to the configuration tab of a business
process or a business process step, document the customizing views. These have to
be maintained to ensure that the business process/step runs, as designed during the
blueprint stage.
o Development Objects: all modifications are documented as an assignment of the
developed object to the business process/step for which the modification was
created. Additionally, technical documentation for the modifications and extensions
can be assigned and connected to the development object directly.
o Test Case Descriptions: The testing prescriptions for a business process step are
assigned to appropriate structures (using the test object results in a transaction
assigned to the business process step). During the creation of a test plan, the test
case descriptions can be selected and brought into the test scope as a test case
(together with assigned transactions).
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 13 of 59
o Training Materials: The training documents, which describe how a transaction is to be
used by end users in the context of the business process, can be assigned to the
business process step on the Training tab. These documents can be used to create
Learning Maps and distribute them to end user groups.
o End User Groups: To document which business process step is used by which group
predefined end user groups can be assigned. This assignment can be used as a
filtering criterion for Learning Map creation.
2.9 Document Management
Document management in SAP Solution Manager uses the Knowledge Management (KM)
functionality with additional functions specific to SAP Solution Manager. All documents are
physically organized in so-called KW Folders. This folder (folder group) is used to check the
authorization for all documents stored inside. Please refer to the chapter “6.2 Document
Management” (Authorization).
Document Types
SAP Solution Manager uses predefined document types to document business processes
and steps. Reusable document types can be predefined centrally by uploading document
templates into SAP Solution Manager. To this end, all relevant forms and templates can be
uploaded into SAP Solution Manager to make them available for later documentation during
the blueprint or configuration project phase.
Recommendation: Define and use customer-specific document types created in a customer
name space (Z* or Y*).
Show how this procedure is executed in SAP Solution Manager.
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:
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 14 of 59
o The lower the level of the information the better. This means that the more granular a
document the better suited it is to be reused.
Business Process Step Example: Create purchasing scheduling agreement
(transaction ME31L)
General Documentation Tab: contains documents describing the design of transaction
ME31L ( in case template management was used, functional
specification or additional documentation…)
Project Documentation Tab: project related documentation for ME31L
Configuration Tab: document describing the configuration needed for transaction
ME31L (Configuration objects and descriptions, Authorization
Roles…)
Development Tab: All developments needed to run the transaction ME31L
(Technical specifications, development forms…)
Test Case Tab: Test case descriptions. All types of functional tests can be
represented by different document types. Additionally, test
data documents can be assigned at business process level.
Training Materials: All kinds of training documents which will be made available
to end users (simulations, presentations)
o Use of a common final status value for all document types (documents). All document
types use the same or different status schema(s). Every status schema ends with the
same common final status value.
o Reuse of documents by links. In order to decrease the number of documents, you can
link documents to the same business process steps used in different business
processes (basic documentation). Additional documents describing the differences can
be assigned to the occurrence selectively.
Document
Type Description Structure Tab
ZBPD Business Process Description Business Process Gen/Project. Documentation
ZFSP Functional Specification Business Process/Step Gen./Project Documentation
ZCON Configuration Description Business Process/Step Configuration
ZAUT Authorization Business Process/Step Configuration
ZTSP Technical Specification Business Process/Step Development
ZTCD Test Case Description Step Test Cases
ZUT User Training Step Training Material
ZINT Interface Description Interface Step Gen./Project Documentation
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 15 of 59
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.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 16 of 59
2.10 Procedures for Solution Documentation
The information about current productively used business processes can be collected
centrally by business process owners or from existing documents into an excel file (1). In this
file, the business process structure is created. In the same file, an assignment of transaction
codes to business process steps, logical components (in which the transaction is executed),
and links to all relevant documents which have to be migrated to SAP Solution Manager are
created. Typically, you can upload business process descriptions, specifications, and test
cases to the appropriate tabs (please refer to the previous chapter “2.8.1 Document
Management”).
After all data relevant to migration have been collected into an excel file, the data have to be
converted to an XML format. Afterwards, the data can be uploaded easily using report
RS_SA_PROJECT_IMPORT (2) into an existing implementation or template project.
This conversion from excel into xml format is a consulting solution. In the 7.1 release of SAP
Solution Manager, this possibility is provided in the standard version.
After these steps have been performed, the data can be entered directly into SAP Solution
Manager using SOLAR01/02 where additional data like development objects, configuration
views, or structure / document attributes can be assigned to the structure.
Figure 4-1 Business Process migration
After the migration content has been uploaded into SAP Solution Manager and extended by
additional assignments, you can start verifying it using the Solution Documentation Assistant
(SDA). To do so, the business processes have to be copied into an SDA analysis project (3).
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 17 of 59
This copy will take business process structures with all assigned transaction/report
information from the Transaction tab. If no further checking rules are assigned to the
business processes in the analysis, the system will analyze the business processes based
on the statistics for actively used transactions in the managed systems. Since the business
processes were created based on the experience of business process owners and/or on
existing documents, no red alerts should appear (a red alert means that the transaction has
not been executed).
Once the verification is completed and has yielded positive results (which means that all
transactions used for business process documentation are executed in managed systems),
the content can be copied into a solution (4). A few tasks need to be performed during the
content copy of the documentation project into a solution:
o Creation of a Solution: The business processes and their entire documentation will
be stored in the solution after go-live.
o Content copy from Project into Solution: It is recommended to use the work center
to copy the business processes from the rollout project into the solution. Once the
content is copied, all documents will turn into “Copy of…” and will get initial document
status. To fix this, you can use the BAdI interface IF_EX_SOLAR_DOCUMENTS. All
other objects will be copied from the project into the solution directly (together with
structure and document attributes). If necessary, the logical components can be
replaced by those representing the maintenance landscape.
Show how this procedure is executed in SAP Solution Manager.
o Content Maintenance: To perform planned changes to the productive content, it is
recommended to create and assign a maintenance project to the solution. By
activating Check In/Out, the business processes cannot be changed in a solution, but
exclusively in the maintenance project assigned to it (5+6). Optionally, the Change
Request functionality can be activated for this maintenance project.
Before each maintenance cycle, the planned normal corrections can also be reflected
in the checked out structures, where documentation and further assignments can be
adjusted.
However, business process flow changes cannot be performed in a maintenance
project. These redesigns of productively used business processes can be performed
in so-called long-term projects.
Show how this procedure is executed in SAP Solution Manager.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 18 of 59
In case the maintenance project is also used for change request management purposes, all
logical components collected in the solution have to follow the same maintenance cycle.
2.10.1 Interface Scenarios
SAP Solution Manager provides the possibility to document interfaces between systems.
Interfaces can be specified in a specific interface scenario structure. For each interface, you
can specify the sending and receiving system; the type and technology. On the
documentation tabs, the interfaces can be documented and described.
Once the interfaces are documented, you can assign them to the appropriate business
processes on the Graphics tab. This assignment of one interface can be done several times
for several business processes. After this, evaluating which interface is used for which
process becomes very easy.
Once the interface is assigned to a business process in a documentation project, and the
content is used to build a solution, the interface information is still represented on the
Graphics tab. However, the original information is still in the documentation project. In this
case, it is recommended to resolve the external interface thereby copying the original
interface into the solution.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 19 of 59
3 Building Long-Term Projects
Once the business processes are documented in a solution, and the maintenance is in
progress, you can start using the long-term method to redesign business processes. To
ensure that during the redesign, all changes to the business process documentation are also
reflected in the long-term project, the long-term project should be created in a different KW
enhancement. This demands a specific procedure for the creation of a long-term project.
Once this has been done, the business processes which are to be redesigned can be copied
into the projects (1). Choose the option “Refer Documents” to ensure that changes to existing
maintenance documents are reflected in the long-term project.
Figure 5-1 Creation of Long-term Project and Change Reflection
It could happen that during long-term project redesign of the business process the same
business process content is changed in the maintenance project (2 + 2). The changes to the
documents available during the process copy are immediately reflected in the long-term
project documentation (because all documents are linked). In case new documents were
created, or new assignments were made to the business process with a maintenance
project, the Compare & Adjust should be performed on the long-term project separately
(3+3). In the SAP Solution Manager release 7.0 this has to be done manually, in the release
7.1 you can make use of an extended Compare & Adjust functionality which detects these
changes automatically. After the maintenance cycle is finished, the content can be checked
in into the solution (4) and all changes made during the maintenance cycle will become
visible in the solution as well.
While the maintenance cycles are being performed, the long-term project changes the
business processes by assigning new content (5) or by completely redesigning the business
processes using the old content as a starting point.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 20 of 59
Figure 5-2 Long-Term Go-Live
When the old documents have to be adjusted (4), the system will create a copy (due to the
different KW enhancement). Using this procedure ensures that current productive
documentation is not changed unintentionally.
Newly created documents can be signed additionally with document attributes which show in
which project the document was created.
After redesigning business processes, reconfiguration in the development system and testing
of the content have to be prepared for deploy. The extended Compare & Adjust functionality
can be run (Release 7.1) against the business process source: the solution. After the
changes to the content have been detected, the appropriate business processes can be
checked out into the maintenance project (6). In the maintenance project, the consolidation
of the changes can be performed (7). All changes to documents can be merged into existing
documents (this is the only way to ensure that the new information will be visible
automatically in other projects which may run in parallel). This is also the case for process
structures and their assignments (7). As soon as all deltas are adjusted, the business
processes can be retested (in case of dual system landscape). Afterwards, all business
processes can be checked in at the end of the maintenance cycle together with the normal
maintenance content.
Show how this procedure is executed in SAP Solution Manager.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 21 of 59
3.1 Document Management in a Long-Term Project
Using a different KW Enhancement for the long-term project than for the other
projects/solutions has an important advantage: an initial link is established between the
business process documentation (which was originally stored in the solution) and the
documents available in the long-term project. So, whenever the process documentation is
changed in maintenance, the changes will be reflected automatically in the long-term project
as all documents are linked.
For all business processes which have to be redesigned existing documentation can be
reused. However, as soon as an existing document is clicked in change mode, it will cause
the document to be copied automatically. This happens because the long-term project was
created in a different KW Enhancement (the system does not allow bidirectional links
between two projects which are in different KW Enhancements). You will be informed about
the creation of the copy by a popup. The newly created copy will have the same content, but
will be a physically independent object, where new information can be stored. To highlight all
new documents, you can use the customer attributes for documents to assign the project ID,
in which the document was created/changed. Additionally, the BAdI interface
IF_EX_SOLAR_DOCUMENTS can be used to prevent the title changing to “Copy of…” and
to pre-fill the document attributes for documents.
During the go-live, all the redesigned processes have to be reflected in the solution content.
In case other parallel projects are using the same business processes as those in
consolidation, the documents are merged with the original documents. From now on, you can
use the extended Compare & Adjust functionality to detect business process deltas and
“new” documents.
3.2 Methodology for Long-term Project (Roadmap)
To document the methodology of a long-term project, you can use the Roadmap
functionality. Within transaction RMMAIN, you have access to standards like ASAP or
Upgrade Roadmaps which SAP delivers. You can also define and create your own
Roadmaps in SAP Solution Manager, using transactions RMDEF and RMAUTH. In this case,
customer-specific phases, tasks, and activities can be described and customized, and
accelerators can be provided (documentation on how to proceed with the phase, task or
activity).
Roadmaps, which are assigned at a later point in time to the long-term project, can be used
to store all document types which help to manage a project (such as meeting minutes).
These documents will not be a part of ALM (will not be handed over to the solution).
Show how this procedure is executed in SAP Solution Manager.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 22 of 59
3.3 Testing in the Long-Term Project
As the test case descriptions were uploaded into SAP Solution Manager, they are already
part of the solution. Thus, when taking the business processes into the long-term project, the
information is available there and is kept in sync with maintenance tasks.
When redefining or redesigning a business process, the assigned test case descriptions
have to be adjusted or rewritten after the new developments are implemented. You can build
a test plan based on the corrected test case descriptions and the technical business process
step information (transaction), tailor it into testable entities (test packages), and assign the
entities to the tester.
In so-called test sequences, you can rearrange the order in which test activities are to be
performed, or you can rebuild business processes for specific test types. To this end, the
structure attributes can easily be used to filter business processes which may be tested or
regrouped separately.
Show how this procedure is executed in SAP Solution Manager.
3.4 Training Materials
After successfully testing the implemented business scenarios, the end user needs to be
trained. If the training information was assigned to the business processes in the solution,
and if some business processes were redesigned during the long-term project, the training
materials can be adjusted and published/distributed using Learning Maps in SAP Solution
Manager.
The Learning Map functionality gives you the possibility to create end user group specific
Learning Maps and distribute or publish them in a specific knowledge-transfer area.
The end user will get access to the documents provided in his Learning Map, without
needing a user in the SAP Solution Manager. All training materials collated in the Learning
Map will be shown to the end user in display mode.
Show how this procedure is executed in SAP Solution Manager.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 23 of 59
3.5 Go-Live and Maintenance
o Adjustments after Maintenance Cycles: All changes to the business
scenario/process and step content which were made during maintenance should also
be reflected in the long-term project. To this end, the Compare & Adjust functionality
can be used to roll all changes made in maintenance cycles into the long-term
project.
o
Show how this procedure is executed in SAP Solution Manager.
4 Change Request Integration
To manage all changes made to all relevant development systems, you can use the Change
Request functionality. This functionality can be used for the maintenance work and the
appropriate landscape as well as for long-term projects. Change Request Management in
SAP Solution Manager consists of three main areas:
- Change Administration: Management of all change requests, change
categorization, approval workflow, and status reporting.
- Project Management: project planning, project documentation, like customizing or
development specifications and test management
- Change Logistics: Customizing and Development realization, transport scheduling
(seamless integration into TMS) and transport tracking.
Combinations of these three topics allow full control over the landscape and all changes
made to it. The following descriptions roughly explain the procedures of ChaRM use during
maintenance and for long-term projects.
4.1 ChaRM in a Maintenance Project
Activating the ChaRM flag for your maintenance project allows the system to control all
changes planned for the maintenance system landscape in so-called maintenance cycles.
4.1.1 Method
After configuring and activating the standard ChaRM functionality in your system, you can
use the workflow-based functionality. This means that when a change necessity is detected
(possible integration into SAP Solution Manager service desk), the change can be requested
using the Change Request. This transaction type is used for approval workflow tasks. During
the workflow, the change is categorized (see 4.1.2 Change Types), and then approved or
rejected by a change manager. Once the change has been approved, the system will create
another transaction type (based on the categorization) called the change document. This
type of document is used to perform all development activities aligned to the approved
change request. Typical tasks are:
- Creation of a transport request
- Logon to relevant system to develop/test/validate the requested functionality
- Testing
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 24 of 59
- Organization of transport (depending on change type)
4.1.2 Change Types
Four main Change Types, delivered in the standard version, can be used by default (as a
copy of the SAP origin):
- Normal Correction: This process is used to make regular corrections in your
maintenance landscape and to implement planned features into your development
landscape. Normal correction workflow has a strong dependency on the maintenance
cycle phase.
- Urgent Correction: This process is used to make an urgent correction in your
production system. This transaction is only permitted within a maintenance
landscape. In contrast to normal correction, urgent correction gives you the possibility
to implement the correction into your production system independently of the
maintenance cycle.
- Test Message (Defect Correction as of 7.1): This type is used during testing, for
corrective development.
- Administration Changes: This type is used for all system changes which cannot be
included in a typical transport request. An example would be number range.
4.1.3 Phase Change (Task List)
Maintenance cycles can be managed and switched in a task list. The task list is a collection
of all typical activities during the maintenance cycle.
Activating Change Request Management for the long-term project on the ChaRM tab in the
transaction SOLAR_PROJECT_ADMIN creates a task list in the background. This task list
records, collects, and manages all changes made to the managed system(s) or clients.
The task list can be used for:
Creating transport requests and tasks
Scheduled and/or on demand import
Transporting copies
Security functionalities like Cross System Object Lock and Critical Objects Check
Retrofit for n+1 landscape
Reporting capabilities
Transporting non-ABAP objects though the integration with CTS+
The Change Tracking function of Change Request Management allows you to track
everything that relates to changes within the context of a Solution Manager or an IMG
project. You can track all transport requests from the system where they are created to the
systems/clients into which they are imported. Within the project context, all transport
requests that belong to a particular project can be tracked across all the systems in the
project landscape. You can navigate into the transport logs and import queue as well as into
the corresponding service transaction or task list. You can also navigate into the Solution
Manager project, the satellite IMG project, or the CTS project.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 25 of 59
4.1.4 Business Process Integration for Document Management
Change Request Management can be used not only in a maintenance project, but especially
in connection to a solution embedded in a check out/in procedure. By using this variant, you
create a change request which is directly related to a business process or its steps. So the
information about existing change requests will be available not only in the business process
structure, but also in “Change Request” and thus also in “Change Document” on the Context
tab. This method allows you to combine the technical work with documentation tasks by
linking the Change Request Management directly to the business process documentation.
The Context tab can also be used to check out the business processes into the maintenance
project (taking into maintenance) directly and to check it back after successful testing.
Following this procedure ensures that the change documentation is always in sync with the
technical realization.
4.2 ChaRM in Long-Term Project
It is also possible to activate the Change Request Management for long-term projects. For
this project type, you can choose between three different change documents (normal
change, admin change and test message). Urgent corrections are not necessary as you are
implementing a new functionality (all fixes for production will be performed by maintenance).
4.2.1 Method, Change Types and Phase changes (Task list)
All necessary redesign tasks will be reflected by normal corrections which take longer than
the normal maintenance cycle. Once you decide to perform a long-term project and you copy
the necessary business processes into it, you will be able to assign the appropriate business
process or business process step to the Context tab of the normal correction. In this way, the
connection between the changes and the documentation is guaranteed.
Please refer to the descriptions in the chapters 4.1.2 Change Types (not „urgent correction‟)
and 4.1.3 Phase Change (Task list).
It should be noted, however, that using Change Request Management requires additional
configuration of SAP Solution Manager. This includes ChaRM-specific customizing
(activation or standard ChaRM customizing) as well as system landscape information in SAP
Solution Manager, such as the definition of logical systems: the source, target, and
production.
5 Organizational Aspects for Long-Term Projects in SAP Solution
Manager The use of SAP Solution Manager as an implementation tool also brings about the need to
ensure the quality of all activities performed in this tool. A proven method is to establish a
quality assurance team which ensures that all basic activities in SAP Solution Manager are
performed correctly.
There are several areas where governance is needed:
o System Landscape: The system landscape information is the foundation for nearly
all SAP Solution Manager functionalities. The quality assurance team should have
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 26 of 59
access to this area, be authorized to create and change managed systems, and also
be able to create all necessary RFCs for all appropriate clients. The systems can then
be grouped into logical components. These logical components are used for all
current and future projects.
o Standard and Design Definitions: To ensure the consistency of all standards used
in the projects like document types, status schemas, structures, and document
attributes, the team should also attend to design questions, decisions concerning
building of the ALM in SAP Solution Manager, and to the decisions on which non-
SAP tools have to be used for ALM purposes.
o The aim of this team should also be to ensure the correctness and quality of the
business process design. While keeping the business processes granular (please
refer to the chapter “Business Process design”), correct assignment handling has to
be guaranteed as well.
o Possible services for incoming projects:
Project Consulting (which processes, project type and so on). Before a new
project starts, the quality assurance team could discuss with Project Management
how to perform the project and how SAP Solution Manager can support them for
this purpose. Possible reuse of existing business processes or documents should
be discussed.
Project Creation. As a service to the project team, SAP can offer to take over
central activities in SAP Solution Manager like creating a project or assigning a
project landscape. This will also ensure the quality of performed tasks.
Standards Review. Definition of quality control points (Quality Gate) and regular
checks of business processes and documentation quality.
Business Process Design Consulting. Assurance that all new projects have the
same design and follow the same procedures to allow reuse in ALM.
SAP Solution Manager Consulting. This central team is the main contact point for
all requests regarding SAP Solution Manager functionalities. All customizing
and/or development activities have to be approved and activated by this team.
Knowledge Transfer. Every new project team has to be trained on how to use
SAP Solution Manager functionalities: especially on how to handle documents,
make developments, and clarify customizing tasks.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 27 of 59
6 Authorizations
6.1 Projects
Concerning restrictions, you have two options:
Restrictions between Projects:
You could use the authorization object S_PROJECT. Depending on the number of
implementation projects, you could:
1) Assign the authorization for specific projects to the object (PROJECT_ID Project
name) to which the user has access.
2) Work with a predefined name space for the projects (e.g., Implementation Projects
begins with I; template projects with T). Afterwards, you prepare the object S_PROJECT
for several users (one group has PROJECT_ID = I* and the other PROJECT_ID =T*).
Authorization object S_PROJECTS and S_PROJECT can be found, for example, in the role
SAP_SOLAR_PM. Please copy the role and set it up.
Restrictions within a Project (Structure):
The setting "Restrict changes to nodes in project to assigned team members" can be
activated in SOLAR_PROJECT_ADMIN on the Team Members tab and allows changes to
nodes in SOLAR01/02 where the user is assigned. All other nodes will only be in display
mode.
6.2 Document Management
Standard Solution: Restrictions within a Project
This solution is based on a standard functionality of SAP Solution Manager which restricts
the ability to change nodes in a project to assigned team members. This flag can be set in
transaction SOLAR_PROJECT_ADMIN on the tab Project Member. If you check this box,
only team members who are assigned in the Administration tab can work on the nodes of a
project structure. Other team members can only open the tab in display mode.
You need to change the authorization for the tab (authorization object AI_SA_TAB) to enable
assigned team members to work in the tab.
Using additional KW Folders
You can use different KW folders within one project. One KW Folder can be assigned to
exactly one folder group. The authorization for all included documents is checked against this
folder group. Please follow the description below to set these up in your system.
1) Please start transaction SI23, for the area SAP Solution Architect, and go to the menu
Settings Folder Groups. In this view, you can create a folder group for the new folder.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 28 of 59
2) Afterwards, start transaction SI80 and select the folder in which the folder group will be
changed. Go to the menu Folder Attributes Change (the context where you
currently are should be equal to the origin context in the attributes of the folder;
otherwise it will not be possible to change the folder group). Now you should be able to
choose the folder group (created in step 1), using F4-help. Alternatively, you can create
a new KW folder and assign the folder group to it.
3) The folder group can be assigned to the authorization object S_IWB. The parameter
IWB_FLDGRP is usually equal to the project name of the folder created by the system,
during project creation. Afterwards, you should be able to move special "top secret"
documents to the newly created folder, using the Attribute popup of the document and
the button “Replace Folder”.
Alternatively, the assignment is also possible when saving the document in Method
HANDLE_EXIT_BEFORE_SAVE in Class CL_SA_IO_DOC, using KW function modules.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 29 of 59
7 Setup/Configuration and Procedures
7.1 General Configuration
7.1.1 Definition of System Landscape – SMSY
SAP Solution Manager is the central access point for your landscape. If a new Managed System is to be included, some basic configuration needs to be executed in transaction SMSY either manually or automatically.
The following instructions describe how to create RFC connections between SAP Solution Manager and the Managed System. For details on how to maintain a system in SAP Solution Manager, please refer to the basic configuration guide of SMSP (Solution Manager Starter Pack).
What to do Screen Display
Select system and
client from SMSY
in SAP Solution
Manager
For a new client,
no RFC
connections are
established.
Select the client
and click button
„Generate RFC
with Assistant‟.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 30 of 59
Follow the wizard
and use default
values for
creating RFC
connections.
Select „Continue‟.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 31 of 59
Create users for
RFC connection,
select „Continue‟.
Create users for
RFC connection,
select „Continue‟.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 32 of 59
Select „Continue‟.
Select „Continue‟.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 33 of 59
Select „Continue‟.
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.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 34 of 59
7.1.3 Definition of Document Types
At least the following document types should be available in the customer system (example):
o ZBPD: Business Process Description
o ZCON: Configuration Description
o ZFSP: Functional Specification
o ZTSP: Technical Specification
o ZUT: User Training
o ZUAT: User Acceptance Test
o ZAUT: Authorization
Where to configure/how to do:
What to do Screen Display
Document
Types
(transaction
SOLAR_PROJ
ECT_ADMIN
menu Goto
Project
Template
Implementation
Project,
template
project…)
Select
Documentation
Type Tab
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 35 of 59
Define
Documentation
Type (here:
ZBPD)
Upload the
template into the
Documentation
Type
New template has
to be released in
order to be
available for later
use
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 36 of 59
Possible
corrections on the
Documentation
template
Further settings
for the
Documentation
Type like:
global availability,
several
assignments
possible,
relevance for
Blueprint
document or
status schema
assignment.
7.1.4 Definition of Status Schema
Document types are assigned to customer specific status schema(s). All status schemas
contain customer defined status values like:
o Z_NEW
o Z_PROGRESS
o Z_APPROVAL
o Z_RELEASED
Status value Z_RELEASED shall be included into the table for Read Authorization.
Please create one common Release status value for all status schemas.
Where to configure/how to do:
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 37 of 59
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
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 38 of 59
Select from the
list of available
Status Values
Definition of
Status Schema
Create the Status
Schema by
pushing “New
Entry”
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 39 of 59
Decide which
entries shall be
part of Status
Schema
Assign Status
Schema to
Documentation
Types
Make
Documentation
Type available for
project type
Return to topic content
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 40 of 59
7.1.5 Adjustments to Blueprint Document
The functionality for creating the Business Blueprint is provided for all project types in SAP
Solution Manager. Using it, you can create the blueprint document based on the content of
all blueprint-relevant documents collected for the rollout project (process description,
functional specification or similar). The template of the blueprint document can be adjusted in
customizing as shown.
Where to configure/how to do:
What to do Screen Display
Download of
SOLARBLUEPRINT
.DOC and
correction
(replacement of
Logo).
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 41 of 59
Change the
template
Upload the
template from the
storage location,
where it was
changed
From now on the
customer version
will be used to
create a blueprint
document.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 42 of 59
7.1.6 Structure/Object Attributes
Structure attributes are typically used for filtering purposes in templates, rollout projects, test
plans and also as a reporting help, in a solution. For this, custom-defined tables can be used
with a defined range of possible input values.
Where to configure/how to do:
What to do Screen Display
Customization in
transaction SPRO
Creation of
Structure/Object
attribute “Area”
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 43 of 59
Decide which
entries will be used for the
attribute (table assignment)
Assign attribute
Z_SAP_AREA to objects
Attribute will be
available for
structure nodes
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 44 of 59
Assign attribute
Z_COMPONENT to
object Project and
Solution Node
Set the other
options
Result: the
attribute is
available for
business process
structures
Return to topic content
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 45 of 59
7.1.7 Customer Attributes for Documents
To improve reporting of documents in the design or configuration phase of your project, it is
possible to create customer attributes for documents. The advantage of these attributes is
their ALM accomplishment. This means that those attributes will be passed to all document
copies of the original documents. One possibility for such an attribute is the Project ID under
which the document was created/changed. The information on who changed the attribute
and when it was changed will be logged in the history of the document. The customization
described below is done with the example of Project ID as an attribute.
Where to configure/how to do:
What to do Screen Display
Create an
attribute through
transaction SPRO
Create an
attribute “Project
ID”
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 46 of 59
Assignment of a
table and field to
which the
attribute will
relate
Activate the
attribute
Record changes in
a package
Assign the newly
created custom
attribute to PHIO
class
SOLARGENSRC_V
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 47 of 59
New attribute has
to be assigned to
instance
attributes
After saving, the new
customization has
to be activated
Result in
SOLAR01/02 for
document
After creating the attributes, it might be necessary to refresh the buffer on servers
(transaction SE33 for context IWB_CLASS_PROPS).
The same activities can also be performed for the attribute “SAP Component” to detect which
documents belong to which SAP area.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 48 of 59
7.2 Long-Term Project Creation
To use the long-term project in SAP Solution Manager, there are several steps to be
maintained in the system:
o Project Creation in different KW Enhancement
o System landscape maintenance
o Business process structure copy
o Behavior of assignments:
- Document - Transactions - Configuration - Structure Attributes - Document Attributes
What to do Screen Display
long-term Project Creation
Enter the T-Code
SOLAR_PROJEC
T_ADMIN and
then you will go
to the project
administration
screen where you
can start to create
the project.
Maintain Mandatory Fields and Save
You can assign
the solution to the project when the
project deals with the same system
landscape
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 49 of 59
During saving, the
KW Enhancement
has to be
changed from
KWCUST 620 to
any other one
Business Process Assignment
a. Navigate to the
business blueprint
screen
b. Go to the
structure tab,
select the Source: “Solution” and
use F4 Help to copy business
scenarios or
processes from the solution
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 50 of 59
Choose the
option: “Refer to
Documents”
System landscape
will be copied
from the solution into the long-term
project
Business Process Assignments
a. Business
processes will be copied into the
project:
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 51 of 59
b. together with
all assignments
on all tabs
Document Management in a long-term project
a. All Documents
are linked from
the solution into
the project. The
picture shows a
change to a
document in the
maintenance
project assigned
to the solution.
Document
attributes are
changed (project
ID)
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 52 of 59
b. Changes made in maintenance
will also be reflected in the
long-term project
c. As soon as the
document is changed, the
system will create
a copy. Changes made to
this document will not be reflected in
the solution/ maintenance
documentation.
At the end of the
long-term project,
the document
content is merged
with the original
document stored
in the solution
(through
maintenance).
This will be visible
in all other
potential long-
term projects
Return to topic content
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 53 of 59
7.2.1 Compare & Adjust: From Maintenance to Long-Term 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_UPGRADE) for the long-
term project
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 54 of 59
Results will be displayed in the
implementation project.
Adjustment can be
started.
You can adjust all
changes or select
changes you want to
take over (depending
on global attributes).
Afterwards, select
„Copy‟ and „Complete‟.
Return to topic content
7.2.2 Testing in the Long-Term Project
During the project implementation phase, the test phase is prepared. Existing test cases (coming from the solution) can be reused or redesigned. Afterwards, test plans and test packages can be generated according to business processes and the progress of testing and reporting can be tracked.
Test Case Assignment in a Project
In a long-term project, it is possible to assign or redesign test cases, ECATT scripts, or to assign test descriptions to business scenarios, business processes or business process steps.
These test documents can be reused for test plan creation.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 55 of 59
Assign test documents
to a business process
step, on tab Test Case.
Test Workbench
Test Workbench is
embedded in SAP
Solution Manager for
Test Management.
After the assignment of
test documents, a test
plan can be generated
in the Test Workbench
and test packages can
be created for different
Testers.
Return to topic content
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 56 of 59
7.2.3 Learning Map
What to do Screen Display
Create a Learning Map
using transaction
SOLAR_LEARNING_
MAP
Create Chapter and
Units
Search for training
material and assign
these to the units.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 57 of 59
Send to End User
Return to topic content
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
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 58 of 59
Take over changes
Return to topic content
7.2.5 Post Go-Live Maintenance
A solution is created after go-live. From now on, all operations and maintenance are executed on the solution instead of the project.
Maintenance Project
To change the business
process structure in a
solution, it is
recommended to use a
maintenance project
instead of making
changes directly to the
solution
Assign a maintenance
project to a solution, and
then enable the „Check-
out/Check-in‟
functionality.
Business Process Long-Term Redesign
© 2011 SAP AG
Dietmar Hopp 16
D-69190 Walldorf
Title: Long-Term Implementation Version: 2.0
Date: 23.08.2011
Page 59 of 59
Check-In / Check-Out
After the maintenance
project is assigned to
one solution, it is no
longer possible to
change the business
structure, document, or
landscape directly in the
solution.
Any necessary changes
will be checked-out into
the maintenance project
and checked-in after
changes.
The maintenance project
for this solution can be
checked in into the
Solution Directory.
Use the „Check-
in/Check-out‟ button in
the Solution Directory
and maintenance
project, to perform post
go-live maintenance.
Return to topic content