asap methodology business blueprint.pdf

Project Name

ASAP Methodology Business Blueprint

CS STATUSinternal in progress

VERIFIER DATE PLACE VERSION

ASAP Methodology Business Blueprint.doc – 20.09.2010

Business Blueprint Concept

Allocator Name Company

Name Surname Company

Date Name Alteration Reason Version

dd.mm.yyyy Name Surname Creation 0.1

Table of Contents

1 Introduction 5

1.1 Management/Executive Summary 5

1.2 Basic Documents 6

1.3 Project Charter 6

1.4 Project Scope/Scope Document 7

1.5 Significant Changes to the Current Status 8

2 Business Processes Modeling 9

2.1 Cross Process related topics 9

2.1.1 Information Carrier Model 9

2.1.2 System Model 9

2.1.3 Organisational Model 9

2.1.4 Entity Model 9

2.2 Process Model Level 1, “Core and Support processes” <Name> 9

2.3 Process Model Level 2, “Process groups” <Name> 10

2.4 Process Model Level 3, “Business Process 1” <Name> 10

2.4.1 Short Description of the Process 10

2.4.2 Flow diagram 10

2.4.3 RACI or alternative written description (Roles and relation to process step, input, output, systems, business objects, quantities) 10

2.4.4 Linked Processes 11

2.4.5 Inputs (Event Triggers, entities, parameters) 11

2.4.6 Outputs (Process Results) 11

2.4.7 Business Requirements 11

2.4.8 Process specific User Roles & Requirements for the Authorization Concept 12

2.4.9 Quantification 12

2.4.9.1 Transaction and Data Volumes 12

2.4.9.2 Frequency of the Processes 12

2.4.10 Measurable KPIs 13

2.4.10.1 Status of KPIs before the Project 13

2.4.10.2 Target KPIs 13

2.4.11 Improvements to the Process Compared to As-Is Status 13

3 Solution Transformation 14

3.1 Cross Process related Topics 14

ASAP Methodology Business Blueprint.doc page 2/24


3.1.1 SAP Organizational Structure 14

3.1.1.1 Introduction “Organizational Unit” <Org Unit name> 14

3.1.2 Master Data Concept 14

3.1.3 High-Level Migration Concept 14

3.1.4 Roles 15

3.1.5 Business object model 15

3.1.6 Service model 15

3.2 Process Model Level 1, “Core and Support processes” 15

3.3 Process Model Level 2, “Process groups” 15

3.4 Business Process 1 15

3.4.1 Gaps in the Process Coverage by the SAP Standard 15

3.4.2 Identification of the Gaps 16

3.4.3 Solutions for the Gaps 16

3.4.4 Organizational Aspects 16

3.4.4.1 Compulsory Organizational Changes 16

3.4.4.2 Recommended Organizational Changes 16

3.4.4.3 Special Training Requirements 16

3.4.4.4 Binding Laws and Company-Specific Policies 17

3.4.5 Core configuration 17

3.4.5.1 Important Customizing Settings and their Purpose 17

3.4.6 Core enhancement 17

3.4.6.1 Permanent Interfaces 17

3.4.6.2 Migration Programs 18

3.4.6.3 Required Evaluations/Reports 18

3.4.6.4 Workflows 18

3.4.6.5 Forms/Print-Outs 18

3.4.6.6 Changes to the Program Code 18

3.4.6.7 Business objects 19

3.4.7 SOA / Composition 19

3.4.7.1 User/Interaction Business Components 19

3.4.7.2 Orchestrating Business Components and Services 19

3.4.7.3 Functional Business Components 19

3.4.7.4 Business Objects 19

3.4.7.5 Business Services 19

3.4.7.6 Process Component Mapping 19

3.4.8 Third party solutions 19

3.4.8.1 Overview of all relevant third party systems 19

3.4.8.2 Description of interfaces to third party solutions 20

4 High Level architecture / System landscape 21

