E2e standard-for-solution-documentation

SAP Standard for E2E Solution Operations

Document Version: 1.0 – 2014-12-12

CUSTOMER

SAP Standard for Solution Documentation SAP Solution Manager 7.1

2

CUSTOMER

© 2014 SAP SE or an SAP affiliate company. All rights reserved.

SAP Standard for Solution Documentation

Typographic Conventions

Typographic Conventions

Type Style Description

Example Words or characters quoted from the screen. These include field names, screen titles,

pushbuttons labels, menu names, menu paths, and menu options.

Textual cross-references to other documents.

Example Emphasized words or expressions.

EXAMPLE Technical names of system objects. These include report names, program names,

transaction codes, table names, and key concepts of a programming language when they

are surrounded by body text, for example, SELECT and INCLUDE.

Example Output on the screen. This includes file and directory names and their paths, messages,

names of variables and parameters, source text, and names of installation, upgrade and

database tools.

Example Exact user entry. These are words or characters that you enter in the system exactly as they

appear in the documentation.

<Example> Variable user entry. Angle brackets indicate that you replace these words and characters

with appropriate entries to make entries in the system.

EXAMPLE Keys on the keyboard, for example, F2 or ENTER .


Document History

CUSTOMER

© 2014 SAP SE or an SAP affiliate company. All rights reserved. 3

Document History

Version Date Change

1.0 2014-12-12 First version created

4

CUSTOMER



Table of Contents

Table of Contents

1 SAP Standards for E2E Solution Operations .............................................................................................. 5 1.1 Control Center Approach ........................................................................................................................................ 6

2 Overview of the Standard for Solution Documentation............................................................................ 9 2.1 Standard Solution Documentation and Application Lifecycle Management ..................................................... 9

2.1.1 Aim ......................................................................................................................................................... 10 2.1.2 Scope ...................................................................................................................................................... 11 2.1.3 Benefits ................................................................................................................................................... 11

2.2 Basic Architecture ................................................................................................................................................. 12 2.2.1 Prerequisites ......................................................................................................................................... 12 2.2.2 Technical Basics .................................................................................................................................... 12 2.2.3 Logical Component Concept ............................................................................................................... 13

3 Lifecycle of Solution Documentation ........................................................................................................ 14 3.1 Plan ......................................................................................................................................................................... 14

3.1.1 Project Types ......................................................................................................................................... 14 3.1.2 Business Process Structure ................................................................................................................. 14 3.1.3 Business Process Design ..................................................................................................................... 15 3.1.4 Initial Documentation or Re-Documentation ..................................................................................... 16 3.1.5 Solution Documentation Use Cases .................................................................................................... 17

3.2 Build ........................................................................................................................................................................ 17 3.2.1 Core and Mission-Critical Business Processes .................................................................................. 19 3.2.2 Integration Scenarios ........................................................................................................................... 19

3.3 Run .......................................................................................................................................................................... 23 3.3.1 Handover and Maintenance ................................................................................................................. 23 3.3.2 Reporting ............................................................................................................................................... 24

3.4 Optimize ................................................................................................................................................................. 24 3.4.1 Solution Documentation Assistant ..................................................................................................... 25

4 Driving Continuous Improvement ..............................................................................................................26 4.1 Quality assurance tasks ........................................................................................................................................ 26 4.2 Quality Targets and KPIs....................................................................................................................................... 26

5 Training ..........................................................................................................................................................29 5.1 Expert Guided implementation Sessions ............................................................................................................ 29

6 More Information ......................................................................................................................................... 31


SAP Standards for E2E Solution Operations

CUSTOMER


1 SAP Standards for E2E Solution Operations

IT organizations face new challenges every day as they attempt to remain effective and future safe while also

keeping costs for day-to-day operations as low as possible. They are also being challenged more than ever to

demonstrate their value to businesses. Therefore, it is important to optimize the day-to-day tasks that have less

obvious business value and to use KPI and benchmark-based reporting to make IT processes more visible,

demonstrating the real value that IT can provide.

In order to minimize the costs of IT, it is necessary to standardize and automate IT processes end-to-end (E2E)

without reducing the SLAs required by the business, such as stability, availability, performance, process and data

transparency, data consistency, IT process compliance, and so on.

Based on the experience gained by SAP Active Global Support (AGS) while serving more than 36,000 customers,

SAP has defined process standards and best practices to help customers set up and run E2E solution operations

for their SAP-centric solutions.

The Build phase of SAP best practices supports a Build SAP Like a Factory approach, consisting of the following

processes:

Custom code management

Change, test, and release management

Incident, problem, and request management

Solution documentation

Remote supportability

During the Run phase of a solution, adapting your IT infrastructure to a Run SAP Like a Factory operation impacts

both application operations and business process operations. Therefore, operations processes, such as technical

monitoring, end-to-end root-cause analysis, technical administration, and data volume management need to be

optimized to achieve state-of-the-art application operations. In business process operations, the same applies to

business process and interface monitoring (including performance optimization), data consistency management,

and job scheduling management.

Quality management processes and tasks need to be established throughout the lifecycle to guarantee

continuous improvement of the end-to-end operations processes while simultaneously ensuring the flexibility

needed to react to changing requirements.

6

CUSTOMER




Figure 1: Organizational Model for Solution Operations

This figure shows an organizational model for solution operations that aligns SAP best practice topics and E2E

standards with SAP's control center approach.

The Operations Control Center executes and controls the Run SAP Like a Factory processes, while the Innovation

