1      Management summary

The purpose of the business blueprint document is to present the results, findings and conclusions of the blueprint finalization phase of the SAP project. This document consists of:

  • The business process requirements of Company within the scope of SAP;
  • The specification for the SAP system to support these target business processes;
  • The detailed work-plan to design the SAP system and business processes.

SAP poject phase overview:

Setup and Scoping –> Blueprint  –> Core System –> Core System –> Implementation
Scoping                        finalization      realization           construction

Document status

This blueprint document supersedes all other prior documentation defining the project, scope and products. To ensure the quality of this document, the deliverable of the previous phase (set-up and scoping) and the recommendations of the gate review of this phase have been taken into account.


The scope, objectives and approach for the project are set out in the results of the previous phase. The particular objectives for the blueprint finalization phase were to develop a well-defined vision on the future way of working, outlined in functional requirements of the improved business processes. These requirements have been detailed in order to realize the development of the core system in the next project phase.

This document reflects the results of the blueprint finalization phase on a high level. To get insight on a detailed level, reference is made to the attached appendices.


Within the SAP project, business processes are decomposed into the following


  • Domains that represent a major activity or resource of the enterprise and can map distinctive enterprise activities (e.g. Management Accounting);
  • Subjects representing a natural subdivision of an enterprise concentrating on a major activity or resource of the enterprise. A subject consists of a highly cohesive grouping of processes that are required by the enterprise to achieve goals and objectives (e.g. actual cost allocation);
  • Facets representing a process chain that is a group of linked elementary processes that produce an outcome (e.g. activity allocation).

During the previous phase, Project Set Up and Scoping, three major domains were defined, Financial Accounting, Management Accounting and Materials Management.

In this phase, subject & facets have been worked out in further detail till the lowest level, which is the elementary process.

For each subject the following topics have been described:

  • What is in/out of scope of SAP?
  • What are the consequences for Company?
  • What is the organizational impact?
  • What are the controls?
  • What are the open issues/ discussion topics for the Gate review?

Activities performed

The blueprint finalization phase effort was concentrated in three major areas of activity. Throughout the current business processes were reviewed until consensus was reached or the business process owners made decisions.

  • The first and most visible area was the development of the business process design in the domains Materials Management, Financial Accounting and Management Accounting. The teams have conducted a series of workshops and subsequent reviews to reach agreement within their teams.
  • The second area focused on Data Management, planning the migration of the SAP data structures, and developing the approach for interfaces with the existing systems and conversion strategies for systems replaced by SAP Release-1.

Key issues

The following key issues have been identified and are still unresolved:

  • The structure of Cost Center and Internal Order may change.
  • Company internal procedure for Purchase Requisitions needs to be reviewed to comply with the SAP PR approval procedure.  Currently, Company approves purchase requisitions on total level, whereas in SAP, Company will need to approve purchase requisitions on line item level.

Next Steps

The focus of the next phase (Core System Realization) is to complete the training of the end users involved in Integration and User Acceptance Tests and to specify changes to legacy systems, data migration, etc.


  • Apart from some details to be discussed, the SAP business blueprint has been finalized.
  • Project is ready to start the next phase, the Core System Realization.

2      The Enterprise Model

2.1      Enterprise Model – Introduction

The Enterprise Model is a process decomposition of the Company business within the scope of SAP, providing a mechanism for mapping of business processes with enterprise data, organizational structure and the supporting IT landscape.  It provides a framework for defining the scope of SAP against the Company Enterprise, thereby supporting commonality of processes and highlights the link of AP to other Company critical success factors.

The Enterprise Model is based on the following principles:

  • The model represents the Company “To-Be” processes to be adopted within Company sites
  • The model is a top-down decomposition of Company’s business processes
  • The model is cross-functional and the process models are independent of the organization
  • The model does not assume any existing IT solutions are in place

This section within the Site Business Blueprint is intended to summarize issues and change considerations against the Enterprise Model, highlighting kernel changes required to fit the site business requirement at Elementary Process level.

2.2      Business scenarios

Business Scenarios are used to combine all the elementary processes of the Enterprise model with all their variants in a pragmatic business solution.

These are used for:

  • Validating the scope
  • Integration test scenarios
  • User acceptance testing
  • Input for the work instructions
  • Input for the administrative and organizational procedures

The project team has identified the business scenarios in scope in Gap Definition.

The table shows in summary the scenarios, gaps that have been identified in the previous phase and the way of working in SAP:

ID Scenario Area In Scope? Gap? Gap Reference
B1 Purchase of materials to valuated stock MM
B2 Purchase of goods for direct consumption MM
B3 Purchase of services MM
B5 Purchase via Delivery Schedules MM
B7 Purchase without Purchase Requisition (Rush order) MM
B13 Vendor managed inventory (non-consignment) MM
B14 Vendor managed inventory (consignment) MM
B15 Framework Orders MM
B16 Return Deliveries to suppliers MM
B19 Subcontracting for (semi-)finished products MM
B20 IM Unplanned Goods Movements MM
B21 Forecasting & MRP MM
B23 IM Physical Inv & Cycle Count MM
B35 Maintaining master data MM
B43 Quality Inspection MM
B47 Purchase of equipment (instalment payment) MM
B48 Supplier evaluation MM
B49 WM Movements MM
B50 WM Physical Inv & Cycle Count MM
B52 Request for Quotation – Proposal – Information MM
B53 Outline Agreements MM
B54 managed consignment stock MM
B25 Forecasting CO
B26 Actual cost/ revenue allocation CO
B27 General ledger accounting FI
B28 Accounts payable FI
B29 Handling fixed assets FI
B32 Month-end closing FI
B37 Counterclaim handling CO
B38 GSA handling CO
B39 Sector allocation handling CO
B34 Year-end closing FI
B35 Maintaining master data FI
B36 Internal Order Handling per type CO
B42 Accounts receivable FI
B45 Handling capital investments CO


3      Reporting

3.1      Reporting Definition

Key Strategy

  • All reports that can be generated from SAP will be generated from SAP.
  • It is not the expectation that all reports will come out of SAP (normally limited to data available in standard SAP R/3 or imported data via interfaces to legacy systems).
  • Standard SAP R/3 reports will be used without modifications where the information contained in the reports meets business requirements.
  • Most standard SAP reports have the possibility to drill-down to the underlying documents. For example, the purchase order (PO) history can be displayed within the PO. In the PO history an overview is shown of all the goods receipts and invoice receipts. Then on the goods receipt it is possible to drill down to the original document and financial posting.
  • Any modifications to standard reports will need to be economically justified based on improvement in efficiency and/or effectiveness and have to be approved by the SAP Project Management.
  • Where possible users will generate and view reports online.
  • All SAP generated internal reports will be common.
  • SAP generated external documents (customer statement, purchase orders etc.) will be common. The standard design can be adapted to meet local requirements during rollout.

General reporting requirements

In general we defined 4 categories of business reports:

  1. Operational reports

All kinds of lists needed to manage the daily operations; for instance a list of open orders, receipts, purchase requisitions, etc.

  1. Management reports

For Management to control / steer the day to day business; for instance an overview of commitments, capital expenditure, projects

  1. Strategic reports

For Management to enable decision making; for instance trends, analysis, high level overview

  1. Fiscal / legal required reports

To meet local fiscal and or legal requirements; for instance tax or customs reports

The following table lists the current reports as required by Company on SAP. Nevertheless there may be other reporting requirements, e.g. local legal/fiscal requirements or internal Management reports which may be deemed to be necessary to develop on SAP using Standard and/or Technical Reporting Tools (ABAP) or may be maintained externally using data downloaded/extracted from SAP.

It must be stressed that the objective is to minimize all additional reporting outside of standard SAP Reports, Standard Report Variants/Layouts and current Kernel developed reports.

4      Application Landscape, Interfaces & Data conversion

4.1      Domains, systems and interfaces SAP kernel

All domains that were described earlier in this document are summarized in the following picture.

SAP modules in Release-1 (seen from the point of view of a site) support the colored parts of the domains below. The processes within these domains are also supported.

Domain Data Management covers the maintenance of basic data. Some of the basic data, like material master pricing data, are maintained in systems (Prime/Spine) and will be interfaced with SAP.

Financial modules of SAP will be the functional backbone for the domains Management Accounting and Financial Accounting.  Pricing of semi finished goods and finished goods will still be done in Legacy ERP. Some local/national systems (for tax reporting, time writing, forecasting) will remain and must be interfaced. For consolidation and reporting purposes corporate systems will be used, these systems will get their input from SAP.

SAP will cover a major part of needed functionality to support processes within the Supply Base Management domain.

Inventory and Warehouse Management for Raw materials is completely covered by SAP Release-1. Legacy systems will need to exchange information on orders, goods movements and stocks of these materials.

For (semi-) finished and finished goods the management of inventory is done in legacy systems. Financial impact of the goods movements of (semi-) finished products will be interfaced between legacy systems and SAP. This requires some basic data maintenance for these goods in SAP Release-1.

Quality Management of raw materials is done in SAP Release-1 if the materials are stored in SAP, as far as needed by the sites. Quality Management of semi finished goods and finished goods are not included in SAP Release-1.

Order Handling and Shipping will be covered by legacy systems in SAP Release-1. Financial information of the sales transactions of (semi-) finished products will be interfaced between legacy systems and SAP. This requires some basic data maintenance for (internal) customers.

Domains Material Requirements Planning, Production Scheduling & Control will be completely out of scope for Release-1 except for planning of spares. But interfaces with legacy systems supporting these domains are necessary.

Human Resource Management, Supply Chain Management and Shop Floor Control are not part of SAP; systems to support processes within these domains will remain unchanged, except for some interfaces with SAP.

It will be clear after this description of domains that after implementation of SAP Release-1 a number of legacy systems and corporate systems will still exist. Most of these systems will be interfaced with SAP, and there also will remain interfaces between legacy systems.

5      Appendices