4.1 Planned/After Go-Live 21

4.2 Actual/Before the Project Launch 21

4.2.1 Requirements for the Authorization Concept 21

4.2.2 Necessary IT Systems (Legacy Systems That Are Still Required) 21

4.3 Security Requirements 22

4.4 User and Identity Management 22

4.5 Development Environment / Development Tools 22



5 Glossary 23

Index of illustrations 23

Index of tables 23

References/Bibliography 23

Appendix A – Overview of Business Partners in Customer’s Departments 24

Appendix B – <Topic> 24



1 Introduction

Guidelines for Business Blueprinting: for use of this BBP Template see also Guideline including Dos

& Don’ts of a BBP concept (Link), and further the Presentation on Approach and Guidelines (Link,

3MB) for developing a Blueprint. This contains info on how to execute BBP workshops, involved project roles,

use of Solution Manager, etc.

Both are published on the PMO Homepage, section SR03_Mesthodology & Tools > 03_Guidelines

https://portal.wdf.sap.corp/go/de-pmo

Internal SAP note: The Business Blueprint Concept is a mandatory document in the project management

process of SAP Consulting. The Business Blueprint Concept should follow the structure defined in this

template. Optional sections are marked as such. Delete all template texts (colored in pink) before sending the

document. You can delete any indexes that you do not need.

In the introductory sections, explain what type of document it is, who the intended readership is, and how the

document is important in the context of the project as a whole. Do not include specific technical information or

information about specific cases here. The introduction should be about half a page long and never longer

than one page. The introduction is mandatory.

This document states all of the conceptual results of the project XPROJEKT. These project results were

devised and decided on by the project team and the department experts from customer XCUSTOMER

during the Business Blueprint project phase. This is the main concept document of the project. It is

supplemented by separate specifications for custom developments.

The content of this document forms the basis and the guidelines for the subsequent realization phase.

This document aims to describe the future business solution based on SAP software. Both IT subjects and

organizational issues that are required to understand the situation are described in it.

Any additional explanations that are only relevant when the project is in progress are given in the various

project management plan documents, which the project management team will provide on request.

The following authors contributed to the Business Blueprint Concept:

Name Specialist Area

Table 1 Overview of Authors

The contact persons in the customer’s departments are listed in the appendix.


https://portal.wdf.sap.corp/irj/servlet/prt/portal/prtroot/com.sap.km.cm.navigation/guid/e714c8fe-0201-0010-48be-97a6fc70f1a4

https://portal.wdf.sap.corp/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/guid/22bf2263-0501-0010-1385-85c750532d13

https://portal.wdf.sap.corp/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/guid/22bf2263-0501-0010-1385-85c750532d13


1.1 Management/Executive Summary

Give a very condensed summary of the business blueprint here. This section should give the reader a basic

overview of the key aspects. Focus more on process-related issues than technical aspects. The summary

should not be longer than three pages.

This is a mandatory section.

1.2 Basic Documents

Give references to important documents on which the business blueprint is based or quote from the most

important passages of these documents. This section generally should not be longer than two pages.

For large and complex projects, this section can easily become too long and unclear. In that case, only create

cross-references to the documents in the bibliography; do not quote from them (Insert Reference Cross-

reference).

This section is mandatory.

The following describes the foundations of the project work that affected the initial designs and concepts of

the project. The information here is a selection of the most important information. The complete information is

available on the shared project file server at \\Path\here\there\File.doc.

1.3 Project Charter

To understand the intention of the business blueprint, we need to know the overall goal of the project.

Therefore, a project charter is one of the documents created during the initiating project management phase.

State the essential information contained in the project charter in this section. Briefly and precisely present

the facts in the project charter on one page. This section is mandatory.

The project sponsor Mr. XXX ordered this project on xx.xx.200x.

The name of the project is XPROJECT.

The go-live of the project is scheduled for XX.XX.200x.

