EA Foundation

Turning Strategy into Execution

EA Foundation
SAP BI Blueprint
V2.0
12/03/2009

SAP Roadmap

Document Unique ID
File Name
EA Foundation Programme SAP BI
Blueprint v2.0.ppt

Date
09/03/2008

Issuer

Reviewed by

Paul Tennyson / Mark

Owen

Paul Chilton

Purpose of this document

This document sets out the Blueprint and Roadmap for reporting and analytics
based on SAP systems using the SAP Business Intelligence (BI) component.

It positions SAP BI in the context of the overall Enterprise Information

Management Blueprint as defined in the EA Foundation Programme.

It provides Architectural guidance in the following ways:

High level standards to guide identification of the appropriate reporting tool

against requirements

A definition of the target architecture and associated roadmap for SAP BI to be

used as part of ERP governance

SAP BI: Background

Information Exploitation in the SAP context relates to the usage of the Reporting and
Analytics capabilities of SAP. Reporting has always been a component of SAP, initially
provided through the use of SAP-standard and custom report programs within the R/3
system itself. However, the main reporting and analytics engine for SAP is now SAP
Business Intelligence (BI, formerly Business Warehouse, BW).
Currently AZ has 4 major SAP BI or BW systems associated with SAP instances:

Smaller instances (e.g. Portugal) also exist but are regarded as standalone and not
considered within the Architecture.
Like the transactional systems the BW instances have not been implemented with any
standardisation in mind so there is no commonality designed into the systems.
BW activities should be defined and included in ERP roadmap

The minimum strategy would be to adopt a do nothing approach to BW, but as a minimum even
this would require identification of maintenance-driven upgrade requirements (BW 3.5 end of
standard maintenance Mar 2010, extended maintenance 2013)

However, changes in the SAP BI landscape are imminent that make it worth developing a
more coherent approach to this component and considering adoption of standardised
ways of working:

EBS
ICON
NAM
AsiaPac

Possible introduction of a Global BI to support Supply Chain

Ongoing Regional consolidation of transactional systems meaning the BI has the potential to
become a common reporting engine for the business with a greater degree of standardisation.
The acquisition of Business Objects by SAP and the future direction within SAP to integrate the
SAP Business Objects and BI product set.

Content

The content of this document is divided into a number of main sections,

following a structure defined by the main headings of the TOGAF
wheel:

Architecture Vision
Requirements and principles setting out the overall context and groundrules for
the target architecture

Business Architecture
Sets out the scope and strategy for SAP BI in relation to reporting against Level 2
process areas in the METIS model

Information Systems Architecture and Technology Architecture

Defining the target architecture and standards relating to the use of the SAP BI

Opportunities and Solutions

Setting out the roadmap activities

Positioning SAP BI in relation to the EIM theme

Usage of SAP BI is positioned in the context of Enterprise Information Management (EIM) across AZ. The
EA Foundation EIM theme defines a framework for this, based on a set of building blocks, each of which
identifies a component of the Architecture.
Not all of these are relevant to the SAP BI area. Those which are directly relevant are highlighted below.

Access Search &

Delivery

Business
Intelligence

Information Asset
Management

Enterprise Data
Management

Enterprise Content
Management

Enterprise
Portals

Enterprise Perf.
Management

Info Lifecycle
Management

Data
Warehousing

Document
Management

Enterprise
Search

Operational BI

Information
Security

Master Data
Management

Web Content
Management

Mobile Device
Access

Predictive
Analytics

Metadata &
Taxonomy Mgmt

Data Integration

Collaboration &
Knwldg Capture

Workflow Info
Management

External Data
Standards

Records, IP
Mgmt, Contracts

Access
Monitoring

Data Quality
Improvement

ERP Doc Mgmt

Integration

Data Centre
Management

Data Migration

Digital Asset
Management

Info System
Useability

Architecture
Vision

EIM building block definitions and relevance to SAP

Architecture
Vision

The following table reproduces the Building Block definitions from the EIM
theme summary, with some additional commentary to relate it to the SAP
context.

EIM Building Block

EIM definition

SAP context

Enterprise Performance
Management

Provides a set of processes to help optimise business

performance via a framework for organising, automating and
analysing methodologies, metrics, processes and systems that
drive business performance.

Decision Support Reporting from SAP BI:

Summarised data across one or more dimensions
Reporting across extended time periods
Trend / history reporting
Planning, forecasting and modelling

