sap mm ebook

7/29/2019 Sap Mm eBook

http://slidepdf.com/reader/full/sap-mm-ebook 1/3

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 Practicesversions (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 on the CD tomake 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 canbe 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 onehand. On the other hand parts (scenarios, processes) that are not wanted in the new solution can not easily beremoved 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 yearsexperience with preconfigured industry- and cross industry solutions reusable parts of a solution were identifiedand encapsulated in Building Blocks according to a standard methodology that is drafted below. As a newparadigm, 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 andeCATT procedures or LSMW projects that allow modifying individual data and settings already during theinstallation process.

As a result, you find that the enclosed SAP Best Practices scenarios are set up by Building Blocks that can bereused flexibly in other scenarios or for the implementation of your own configuration project. Each of the BuildingBlocks contains all the information and deliverables that are required for the reuse independently from the SAPBest 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 informationcontent. No explicit instructions are possible here since a number of different influencing factors need to beregarded, 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 reusabilityfrom an implementation point of view. The content was mainly defined by making use of our long yearsexperience in creating preconfigured business solutions, to define identical reusable parts within the preconfiguredsolution 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 influencefactors described above are valid here as well. Since larger Building Blocks are normally more specific and thoughhave a reduced reusability we try to define them as small as reasonable (i.e. the additional efforts are justified bythe number of reuses). Larger entities like process groups or scenarios (that are representing Building Blocks aswell) are created by nesting smaller Building Blocks into larger ones. So a high level of transparency andreusability can be reached. Needless to say: With a higher nesting level you reach a higher level of functionalorganization connected to a higher potential for reuse and synergy on one hand. On the other hand the complexityand 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 on this HTML CD. Here you can browse through hundreds of Building Blocks withreference 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 notinclude the scenarios in this library, since the scenario is our central level of offering business content that can beaccessed directly from every SAP Best Practices version. Take the Building Block library as starting point to reusebusiness content different from the one you are evaluating with a particular SAP Best Practices version.



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 clearand easy rules. One of the most important rules is that every Building Block in principle has the same deliverablesas a Best Practices version, but all of these deliverables refer only to the content that is covered by the BuildingBlock itself. While nearly all Building Blocks have descriptions, installation roles, configuration roles, installationguides, configuration guides, some of the deliverables such as the Business Process Procedures might not beavailable 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 considerationsand should contain all information that refers to it. To ensure that all Building Blocks follow a similar andreproducible 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 thesequence they need to be applied. Here other Building Blocks can be nested if they represent apreparation step (for example the installation of the Organizational structure). The activities listed hereare a prerequisite for the Building Block, but are not a specific step for the functionality of the BuildingBlock. This differentiation is important to reduce complexity of Building Block set ups an will be explainedlater. A typical example is the organizational structure that is a prerequisite for a number of businesscontent related Building Blocks, but normally not specific for the business content like batch managementor returns processing.

After you installed a scenario or other business content (Building Blocks), some of the activitiesmentioned in this sections are already carried out and therefore do not need to be repeated for theinstallation of the next Building Block. If the structure defined for the activities in the preparation phaseis 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 thatthese installation activities are specific steps for the content of the respective Building Block, for examplebatch 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 onceit 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 allactivities 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 canassign objects that belong to them, for example the configuration documentation of a configuration step, a BC-Setthat 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-Setincluding variable parameters, and so on. Some of the objects might refer to a number of steps and thereforeneed to be assigned to a higher node like a hierarchical BC-Set that contains a number of single BC-Sets holdingthe 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 contentreferenced 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.



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 configurationdocuments assigned to the configuration steps.

Business Process Procedures combine the single steps given in the section Test & Use of the Development MasterList. 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 separatedfrom the details of the previous chapters. Creating a high number of small Building Blocks with differentpreparation steps might result in a complexity that is not manageable if no overlying concept exists. For the SAPBest Practices we make use of an elementary kind of the layer concept that is explained below. Other approachesare 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 separatedproperly into not-content-specific (Preparation ) and content-specific steps (Installation ). For details please see thedefinition 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 alarger number of Building Blocks, this layer now replaces a big number of preparation steps in all these BuildingBlocks. After one of these Building Blocks is installed, the installation of the layer can be skipped for the otherBuilding Blocks. So it is easy to combine Building Blocks and to identify remaining preparation steps for a BuildingBlock installation that are not covered by the layer settings without checking a very large number of singlesettings.

In the SAP Baseline Packages, you find this kind of approach by using the “Layer 0” as a common prerequisite forall the scenarios. Now you understand that for usability reasons it makes sense to define “Layer 0” as apreparation step for a particular Building Block even though “Layer 0” contains particular settings that might notbe required for a given Building Block.

The number of layers in the layer concept is not limited. Further layers for example could combine commonprerequisites 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 businesscontent, technical settings, information, etc. It is focused more on the implementation perspective than onbusiness modeling, but the business content delivered with SAP Best Practices can easily be set up by the BuildingBlocks. Even if the methodology is easy, the quality of the Building Blocks is dependent on the experience and skillof the development team as well as on the existence of an overall concept and the ability to identify patterns thatare valid for different configuration projects.

All delivered building blocks will be constantly improved.

sap mm ebook

Documents