The internal sponsor is the XDEPARTMENT department. XCUSTOMER has named Ms. XNAME as its

project manager.

Additional external project employees from XCONSULTANTCOMPANY have also been hired.

The complete project charter is available on the project server at \\ddddd\XXXX\.

Example of how to state the project goal:

The project aims to harmonize the different financial accounting processes used in XCUSTOMER’s various

subsidiaries, thereby also unifying the different IT systems. The degree of automation should be as high as

possible.



Especially system XALT1 is to be replaced as soon as possible, so that the customer can save on the

associated licensing costs.

1.4 Project Scope/Scope Document

To provide the necessary context for the information contained in this document, refer to the document that

contains the detailed project scope (details, components, processes, users, functions, programs,

enhancements, and so on). The complete scope should be presented in this business blueprint concept.

Ideally, you should give a summary of the scope here and provide a reference to the document containing the

full details.

Although this can make some of the complete scope information redundant, this is only a summary and

should not cause any problems for readers. We feel that very few readers from other departments will be able

to judge the following content correctly if they do not have the necessary information about the project charter

and scope. Experience shows that most people do not read the referenced documents.


This section summarizes the project scope that was agreed between the customer and the contractor. This

scope goes beyond the tasks that the service provider XCONSULTANTCOMPANY has been assigned and

includes all project tasks that XCUSTOMER must complete internally for itself.

The scope is subject to a strict change procedure. The process for changing the scope is described in

\\ddddd\XXXX\.

To explain the scope as precisely as possible, several dimensions were chosen for examining the scope,

some of which may overlap: Specifically, the scope is examined in terms of the processes, IT functions,

technology, organization, method, and deliverables.

The highlights are (examples):

Processes:

- General ledger accounting, accounts receivables accounting, treasury

Functions:

- mySAP ERP 2004, component XX-XX and component XX-XY

Technology:

- Complete replacement of system XALT1

- Permanent interfaces to XALT2 and XALT3

- Connection of the new output management system XNEW1

- Creation of 7 new print forms

- No modifications, no extension programs

Organization:

- Preparation of a centralized accounting department for all subsidiaries, including the appropriate

training activities

Method:

- The project includes the training of 120 end users

- Project staff will provide support for the end users during the first 2 months after the go-live

The current version of the complete project scope is available at \\ddddd\XXXX\.



1.5 Significant Changes to the Current Status

In this section, state the project’s most significant changes (“impacts”) to the customer’s current processes,

company policies, and external factors. Later, these impacts can be used to determine which people need to

be addressed by change management (communication matrix). This section should be 1–2 pages long.

If the current status has been documented, refer to the relevant documents.

We especially want to recommend that specific agreements are made in advance with the customer’s

personnel or works council, because changes often require their consent and the agreement procedures can

be very time-consuming.

Make the size and importance of this section proportional to the size of the project.




2 Business Processes Modeling

2.1 Cross Process related topics

2.1.1 Information Carrier Model

2.1.2 System Model

2.1.3 Organisational Model

2.1.4 Entity Model

Present all processes that the business blueprint examines in a structured format using three process model

levels. Handle the processes according to the various criteria.

Often, the structured descriptions of processes on the lower levels contain process variants that only deviate

from the main process in minor details, but which can later affect subsequent processes. In such cases,

decide whether it makes sense to include the variants in the process model.

Some topics and information in the following subsections apply to several different processes (for example,

certain interfaces). We recommend that you begin with a complete description of the core process or

processes. For the following processes, you can refer back to this information instead of repeating it each

time (“see section xy”). The core process is the process that takes place most often or is the most important.

For example, this could be processes such as “sell from stock” or “receivables collection.”

SAP’s official terms for the different levels are, Business Scenario, Business Processes and Process Steps.

The decision to have three process levels was made to ensure compatibility with SAP Solution Manager,

which also maps these three levels.

Note that the following paragraphs can be entered manually or generated from the SAP Solution Manager