Operational BI

Provides a mechanism to be able to accurately manage the

business to make fact-based analytical decisions. Key enablers
are techniques for defining Key Performance Indicators (KPIs),
Critical Success Factors (CSFs), predictive modelling and
historical trend analysis.

Operational Reporting from SAP BI:

Snapshot, short-term status reporting
Exception reporting

Data Warehousing

Provides an approach for delivering a Datamart, an Enterprise

Data Warehouse or variants of these systems that are more
departmentally-focused, operational in nature or applicationspecific.

Use of the SAP BI data warehouse back-end systems.

Data Integration

Provides the supporting processes to allow access to and the

combination of data residing at different sources, to provide the
user with a unified view of these data.

Use of extractors and ETL tools for populating SAP BI from SAP R/3 and
ECC, and other data sources.

Information

reported at the transactional level

Architecture
Vision

Architecture Vision - Principles

Enterprise Information Management Architecture Principles:

The following Principles are extracted from the EIM Theme Summary. They are reproduced below with a discussion of the
SAP BI implications.

EIM Principle Description

SAP implication

Information should be provided where possible as a service, as part of a Service Orientated

Architecture approach.

SAP SOA capability is addressed in the SAP Integration / SOA Theme Summary
document. SAP SOA standards should be extended to provision of Information as
a service out of ECC or BI as requirements dictate.

Information should be regarded as a critical asset

There is a need to understand how SAP-based data is used to support Business

KPIs, and to develop standardised, architected approaches to delivering them.

Information should be shared

The SAP BI Architecture should support consolidation of information for the

reporting to Regional and Global levels as appropriate.

Information should be accessible

The SAP BI Architecture needs to address techniques for providing ease of enduser access to reports and queries.

Information quality should be fit for purpose

Enterprise wide standards and processes relating to data quality will be applicable
to SAP.

Information management is compliant with law and regulations

Legal and regulatory considerations apply to SAP along with all other systems.

Information is appropriately assessed and secured as needed

SAP BI should be implemented with an appropriate authorisation model in line with

AZ security standards.

Information adopts a common vocabulary and data definition wherever possible

Enterprise standards for semantic data and service definitions should be consistent
with SAP definitions.

Information is not duplicated wherever possible

The SAP BI Architecture should reflect consistent use of SAP BI across Regions
and in conjunction with other reporting solutions.

Information value should be at the forefront of decision making

Design decisions should be made in the context of an Architecture that positions

SAP BI against other Enterprise-wide reporting tools.

Architecture principles: SAP Summary

Architecture
Vision

The scope of this document is the use of SAP-based Business Intelligence tools (specifically SAP
BW / BI) for reporting and analytics. The approach for SAP BI is a constituent part of the overall EIM
Theme.

AZ does not have a designated strategic Enterprise-wide reporting solution. There are, though, a
number of established reporting solutions based on a range of applications and technologies. These
will remain in the AZ environment and SAP needs to coexist with them.

Significant reporting tools that have a link to SAP (e.g. because they receive SAP feeds, or because
they exist in a space where an SAP-based solution might provide an alternative), include:

Specific custom or package applications with focused reporting functionality, e.g.:

Hyperion for Group Financial Consolidation

Ariba for Procurement Reporting

The Common Data Warehouse BI platform used within AZ to support BI requirements across
SET areas. This in turn comprises:

A technical platform based on a combination of an Oracle Data Warehouse, Informatica ETL, and Business Objects reporting
A set of reporting applications built on this platform including:
EPV for Group Financial Management and sales reporting
Enigma ISMO performance reporting
SCM Operations performance reporting
FinD/FinD+ for cost centre reporting across some of the SET areas

As a general principle, SAP BI will be used as a reporting platform in areas where the transactional
and master data needed to support it are derived entirely, or primarily, from SAP systems.

Architecture principles: SAP Summary

10

Architecture
Vision

The Target Architecture for SAP BI considers the following topics:

Functional scope of SAP BI and its positioning against other

reporting systems

Target level of standardisation across SAP BI environments in

different regions

SAP BI instance strategy aligned with the broader Regional instance

strategy

Technical architecture and fit with other reporting tools and

architecture

SAP BI in relation to Business Architecture

Business
Architecture

Information
Systems
Architecture

The purpose of this section is to position the usage of SAP BI as the

preferred reporting software tool against reporting requirements. This is
done at a high level, looked at from 3 perspectives:

Process area
Processes are listed using METIS level 1 / 2 definitions. This is closely aligned
with the SAP Application Architecture. SAP BI is positioned as a reporting tool
only against those process areas for which SAP is identified as the strategic
target application.

Reporting Type (using the EIM Building Block definitions):

Enterprise Performance Management
Operational BI

Geographical scope: Local (Plant / Country) / Regional / Global

The extent to which SAP BI reporting needs to support either operational reports
or KPI measures.

11

SAP BI positioning against process area reporting

requirements

Business
Architecture

Information
Systems
Architecture

The Target Reporting Architecture defines a set of standards, listed below, that position
the usage of SAP BI as a reporting tool. The following colour coding is used in the next
set of charts to indicate positioning of SAP BI against process area
Core reporting scope for which SAP BI is the preferred platform across all Hubs, for those
process areas where SAP is defined as the strategic target application in the Application
Architecture.
All Regional hubs should standardise on SAP BI as a reporting platform for these process
areas, and look to leverage common data structures / query designs across Hubs to the extent
that process harmonisation permits.

SAP BI is the preferred reporting platform across all Hubs for some elements of reporting,
potentially in conjunction with other reporting tools.
As above, all Regional hubs should standardise on SAP BI as a reporting platform for these
process areas, and look to leverage common data structures / query designs across Hubs to
the extent that process harmonisation permits.

SAP BI is not the standard reporting platform across all hubs. Other reporting applications are
currently, and will remain, in place in some areas.
This does not preclude use of SAP BI to satisfy local requirements. The standards include a
further set of guidelines to help determine the applicability of SAP BI as a Reporting tool
against any new requirements.

No clear vision yet regarding target process model or positioning of SAP as a strategic target
application.

12

SAP BI Positioning against Process Areas: Market

and Sell Drug

Business
Architecture

Market and
Sell Drug
Operational BI
Portfolio Strategy

Local

Regional

Enterprise Performance Mgmt

Global

Local

Regional

Global

Brand Strategy
Pricing and
Contract Strategy
Sales Forecasting
and Planning
Product Licensing
Market
Intelligence
Market
the Brand
Sales Channel
Management
Selling and
Contracting
Medical Support
Sample
Management

13

SAP positioning
from Application
Architecture

Order-to-Cash
reporting from
Regional Finance
Systems

N/A

ISMO / US Sales Reporting

Scope of SAP BI reporting is limited in the Market and

Sell Drug area, limited to operational Order-to-Cash
processes executed in Regional SAP systems.

Information
Systems
Architecture

SAP BI Positioning against Process Areas: Make Drug

Business
Architecture

Information
Systems
Architecture

Make Drug
Operational BI

Planning
Production

Local

Regional

Enterprise Performance Mgmt

Global

Local

Regional

Global

Manage
Production
Develop
Manufacturing
Approach
Bulk Drug
Manufacture
Formulation
Operational
Reporting for
Manufacturing
in-scope for
SAP

Package Drug
Plant Design
and Build

N/A

Manufacturing
KPIs at Plant or
country level (1)

No requirement
identified for Regional
or Global KPI Reporting
(2)

Ensure Plant
Availability
Product Tracking out of scope for SAP BI

Track Products
Maintain
Regulatory
Compliance

14

1.

Opportunities exist to leverage standard queries and reports across

systems, and define standard KPIs for manufacturing, although the
reporting scope will typically be local to a country / plant.

2.

The requirement potentially exists to compare performance across plants

at the KPI level, but the assumption is there is no requirement to report in
different dimensions or slice and dice against a Regional or Global Data
Warehouse.

SAP BI Positioning against Process Areas: Supply

Chain

Business
Architecture

Information
Systems
Architecture

Supply Chain
Supply Chain
Strategy

Operational BI
Local

Regional

Enterprise Performance Mgmt

Global

Local

Regional

Global

Planning the
Supply Chain
Manage
Supply Chain

Operational Reporting around Supply Chain

performed at appropriate level for scope of
process

SAP BI in conjunction with

other Reporting Tools

Inventory
Management

Distribution

Safety, Health
and Environment

Category
Management

Buying

15

Local or Regional Process

execution

N/A

TBD

TBD
Reporting to support Supply Chain processing will move into SAP in line
with the implementation of SAP to support the LSCI initiative.

Assume PTP Operational Reporting comes under scope of Transactional Finance where
implemented in SAP. Other Procurement Reporting out of scope for SAP BI.

