Tips and tricks for using

SAP NetWeaver Business

Intelligence 7.0 as your
Enterprise Data Warehouse

Dr. Bjarne Berg

2008 Wellesley Information Services. All rights reserved.

 In This Session ...

We will explore 6 large-scale EDW implementations, and see how to

apply lessons to your strategy and projects.

Examine the difference between an evolutionary SAP NetWeaver BI data

warehouse architecture and a top-driven design method.

Compare the results of using a data mart (bottom-up) approach to an

EDW (top down) approach, and determine which approach best fits your
requirements.

Explore the ways in which new SAP NetWeaver BI enhancements can

support real-time data warehousing

We will look at common EDW pitfalls and how to leverage the SAP
NetWeaver BI architecture in a large landscape using the Corporate
Information Factory (CIF)

2
What Well Cover
Difference between evolutionary DW architecture and a design
Data marts vs. Data warehouses
Real-time Data warehousing
The many mistakes of EDWs
Successes and failures of six large-scale SAP BI-EDWs
SAP NetWeaver BI architecture & Corporate Info. Factory (CIF)
Wrap-up

3
 Evolution of Data Warehousing

Complex (score cards,

budgeting, planning, KPI) Level of Embedded Analytics

Horizontal approach Integrated analytical

(2nd generation) (3rd generation)

Emerging
(1st generation)
Emerging Vertical approach
(1st generation) (2nd generation)

Interactive Mgmt.
reporting (OLAP, MQE)
Toolsets &
accelerators Level of Pre-delivered Content Analytical applications
for specific industries

Source: Mike Schroeck, David Zinn and Bjarne Berg, Integrated Analytics Getting Increased Value from
Enterprise Resource Planning Systems, Data Management Review, May, 2002;
Adapted: Bjarne Berg How to Manage a BW Project, BW & Portals Conference, 2007, Miami
4
A General Conceptual Enterprise DW Architecture

Metadata

Operational Data
Source Data Extract Data Store Transform Warehouse BI Applications
Functional Area Custom
Invoicing Developed
Systems Purchasing
Applications
Purchasing Marketing
Systems Data and Sales Data
Extraction Translate Mining
Corporate
General Integration Segmented
Information Attribute
Ledger and Data Subsets
Cleansing Statistical
Processes Summation Calculate
Other Internal Programs
Systems Product Line Derive
Summarized
External Data Summarize Data Query Access
Sources Location Tools
Synchronize

Data Resource Management and Quality Assurance

Source: Bjarne Berg, Introduction to Data Warehousing,
Price Waterhouse Global System solution Center, 1997
 SAPs Technical EDW Architecture
Enterprise Portal
KM
Visual
Composer BI
Kit Business Explorer Suite (BEx)
Information Broadcasting
BEx Web BEx Analyzer
BI Pattern
Web
Web Report MS Excel
Application
Analyzer Designer Add-in
Designer
BI Consumer Services

BEx Query Designer

BI Platform Analytic Engine Meta Data Mgr

UDI
SAP Service
JDBC XMLA ODBO Data Warehouse DB
BAPI File XML/A
Query Connect API

Source: SAP AG
 SAPs EDW Enablers - Query optimization
SAP Any
BW tool

The SAP BI accelerator Analytic

makes query response Engine
time 50-10,000 faster.

You use process chains to

maintain the HPA engine
after each data load InfoCubes
HPA Engine/Adaptive Computing

Data 1. In-memory processing

Acquisition
2. Dictionary-based, smart
SAP NW 2004s BI compression using integers
3. High parallel data access /
Both HP and IBM have standard solutions horizontal partitioning
ranging from $32K to $200K+ that can be 4. Column-based data storage &
installed and tested in as little as 2-4 weeks access/vertical table decomposition
(+ SAP licensing costs) 7
 SAPs EDW Enablers - Remodeling Tool Box

In NW2004s you get a new tool to add characteristics and key figures to
your model.

In older BW versions,
if you forgot to
include a field in your
infocube, the rework
was quite substantial
and often involved
reloading the
infocube as well.

Source: SAP AG, Richard

Brown, Aug. 2006

NW 2004s goes a long way to address the complaints that BW is a

hard to maintain environment with forever fixed models. 8
 SAPs EDW Enablers - Central EDW Adm. & Tool reductions