using the Business Scenario and Business Process templates for this purpose. The generated blueprint will

have to be inserted in this overall document on this place or as appendix.


2.2 Process Model Level 1, “Core and Support processes” <Name>

(Examples: External Accounting; Claims handling and Fulfillment)



The highest process level usually contains relatively generic business topics such as “external accounting,”

“sales,” and “human resources” which are more areas of the customer enterpise. Specifically in the logistics

area you will find here real business scenario variants like “Sales from Stock”.

This level is a mandatory section. There should be an introduction of each scenario process level. In a few

lines, give additional information:

Introduction, background, aim of the scenario process or enterprise area, people involved.

The major requirements for change, if any.

The major organizational impacts

The key decisions

The fit to the standard SAP functionality

Descriptions in the highest process model level often take the form of abstract lists, not topics that are

connected to each other like a flow diagram. Graphically, this is displayed as a collections of boxes that are

placed next to each other without any specific connections.

If there are > 1 individual topics on each level – copy the template sections for this.

2.3 Process Model Level 2, “Process groups” <Name>

(Examples: Perform Closing Operations; Notice of Loss by Letter or DME)

This process level forms the main body of the Business Blueprint and should be described in detail according

to the following chapters. The future (to-be) business environment should be described.

2.4 Process Model Level 3, “Business Process 1” <Name>

2.4.1 Short Description of the Process

In no more than half a page, give a summary of the process content to provide an introduction to the detailed

process descriptions that make up the main part of the blueprint concept.


2.4.2 Flow diagram

Diagram/graphic, mandatory.

2.4.3 RACI or alternative written description (Roles and relation to process step, input, output, systems, business objects, quantities)



2.4.4 Linked Processes

In this section, link the individual processes together. The way you illustrate this depends primarily on the

project’s complexity. You should preferably describe the situation in writing, focusing on the factual aspects.

(Why is there a link here? What triggers the switch from one process to another?) If you realize that your

description of the links is unclear, this may be a sign that the definitions of the processes could still be

improved. In that case, either rework the process definitions or make your description of the processes

clearer by showing the links between them in a table format. This section should not be longer than one page.

This section is mandatory. If there are no links between the process, state that this is the case.

2.4.5 Inputs (Event Triggers, entities, parameters)

Describe the triggers can that initiate each process. Be sure to give all relevant information and do not leave

out any important details. The description should be in the form of a short list. Later, this will be helpful when

creating test cases and variants. When subsequent checks are done, it must be checked whether all inputs

are also outputs of other processes.

Triggers can be system events as well as real-world events (such as “call from customer”). In particular,

describe the unusual triggers, not only the common ones that would occur in the perfect process flow. This

section should usually be 5-15 lines long.


2.4.6 Outputs (Process Results)

Describe the results of the process. Examples of results are: print forms (such as order confirmation), send

an e-mail, trigger a workflow.

Describe the output of the process in a few key points. This section should not be more than 1 page long,

including any explanations that are needed to understand the output.

This section is mandatory. If there is NO output, state this here.

2.4.7 Business Requirements

Describe the purpose that the specific process fulfills. Note that this description is not the same as the short

description of the process (section 5.2.1) and the description of the output (section 5.1.1.1.2.3.). Instead, it

should state from a wider perspective why the process is necessary; that is, which business requirements it

fulfills. Regardless of the size of the project, this description should not be more than 1 page long. In most

cases, you can give the necessary information on a half page if you write in note form.




2.4.8 Process specific User Roles & Requirements for the Authorization Concept

It is important that you clearly state the customer’s users and their future roles since this information is

needed for designing portal and authorization roles as well as for organizational change management

activities.

User Role Description of the Role Activities

Accountant Description (as precise as possible) Specific activities, tasks, transactions, etc. that are related to the user role

Call Center Employee

Warehouse Employee

This section should typically be about 5 lines long. This section is mandatory.

2.4.9 Quantification