Note this may be revisited with evaluation of SAP SRM 7.0 for Procurement against
which SAP BI would be positioned for Global Reporting.

SAP BI Positioning against Process Areas:

Supporting AZ
Supporting AZ

Operational BI
Local

HR
Planning

Regional

Business
Architecture

Information
Systems
Architecture

Enterprise Performance Mgmt

Global

Local

Regional

Global

Management
Accounting
IT/IS
Planning

Vision to be
established.
Where Local
Management
Accounting
implemented in
SAP, look to
leverage BI
reporting to
support the
process

Internal
Communications
Facilities
and Equipment
Management
HR
Administration

N/A

Vision to be
established.
Where Local
Management
Accounting
implemented
in SAP, look
to leverage
BI reporting
to support
the process

Financial Performance
Management across local
companies out of scope for
SAP BI.

Staffing and
Development
Engineering
Projects
Operation
reporting for
Transactional
Finance (1)

Accounting
Operations
IT/IS
Operations
Professional
Administration

16

N/A

Service Centre KPIs by

Country and Region (1)

No requirement
identified for
Global KPI
Reporting (2)

1.

Opportunities exist to leverage standard queries and reports across Regions, to the
extent that this is compatible with the level of process standardisation.

2.

The requirement potentially exists to compare performance across Regions at the KPI
level, but the assumption is there is no requirement to report in different dimensions or
slice and dice against a Global Data Warehouse.

SAP BI direction in relation to Functional areas

Business
Architecture

Information
Systems
Architecture

Current state a long way from target (SAP adoption/process vision). E.g. SAP not adopted
Current state has adopted SAP BI but SAP adopted to a limited degree
Current state has adopted SAP but opportunities not fully realised or SAP only partially adopted
Vision unclear: strategy development required

Utilise SAP BI for OTC reporting as new countries come on to SAP

Extend use of SAP BI for Manufacturing Reporting as countries are incorporated

into Regional SAP systems. Align with European SAP manufacturing strategy.
Look to leverage common queries and data design to the extent permitted by
the Regional SAP systems.

Supply Chain Reporting not yet in place from SAP but will be supported from
new Global BI system.
Local reports aligned with Regional SAP systems.

BI can be used to support Management Accounting where the process is

supported by SAP, but recognise it will continue to coexist with local solutions
where these are already implemented.
BI continues to support Transactional Finance operation reporting and KPIs.
New countries rolled in as they are brought on to SAP. Look to leverage
common queries and data design to the extent permitted by the Regional SAP
systems.

17

Architectural guidelines on SAP BI positioning

Information
Systems
Architecture

Technology
Architecture

The following guidelines position use of SAP against the use of CDW or other
reporting tools for requirements where SAP BI is not the target reporting
platform.

Decision criteria

Leaning to SAP BI

Leaning to CDW or other reporting

tools

Domain of reporting

Single country, plant, Region or BU

view, or reporting on Global Process
executed in SAP (e.g. Supply Chain)

Consolidated or comparative reporting

across Regions or BUs.

Functional Area

Supporting a process within ERP and

for which SAP is the target application
within the Application Architecture

Outside ERP or SAP scope

SAP content

Standard SAP content available

No standard SAP content available

Data sources

Mainly or exclusively SAP (including

ERP systems potentially migrating to
SAP on the roadmap e.g. Sweden)

Multiple systems including non-SAP

Data granularity

Reporting on, or drill-down to,

transactional data

Summary data only

Existing data store

Data not currently held in CDW or

other reporting system

Data currently held in CDW or other

reporting systems

18

Information
Systems
Architecture

Reporting Technical Architecture

Technology
Architecture

The following slides address the target technical architecture for SAP BI,
referencing the technical layers corresponding to the EIM building blocks.

The as-is SAP BI technical architecture is summarised below:

Operational BI

SAP BI (NAm)

SAP BW

BEx Analyser

Enterprise Performance
Management
Reporting Layer

Data
Warehouse
Layer

Web Reporting
Dashboard
Apps

BEx Analyser

SAP BW

19

SAP BW / BI acts as Data

Warehouse layer.

SAP BI

Flat file
extracts

Extractors

Data
Integration
Layer

SAP BEx Analyser used as the

primary end-user access tool for
SAP BI users.
Provides capability to run
standard queries and allows
power-users to create ad-hoc
queries for OLAP analysis.
NAm also use BI Web Reporting
and some Dashboard
applications.

