Project Name

ASAP Methodology Business Blueprint

CS

STATUS

internal
VERIFIER DATE

in progress
PLACE VERSION

57926576.doc – 20.09.2010

Business Blueprint Concept

Allocator

Name Name Surname

Company Company

Date dd.mm.yyyy

Name Name Surname

Alteration Reason Creation

Version 0.1

Table of Contents
1 Introduction 5 1.1 Management/Executive Summary 6 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
57926576.doc page 2/24

2 Orchestrating Business Components and Services 3. “Core and Support processes” 3.8 Third party solutions 3.7.4.7.1.5 Business Services 3.4.4.6 Process Component Mapping 3.1.4.3 Required Evaluations/Reports 3.1.8.4 Business Process 1 3.5.6 Changes to the Program Code 3.4.4 Business Objects 3.4 Roles 3.1.4.4.4.3 Security Requirements 14 14 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 20 20 21 21 21 21 21 22 57926576.4.1 Gaps in the Process Coverage by the SAP Standard 3.4.1 Planned/After Go-Live 4.3 Functional Business Components 3.4.4 Binding Laws and Company-Specific Policies 3.2 Process Model Level 1.7.4.Business Blueprint Concept 3 Solution Transformation 3.1.1 User/Interaction Business Components 3.6.4.4.5 Core configuration 3.3 Solutions for the Gaps 3.4.1 Compulsory Organizational Changes 3.4.1 Cross Process related Topics 3.4.4 Workflows 3.2 Description of interfaces to third party solutions 4 High Level architecture / System landscape 4.4.1 Permanent Interfaces 3.6.4.4.7 SOA / Composition 3.1.1 SAP Organizational Structure 3.4.7.7.4.5 Forms/Print-Outs 3.2 Actual/Before the Project Launch 4.4.3 High-Level Migration Concept 3.1 Requirements for the Authorization Concept 4.1 Introduction “Organizational Unit” <Org Unit name> 3.7.4.1 Overview of all relevant third party systems 3.4.1.1 Important Customizing Settings and their Purpose 3.4.6 Core enhancement 3.6.8. “Process groups” 3.4.2 Recommended Organizational Changes 3.2 Identification of the Gaps 3.5 Business object model 3.2.4.6.6.4.4.2 Migration Programs 3.2 Necessary IT Systems (Legacy Systems That Are Still Required) 4.4.2 Master Data Concept 3.6.6.4.doc page 3/24 .3 Special Training Requirements 3.6 Service model 3.2.1.3 Process Model Level 2.7 Business objects 3.4 Organizational Aspects 3.

5 Development Environment / Development Tools 5 Glossary Index of illustrations Index of tables References/Bibliography Appendix A – Overview of Business Partners in Customer’s Departments Appendix B – <Topic> 22 22 23 23 23 23 24 24 57926576.Business Blueprint Concept 4.doc page 4/24 .4 User and Identity Management 4.

3MB) for developing a Blueprint. Both are published on the PMO Homepage. In the introductory sections. You can delete any indexes that you do not need.corp/go/de-pmo Internal SAP note: The Business Blueprint Concept is a mandatory document in the project management process of SAP Consulting. The introduction should be about half a page long and never longer than one page.doc page 5/24 . use of Solution Manager. The introduction is mandatory. explain what type of document it is. This contains info on how to execute BBP workshops. 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. who the intended readership is. Both IT subjects and organizational issues that are required to understand the situation are described in it.sap. This document states all of the conceptual results of the project XPROJEKT. This is the main concept document of the project. 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. Optional sections are marked as such. Do not include specific technical information or information about specific cases here. 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. 57926576. Delete all template texts (colored in pink) before sending the document. etc. The Business Blueprint Concept should follow the structure defined in this template.wdf. 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. section SR03_Mesthodology & Tools > 03_Guidelines  https://portal. and further the  Presentation on Approach and Guidelines (Link.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). involved project roles. and how the document is important in the context of the project as a whole. It is supplemented by separate specifications for custom developments.