Write a few lines as an introduction to the issue of volumes in this section. It is helpful if you state which

sources (people, departments, evaluations) the following information comes from. This introduction is

mandatory. The information section forms the basis for deciding on the priority of the respective processes

and how critical potential errors are.

2.4.9.1 Transaction and Data Volumes

Give an estimation of how often the process and the individual steps or transactions will be executed per unit

of time. This is only relevant for steps that already existed with the customer’s old systems. Avoid making

unfounded predictions, because this can cause legal liability problems. Make sure that any numbers that you

present were provided by the customer’s employees.

As an alternative to the question “how often does someone perform something?” you can also examine the

question “how many documents of what type are generated?” This can be a useful way of answering

questions about archiving and sizing. Also keep the aspects of data volumes and archiving in mind!

A list about 5 lines in length is sufficient in this section. This section is mandatory.

2.4.9.2 Frequency of the Processes

On average, how often is this process performed (per day/week/month/year)? Are there any seasonal

fluctuations? If the process has been created from scratch and there are no past experiences with it: How

often is the process expected to be performed? What effect does the frequency of this process have on the

archiving of which objects?

This section should be no more than half a page long. This section is mandatory.

Process Name Name of the Process



Frequency at Which the Process Takes Place

1 time per week, Friday afternoon Name the source: state if logged/estimated/expected

Data Volume That Is Transferred

x MB Per transaction

Table 2 Quantification of the Process Name of Process

2.4.10 Measurable KPIs

The following sections describe the KPIs for the project.

This section and its subsections are optional.

2.4.10.1 Status of KPIs before the Project

List the KPIs that were measured before the project. You must give detailed information about the sources of

these figures (systems, people, departments, dates).

You must also give very extensive descriptions of the circumstances under which the measurements were

performed. These circumstances should be described in at least 10-20 lines; the more precise, the better.

Descriptions for individual KPIs are also helpful.

This section is generally optional. However, if you specify target KPIs, you must always also state the old

KPIs and circumstances.

2.4.10.2 Target KPIs

Compare the KPIs before the project with the KPIs that are to be achieved by the end of the project.

2.4.11 Improvements to the Process Compared to As-Is Status

What improvements will the new processes cause? Also state benefits that cannot be quantified in the KPIs.

The best way to describe the advantages is to begin with the most important functions and processes that

have been changed and describe the benefits brought about by each of them.



3 Solution Transformation

3.1 Cross Process related Topics

3.1.1 SAP Organizational Structure

Explain the SAP organizational structure and units (clients, company codes, plants, and so on) that were

chosen for the project. We highly recommend using graphical illustrations to do so.

Note that body of this paragraph can be entered manually or generated from the SAP Solution Manager using

the Organizational Unit template for this purpose. The generated blueprint will have to be inserted in this

overall document. Each organizational unit will be described below. This section is mandatory.

3.1.1.1 Introduction “Organizational Unit” <Org Unit name>

This section will introduce the Organizational Structure Unit, it’s purpose and major characteristics for the

business..

3.1.1.1.1 Business Requirements

This section will describe the major requirements of the company in respect to this unit. This includes

financial, logistics, authorization and reporting requirements

3.1.1.1.2 Design Aspects

This section will describe the chosen design. It documents the relation between the SAP Organization

structure unit and companies business organization model; the consequences of the choices made and the

naming/coding conventions. This includes the consequences for the financial, logistics, authorization and

reporting concepts.

3.1.2 Master Data Concept

The master data concept should state all master data elements (material master, customer master, vendor

master, bill of material and so on) that will be needed to operate the software. For the master data, you must

describe which requirements there will be in terms of data maintenance and data transfer from the legacy

system. Also state which technical and business requirements there are with regard to harmonizing and

maintaining the master data. It is important that you define the organizational maintenance of master data

and specify the distribution concepts. This section is mandatory.

Note that this paragraph can be entered manually or generated from the SAP Solution Manager using the