Non-SAP
SAP R/3

SAP ECC

SAP extractors used to move data

from R/3 / ECC systems to SAP
BI. Data from non-SAP source
systems connected through flatfile extracts.

Information
Systems
Architecture

Reporting Technical Architecture

Technology
Architecture

The SAP BI technical components are shown in the diagram below in relation to the technical layers in
the Central Data Warehouse (CDW).
The Reporting Layer of the CDW is based on the Business Objects Toolset which is now part of the
SAP product set. This creates the opportunity to develop the SAP BI roadmap to incorporate the
Business Objects Reporting layer, and converge on to a single set of reporting tools.
CDW
SAP BW
SAP BI
(NAm)
Business Objects Layer
Operational BI

BEx Analyser

Enterprise Performance
Management

Excelsius

Web Reporting
Dashboard
Apps

BEx Analyser

Reporting Layer

Web
Intelligence
BOBJ Universes
Oracle Data Marts

Data
Warehouse
Layer

SAP BW

SAP BI
Oracle

Flat file
extracts

Extractors

Informatica

Non-SAP

20

Data
Integration
Layer

SAP R/3

SAP ECC

SAP

Non-SAP

Reporting architecture direction as determined by

SAP product roadmap

Information
Systems
Architecture

Technology
Architecture

Highlights of SAPs product roadmap for Business Objects are summarised

below

BEx tools will be supported by SAP until 2016 but will not have any further
functional enhancements and its functionality will be superseded by Business
Objects capabilities at the reporting layer.
A new product, Pioneer combining the capabilities of SAP BEx Analyser and
Business Objects Voyager for query design, execution and analysis will be
launched in 2010.
Web Intelligence and Excelsius will become SAP flagship products for ad-hoc
query / reporting and dashboards / visualisation.
The use of front-end software tools in the SAP and EPV reporting layers will
therefore coalesce as Business Objects becomes incorporated into the SAP
toolset.
This leads to the following direction in relation to the development of Target
Architecture standards
Continue with BEx Analyser as legacy tool and standard choice for SAP BI query definition
and execution.
Evaluate Pioneer as replacement for BEx Analyser for new requirements in 2010.
Web Intelligence and Excelsius to become standard reporting layer tools for SAP for new
dashboard-based requirements.

21

Information
Systems
Architecture

Reporting technical platforms target architecture

Technology
Architecture

Business Objects Layer

Dashboards
Excelsius

BEx Analyser

Query definition,
analysis

Pioneer

Ad-hoc query
and reporting

Pilot and exploit improved

integration between Business
Objects and SAP. Migrate BEx
Analyser to new Pioneer tool.

Business Objects Dashboarding and

Adhoc reporting tools become
standard access point for SAP as well
as CDW reporting.

Web Intelligence
BOBJ Universes

Oracle Data Marts

Data
Warehouse

22

Oracle

Target Architecture 2010 onwards: SAP BI and CDW continue to coexist to meet different reporting
requirements, with a move towards common Business Objects based Reporting Layer for SAP as well
as CDW reporting applications.
Evaluate use of Pioneer as the standard user interface to SAP BI based queries.

SAP BI

Potential migration from BEx Analyser to Pioneer

Prerequisite will be upgrade of SAP BI to minimum level of 7.0. Potentially a further release level of SAP
BI will be needed to exploit fully the integration with Pioneer.

Business Objects Dashboarding and Ad-hoc Web reporting tools become standard access point for
SAP as well as CDW reporting.

Reporting technical platforms future considerations

SAP BI is used for some reporting requirements

The same SAP-sourced data needs to be consolidated with other data in the CDW for different requirements

Solution design options for CDW reporting may then include:

Technology
Architecture

Development of the SAP BI target architecture will give rise to design considerations regarding the
placement of data across SAP BI and CDW. Potential scenarios will arise in which:

Information
Systems
Architecture

Load data into CDW as well as SAP BI.

Hold data in one place or the other and integrate at the Reporting layer, e.g. by creating logical views across both
systems using Business Objects Universes.

The preferred approach will be determined in the design principles and standards used for CDW.
Potential also to standardise ETL methods through common software (Informatica)
BOBJ universes used to create logical views
BOBJ Universes
across Oracle and SAP BI.

Data
Warehouse

ETL
Source
systems
23

Oracle Data Marts

SAP BI
Oracle

Informatica

Extractors

