Document Management
In SAP Solution Manager Application Lifecycle
Management
www.sap.com
TABLE OF CONTENTS
1.0 Motivation ................................................................................................................................................... 3
2.0 Method and Prerequisites ......................................................................................................................... 4
2.1 Document storage in SAP Solution Manager .............................................................................................. 4
2.2 Document types ........................................................................................................................................... 5
2.3 Status schema and digital signature ............................................................................................................ 5
2.4 Customer attributes for documents ............................................................................................................. 6
2.5 Automatic generation of a Blueprint, Configuration Guide and Test Report. .............................................. 6
2.6 Documentation process and responsibilities ............................................................................................... 7
3.0 Usages ........................................................................................................................................................ 8
3.1 One project as single source of truth ...................................................................................................... 8
3.1.1 Document management during maintenance .......................................................................................... 8
3.1.2 Document management during major release. ........................................................................................ 9
3.1.3 Summary ................................................................................................................................................ 10
3.2 Solution as single source of truth ......................................................................................................... 11
3.2.1 Document management during maintenance ........................................................................................ 11
3.2.2 Document management during major release. ...................................................................................... 12
3.2.3 Summary ................................................................................................................................................ 13
3.3 Template as single source of truth ........................................................................................................ 14
3.3.1 Document management during maintenance. ....................................................................................... 15
3.3.2 Document management during major release. ...................................................................................... 15
3.3.2.1 Changing documents stored on the General Documentation tab ....................................................... 16
3.3.3 Summary ................................................................................................................................................ 16
4.0 Authorizations in Document Management ........................................................................................... 17
4.1 Restrictions between projects .................................................................................................................... 17
4.2 Restrictions within a project structure ........................................................................................................ 17
4.3 Restrictions within the document management (different KW Folders) .................................................... 17
4.4 Standard authorization roles ...................................................................................................................... 18
4.4.1 Project administration (SOLAR_PROJECT_ADMIN) ............................................................................. 18
4.4.2 Business Blueprint (SOLAR01) .............................................................................................................. 18
4.4.3 Configuration (SOLAR02) ....................................................................................................................... 19
4.4.4 Solution Directory (SOLMAN_DIRECTORY) ......................................................................................... 21
5.0 Glossary ................................................................................................................................................... 22
6.0 Linked Documents................................................................................................................................... 22
Best Practice: Document Management in SAP Solution Manager ALM
1.0 Motivation
The goal of Solution Documentation in SAP Solution Manager is to have central documentation for ITsupported business processes and technical information about SAP and non-SAP solutions for transparency
and efficient collaboration.
Business process documentation – represented in the Application Lifecycle Management (ALM) process
“Solution Documentation” – is embedded as an integral part of the lifecycle management concept. It can be
viewed as the foundation for ALM and, like a foundation or groundwork of a house, its value consists in
building a strong and reliable base for the house built on top of it. For ALM, this means having strong,
reliable and up-to-date business process documentation in SAP Solution Manager will allow you to benefit
from other ALM capabilities built on top of it. These benefits are measurable and, in the end, will help you
save time and money.
The basis of the business process documentation is the business process structure. It gives order to the
assigned business process documentation. The design aspects of the business process structure is not part
of this document, but of the document ALM Architecture Design in SAP Solution Manager.
We can distinguish between two main types of assigned business process documentation:
- By technical documentation. This describes which technical objects such as transactions, background
jobs, programs, user exits, Business Add-Ins (BAdIs) or other extensions are required to perform a
business transaction within the context of a business process or business process steps. This
information is always up-to-date as the objects are physically available in the managed system and
are just referred to in the business process context.
- By documents. These documents describe the requirements, design, and realization of business
scenarios, processes and steps. These are documents stored directly in SAP Solution Manager.
Both types are relevant for Application Lifecycle Management and have to be updated with respect to
changes performed during major or minor releases.
This document describes ways how SAP Solution Manager can support the procedure to keep the business
process documentation up-to-date. It describes the basics of Document Management in SAP Solution
Manager as well as the methods based on three best practice use cases.
3
Best Practice: Document Management in SAP Solution Manager ALM
2.0 Method and Prerequisites
How SAP Solution Manager will be used for Application Lifecycle Management depends on many factors.
How daily changes in the system landscape have to be documented and identifying where changes to the
organizational structures will be performed both have a direct impact on the method and configuration of
SAP Solution Manager.
The following chapters explain how to deal with these situations focusing particularly on documentation
activities. Topics around documentation of variants but also general information about techniques and
possibilities for Document Management are highlighted to establish an information basis for the use case
discussion which begins in Chapter 3.0.
2.1 Document storage in SAP Solution Manager
Technically, SAP Solution Manager uses the Knowledge
Provider (KPro) to store all documents which are created
within or uploaded into the system. The use of KPro also
influences the techniques how documents are stored
(Figure 2.1-1). When creating a document in SAP Solution
Manager, the system creates two objects:
o Logical representation of the document (LOIO): A
unique ID which describes and identifies the
document in SAP Solution Manager
o Physical representation (PHIO) which is created for
the LOIO whenever the document or its attributes
are changed or translated. The list of PHIOs fills
the history tab of the document attribute popup.
Ultimately from an SAP Solution Manager perspective, all
documents are stored and organized by a Business
Process Hierarchy. This hierarchy can be built in projects or
in solutions.
Figure 2.1-1 Relations between logical and
physical objects
All documents in SAP Solution Manager are stored in Knowledge
Warehouse (KW) and organized in so-called KW Folders (Figure
2.1-2). Typically, there is a one-to-one relation between a KW
folder and a project/solution. In general, a document is stored in
one KW Folder but it can be referenced by other KW folders. It is
possible to change the document content in the original folder as
well as from the referenced side.
The situation changes when the documents are created in a
different KW Enhancements. This will be the case once you
decide to create a project in a different KW Enhancement rather
than KWCUST Release 620. In this case, the linked document will
be exclusively changeable from the original folder
Figure 2.1-2 Knowledge Warehouse (project/solution) but not from the linked place. Should you change
integration
the document from the linked place the system will create a
document copy. This behavior is called “late copy”.
In case the documents are stored in different KW Enhancements, we can achieve a real persistent
linkage and thus allow changeability from the original and linked place by the so-called Reference KW
Folder functionality. For more information, please refer to the chapter “3.3 Template as single source of
truth” or to the SAP Note 1236369.
4
Best Practice: Document Management in SAP Solution Manager ALM
2.2 Document types
SAP Solution Manager provides the possibility to standardize documentation by using certain document
types and templates. A document type is determined according to its content; for example, ones with a
technical or a functional specification. Behind every document type, you can upload a customer-specific
document template which gives the document type a custom-specific design. This design appears as soon
as a new document based on a document type is created directly in SAP Solution Manager.
The following table gives a proposal which document types might be required to document the business
processes. It highlights also the place (tabs in SOLAR01/02) where the documentation should be assigned.
Document
Type
Description
Structure
Tab
ZBPD
Business Process Description
Business Process
Gen. Documentation
ZFSP
Functional Specification
Business Process/Step
Gen. Documentation
ZCON
Configuration Description
Business Process/Step
Configuration
ZTSP
Technical Specification
Business Process/Step
Development
ZTD1
Test Case Description
Step
Test Cases
ZUT
User Training
Step
Training Material
ZINT
Interface Description
Interface Step
Gen. Documentation
ZTDS
Test Data Sheet
Business Process/Scenario
Project Documentation
Figure 2.2-1: Customer document types
The document types mentioned above are examples. Different document types can be created to suit
different documentation requirements.
Recommendation:
Define and use customer-specific document types created in a customer name space.
2.3 Status schema and digital signature
The possibility to create status schemas in SAP Solution Manager provides the ability to specifically change
status values in a predefined order. This order can vary from document type to document type. Once the
decision has been made to use new status values and status schemas, it is recommended to assign a status
schema to all document types. This will prevent the users from seeing all status values available in the
system except those which are part of the status schema assigned to the particular document type.
In the status schema you can specify:
- Status values which are part of the status flow
- Specific order in the flow
- Initial status (automatically proposed by the system during document creation)
- End status (locks the document content once the status value is set). This function is particularly
useful when the document is prescribed to follow a specific workflow with approval steps
5
Best Practice: Document Management in SAP Solution Manager ALM
Recommendation:
All status schemas should end with a common released status.
- Digital signature as necessary to set a specific status value within the status schema. By using the
digital signature, only authorized persons are allowed to set the status value in initiating or finishing
the approval of the document.
Recommendation:
When using Digital Signatures the number of described ALM use cases will get restricted to the
“One project as single source of truth”. The reason is that the copy of documents does not keep
the signature and copied documents are unsigned on the end.
2.4 Customer attributes for documents
SAP Solution Manager provides the option to setup and use different customer attributes for documents.
These attributes can identify the owner of the document for a specific organizational unit (org. unit) or area or
it could specify a unique number of bundling documents into a group. This significantly speeds up the
reporting and work list creation.
2.5 Automatic generation of a Blueprint, Configuration Guide and Test Report.
SAP Solution Manager provides the capability to generate based on available process documentation from
the following documents:
Document
Description
Execution Path
Blueprint
Document
Collects content from all blueprint-relevant
documents stored for business process
hierarchies on the Project Documentation
tab (a document can be flagged as blueprintrelevant on his attribute popup). After the
collection you can start a standard Macro
SAP_BUSINESS_BLUEPRINT which builds
the content of the blueprint document. The
file will be stored locally and can be
uploaded into SAP Solution Manager if
needed.
Transaction:
SOLAR01
Configuration
Guide
Similar to the business blueprint you can
also create a collection of all configuration
documents in one big project- related
configuration guide.
The “Generate Configuration Guide” activity
considers all documents stored on the
Configuration Tab. The processing is done
locally by using the Macro
SAP_CONFIGURATION_GUIDE.
Test Report
Collects the test status and all test notices in
the test phase. The report collects the
information from test cases collected in a
test plan and builds the information together
by executing macro
SAP_CREATE_TESTREPORT.
Menu:
Business Blueprint 
Generate Blueprint
Document
Transaction:
SOLAR02
Menu:
Configuration  Generate
Configuration Guide
Transaction:
STWB_2 or
SM_WORKCENTER for
Test Management
Menu:
GoTo  Create Test
Report
6
Best Practice: Document Management in SAP Solution Manager ALM
Recommendation:
Consider possible design changes on the Business Blueprint,- Configuration Guide,- and Test
Report template format. Please follow therefore the technical configuration.
2.6 Documentation process and responsibilities
Before starting the ALM design, the general documentation process has to be designed and established.
These processes are tool-independent and define the responsibilities and tasks in documentation
management. The highest priority of these procedures is to keep the documentation up-to-date throughout
the entire Application Lifecycle.
Translated to tools like SAP Solution Manager, this will also influence the authorization concept for all people
or groups involved in IT processes. From the SAP Solution Manager perspective, we have the following
groups and responsibilities:
- ALM Governance Group: this group defines the ALM standards for the following:
o Basic SAP Solution Manager configuration
o System Landscape maintenance
o Definition of ALM standards (document types, templates, status values etc.)
o Definition of authorization concept
- Business Process Owner/Expert: owns the business process with all its documentation and is
responsible for approving change requirements/changes, actively takes part in Quality Gate checks
and merges documentation.
- Business Process Expert/Developer: responsible for implementing requirements and documents all
changes within Solution Documentation.
The graphic below shows the typical tasks during the documentation management process.
Figure 2.2-2: Customer document procedure and roles
Work lists in SAP Solution Manager can be created based on:
- Change Request Management integration (please refer to chapter 3.1)
- Dedicated user assignments to the document: the document owner attribute has to be changed to the
next processor of the document. Together with suitable status values, (like “for processing”, “for
approval”) the detection of a work list of the appropriate roles can be selected by the evaluation
transaction SOLAR_EVAL.
7
Best Practice: Document Management in SAP Solution Manager ALM
3.0 Usages
The following use cases give an insight into the possibilities how to manage Application Lifecycle
Management in SAP Solution Manager from a business process documentation perspective. All cases are
based on the pre-discussed business process design (please refer to the ALM Architecture design
document).
3.1 One project as single source of truth
One project as single source of truth offers a stable single place to document all business processes -- those
in production, in plan, as well as those in maintenance. The business process and thus also the documents
will reside in this one project in SAP Solution Manager. This fact offers diverse options for document
handling from a storage and authorization perspective.
In general, the documentation will be stored within different tabs of a project following the logic provided in
the Figure 2.2-1. However, how the documentation will be handled and how the content will be designed
differs from other use cases. In general, all documents used for this case are composed of two main parts:
- Persistent area which describes the current production system behavior (existing and live processes /
functionalities). For example: the design specification for a business process step describes the
current transactional design and behavior; the test case provides how to test the functionality running
in the production system.
- Temporary area is a location that is only available within a major release project. Within this area, all
changes made to the document will be noted and temporarily stored for the time duration of the
release project. Before the release project activities end, the temporary area has to be moved to the
persistent area. This is to be performed by the business process expert/owner for all documents in
his/her responsibility. The procedure can be supported by a Change Management procedure from
the beginning of the major release.
Change Management procedure: During the approval procedure of a change request, all relevant
documents from the appropriate business process can be highlighted and linked directly to the
change request by the business process owner. After the approval, the developer takes over the
processing of the change in which all required documents have already been linked. During this
processing, the change remains as the only gate for the developer to enter the managed system,
which then, develops and updates the assigned documentation. After successful testing, the change
can be finally approved by the business process owner. During this approval, all changes on all
relevant documents can be reviewed and the change released. This will initiate the transport
management to finalize the change.
The information provided above is also valid for all
other types of projects which will be centrally
documented in the single source of truth (e.g.
Implementation or upgrade).
The documentation management is supported in this
use case through the following tabs:
- General Documentation (In case the single
source of truth is a template project)
- Project Documentation
- Configuration
- Development
- Test Cases
- Training Materials
Figure 3.1-1: Document change in maintenance.
3.1.1 Document management during maintenance
Changes on the business process documentation during maintenance phase are reflected directly in the
main documentation project. All documents can be changed and stored directly in SAP Solution Manager. To
8
Best Practice: Document Management in SAP Solution Manager ALM
lock a specific document for other changes, it can be checked out to a local desktop for content changes.
See Figure 3.1-1. During this operation, the document is available for all other users in display mode and the
system will identify which user has sole use of the document. After the change has been documented, the
document can be checked into the appropriate business process structure and subsequently the document
stored in SAP Solution Manager will be updated.
3.1.2 Document management during major release.
Major releases as well as roll out projects are
concurrently accessing the same documentation
but updating different project specific chapters of
the document. In these chapters the projectspecific change scope will be documented (Figure
3.1-2).
The changes to the document content in the
specific release or implementation chapter have
to be approved at the end of the
release/implementation phase and moved to the
persistent content of the document.
Figure 3.1-2: Document content changes during major
The usage of only one central storage place for
release or roll out
the business process documentation sometimes
results in concurrent access to documentation.
Such a situation could be a change from a project and maintenance perspective. To avoid a mix-up and
uncoordinated development of document content it is recommended to:
- Use specific document chapters to reflect different activities. Almost all document types (excepting
test cases) should contain a stable content core which describes the current productive process or
transactional design. In addition, there should be different chapters describing the deltas developed
during maintenance and roll out or release projects. After the release or roll out content has been
transported to the productive environment, the appropriate chapter content should be moved as well to
the stable document core. By using this method, the order of changes is always clear and shows the
current flow of the design. The exception of test cases is founded in the fact that the roll out or release
can produce different ways of testing. During that time, the old or original test case remains available.
- Re-use or link the same document in several places as often as possible. As documents remain at
the same place and never leave the project, a permanent linkage of documents between structures
can be created. Whenever the original document is changed, the changes will become visible for all
occurrences across the process hierarchy. An example of such a shared documentation could be a
development or configuration documentation for user exits or BAdIs used for several different business
processes/steps.
- Lock documents by setting the final status value. In this case, the last status value (“release”) will
lock the document content; no changes will be possible to the document content or its attributes. A
change to this document can be requested by the business process owner who unlocks it for this
event. This changes the document status automatically to the initial status value (in case an initial
status value has been setup in the status schema). By setting the new processor name in the field
“Owner”, a working list can be created. Following this procedure, it is guaranteed that the status
schema will be passed through as designed.
- Use keywords for test case documents to make the content of the document visible while filtering
criteria during test plan creation. The information about the release or organization unit can be used to
test specifically in combination with structure attributes as to what is relevant and is in the scope for a
specific test phase.
- Use customer attributes for documents to describe business process characteristics e.g. country
relevance of developments or process flow/descriptions. This will allow you to report more specifically
on the documents collected in the single source of truth.
9
Best Practice: Document Management in SAP Solution Manager ALM
- Use local document check-out functionality to lock the document content and inform about current
processing in this area. In analogy to the ABAP objects, the person who checks out the document
locally to his PC will lock the document content. This will allow making changes in this document also
offline. During this process, concurrent accesses are not allowed and the system will identify who is
locking the document.
- Optionally, use additional KW folders to restrict accessibility to business process documentation. For
further details, please consider the information provided in the chapter “4.0 Authorizations in
Document Management”.
With respect to business process structures it is recommended to:
- Extensively, use structure attributes (e.g. Status on the ”Administration” tab in SOLAR01/02) to
maintain the processing status of the business process (e.g. “under release construction”; “ready for
test”, and so on)
- Optionally use the project team member assignments as an authorization restriction. By assigning
team members to the business process hierarchy you can define a fixed group of people who are
allowed to change documents and other objects on the tabs for a specific hierarchy area. Very
common in this context is the assignment of groups to business process structures reflecting their
main focus (for example SAP Application Component). In this case, only those persons assigned to
the business process/step are allowed to change content stored on it. Information assigned to the
business process hierarchy in which the user is not assigned will be made available to him/her in
display mode only.
By using this best practice use case almost all governance activities are separated from the SAP Solution
Manager tool. There must be a strong Quality Gate control to establish and guarantee consistent quality and
permanent update during roll out/release/maintenance activities. In addition, business process ownership
should be established to take the responsibility to approve and control changes within the business process
documentation.
All changes which are performed and transported through the system landscape can be controlled by
Change Request Management activated in other SAP Solution Manager projects. These projects are just for
transport bundling and are not used to update the business process documentation
3.1.3 Summary
This best practice is addressed to customers starting with central and overall solution documentation. It is
also recommended for customers within a centralized environment focusing on test management or those
needing to integrate with modelling tools.
As everything is documented in just one central project, the ALM architecture, which means the concept of
used projects and solutions, is very easy. You have a real single source of truth with all solution
documentation information, one common place to display and change documentation. As the customer has
new and old test information in one central place, integration and regression test plans can be created and
maintained very quickly.
Information changes happen in the same document. Thus, for a major release the customer initially has to
add the new information, test and at go live, merge it with the older content.
This behaviour causes less transparency to distinguish between productive information and information
under maintenance or in planning. There is no tool support to identify changed documents (Compare &
Adjust compares documents and other content of 2 separate projects/solutions). To get this transparency the
customer has to add status information and attributes to documents. Thereafter, he can filter the project
information in project reporting.
While you have an easy ALM architecture without the need to roll-back/compare and adjust information
between several projects, you should have stronger governance with Quality Gates to control the
maintenance of this single project.
10
Best Practice: Document Management in SAP Solution Manager ALM
3.2 Solution as single source of truth
The documentation management of the “Solution as single source of truth” use case follows the software
change transportation and can be seen as the best integration between the two areas. On one hand, it
allows urgent and normal changes to be handled in a maintenance project. And on the other hand, it gives
the possibility to decouple the existing solution documentation for major release purposes.
Documentation management is supported in this use case through the following tabs:
- Documentation (solution directory) / Project Documentation (in maintenance and roll out/major
release/upgrade projects)
- Configuration
- Development
- Test Cases
- Training Materials
3.2.1 Document management during maintenance
During the maintenance phase only corrections
(urgent changes, bug fixes) or small developments
(normal changes) are realized. These have little
impact on the business process design but rather on
the documentation stored for the business
process/step.
For this purpose, the solution cooperates with an
explicitly assigned maintenance project with activated
“Check Out/In” functionality (Figure 3.2-1). The big
advantage of this functionality is the versioning
management of documents between solution directory
and the maintenance project. So while the document
stays unchanged in the solution directory, a new
version can be created in the maintenance project.
This version is published to the solution directory at
the “Checking In” procedure. Through this process,
the original document is replaced by its new version
Figure 3.2-1: Check out of business process step
and document change
automatically.
While the business process and its content are not changeable in the solution, every change can be
requested, approved and checked out by using Change Management (change request). Without this option,
check out can be made in the maintenance project where the content-like documents or other assignments
can be changed.
Change Management procedure: creating the Change Request directly from the solution directory has the
advantage that the business process/step information is already stored in the change request. The approval
of this change can use the partner finding rules and the notification capabilities available in Change Request
Management (ChaRM). The availability of the business process/step allows not only the navigation to the
managed system to fulfill development or customizing activities but also the navigation to the business
process/step hierarchy where documentation can be also be adjusted. By governance it can be ensured that
no change request is finished without updating the appropriate documentation. The update of the solution
directory is performed by a check in procedure which can also be initiated from the change.
Without Change Management, the business process/step can be checked out using a one or two step
procedure (with or without approval, respectively).
11
Best Practice: Document Management in SAP Solution Manager ALM
Possibilities of “Check Out/In”:
- Specific business process step: allows changes on all assignments attached within the step level. New
assignments can be done on all available tabs
- Specific business process: allows changes to the specific business process level (existing
assignments and adding new objects) as well as to all business process steps that are part of the
business process. New steps can be created and documented or not required steps can be deleted.
- Specific business scenario: allows changes to the checked out scenario (all tabs are available in a
change mode). Additionally, it allows the addition or removal of business processes from a specific
scenario. Business processes and their steps are not changeable.
- Node “Business Scenarios”: only available tabs can be changed. The main use case is the addition of
new scenarios into the solution directory.
3.2.2 Document management during major release.
The concept of documenting major release activities
is based on “late copy” behavior for all documents
stored originally in the solution directory (Figure 3.22). This means that all documents coming with the
business process are to be initially linked between
the solution and the major release project (1). This
fact guarantees automatic updates of the content in
major release whenever the documents get changed
during maintenance. Once the documents are
changed in major release (2) the system will
automatically create a copy of this particular
document (3).
Figure 3.2-2: Updating of documents during major
release
You will experience two different document behaviors, depending on the tab where the document has to be
changed:
- Copy and addition: This behavior is designed for the Test Cases tab exclusively. When the original
test case is touched in the major release project the system will create a copy based on the original
test case and place it below the original
- Replacement of the original document by its copy: This behavior is available for all other tabs in
which document storage is possible.
Such a behavior is achieved by creating the major release project in a different KW Enhancement than the
solution. For more details, please refer to the document “Business Process Redesign in SAP Solution
Manager Application Lifecycle Management” available in Service Marketplace.
The creation of new documents during the major release projects also allows detection of changes during the
cutover phase with the Compare & Adjust functionality. Please refer to the document “
How to Guide for Compare & Adjust in SAP Solution Manager Application Lifecycle Management” available
in the Service Marketplace.
12
Best Practice: Document Management in SAP Solution Manager ALM
3.2.3 Summary
This use case can be proposed to all customers who need a clear separation between productive,
maintained and a planned environment. This leads to a high transparency in the authorization concept and
change process, e.g. in the food producing and pharmaceutical industries.
The solution is having a common area to display productive processes and their documentation. Urgent
changes and minor corrections are done in the assigned maintenance project supported by the check-in/out
or the Change Request Management functionality. Process changes and the assigned documentation are
developed in separate projects. This leads to a very good transparency, a deep integration of document, test
and change management and an easier administration per project/solution. This use case is applicable to
the dual system landscape concept.
The disadvantage is that the changes in the different projects/solutions have to be identified and retrofitted
into the solution. The document change and retrofit process is supported by several tool functions, like “late
copy” or Compare&Adjust. But despite this, the customer would still have a rather complex merge process
after a cutover. The more projects/solutions you have the more complex this procedure gets.
Further, you have only one assigned maintenance project per solution. All products that are part of this
documentation have to follow the same maintenance cycle. Either you are able to harmonize software
changes in your company or you get quite a complex ALM architecture.
This is also true for the integration of modelling tools. In the use case with only one central project you can
clearly distinguish between document management done in the project and business process changes done
in the modelling tool.
With respect to test management, the big disadvantage is that re-generation of test plans from a solution is
not possible. That means that after test cases or the process structure have been updated; a completely new
test plan has to be created for your integration or regression tests. So for customers with strong focus on
time-efficient test management, this use case is not recommended.
13
Best Practice: Document Management in SAP Solution Manager ALM
3.3 Template as single source of truth
The template project as single source of truth follows the main idea of Template Management in SAP
Solution Manager. It combines all the methods and functions available, including the possibility of cutover
delta information from roll out or major release projects by using the Compare&Adjust functionality.
The organization and distribution of business processes in and from the template project (e.g. major release
or roll out projects) can be generally organized by two options:
-
Use of templates: all required business scenarios will be assigned to a predefined template ID. The
templates can strictly focus on the SAP modules (components) (e.g Finance or Logistics) or on the
functionality (e.g. Order to Cash or Procure to Pay). These templates are then made available to the
major release or rollout projects and can be selected from the Scope tab of the new project. This
selection copies all relevant (included in the template) business scenarios, processes, steps with all
assigned objects (documents and technical objects) to the new project in the background.
Procedure: Start transaction SOLAR_PROJECT_ADMIN for a major release/rollout
project; select Scope tab  “Template selection” and select appropriate templates.
After saving, the system copies the template content into your project. All documents
will be linked automatically.
-
Without template use: only in cases in which no template ID has been created for the Single Source
of Truth can you scope the major release or roll out project flexibly. You can scope/copy whole
business scenarios or processes from the Single Source of Truth into your major release or roll out
project.
Procedure: Start transaction SOLAR01 for your major release/rollout project,
navigate to the Structure tab; change the content of the field “Source” from “Business
Process Repository” to “Project”; on the pop-up select the Single Source of Truth
(template project); select the appropriate business scenario or business process
(depending on which level you started the selection). The system will copy the content
and ask how to proceed with documents. Select “Refer to documents”.
The Document Management is supported in this use case through the following tabs:
- General Documentation (template project): provides generic documents describing business
scenarios, processes or steps in their flow, design and functional use. These documents are not
directly changeable in roll out/major release projects. Please consider in this context Chapter 3.2.2
“Document management during major release”.
- Project Documentation: is used in the template project for internal purposes and is not a part of a
roll out or major release project. This tab can be used to manage changes coming from a roll
out/major release project and to merge them into the general documentation. In a major release/roll
out project this tab can be used to maintain country-specific roll out information or changes in
design made during a major release project. Please consider in this context Chapter 3.2.2
“Document management during major release”.
- Configuration: provides documentation about scenarios, processes or steps related to specific IMG
configuration.
- Development: aside from technical objects, it gives the possibility to describe, specify and document
the design of your developments.
- Test Cases: provides a collection of test case descriptions for all relevant test types and all
executable variants.
- Training Materials: provides in a template, already predefined training materials describing the
usage of the transactions and its different variants from the end-user perspective.
You will experience different document behaviors depending on the tab where the document has to be
changed and where it is originally stored:
- Copy and addition. This behavior is designed exclusively for the Test Cases tab. When the original
test case is changed in a major release project then the system creates a copy based on the original
and places it below the original.
14
Best Practice: Document Management in SAP Solution Manager ALM
- Replacement of the original document by its copy (also called “late copy”). This behavior is
available on all other tabs (except the General Documentation tab) where document storage is
possible.
- Reference Folder is a possibility to link
documents provided by templates to the
rollout/major release project. This means that
the original document stored in the template
project (1) is changeable not only in the
template project but also in the roll- out/major
release project (2). This is shown by the Figure
3.3-1. In such case, the users who are allowed
to change the content must be authorized for
the specific KW folder (2). Please refer to
Chapter 4.0 “Authorizations in Document
Management”.
Figure 3.3-1: Document change in maintenance.
3.3.1 Document management during maintenance.
Changes on business process
documentation during maintenance are
reflected directly in the Single Source of
Truth (Figure 3.3-2). All documents can be
changed and stored directly in SAP Solution
Manager. To lock a specific document for
other changes it can be checked out to a
local desktop for content changes. During
this operation, the document is locked for all
other users. The system informs others
which user currently locks the document.
Figure 3.3-2: Document change in maintenance.
After the change has been documented, the
document can be checked into the appropriate
business process structure and automatically, the document stored in SAP Solution Manager is updated.
3.3.2 Document management during major release.
The document management for the major release project is based on the standard document behavior
between template project and rollout project. This means that almost all documents provided by the single
source of truth are initially linked to all consuming projects like roll out or major releases (1). They are signed
for late copy. The exceptions here are all documents stored on the General Documentation tab as well as all
documents stored in a KW reference folder (see Figure 3.3-1).
The system prevents making changes to the original
documentation and forces a copy creation once it is
intended to edit the document in the rollout/major
release project (2). The copy of the document allows
separating the document content for the existing
functionalities and functionalities being
developed/changed by the new project (3). Note
however that the system always recognizes this
copied document as a new “version” of the original.
The new information will be especially relevant when
cutting over the documentation into the single source
of truth. There is a detailed description in the
Compare&Adjust How to Guide (link).
Figure 3.3-3: Document change in roll out/major
release.
15
Best Practice: Document Management in SAP Solution Manager ALM
3.3.2.1 Changing documents stored on the General Documentation tab
The General Documentation tab provides documentation which is not directly changeable in rollout/release
projects. However, in some situations the documents have to be changed, for instance, in case the
business process design or transaction will follow a different design.
In such a case, the appropriate document has to be linked to the Project Documentation tab. As long as
the document is not edited on the Project Documentation tab all changes done to the original document
during maintenance will be visible also in rollout/major release projects. At the first attempt to change the
linked document or its attributes, the system will automatically create a document copy (late copy). As of
now, the new process information (changes to design or behavior of the process step or transaction) will
be included in this new document copy. During that time, the original document is still available in its
original state on the General Documentation tab.
The cutover of the information about the changed process, step or transaction design into the Single
Source of Truth is guaranteed by the Compare&Adjust functionality. This functionality will detect changes
and allow these to be brought into the template project. However, these new documents will be cutover to
the Project Documentation tab of the template project and remain private (to the template project) unless
they are harmonized (from content perspective) with the documents stored on the General Documentation
tab.
Please Note:
If you use the global rollout functionality and global attributes, all blueprint-relevant
documents stored on the General Documentation tab will be copied per default to
the Project Documentation tab of the major release/rollout project. This may lead to
an issue in the cutover phase. As all documents, also unchanged ones, are now
stored on the project documentation tab, they will be rated with a delta. By using
Compare&Adjust all of them will be detected and potentially brought back to the
template project.
This behavior can be suppressed using the BAdI CL_SA_DEFINE_GLOBAL_ATTR.
In the method CHECK_GLOBAL_ATTRIBUTE you can deactivate this behavior by
initializing the parameter copy_blueprint_docs_to_proj_do = ' '.
3.3.3 Summary
This alternative can be treated as an extension of the first use case, with one central project. It is most
suitable for customers having a single or a dual system landscape and a central documentation.
The solution documentation is represented by a combination of a template project, roll out and/or major
release projects and has a close integration to Change Request Management and Test Management. This
use case combines the advantages of the two use cases beforehand. There is a clear separation of general
and project documentation. Via template test plans, it is possible to have an additional integration between
documentation and test management. Test plans can be updated with delta information. The integration with
modeling tools is still rather clear.
The integration with Change Request Management is a compromise between both use cases. You have
good transparency and separation of productive and planned processes, but less strict integration in
maintenance.
The disadvantage of harmonization needs is not as big as in the central solution use case beforehand, but
there is still a complex merging of documents after cutover into the template project (especially for General
Documentation tab).
16
Best Practice: Document Management in SAP Solution Manager ALM
4.0 Authorizations in Document Management
4.1 Restrictions between projects
To restrict access to different projects, the authorization object can be used. Depending on the number of
implementation projects it is possible to:
1) Assign a specific project ID to the authorization object S_PROJECT (PROJECT_ID  Project name)
and assign this authorization to the project team members.
2) Work with a predefined namespace for projects (e.g., projects used by a specific organizational unit
will use a predefined prefix for project IDs). Afterwards, you can provide the prefix in the authorization
object S_PROJECT and use it for several project teams.
Authorization objects S_PROJECTS and S_PROJECT can be found, for example, in the role
SAP_SOLAR_PM. Please copy the role to a customer namespace and set it up based on your requirements.
4.2 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. This will allow changes to structure nodes in
SOLAR01/02 where the users are assigned from the Administration tab. All other nodes will only be
accessible in display mode.
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 appropriate tabs in display mode.
You need to change the authorization for the tab (authorization object AI_SA_TAB) to enable assigned team
members to work on the specific tab.
4.3 Restrictions within the document management (different KW Folders)
You can use different KW folders within one project. One KW folder can be assigned to exactly one folder
group. The authorization for all included documents is checked against this folder group. Please follow the
description below to set these up in your system.
1)
2)
3)
Start transaction SI23, for the area SAP Solution Architect, and go to the menu Settings  Folder
Groups. In this view, you can create a folder group for the new folder.
Afterwards, start transaction SI80 and select the folder in which the folder group will be changed. Go to
the menu Folder  Attributes  Change (the context where you currently are should be equal to the
original context in the attributes of the folder; otherwise, it will not be possible to change the folder
group). Now you should be able to choose the folder group (created in step 1), using F4-help.
Alternatively, you can create a new KW folder and assign the folder group to it.
The folder group can be assigned to the authorization object S_IWB. The parameter IWB_FLDGRP is
usually equal to the project name of the folder created by the system during project creation.
Afterwards, you should be able to move special "top secret" documents to the newly created folder,
using the “Attribute” popup of the document and the button “Replace Folder”.
Alternatively, the assignment is also possible when saving the document using the method
HANDLE_EXIT_BEFORE_SAVE, class CL_SA_IO_DOC, and using KW function modules.
17
Best Practice: Document Management in SAP Solution Manager ALM
4.4 Standard authorization roles
This chapter provides information which authorization roles are available for the main solution documentation
transactions.
4.4.1 Project administration (SOLAR_PROJECT_ADMIN)
In general you can use the predefined composite roles (technical abbreviation: *_COMP) for following user
groups:
1)
2)
3)
4)
5)
Project Manager (technical role name: SAP_SOL_PM_COMP)
Application Consultant (technical role name: SAP_SOL_AC_COMP)
Technical Consultant (technical role name: SAP_SOL_TC_COMP)
Development (technical role name: SAP_SOL_BC_COMP)
Display User (technical role name: SAP_SOL_RO_COMP)
Authorization Roles
Description
SAP_SOL_PROJ_ADMIN_ALL
Full authorization for project management
SAP_SMWORK_BASIC_IMP
Basic authorization for the “Implementation and upgrade”
work center
SAP_SMWORK_IMPL
Authorization for the “Implementation and upgrade” work
center
SAP_SOL_PROJ_ADMIN_DIS
** Display authorization for other users such as Application
consultant
SAP_SMSY_ALL
Full authorizations you need for maintaining the system
landscape in transaction SMSY that includes logical
components.
For more info, please refer to link: http://service.sap.com/instguides  SAP Components  SAP Solution
Manager  <current release>  Operations
4.4.2 Business Blueprint (SOLAR01)
Application consultants are responsible for making sure that the business blueprint and software
configuration are tailored to the business processes and that analysis and report requirements are fulfilled.
Application Consultant (technical role name: SAP_SOL_AC_COMP)
The table underneath gives you a further details regarding some of the single roles which are required, also
included in the Application Consultant composite role
Authorization Roles
Description
SAP_SOL_PROJ_ADMIN_DIS
Full authorization for project management.
SAP_SMWORK_BASIC_IMP
Contains full authorization for work center - related
functions for implementation.
SAP_SMWORK_IMPL
Allows access to the implementation and upgrade work
center
18
Best Practice: Document Management in SAP Solution Manager ALM
SAP_SOLAR01_ALL
Contains full authorization for business blueprint
(transaction SOLAR01). Allows you to build your
business processes and steps.
SAP_SUPPDESK_CREATE
Full authorization to create a service desk message
when the following functions are used:
o Roadmap
o Business Blueprint
o Configuration
SAP_SOL_KW_ALL
Contains full authorization for Document management
within transactions SOLAR01, SOLAR02, and
SOLMAN_DIRECTORY (Knowledge Warehouse
folders)
SAP_SMSY_DIS
Contains display authorizations for the system
landscape in transaction SMSY that includes logical
components.
For more info, please refer to link: http://service.sap.com/instguides  SAP Components  SAP Solution
Manager  <current release>  Operations
4.4.3 Configuration (SOLAR02)
Application consultants are responsible for making sure that the business blueprint and software
configuration are tailored to the business processes and that analysis and report requirements are fulfilled.
Application Consultant (technical role name: SAP_SOL_AC_COMP)
The table underneath gives you a further details regarding some of the single roles which are required, also
included in the Application Consultant composite role
Authorization Roles
Description
SAP_SOL_PROJ_ADMIN_DIS
Contains full authorization for project management.
SAP_SMWORK_BASIC_IMP
Contains full authorization for work center - related
functions for implementation.
SAP_SMWORK_IMPL
Allows access to the implementation and upgrade work
center.
SAP_SOLAR02_ALL
Contains full authorization for business blueprint
(transaction SOLAR01). Allows you to build your
business processes and steps.
SAP_SUPPDESK_CREATE
Full authorization to create a service desk message
when the following functions are used:
o Roadmap
o Business Blueprint
o Configuration
SAP_SOL_KW_ALL
Contains full authorization for Document Management
within transactions SOLAR01, SOLAR02, and
SOLMAN_DIRECTORY (Knowledge Warehouse
folders).
19
Best Practice: Document Management in SAP Solution Manager ALM
SAP_SMSY_DIS
Contains display authorizations for the system
landscape in transaction SMSY, which includes logical
components.
Development consultants work with the project manager and the application consultant on the planning
and organization of the authorization concept. They also perform developmental tasks and customer-specific
developments.
Basis/Development Consultant (technical role name: SAP_SOL_BC_COMP)
The table underneath gives you a further details regarding to some of the single roles which are required,
also included in the Application Consultant composite role
Authorization Roles
Description
SAP_SOL_PROJ_ADMIN_DIS
Contains full authorization for project management.
SAP_SMWORK_BASIC_IMP
SAP_SMWORK_IMPL
Contains full authorization for work center - related
functions for implementation.
Allows access to the implementation and upgrade work
center.
SAP_SOLAR02_EXE
Contains full authorization for business configuration
(transaction SOLAR02). Allows you to add all
necessary configuration information to your business
processes and steps.
SAP_SUPPDESK_CREATE
Full authorization to create a service desk message
when the following functions are used:
o Roadmap
o Business Blueprint
o Configuration
SAP_SOL_KW_ALL
Contains full authorization for Document Management
within transactions SOLAR01, SOLAR02, and
SOLMAN_DIRECTORY (Knowledge Warehouse
folders).
SAP_SMSY_DIS
Contains display authorizations for the system
landscape in transaction SMSY, which includes logical
components.
For more info, please refer to link: http://service.sap.com/instguides  SAP Components  SAP Solution
Manager  <current release>  Operations
20
Best Practice: Document Management in SAP Solution Manager ALM
4.4.4 Solution Directory (SOLMAN_DIRECTORY)
In addition to the provided authorization roles you can also use the BAdI
DSWP_SOLUTION_AUTHORISATION. It contains the new BAdI DSWP_SOLUTION_AUTH_BADI
providing capabilities to precise the authorization concept for solutions.
Authorization Roles
Description
SAP_SOL_PROJ_ADMIN_DIS
Contains full authorization for project management.
SAP_SMWORK_BASIC_IMP
Contains full authorization for work center - related
functions for implementation.
SAP_SMWORK_IMPL
Allows access to the implementation and upgrade work
center.
SAP_SM_SOLUTION_ALL
SAP_SOLMAN_DIRECTORY_ADMIN
SAP_SUPPDESK_CREATE
SAP_SOL_KW_ALL
SAP_SMSY_DIS
Contains full authorization for solutions. You use
solutions in transaction SOLMAN_DIRECTORY, for
instance using check out/check in function (solution to
maintenance project and maintenance project to
solution)
o Evaluate
o Build
o Going Live Preparation
o Reports
Contains full authorization for the Solution Directory
(transaction SOLMAN_DIRECTORY) and the
maintenance of solutions on the solution settings tab.
Full authorization to create a service desk message
when the following functions are used:
o Roadmap
o Business Blueprint
o Configuration
Contains full authorization for Document Management
within transactions SOLAR01, SOLAR02, and
SOLMAN_DIRECTORY (Knowledge Warehouse
folders).
Contains display authorizations for the system
landscape in transaction SMSY which includes logical
components.
For more info, please refer to link: http://service.sap.com/instguides  SAP Components  SAP Solution
Manager  <current release>  Operations
21
Best Practice: Document Management in SAP Solution Manager ALM
5.0 Glossary
KW Folder
From a technical perspective every project or solution in SAP Solution Manager will automatically create
exactly one KW folder in which all its original documents will be stored (with exception of template
project type). The technical name of this KW folder is always equal to the technical project name or
solution ID. Between several folders you can share the same documents (link) or copy them. In case of
linked documents the document can be changed from all linked places.
KW Enhancement
Basically every project/solution in SAP Solution Manager will be created in so-called KW Enhancements.
The Enhancements is an attribute which will be assigned to every document created for the project.
Such a document can be linked to another project (created in another KW Enhancement) and will share
information between each other but it is not allowed to change linked documents from both sides.
Changes on documents are just allowed from the side where the document is originally stored in.
Late Copy
One document is shared between two places (linked). While the original place (project) can change the
document context, changes from the other side are not allowed. The system forces document copy. The
late copy mechanism uses the method of different KW enhancements.
Another reason for the late copy is when the original document is stored in a template project. Also in
this case we will have the late copy behavior while trying to change the document in roll out project.
Reference folder
Reference folder is a method to suppress the late copy mechanism. This can be achieved by performing
specific configuration as described in SAP Note 1236369.
6.0 Linked Documents
ALM Architecture Design in SAP Solution Manager
Compare & Adjust in SAP Solution Manager ALM
Business Process Redesign in SAP Solution Manager ALM
22
www.sap.com
© 2014 SAP AG. All rights reserved.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP
BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP
products and services mentioned herein as well as their respective
logos are trademarks or registered trademarks of SAP AG in Germany
and other countries.
Business Objects and the Business Objects logo, BusinessObjects,
Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and
other Business Objects products and services mentioned herein as
well as their respective logos are trademarks or registered trademarks
of Business Objects Software Ltd. Business Objects is an SAP
company.
Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL
Anywhere, and other Sybase products and services mentioned herein
as well as their respective logos are trademarks or registered
trademarks of Sybase Inc. Sybase is an SAP company.
Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services are
registered trademarks of Crossgate AG in Germany and other
countries. Crossgate is an SAP company.
All other product and service names mentioned are the trademarks of
their respective companies. Data contained in this document serves
informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials
are provided by SAP AG and its affiliated companies ("SAP Group")
for informational purposes only, without representation or warranty of
any kind, and SAP Group shall not be liable for errors or omissions
with respect to the materials. The only warranties for SAP Group
products and services are those that are set forth in the express
warranty statements accompanying such products and services, if
any. Nothing herein should be construed as constituting an additional
warranty.