Solution Document Good

SAP® Standard Solution Documentation
Version: 2.0
January 2011
Solution Documentation
Active Global Support

SAP AG
© 2011 SAP AG SAP Standard Solution Documentation Page 1 of 67

Version: 2.0
Table of Content
1 Management Summary ........................................................................ 4

2 Application Lifecycle Management..................................................... 7
3 Solution Documentation Introduction .............................................. 10
3.1 Solution documentation definition.................................................................. 10
3.1.1 Technical landscape documentation – basic content and roles ..................... 11
3.1.2 Business process documentation – basic content and roles.......................... 11
3.1.3 What are core and mission critical business processes? ............................... 12
3.1.4 Business process structure 3-level hierarchy ................................................ 13
3.2 Solution documentation lifecycle ................................................................... 14
3.2.1 Main use cases – initial and re-documentation .............................................. 15
3.2.2 Solution documentation benefits ................................................................... 15
4 How to implement Solution Documentation Standard.................... 17
4.1 Technical landscape documentation ............................................................. 17
4.1.1 How to implement technical landscape documentation ................................. 17
4.1.2 Integration of non-SAP components in solution documentation ..................... 18
4.2 Business process documentation .................................................................. 18
4.2.1 How to implement business process documentation ..................................... 18
4.2.2 SMA Service ................................................................................................. 23
4.3 Enrich the process structure with technical information ................................. 24
4.3.1 Documentation of transactions and custom code .......................................... 24
4.3.2 Documentation of background jobs ............................................................... 25
4.3.3 Documentation of interfaces.......................................................................... 26
4.4 Reporting ...................................................................................................... 27
4.5 How to keep business process documentation current .................................. 28
4.5.1 SAP Solution Manager solutions ................................................................... 28
4.5.2 Solution tailoring ........................................................................................... 31
4.5.3 Controlled maintenance via check-in/check-out ............................................ 33
4.6 Verify the process structure and related objects with
solution documentation assistant .................................................................. 37
4.6.1 Solution documentation assistant benefits .................................................... 37
4.6.2 Solution documentation assistant use cases discover and verify................... 38
4.6.3 Use case verification of business process variants – rule database .............. 42
4.6.4 Use case housekeeping ................................................................................ 43
4.6.5 Use case governance ................................................................................... 45

Version: 2.0
4.6.6 Use case test management........................................................................... 46

4.6.7 Solution documentation assistant data sources and
recommended data flow ................................................................................ 48
5 Functions beyond the core solution documentation ...................... 51
5.1 Further enrich the process structure with information .................................... 51
5.1.1 Project documents ........................................................................................ 51
5.1.2 Configuration documentation ........................................................................ 52
5.1.3 Documentation of test cases ......................................................................... 53
5.1.4 Training material and learning maps ............................................................. 54
5.2 Which expert functionalities does the
business process documentation offer? ........................................................ 54
5.2.1 Template management ................................................................................. 55
5.2.2 Short cuts...................................................................................................... 56
5.2.3 Customer Attributes ...................................................................................... 57
5.2.4 Key words ..................................................................................................... 58
5.2.5 Graphics ....................................................................................................... 58
6 Appendix ............................................................................................. 60
6.1 Process components of projects and solutions.............................................. 60
6.2 Solution ......................................................................................................... 61
6.3 System components of a solution.................................................................. 61
6.4 Technical environment needed for data collection – EWA / ST-PI ................. 62
6.5 Solution documentation assistant .................................................................. 63
6.5.1 Solution documentation assistant - definition................................................. 63
6.5.2 Solution documentation assistant - technical prerequisites............................ 63
6.6 Project to solution – important transactions and work centres ....................... 64
6.7 Project preparation ........................................................................................ 65
6.8 Important links to more detailed information .................................................. 66

Version: 2.0
1 Management Summary
As solution landscapes are maintained and adapted to meet business demands, planning
and reporting of the respective initiatives and projects become a fundamental instrument for
successful solution operations. Efficient planning, reporting and operations require a clear
and reliable documentation of the existing customer solution. This is the focus of the solution
documentation standard. Its goal is to centrally document and relate business processes
and technical information of SAP and non-SAP solutions, ensuring transparency, cost-
efficient maintenance, and internal collaboration as well with SAP.
This standard is intended as a starting point in the work with projects and solutions showing
typical use cases along the application lifecycle. It lays a specific focus on the re-
documentation use case. Though the technical landscape documentation is part of the
solution documentation as well, it is treated as given and therefore explained less detailed.
The standard solution documentation for custom development gives step by step
guidance how to do solution documentation for custom developments. There are several
more use cases covered than those shown in this standard. For instance, the details of
template management and project implementation are extensive processes themselves, and
therefore covered by separate documents.
Consisting of technical landscape and business process documentation, solution

documentation is the basis for all other SAP Solution Manager capabilities (see figure 1.1).
This deep integration and reuse of business and IT information along the application life-
cycle is the biggest advantage and the unique selling point of SAP Solution Manager.
Solution documentation describes a customer‟s technical components (SAP and non-SAP),
his core business processes, and interfaces. It includes custom code/modification
documentation, and links to supporting technical objects, like transactions and programs.
Figure 1.1: The system information and business process information maintained
through solution documentation lies the foundation for all application lifecycle
management processes shown in this figure.
The correct usage of implementation projects automatically leads to sufficient solution

documentation in the operations and optimization phase. If you start with the documentation
in the operations phase, you should re-document your core business processes in SAP

Version: 2.0
Solution Manager (see figure 1.2). As a result, in relation to a complete implementation

project only a subset of information is needed.
Solution documentation can be continuously enriched along the ALM lifecycle phases:
 Design: Create global business process templates and specifications, e.g. for later
roll-out of regional implementation projects
 Design/Build: Newly create or locally adjust business process structures during your
regional implementation project
 Build/Test: Extend business process documentation during solution configuration,
e.g. with custom code documentation, configuration information, test cases
 Operate: Re-document or adjust your business process documentation during
operations, e.g. with system information; adjust process documentation after go-live
 Optimize: Verify your business process documentation before upgrades, e.g. delete
obsolete information, such as not used custom code
Figure 1.2: Solution documentation focus areas
Solution documentation functions as basis for the whole application management lifecycle. It
ensures that customers achieve transparency of their IT solution landscape and business
processes. Moreover, it fully exploits the potential of SAP Enterprise Support. Figure 1.3.lists
customers‟ typical solution documentation pain points and the SAP Solution Manager
offerings solving those.

Version: 2.0
Figure 1.3: Solution documentation - typical pain points and SAP Solution Manager benefits
The solution documentation standard provides you with best practice for set-up and usage of
your own (re-) documentation. Readers will learn which documentation of customer solutions
is urgently required and how this information can be gathered. The best documentation
becomes worthless if it is not regularly updated. SAP Solution Manager provides the
capabilities allowing a cost efficient and controlled update of your solution documentation.
The main solution documentation capabilities are:

 System Landscape Maintenance/Directory (SMSY/SLD)
 Business Blueprint
 Solution Configuration
 Solution Documentation Assistant
Chapter 2 of this document provides a general overview of application lifecycle management

and SAP‟s standards for end-to-end (E2E) solution operations. Chapter 3 gives an
introduction into the topic solution documentation and clarifies the basic definitions. Chapter 4
explains how to implement the standard. The technical landscape documentation is part of
the solution documentation, but already well documented in the SAP Solution Manager
master and operations guide. This is why the detailed technical landscape documentation is
not in focus of this standard. Chapter 5 shows helpful functions beyond the core solution
documentation. Chapter 6, the appendix of this document, offers additional definitions,
technical prerequisites and additional information to project preparation and implementation.
After reading this standard, you will know how to fulfill the basic needs for an efficient lifecycle
management and enterprise support, as well as the next steps to further benefit from SAP
Solution Manager capabilities.

Version: 2.0
2 Application Lifecycle Management

Companies expect from their IT departments that mission-critical business applications run
smoothly, without business disruptions, at low cost, and easily adaptable to new
requirements- which is exactly the purpose of application lifecycle management (ALM). SAP‟s
ALM portfolio consists of processes, tools, services, and best practices to manage SAP and
non-SAP solutions throughout the entire application lifecycle. For details about the complete
portfolio, please refer to http://service.sap.com/alm.
According to the IT infrastructure library (ITIL), the application management lifecycle
comprises six phases:
 Functional and non-functional requirements are collected and evaluated during the
requirements phase.
 In the design phase, the findings from the requirements phase are used to specify
how the application or IT operation processes are to function, and which IT
applications should be used to map the processes.
 In the build and test phase, a system landscape is set up and configured to
implement and test the planned scenarios and processes.
 The deploy phase is the transition from a pre-production environment to production
operation.
 The operate phase groups tasks that are performed after system startup, to ensure
the availability and stability of the solution. These tasks include activities, such as
system administration, system monitoring, business process monitoring, message
processing (Service Desk), root cause analysis, issue management and service
delivery.
 The optimize phase collects key figures and data from the live solution, to reduce
costs or improve performance.
ALM processes span the six phases to ensure stable operation of the IT solution while
enabling accelerated innovation. Optimizing these processes reduces costs, and ensures the
highest quality of IT operation.
Typically, multiple teams are involved in the ALM processes (see Figure 2.1). They belong to
the key organizational areas Business Unit and IT. The names of the organizations differ from
company to company, but their functions are equivalent. For example, a program
management office communicates business requirements to the IT organization, decides on
the financing of development and operations, and ensures that the requirements are
implemented. On the technical side, the application management team is in direct contact
with the business units. It is responsible for implementing the business requirements and
providing support to end users. Business process operation covers the monitoring and
support of the business applications, their integration, and the automation of jobs. And SAP
technical operation is responsible for the general administration of systems and system
diagnostics. Further specialization is possible within these organizations. For example, there
may be separate experts for different applications within SAP technical operations in larger
organizations.

Version: 2.0
Figure 2.1: Organizational model for application lifecycle management