In that case. Therefore. This section is mandatory. The information here is a selection of the most important information. XNAME as its project manager. a project charter is one of the documents created during the initiating project management phase.200x. This section generally should not be longer than two pages. The name of the project is XPROJECT. State the essential information contained in the project charter in this section.200x.XX.3 Project Charter To understand the intention of the business blueprint. The internal sponsor is the XDEPARTMENT department. XCUSTOMER has named Ms. 1. This is a mandatory section. do not quote from them (Insert  Reference  Crossreference). Example of how to state the project goal: The project aims to harmonize the different financial accounting processes used in XCUSTOMER’s various subsidiaries.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. The complete project charter is available on the project server at \\ddddd\XXXX\. this section can easily become too long and unclear. For large and complex projects. This section is mandatory. 57926576. This section should give the reader a basic overview of the key aspects. The complete information is available on the shared project file server at \\Path\here\there\File. Focus more on process-related issues than technical aspects. Additional external project employees from XCONSULTANTCOMPANY have also been hired.Business Blueprint Concept 1. The go-live of the project is scheduled for XX. thereby also unifying the different IT systems. The project sponsor Mr. we need to know the overall goal of the project. The summary should not be longer than three pages. only create cross-references to the documents in the bibliography. XXX ordered this project on xx.xx.1 Management/Executive Summary Give a very condensed summary of the business blueprint here. The following describes the foundations of the project work that affected the initial designs and concepts of the project. 1. Briefly and precisely present the facts in the project charter on one page.doc page 6/24 .doc. The degree of automation should be as high as possible.