Master Data template for this purpose. The generated blueprint will have to be inserted in this overall

document on this place.

3.1.3 High-Level Migration Concept

In this section, describe how the required master data and transaction data will be migrated from the old

system into the project’s new system(s). For example, it may be necessary to migrate customer masters,



material masters, accounting documents, or production orders. State which migration programs are required

for which master data and which transaction data, and any possible dependencies between the data. (For

example, a material master is necessary before any production orders can be created.) This section is

necessary in order to provide an overview of the additional programming effort that the project will require.

Most of these programs need to run stably in the Go-Live Preparation ASAP phase.

This section is mandatory. If there is no migration concept, state that this is the case.

3.1.4 Roles

3.1.5 Business object model

3.1.6 Service model

3.2 Process Model Level 1, “Core and Support processes”

3.3 Process Model Level 2, “Process groups”

3.4 Business Process 1

(Examples: Reconcile and Close Accounts; Process Incoming Paper Document)

The lowest process level describes the individual steps within a process. This is an optional level to describe

as a part of the Business Blueprint. Describing this level of detail will only be required if a very detailed

blueprint is required. (For example if another partner will perform the configuration of the system) Please

make sure this is discussed with the customer upfront in order to manage mutual expectations and to make

sure that the project schedule (and budget) is in line with this level of documenting the requirements and

solutions. If this level of detail is required, the Process Model Level 2 is only used as management summary.

3.4.1 Gaps in the Process Coverage by the SAP Standard

Describe any gaps where the SAP standard does not provide all necessary functions for the processes. State

the project’s general attitude towards additional programming and modifications: Are they prohibited/allowed/

desired and so on? Any more detailed information should be given in the relevant subsection.

Use a separate Excel spreadsheet to administer and track the modifications. This section is mandatory.



3.4.2 Identification of the Gaps

This is one of the most important sections of the process description. All gaps that are identified here must be

eliminated either by development work (possibly even modifications), workarounds (working around the gap

using organizational regulations), or by abandoning the process (if the development work would be too great

or the process is not important enough). In most cases, however, these considerations themselves cause

more effort (discussions with the customer about the necessity of the process, evaluation of the development

effort, change requests, risk evaluations, or recalculation of the project budget and schedule). Describe these

gaps meticulously, so that the project is as transparent as possible. This section is mandatory.

3.4.3 Solutions for the Gaps

Accepting solutions, workarounds, additional programs, and so on.

3.4.4 Organizational Aspects

The organizational aspects are described in detail in the follow sections.

3.4.4.1 Compulsory Organizational Changes

Explain the effects that the new processes will have on the customer’s organizational structure and

procedures. SAP products often require new activities that did not have to be performed before. These

activities must be allocated to an existing organizational unit. Alternatively, the customer should be

recommended to establish a new organizational unit. You should also state which old activities will be

eliminated.

It is also important that you state any new organizational directives that were defined for the project. For

example, these could be new value limits for releasing purchase orders or the instruction to employees to

perform specific checks at predefined intervals.

The length of this section can vary depending on the project. The main thing is to include all information that

is available.

If this project has organizational effects, this section is mandatory.

3.4.4.2 Recommended Organizational Changes

Which organizational changes to the current process are not absolutely necessary but are nevertheless

recommendable? (Give reasons: for example, shorten processes, save resources such as personnel or

materials, improve customer or supplier relationships.) Give a separate reason for each suggested change.

This section should be no more than one page long. This section is optional.

3.4.4.3 Special Training Requirements

State the process-related training requirements in this section. Which user groups need to be trained for this

process? How and by whom should the different user groups be trained? Are there any special training

requirements that are not directly related to the system? This section is not intended to replace the training

concept and the actual training plan. Instead, it should provide the basic information and topics with which a

training concept can be generated.



3.4.4.4 Binding Laws and Company-Specific Policies