Two things are the key to optimizing the collaboration of the groups involved: a common
infrastructure, and a clear definition of the collaboration processes, including the activities
involved, responsibilities, and service levels. The infrastructure is provided by SAP Solution
Manager as a collaboration platform. It provides role-based access to all functions required
(provided either by SAP Solution Manager itself or by integrated tools), via work centers. It
also provides all related information, centrally, so that all stakeholders involved have easy
access to the information they require. Many customers have defined collaboration
processes. SAP has leveraged the experience of these customers and of its own application
lifecycle management experts to create best-practice descriptions of important ALM
processes. These documents are published as E2E Solution Operations standards in SAP
Service Marketplace at http://service.sap.com/supportstandards. Customers can refer to
these standards when optimizing their own IT processes.
With Run SAP, SAP provides a methodology for the implementation of the End-to-End
Solution Operations standards. The road map for Run SAP guides through defining the scope
of the operations to be implemented, preparing a detailed plan, doing the setup, and running
SAP solutions. Moreover, it helps to find the right strategy and tools to implement ALM. The
road map provides not only what needs to be implemented, but also contains information
about how it needs to be implemented, in the form of implementation methodology
documents and best-practices documents.
Currently, SAP provides the following standards:
● Solution Documentation and Solution Documentation for Custom Development
define the documentation and reporting required for the customer solution
● Incident Management describes the incident resolution process
● Remote Supportability contains five basic requirements that have to be met to
optimize the supportability of customer solutions
● Root Cause Analysis defines how to perform root cause analysis, end-to-end, across
support levels and technologies
● Exception Handling and Business Process and Interface Monitoring explains how to
define a model and procedures to manage exceptions and error situations during

Version: 2.0
daily business operations, and how to monitor and supervise mission-critical

business processes
● Job Scheduling Management explains how to manage the planning, scheduling and
monitoring of background jobs
● Data Integrity and Transactional Consistency avoids data inconsistencies and
safeguards data synchronization across applications, in distributed system
landscapes
● Data Volume Management defines how to manage data growth
● Change Management enables efficient and punctual implementation of changes with
minimal risks
● Test Management describes the test management methodology and approach for
functional, scenario, integration and technical system tests of SAP-centric solutions.
● System Monitoring covers monitoring and reporting of the technical status of IT
solutions
● System Administration describes how to administer SAP technology to run a
customer solution efficiently
● Custom Code Management describes the basic concepts of custom code operation
and optimization
● Security describes basic activities to setup, maintain and evolve security measures
for the operation and organization of SAP solutions.
● Upgrade guides customers and technology partners through upgrade projects
Out of this list, this white paper describes the solution documentation standard.

Version: 2.0
3 Solution Documentation Introduction

At the beginning of the project, the goals and the project scope need to be clearly defined.
The scope definition will comprise a list of business processes and a list of systems affected
by the project. This step should also include the Solution Documentation Standard for
Custom Developments as integral part of Solution Documentation.
The solution documentation standard is owned by application management. As with most

of the other standards, several roles participate in this fundamental standard. End-users,
business process champions, development architects, project team members and the
program management office contribute to and rely on landscape and business process
information. The solution documentation standard provides all involved parties with a
common understanding. Therefore, this standard is a prerequisite for optimizing all solution
operations processes. In addition, solution documentation is a key enabler for business and
IT alignment, not to mention that the provided transparency can accelerate IT activities and
improve their results. SAP Solution Manager enables the documentation of SAP solutions.
Beside the benefits of central and reliable solution documentation, there are several reasons
to change your software, causing the need for solution documentation. Key drivers for
software changes with the need of solution documentation are:
 Internal business needs, e.g. functional enhancements required to increase user

productivity
 Market driven needs, e.g. the need to comply with financial and environmental
legislation
 Need for increased competitiveness, e.g. fulfilling sustainability criteria to increase
the corporate image
 Regular maintenance, e.g., implementation of support packages to correct software
errors
 End of maintenance of a software release e.g. implementation of a new solution, or
innovation via new enhancements
3.1 Solution documentation definition

The goal of solution documentation is to centrally document business processes and
technical information about SAP and non-SAP solutions to ensure transparency, efficiency
and collaboration. The proper documentation of your business processes, and the technical
information on systems upon which these processes ideally already run as part of a template
or implementation project maintained in SAP Solution Manager. The documented business
processes are prerequisites for later business process driven blueprint, configuration, testing,
verification and re-documentation of these pieces of information, e.g. using the solution
documentation assistant.
Solution Documentation means having documented the following key elements:

 core business processes
 related technical objects, such as transactions, programs, custom code, background
jobs, interfaces
 related (non-SAP) system and software components

Version: 2.0
The recommended documentation (project) language is English. To fulfill the SAP Enterprise
Support requirements it‟s sufficient to have an English speaking CCoE full time available. If
needed, this CCoE contact can translate the information available in SAP Solution Manager.
Regularly, though, the internal and external communication is more efficient if you choose
English as default project language. To see the scope of services provided under the SAP
Enterprise Support schedules refer to www.service.sap.com/enterprisesupport >> Scope
Description for Direct SAP Customers.
Solution documentation contains 2 types of documentation: the technical landscape

documentation and the business process documentation. Dependent on the documentation
content, the maintenance is done by different experts.
3.1.1 Technical landscape documentation – basic content and roles
Technical landscape documentation is mainly done during the basic configuration of SAP
Solution Manager, and contains the documentation of system, server, database and software
component documentation. It is done by:
 Application management team, e.g. business process operations experts

 SAP IT experts
 Technical SAP Solution Manager experts
The data is displayed and maintained in the work centers SAP Solution Manager
administration and the system landscape management.
3.1.2 Business process documentation – basic content and roles
Business process documentation relates this technical information with business related
information. It consists of the documentation of (core) business processes, project
documentation, test cases, interface and custom code information. The maintenance is done
by:
 Solution architects, e.g. for custom development and interface specifications,

 Business process champions and experts, e.g. to document (core) process flow
 Key users and project members, e.g. to document test cases and project specific
customizing
 Functional SAP Solution Manager experts, e.g. for simple transfer of the business
process structure and related objects - if good process documentation is available
The data is displayed and maintained in the Work Centers Implementation/Upgrade and
Solution Documentation Assistant. More details about roles can be found in the attachment of
this document.
You start your solution documentation with initial technical landscape documentation. Based
on this, you document and configure your business processes. With and after hand-over to
operations, the technical landscape and business process documentation have to be
regularly verified (see figure 3.1).

Version: 2.0
Figure 3.1: Solution documentation process flow
3.1.3 What are core and mission critical business processes?

The number of core business processes is typically very limited and can be tailored by
company branch. Core business processes are the most important processes, leading to a
severe impact on the company‟s business if they are disrupted. The documentation of core
business processes (see figure 3.2) should contain all:
 core business processes
 related technical objects, such as transactions, programs, custom code, background
jobs, interfaces
 related (non-SAP) system and software components
Figure 3.2: Key elements of solution documentation

Mission critical business processes are new or technically challenging business processes,
e.g. with custom developments or non-SAP components needing high awareness or
monitoring
Documentation in SAP Solution Manager does not intend to model every process step variant
and detail, but to have an understandable structure with information relevant for reuse of
other teams and other application lifecycle capabilities
Let‟s take a look at an example of the manufacturing industry: Material supply of the
production

Version: 2.0
 If this process is disrupted and material outages arise, the production of finished
parts will be impossible. So, the company has to change production plans, causing
higher total production cost
 In addition, customer orders will not be delivered in time, so that customer
satisfaction decreases
 Therefore, the material supply process needs to be considered a critical core
process, as in case of material outages the company loses a lot of money
3.1.4 Business process structure 3-level hierarchy
Business process information in SAP Solution Manager is maintained in a clearly structured

3-level business process hierarchy. If you have process information available already, you
have to adjust this process structures to this three-level model before the (automated)
transfer to SAP Solution Manager.
 Business Scenario: A business scenario is a set of business processes that define a

business task in a comprehensive way
o A Business Scenario is normally related to a company’s business unit, a
central function, or a profit center and it can also involve business partners
from other companies
o A Business Scenario requires one or more SAP components and possibly
non-SAP software
o A Business Scenario may consist of a number of variants, each of them
describing an end-to-end business flow
o Each end-to-end business flow is represented by an ordered sequence of
business processes
 Business Process: A business process is a set of logically related tasks performed to

achieve a defined business outcome
o A Business process is composed of several business process steps
o A Business process can run across several SAP components and possibly
non-SAP software
o A Business process may occur in one or more Business Scenarios
 Business Process Step: An elementary activity performed to accomplish a process

o Is carried out by the user or by the system
o Runs in only one software component
o Is relevant to implementation and/or operation

Version: 2.0
Remarks
A business process step should be represented by one transaction.
Figure 3.2: Business process structure - example for 3-level process hierarchy
If the maintenance of several transactions is necessary specify the standard transaction with
the radio button „Standard‟ (see Figure 3.3).
Figure 3.3: Choose standard transaction in case of more than one transaction per
process step
3.2 Solution documentation lifecycle

Solution documentation offers several starting points. Prominent starting points are
implementation or upgrade projects where customers (re-) define their business processes,
test management, where the business process structure is used to structure test cases, or
business process monitoring, allowing the combination of technical monitoring in business
process context.
Ideally you start defining templates or with an SAP solution implementation. Then you have
the business process structure as a clear backbone for all types of documentation later
needed in the application lifecycle, and capabilities for the activities needed to keep the
documentation up-to date (see figure 3.4).

Version: 2.0
Figure 3.4: Solution documentation lifecycle

Other processes and capabilities in SAP Solution Manager mainly use technical landscape
documentation, e.g. change request management, system monitoring or root cause analysis.
Integrating and reusing the technical and business process information with all SAP Solution
Manager capabilities, solution documentation is the foundation for efficient application
management.
3.2.1 Main use cases – initial and re-documentation

Dependent of your current situation your focus lies on an initial (e.g. during an
implementation project) or a re-documentation of your business processes and the related
solution landscape (e.g. before an upgrade) (see figure 1.2).
The correct usage of implementation projects automatically leads to sufficient solution

documentation in the operations and optimization phase. If you start with the documentation
in the operations phase, you should re-document your core business processes in SAP
Solution Manager as well. In relation to a complete implementation project, only a subset of
information is needed then.
3.2.2 Solution documentation benefits

Solution documentation is the basis for all other SAP Solution Manager processes, for
instance:
 Solution configuration (quicker ROI through centralized configuration)
 Test management (structured, risk based testing and test planning)
 Business process operations (minimized risk by monitoring business processes and
interfaces)
 Upgrade (reduced upgrade costs by reviewing business processes before upgrades)

Version: 2.0
In brief, the technical landscape documentation provides:

 Central, reliable and up-to-date system landscape information for SAP and third-party
tools
 Documentation of hosts, databases, systems, products, software components,
system groups and logical components
In brief, the business process documentation provides:

 Central and clearly structured documentation of business processes, related systems
and technical information
 Methods and tools like solution documentation assistant to keep this documentation