In a custom data warehouse In a SAP data warehouse
environment you need many tools: environment you need one tool:

- Data loads and transformations SAP NetWeaver

- Scheduling of jobs
- Database management
- Data modeling
- Managed query environments
- On-line Analytical Processing tools (OLAP)
- Statistical analysis tools
- Data visualization tools
- Formatted reporting tools
- Web presentation tool
- Security administration tool
- EDW administration tool(s) SAP NetWeaver has solutions for a complete
- Others ? EDW architecture, including an Administrator
Cockpit for managing the system
9
SAPs EDW Enablers - Global Tool Reach
After the SAPs Acquisition of Business Objects, many have questioned
the long-term vision of SAP as the EDW. In Response, SAP published
their tool integration vision in February 2008:

The SAP Message:

BO and SAP
provides
Alignment,
Extension &
Augmentation of
two leading,
complementary BI &
EIM solutions

Source: SAP February 2008 10

SAPs EDW Enablers - Long-term communicated vision
SAP has a long-term commitment to EDW and has published their 3-year
tool plan so that customers can plan ahead.

Notice that SAP

Web Application
Designer is
Replaced by
Xcelsius+ in
2009 and a new
tool called
Pioneer will be
launched that
year also.
Source: SAP February 2008

11
What Well Cover
Difference between evolutionary DW architecture and a design
Data marts vs. Data warehouses
Real-time Data warehousing
The many mistakes of EDWs
Successes and failures of six large-scale SAP BI-EDWs
SAP NetWeaver BI architecture & Corporate Info. Factory (CIF)
Wrap-up

12
Design Vs. Evolution

An organization has two fundamental choices:

1. Build a new well architected EDW

2. Evolve the old EDW or reporting system

Both solutions are feasible, but organizations

that selects an evolutionary approach should
be self-aware and monitor undesirable add-ons
and workarounds.

Failure to break with the past can be

detrimental to an EDWs long-term success

13
 ODS Vs. Data Warehouse Vs. Data Marts
To Understand the differences between DSO, Data Warehouses and Data Marts we
can examine them in terms of usage, modeling and purpose:

Data Store Objects (DSO) Data Warehouse Data Mart

Acts as source to populate Provides mgmt reporting Specific application or

DW and marts
Often used for operational
reporting
Detailed, atomic data
Huge data volumes
Integrated, clean data
Cross-functional and cross-
departmental
Supports data mining
May use denormalized form
modeling (NOT dimensional)
Summarized data
Tuned to optimize query
performance
Multiple departments or
processes
May act as staging area for
data marts
Uses dimensional data
modeling
workgroup focus
Narrow scope
Customized or stand alone
analysis
Interactive query
Highly summarized
Single subject and
department oriented
Uses dimensional data
modeling
14
 Data Warehouse Vs. Data Marts - Implementation Sequence
There are several alternatives for an iterative approach to implementing
the various storage structures, based upon organizational needs.
The various structures can be enterprise or departmentally focused.
They can be built first, middle, or last. They can be stand-alone or
combined. The important point is to have a concept of the long term
vision of the data warehouse project and how each type of structure is to
be used.
A) ODS first: Start by building an enterprise data warehouse from a subject area
perspective and then gradually move subsets of data to data marts. This
approach may take a longer time to implement.
B) Data mart first: Start by building data marts to get data out to users quickly.
This approach may encounter difficulties in integrating data from an enterprise
perspective.
C) Data marts first within the framework or vision of an ODS: Start by developing
a high-level enterprise or subject area data warehouse framework to guide the
incremental development of the data marts or data warehouse.
15
 Advantages of building the data marts first
There is a significant trend in the industry today toward building data
marts first, then consolidating backwards to create the data warehouse
and operational data store. There are several advantages to this
approach:
A) Allows faster implementation
The average data mart may take 2-3 months to implement; the average EDW evolves
over many iteration and may take years to mature. Several marts can be started in
parallel.

B) Reduces political liability through alignment with a specific business need.

The mart can deliver value to the organization in a much shorter period of time and
can focus on a specific business function or problem. The business sponsors will
see faster results and can affirm their decisions with benefit analysis and feedback.
This is important to maintaining interest and adequate funding levels for the
program. This is in contrast to the time and complexity of building an enterprise
data warehouse.
16
 Advantages of building the data marts first (continued)

C) Limits risk while learning how to implement data warehouse.