Control Center ensures optimal custom code management and a smooth transition to production with integration

validation procedures. SAP connects to these control centers from the Mission Control Center to ensure that

professional support is available to the customer. The following Application Lifecycle Management (ALM)

functions are not provided directly in one of the control centers because they must be handled across different

areas:

Change, test, and release management

Incident, problem, and request management

Solution documentation

Remote supportability

The quality management methodologies are an essential part of SAP's Advanced Customer Center of Expertise

(CoE) concept and ensure that the KPI-driven processes are continuously improved across all processes and

teams. In addition, the quality manager roles ensure consistent and value-centric reporting to the business and

management. This unified reporting platform is known as the Single Source of Truth.

1.1 Control Center Approach

The Operations Control Center (OCC) is the physical manifestation of the Run SAP Like a Factory philosophy. The

OCC allows for automated, proactive operations, which simultaneously reduces operational costs while increasing

the quality of IT services, leading to improved business satisfaction. The OCC also drives continuous improvement

of business processes and IT support. To achieve these goals, it relies on a close interaction with both the

Innovation Control Center (ICC) and the SAP Mission Control Center (MCC).



CUSTOMER


Figure 2: Interaction Between ICC, OCC, and MCC

The OCC is a central IT support entity at the customer site, which monitors the productive SAP environment as

well as important non-SAP applications. During operation, the OCC requires a workforce of 2 full-time equivalent

(FTE) per shift to ensure that incidents are detected and resolved as quickly as possible. The OCC is equipped

with large screens that display the status of business processes, IT landscape components, as well as exceptions

and alerts. If problems occur, you use a video link to get live support from SAP and partners. The customer usually

sets up the room with assistance from SAP Active Global Support (AGS). The customer is responsible for

managing the OCC and the team of technical and functional IT operators who act on the alerts.

The OCC is most effective when closely integrated with other IT processes, such as IT Service Management

(ITSM) and Change Management. Central monitors and dashboards based on application and business process

operations display the current status of business and IT-related processes. This data can also be used to drive

continuous improvement.

An effective system monitoring and alerting infrastructure is fundamental to the success of an OCC.

8

CUSTOMER




Figure 3: OCC Concept

The OCC is most effective when closely integrated with other IT processes, such as IT Service Management

(ITSM) and Change Management. Central monitors and dashboards based on application and business process

operations display the current status of business and IT-related processes. This data can also be used to drive

continuous improvement.

An effective system monitoring and alerting infrastructure is fundamental to the success of an OCC.

For Job Scheduling Management, the OCC supervises all background monitoring processes, SAP controls and

legacy background operations. It reacts to job monitoring alerts according to predefined error-resolution

activities, and triggers follow-up activities for error handling if the relevant task are not completed within a certain

timeframe.


Overview of the Standard for Solution Documentation

CUSTOMER


2 Overview of the Standard for Solution Documentation

The SAP Standard for Solution Documentation describes how to document processes, information, technical

objects, and requirements that need to be addressed to ensure consistent solution documentation throughout

SAP Solution Manager Application Lifecycle Management (ALM). The SAP Standard for Solution Documentation

is owned by application management. As with other standards, people with a variety of roles work together to

apply this standard. End-users, business process owners, development architects, project team members, and

the program management office contribute to and rely on landscape and business process information.

Solution documentation enables you to align your enterprise and IT services, and increase transparency, which

allows you to accelerate IT activities and improve their results. SAP Solution Manager enables you to document

SAP solutions and non-SAP applications running in your system landscape. In addition to the benefits of central

and reliable solution documentation, there are several reasons to change your documentation. The following key

drivers for software changes require you to also amend your solution documentation:

Functional enhancements required to increase user productivity

Financial and environmental legislation

Sustainability criteria to increase the corporate image

Regular maintenance and implementation of support packages

Implementation of a new solution or innovation via new enhancement packages

2.1 Standard Solution Documentation and Application Lifecycle Management

Application Lifecycle Management (ALM) traditionally focuses on the software development lifecycle in

combination with other practices and tools related to governance and operations. This definition aligns well with

the most widely accepted and adopted industry standard for IT Service Management, namely the IT Infrastructure

Library (ITIL). The application lifecycle consists of six phases:

Phase Description

Requirements Collecting requirements for new or adjusted applications

Design Translating requirements into feature specifications and creating or adjusting

business processes around the new requirements

Build Developing and Customizing deployed solutions

Deploy Handing over from project into the operations

Operate Delivering the application-based service required by the business

Optimize Discussing potential improvements based on performance measurements and

initiating new developments

10

CUSTOMER




Figure 4: Interaction Between ALM and Solution Documentation

Solution Documentation serves as a platform for maintaining relevant information regarding all of these phases in

one central location. This is known as the Single Source of Truth concept. Therefore, Solution Documentation

covers all ALM phases starting with tracking requirements through the design, build, and test phases right up to

the handover, production, and operations phases. To ensure that this broad coverage is maintained, Solution

Documentation must be closely integrated with other ALM areas, such as Test Management, Change Request

Management, and Business Process Monitoring.

2.1.1 Aim

To properly document your business processes, you can begin either when blueprinting for a new application or

during productive usage of an application. The second option is referred to as reverse documentation. The

documented business processes are prerequisites for later business-process-driven blueprint, configuration,

testing, verification, and re-documentation tasks. For example, if you use the Solution Documentation Assistant,

Solution Documentation contains information about the following aspects of your application:

Core business processes

Related technical objects, such as transactions, programs, custom code, and background

Jobs and interfaces

Related (non-SAP) system and software components

Process-relevant documentation

In addition to this, there are variations of Solution Documentation. For example, the Minimum Documentation for

Test Management covers everything that allows you to use Test Management features in SAP Solution Manager.

For more information, see the Error! Reference source not found. chapter.



CUSTOMER


2.1.2 Scope

In general, Solution Documentation contains the following two main types of documentation:

Technical landscape documentation Documents systems, servers, and the technical interfaces between

these systems. This is mainly created during the initial setup of SAP

Solution Manager and managed system configuration. The data is

reused for functions like Technical Monitoring and Job Management.

Business process documentation Structured in a clear, three-level hierarchy, which is used as the basis

for the documentation of related technical objects, such as

transactions, programs, custom code, background jobs, and

interfaces.

This standard focusses primarily on business process documentation. In addition to all the SAP objects, you can

also maintain non-ABAP and non-SAP objects and documents. Solution Documentation serves not only as the

platform for SAP and non-SAP processes but also ensures that all involved systems can be documented properly.

2.1.3 Benefits

Solution Documentation acts as a central application for all documents and technical objects, which serves as a

single point of communication between operations, development, and business departments. Therefore, one of

the main benefits is a central, unified documentation platform for SAP and non-SAP processes and objects.

During the different phases of the application lifecycle, multiple employees use and interact with this

documentation. Developers can maintain technical specifications, testers can access their test cases, application

management teams can check for technical objects when an incident is reported, and business process owners

can see the current status of process implementation. The information is reused in each of the ALM phases. With

the help of a tool like the Solution Documentation Assistant, you can identify unused and undocumented

transactions, and verify business processes on a regular basis to keep this transactional data up to date. For more

information, see Optimize.

Another common problem is a lack of governance when processing documentation. Different file shares and

share points often are used. Solution Documentation allows you to search for information easily by using

keywords and attributes, maintained status values, including digital signatures, and document versioning. All

involved parties have more control over the changes happening in their documentation and transparency is

improved.

In addition to more transparency and control, your documentation remains up to date. The relevant organization

can ensure this by using the following tools:

Solution Documentation Assistant, which allows you to analyze processes

Change Request Management, which indicates changes to the system and consequent changes to the

documentation.

Business process documentation provides the following features:

Central and clearly structured documentation of business processes, related systems, and technical

information

Methods and tools like Solution Documentation Assistant to keep this documentation up to date

12

CUSTOMER




Business, landscape, and technical view enables internal business and IT process alignment

2.2 Basic Architecture

The SAP Standard for Solution Documentation does not need to be implemented itself. Instead, it needs to be

established when implementing, operating, or changing your IT solution or organization.

2.2.1 Prerequisites

This chapter explains the configuration steps and permissions necessary to use solution documentation features

in SAP Solution Manager.

Required Setup

SAP Solution Manager offers a guided basic configuration, which can be used after installing or importing support

packages containing all of the technical configuration process steps. In SAP Solution Manager Configuration

(transaction SOLMAN_SETUP), you need to complete the following scenarios:

System Preparation

Basic Configuration

Managed System Configuration

For more information about technical landscape documentation, see the SAP Solution Manager Master and

Operations Guides on the SAP Service Marketplace at https://service.sap.com/alm.

General Configuration Aspects (RFC, ST-ICO)

During the required setup, your IT and system administration department connect all managed systems to SAP

Solution Manager by establishing the required Remote Function Calls (RFCs).

You can navigate to and work in the following areas once you have set up the required connections:

The evaluation system during business blueprinting (system role evaluation)

The development system during business blueprinting and configuration (system role development)

The test system to perform test activities (system role quality assurance)

SAP also recommends implementing Solution Tools Implementation Content (ST-ICO) to be able to use the full

range of functions available in SAP Solution Manager.

The ST-ICO contains predefined contents, such as standard processes, shipped via the Business Process

Repository. This content can be used during the various phases of an implementation project.

2.2.2 Technical Basics

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 created

by the following teams:



CUSTOMER


Application management team, for example, the business process operations experts

SAP IT experts

Technical SAP Solution Manager experts

The data is displayed and maintained in the SAP Solution Manager Administration work center and System

Landscape Management.

Non-SAP components can be integrated in the solution documentation as well. Technical landscape

documentation allows you to automatically collect and display third-party system information by using the

System Landscape Directory (SLD) or Landscape Management Database (LMDB).

As with SAP applications, technical landscape documentation is often reused, for example, when performing root

cause analysis, creating business process documentation, testing, system monitoring, or during business process

operations.

Core business process documentation includes non-SAP business processes. Like SAP processes, non-SAP

process steps can be linked with the above mentioned documents, custom code documentation, configuration

information, and test cases, and displayed in the business blueprint graphics.

2.2.3 Logical Component Concept

You create logical components as part of a properly maintained system landscape. A logical component is a

system-related entity that describes an instance of an SAP product. It specifies on which SAP or non-SAP product

a dedicated business process or process step runs.

Typically, enterprise and IT departments determine which logical components are required for a project. A logical

component can be defined for any combination of an SAP product and a main instance. It can also be defined for

non-SAP or third-party products. This helps to describe the entire software solution in SAP Solution Manager,

regardless of whether SAP or non-SAP software is implemented.

14

CUSTOMER



Lifecycle of Solution Documentation

3 Lifecycle of Solution Documentation