efficiently up-to date
 Business, landscape and technical view enables internal business and IT alignment
 Central access to documentation makes internal projects and collaboration with SAP
efficient
Solution documentation functions as basis for the whole application management lifecycle. It
ensures that customers achieve transparency of their IT solution landscape and business
processes. Moreover, it fully exploits the potential of SAP Enterprise Support.
More detailed information on SAP solution documentation can be found under
https://service.sap.com/alm.

Version: 2.0
4 How to implement Solution Documentation

Standard
The solution documentation standard does not require an implementation of itself. It rather
needs to be established during implementation, operation, and change of the IT solution.
Documentation of such activities and the results achieved is absolutely necessary. The
activities required to implement the solution documentation standard are to agree upon and
adhere to a set of policies and practices of documentation.
4.1 Technical landscape documentation

Technical configuration of SAP Solution Manager is part of the technical landscape
documentation. It
 is required for initial set-up, basic configuration and regular updates
 offers a single wizard that is easy to use
 provides highly automated and centralized configuration
 has integrated configuration documentation
4.1.1 How to implement technical landscape documentation

SAP Solution Manager offers an automatic basic configuration roadmap which you can use
after installation or after importing support packages comprising all technical configuration
process steps in transaction SOLMAN_SETUP (see figure 4.1).
Figure 4.1: Navigation in the guided procedure for the SAP Solution Manager basic
configuration, transaction SOLMAN_SETUP
To use the basic scenarios of SAP Solution Manager, the following configuration scenarios
must be performed successfully:
 In the system preparation, you make settings which are a prerequisite for the
configuration of SAP Solution Manager.
 In the basic configuration, you perform the necessary configuration which is needed
to use basic scenarios in SAP Solution Manager, for example, connecting to SAP,
performing a root cause analysis, using the SAP EarlyWatch Alert, or downloading
patches and upgrades.

Version: 2.0
 In the Managed System Configuration, you connect managed systems to SAP

Solution Manager. You have to perform this scenario for each managed system
separately.
The details regarding technical landscape documentation are described in the SAP Solution
Manager Master and Operations Guides.
4.1.2 Integration of non-SAP components in solution documentation

Non-SAP components can be integrated in the solution documentation as well. The technical
landscape documentation offers the automated collection and display of third party system
information via the co called system landscape directory (SLD). As for SAP applications this
technical landscape documentation is re-used in many capabilities, e.g. for root cause
analysis, business process documentation, testing, system monitoring or business process
operations.
The documentation of core business processes includes non-SAP supported business
processes as well. Like SAP processes non-SAP process steps can be linked with the above
mentioned documents, custom code documentation, configuration information, test cases etc,
and displayed in the business blueprint graphics.
4.2 Business process documentation

If a project aims at implementation or change (continuous improvement) of an IT solution or
parts of an IT solution, it should adopt the solution documentation standard as the project
standard for documentation. For IT solutions that are in productive operation, a project aiming
at operations optimization should be initiated in terms of establishing the standard.
As the focus of the various project types is different, the priorities while establishing the
elements of the solution documentation standard are different. An implementation project
typically starts with the focus on business processes. The project will cover the system
landscape and the aspects of operations later. The focus of an operations optimization
project is on the system landscape and the operations processes first, including issue
management and service planning. Core business processes will be integrated in the
documentation later. In all cases, the project teams will build complete solution
documentation while working to reach the project goals. Therefore, the project team
members need to understand the terminology defined in this standard (solution, business
process, installation, system, etc.).
4.2.1 How to implement business process documentation
There are a few typical use cases when you start with your solution documentation. The
decision tree of figure 4.2 helps you identifying the best procedure in your current situation.
The Decision tree of figure 4.3 helps you identifying the best procedure in your current
situation.

Version: 2.0
Figure 4.2: Decision Tree: How to come to a central and reliable business process structure
with related documents in SAP Solution Manager
Discover - no documentation available at all
If you have no business process documentation available you can use SAPs implementation
content/business process repository (BPR) as starting point. This helps you to get familiar
with the process hierarchy, the assigned system information (logical components), SAP
documentation, the technical objects (transactions and programs) and test cases. As there
are 2500 predefined business processes, it makes sense to start with your well known core
business processes.
After downloading the predefined SAP implementation content, you need to:
 check/adjust the list of business process steps
 check/adjust the association to your logical systems
 check/adjust the association to the supporting technical objects, like transactions and
programs
 for each additional logical business step realized via own custom software add an
additional business process step with a meaningful name reflecting the business
activity executed within this step
 document the interfaces
In case that you are in operations mode already, it is more efficient to use the solution
documentation assistant to verify this draft with the usage data of your productive system.
Based on usage data of technical objects, the solution documentation assistant allows the
analysis if, and how often, business processes and business process steps are used, and
which related technical objects need to be documented. This is valid for SAP and non-SAP
transactions and programs as well. The solution documentation assistant use cases and its
detailed functional range will be described later in this document. For all use cases is valid
that the analysis data should be discussed with a business process expert and then adjusted
in the business blueprint. If new processes, process steps are assigned, upload or link the
appropriate documentation on the project documentation tab.

Version: 2.0
If you are well aware of your business processes and the linked technical objects, and have
your own company specific nomenclature differing from SAPs wording in the implementation
content, you can maintain the processes manually and directly in the blueprint structure (see
figure 4.3). In case of few and well known processes and process steps, this is the fastest
method to document the initial process structure.
Figure 4.3: Manual re-documentation or maintenance of business processes
Valid for all use cases is that, once maintained, business processes can be automatically
verified with the help of the solution documentation assistant (see chapter 4.6).
Reuse - current documentation available
Having a current documentation available, you can manually transfer business process
structure and related objects in the business blueprint. Many customers have their business
process structure and related objects maintained in XLS or Lotus Notes, and are able to
transfer this information very quickly.
Sometimes it is necessary to adjust the level of process structures before the transfer to SAP
Solution Manager. In this case it is often helpful to reduce the number of process levels with
the help of prefixes (see figure 4.4). If additional documentation relevant for the
understanding of the business process (step) is available, upload or link the appropriate
documentation on the project documentation tab.

Version: 2.0
Figure 4.4: Working with prefixes allows reducing the number of business process structure
levels
Transfer - current and compatible tool based documentation available
Having documented many processes and related information in XLS or Lotus Notes, this
information can be initially imported via XML upload, by a specific SAP Solution Manager
interface. As this procedure requires expertise, you have to know XML technology and the
SAP Solution Manager structure very well. Currently, this is only a consultant solution.
There are tools, like the ARIS Business Architect for SAP, where business processes and
related information can be regularly exchanged with SAP Solution Manager. So using a bi-
directional synchronization mechanism, business process documentation available in ARIS
Business Architect for SAP can be transferred to SAP Solution Manager.
The main benefit of the ARIS and SAP Solution Manager integration is the reuse of business
process information, documented and in SAP Solution Manager re-documentation,
implementation, or upgrade projects.
Working with ARIS in connection with SAP Solution Manager, it should be ensured that SAP
Solution Manager is the leading system. The business process information should be reused
in the application lifecycle and therefore it should be structured in the best reusable way. To
ensure this, the following best practice is recommended (see figure 4.5):

Version: 2.0
Create a project & system landscape in SAP Solution Manager

1. Select content from Business Process Repository or manually maintain process
structure in the newly created project. Assign transactions to the process structure.
2. Transfer the project to ARIS Business Architect for SAP NW
3. Extend the basic business process via detailed modeling in ARIS Business Architect.
ARIS scripts allow the re transfer of the detailed ARIS modeling information to the
basic 3-level IT view to be exchanged with SAP Solution Manager.
4. Synchronize the adjusted process structure inclusive transactions, documents and
SAP system landscape information back with SAP Solution Manager
Figure 4.5: Exchange business process information with the modeling tool ARIS Business
Architect for SAP
Note: The integration is part of the SAP Enterprise Modeling Applications by IDS offering at
no additional costs. It is delivered as an ABAP import within the SAP Enterprise Modeling
Applications by IDS offering.
Verify – documentation available in SAP Solution Manager
You most likely get good solution documentation if you already have an SAP Solution
Manager project or solution containing your core business process(es). In this case you can
copy this information to the SAP Solution Manager solution. Verified and proved with the help
of solution documentation assistant (see chapter 4.6), you have all information needed for an
efficient lifecycle management.

Version: 2.0
4.2.2 SMA Service

If you like to get your processes documented by SAP experts you can order the SAP Solution
Management Assessment service. The SAP Solution Management Assessment team will be
on-site with the customers‟ experts for three or more days, depending on the complexity of
the assessed solution, and checks or adjusts the system information in SAP Solution
Manager. SAP Solution Management Assessment is available worldwide for all SAP
solutions and contains:
 Assessment of your
o critical end-to-end core business processes and technical infrastructure
o operation, monitoring and administration procedures
o performance, data volume and throughput of core business processes
o solution management strategy
o operation efficiency by aligning your business and IT departments
o rollout strategy
 Identification of related top issues and areas of concern
o eliminate existing and potential issues for solution
 Analysis and description of
o the core business processes (see figure 4.6) and solution landscape
o the system landscape and related interfaces
o the issues and recommendations to be applied
 Detailed action and service plans to address identified issues and recommendations

Version: 2.0
Figure 4.6: Core business processes defined in SAP Solution Management Assessment
service
SAP Solution Management Assessment has been delivered more than 100 times per year for
10 years.
4.3 Enrich the process structure with technical information

This chapter gives you a brief summary with which type of information you can enrich your
business process structure in SAP Solution Manager. This additional information and the
reuse in the further application lifecycle make the difference between SAP Solution Manager
and typical business process modeling or document management tools.
4.3.1 Documentation of transactions and custom code
New technical objects, like customer transactions or programs, can be created in the
configuration phase using transaction SOLAR02. You have to document them on the
transactions tab. Until creation, the developer works on the development tab. It is the working
environment for developers.
Especially regarding the customer developments, which are by their nature not -SAP
standard, the clarity, completeness and reliability of your solution documentation stands in
direct relationship to the efficiency of your internal communication and SAP Support. To fully

Version: 2.0
benefit of the SAP Enterprise Support offerings, your custom development solution
documentation has to contain (see figure 4.7):
 A business process step with a meaningful name
 A short description of the development on project documentation or development tab.
 The related development objects, e.g. programs or transactions in the customer
name space
 When released the finalized programs and transactions have to be maintained on the
