Project Name
ASAP Methodology
Business Blueprint
CS
internal
VERIFIER
106751454 – 07.03.2016
DATE
STATUS
in progress
PLACE
VERSION
Business Blueprint Concept
Allocator
Name
Company
Name Surname
Company
Date
Name
Alteration Reason
dd.mm.yyyy
Name Surname
Creation
Version
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
106751454
page 2/24
Business Blueprint Concept
3.1.1 SAP Organizational Structure
3.1.1.1 Introduction “Organizational Unit” <Org Unit name>
3.1.2 Master Data Concept
3.1.3 High-Level Migration Concept
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
3.4.1 Gaps in the Process Coverage by the SAP Standard
3.4.2 Identification of the Gaps
3.4.3 Solutions for the Gaps
3.4.4 Organizational Aspects
3.4.4.1 Compulsory Organizational Changes
3.4.4.2 Recommended Organizational Changes
3.4.4.3 Special Training Requirements
3.4.4.4 Binding Laws and Company-Specific Policies
3.4.5 Core configuration
3.4.5.1 Important Customizing Settings and their Purpose
3.4.6 Core enhancement
3.4.6.1 Permanent Interfaces
3.4.6.2 Migration Programs
3.4.6.3 Required Evaluations/Reports
3.4.6.4 Workflows
3.4.6.5 Forms/Print-Outs
3.4.6.6 Changes to the Program Code
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
4.2 Actual/Before the Project Launch
4.2.1 Requirements for the Authorization Concept
4.2.2 Necessary IT Systems (Legacy Systems That Are Still Required)
4.3 Security Requirements
4.4 User and Identity Management
4.5 Development Environment / Development Tools
106751454
14
14
14
14
15
15
15
15
15
15
15
16
16
16
16
16
16
17
17
17
17
17
18
18
18
18
18
19
19
19
19
19
19
19
19
19
19
20
21
21
21
21
21
22
22
22
page 3/24
Business Blueprint Concept
5 Glossary
Index of illustrations
Index of tables
References/Bibliography
Appendix A – Overview of Business Partners in Customer’s Departments
Appendix B – <Topic>
106751454
23
23
23
23
24
24
page 4/24
Business Blueprint Concept
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. 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.
106751454
page 5/24
Business Blueprint Concept
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  Crossreference).
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.
106751454
page 6/24
Business Blueprint Concept
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 is mandatory.
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\.
106751454
page 7/24
Business Blueprint Concept
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.
This section is mandatory.
106751454
page 8/24
Business Blueprint Concept
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.
This section is mandatory.
2.2
Process Model Level 1, “Core and Support processes” <Name>
(Examples: External Accounting; Claims handling and Fulfillment)
106751454
page 9/24
Business Blueprint Concept
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
2.4.1
Process Model Level 3, “Business Process 1” <Name>
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.
This section is mandatory.
2.4.2
Flow diagram
Diagram/graphic, mandatory.
2.4.3
106751454
RACI or alternative written description (Roles and relation to process step, input,
output, systems, business objects, quantities)
page 10/24
Business Blueprint Concept
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.
This section is mandatory.
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.
This section is mandatory.
106751454
page 11/24
Business Blueprint Concept
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
106751454
Name of the Process
page 12/24
Business Blueprint Concept
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.
106751454
page 13/24
Business Blueprint Concept
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,
106751454
page 14/24
Business Blueprint Concept
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.
106751454
page 15/24
Business Blueprint Concept
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.
106751454
page 16/24
Business Blueprint Concept
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.
This section is mandatory.
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
106751454
page 17/24
Business Blueprint Concept
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.
106751454
page 18/24
Business Blueprint Concept
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
3.4.7
Business objects
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
3.4.8.1
106751454
Third party solutions
Overview of all relevant third party systems
page 19/24
Business Blueprint Concept
3.4.8.2
106751454
Description of interfaces to third party solutions
page 20/24
Business Blueprint Concept
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.
106751454
page 21/24
Business Blueprint Concept
4.3
Security Requirements
4.4
User and Identity Management
4.5
Development Environment / Development Tools
106751454
page 22/24
Business Blueprint Concept
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.
This section is mandatory.
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]
106751454
page 23/24
Business Blueprint Concept
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.
106751454
page 24/24