3.1 Plan

The purpose of this phase is to prepare and create your project based on the business requirements. You also

define your general settings in this phase. Based on this, you start to develop a business blueprint that provides a

general idea of how an enterprise’s business processes should be mapped in one or more SAP systems. You

continue to use the business blueprint in SAP Solution Manager during the realization phase (configuration and

testing). You reuse the project structure you created in the business blueprint phase to configure and generate

test plans.

3.1.1 Project Types

Depending on the initial situation of your project, you need to select the correct project types to start the project.

If a global rollout is necessary, the template project provides additional tools to help with this process. The next

section introduces the individual project types in detail.

Project Type Objective

Template project Used to create and distribute templates

Contains a defined project structure and allocated objects, such as documents,

test cases, Customizing objects, and developer and training material.

Objects can be reused for follow-up projects.

If you have multiple SAP Solution Manager systems, templates and their

contents can be transported.

Used to creating a standard process hierarchy or efficiently controlling global

rollouts.

Implementation project Used to implement business processes in your SAP landscape

Maintenance project Used to control and document changes to the production systems (solutions)

Supported by the use of Change Request Management

Receives all maintenance activities and urgent corrections

Upgrade project Used to implement and document additional functions, or improve existing

functions that are associated with a current solution

3.1.2 Business Process Structure

SAP Solution Manager allows you to design business processes on the following three different levels:



CUSTOMER


Business process step

Usually related to a transaction, a background job, a Web UI, or similar system activity. Sometimes it makes

sense to document some activities within the business process flow as well. The business process step is the

most granular entity in business process definition and is assigned to a system where it is executed.

Business process

Collection of business process steps, grouped according to certain criteria, such as business content or SAP

modules combined to process chains.

Business scenario

Collection of business processes to be executed one by one resulting in the execution of an operational

procedure. Scenarios can be organized according to business unit, SAP module, or other kinds of grouping,

for example, template-related groupings.

3.1.3 Business Process Design

You can assign documentation to each of your business process steps. As such, your documentation must follow

the logical flow of each of the business process steps.

In general, there are many ways that business processes can be represented in SAP Solution Manager. However,

the best ALM integration can be achieved by applying an end-to-end design. For this, you can choose one of

methods depending on your organization's structure and assigned responsibilities, and which requirements have

been raised to business process handling in ALM.

End-to-End Processes

When designing end-to-end (E2E) business processes, you need to consider what the process will involve. This is

difficult when you first begin to create your business process documentation, and the problems usually occur

when considering organizational aspects, such as responsibilities, user access, and monitoring capabilities.

However, the E2E model shown in the following figure is the most reusable business process model for

documentation purposes, test capabilities, interface documentation, and business process monitoring.

Figure 5: End-to-End Process

16

CUSTOMER




Modular End-to-End Processes

If you want to organize your solution documentation according different modules, for example, business process

responsibility, maintenance activities, and projects, SAP recommends using another business process model. In

this model, you combine the business process steps present in different modular business processes, such as

purchase order processing and invoice processing, into one end-to-end business scenario. Although the E2E

business process in this model does not actively use each business process step in each modular business

process, each modular processes still plays an important role.

Figure 6: Modular E2E Process

3.1.4 Initial Documentation or Re-Documentation

Depending on your current setup, you need to decide whether to focus on initial documentation or re-

documentation of your business processes and the related solution landscape. This should be done before you

make any upgrades.

Using implementation projects correctly ensures appropriate solution documentation in the Run and Optimize

phases. If you begin documentation during the Run phase, you should re-document your core business processes

in SAP Solution Manager as well. Unlike a complete implementation project, with this method, you only need a

subset of information.



CUSTOMER


3.1.5 Solution Documentation Use Cases

The following use case scenarios show how you can manage Application Lifecycle Management in SAP Solution

Manager using a business process model approach. They also show how to manage documentation and test

capabilities. All cases are based on business process models. For more information on single use cases, see the

best practice document for Solution Documentation on the SAP Service Marketplace at

https://service.sap.com/alm.

The following three main use cases are available during the planning phase:

Use Case Advantages and Disadvantages

One project as single source

of truth

Advantage:

Simple architecture

Efficient testing

Technical and organizational flexibility

Disadvantage:

Less clear project and operations view

Lower transparency

Solution as single source of

truth

Advantage:

Full flexibility to document planned and current processes

Clear separation of planned and current processes and documentation

More governance enables you to control document changes

Integration with documentation and Change Request Managament

Disadvantage:

Increased manual effort

No reuse (regeneration) of test plans

Limited technical and organizational flexibility

Template as single source

of truth

Advantage:

Clear visibility and flexibility of planned and current processes and

documentation

More governance enables you to control document changes

Integration with documentation and Change Request Managament

Generation of template test plans

Disadvantage:

Increased manual effort

3.2 Build

The Build phase begins after you have defined a concept, chosen a solution documentation use case, and chosen

a method for maintaining the processes. In this phase, you fill the created projects with business processes and

https://service.sap.com/alm

18

CUSTOMER




enhance them with technical objects and documentation. All activities can be started from the central

Implementation and Upgrade work center, which is divided into the different project phases.

Maintaining content in the Solution Documentation Project is divided into two phases. In the first phase, the

business blueprint, scenarios, business processes, process steps, and attached executables, such as

transactions, are maintained along with the related project documentation. This structure can be used to sign-off

with the customer or business department. In the following phase, the configuration phase, the structures are

