The document discusses SAP Best Practices Building Blocks, which are reusable parts of preconfigured solutions that have been encapsulated according to a standard methodology. Building Blocks can be flexibly combined to implement customized configurations. Each Building Block contains all necessary information and materials for independent reuse. They are defined based on implementation considerations rather than business modeling. The methodology involves defining the business content and structure of each Building Block, then assigning related documentation, technical objects, and other materials. Building Blocks can be layered based on common preparation steps to simplify reuse across multiple configurations.

1. SAP Best Practices Building Block Concept
Enhance Reusability and Flexibility of Preconfiguration
This document contains background information for the Building Block concept used in the SAP Best Practices
versions (including the Baseline Packages). The information provided should give you a first understanding of SAP
Best Practices Building Blocks that empowers you together with the other documentation you find in the
Documentation package to make full use of this new and flexible approach of re-using business content.
The Idea
Preconfigured solutions usually are the result of a nameable investment of time and money. This investment can
be leveraged by reusing it in other areas or for other solutions.
Reusing a complete solution is often difficult because of individual settings like the organizational structure on one
hand. On the other hand parts (scenarios, processes) that are not wanted in the new solution can not easily be
removed because of strong interdependencies with the remaining preconfiguration and/or master data.
The SAP Best Practices Building Block concept tries to overcome these limitations. Based on the long years
experience with preconfigured industry- and cross industry solutions reusable parts of a solution were identified
and encapsulated in Building Blocks according to a standard methodology that is drafted below. As a new
paradigm, the basis for the definition of the Building Block content is given mainly by implementation
considerations and less by the results of business modelling.
Where possible, this approach is complemented by the extensive use standard tools such as BC-Sets, CATT and
eCATT procedures or LSMW projects that allow modifying individual data and settings already during the
installation process.
As a result, you find that the enclosed SAP Best Practices scenarios are set up by Building Blocks that can be
reused flexibly in other scenarios or for the implementation of your own configuration project. Each of the Building
Blocks contains all the information and deliverables that are required for the reuse independently from the SAP
Best Practices Scenario.
The Methodology (Content Definition)
Business Content of Building Blocks
One of the most challenging tasks in creating a Building Block is to define its business, technical, or information
content. No explicit instructions are possible here since a number of different influencing factors need to be
regarded, such as the context of use, business area, and technical considerations, up to the very accurate
definition of the target group of the Building Blocks and organizational conditions of the development group.
As mentioned above, the main criterion for the content covered by SAP Best Practices Building Blocks is reusability
from an implementation point of view. The content was mainly defined by making use of our long years
experience in creating preconfigured business solutions, to define identical reusable parts within the preconfigured
solution and with a strict focus on its specification.
Size and nesting of Building Blocks
As for the business content, there is no clear rule for the size of a Building Block possible. A number of influence
factors described above are valid here as well. Since larger Building Blocks are normally more specific and though
have a reduced reusability we try to define them as small as reasonable (i.e. the additional efforts are justified by
the number of reuses). Larger entities like process groups or scenarios (that are representing Building Blocks as
well) are created by nesting smaller Building Blocks into larger ones. So a high level of transparency and
reusability can be reached. Needless to say: With a higher nesting level you reach a higher level of functional
organization connected to a higher potential for reuse and synergy on one hand. On the other hand the complexity
and administrational effort for the solution is rising. It is a very individual decision to find the right balance here.
Building Block Library
To have an orientation how Building Blocks might be defined just take our examples listed in the Building Block
Library that can be found in this HTML Documentation package. Here you can browse through hundreds of
Building Blocks with reference to the Industry/Country they are used. From the library, you can directly access the
Building Block description that summarizes the content of the Building Block. Although they are Building Blocks, we
did not include the scenarios in this library, since the scenario is our central level of offering business content that
can be accessed directly from every SAP Best Practices version. Take the Building Block library as starting point to
reuse business content different from the one you are evaluating with a particular SAP Best Practices version.