Building very large databases of several Terabytes is inherently complex. Backup

and recovery systems may require specialized hardware and software. Complex
tuning may be necessary to achieve satisfactory query performance levels.

Identifying and defining data from many different sources creates opportunities for
users and sponsoring departments to disagree. The ultimate business goals may be
overshadowed by the technical and political difficulties of building the large
warehouse. Starting small with a data mart, experimenting, and using the
implementation as a learning experience, will reduce the risk and may actually result
in a higher quality deliverable.

D) Costs less than an EDW.

Initially, the economics of smaller scale hardware, software, and development staff
may contribute to lower costs for marts than EDWs.

17
 Major Risks of building the Data Marts first
Data marts do not replace data warehouses.

The data mart is not the next step in data warehouse evolution. It must
be planned and implemented as part of the overall architectural vision.

To be effective, you must maintain centralized control of data distribution

to the mart in order to support the enterprises overarching warehouse
goals of data quality, consolidation, and sharing.

Data marts also increase the complexity of the data warehouse

environment with multiple extract, transform, and transfer routines.

There are some great risks of succumbing to political pressures.

Business units that demand a quick hit and a stovepipe

implementation of data marts may only serve to undermine the best
laid plans for an integrated and durable data warehousing program.
18
Risks of building the data marts first

If the IT department agrees to a bottom-up EDW, a strictly

application specific approach, they may end up with multiple data
marts that can not be integrated into a larger EDW/ODS view and
which can not support analysis across different marts.

The bottom line is plan and build a reusable data and technical
foundation (technology standards, data modeling principles, and
integrated databases).

The Gartner Group estimates that resources required to manage a

disjointed data mart environment are three times greater than an
integrated data warehouse architecture.
19
 SAPs Vision of Data Marts
If you insist on building data marts, you can
also use SAPs newly acquired Rapid Marts tool
from Business Objects.

Built with Data Integrator, SAP Rapid Marts are ready-

made data marts for SAP. It has pre-built data flows,
business logic, and schema that understand the SAP
meta-data.

SAP Rapids Marts also include content that is

immediately consumable by business users and can
be deployed independent from an EDW
implementation.
SAP has now inherited a tool
It supports data profiling and cleansing and can be for Data Marts that is
the first step toward a holistic EIM program or global independent from the SAP
EDW strategy. In a prototype environment it can NetWeaver Platform
also provide early understanding of data quality
problems. Source: SAP, Feb 2008 20
What Well Cover
Difference between evolutionary DW architecture and a design
Data marts vs. Data warehouses
Real-time Data warehousing
The many mistakes of EDWs
Successes and failures of six large-scale SAP BI-EDWs
SAP NetWeaver BI architecture & Corporate Info. Factory (CIF)
Wrap-up

21
 Real-time SAP Enterprise Data warehousing gets better
NW 2004s has more features for updates that does not follow the
typical asynchronomous (batch) updates. This include:

1. We can use XML to fill the PSA directly

2. Daemon-based update from delta queue (BW API)
3. Daemon-based update of the ODS and minimal logging

Note: XML documents creates

many tags that will slow down
large dataloads due to the size of
each XML record (relatively large)

However, it works great for

smaller streams of data.

22
 Limitations of Real-time SAP Enterprise Data warehousing
There are some limitations depending on the version of SAP BI/BW you
use. For versions 3.5 and higher, there are few limitations and they
include:
You can only use real-time to load ODSs or PSA
A normal delta update and a real-time update cannot happen at the
same time for the same DataSource and/or ODS
For data targets that subsequently store the real-time-supported ODS
objects, real time data transfer cannot be used
InfoPackages that use real-time updates cannot be associated with
InfoPackage Groups or Process Chains

Consider Using SAP Exchange Infrastructure (SAP-XI) to generate the XML

documents from non-SAP Systems. This can help build a corporate data hub center
Tip that can reduce the number of custom interfaces in the organization
23
What Well Cover
Difference between evolutionary DW architecture and a design
Data marts vs. Data warehouses
Real-time Data warehousing
The many mistakes of EDWs
Successes and failures of six large-scale SAP BI-EDWs
SAP NetWeaver BI architecture & Corporate Info. Factory (CIF)
Wrap-up