List any laws, regulations, rules, and customer-specific policies that the process must adhere to. For

example, these could be quality aspects, the principle of dual control, documentation requirements, security

policies, and so on. It is sufficient if you provide a reference and an explanation.

This section should be a few lines long. This section is optional.

3.4.5 Core configuration

3.4.5.1 Important Customizing Settings and their Purpose

This subsection forms the bridge between the purely business-related considerations and the ways in which

they will be realized in the SAP system. It is important to find the right level of detail for this section.

Do not give specific instructions for customizing every IMG entry. Likewise, you should not list very long

customizing tables with > 50 entries here, except in very rare cases where it might be appropriate.

You should, however, state any important settings that were discussed and agreed upon in the business

blueprint phase. Include anything that is needed so that the processes function as required.

It is impossible to give an indication of how long this section should be. Roughly, it should make up no more

than 20% of the text in the entire process section. In this section, you must state precisely why each of

the customizing entries is to be made.


3.4.6 Core enhancement

List all developments that were deemed necessary by the analysis of gaps in the process coverage or which

are needed to support a given process. If there are any other types of custom developments that are not

addressed by the sections below, you can add them to the information in these sections. This section forms

the basis for the entire development effort for all processes in the project. To prevent making inaccurate

estimates of effort, make sure that your descriptions of the custom developments are very detailed.

Please note: The business blueprint document is also intended for use as documentation after the go-live.

Therefore, do not document any estimated effort for custom developments here. Also take note of the

information in section 6.11. This section is mandatory.

3.4.6.1 Permanent Interfaces

Also see section 4.1.1.1.7. (Legacy Systems That Are Still Required). An interface is anywhere where there is

a transfer from one system to another within a process. If this transfer is defined in the concept, it is a

permanent interface. The difference between permanent interfaces and one-off interfaces can be seen in the

level of detail with which they are described. With permanent interfaces, it is very likely that they will be

changed during the course of their life cycle (upgrades or patches). These interfaces therefore have to be of a



very high quality. The documentation also has to written in such a way that people who are not involved in the

project can understand it.

The permanent interfaces for a process are described in detail in this section. It can be up to 3 pages long.

This section is mandatory if there are permanent interfaces.

3.4.6.2 Migration Programs

Briefly describe the migration programs that are needed for this process. This includes one-time loading

programs and programs that initially generate data in the SAP systems based on algorithms, as well as

programs for data cleansing if data cleansing is planned.

Give a simple list with 2-5 lines of explanations for each entry. This section is mandatory.

3.4.6.3 Required Evaluations/Reports

List the evaluations and reports that occur in the process. State specifically why each evaluation/report is

needed. You can write this section in note form. This section is optional.

3.4.6.4 Workflows

List all workflows that are triggered in the course of the process. Describe in detail the purpose of each

workflow and which user groups or individual users it affects. Caution: “user” and “user groups” are used in

an abstract sense here. Do not write “the user Mr. Smith.” Instead, for example, write “order processor” or

“purchaser.”

This section is mandatory. If there are no workflows, state that this is the case.

3.4.6.5 Forms/Print-Outs

List all forms, correspondence, other print-outs, and outputs that are required in this process. Differentiate

between SAP standard forms and requirements for forms that involve new programming.

State which technologies are used (SAP Smart Forms vs. SAPscript) and/or the legacy systems that are

involved. For each form, write 2-5 lines. This section is mandatory.

3.4.6.6 Changes to the Program Code

In the following sections, the changes to the program code (source code) are described in detail.

Enhancements

Enhancements are any “permitted” changes or enhancements to the SAP source code. In other words: all

programming that would not cause more effort for a source code comparison when an upgrade, patch, or

release upgrade is performed. Individually describe each of the enhancements and its functionality in note

form. For enhancements, you do not necessarily have to explain why the source code is being changed – this

is optional.

This section is mandatory. If there are no enhancements, state that this is the case.



Modifications