Or Flat File
extracts
SAP ECC

Version and upgrade strategy

Opportunities
& Solutions

Regional Hub

Version / Upgrade strategy

Global

New Global BI system (Version 7.0) to be implemented in conjunction with LSCI. Primarily connected
to Global systems but may also consolidate data from local systems.

EBS

Currently BW 3.5. Upgrade prior to 2Q 2010 to latest available stable version

NAm

Currently BI 7.0, continue until SAP BI upgrade roadmap becomes clearer

AP

Currently BI 7.0, continue until SAP BI upgrade roadmap becomes clearer

European Manufacturing

Open question. Strategy for upgrade / migration of ICON to be determined in line with SAP EU
Manufacturing strategy developed.

LatAm

Open question. Separate instance or link to Regional BI instance?

24

Information
Systems
Architecture

SAP BI Instance Strategy: 1-year outlook

Global
MDM

Global
Supply
Chain

Regional Strategy is an extension of

current Regionally-based BI landscape.

SRM 7.0

No requirement identified for Global

reporting from Transactional Finance or
Manufacturing areas.

Global BI
NAm

NAm BI

EU Man
?
?

EU Man
BI
LatAm

25

Technology
Architecture

AP

EBS

Europe
BI

AP BI

Information
Systems
Architecture

BI instance strategy linkage to MDM

The target picture involves Regional BI instances

(plus a Global BI instance) capable of reporting with a
Regional scope.
Working assumption is that each BI instance is linked
to one primary SAP ECC or R/3 instance, and draws
its data from that system:

26

Regional
BI
Material Mappings
AB12 ABC 123 ZYX
CD34 DEF 456 WVU
EF56 GHI 789 TSR

EBS
NAm
AsiaPac
SAP SCM for Global

Thus exploitation of SAP BI is tied in with

consolidation of countries into the Regional hubs.
For example as countries are brought into EBS their
reporting can also roll in to BI. Similarly exploitation
of BI for Manufacturing reporting in Europe would be
linked to the consolidation into a Europe
Manufacturing hub.
Requirements for a Regional BI to link to individual
country systems (e.g. for Regional reporting to
precede R/3 instance consolidation), an additional
dependency may arise around Master Data. If
consolidated reporting across data from multiple
source SAP systems is required, the requirement
may be dependent on the SAP MDM Consolidation
scenario (see SAP MDM Blueprint).
This is not currently shown on the roadmap but may
be needed if the requirement emerges.

Technology
Architecture

SAP MDM
Material Mappings
AB12 ABC 123 ZYX
CD34 DEF 456 WVU
EF56 GHI 789 TSR

Transactional
Systems
Materials
ABC
DEF
GHI

Materials
123
456
789

Materials
ZYX
WVU
TSR

Opportunities & Solutions Roadmap

Opportunities
& Solutions

SAP BI
Short Term

Medium Term

Long Term

< 9 months

9-18 Months

18-36 months
SAP BI Target

New EU
Man BI
?

European
SAP Manu
strategy

Migrate BEx
Pioneer

Common
Business
Objects frontend

Pilot
Business
Objects
Integration
New
Global BI
aligned
with LSCI
project

EBS BW
upgrade

LatAM BI
instance
strategy

27

New LatAm
BI
?

Opportunities & Solutions Roadmap Rationale

Opportunities
& Solutions

SAP BI

Opportunity
ID

28

Opportunity - Roadmap
Activity

Rationale

Implication

European SAP manufacturing

Strategy

Opportunities to extend and harmonise manufacturing reporting across European sites.

Need to align with European SAP Manufacturing

Strategy. Potential new BI instance for EU
manufacturing or incorporate into EBS instance

LatAm BI instance strategy

BI reporting for consolidated LatAm system

Potential new LatAm BI instance or LatAm roll-in

to another Regional instance.

New Global BI aligned with LSCI

project

Global Reporting for Supply Chain

New Global BI instance

EBS BW upgrade

Consistency with other Regional systems, retain mainstream support, exploit Business Objects
Integration capability.

Upgrade project needs to be included in overeall

roadmap.

Pilot Business Objects Integration

Move towards exploitation of Business Objects as common front-end

Migrate BEx Pioneer

Move towards exploitation of Business Objects as common front-end

User migration, change in SAP BI usage

Common Business Objects front-end

Common architecture across SAP and CDW, with common Business Objects front-end

User migration, change in SAP BI usage