Business Blueprint Concept

Project Name

ASAP Methodology Business Blueprint Concept

cSStatus

internalin progress

VerifierDatEPlaceVersion

AllocatorNameCompany

Name SurnameCompany

DateNameAlteration ReasonVersion

dd.mm.yyyyName SurnameCreation0.1

Table of Contents

1 Introduction32 Business Processes Modeling73 Solution Transformation124 High Level architecture / System landscape195 Glossary21 Index of illustrations21 Index of tables21 References/Bibliography21 Appendix A Overview of Business Partners in Customers Departments22 Appendix B 22

1 IntroductionGuidelines for Business Blueprinting: for use of this BBP Template see also Guideline including Dos & Donts 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-pmoInternal 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:

NameSpecialist Area

Table 1 Overview of AuthorsThe contact persons in the customers departments are listed in the appendix.

1.1 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.

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 Cross-reference).

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 XCUSTOMERs 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.

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\.

1.5 Significant Changes to the Current Status

In this section, state the projects most significant changes (impacts) to the customers 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 12 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 customers 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.

2 Business Processes Modeling2.1 Cross Process related topics2.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.

SAPs 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

(Examples: External Accounting; Claims handling and Fulfillment)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

(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 Process Model Level 3, Business Process 1

2.4.1 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 RACI or alternative written description (Roles and relation to process step, input, output, systems, business objects, quantities)

2.4.4 Linked Processes

In this section, link the individual processes together. The way you illustrate this depends primarily on the projects 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.

2.4.8 Process specific User Roles & Requirements for the Authorization Concept

It is important that you clearly state the customers 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 RoleDescription of the RoleActivities

AccountantDescription (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 customers 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 customers 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 NameName of the Process

Frequency at Which the Process Takes Place1 time per week, Friday afternoonName the source: state if logged/estimated/expected

Data Volume That Is Transferredx MBPer transaction

Table 2 Quantification of the Process Name of Process2.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.

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 This section will introduce the Organizational Structure Unit, its purpose and major characteristics for the business..3.1.1.1.1 Business RequirementsThis section will describe the major requirements of the company in respect to this unit. This includes financial, logistics, authorization and reporting requirements3.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 projects new system(s). For example, it may be necessary to migrate customer masters, 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 projects 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.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 AspectsThe 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 customers 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.

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 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.

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 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

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.

4.3 Security Requirements4.4 User and Identity Management4.5 Development Environment / Development Tools5 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.

TermExplanation

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] AuthorTitleFile NameCompanyDate/Version

[2]

Appendix A Overview of Business Partners in Customers Departments

List the business partners and their departments in the customer company do not list individual discussions or conversations about technical or business details.

NameDepartment

Appendix B

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.

ASAP%20Methodology%20Business%20Blueprint.doc 20.09.2010ASAP%20Methodology%20Business%20Blueprint.docpage 22/22