transactions tab. Only then it can be reused for other SAP Solution Manager
capabilities like Solution Documentation Assistant and Business Process Change
Analyzer.
Customer developments can be programs that are implemented in SAP applications,
independent applications that are operated in addition to an SAP application, and that are
connected to it via interfaces, or changes to existing standard applications (modifications).
Figure 4.7: Key elements of custom code documentation

The Standard Solution Documentation for Custom Development describes the
requirements and gives step by step guidance how to do solution documentation for custom
developments.
4.3.2 Documentation of background jobs
It is recommended to document critical background jobs on the transactions tab of the

specific business process structure element. This serves as basis for job scheduling
management functionality of SAP Solution Manager, and bridges a communication gap
between business and IT. You either have the possibility just to document the specific
background jobs name or to maintain a link leading to the detailed Job Management Work
Center providing detailed job information including systems, contacts, authorizations, tasks,
error handling etc.

Version: 2.0
4.3.3 Documentation of interfaces

rd
Interfaces used in core business processes, especially interfaces to 3 party systems, should
be documented as well. Interfaces of a core business process are grouped under the header
Interface Scenarios (see figure 4.8). You define the list of interface scenarios on project level
in the „Structure‟ tab in the „Interface Scenarios‟ node. At least one interface scenario has to
be defined to group the single interfaces.
Figure 4.8: Interface documentation of scenarios, attributes and where used check
Define a meaningful scenario name and add the list of single interfaces to the scenarios. This
is done on the „Structure‟ tab as well. Enter the sending and receiving logical component and
via application help the interface technology and type.
Using the „attributes‟ button, you have the advantage to document interface details in a
guided way. Using this button, you are asked for the central information typical for interface
documentation. As you are linked to the managed system, you can choose values directly out
of the data from the managed system (see figure 4.9). So it is ensured that the spelling is
correct and the content really available. Alternatively or in addition, you can add already
existing and valid documentation to the project documentation tab.
Configuration data of interfaces you maintain in the business process structure on the
configuration tab in the predecessor and successor process step of the interface.

Version: 2.0
Figure 4.9: Attributes maintenance, application help leading to the managed system
If you have done the interface documentation this way, a user with information needs can
check directly via the graphics or via the „Where used‟ button, in which process an interfaces
is used (see figure 4.7).
In the standard solution documentation for Custom Development you find a more detailed
description of how to maintain interface documentation. In the SAP Service Marketplace alias
ALM, under Processes, Solution Documentation, Capabilities, Business Blueprint and
Solution Directory, you find demos showing how to maintain interfaces and how to transfer
them into a solution.
4.4 Reporting
While the project duration, SAP offers a collection of useful reports in one transaction
allowing a fast ad-hoc reporting. The reporting can be accessed directly via transaction
SOLAR_EVAL, or from the Implementation/Upgrade work center navigation area Reports
(see figure 4.10).

Version: 2.0
Figure 4.10: Reporting via the Implementation/Upgrade work center
Moreover, the project phase specific transactions (e.g. SOLAR01 for the Business Blueprint)
allow to jump into the reporting transaction (Environment –> Project Analysis). All
assignments that are done in the business blueprint or in the realization phase of a project
can be evaluated.
The project analysis and analysis results display options are very flexible. You can use
selection criteria to restrict the scope of the analysis. You can also specify the presentation of
the analysis results. You can create standard analyses and save them as selection variants.
You can call the displayed elements of the project structure or IMG activities directly from the
output.
4.5 How to keep business process documentation current
4.5.1 SAP Solution Manager solutions
As SAP‟s central application management platform, SAP Solution Manager is crucial for
documenting customer solutions. One of the main goals of SAP Solution Manager is to
provide transparency of the solution and of related operations processes. For this, the tool
provides various functions to set up technical documentation, collect required documentation,
and to make the information available for stakeholders. This includes both the reuse of
existing documentation from earlier projects and the creation of new documentation within a
solution.
Projects and solutions have a typical lifecycle. In the implementation and configuration
phase your solution documentation is based on implementation projects. With the hand-over
to operations, the project content can be taken over to one or several solutions. The solution
is then used as the basis for the ongoing maintenance or business process monitoring. In

Version: 2.0
case of bigger changes, the solution content is the perfect backbone for a new upgrade
project (see figure 4.11).
Figure 4.11: Application lifecycle management is based on projects and solutions
After the go-live of a project and the copy of the project information to one or several
solutions, the project is locked for changes, and the solution contains the up-to-date
documentation of all core business processes and the supporting productive system
landscape information. So, scenarios, processes, process steps, master data, organizational
unit structures, and all linked documents, configurations, transactions, test cases and
learning maps are available for solution operations (see figure 4.12) .
When you are copying a project, interfaces are not handed over automatically. To transfer an
interface to a solution, you have to select it via the selection help at the interface structure tab
of a solution. Then mark and assign the interface in the graphics tab.

Version: 2.0
Figure 4.12: Projects and solutions have nearly the same structure and content
Solutions allow the controlled maintenance of business processes and dedicated information
via maintenance projects and check-out/check-in functionality. So, the benefits of a solution
are up-to-date, central solution documentation with a reliable solution documentation to be
used in the complete operations phase. In addition, the information available with the
solutions are basis for many other SAP Solution Manager capabilities, like business process
and interface monitoring, upgrade projects, knowledge transfer and issue management.
Solutions are accessed via the Solution Manager administration work center or the solution
directory (transaction SOLMAN_DIRECTORY). They contain information, data, and
documentation similarly structured to projects.
The highlighted areas in figure 4.13 show the main differences from projects.
1. The list of maintained solutions is shown in the navigation tree
2. Productive systems must not be changed without controlled access; so the

Configuration tab is for display only.
3. The controlled access and change is provided by the check-in/check-out mechanism,

which can be extended to a full change request management workflow.
4. The last entry in the navigation structure is folders listing system and server
information supporting the business scenarios and processes above

Version: 2.0
Figure 4.13: Content differences of projects and solutions
To transfer documents from projects, the business process repository or other solutions, into
your current solution, you can copy or reference documents or transfer documents of
selected document types only, e.g., specifications, requirement or customer-defined
document types.
4.5.2 Solution tailoring
In the beginning an SAP Solution Manager solution typically has exactly one project as
source (1:1 relationship). Later in time the solution can be enriched with business processes
of other maintenance or implementation projects. The solution combines productive systems
of a solution landscape (the productive systems are now the leading role in the logical
component). To allow a quick technical overview and to document which (core) business
processes run on which systems, an SAP customer has at least one SAP Solution Manager
solution.
Solutions have specific properties allowing central access and efficient maintenance, and
ensuring long-term reliability
 Every solution has a leading system role as a unique characteristic, e.g. production,
preproduction or quality assurance
 The solution has an authorization concept with roles and authorization objects, so
that the access of different users can be restricted
 Solutions are independent from each other. The criteria for solution design can take
into account independent organizational or business units

Version: 2.0
Usually small and midsize customers do not need more than one solution (see figure 4.14).
Figure 4.14: Solution design of a small to midsize company
As big companies have several org. units and core business processes implemented or
maintained in parallel, solutions can be tailored due to the specific needs. Creating more than
one solution, several factors should be taken into account:
 Organizational units of a company or a corporate group, also their structure, required
technical availability, etc. (see figure 4.15).
Figure 4.15: Solution design of a global oil company

Another important factor having influence on the number of projects and solutions is the
organizational view relevant within a corporation. Individual customer organizations split
responsibilities related to systems and processes. Thus, solutions might be defined according
to organizational structures, such as company structures, business units, support
organizations, or regional organizations.

Version: 2.0
As a rule, such units are organizationally independent, including the customer IT departments
and possibly also the support centers. In such cases it makes sense to create different
solutions.
 The end-to-end business processes across all involved systems/logical components