enhanced with technical objects, such as IMG-objects, Z-tables, and programs. In addition to the technical

objects, all necessary information for Test Management is added. Test cases, technical bills of material (TBOMs),

and transaction-automated test cases have to be maintained to ensure a proper test phase in SAP Solution

Manager.

To create this content, you can use one of the following methods:

Creating content manually

Scenarios, processes, and process steps are maintained during the blueprint phase. Later on, technical

objects and documents are added during the configuration phase of your project.

Reusing existing Documentation

o Business Process Repository (BPR)

BPR is a central pool of SAP standard processes

o SAP Templates and Roadmaps

SAP Templates and Roadmaps are a set of predefined processes and methodologies for different SAP

products and industry specific solutions

o Excel

You can upload of existing documentation maintained in a predefined Excel spreadsheet, which can be

used for processes, transactions, attributes, developments and configuration data

o Other projects

You can transfer existing information from projects within SAP Solution Manager

Using Reverse Business Process Documentation (RBPD)

Analysis of a currently running productive application with checks of executed transactions and used tables

The RBPD content was created as a strategic collaboration between SAP and IBIS. The RBPD analysis is

performed in the Solution Documentation Assistant. An RBPD analysis allows you to re-document your business

processes directly from your SAP systems. Re-documentation is completed by analyzing the current system

usage and is supported by comprehensive analysis content delivered by SAP. The content uses SQL statements,

which are executed on the database to check the existence of dedicated customizing and master data. The initial

analysis provides an overview of SAP standard processes being used on the managed system. For more

information, see the Service Marketplace in the Software Download Center for ERP, CRM, NetWeaver, Solution

Manager, and some industry solutions.

The RBPD analysis provides the following benefits:

Complete transparency regarding SAP application usage with the most important business processes

Comprehensive representation of the current implemented and used business processes

Quick and easy access to documentation for SAP standard business processes in SAP Solution Manager

Easy approach to creating a central basis for further ALM processes used for ALM topics like Test

Management

All maintained processes and documentation provided using the different creation methods can be expanded with

additional selection criteria. You can do this by using one of the following two options:

Keywords



CUSTOMER


Used in project internal structuring. Keywords, such as integration test relevant, can be assigned to processes

and documents.

Attributes

Used in project independent structuring. Multiple variants of attributes can be assigned to structures,

documents and technical objects. All attributes are handed over to follow-up projects

In addition to these project standards, there are further standards that need to be applied after being defined in

the Plan phase.

Document types used in the project to define templates and the behavior of the documents

Status values for processes, for example, in process, approval released, used to track the current level of

implementation

Status values and schemas for documents used to clearly track document changes

Roles and responsibilities for projects the different processes and documents are also important points. These

roles need to be defined during the Plan phase and assigned to all relevant objects. This allows you to reuse these

assignments with the key words and attributes during the run phase to easily track responsibilities and issue

reports.

3.2.1 Core and Mission-Critical Business Processes

The number of core business processes is typically very limited and can be adapted by enterprise departments.

Core business processes are the most important processes, which have a major impact on the company’s

business if they are disrupted.

Mission-critical business processes are new or technically challenging business processes, for example, which

require custom developments or non-SAP components that need to be administrated and monitored closely.

Documentation in SAP Solution Manager does not have to model every variant for each process step in detail. The

aim is to create an understandable structure containing relevant information that can be reused by other teams

and other application lifecycle capabilities.

3.2.2 Integration Scenarios

IT Project Management (cProjects).

Integrating SAP Solution Manager Projects and cProjects allows you to plan and manage projects in an IT

environment, using SAP Solution Manager functions.

You can improve your SAP Solution Manager projects with the project management capabilities in cProjects. You

can perform detailed project planning and structuring activities, manage resources, and hand over plans for

implementation. Time and status feedback allow you to monitor the progress and resource consumption of your

project.

You can use the project management functions in IT Project Management to manage, for example, project time,

resources, and status. SAP Solution Manager projects are linked to cProjects for technical operations. Requests

for change are also integrated with tasks in IT Project Management by integrating with Change Request

Management.

You can use the project management capabilities in cProjects to manage SAP Solution Manager projects. When

assigned, the cProjects is the leading project management tool, which replaces some SAP Solution Manager

20

CUSTOMER




project management functions. You can use this for implementation and maintenance. Data entered into IT

Project Management is mapped and transferred to an SAP Solution Manager project, and the SAP Solution

Manager project administration data entry capabilities are disabled to guarantee data consistency. The following

figure shows an overview of this integration:

Figure 7: IT Project Management Integration

Change Request Management

To manage any changes made in development systems, you can use the change request function. You can use

this function to perform maintenance work or for implementation and upgrade projects in your landscape.

Change Request Management provides functions that allow you to manage the following three main change

management processes:

Change Administration

Manage change requests, change categorization, approval workflow, and status reporting

Project Management

Manage project planning, project documentation, such as customizing changes or development

specifications, and test processes

Change Logistics

Make Customizing changes and implement developments, as well as manage transport scheduling, including

seamless integration with TMS, and transport tracking

Combining these three processes allows you to fully control any changes that you make to your landscape.

You can create a request for change for both business processes and business process steps. You can find

information about existing requests for change in both the business process structure and the change request

itself. This means that you can also find it in the relevant change documents in the Projects assignment block. As a

result, you can combine technical work with documentation tasks to link Change Request Management to



CUSTOMER


business process documentation directly. In this assignment block, you can also jump directly to the business