2. The Methodology (Creation of Building Blocks)
Once the content of a Building Block is defined as shown above, the creation of the Building Block follows clear
and easy rules. One of the most important rules is that every Building Block in principle has the same deliverables
as a Best Practices version, but all of these deliverables refer only to the content that is covered by the Building
Block itself. While nearly all Building Blocks have descriptions, installation roles, configuration roles, installation
guides, configuration guides, some of the deliverables such as the Business Process Procedures might not be
available where it makes no sense (like for the Organizational structure). Most of the deliverables are consolidated
along a defined structure composed by single steps as described in the next section.
Internal structure of a Building Block
In the chapters above you just learned that the Building Block is focuses mainly on implementation considerations
and should contain all information that refers to it. To ensure that all Building Blocks follow a similar and
reproducible structure we defined three phases that outline a kind of life-cycle for each Building Block:
1. Preparation
In this phase all activities that are a prerequisite for the installation of the Building Block are listed in the
sequence they need to be applied. Here other Building Blocks can be nested if they represent a
preparation step (for example the installation of the Organizational structure). The activities listed here
are a prerequisite for the Building Block, but are not a specific step for the functionality of the Building
Block. This differentiation is important to reduce complexity of Building Block set ups an will be explained
later. A typical example is the organizational structure that is a prerequisite for a number of business
content related Building Blocks, but normally not specific for the business content like batch management
or returns processing.
After you installed a scenario or other business content (Building Blocks), some of the activities
mentioned in this sections are already carried out and therefore do not need to be repeated for the
installation of the next Building Block. If the structure defined for the activities in the preparation phase
is designed in a reasonable way, it is easy to identify rapidly prerequisites that are already fulfilled.
2. Installation
In this phase nearly the same is valid as for the preparation phase listed above, with the exception that
these installation activities are specific steps for the content of the respective Building Block, for example
batch level definition for a Building Block Batch Management. A clear structure leads to a maximum of
transparency that makes it easy to understand what to do step by step to configure the functionality
covered by the Building Block. Of course nesting of Building Blocks is possible here as well.
3. Test & use
The activities listed in this phase are carried out to test and use the functionality of a Building Block once
it is installed. This might be steps of a process flow (e.g. transaction) or activities that make sure that the
configuration is properly up and running.
The result is a tree-like structure with the three highest nodes Preparation, Installation, Test & Use that contain all
activities that refer to the content of a Building Block in the order they are applied. This is the common principle of
all Building Blocks and the structure is pretty reproducible since it is determined by the objective constraints of
content and implementation.
Assignment of Documentation, Technical Objects and other Information to the Structure
The structure created above now holds all activities of the Building Block life-cycle. To these activities you can
assign objects that belong to them, for example the configuration documentation of a configuration step, a BC-Set
that holds the configuration settings of this configuration step, the SAP Best Practices transaction that calls the BC-
Set that holds the configuration settings, the installation instruction that describes the activation of the BC-Set
including variable parameters, and so on. Some of the objects might refer to a number of steps and therefore
need to be assigned to a higher node like a hierarchical BC-Set that contains a number of single BC-Sets holding
the configuration.
The result of such a structure with assigned objects, documents, deliverables, etc. you can see as the
Development Master List that is a mandatory deliverable of every Building Block.
Relation Building Block Structure – Building Block Deliverables
With the procedure described above we made sure to have everything in place that is related to the Building Block
and its content. The deliverables you get with the SAP Best Practices represent the consolidation of content
referenced in the Development Master List explained above.
Examples:
The installation role is the combination of all installation activities, the structure is determined by the structure of
the Development Master List.

3. The Installation Guide is the sequential collection of all installation documents assigned to the installation activities
(including preparation steps). The structure of this document (table of content) is determined by the structure of
the Development Master list as well. The very same applies for the configuration guide and the configuration
documents assigned to the configuration steps.
Business Process Procedures combine the single steps given in the section Test & Use of the Development Master
List. The same structure you find in the Test Catalogues of the Building Blocks (if any).
These examples can be continued. It is now easy to see how the Building Block deliverables represent the whole
or part of the structure evolved in the Development Master List.
Reusing Building Blocks and Conclusion
The considerations how to reuse and how to (re)combine Building Blocks to a solution can not seen separated
from the details of the previous chapters. Creating a high number of small Building Blocks with different
preparation steps might result in a complexity that is not manageable if no overlying concept exists. For the SAP
Best Practices we make use of an elementary kind of the layer concept that is explained below. Other approaches
are possible but not covered in this document.
Layer Concept
A prerequisite for the layer concept is that preparation and installation steps of a Building Block are separated
properly into not-content-specific (Preparation) and content-specific steps (Installation). For details please see the
definition of the internal structure of a Building Block above.
Now Building Blocks can be grouped according to identical preparation steps. This preparation steps can be
combined in Building Blocks that are forming a layer. Since this layer now represents the preparation steps of a
larger number of Building Blocks, this layer now replaces a big number of preparation steps in all these Building
Blocks. After one of these Building Blocks is installed, the installation of the layer can be skipped for the other
Building Blocks. So it is easy to combine Building Blocks and to identify remaining preparation steps for a Building
Block installation that are not covered by the layer settings without checking a very large number of single
settings.
In the SAP Baseline Packages, you find this kind of approach by using the “Layer 0” as a common prerequisite for
all the scenarios. Now you understand that for usability reasons it makes sense to define “Layer 0” as a
preparation step for a particular Building Block even though “Layer 0” contains particular settings that might not
be required for a given Building Block.
The number of layers in the layer concept is not limited. Further layers for example could combine common
prerequisites for manufacturing scenarios or common preparation steps for service scenarios.
Following the principle to keep things simple, complex constructions of layers should only be created if they are
justified by the complexity of the solution and manageable by the development team (skills).
Conclusion
The Building Block concept offers a flexible and easy to use methodology to create reusable parts of business
content, technical settings, information, etc. It is focused more on the implementation perspective than on
business modeling, but the business content delivered with SAP Best Practices can easily be set up by the Building
Blocks. Even if the methodology is easy, the quality of the Building Blocks is dependent on the experience and skill
of the development team as well as on the existence of an overall concept and the ability to identify patterns that
are valid for different configuration projects.
All delivered building blocks will be constantly improved.