24
Common EDW Mistakes Not Using Standard SAP Solutions
In the 1950s, you could buy a standard Sears house for $2,065 and pay
$935 more to have it implemented on your own land
The customers who selected to buy
the standard house were either
extremely happy or totally
disappointed.

When Sears examined why, they

found a strong correlation between
level of modifications to the home
and unhappiness
You buy SAP NetWeaver for its pre-built content
and connections to other SAP applications.

The more you add to the standard solutions, the

harder it will become to realize the benefits you
sought in the first place. 25
 Leveraging SAP Standard Content in The EDW
Mostly standard storage objects
As a guiding principle, Some customization

map requirements to Highly customized storage objects

standard content before 31% 36%

customizing
However, youll probably
also have external data
sources that require 33%
An example from a large
manufacturing company

custom ODSs and

InfoCubes
BW Content available (BI
(BI 7.0)
7.0)
Customizing lower level
objects will cause higher Cockpits ???
level standard objects to Workbooks 2,211

not work, unless you are
Queries
Roles
4,325
934
willing to customize MultiProviders 402
these also.
InfoCube 783
DSO objects 687
InfoObjects 14,368
26
 How to Leverage Standard BI Content in the EDW
1. Create a model based on pre-delivered SAP BW content
2. Map your data requirements to the delivered content, and identify gaps
3. Identify where the data gaps are going to be sourced from
Unit
Logistics
Material
Currency Key Billing information
Plant Unit of Measure
Material number
Shipping/receiving point Base unit of measure
Material entered Billing document
Material group Sales unit of measure
Billing item
Item category Volume unit of measure
Billing type
Product hierarchy Weight unit of measure
Billing category

Storage EAN/UPC Billing Billing date

Creation date
Cancel indicator
Requirements Customer
Number of billing documents
Number biling line items
Output me dium
~ Batch billing indicator
Billed item quantity Debit/cre dit re ason code
Sold-to Net weight Biling category
Ship-to Subtotal 1 Reference document
Bill-to Subtotal 2 Payment terms
Payer Subtotal 3 Cancelled billing document
Customer cla ss Subtotal 4 Divison for the order header
Subtotal 5 Pricing procedure

+
Customer group
~ Customer country Subtotal 6
~ Customer region Subtotal A Document details
~ Customer postal code Net value
~ Customer industry code 1 Cost
End user Tax amount Sales order docume nt type
Volume Sales deal
Sales docuement
Organization

Company code
Division
Distribution channel
Personnel Accounting
Time Storage
Standard content Sales organization
Sales group
Sales rep number Cost center
Profit center
Controlling area
Calendar
Calendar
year
month
Objects
Account a ssignme nt group Calendar week
Calendar day
LEGEND
Map functional requirements to
the standard content before Delivered in standard extractors
Delivered in LO extractor
you make enhancements Not in delivered Content -but in R-3 27
 Common EDW Mistakes No Tailored Approach
TOP-DOWN APPROACH BOTTOM-UP APPROACH
CONTINUE

Build a global data warehouse
for the company, and proceed
sourcing data from old legacy
systems driven from a top-
down approach.
CHANGE
Focus on a bottom-up approach where
the BW project will prioritize supporting
and delivering local BW solutions,
thereby setting the actual establishment
of the global Data Warehouse as
secondary, BUT not forgotten.

Each organization has different corporate cultures and considerations.

The Top-down approach is preferred in centralized organizations, and the bottom-up is
preferred in decentralized organizations. Pick one approach and stick with it. 28
 Common EDW Mistakes loose data standards
Some Many organizations place little value on enforcing data standards.

This include InfoObject, DSO and InfoCube naming standards. It also include naming conventions for queries and InfoAreas.

As a result, these organizations often have a mess where it is hard to understand what is available without researching every field and data store.

It may also lead to problems integrating data with different data types and data lengths due to lack of enforcement

Develop your data standard and have an architect

enforce them throughout the lifetime of the EDW.
ry Ch
0FIA
R_O Vcha
r2(15 Jims Que ar (18
05 X0C_K01 0SD_C03 SUDHIRC99 ) ) 29
AA Z0986 Query
 Common EDW Mistakes Lack of environment management
Some organization have a hard-time to say No to the business community.

As a result, their architecture often looks like mix-and-match of systems that was
acquired to put out urgent needs.

In these organizations, multiple portals are common and overlapping reporting

systems is the rule, not the exception.

EDWs are like marriages between IT and