processes in the project. By doing this, you ensure that change-related documentation is always in sync with your

actual technical implementation.

Test Management

Test management processes depend entirely on your current business structure. However, they constantly

require and reuse any existing documentation about your landscape.

Solution documentation is used in the following areas to support test management:

Create TBOMs

Reuse structures, including transactions

Reuse keywords and attributes

Implement automatic and manual test cases

Structures, transactions, keywords, attributes, test cases, and TBOMs are the minimum documentation

requirements for test management.

SAP Solution Manager provides a range of tools to support you during testing. Depending on your system, you

can either create new business processes or verify the impact of any updates on your existing processes.

Figure 8: Test Management Integration

You need to create TBOMs if you want to use the Business Process Change Analysis tool. Technical bills of

material are containers that hold every table and object used by a certain business process step. You must create

TBOMs during the design and build phases of your implementation process. You compare TBOMs with future

upgrade or change transports to assess any impact on business processes. This information can be used for risk-

based test scoping and planning.

You can then begin to plan your test processes based on the information collected during the change impact

analysis.

Test plans are split into different test packages which are assigned to the related testers. During this planning

phase, you can reuse different keywords and attributes. For example, the keywords test relevant UAT and test

relevant regression, and the attributes for divisions and units within your enterprise. You need to create these

filters in your solution documentation before you can use them. Once you have defined them they will help you to

define the scope of your tests.

You then assign testers to test packages containing individual test cases and instructions on how to carry them

out. When performing the test, testers can jump directly to the correct transaction on managed systems provided

that you have previously assigned them in Solution Documentation.

Testers can find test documents in the Test Cases tab, in Solution Documentation. Here, you will not only find

manual tests but automatic tests, for example, eCATT or Component Based Test Automation (CBTA) scripts as

well.

All of this allows to reuse test cases different test types, rollouts, and releases. Solution Documentation serves as

the central platform for all test-related documents.

22

CUSTOMER




Custom Code Lifecycle Management

You use Solution Documentation to store documentation centrally. Therefore, customer transactions and custom

code need to be identified and maintained in the relevant business processes. First, you use Solution

Documentation Assistant to analyze your productive to create a list of used and unused Z-transactions and

reports. Used reports have to be assigned to the right business process to enhance your SAP Transaction

documentation.

For more information, see the SAP Standard for Custom Code Management.

Business Process and Interface Monitoring

Business process monitoring reuses business process structures after they have been moved to the operations

phase. After you have designed, developed, and tested your structures, you must ensure that core business

processes are running without any exceptions.

If you chose the solution as single source of truth solution documentation use case, you can monitor your

business processes. Otherwise, you need to create an additional solution. For more information on solution

documentation use case, see Solution Documentation Use Cases. Based on the processes in the underlying

systems, you can set up a wide range of monitoring processes. These include technical monitoring processes for

IDocs, QRFCs, and background jobs as well as business-related monitoring processes, such as the number of

overdue sales orders or deliveries.

The business monitoring objects allow you to improve these processes by identifying training and process design

gaps. If critical situations occur, you can alert the person responsible by email, SMS, or by reporting an incident in

SAP Solution Manager.



CUSTOMER


Figure 9: Business Process Monitoring Integration

You can prepare for business process monitoring integration during the design and build phases by defining and

maintaining attributes and priorities for all processes. This helps you to determine critical processes that you

need to monitor closely and attributes, like country, which can help to setup specific monitoring processes.

3.3 Run

Solution Documentation in SAP Solution Manager allows you to identify, add, or implement new or extended

business processes and technical information.

The information collected here constantly grows and is structured by the solution documentation in SAP Solution

Manager in a clear and comprehensible manner.

This chapter provides an overview of how to execute projects using SAP Solution Manager as a documentation

tool and the benefits of this information when reusing project data.

3.3.1 Handover and Maintenance

In the run phase, you focus on maintaining productive processes. After an initial setup, you have to hand your

documentation over to daily operations.

You can do this in one of the following ways:

Approach Description Tasks

Solution-based Hand over all data to this solution.

It serves as the single source of

truth for the entire landscape

Copy all processes from the

implementation projects into the

central solution via the Solution

Directory (Pull Method)

Create a new Solution based on an

existing documentation project

with the help of the “Copy Projects

and Solutions” available in the

Implementation & Upgrade work

center

Project-based Define the central documentation

project which serves as the single

source of truth in your landscape

Either the implementation project

is used as single source of truth

and is defined as productive after

the project phase ends or all

processes has to be copied into the

central documentation project

SAP recommends that you work according to team member assignments and status values attached to

processes. With the help of the process statuses, you can clearly see which processes are currently being

24

CUSTOMER




implemented and which are already finished and operating productively. When a process is marked as productive,

all documents and technical objects assigned to this process need to be up to date.

There are multiple ways of keeping your documentation up to date. One is way is to use Solution Documentation

Assistant regularly to check your processes against your current system usage. Another way is to define

organizational structures and roles, such as business process owners, who are responsible for each business

process, and note this in the administration tab.

A quality manager can also assist with, verify, and check processes and documents on a regular basis. Rules need

to be defined, for example, each process has to have a process description.

You can also integrate with Change Request Management to assign each change to a business process, in the

Service Message tab. This technical change also causes changes to documents. Therefore, every time a change is

assigned, the responsible person has to check the documentation and keep it up to date.

3.3.2 Reporting

Reporting allows you to maintain an overview of the current status of your documentation. You can use it during