Modifications are changes to the source code that cause additional effort during upgrades, patches, and

release upgrades. Modifications should be avoided whenever possible, because they require a more

intensive test phase and can cause unexpected side effects for the project. In live operation, modifications

cause a higher TCO and also threaten system stability. Just one modified line in the source code can cause

major problems.

In this section, describe all modifications to processes in writing (no coding!) and explain exactly why the

modifications are necessary.

This section is mandatory. If there are no modifications, state that this is the case.

3.4.6.7 Business objects

3.4.7 SOA / Composition

3.4.7.1 User/Interaction Business Components

3.4.7.2 Orchestrating Business Components and Services

3.4.7.3 Functional Business Components

3.4.7.4 Business Objects

3.4.7.5 Business Services

3.4.7.6 Process Component Mapping

3.4.8 Third party solutions

3.4.8.1 Overview of all relevant third party systems



3.4.8.2 Description of interfaces to third party solutions



4 High Level architecture / System landscape

4.1 Planned/After Go-Live

Describe the planned system landscape as it will be after the go-live. Explain the architecture that is planned

for live operation. You should mostly use graphical means of illustrating the architecture and you must include

the neighboring legacy systems.

This section is not about hardware or servers. Do mention permanent interfaces.

This section should be 1-2 pages long. This section is mandatory.

4.2 Actual/Before the Project Launch

Give a simple description of the actual system landscape as it is before the project launch. Do not include

clients, only mention systems and components. Do not include transport routes. Give a graphical overview of

the interfaces.

This section should be between half a page and 2 pages in length. This section is mandatory.

4.2.1 Requirements for the Authorization Concept

Explain any dependencies between this process and certain user roles or security levels. The dependencies

for the authorization concept that will be created are determined based on this information. In some cases,

certain processes will lead to new user roles being created.

Depending on the content of the process, this section can become very long. In that case, name the roles in

question and refer to another document that contains the full details. Generally, this section should not be

longer than 1 page.

This section is mandatory. Even if there are no requirements for the authorization concept, it is important that

you state that this is the case.

4.2.2 Necessary IT Systems (Legacy Systems That Are Still Required)

Sometimes, it is not possible to completely replace all legacy systems. In such cases, companies still need to

access their old systems. To do so, they have to use an interface, which must be described in the relevant

section of this document. Important information that must be in the section: What is the legacy system? How

will the interface to the legacy system be realized (manual, EDI, …)? How much longer will the legacy system

exist? How will the process change when the legacy system has been deactivated? Caution: Be sure to take

these legacy systems into account for data backups and the archiving concept.

This section should not be longer than one page. This section is optional.



4.3 Security Requirements

4.4 User and Identity Management

4.5 Development Environment / Development Tools



5 Glossary

In the Glossary section, explain the terms that you have used in the blueprint. Throughout the document, it is

important that you find the right balance in the terminology that you use: You do not want to explain too many

terms in the glossary, but you should also avoid using too much SAP-specific terminology that outside

readers will have difficulty with – and make sure that any such SAP terminology is explained in the glossary.

Keep in mind that the blueprint document belongs to the customer, who will still need to use it after the project

is finished – in fact this is often when the, document is used most.


Term Explanation

Index of illustrations

Index of tables

References/Bibliography

All sources, to which the text refers, are to be specified here, i.e. only one cross reference is inserted in the

appropriate place in the text. That means that no document name or something similar should appear in the

text. In order to keep the document visible and additionally simplify updating, the bibliography always has to

be at the end.

[1] Author Title File Name Company Date/Version

[2]



Appendix A – Overview of Business Partners in Customer’s Departments

List the business partners and their departments in the customer company – do not list individual discussions

or conversations about technical or business details.

Name Department

Appendix B – <Topic>

Write a few introductory sentences to explain the content of the appendix. The appendix should contain all

long, complicated texts that are not immediately essential for understanding the blue print. This introduction is

mandatory.