Business. You have to work at it constantly,
give it attention, and be faithful to the solution.
30
 Common EDW Mistakes lack of transport controls
Most companies have strong change management of their R/3 systems. However, it is common that the same organizations have very loose approval processes for their BI
systems.

BI is becoming a mission critical system for most organizations and the same processes placed on the R/3 system should be applied to a production BI system.

Dont allow quick-fixes and untested service packs and notes to be applied to the production box without adequate testing. BWQ is not for window dressing!!

If you want a stable BI system, you

have to enforce testing and controls
31
 Common EDW Mistakes Poor Performance
When you build an enterprise data warehouse, you should
plan for at least 10-15% of your project time for
performance testing and tuning.

Click-stream analysis have shown the 50% of your casual

audience will hit the refresh button or navigate away from
your web site if the reports take more than 7 seconds.

If your query takes more then 20 seconds to run, you have

major problems.

Get substantial amount of memory for caching and make

sure your have a fast network and hardware resources.

#1 complaint of EDW is lack of performance.

Consider BIA as part of your infrastructure
32
What Well Cover
Difference between evolutionary DW architecture and a design
Data marts vs. Data warehouses
Real-time Data warehousing
The many mistakes of EDWs
Successes and failures of six large-scale SAP BI-EDWs
SAP NetWeaver BI architecture & Corporate Info. Factory (CIF)
Wrap-up

33
 SAP EDW in 6 large Companies - Overview

In this EDW case study we are going to look at 6 diverse organizations

and see their lessons learned in their own words

34
 SAP as the EDW in an Insurance Company
Go-live Year: 2003 (BW v. 3.0b)
Mistakes Made: Under estimated the time it would
take to get the staff up to speed and trained in
BW. Had no SAP web skills in-house and went
with the wrong portal choice (non-SAP)