both the plan and run phases to check processes, documents, and other objects. It is not based on bar, pie, or

stacked column charts like typical reporting functions. Instead, it focuses on retrieving the right objects from your

central documentation store.

You can access reporting directly in transaction SOLAR_EVAL or from the Reports navigation are, in the

implementation and upgrade work centers. In addition, the project phase specific transactions (for example

SOLAR01 for the Business Blueprint) allow you 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. If you are only related to parts of the project you can restrict the area where you want to

search with the help of keywords, attributes but also your assignment as a team member to certain business

processes. You can create standard analyses and save them as selection variants. All elements displayed in the

results can be called directly from the reporting output or you can jump into SOLAR01 (Blueprint) or SOLAR02

(Configuration) to the right process node. Therefore, SOLAR_EVAL is not only a reporting tool it is the general

access to your documentation.

3.4 Optimize

Improving your business process documentation allows you to improve the business processes themselves. To

do this you need to do the following:

Check documentation requirements with key users and business process champions

Improve your documentation concept, for example, by making adjustments to document handling processes

or using different project types

Regularly review documentation (quality assurance)

Change and update business process documentation

To ensure that you benefit from your documentation you need to make sure that it is kept up to date. Therefore, IT

staff should work closely with all documentation users adapt the documentation concept and processes to the



CUSTOMER


needs and requirements of all users, for example, by creating new documentation types and adjusting attributes

or status values. You must also establish a regular review process for all scenarios and processes.

It is difficult to apply concrete Key Performance Indicators to documentation. However there are some criteria

that you can use. For example, you can check the following:

All processes have a process description assigned

All process steps have an executable variant, for example, transaction or CRM WebUI

Test cases are assigned to all critical processes

Key attributes are assigned to all process nodes

Each process node has a responsible team member and status

The amount of documentation you have is not a good indicator of good documentation quality. You can only

ensure this by using a clearly defined process, for example, by not allowing document writers to release their own

documentation.

3.4.1 Solution Documentation Assistant

In SAP Solution Manager, the Solution Documentation Assistant helps to identify unnecessary transactions and

process steps to help you improve your documentation.

Solution Documentation Assistant verifies and rates customers’ business process documentation. It does so by

using data about how often technical objects related to the business process structure are used. Usage-frequency

provides an overview of potentially obsolete objects and makes mission-critical objects clear.

It is an excellent starting point for initial documentation or verification of existing documentation.

Scope

o Analyze the template, implementation, and maintenance projects

o Analyze usage of technical objects like transactions, reports, BADIs, and custom developments

o Analyze SQL statement to enable live system analysis from a business perspective

o Use existing SAP Solution Manager infrastructure, like system connections and technical statistical data

Benefits

o Accelerated initial solution documentation

o Enhanced solution and transparency of use

o Simple and fast system consolidation

o Improved business performance

o Standardized processes by making comparison of business processes at different locations

o Optimized test planning

o Cost-efficient documentation thanks to automated verification

26

CUSTOMER



Driving Continuous Improvement

4 Driving Continuous Improvement

This chapter focuses on improving the quality of your processes and is relevant for the CCOE's quality manager.

4.1 Quality assurance tasks

To ensure quality management, you need to perform the following key tasks:

Ensure identification of process exceptions and gaps

Ensure documentation of top issues, system landscape, and custom code

Include and align key aspects of solution documentation to business requirements

Ensure media-break reduction and establish a Singe Source of Truth

Identify of critical success factors

Identify of KPIs and benchmarking, for example, technical, quality, and business

Answering the following questions will help you to identify areas that need to be addressed:

Are core business processes documented?

Are solution landscapes and production systems documented?

How is your top-issue reporting defined?

Have you established quality gate management?

Have you created project documentation?

Which KPIs and scorecards do you use?

How do you execute and control SLA reporting?

How do you document and track change requests?

How do you ensure transport transparency?

Do you use an issue resolution database?

4.2 Quality Targets and KPIs

The following quality targets are important to the maturity of your solution documentation management and drive

value recognition of your IT department:

Reduce complexity and improve transparency and controllability of your IT environment

Accelerate documentation creation and reduce effort to increase efficiency

Increase reaction time to meet business requirements and business innovation

Clearly defined parameters and measurable objectives are required to assess the quality of your solution

documentation management processes. The key parameters should be collected and evaluated in regular

reports. Historical data created in this way can be used to identify trends and then derive the necessary

information.



CUSTOMER


The following table describes the main challenges for each of these quality targets and which KPIs can be used to

measure them:

Quality Target Challenges KPIs

Reduce complexity and improve

transparency and controllability of

your IT environment

Visibility

Lack of a consistent, unified

view of all critical assets

Not correctly using and

involving IT assets can affect

risk assessment results for, for

example, change requests.

Percentage increase in the time

it takes to resolve issues

following solution

documentation creation

Percentage of change requests

or transports causing incidents

with high business impact after

solution documentation in

place compared to before

Percentage of incidents or

complaints successfully

resolved within SLAs or by

using knowledge database;

Accelerate documentation creation

and reduce effort to increase

efficiency

Time consuming

documentation effort in terms

of cost for operation

Non-aligned documentation

sources especially lead to

increased complexity and

maintainability of updated

documentation

Missing or misleading

standards/guidelines for

documentation increase the

multitude of documentation

types, increasing the effort of

alignments and re-work

Implementing and following a

standardized methodology to

reduce the effort and costs for