users. several dimensions were chosen for examining the scope. some of which may overlap: Specifically. and so on). you should give a summary of the scope here and provide a reference to the document containing the full details. technology.4 Project Scope/Scope Document To provide the necessary context for the information contained in this document. programs. method.The project includes the training of 120 end users .General ledger accounting. component XX-XX and component XX-XY  Technology: . and deliverables. organization. The scope is subject to a strict change procedure. no extension programs  Organization: .Business Blueprint Concept Especially system XALT1 is to be replaced as soon as possible. IT functions. This section summarizes the project scope that was agreed between the customer and the contractor.Creation of 7 new print forms . so that the customer can save on the associated licensing costs. 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.Complete replacement of system XALT1 . The process for changing the scope is described in \\ddddd\XXXX\. refer to the document that contains the detailed project scope (details. To explain the scope as precisely as possible. Although this can make some of the complete scope information redundant. functions. including the appropriate training activities  Method: . 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.mySAP ERP 2004. The highlights are (examples):  Processes: .Preparation of a centralized accounting department for all subsidiaries. treasury  Functions: . 1.Connection of the new output management system XNEW1 .doc page 7/24 . accounts receivables accounting. Experience shows that most people do not read the referenced documents.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\. This section is mandatory. components. 57926576. processes.Permanent interfaces to XALT2 and XALT3 . the scope is examined in terms of the processes. Ideally. enhancements. The complete scope should be presented in this business blueprint concept.No modifications.

5 Significant Changes to the Current Status In this section. Later.doc page 8/24 . This section is mandatory. because changes often require their consent and the agreement procedures can be very time-consuming. If the current status has been documented. these impacts can be used to determine which people need to be addressed by change management (communication matrix). refer to the relevant documents. and external factors. state the project’s most significant changes (“impacts”) to the customer’s current processes. Make the size and importance of this section proportional to the size of the project.Business Blueprint Concept 1. We especially want to recommend that specific agreements are made in advance with the customer’s personnel or works council. This section should be 1–2 pages long. 57926576. company policies.

The core process is the process that takes place most often or is the most important. The generated blueprint will have to be inserted in this overall document on this place or as appendix. For example. This section is mandatory. For the following processes. Often.Business Blueprint Concept 2 2. Handle the processes according to the various criteria. In such cases. The decision to have three process levels was made to ensure compatibility with SAP Solution Manager. Business Scenario.doc page 9/24 .2 System Model 2.1 Information Carrier Model 2. Business Processes and Process Steps. We recommend that you begin with a complete description of the core process or processes. Claims handling and Fulfillment) 57926576.” SAP’s official terms for the different levels are.3 Organisational Model 2. which also maps these three levels.4 Entity Model Present all processes that the business blueprint examines in a structured format using three process model levels. Some topics and information in the following subsections apply to several different processes (for example.1. but which can later affect subsequent processes.2 Process Model Level 1. 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. “Core and Support processes” <Name> (Examples: External Accounting.1.1.1. this could be processes such as “sell from stock” or “receivables collection. decide whether it makes sense to include the variants in the process model. you can refer back to this information instead of repeating it each time (“see section xy”). certain interfaces).1 Business Processes Modeling Cross Process related topics 2. 2. the structured descriptions of processes on the lower levels contain process variants that only deviate from the main process in minor details.

The future (to-be) business environment should be described.3 RACI or alternative written description (Roles and relation to process step. 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.doc page 10/24 . Flow diagram 2. There should be an introduction of each scenario process level. give additional information:      Introduction. 2. not topics that are connected to each other like a flow diagram. Specifically in the logistics area you will find here real business scenario variants like “Sales from Stock”.” “sales. The major requirements for change. 2. mandatory.1 Short Description of the Process In no more than half a page.3 Process Model Level 2. systems. “Business Process 1” <Name> 2. input. if any. business objects.4. 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. Graphically. aim of the scenario process or enterprise area. this is displayed as a collections of boxes that are placed next to each other without any specific connections.Business Blueprint Concept The highest process level usually contains relatively generic business topics such as “external accounting. background.” and “human resources” which are more areas of the customer enterpise. If there are > 1 individual topics on each level – copy the template sections for this. output.4 Process Model Level 3.4. This section is mandatory. quantities) 57926576.4. “Process groups” <Name> (Examples: Perform Closing Operations. This level is a mandatory section. 2. 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 Diagram/graphic. people involved. In a few lines.

1) and the description of the output (section 5.5 Inputs (Event Triggers. Be sure to give all relevant information and do not leave out any important details. 2.doc page 11/24 .1. it should state from a wider perspective why the process is necessary. Instead. Note that this description is not the same as the short description of the process (section 5.6 Outputs (Process Results) Describe the results of the process. this will be helpful when creating test cases and variants.2.1. describe the unusual triggers. This section should not be more than 1 page long. This section is mandatory. If there are no links between the process. Triggers can be system events as well as real-world events (such as “call from customer”). In that case. This section should not be longer than one page.4. it must be checked whether all inputs are also outputs of other processes. 2. The way you illustrate this depends primarily on the project’s complexity. trigger a workflow. 2. parameters) Describe the triggers can that initiate each process. link the individual processes together. Examples of results are: print forms (such as order confirmation). In most cases. (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. entities. This section is mandatory. When subsequent checks are done.4. You should preferably describe the situation in writing. including any explanations that are needed to understand the output.4.4 Linked Processes In this section. If there is NO output. either rework the process definitions or make your description of the processes clearer by showing the links between them in a table format. Later. which business requirements it fulfills. 57926576. not only the common ones that would occur in the perfect process flow. This section should usually be 5-15 lines long. focusing on the factual aspects. Regardless of the size of the project.1. send an e-mail.Business Blueprint Concept 2.7 Business Requirements Describe the purpose that the specific process fulfills. Describe the output of the process in a few key points.4. you can give the necessary information on a half page if you write in note form.2. state that this is the case.). The description should be in the form of a short list. In particular. state this here. that is. This section is mandatory. this may be a sign that the definitions of the processes could still be improved. this description should not be more than 1 page long.3. This section is mandatory.

This section is mandatory. transactions. because this can cause legal liability problems.9. 2.4. Also keep the aspects of data volumes and archiving in mind! A list about 5 lines in length is sufficient in this section. Avoid making unfounded predictions.4.4.9 Quantification Write a few lines as an introduction to the issue of volumes in this section. Make sure that any numbers that you present were provided by the customer’s employees. 57926576. This section is mandatory.8 Concept Process specific User Roles & Requirements for the Authorization 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. 2. This section is mandatory. 2.4. The information section forms the basis for deciding on the priority of the respective processes and how critical potential errors are. etc. User Role Accountant Description of the Role Description (as precise as possible) Activities Specific activities.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.doc page 12/24 . It is helpful if you state which sources (people. 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. tasks. 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. that are related to the user role Call Center Employee Warehouse Employee This section should typically be about 5 lines long.Business Blueprint Concept 2. departments. This introduction is mandatory.2 Frequency of the Processes On average. This is only relevant for steps that already existed with the customer’s old systems. evaluations) the following information comes from.

You must also give very extensive descriptions of the circumstances under which the measurements were performed. the better. 2. 2.10. Friday afternoon x MB Name the source: state if logged/estimated/expected Per transaction Table 2 Quantification of the Process Name of Process 2.Business Blueprint Concept Process Name Frequency at Which the Process Takes Place Data Volume That Is Transferred Name of the Process 1 time per week. This section is generally optional. dates). if you specify target KPIs. This section and its subsections are optional. 2.10 Measurable KPIs The following sections describe the KPIs for the project. You must give detailed information about the sources of these figures (systems. However.1 Status of KPIs before the Project List the KPIs that were measured before the project. Descriptions for individual KPIs are also helpful. 57926576.2 Target KPIs Compare the KPIs before the project with the KPIs that are to be achieved by the end of the project. the more precise.doc page 13/24 .4. These circumstances should be described in at least 10-20 lines.4. people.4.4. departments.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. you must always also state the old KPIs and circumstances.10. 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.

1. The generated blueprint will have to be inserted in this overall document.1.1. plants. it’s purpose and major characteristics for the business. This section is mandatory. company codes. Also state which technical and business requirements there are with regard to harmonizing and maintaining the master data.doc page 14/24 . Note that this paragraph can be entered manually or generated from the SAP Solution Manager using the Master Data template for this purpose.2 Master Data Concept The master data concept should state all master data elements (material master. For the master data.1. 3. For example. logistics. you must describe which requirements there will be in terms of data maintenance and data transfer from the legacy system.1 3. 3. The generated blueprint will have to be inserted in this overall document on this place.3 High-Level Migration Concept In this section.1 Business Requirements This section will describe the major requirements of the company in respect to this unit.. We highly recommend using graphical illustrations to do so. logistics. bill of material and so on) that will be needed to operate the software. and so on) that were chosen for the project.1. describe how the required master data and transaction data will be migrated from the old system into the project’s new system(s).Business Blueprint Concept 3 3. 3.1. This includes financial. It is important that you define the organizational maintenance of master data and specify the distribution concepts. it may be necessary to migrate customer masters. vendor master.1. customer master. 57926576. Each organizational unit will be described below.1 Introduction “Organizational Unit” <Org Unit name> This section will introduce the Organizational Structure Unit. This includes the consequences for the financial. 3.1 Solution Transformation Cross Process related Topics SAP Organizational Structure Explain the SAP organizational structure and units (clients. It documents the relation between the SAP Organization structure unit and companies business organization model.1. 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.2 Design Aspects This section will describe the chosen design.1. This section is mandatory.1. the consequences of the choices made and the naming/coding conventions. authorization and reporting concepts.1. authorization and reporting requirements 3.

4. If this level of detail is required.) This section is necessary in order to provide an overview of the additional programming effort that the project will require.2 Process Model Level 1. Process Incoming Paper Document) The lowest process level describes the individual steps within a process. Use a separate Excel spreadsheet to administer and track the modifications. (For example. If there is no migration concept. “Process groups” 3. This section is mandatory. “Core and Support processes” 3. Describing this level of detail will only be required if a very detailed blueprint is required. 3.doc page 15/24 .1.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.6 Service model 3.1.3 Process Model Level 2. Most of these programs need to run stably in the Go-Live Preparation ASAP phase.1.4 Business Process 1 (Examples: Reconcile and Close Accounts. This section is mandatory. (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. 57926576.4 Roles 3.5 Business object model 3. or production orders. accounting documents. a material master is necessary before any production orders can be created. This is an optional level to describe as a part of the Business Blueprint. the Process Model Level 2 is only used as management summary. and any possible dependencies between the data.Business Blueprint Concept material masters. 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. 3. State which migration programs are required for which master data and which transaction data. state that this is the case.

In most cases. workarounds (working around the gap using organizational regulations). This section is mandatory. 3. Alternatively. 3. If this project has organizational effects.4.3 Solutions for the Gaps Accepting solutions. All gaps that are identified here must be eliminated either by development work (possibly even modifications).Business Blueprint Concept 3. or recalculation of the project budget and schedule). improve customer or supplier relationships. workarounds.4. These activities must be allocated to an existing organizational unit. The length of this section can vary depending on the project. so that the project is as transparent as possible. these considerations themselves cause more effort (discussions with the customer about the necessity of the process.4. these could be new value limits for releasing purchase orders or the instruction to employees to perform specific checks at predefined intervals. SAP products often require new activities that did not have to be performed before.2 Recommended Organizational Changes Which organizational changes to the current process are not absolutely necessary but are nevertheless recommendable? (Give reasons: for example. change requests. It is also important that you state any new organizational directives that were defined for the project. or by abandoning the process (if the development work would be too great or the process is not important enough). For example.2 Identification of the Gaps This is one of the most important sections of the process description.4. additional programs.4. The main thing is to include all information that is available.1 Compulsory Organizational Changes Explain the effects that the new processes will have on the customer’s organizational structure and procedures. save resources such as personnel or materials. 3.4. This section should be no more than one page long.4 Organizational Aspects The organizational aspects are described in detail in the follow sections. this section is mandatory. Describe these gaps meticulously. 3. risk evaluations. evaluation of the development effort. shorten processes. You should also state which old activities will be eliminated. 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 57926576.4. however. 3. the customer should be recommended to establish a new organizational unit.) Give a separate reason for each suggested change.4.3 Special Training Requirements State the process-related training requirements in this section.4. and so on. This section is optional.doc page 16/24 .

and so on. it should provide the basic information and topics with which a training concept can be generated. 3. 3.4. Include anything that is needed so that the processes function as required. Therefore.5. it should make up no more than 20% of the text in the entire process section.4. This section is optional. 3. these could be quality aspects.7.1. Also take note of the information in section 6.doc page 17/24 . For example.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. This section forms the basis for the entire development effort for all processes in the project. This section is mandatory.1.1 Permanent Interfaces Also see section 4. regulations. and customer-specific policies that the process must adhere to. If this transfer is defined in the concept. To prevent making inaccurate estimates of effort.11. 3. 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. except in very rare cases where it might be appropriate. it is a 57926576. This section is mandatory. You should.4 Binding Laws and Company-Specific Policies List any laws. Roughly.4. It is important to find the right level of detail for this section.4.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. state any important settings that were discussed and agreed upon in the business blueprint phase. you can add them to the information in these sections. An interface is anywhere where there is a transfer from one system to another within a process. rules. security policies.1. the principle of dual control. Do not give specific instructions for customizing every IMG entry. documentation requirements. you should not list very long customizing tables with > 50 entries here. This section should be a few lines long. In this section.6. do not document any estimated effort for custom developments here.5 Core configuration 3. you must state precisely why each of the customizing entries is to be made. however.4.4. It is impossible to give an indication of how long this section should be.Business Blueprint Concept concept and the actual training plan. Likewise. If there are any other types of custom developments that are not addressed by the sections below. (Legacy Systems That Are Still Required). Instead. It is sufficient if you provide a reference and an explanation.

3. Give a simple list with 2-5 lines of explanations for each entry.6.doc page 18/24 . State specifically why each evaluation/report is needed.6. This section is mandatory. correspondence. state that this is the case. For each form. Individually describe each of the enhancements and its functionality in note form.6 Changes to the Program Code In the following sections. it is very likely that they will be changed during the course of their life cycle (upgrades or patches).4. For enhancements. for example. State which technologies are used (SAP Smart Forms vs. 3.6. This section is mandatory if there are permanent interfaces.6. Describe in detail the purpose of each workflow and which user groups or individual users it affects.6. Enhancements Enhancements are any “permitted” changes or enhancements to the SAP source code. you do not necessarily have to explain why the source code is being changed – this is optional. 3. This section is optional. The difference between permanent interfaces and one-off interfaces can be seen in the level of detail with which they are described. The documentation also has to written in such a way that people who are not involved in the project can understand it. 3.4.Business Blueprint Concept permanent interface.5 Forms/Print-Outs List all forms.4. The permanent interfaces for a process are described in detail in this section. This section is mandatory. With permanent interfaces. Do not write “the user Mr. 3. or release upgrade is performed. If there are no workflows.4 Workflows List all workflows that are triggered in the course of the process. patch. This includes one-time loading programs and programs that initially generate data in the SAP systems based on algorithms. 57926576. and outputs that are required in this process. as well as programs for data cleansing if data cleansing is planned. write 2-5 lines.” Instead. In other words: all programming that would not cause more effort for a source code comparison when an upgrade. Differentiate between SAP standard forms and requirements for forms that involve new programming. the changes to the program code (source code) are described in detail. These interfaces therefore have to be of a very high quality. write “order processor” or “purchaser.” This section is mandatory.4. Smith. other print-outs. You can write this section in note form. SAPscript) and/or the legacy systems that are involved.4.2 Migration Programs Briefly describe the migration programs that are needed for this process. It can be up to 3 pages long. Caution: “user” and “user groups” are used in an abstract sense here.3 Required Evaluations/Reports List the evaluations and reports that occur in the process.

8 Third party solutions 57926576.4. describe all modifications to processes in writing (no coding!) and explain exactly why the modifications are necessary. Modifications Modifications are changes to the source code that cause additional effort during upgrades.1 User/Interaction Business Components 3. Just one modified line in the source code can cause major problems. If there are no modifications.4. and release upgrades.6 Process Component Mapping 3. state that this is the case.7. In live operation.4.7 SOA / Composition 3.4.6.3 Functional Business Components 3.5 Business Services 3.Business Blueprint Concept This section is mandatory. 3. patches.4.7.7 Business objects 3. because they require a more intensive test phase and can cause unexpected side effects for the project.7.4 Business Objects 3.7.7.doc page 19/24 .4.7. In this section.4. modifications cause a higher TCO and also threaten system stability. state that this is the case.4. Modifications should be avoided whenever possible.4. This section is mandatory.2 Orchestrating Business Components and Services 3. If there are no enhancements.

2 Description of interfaces to third party solutions 57926576.Business Blueprint Concept 3.1 Overview of all relevant third party systems 3.8.4.8.4.doc page 20/24 .

2 Necessary IT Systems (Legacy Systems That Are Still Required) Sometimes. certain processes will lead to new user roles being created. This section is optional. This section is not about hardware or servers. In some cases. 57926576.Business Blueprint Concept 4 4. Important information that must be in the section: What is the legacy system? How will the interface to the legacy system be realized (manual. In such cases. this section can become very long. Do mention permanent interfaces. it is not possible to completely replace all legacy systems.1 Requirements for the Authorization Concept Explain any dependencies between this process and certain user roles or security levels. To do so.1 High Level architecture / System landscape Planned/After Go-Live Describe the planned system landscape as it will be after the go-live. You should mostly use graphical means of illustrating the architecture and you must include the neighboring legacy systems. 4. it is important that you state that this is the case. Even if there are no requirements for the authorization concept. 4. This section should not be longer than one page. name the roles in question and refer to another document that contains the full details. This section should be between half a page and 2 pages in length.doc page 21/24 . Do not include clients. Depending on the content of the process. 4. The dependencies for the authorization concept that will be created are determined based on this information. which must be described in the relevant section of this document. Give a graphical overview of the interfaces. This section should be 1-2 pages long. This section is mandatory. This section is mandatory. only mention systems and components. companies still need to access their old systems. In that case.2. This section is mandatory. Do not include transport routes. EDI. they have to use an interface. …)? 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. Explain the architecture that is planned for live operation. this section should not be longer than 1 page.2.2 Actual/Before the Project Launch Give a simple description of the actual system landscape as it is before the project launch. Generally.

3 Security Requirements 4.4 User and Identity Management 4.5 Development Environment / Development Tools 57926576.doc page 22/24 .Business Blueprint Concept 4.

who will still need to use it after the project is finished – in fact this is often when the.doc page 23/24 . Throughout the document. In order to keep the document visible and additionally simplify updating. [1] [2] Author Title File Name Company Date/Version 57926576. explain the terms that you have used in the blueprint. This section is mandatory. document is used most.Business Blueprint Concept 5 Glossary In the Glossary section. i.e. 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. only one cross reference is inserted in the appropriate place in the text. Keep in mind that the blueprint document belongs to the customer. to which the text refers. Term Explanation Index of illustrations Index of tables References/Bibliography All sources. the bibliography always has to be at the end. That means that no document name or something similar should appear in the text. are to be specified here.

complicated texts that are not immediately essential for understanding the blue print.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. This introduction is mandatory.doc page 24/24 . The appendix should contain all long. 57926576. Name Department Appendix B – <Topic> Write a few introductory sentences to explain the content of the appendix.

Sign up to vote on this title
UsefulNot useful