2. 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
3. What We’ll 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
4. Evolution of Data Warehousing
Level of Embedded Analytics
Complex (score cards,
budgeting, planning, KPI)
Horizontal approach
(2nd generation)
Emerging
(1st generation)
Emerging
(1st generation)
Integrated analytical
(3rd generation)
Vertical approach
(2nd generation)
Interactive Mgmt.
reporting (OLAP, MQE)
Toolsets &
accelerators
Level of Pre-delivered Content
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
Analytical applications
for specific industries
4
5. A General Conceptual Enterprise DW Architecture
Metadata
Source Data
Extract
Operational
Data Store
Transform
Data
Warehouse
BI Applications
Functional Area
Invoicing
Systems
Purchasing
Systems
General
Ledger
Other Internal
Systems
External Data
Sources
Custom
Developed
Applications
Purchasing
Data
Extraction
Integration
and
Cleansing
Processes
Marketing
and Sales
Corporate
Information
Data
Mining
Translate
Attribute
Summation
Calculate
Product Line
Derive
Segmented
Data Subsets
Location
Summarize
Summarized
Data
Synchronize
Statistical
Programs
Query Access
Tools
Data Resource Management and Quality Assurance
Source: Bjarne Berg, “Introduction to Data Warehousing”,
Price Waterhouse Global System solution Center, 1997
6. SAP’s Technical EDW Architecture
Enterprise Portal
Visual
Composer BI
Kit
KM
Business Explorer Suite (BEx)
Information Broadcasting
BEx Web
BI Pattern
Web
Application
Designer
Web
Analyzer
BEx Analyzer
Report
Designer
MS Excel
Add-in
BI Consumer Services
BEx Query Designer
BI Platform
Analytic Engine
Meta Data Mgr
UDI
SAP
JDBC XMLA ODBO
Query
Data Warehouse
DB
Connect
BAPI
Service
API
File
XML/A
Source: SAP AG
7. SAP’s EDW – Enablers - Query optimization
SAP
BW
Analytic
Engine
The SAP BI
accelerator makes
query response time
50-10,000 faster.
You use process
chains to maintain the
HPA engine after each
data load
Any
tool
InfoCubes
HPA Engine/Adaptive Computing
Data
Acquisition
SAP NW 2004s BI
Both HP and IBM have standard solutions
ranging from $32K to $200K+ that can be
installed and tested in as little as 2-4 weeks
(+ SAP licensing costs)
1. In-memory processing
2. Dictionary-based, smart
compression using integers
3. High parallel data access /
horizontal partitioning
4. Column-based data storage &
access/vertical table decomposition
7
8. SAP’s 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
9. SAP’s EDW Enablers - Central EDW Adm. & Tool reductions
In a custom data warehouse
environment you need many tools:
In a SAP data warehouse
environment you need one tool:
- Data loads and transformations
- 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)
- Others ?
SAP NetWeaver
SAP NetWeaver has solutions for a complete
EDW architecture, including an Administrator
Cockpit for managing the system
9
10. SAP’s EDW Enablers - Global Tool Reach
After the SAP’s 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
11. SAP’s 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
12. What We’ll 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
13. 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 EDW’s long-term success…
13
14. 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)
• Acts as source to populate
DW and marts
• Often used for operational
reporting
• Detailed, atomic data
• Huge data volumes
• Integrated, clean data
• Cross-functional and crossdepartmental
• Supports data mining
• May use denormalized form
modeling (NOT dimensional)
Data Warehouse
• Provides mgmt reporting
• Summarized data
• Tuned to optimize query
performance
• Multiple departments or
processes
• May act as staging area for
data marts
• Uses dimensional data
modeling
Data Mart
• Specific application or
workgroup focus
• Narrow scope
• Customized or stand alone
analysis
• Interactive query
• Highly summarized
• Single subject and
department oriented
• Uses dimensional data
modeling
14
15. 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
16. 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
17. 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
18. 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 enterprise’s 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
19. 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
20. SAP’s Vision of Data Marts
If you insist on building data marts, you can
also use SAP’s newly acquired “Rapid Marts” tool
from Business Objects.
Built with Data Integrator, SAP Rapid Marts are readymade 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.
It supports data profiling and cleansing and can be
“the first step toward a holistic EIM program or global
EDW strategy”. In a prototype environment it can
also provide early understanding of data quality
problems.
Source: SAP, Feb 2008
SAP has now inherited a tool
for Data Marts that is
independent from the SAP
NetWeaver Platform
20
21. What We’ll 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
22. 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
23. 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
that can reduce the number of custom interfaces in the organization
Tip
23
24. What We’ll 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
25. 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 customer’s 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
26. Leveraging SAP Standard Content in The EDW
•
•
•
As a guiding principle,
map requirements to
standard content
before customizing
However, you’ll
probably also have
external data sources
that require custom
ODSs and InfoCubes
Customizing lower
level objects will cause
higher level standard
objects to not work,
unless you are willing
to customize these
also….
Mostly standard storage objects
Some customization
Highly customized storage objects
31%
36%
33%
An example from a large
manufacturing company
BW Content available (BI 7.0)
(BI 7.0)
•
•
•
•
•
Cockpits
???
Workbooks 2,211
Queries
4,325
Roles
934
MultiProviders 402
• InfoCube
783
• DSO objects 687
• InfoObjects 14,368
26
27. 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
Material
Material number
Material entered
Material group
Item category
Product hierarchy
EAN/UPC
Storage
Requirements
Plant
Shipping/receiving point
Currency Key
Unit of Measure
Base unit of measure
Sales unit of measure
Volume unit of measure
Weight unit of measure
Billing
Customer
+
Unit
Logistics
Sold-to
Ship-to
Bill-to
Payer
Customer cla ss
Customer group
~ Customer country
~ Customer region
~ Customer postal code
~ Customer industry code 1
End user
Number of billing documents
Number biling line items
Billed item quantity
Net weight
Subtotal 1
Subtotal 2
Subtotal 3
Subtotal 4
Subtotal 5
Subtotal 6
Subtotal A
Net value
Cost
Tax amount
Volume
Organization
Standard content
Company code
Division
Distribution channel
Sales organization
Sales group
Map functional requirements to
the standard content before
you make enhancements
Personnel
Sales rep number
Accounting
Cost center
Profit center
Controlling area
Account assignme nt group
Billing information
Billing document
Billing item
Billing type
Billing category
Billing date
Creation date
Cancel indicator
Output me dium
~ Batch billing indicator
Debit/credit reason code
Biling category
Reference document
Payment terms
Cancelled billing docume nt
Divison for the order header
Pricing procedure
Document details
Sales order document type
Sales deal
Sales docuement
Time
Calendar
Calendar
Calendar
Calendar
year
month
week
day
Storage
Objects
LEGEND
Delivered in standard extractors
Delivered in LO extractor
Not in delivered Content -but in R-3
27
28. Common EDW Mistakes – No Tailored Approach
Build a global data warehouse
for the company, and proceed
sourcing data from old legacy
systems driven from a topdown approach.
BOTTOM-UP APPROACH
CHANGE
CONTINUE
TOP-DOWN APPROACH
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
29. 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.
0FIA
R_O
05
X0C_K01
0SD_C03
SUDHIRC99
Vcha
r2(15
)
ry
Jims Que
AA Z0986 Query
Ch
ar
(18
)
29
30. 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
31. 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.
Don’t 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
32. 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
33. What We’ll 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
34. 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
Organization
Company 1
Company 2
Company 3
Industry
Insurance
Oil & Gas
Oil & Gas
System
BW 3.5
BI 7.0
BI 7.0
Number of Executive Users*
25
34
22
Number of Casual users*
952
3,118
2,480
Number of Power users*
34
14
46
Number of non-SAP sources
6
4
11
Number of SAP sources
31
107
86
EDW data content (0-100%)**
80%
70%
75%
Lessons learned
"Start with content
"Have strong
"Spend serious
in finance and do executive support time on end user
few enhancements and think very longtraining and
in the beginning" term; 3-10 years" support. Sell the
EDW internally"
Overall satisfaction***
7
BI Accelerator and
web cockpits
8
Global rollout
(Asia & Europe)
Future Plans
8
Global rollout
(Europe)
Company 4
Company 5
Company 6
Manufact.
High-Tech
Gov.
BI 7.0
BW 3.5
BI 7.0
11
42
6
1,398
1,122
409
23
89
7
3
13
24
24
144
9
50%
50%
30%
"Shut-down
"Users look at the "Data integration is
competing
query tools &
70% of the project.
reporting
don't care about
Look at source
systems; don't
the EDW. Use
systems early"
allow access
web tools"
databases"
8
7
9
Add new
Rollout and add
Rollout to the
divisions in US &
subsidiarie's
whole organization
purchasing
content
* = actual users logged in within a 30 days period
** = estimated amount of organizational reporting done with EDW data
*** = Scale 1 to 9 (9 being highest and 5 being neutral)
34
35. SAP as the EDW in an Insurance Company
Organization
Company 1
Industry
Insurance
System
BW 3.5
Number of Executive Users*
25
Number of Casual users*
952
Number of Power users*
34
Number of non-SAP sources
6
Number of SAP sources
31
EDW data content (0-100%)**
80%
Lessons learned "Start with content
in finance and do
few enhancements
in the beginning"
Overall satisfaction***
7
BI Accelerator and
web cockpits
Future Plans
* = actual users logged in within a 30 days period
** = estimated % of org. reporting done with EDW data
*** = Scale 1 to 9 (9 being highest and 5 being neutral)
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
tuning (BIA) and cockpits
more memory than first anticipated.
35
36. SAP as the EDW in Oil & Gas Company
Organization
Industry
System
Number of Executive Users*
Number of Casual users*
Number of Power users*
Number of non-SAP sources
Number of SAP sources
EDW data content (0-100%)**
Lessons learned
Company 2
Oil & Gas
BI 7.0
34
3,118
14
4
107
70%
"Have strong
executive support
and think very longterm; 3-10 years"
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.
Overall satisfaction***
8
Global rollout
(Asia & Europe)
Future Plans
* = actual users logged in within a 30 days period
** = estimated % of org. reporting done with EDW data
*** = Scale 1 to 9 (9 being highest and 5 being neutral)
Next Steps: Adding the
subsidiaries and corporate
entities in Asia and Europe
(650 more users)
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
performance tune the workbooks when we upgraded.
They went from kilobytes to
Megabytes. Needed
on-line user training (CBT)
36
37. SAP as the EDW in another Oil & Gas Company
Organization
Industry
System
Number of Executive Users*
Number of Casual users*
Number of Power users*
Number of non-SAP sources
Number of SAP sources
EDW data content (0-100%)**
Lessons learned
Overall satisfaction***
Company 3
Oil & Gas
BI 7.0
22
2,480
46
11
86
75%
"Spend serious
time on end user
training and
support. Sell the
EDW internally"
8
Global rollout
(Europe)
Future Plans
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 Clevel 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.
* = actual users logged in within a 30 days period
** = estimated % of org. reporting done with EDW data
*** = Scale 1 to 9 (9 being highest and 5 being neutral)
Next Steps: Adding
European training and rollout
(2 more R/3 systems)
Technology Challenges: Needed more HW than
originally planned. Performance was a real
until 2006 when we started using the
Broadcaster and cached some reports in
problem
memory.
37
38. SAP as the EDW in a Manufacturing Company
Organization
Industry
System
Number of Executive Users*
Number of Casual users*
Number of Power users*
Number of non-SAP sources
Number of SAP sources
EDW data content (0-100%)**
Lessons learned
Company 4
Manufact.
BI 7.0
11
1,398
23
3
24
50%
"Shut-down
competing
reporting
systems; don't
allow access
databases"
Overall satisfaction***
8
Add new
divisions in US &
Future Plans
purchasing
* = actual users logged in within a 30 days period
** = estimated % of org. reporting done with EDW data
*** = Scale 1 to 9 (9 being highest and 5 being neutral)
Next Steps: Add more
functionality (purchasing)
and rollout to purchasing
group and the sales reps.
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
hardest. We had to spend most of our project time on
masterdata mapping & consolidation.
38
39. SAP as the EDW in a High-Tech Company
Organization
Company 5
Industry
High-Tech
System
BW 3.5
Number of Executive Users*
42
Number of Casual users*
1,122
Number of Power users*
89
Number of non-SAP sources
13
Number of SAP sources
144
EDW data content (0-100%)**
50%
Lessons learned "Users look at the
query tools &
don't care about
the EDW. Use
web tools"
Overall satisfaction***
7
Rollout and add
subsidiarie's
Future Plans
content
* = actual users logged in within a 30 days period
** = estimated % of org. reporting done with EDW data
*** = Scale 1 to 9 (9 being highest and 5 being neutral)
Next Steps: Add 2 more
acquired companies to
SAP R/3 and BI.
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
tuned the ABAP.
39
40. SAP as the EDW in a Government Organization
Organization
Company 6
Industry
Gov.
System
BI 7.0
Number of Executive Users*
6
Number of Casual users*
409
Number of Power users*
7
Number of non-SAP sources
24
Number of SAP sources
9
EDW data content (0-100%)**
30%
Lessons learned "Data integration is
70% of the project.
Look at source
systems early"
Overall satisfaction***
9
Rollout to the
whole organization
Future Plans
* = actual users logged in within a 30 days period
** = estimated % of org. reporting done with EDW data
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.
*** = Scale 1 to 9 (9 being highest and 5 being neutral)
Technology Challenges: During the BI 7.0 upgrade,
Next Steps: Add another
maintenance organization
and work on web cockpits.
the unicode conversion took long (did not
complete over the weekend). The BSP web templates
had to be rebuilt completely.
40
41. What We’ll 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
42. 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 CIF’s 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
NetWeaver BI
42
43. 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:
number of
hardware servers
Distributed
Apps
mySAP
SRM*1
End-to-End
Service
Predictability
mySAP
ERP*1
FI/CO,
HR
mySAP
CRM*1
FI
Web
Order
….
Other Enterprise Applications
mySAP SCM*1
TCO =
2. Consolidates
the platform
needs for budgeting,
planning, forecasting and
scheduling
Simplified
Integration
Portal
Sec.
EDW
Enterprise
Platform
SAP NetWeaver
the platforms for
web access, security,
reporting and analysis.
Factory
Dist
SOA / WS
SOA / WS
1. Reducing
Inv
mySAP PLM*1
Enterprise Platform Cost
+
Cost of Integrating
Apps & Platforms
+
Cost of Applications
2008
3. Simplifies
CIF – provides a corporate framework for the EDW;
NetWeaver provides the capabilities to do so with
one platform
Solution
43
44. SAP’s 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.
DataMart
DataMart
DataMart
SAP NetWeaver
Ad Hoc Query
and Reporting
Statutory
Reporting
Budget
Plan/Forecast
Balanced
Scorecard
Consolidation
Modeling and
Optimization
Knowledge Management
Content Management
Business Proc. Management
Web Presentation/Portal/Mgmt Reporting
DataMart
Data Warehouse
Integration Broker
ERP/CRM/SCM/External Sources
Source: SAP
Information
Integration
People
Integration
Process
Integration
EDW is an ongoing activity
with continuous
investment
needs.
44
45. What We’ll 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
46. 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/5
586d290-0201-0010-b19e-a8b8b91207b8
Enterprise DataWarehousing – SAP Help
http://help.sap.com/saphelp_nw70/helpdata/en/29/d9144236bcda2ce
10000000a1550b0/frameset.htm
46
47. 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