maintaining your SAP

landscape and solution

implementation

Percentage of effort reduction

for project implementation

Number of tools available for

documentation (avoid media

breaks)

Frequency of documentation

reviews to ensure updated

Single Source of Truth

Frequency of guideline reviews

to ensure updates and

simplification

Ratio of critical business

processes documented to

overall critical business

processes to ensure

completeness of solution

documentation

Ratio of custom developments

documented according to SAP

Standard to overall custom

developments

Number of operation handbook

updates after go-live (t=0)

Increase reaction time to meet

business requirements and

business innovation

Demonstrating the benefit of

solution documentation with

the support of different tools

Consistent and uniform

documentation guidelines

Percentage of increased

reporting speed for

operational/compliance needs

Trend in manual report

creation

28

CUSTOMER




Quality Target Challenges KPIs

Standardize and simplify

business processes and

system infrastructure due to

increased transparency of all

subsidiaries

Streamline IT architectures

Harmonize data

Ensure optimized business

processes

Ensure automation, especially

in terms of reporting to

increase speed and reduce

effort

Trend in utilization of assets

Percentage of synergy effects

realized


Training

CUSTOMER


5 Training

SAP offers the following training courses relating to solution documentation:

SMI310 Implementation Projects with SAP Solution Manager

Goals

Understand the concept of SAP Solution Manager with the focus on supporting implementation (and

upgrade) projects based on SAP Best Practices

Explore tools, services, and methods in detail to successfully and efficiently implement complete software

solutions and new enhancements

Learn how to create a structured, comprehensive, standardized, and above all reliable collection of

information about all ongoing projects and the status of the productive SAP solution, which in turn is the basis

for informed, fact-based decisions and measures during the entire lifecycle of the solution.

Course Content

Explore the key concepts of SAP Solution Manager in the context of implementation projects based on SAP

best practices

Define a project and document the system landscape for the solution to be implemented

Design and document the business processes, including business requirements

Learn how to create business process variants

Configure business processes

Use the Document Management in SAP Solution Manager

Organize, perform and document all project-related test activities

Use roadmaps as the underlying project methodology

Explore reports to support project management activities

5.1 Expert Guided implementation Sessions

For Enterprise Support Customers, SAP offers Expert Guided Implementation Sessions (EGI).

Expert Guided Implementation (EGI) sessions are a combination of remote training, live configuration, and on-

demand expertise, which allow you to perform complex activities with the help of experienced SAP support

engineers. The instructor will demonstrate what to do step by step. Afterwards, you can perform the relevant

steps in your own version of SAP Solution Manager. If you have any questions, you can then contact an SAP

expert via phone or e-mail.

For Solution Documentation the following EGIs are available:

Expert Guided Session for Solution Documentation I

Expert Guided Session for Solution Documentation II

Expert Guided Session for Project Implementation

30

CUSTOMER



Training

More information regarding the content of the EGIs and time schedule can be found at the EGI calendar at

http://www.service.sap.com/~sapidb/011000358700001780312008E

Figure 10: Overview on the different EGIs in the different topic areas

http://www.service.sap.com/~sapidb/011000358700001780312008E


More Information

CUSTOMER


6 More Information

Documentation Link

Expert Guided Implementation information and

booking in SAP Service Marketplace

http://service.sap.com/expert-guided-implementation

Administering remote connection with SAP

Solution Manager

http://help.sap.com/saphelp_sm71_sp10/helpdata/en/2

8/9015dd452e48fabfb86098cda89e5b/content.htm?fra

meset=/en/45/51fbdbd4941803e10000000a1553f7/fra

meset.htm

Remote supportability https://support.sap.com/support-programs-

services/remote-support-component.html

Solution Documentation Assistant http://help.sap.com/solutionmanager71 Application

Help SAP Library Solution Documentation Solution

Documentation Assistant Work Center

Custom Development Management Cockpit http://help.sap.com/solutionmanager71 Application

Help SAP Library Solution Documentation Custom

Development Management Cockpit

http://service.sap.com/expert-guided-implementation

http://help.sap.com/saphelp_sm71_sp10/helpdata/en/28/9015dd452e48fabfb86098cda89e5b/content.htm?frameset=/en/45/51fbdbd4941803e10000000a1553f7/frameset.htm




https://support.sap.com/support-programs-services/remote-support-component.html

https://support.sap.com/support-programs-services/remote-support-component.html

http://help.sap.com/solutionmanager71

http://help.sap.com/solutionmanager71

www.sap.com/contactsap


No part of this publication may be reproduced or transmitted in any

form or for any purpose without the express permission of SAP SE

or an SAP affiliate company.

The information contained herein may be changed without prior

notice. Some software products marketed by SAP SE and its

distributors contain proprietary software components of other

software vendors. National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company

for informational purposes only, without representation or warranty

of any kind, and SAP or its affiliated companies shall not be liable for

errors or omissions with respect to the materials. The only

warranties for SAP or SAP affiliate company 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.

SAP and other SAP products and services mentioned herein as well

as their respective logos are trademarks or registered trademarks of

SAP SE (or an SAP affiliate company) in Germany and other

countries. All other product and service names mentioned are the

trademarks of their respective companies. Please see

www.sap.com/corporate-en/legal/copyright/index.epx for

additional trademark information and notices.

Material Number:

http://www.sap.com/corporate-en/legal/copyright/index.epx

E2e standard-for-solution-documentation

Data & Analytics

Transcript of E2e standard-for-solution-documentation