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 on the CD 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 on this HTML CD. 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. 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. I nternal 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. I nstallation 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 I nformation 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. 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.