(also third-party)
One of the most important criteria for a solution unit is the integrity of business
processes. From a logical point of view, it is necessary to have all of the business
process steps that are related to the same core business process in one solution.
This is especially important if you plan to set up business process monitoring, in
order to enable the monitoring of a complete business process within one solution. It
is also required for the delivery of SAP Services that analyze business processes
(Business Process Performance Optimization, Solution Management Assessment,
Technical Integration Check, and so on). One service can only be assigned to one
solution, so all (Please also refer to the Best Practice Document „SAP Solution
Manager – Solution Lifecycle‟ (www.service.sap.com/solutionmanager -> Media
Library -> Technical Papers) necessary business processes and business process
steps must be contained in that solution for successful service delivery.
 Additional reasons to create more than one solution might be:
o Data sensitivity, allow access only for specific roles, user groups or org. units
o Parallel maintenance cycles
o System responsibilities
o Monitoring SAP and non-SAP systems is separated
o Performance in case of very big projects with thousands of process
structures and objects
4.5.3 Controlled maintenance via check-in/check-out
One maintenance project can be assigned to one solution, and the check out/in functionality
can be activated. In this case, the structure between solution and project can be exchanged
(during the entire cycle the data in the solution cannot be changed). The checked out
scenario/process/process step can be adjusted in the maintenance project before check in
back to solution.
Note: The maintenance project is intended for minor changes only, like adjustment of
documentation. Changes causing high effort should be done in a new long term
implementation project. Such a long-term change could be a new business process with the
need of end-user training.
Basically you have 3 options to maintain a solution:

 Option 1: Transfer processes to be changed into a maintenance project for editing
with check-in check-out functionality, and then back into the solution. This is the
option to start with and is described more detailed further down.

Version: 2.0
 Option 2: Extended check-in/check-out with change request management. The

check-in/check-out process can be combined with the complete change request
management functionality (see standard change management)
 Option 3: Maintain directly in solution directory. Due to the lack of control and a
decreasing reliability and accuracy of the solution documentation, this option is not
recommended.
Option 1: Check-in/Check-out workflow

 Changes to the sub-structures "Organizational Units", "Master Data" and "Business
Scenarios" are made in the maintenance project assigned to the solution on the
„Solution Settings‟ tab in the Solution Directory (see figure 4.16).
Figure 4.16: Assign or create a maintenance project for a solution, and activate the history
 To change an object, a request is sent to the solution administrator who has approval
authority
 If approved, the object can be checked out to the assigned maintenance project

Version: 2.0
 Once all changes have been made, the checked out sub-structure is set to “ Ready
for check-in” in the maintenance project, and can be checked back in to the solution
directory (see figure 4.17)
 This procedure works without a formal change request workflow (the check box
„Enable Change Request Management‟ has been left unchecked).
Figure 4.17: Solution maintenance workflow
Via the history push button, projects and solutions provide information of changed business
process structures, documents, transactions, issues, end user roles and other administrative
data. Via the history you can answer questions like: „Who did, when, which kind of changes?‟
(see figure 4.18)

Version: 2.0
Figure 4.18: The history shows who did change what
The transactions Business Blueprint and Configuration provide a context check,

investigating if the maintained technical objects on transaction tab are really available in the
managed system. Run this check before a go-live and the do a solution documentation
assistant analysis to ensure data reliability. To perform the context check, choose your
project, go to the menu entry „Update Component System Check‟ and start a report to identify
misspelled or outdated technical objects (see figure 4.19). Done that, you can remove not
existing objects out of your solution documentation, or add the missing objects to the
managed system.
Figure 4.19: The Context check allows the identification of obsolete solution documentation

Version: 2.0
4.6 Verify the process structure and related objects with

solution documentation assistant
Customers need clarity and transparency about their current situation. To find the right
starting point, it is important to identify which data exists, and which processes are already
documented. Information about planned and scheduled activities also helps to identify the
use cases for solution documentation assistant in these plans.
Typical customer pain points which describe where solution documentation assistant can
support customers, partners and consultants are:
 Is my external maintained business content still up to date?
 How can I use SAP‟s implementation content to validate my business content in SAP
Solution Manager?
 How can I use solution documentation assistant to start maintaining my business
content in SAP Solution Manager?
 Is my maintained project content still valid?
 Is my solution content still valid?
Solution documentation assistant (SoDocA) verifies and rates customers‟ business process
documentation. Data basis is the usage frequency of technical objects related to the business
process structure. The usage frequency gives transparency about potentially obsolete
objects, clarity about mission-critical objects, and is an excellent starting point for initial
documentation as well. As the prerequisite for the usage of the solution documentation
assistant is to have system data available, most of the use cases are related to the
operations phase. Solution documentation done with the solution documentation assistant
has the big advantage that it is based on the real usage of your system and not on theoretical
models and concepts.
4.6.1 Solution documentation assistant benefits

Solution documentation assistant analyzes solutions and all project types, like template,
implementation and maintenance projects, and combines it with usage data of technical
objects, like transactions, reports, BADIs and custom developments. This
 accelerates initial Solution Documentation
 enhances solution and usage transparency
 enables simple and fast system consolidation
 allows cost-efficient verification of Solution Documentation through automated,
regular analysis
 provides a basis for optimized test planning
SQL statement analysis, the involvement of table entries, enables a detailed live system
analysis from a business perspective. This:
 facilitates business improvements
 causes standardization through comparison of business processes at different
locations
Solution documentation assistant is a young functionality which will be further developed with
the next SAP Solution Manager releases. Its focus remains on the verification of the business

Version: 2.0
process structure and related technical objects. It has an interface to up and download
configuration content (rules), enabling SAP consulting or partners to use templates for a fast
initial documentation or analysis of business processes
4.6.2 Solution documentation assistant use cases discover and verify
In the context of your business process structure there are two main use cases: „Discover‟
and „Verify‟ (see figure 4.20):
Figure 4.20: Decision tree – when to use solution documentation assistant
If no business process documentation is available, you firstly should check the SAP standard
documentation, the predefined SAP implementation content (BPR) (see figure 4.21). Create a
new implementation project. Use the BPR as template, selecting the scenario(s) likely
reflecting your core business process(es). Verify the scenario(s) with the help of solution
documentation assistant. You will quickly identify which of the standard processes are used.
Update the original project or create a new one. In a second run, remove the not used
structures and enrich the business process structure with your custom developed objects and
non standard process steps, and define more specific rules. With this method you quickly
come to a reliable documentation of your core business processes based on real usage data.
Extend the documentation with critical processes or selected scenarios using BPR, and verify
the additional structures as shown above. Automatically and regularly verify the project to
keep the documentation reliable and up-to-date. So, the key advantages of this method are to
get a starting point, enable prioritization of business processes by system usage, and the
ability to verify the documentation progress.

Version: 2.0
Figure 4.21: Discover

Alternatively, if you do not want to use the SAP standard, you can use the usage information
of the solution documentation assistant to manually create the initial business process
structure, and document the related objects on the transactions tab.
The verify use case works very similar, the only difference being that you already have a
project or solution as starting point for verification available.
Going into the details of a solution documentation assistant analysis, the rating of a node
includes both sub nodes and the identifying check items directly assigned to the node level
(see figure 4.22). The analysis results of the check items and check steps that are assigned
to the check items are displayed in the screens next to the tree structure.

Version: 2.0
Figure 4.22: Business process verification
Results are displayed with a rating. Depending on the results, the structure nodes have the
following rating possibilities:
 Green: The node is active

 Yellow: The node may be active. The result summarizes different status:
o The results for a structure node take into account the analysis structure
hierarchy, as well as the assigned check items. This way, the result of a
business scenario summarizes, for example, the results of all assigned
business processes. This can cause the status 'possibly active' if, for
example, a business process has both active and inactive process steps
o The results of the analysis for all time periods are shown by default. A node
can have the status 'possibly active' if, for example, it is only active during a
specific time period
 Red: The node is not active
 Grey: The node has not been rated, e.g. the node had no flag and was not analyzed
You can use the results of an analysis to update an existing Solution Manager object or
create a new one.
If you have created an analysis project based on a Solution Manager project, you can update
the Solution Manager source project with the results of the analysis. Creating or updating the
SAP Solution Manager project, you can adjust the effect of the default rating.
For each type of rating, for example „Active‟, „Inactive‟ or „Probably active‟, you can choose
one of the following rules in the „Update Action‟ column (see figure 4.23):
 Set in Scope
 Set out of Scope
 Do Not Change

Version: 2.0
Figure 4.23: When creating/updating a solution manager project, define when the scoping
flag is set and when left blank.
In the project, the checkbox in front of a business process is then accordingly marked as „In
Scope‟ or „Out of Scope‟ (see figure 4.24).
Figure 4.24: Scoping flag at the business process „Order to cash‟

Version: 2.0
In the next run of your analysis you can then choose to use only those structure items and
technical objects which are in scope. Alternatively you can take the not sufficiently used
structures and objects into account as well, but keep an eye on them. After some time, when
you are sure that they are truly obsolete, delete them from your solution analysis or exclude
them from your further analysis.
4.6.3 Use case verification of business process variants – rule

database
The solution documentation assistant offers a rule database with an overview of all available
step checks, including those that are not assigned to any analysis project. Check steps
supported by solution documentation assistant are:
 Transactions
 Reports
 Business Add-In (BAdI)
 Database table
The rule database lets you search for check steps. The results table displays all check steps
in the rule database that meet the search criteria. You can search for specific check steps
with detailed criteria. For each check step, detailed information is provided, such as:
 Name of the check step. By default this is made up of the name and description of
the referenced object in a transaction, for example, SE16 – Data Browser.
 Type of check step, for example, transaction
 User who last changed the check step
 Time of last change
In some cases, the automatically defined check steps based on transactions like the common
VA01 are not specific enough to get an insight of the usage of a business process or
business process variant. In this case, the check steps of a process structure can further be
enhanced with additional rules, including thresholds, e.g. with additional check steps reading
database table entries. You can create SQL check steps that check the following cases:
 Whether a specified database table is present

 Whether a specified field of a database table is present
 Whether specified values occur in fields of a database table
 How often certain values occur in fields of a database table
Figure 4.25 shows the result of such an enhanced, self defined process step. Here, two order
types, standard order and promotion order, have to be checked and compared. The
additional rule for:
 the standard order contained a check on table VBAK, column AUART, Value OR
 the promotion order contained a check on table VBAK, column AUART, Value AA

Version: 2.0
The result was that, during the time period of the last three months, the standard order had
680 table entries, the promotion order 0 table entries. This allows several conclusions to be
checked with the business process champion or expert, e.g.:
 the promotion order business process step is potentially obsolete

 the process to use the promotion order is not known by the end users and there
should be an additional training
 the promotion order process step is valid, but not executed in the selected time
period (this could as well be the case for seldom used BI processes)
Figure 4.25: Business process variants

As summary you can say, that the analysis project independent rule database allows the
reuse, display and management of all rules. This makes sense especially for self-defined
rules requiring some business know-how, e.g. checks of specific table entries.
4.6.4 Use case housekeeping
The solution documentation assistant provides a summary of the analysis results by analysis
success and object use, for example, of SAP or customer-specific transactions and reports
(see figure 4.26).

Version: 2.0
Figure 4.26: Housekeeping – display of not used objects
Depending on the type of check steps used, the analysis results are summarized under
different aspects, for example:
 All transactions and reports
 SAP transactions and reports
 Customer-specific transactions and reports
The following result types are displayed for each of the three named groups (for further
details refer to the online documentation on the SAP Service Marketplace):
 Analyzed
 Not analyzed because, for example, there is no data for the client you specified when
creating the analysis
 Not analyzed in other clients
 Used. The objects are used in the analysis period and in the systems specified for
the analysis
 Not used (only affects customer-specific transactions and reports)- if you have
selected the „Get All Customer Objects‟ option when you created the analysis
Analyzed results can be reused as check-steps. For this, the listed results can be added into
the „Rule Database‟ and accessed via the „Analysis Project‟ view
Selecting the „Get All Customer Objects‟ option creating the analysis, solution documentation
assistant displays you a quick overview of the not used objects for a chosen time frame. This
is a good starting point to identify potentially obsolete coding, and for housekeeping activities.
The expert tool analyzing and managing custom code professionally remains the custom
development management cockpit (CDMC). How to manage custom code is describes in the
standard „Custom Code Management‟

Version: 2.0
4.6.5 Use case governance
Solution Documentation Assistant allows controlling the local roll-out of globally defined
business processes. To do this, you define global templates in a template project. Then you
copy the templates to an implementation project, and do your local adjustments, e.g.
customize the local currency or holidays. After go-live and hand-over a solution you can
control the successful usage with the Solution Documentation Assistant (see figure 4.27).
Figure 4.27: Governance
If some business processes have not the expected usage frequency, you identify the root
cause of the problem and e.g. intensify the local roll-out, or adjust the business process and
its documentation.
Technically, the maintenance of projects and solution works in the following way (see figure
4.28): After finishing your template/implementation project, you copy the data into one or
several solutions. The solution is the data source for the solution documentation assistant
analysis project.
Planning to create a new project out of an analysis, but to keep the project documentation
and configuration data, copy the source project and update the copy with the analysis
results. On the other hand, this copy leads to a break of information in the application
lifecycle between the source project and the copy. So, you are only able to work with the
compare and adjust functionality for template and source project, and separately for the
project copy and derived solution.
In the analysis, the usage data is derived from SAP Solution Manager (EWA) and Satellite
Systems (RFC). With the analysis results, you can update the source project or create a new

Version: 2.0
project. For a controlled update of the solution via check-in/check-out functionality, create a
new, or update the existing maintenance project related to the solution.
Figure 4.28: Solution documentation assistant data flow before and after project analysis -
best practice
4.6.6 Use case test management
Figure 4.29 describes the typical steps to prepare and define a test plan, execute it, and
control the test progress and success. In this sequence, a business process expert can
benefit of solution documentation assistant when they need help to estimate the priority of
processes and objects to be tested.
If the test execution needs several months, the test coordinator can check the test progress,
e.g. if newly developed transactions or programs have already been tested or used. In this
case, the test coordinator or project manager compares the test status available via
transaction STWB_2 and the object usage in the solution documentation assistant. You can
check the object usage pressing the period details pushbutton at a check step (see figure
4.30). Alternatively you can check the usage data in the analysis results.

Version: 2.0
Figure 4.29: Use solution documentation assistant to prioritize processes and objects to be
tested, as well as to check test execution
Figure 4.30: Show period details of a check step to display the usage frequency
development of a specific technical object

Version: 2.0
4.6.7 Solution documentation assistant data sources and

recommended data flow
The solution documentation assistant manages information about projects and productive
solutions. If you create an analysis project choosing the data source, a specific project or
solution, the business process structure is automatically transferred (see figure 4.31).
Figure 4.31: Automated transfer of business process structure from chosen project of
solution
Out of the technical objects on the transaction tab, check items and check steps are
automatically created as well. The analysis project in Figure 4.32 shows the analysis
structure and the check rules (check items including check steps) assigned to the analysis
structure nodes.
The solution documentation assistant offers you a view showing the structure and details of
an individual analysis project. The screen is divided into two related parts. On the left-hand
side, analysis structure mirrors the structure to be analyzed and matches the structure
source, which can be implementation projects, solutions, or an uploaded partner project
structure. The right-hand side contains check items, check steps and threshold values, which
are listed in a hierarchical order and are related to the selected structure node (see figure
4.31).

Version: 2.0
Figure 4.32: Solution documentation assistant analysis project containing process structure
linked to check items and check steps
The process structure mirrors the business processes to be analyzed. The check rules rate
the analysis structure nodes in the analysis. Check rules are the check items and check steps
that belong to a structure node, for example, a business process. The check rules are
displayed in two tables:
 Check items are the header for one or a group of checks steps. Check items are the
link between structure items and check steps. A check item stands for one variant to
analyze the linked process structure. It is possible to assign several check items to a
structure item.
 Check steps contain the technical objects to be analyzed and the threshold value to
identify the usage rate as true or false.
The relation of business structure and rules with usage results allows rating the business
structure later on.
Having the process structure and rules defined, the customer system landscape environment
provides the usage data via the SAP EarlyWatch alert infrastructure (see figure 4.33). The
managed systems must have release 4.6C or higher.

Version: 2.0
Figure 4.33: Data sources of usage data

The data transfer for the workload statistic data is managed by the SAP EarlyWatch Alert
service session, which is already part of our SAP support engagement. The SAP software
component ST-PI has been enhanced to collect the workload statistics data. This enhanced
service has to be activated via the SAP Solution Manager customizing IMG. After activation,
the workload statistics data is transferred via the SAP EarlyWatch Alert. To read the EWA
data, the SAP Solution Manager standard RFC connection SM_XXXCLNTXXX_READ is
used.
Customer managed systems are additionally connected with the customer‟s SAP Solution
Manager via another remote function call connection (RFC). To get access retrieving real
time data, e.g. SQL and BAdI data, the SAP Solution Manager standard RFC connection
SM_SIDCLNTXXX_TMW is used.

Version: 2.0
5 Functions beyond the core solution documentation
5.1 Further enrich the process structure with information
5.1.1 Project documents
You can use the project administration and business blueprint to manage your project
documents. SAP Solution Manager can act as your central platform to store and manage all
project documentation, e.g. configuration guides, manual test cases, and business
requirement documents improving transparency and allowing access to all project
documentation. Business blueprint provides the capability to store and manage project
documents (unstructured content) at various levels within the business process hierarchy.
Figure 5.1: Project documentation tab for maintenance of project specific documentation
Documents can be assigned to specific process structure elements, such as scenario,

process or process step (see figure 5.1). You can develop your own document templates, or
use templates delivered by SAP, for example, business process procedures or configuration
guides.
Done that, you can assign document types to project types (implementation, template,
upgrade and maintenance) in order to make it available for blueprint, configuration and other
project phases.
The definition of document types can be done centrally in SAP Solution Manager using
transaction SOLAR_PROJECT_ADMIN. After the document type is created, the file can be
created using the editor, or uploaded from a local file. The document settings are used to
steer the availability of the document types:
 Global document: Document types indicated as "global" do not need to be explicitly
assigned to a project. Non-global document types have to be assigned to those
projects in which they shall be available. A document type can be assigned to more
than one project.

Version: 2.0
 Several documents allowed: allows assigning several documents of the same

document type to one structure node.
 File extension: specify the extension of the document. This is needed if the document
template will be created based on the editor.
 Blueprint relevant: if the document based on this template will be treated blueprint
relevant or not.
The status schema allows to restrict the number of status values, and to present them in a
specific order. These status values are then assigned to documents, allowing using the
document template in this specific order. Additionally, an initial, locked and final status can be
defined.
Further more, a digital signature can be assigned at a status value level. This digital steers if
a specific status requires a sign or not.
Digital signature based authorizations prevents uncontrolled document changes. The change
history and versioning of documents allows tracking of changes. A full-text search based on
TREX (separate installation) is supported for all uploaded documents, allowing an efficient
work with your managed documents
5.1.2 Configuration documentation
Solution configuration allows access to various customizing tools to make system settings or
store pre-configuration (see figure 5.2). It re-uses the business process structure, is linked to
your managed systems, and central starting point for making system settings for your
implementation project.
Figure 5.2: Configuration documentation on tab „Configuration‟
Besides using the SAP pre-defined implementation content like IMG Objects and BC Sets,
you can as well develop and document customer-specific developments, so getting
transparency through central storage of all documented customer-specific developments. The
central and predefined access to your managed systems allows time-efficient customizing
without reiterative logon. As well the processing status can be tracked, and the responsible
processors visualized.

Version: 2.0
The access to the managed system is enabled via „trusted trusting‟ RFC connection and
logical components. The trusted trusting RFC technique allows a fast, generic logon to the
managed system. In the managed system the user has not more authorizations, but only
those previously assigned to the user.
Customizing settings can be collected by processes into „Business Configuration Sets‟ (BC
Sets). BC Sets make customizing more transparent by documenting and analyzing the
customizing settings. They can also be used for a group rollout, where the customizing
settings are bundled by the group headquarters, and passed on in a structured way to its
subsidiaries. Advantages of using BC Sets:
 Efficient group rollout
 Industry sector systems are easier to create and maintain
 Customizing can be performed at a business level
 Change Management is quicker and safer
 Upgrade is simpler
After creating new BC Sets, you have to assign them to the process structure element. Check
the content of the assigned BC Sets. Delete the assignments of BC Sets that are no longer
required from the project in the application systems. Activate one or more assigned BC Sets.
The status of activated BC Sets is shown in the configuration tab.
5.1.3 Documentation of test cases
A very prominent use case is to use the SAP Solution Manager test management
functionality.
Solution configuration allows assignment of new or existing test cases to a process structure
element. This structured storage of test cases improves transparency and serves as basis for
process oriented test management functionalities. Types of test cases assigned to the
process structure can be:
 Test documents
 Manual test cases in SAP script
 External applications
 Automatic test cases
 Function module tests
Manual test cases can be linked to transaction or program, accelerating the test case
creation and execution. But SAP Solution Manager offers much more than only an
assignment of test cases and linking of technical objects. For instance, you can generate test
plans automatically by using the business process hierarchy, so enabling the continuity of
end-to-end business processes via central test management. The creation of test packages,
reporting, or risk based testing as well benefits of, or interacts with, the process structure and
its related information.
To get an overview about the test management options and details, refer to
www.service.sap.com/alm >> Processes >> Test Management. The integration of the SAP
Solution Manager test management functionality in SAP HP Quality Center by HP has been
described in the SAP Professional Journal Vol.10 (2008), Issue 3 (May/June) in detail.

Version: 2.0
Note: It is recommended to assign the test information directly to the lowest level of the
process design, the process step.
5.1.4 Training material and learning maps
Last functionality to mention in the context of assigned data is the creation and assignment of
training material based on process structure elements (SAP or non-SAP business process
steps). The assignment of training materials, such as descriptions, power point presentations
or simulations is done on tab „Training Materials‟, and serves as a basis for creation of end
user specific learning maps. This central assignment of training material to business
processes offers the possibility to change training materials by changes of business
processes, and reduces the effort required to develop structured end user training material.
The distribution of training material can be efficiently rolled out via web-based e-learning
maps and sent to users with the job profiles, organizational units, or user numbers
maintained on tab „End User Roles‟.
Note: For professional creation and management of training material, SAP Solution Manager
offers integration to the SAP Productivity Pak by RWD via the SAP Productivity Pak by RWD
adapter for SAP Solution Manager (see definitions in the appendix).
5.2 Which expert functionalities does the business process

documentation offer?
Having your basic solution documentation in place, the next question is how to do a more
detailed modeling, and reuse this information in other application lifecycle phases. Up to now,
the focus of SAP Solution Manager was not to offer detailed modeling capabilities.
Nevertheless, it offers several possibilities addressing different blueprint creation and
modeling needs:
 Templates
o Reuse of complex, predefined information to support global roll-out
processes across geographical distances
 Short Cuts
o Links to reuse process structure elements
 Customer Attributes
o Name-value combination to specify and differentiate process structure
elements
 Key Words
o Name to specify and differentiate process structure elements
 Graphics
o Visualize and document simple business process step variants graphically
In general it has to be said that the modeling of business processes is a very customer
specific task. It is dependent on the customers organization, ALM phase, information to be
rd
added, reuse needs, and connected 3 party or partner tools. So, it is not possible to offer a
general best practice, but in the following, you will get a brief overview of the possibilities
working with the business structure, their benefit, and limitations.

Version: 2.0
5.2.1 Template management
Unified standards can be applied throughout the project by using template management. Its
scope comprises the definition of standards and systems, which are used throughout an SAP
Solution Manager project. As shown above, the blueprint phase is further supported by work
with SAP reference processes from the business process repository (BPR). This includes
(minimum scope): predefined SAP processes, configuration and documentation.
Template management allows efficiently managing multi-site SAP installations across

geographical regions – from initial template definition to template implementation and
template optimization, such as part of a global rollout approach (see figure 5.3).
Figure 5.3: Template Management Supporting Global Rollout – process flow
Main template management features are:

 Template definition, implementation and optimization of whole projects and
roadmaps, or linked information, like roles, configuration information and document
types
 Bundling of business processes and standardization
 Link to process-specific developments, configuration, and test data
This predefinition of standards leads to transparency, allows accelerated rollout to other

company locations and to cost efficient re-use of existing business process and configuration
information (see figure 5.4).

Version: 2.0
Figure 5.4: Reuse of configuration templates in configuration
The following modeling methods address not so much the standardization of whole projects,
but rather the time-efficient modeling and modeling of business process variants.
5.2.2 Short cuts
Business blueprint provides short cuts linking to other process structure elements. Short cuts
can be created at business scenario, process or process step level, allowing the reuse of
process structure elements within or across projects or solutions (see figure 5.5).
Figure 5.5: Use short cuts to reuse business process structures and linked information within
or across projects and solutions

Version: 2.0
The usage of short cuts reduces the manual effort during documentation of a large number of
processes. As you can make changes in a central place, changing structures within a
dynamic project, and maintenance of big business structures, can be done more time
efficient. As figure 4.9 shows, short cuts can be a method to model business process variants
as well.
As each process structure in each project or solution has a unique identification number,
(GUID) adjustments in case of transfer to other projects or solutions are necessary. That
means that, after the copy of a project or solution, the short cut needs to be adjusted so that
they point to the correct target structure node in the new project or solution, and not to the
original structure node.
Note: With release of SAP Solution Manager 7.0, this technology cannot be recommended in
case the process documentation is re-used for the „Business Process Change Analyzer‟
(BPCA). Idea behind is that the related technical bills of material (TBOMs) currently cannot
be assigned, currently.
5.2.3 Customer Attributes
Another possibility to deal with business process variants is the use of customer attributes.
Customer attributes are a name-value combination used to specify and differentiate process
structure elements (see figure 5.6).
Figure 5.6: Use attributes to make specific project information visible for specific project team
members or company organizations
The customer attributes allow differentiation of business processes, and document business
process variants. The customer can choose which attributes he wants to define, as well as
which and how many values they should have. Once defined, the attributes and their values

Version: 2.0
are applicable to all (!) projects. The configuration is centrally done via the SAP Solution
Manager Implementation Guide (IMG).
5.2.4 Key words
Keywords work very similar to the customer attributes. Keywords are names dedicated to
process structure elements (business scenario, process or process step level). They are
supposed to specify and differentiate those process structure elements. In comparison to the
customer attributes, keywords set can be created on project (!) level. They are defined in
transaction PROJECT_ADMINISTRATION and visible on the project admin tab at the
business blueprint (see figure 5.7).
Figure 5.7: Use keywords to specify and differentiate process structure elements
One of the benefits of using keywords is the possibility to differentiate business processes,
e.g. “High priority” processes, and the good ad-hoc reporting options using project reporting
(transaction SOLAR_EVAL) or filters.
Note: Structure element associations with keywords currently cannot be transferred to SAP
Solution Manager solutions.
5.2.5 Graphics
If you want to visualize and document simple business process step variants graphically,
business blueprint provides the option to use graphic tab. Here you can model process steps
and simple variants visualizing and documenting the business process variants along the
process flow sequence (see figure 5.8). You can only model on process level. As well, the
modeling is limited to less complex variations as it is not possible to model complex

Version: 2.0
structures, e.g. with „if‟ and „or‟ operators. The graphics can be exported in MS power point
format.
The graphic in the graphic tab at process level visually addresses the following
questions:
• Which process steps does the process contain?
• In which logical components do the process steps run?
• What dependencies exist between process steps (predecessor-successor relationships)?
Figure 5.8: Model the graphics for simple process variants

Version: 2.0
6 Appendix
To make sure that the different groups establish a common understanding, it is necessary to
define the term solution first. Furthermore, definitions of the elements of a solution are
required.
6.1 Process components of projects and solutions

The IT Infrastructure and the solution have one simple goal: to support the customer‟s
business in the best way. This means that IT has to provide information regarding ongoing
and past business transactions, which allows the company to control business processes and
act according to its business goals. Companies have numerous business processes which
are of different significance for economic success. The most important of these processes
are called core business processes. If the core business processes are disrupted, there will
be a severe impact on the company‟s business.
For example, the material supply of the production is a core business process for companies
in manufacturing industries. If this process is disrupted and material outages arise, the
production of at least some finished parts will be impossible, so that the company has to
change production plans, which normally causes higher total production cost. In addition,
some customer orders will not be delivered in time, so that customer satisfaction might
decrease. The material supply process needs to be considered a critical core process,
because in case of material outages the company loses money.
Before implementing an IT solution, it is absolutely necessary to capture the business

processes, and to describe them in a way that allows designing the appropriate IT support. A
methodology that is proven for this purpose is an integral element of this standard. It is based
on the following definitions:
Business scenario: A business scenario is set of business processes that define a business
task in a comprehensive way on macro level. Normally, a business scenario is related to a
company‟s business unit, a central function, or a profit center and it can also involve business
partners from other companies. A business scenario may consist of a number of variants,
each of them describing an end-to-end business flow. Each end-to-end business flow is
represented by an ordered sequence of business processes. A business scenario requires
one or more SAP components or non-SAP software.
Business process: According to the definition of Davenport & Short (1990), a business
process is “a set of logically related tasks performed to achieve a defined business outcome”.
Each process is composed of several process steps, and can run across several SAP
components and possibly non-SAP software. A business process may occur in one or more
business scenarios.
Business Process Step: A business process step is an elementary activity performed to

accomplish a process. It is carried out either by a user or by a system. Each process step
runs only in one software component. In many cases, it is represented by one transaction.
This means that the step ends in the same software component in which it has been started
(leading component). However, functions in other software components may be invoked to

Version: 2.0
provide information that is required to perform the process step, but is not available in the
leading component, e.g. availability check in a warehouse management system during sales
order processing in a CRM system. In such cases, the function invoked needs to be
represented as an additional business process step.
6.2 Solution
The solution is the entirety of all system components and processes that represent a central
business function or a business area in an information system. A company will have a
number of solutions in parallel in order to reflect the different business areas and central
functions in its information systems. Each solution consists of a number of components that
are either process components or system components. As different entities of the company
may use the same business process or system components of a solution, a component may
in general be part of different solutions.
The solution directory in SAP Solution Manager integrates the documentation of the
process components and the system components. Solutions in SAP Solution Manager group
systems of a customer solution according to certain criteria, for example all systems used in a
specific business process or administered by an individual team in the SAP technical
operations department. Solutions in SAP Solution Manager are used to provide filtered views
on the end-to-end customer solution. As such, the solution directory is relevant for all steps of
the documentation methodology. For business processes that have not been documented in
a project yet, the documentation can be done directly in the solution directory, as well.
6.3 System components of a solution

Besides the business process view of a customer solution, it is necessary to document the
technical infrastructure. This is done by describing the system components of the solution.
The following terms are used for this:
Product: A product is a deliverable unit of software which customers can view, install, and
renew, e.g. SAP CRM. Generally speaking, in its entirety, a product solves business tasks. A
product has releases, which are derived from the releases of the software components it
contains. A release of a product is also called product version.
Installation: For each installation of the SAP software product, e.g. SAP CRM, the customer
has to register a separate installation at SAP in writing, and will then receive a unique
installation number. An installation is a set of SAP systems. It reflects a specific product
version of a product, e.g. SAP CRM 7.0.
System: A system comprises components (application server, message server…), which

have direct or indirect access to one database instance. A database instance is determined
as one instance by the fact that each database table appears only once. It is important to
understand in which role the customer uses the system, whether it is used for development,
quality assurance, or productive usage. Often, the related systems, e.g. connected by
transport paths of an installation, are grouped to a system landscape, which needs to be
monitored or used in change processes. Depending on the role of a system, the product
versions in a system landscape can be different. For example, the development and Q&A

Version: 2.0
systems run on product version SAP CRM 5.0, whereas the productive system is not yet
upgraded and runs on SAP CRM 4.0.
Client: A self-contained unit in an SAP system with separate master records and its own set
of tables.
Instance: Instances are the smallest elements for designing system landscapes. They group
technically dependent software component versions, which have to be installed and operated
on a single logical system/server.
Software component: The software component is the smallest unit that can be delivered,
maintained, and deployed. It provides the technical view on the software. Each software
component is installed and patched as a whole. The software component version indicates
the release of a software component. A product version consists of multiple software
component versions. One software component can be used in several products.
Logical component: A logical component is a system-related entity that describes an
instance of an SAP solution, e.g. SAP ERP. It specifies on which SAP or non-SAP product a
dedicated business process runs (or, more precisely, a process step). Logical components
contain all currently needed system roles, like development, test, quality, production or demo
system. Those system roles can be centrally maintained in SAP Solution Manager, e.g. when
a test system has been replaced by another. Wherever the system information is used, the
new status will be automatically updated.
Typically, business and IT together determine which logical components are required by a
project. This can be defined for SAP solutions, non-SAP, or third-party products.
This helps you to describe your entire software solution in SAP Solution Manager, regardless
of whether SAP or non-SAP software is implemented.
In the context of business process modeling in SAP Solution Manager, a business process
step always runs on one logical component, which is very often reflected by a system/client
combination.
6.4 Technical environment needed for data collection – EWA

/ ST-PI
EWA: SAP EarlyWatch Alert helps to make sure that your core business processes work. It is
a tool that monitors the essential administrative areas of SAP components and keeps you up
to date on their performance and stability. SAP EarlyWatch Alert runs automatically to keep
you informed, so you can react to issues proactively, before they become critical.
SAP EarlyWatch Alert is most effective when activated for all SAP components in your
solution. It is covered by your maintenance agreement with SAP with no extra charge, and it
is a technical prerequisite to perform other remote delivery services.
In addition to the SAP EarlyWatch Alert, which is processed per system, there is the SAP
EarlyWatch Alert for solutions, which summarizes the results for a set of systems inside a
solution. It gives an overview of solution-based KPIs and alerts, and evaluates the
performance of cross-component business processes.

Version: 2.0
Keeping total cost of ownership low, and the performance of your SAP solution high, is a
tremendous value to your business – a value delivered by the SAP EarlyWatch Alert.
Knowing the status of each SAP component in your solution allows you to:
 greatly minimize the risk of downtime
 react to issues, such as bottlenecks, before they become critical
 know what is affecting the performance and stability of your solution
The underlying concept of the SAP EarlyWatch Alert is to ensure smooth operation of
individual SAP components by taking action proactively, before severe technical problems
occur. This monitoring tool is based on experience with thousands of installations giving you
a tool to save time, reduce costs and keep your SAP solution running smoothly.
ST-PI: The add-on „Solution Tools Plug-In (ST-PI)‟ provides basis and trace tools required
for service delivery and system monitoring. The solution tool plug-in contains the latest
version of:
 Function modules for data collection
 Transaction SDCCN (Service Data Control Center)
 Application Specific Upgrade: ASU-Toolbox
 Custom Development Management Cockpit (CDMC)
6.5 Solution documentation assistant
6.5.1 Solution documentation assistant - definition

The solution documentation assistant gives support along the whole solution lifecycle in all
kinds of projects. It enables you to automatically evaluate business processes in SAP
Solution Manager. It helps you prepare upgrade projects, evaluate new functions, and
analyze the use of technical objects incl. custom developments.
You can, for instance, determine which business processes are being used with which
intensity in production systems, and view this information graphically to help you identify
standardization potential and optimize your business processes. Customers already
operating a productive solution can benefit from the capability to quickly create a re-
documentation for their existing one. Its scope, however, is not limited to the initial creation of
solution documentation; as the solution documentation assistant is based on application data,
you can also use it to continuously verify and update your solution documentation in order to
keep the documentation efficiently up-to date.
6.5.2 Solution documentation assistant - technical prerequisites

The solution documentation assistant work center is the central access point, and provides
several views to manage the analysis projects, to create analyses, to work with analysis
results, and to manage check rules in the rule database. To have access to the work center,
you have to maintain the appropriate roles described in the security guide (see
www.service.sap.com/instguides > SAP Components > SAP Solution Manager).
Work center roles:

Version: 2.0
 SAP_SMWORK_BASIC (provides all the necessary authorizations for the work

centers themselves, such as authorization for POWL (table control) and navigation. It
needs to be fully maintained, including profile generation and user comparison)
 SAP_SMWOORK_SDA (provides the navigation information needed to work with
that work center)
Solution documentation assistant roles:
 SAP_SDA_DIS (provides display authorizations)
 SAP_SDA_ALL (provides full authorizations)
Solution documentation assistant uses the existing SAP Solution Manager infrastructure, like
system connections and technical statistical data coming with the EarlyWatch Alert, so that
nearly no additional configuration is necessary. Activation and related user authorization have
to be set-up via the implementation guide (IMG) and PFCG user roles.
Minimum release and support package level is SAP Solution Manager release 7.0, SP 16.
but as the work center has been enhanced significantly, SP 18 is recommended. The
managed systems must have release 4.6C or higher and at least the ST-PI release 2008_1_*
SP00 installed.
To have usage data available, the SAP EarlyWatch Alert must deliver data a minimum of one
month before the first analysis run starts. The solution documentation assistant takes into
account data of a full month, meaning that the latest month available for a current analysis is
the preceding month.
6.6 Project to solution – important transactions and work

centres
How to document a business process in SAP Solution Manager? The basic approach for all
documentation projects after the initial setup follows the following process flow (see figure
6.1):
 Project Preparation, create a project (Upgrade/Implementation Work Center,

transaction SOLAR_PROJECT_ADMIN)
 Business Blueprint, model the business process (Upgrade/Implementation Work
Center, transaction SOLAR01); assign documentation (transaction SOLAR01 and
SOLAR02)
 Configuration (Upgrade/Implementation Work Center, transaction SOLAR02) and
test (Test Management Work Center, transaction SOLAR02 and STWB_2)
 Final test and preparation (STWB_2), roll-out (Upgrade/Implementation Work
Center, transaction SOLAR02)
 Go Live & Support, hand-over to production/solution (Solution Manager
Administration Work Center, transaction SOLMAN_DIRECTORY)
 Run (Solution Manager Administration Work Center, Business Process Operations
Work Center, transaction SOLMAN_DIRECTORY)

Version: 2.0
 Verify (Solution Documentation Assistant Work Center, transaction SOLAR01 and

SOLAR02)
Figure 6.1: Business process documentation process flow
6.7 Project preparation

All the central administrative tasks relevant for the project are performed in transaction
SOLAR_PROJECT_ADMIN. There are mandatory and optional tasks:
There are few mandatory tasks enabling a quick start of your project:
 Create project
o Dependent on your ALM phase, there are several project types available,
e.g. template, implementation, maintenance or upgrade project
 Define the system landscape
o You need to define the system landscape for your implementation
project before you can access the managed systems in subsequent
project phases. Then you can centrally manage all the landscapes
you require for your project using the SAP Solution Manager.
 Define the project language
o When you choose a project language, all language-dependent information
for this language (project documentation and status information) is made
available to project members. This is independent of the logon language of
the project member
o The project structure is created, and all content is stored in the selected
project language as well

Version: 2.0
o After the project language has been selected and saved, it cannot be
changed.
The main optional tasks are:
 Determine general data, e.g. project responsible, plan data, milestones

 Assign project team members and organizational units
 Define project standards (status values, documentation types, keywords, status
schemes for document types)
 Activate access concept per structure node
 Activate quality gates
The effort of optional tasks depends very much on the purpose you want to use your project
for. In a template project you may focus on the definition of document templates, but in an
implementation project you may focus on the definition of your project team members.
6.8 Important links to more detailed information

 List of support standards:
o www.service.sap.com/supportstandards -> Media Library
http://service.sap.com/~form/sapnet?_SHORTKEY=0110003587000071119
4&_SCENARIO=01100035870000000202&
 Master guide:
o www.service.sap.com/instguides > SAP Components > SAP Solution
Manager > Release of your interest > Planning > SAP Solution Manager
Master Guide
 Application lifecycle management collection of presentations and demos:

o http://www.service.sap.com/alm-processes > Solution Documentation
 Free of charge learning maps:

o www.service.sap.com/rkt-solman > SAP Solution Manager 7.0 - EHP1 >
Requirements and Design Phase with SAP Solution Manager
 Documentation, technical papers, how to documents:

o www.service.sap.com/alm > SAP Solution Manager and Tools > Media
Library

Version: 2.0
Copyright 2011 SAP AG. All Rights Reserved

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 serves informational purposes only.
National product specifi cations 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.
This document is not subject to your license agreement or any other agreement with SAP.
SAP has no obligation to pursue any course of business outlined in this document or to
develop or release any functionality mentioned in this document. This document and SAP's
strategy and possible future developments are subject to change and may be changed by
SAP at any time for any reason without notice.

Version: 2.0

Solution Document Good

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Solution Document Good

Hochgeladen von

Copyright:

Verfügbare Formate

SAP® Standard Solution Documentation

Active Global Support

© 2011 SAP AG SAP Standard Solution Documentation Page 1 of 67

1 Management Summary ........................................................................ 4

© 2011 SAP AG SAP Standard Solution Documentation Page 2 of 67

4.6.6 Use case test management........................................................................... 46

© 2011 SAP AG SAP Standard Solution Documentation Page 3 of 67

Consisting of technical landscape and business process documentation, solution

The correct usage of implementation projects automatically leads to sufficient solution

© 2011 SAP AG SAP Standard Solution Documentation Page 4 of 67

Solution Manager (see figure 1.2). As a result, in relation to a complete implementation

Figure 1.2: Solution documentation focus areas

© 2011 SAP AG SAP Standard Solution Documentation Page 5 of 67

The main solution documentation capabilities are:

Chapter 2 of this document provides a general overview of application lifecycle management

© 2011 SAP AG SAP Standard Solution Documentation Page 6 of 67

2 Application Lifecycle Management

© 2011 SAP AG SAP Standard Solution Documentation Page 7 of 67

Figure 2.1: Organizational model for application lifecycle management

© 2011 SAP AG SAP Standard Solution Documentation Page 8 of 67

daily business operations, and how to monitor and supervise mission-critical

© 2011 SAP AG SAP Standard Solution Documentation Page 9 of 67

3 Solution Documentation Introduction

The solution documentation standard is owned by application management. As with most

 Internal business needs, e.g. functional enhancements required to increase user

3.1 Solution documentation definition

Solution Documentation means having documented the following key elements:

© 2011 SAP AG SAP Standard Solution Documentation Page 10 of 67

Solution documentation contains 2 types of documentation: the technical landscape

3.1.1 Technical landscape documentation – basic content and roles

 Application management team, e.g. business process operations experts

3.1.2 Business process documentation – basic content and roles

 Solution architects, e.g. for custom development and interface specifications,

© 2011 SAP AG SAP Standard Solution Documentation Page 11 of 67

Figure 3.1: Solution documentation process flow

3.1.3 What are core and mission critical business processes?

Figure 3.2: Key elements of solution documentation

© 2011 SAP AG SAP Standard Solution Documentation Page 12 of 67

3.1.4 Business process structure 3-level hierarchy

Business process information in SAP Solution Manager is maintained in a clearly structured

 Business Scenario: A business scenario is a set of business processes that define a

 Business Process: A business process is a set of logically related tasks performed to

 Business Process Step: An elementary activity performed to accomplish a process

© 2011 SAP AG SAP Standard Solution Documentation Page 13 of 67

3.2 Solution documentation lifecycle

© 2011 SAP AG SAP Standard Solution Documentation Page 14 of 67

Figure 3.4: Solution documentation lifecycle

3.2.1 Main use cases – initial and re-documentation

The correct usage of implementation projects automatically leads to sufficient solution

3.2.2 Solution documentation benefits

© 2011 SAP AG SAP Standard Solution Documentation Page 15 of 67

In brief, the technical landscape documentation provides:

In brief, the business process documentation provides:

© 2011 SAP AG SAP Standard Solution Documentation Page 16 of 67

4 How to implement Solution Documentation

4.1 Technical landscape documentation

4.1.1 How to implement technical landscape documentation

© 2011 SAP AG SAP Standard Solution Documentation Page 17 of 67

 In the Managed System Configuration, you connect managed systems to SAP

4.1.2 Integration of non-SAP components in solution documentation

4.2 Business process documentation

4.2.1 How to implement business process documentation

© 2011 SAP AG SAP Standard Solution Documentation Page 18 of 67

Discover - no documentation available at all