Successes: Built foundation data stores first (AP,

AR, GL, etc. before we started the individual
department needs. This created a real EDW
foundation instead of data marts. Now we are building
more multiproviders and fewer new data stores.
Because we built the EDW first, we can now deliver
solutions faster.

Technology Challenges: Needed 3 app servers and

Next Steps: Performance more memory than first anticipated.
tuning (BIA) and cockpits
35
 SAP as the EDW in Oil & Gas Company
Go-live Year: 2001 (BW v. 2.1c)
Mistakes Made: Stated with wrong area (MM). Should
have done FI first and then HR. MM, APO and
Motor Vehicle Fuel Tax reporting was too
complex and ambitious for the first implementation
when we were learning.

Successes: Met budgets, deliverables and timelines.

User satisfaction was very high when we went
from only BEx workbooks to the web
templates. Upgrade to BI 7.0 was well received
by developers and users.

Technology Challenges: Did not know how to

Next Steps: Adding the performance tune the workbooks when we upgraded.
subsidiaries and corporate They went from kilobytes to Megabytes. Needed
entities in Asia and Europe on-line user training (CBT)
(650 more users) 36
 SAP as the EDW in another Oil & Gas Company
Next Steps: Adding
European training and rollout
(2 more R/3 systems)
Go-live Year: 2000 (BW v. 2.0b)
Mistakes Made: No formal commitment to the EDW,
that evolved over time (3 years). Did not have the top C-
level commitment until 2003 and had to do a lot
of rework to accommodate the new global vision.
Successes: We are 8 years into the EDW and it has
been adapted as the core platform for global HR,
finance and sales reporting. We have most divisions
on the system and have retired six legacy reporting
environments.
Technology Challenges: Needed more HW than
originally planned. Performance was a real problem
until 2006 when we started using the
Broadcaster and cached some reports in memory.
37
 SAP as the EDW in a Manufacturing Company
Go-live Year: 1999 (BW v. 1.2b)
Mistakes Made: Started too early with too ambitious
scope. BW was not ready for EDW in 1999. Not
until version 3.0b (2002) did we get a real ODS
and could realize our earlier ideas of the EDW.

Successes: We kept the scope small and manageable,

and had good consultants. The turnover rate
on the project team has been low and the system
was allowed to mature without business
disruptions. We have consolidated three reporting
groups into one and saved hundred of thousands of
dollars in licenses each year.

Technology Challenges: Data integration was the

Next Steps: Add more hardest. We had to spend most of our project time on
functionality (purchasing) masterdata mapping & consolidation.
and rollout to purchasing
group and the sales reps. 38
 SAP as the EDW in a High-Tech Company
Go-live Year: 2003 (BW v. 3.1c)

Mistakes Made: User interface was not prioritized

high enough. Executives and casual users hated BEx
workbooks. We had to relauch the EDW in 2006 with a
new web interface.

Successes: After the relaunch we have had success

with user adaptation and have a functional steering
committee and CFO sponsorship. Closing the
financial books have gone from 5 days to 3.

Technology Challenges: Was unsure on how to

interface our existing portal with SAP BI content
(SSO). Security setup was hard and advise was too
divergent. Process chains ran very slow until we
Next Steps: Add 2 more
tuned the ABAP.
acquired companies to
SAP R/3 and BI.
39
 SAP as the EDW in a Government Organization
Go-live Year: 2005 (BW v. 3.5)

Mistakes Made: Source data was in too many diverse

old system with no real standards. We under
estimated the time it would take in integrate nine
different mainframes, some that was 20+ years old.
Should not used a big-bang go-live.

Successes: Civilian and uniformed personnel worked

well together and training was well received.
The data collection and reporting that used to
take 14 days each month to produce, now takes 30
minutes.

Technology Challenges: During the BI 7.0 upgrade,

the unicode conversion took long (did not
Next Steps: Add another
complete over the weekend). The BSP web templates
maintenance organization had to be rebuilt completely.
and work on web cockpits.
40
What Well Cover
Difference between evolutionary DW architecture and a design
Data marts vs. Data warehouses
Real-time Data warehousing
The many mistakes of EDWs
Successes and failures of six large-scale SAP BI-EDWs
SAP NetWeaver BI architecture & Corporate Info. Factory (CIF)
Wrap-up

41
 The Corporate Information Factory (CIF)
In 2001, Bill Inmon (the father of DW) and Claudia Imhoff
proposed a reporting architecture known as the CIF.
At the heart CIFs reporting strategy
is the EDW. It is the source of:

1. Decision Support System applications

(APO, CRM, OLAP, Reporting etc).

2. Data Mining and APD

3. Departmental Data Marts

4. Access Media Accelerators (BIA)

Bill Inmon is a SAP BI

technology advisor. He has
advised SAP on how to develop
42
NetWeaver BI
 Using the CIF Reducing number of Platforms
A major CIF decision is how to integrate the solutions in as few
platforms as possible.
NetWeaver helps by:
1. Reducing
number of
hardware servers

2. Consolidatesthe platform
needs for budgeting,
planning, forecasting and
scheduling

3. Simplifies
the platforms for
web access, security,
reporting and analysis.
CIF provides a corporate framework for the EDW;
NetWeaver provides the capabilities to do so with
one platform
Solution 43
 SAPs Conceptual Enterprise Data Warehouse Architecture
SAP recognizes that we do not build EDWs, we are doing Enterprise
Data warehousing. This is an on-going activity that merges information
systems, people and processes.

EDW is an on-
going activity
with continuous
investment
needs.
44
What Well Cover
Difference between evolutionary DW architecture and a design
Data marts vs. Data warehouses
Real-time Data warehousing
The many mistakes of EDWs
Successes and failures of six large-scale SAP BI-EDWs
SAP NetWeaver BI architecture & Corporate Info. Factory (CIF)
Wrap-up

45
Resources Resource

COMERIT (Presentations, articles and accellerators)

www.comerit.net

Enterprise Wide Data Warehousing with SAP BW

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/5586d290-
0201-0010-b19e-a8b8b91207b8

Enterprise DataWarehousing SAP Help

http://help.sap.com/saphelp_nw70/helpdata/en/29/d9144236bcda2ce10000000
a1550b0/frameset.htm

46
 7 Key Points to Take Home
Plan Your Target EDW Architecture before you start the project.

Enforce Standards and pick the right tools for the job

SAP BI is no longer leading or bleeding edge and is used extensively

as the EDW for large organizations

If you are still on BI 3.5: Upgrade!

SAP BI has many new tools that will enhance the front-end for end users.
Your EDW will need them

Critical to EDW success: reduce number of competing reporting system

very quickly

Hire an EDW Technical Architect if you have not already.

47
Your Turn!

How to contact me:

Dr. Bjarne Berg
bberg@comerit.net
48