NW2008_Tips_tricks_EDW_v10.ppt
description
Transcript of NW2008_Tips_tricks_EDW_v10.ppt
-
*
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)
-
*
*
What Well Cover
Difference between evolutionary DW architecture and a design Data marts vs. Data warehouses Real-time Data warehousingThe many mistakes of EDWsSuccesses and failures of six large-scale SAP BI-EDWsSAP NetWeaver BI architecture & Corporate Info. Factory (CIF)Wrap-up -
*
Level of Pre-delivered Content
Toolsets & accelerators
Analytical applications
for specific industries
Level of Embedded Analytics
Complex (score cards, budgeting, planning, KPI)
Interactive Mgmt. reporting (OLAP, MQE)
Evolution of Data Warehousing
Emerging (1st generation)
Vertical approach (2nd generation)
Horizontal approach (2nd generation)
Integrated analytical (3rd generation)
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
Emerging
(1st generation)
-
A General Conceptual Enterprise DW Architecture
Metadata
Data Resource Management and Quality Assurance
Source Data
Extract
Operational
Data StoreTransform
Data
WarehouseBI Applications
Source: Bjarne Berg, Introduction to Data Warehousing,
Price Waterhouse Global System solution Center, 1997
Data
Extraction
Integrationand
Cleansing
Processes
Custom
Developed
Applications
Data
Mining
Statistical
Programs
Query Access
Tools
Summarized
DataSegmented
Data SubsetsFunctional Area
Summation
Marketing
and SalesPurchasing
Corporate
InformationProduct Line
Location
Purchasing
SystemsInvoicing
SystemsGeneral
LedgerExternal Data
SourcesOther Internal
SystemsTranslate
Attribute
Calculate
Derive
Summarize
Synchronize
-
SAPs Technical EDW Architecture
Source: SAP AG
UDI
XMLA
SAP
Query
JDBC
ODBO
Business Explorer Suite (BEx)
BEx Query Designer
Information Broadcasting
Web
Analyzer
Web
Application
Designer
MS Excel
Add-inReport
Designer
BEx Web
DB
Connect
BAPI
Service
API
File
XML/A
BEx Analyzer
BI Pattern
BI Consumer Services
BI Platform
Data Warehouse
Enterprise Portal
Analytic Engine
Meta Data Mgr
KM
Visual Composer BI Kit
-
*
SAPs EDW Enablers - Query optimization
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
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)
SAP NW 2004s BI
HPA Engine/Adaptive Computing
Data
AcquisitionInfoCubes
Analytic
EngineSAP
BW
Any
tool
In-memory processingDictionary-based, smart compression using integersHigh parallel data access / horizontal partitioningColumn-based data storage & access/vertical table decomposition -
*
SAPs EDW Enablers - Remodeling Tool Box
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.
NW 2004s goes a long way to address the complaints that BW is a hard to maintain environment with forever fixed models.
Source: SAP AG, Richard Brown, Aug. 2006
In NW2004s you get a new tool to add characteristics and key figures to your model.
-
*
SAPs EDW Enablers - Central EDW Adm. & Tool reductions
SAP NetWeaver has solutions for a complete EDW architecture, including an Administrator Cockpit for managing the system
In a custom data warehouse environment you need many tools:
- 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 ?
In a SAP data warehouse environment you need one tool:
SAP NetWeaver
-
*
SAPs EDW Enablers - Global Tool Reach
The SAP Message: BO and SAP provides
Alignment, Extension & Augmentation of two leading, complementary BI & EIM solutions
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:
Source: SAP February 2008
-
*
SAPs EDW Enablers - Long-term communicated vision
Notice that SAP Web Application Designer is Replaced by Xcelsius+ in 2009 and a new tool called Pioneer will be launched that year also.
SAP has a long-term commitment to EDW and has published their 3-year tool plan so that customers can plan ahead.
Source: SAP February 2008
-
*
*
What Well Cover
Difference between evolutionary DW architecture and a design Data marts vs. Data warehouses Real-time Data warehousingThe many mistakes of EDWsSuccesses and failures of six large-scale SAP BI-EDWsSAP NetWeaver BI architecture & Corporate Info. Factory (CIF)Wrap-up -
*
Design Vs. Evolution
An organization has two fundamental choices:
Build a new well architected EDW Evolve the old EDW or reporting systemBoth 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
-
*
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:
Specific application or workgroup focusNarrow scopeCustomized or stand alone analysisInteractive queryHighly summarizedSingle subject and department orientedUses dimensional data modeling
Data Store Objects (DSO)
Data Warehouse
Data Mart
Acts as source to populate DW and martsOften used for operational reportingDetailed, atomic dataHuge data volumesIntegrated, clean dataCross-functional and cross-departmentalSupports data miningMay use denormalized form modeling (NOT dimensional)Provides mgmt reportingSummarized dataTuned to optimize query performanceMultiple departments or processesMay act as staging area for data martsUses dimensional data modeling -
*
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.
-
*
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.
-
*
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.
-
*
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.
-
*
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.
-
*
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.
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
-
*
*
What Well Cover
Difference between evolutionary DW architecture and a design Data marts vs. Data warehouses Real-time Data warehousingThe many mistakes of EDWsSuccesses and failures of six large-scale SAP BI-EDWsSAP NetWeaver BI architecture & Corporate Info. Factory (CIF)Wrap-up -
*
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.
-
*
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 PSAA normal delta update and a real-time update cannot happen at the same time for the same DataSource and/or ODSFor data targets that subsequently store the real-time-supported ODS objects, real time data transfer cannot be usedInfoPackages that use real-time updates cannot be associated with InfoPackage Groups or Process ChainsConsider 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
3.unknown -
*
*
What Well Cover
Difference between evolutionary DW architecture and a design Data marts vs. Data warehouses Real-time Data warehousingThe many mistakes of EDWsSuccesses and failures of six large-scale SAP BI-EDWsSAP NetWeaver BI architecture & Corporate Info. Factory (CIF)Wrap-up -
*
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.
-
*
Leveraging SAP Standard Content in The EDW
As a guiding principle, map requirements to standard content before customizingHowever, youll probably also have external data sources that require custom ODSs and InfoCubesCustomizing lower level objects will cause higher level standard objects to not work, unless you are willing to customize these also.BW Content available (BI 7.0)
Cockpits ???Workbooks2,211Queries4,325Roles934MultiProviders402InfoCube783DSO objects687InfoObjects 14,368An example from a large manufacturing company
-
*
Standard content
How to Leverage Standard BI Content in the EDW
Storage Requirements
Storage Objects
Map functional requirements to the standard content before you make enhancements
+
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
-
*
Common EDW Mistakes No Tailored Approach
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.
TOP-DOWN APPROACH
Build a global data warehouse for the company, and proceed sourcing data from old legacy systems driven from a top-down approach.
BOTTOM-UP 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.
CONTINUE
CHANGE
-
*
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.
Vchar2(15)
Char(18)
Jims Query
AA Z0986 Query
X0C_K01
0SD_C03
0FIAR_O05
SUDHIRC99
-
*
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.
-
*
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
-
*
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
-
*
*
What Well Cover
Difference between evolutionary DW architecture and a design Data marts vs. Data warehouses Real-time Data warehousingThe many mistakes of EDWsSuccesses and failures of six large-scale SAP BI-EDWsSAP NetWeaver BI architecture & Corporate Info. Factory (CIF)Wrap-up -
*
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
-
*
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 more memory than first anticipated.
Next Steps: Performance tuning (BIA) and cockpits
-
*
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 performance tune the workbooks when we upgraded. They went from kilobytes to Megabytes. Needed on-line user training (CBT)
Next Steps: Adding the subsidiaries and corporate entities in Asia and Europe (650 more users)
-
*
SAP as the EDW in another Oil & Gas Company
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.
Next Steps: Adding European training and rollout (2 more R/3 systems)
-
*
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 hardest. We had to spend most of our project time on masterdata mapping & consolidation.
Next Steps: Add more functionality (purchasing) and rollout to purchasing group and the sales reps.
-
*
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 tuned the ABAP.
Next Steps: Add 2 more acquired companies to SAP R/3 and BI.
-
*
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 complete over the weekend). The BSP web templates had to be rebuilt completely.
Next Steps: Add another maintenance organization and work on web cockpits.
-
*
*
What Well Cover
Difference between evolutionary DW architecture and a design Data marts vs. Data warehouses Real-time Data warehousingThe many mistakes of EDWsSuccesses and failures of six large-scale SAP BI-EDWsSAP NetWeaver BI architecture & Corporate Info. Factory (CIF)Wrap-up -
*
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:
Decision Support System applications (APO, CRM, OLAP, Reporting etc).Data Mining and APDDepartmental Data MartsAccess Media Accelerators (BIA)Bill Inmon is a SAP BI technology advisor. He has advised SAP on how to develop NetWeaver BI
-
*
Using the CIF Reducing number of Platforms
NetWeaver helps by:
Reducing number of hardware servers
Consolidates the platform needs for budgeting, planning, forecasting and scheduling
Simplifies the platforms for web access, security, reporting and analysis.
A major CIF decision is how to integrate the solutions in as few platforms as possible.
CIF provides a corporate framework for the EDW; NetWeaver provides the capabilities to do so with one platform
6.unknown -
*
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.
-
*
*
What Well Cover
Difference between evolutionary DW architecture and a design Data marts vs. Data warehouses Real-time Data warehousingThe many mistakes of EDWsSuccesses and failures of six large-scale SAP BI-EDWsSAP NetWeaver BI architecture & Corporate Info. Factory (CIF)Wrap-up -
*
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/d9144236bcda2ce10000000a1550b0/frameset.htm
Resources
7.unknown -
*
*
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 jobSAP BI is no longer leading or bleeding edge and is used extensively as the EDW for large organizationsIf 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 themCritical to EDW success: reduce number of competing reporting system very quicklyHire an EDW Technical Architect if you have not already. -
*
*
Your Turn!
How to contact me:
Dr. Bjarne Berg
Tip
Solution
Resource
36%
33%
31%
Mostly standard storage objects
Some customization
Highly customized storage objects
Billing
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
Customer
Sold-to
Ship-to
Bill-to
Payer
Customer class
Customer group
~ Customer country
~ Customer region
~ Customer postal code
~ Customer industry code 1
End user
Material
Material number
Material entered
Material group
Item category
Product hierarchy
EAN/UPC
Time
Calendar year
Calendar month
Calendar week
Calendar day
Unit
Currency Key
Unit of Measure
Base unit of measure
Sales unit of measure
Volume unit of measure
Weight unit of measure
Billing information
Billing document
Billing item
Billing type
Billing category
Billing date
Creation date
Cancel indicator
Output medium
~ Batch billing indicator
Debit/credit reason code
Biling category
Reference document
Payment terms
Cancelled billing document
Divison for the order header
Pricing procedure
Organization
Company code
Division
Distribution channel
Sales organization
Sales group
Logistics
Plant
Shipping/receiving point
Document details
Sales order document type
Sales deal
Sales docuement
Accounting
Cost center
Profit center
Controlling area
Account assignment group
Personnel
Sales rep number
LEGEND
Delivered in standard extractors
Delivered in LO extractor
Not in delivered Content -but in R-3
OrganizationCompany 1Company 2Company 3Company 4Company 5Company 6
IndustryInsuranceOil & GasOil & GasManufact.High-TechGov.
SystemBW 3.5BI 7.0BI 7.0BI 7.0BW 3.5BI 7.0
Number of Executive Users* 25342211426
Number of Casual users* 9523,1182,4801,3981,122409
Number of Power users* 34144623897
Number of non-SAP sources 641131324
Number of SAP sources 3110786241449
EDW data content (0-100%)** 80%70%75%50%50%30%
Lessons learned "Start with content
in finance and do
few enhancements
in the beginning"
"Have strong
executive support
and think very long-
term; 3-10 years"
"Spend serious
time on end user
training and
support. Sell the
EDW internally"
"Shut-down
competing
reporting
systems; don't
allow access
databases"
"Users look at the
query tools &
don't care about
the EDW. Use
web tools"
"Data integration is
70% of the project.
Look at source
systems early"
Overall satisfaction*** 788879
Future Plans
BI Accelerator and
web cockpits
Global rollout
(Asia & Europe)
Global rollout
(Europe)
Add new
divisions in US &
purchasing
Rollout and add
subsidiarie's
content
Rollout to the
whole organization
* = 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)
OrganizationCompany 1
IndustryInsurance
SystemBW 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
Future Plans
BI Accelerator and
web cockpits
* = 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)
OrganizationCompany 2
IndustryOil & Gas
SystemBI 7.0
Number of Executive Users* 34
Number of Casual users* 3,118
Number of Power users* 14
Number of non-SAP sources 4
Number of SAP sources 107
EDW data content (0-100%)** 70%
Lessons learned"Have strong
executive support
and think very long-
term; 3-10 years"
Overall satisfaction*** 8
Future Plans
Global rollout
(Asia & Europe)
* = 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)
OrganizationCompany 3
IndustryOil & Gas
SystemBI 7.0
Number of Executive Users* 22
Number of Casual users* 2,480
Number of Power users* 46
Number of non-SAP sources 11
Number of SAP sources 86
EDW data content (0-100%)** 75%
Lessons learned"Spend serious
time on end user
training and
support. Sell the
EDW internally"
Overall satisfaction*** 8
Future Plans
Global rollout
(Europe)
* = 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)
OrganizationCompany 4
IndustryManufact.
SystemBI 7.0
Number of Executive Users* 11
Number of Casual users* 1,398
Number of Power users* 23
Number of non-SAP sources 3
Number of SAP sources 24
EDW data content (0-100%)** 50%
Lessons learned"Shut-down
competing
reporting
systems; don't
allow access
databases"
Overall satisfaction*** 8
Future Plans
Add new
divisions in US &
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)
OrganizationCompany 5
IndustryHigh-Tech
SystemBW 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
Future Plans
Rollout and add
subsidiarie's
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)
OrganizationCompany 6
IndustryGov.
SystemBI 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
Future Plans
Rollout to the
whole organization
* = 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)
FI
Inv
Factory
Dist
Web
Order
.
SOA / WS
FI
Inv
Factory
Dist
Web
Order
.
SOA / WS
2008
Other Enterprise Applications
Distributed
Apps
mySAP
ERP*
1
FI/CO,
HR
mySAP PLM*
1
mySAP
SRM*
1
mySAP SCM*
1
mySAP
CRM*
1
SAP NetWeaver
Portal
Sec.
EDW
Enterprise
Platform
Simplified
Integration
TCO =
Enterprise Platform Cost
Cost of Applications
Cost of Integrating
Apps & Platforms
+
+
End-to-End
Service
Predictability
End-to-End
Service
Predictability
Web Presentation/Portal/Mgmt Reporting
Modeling and
Optimization
Consolidation
Balanced
Scorecard
Budget
Plan/Forecast
Statutory
Reporting
Ad Hoc Query
and Reporting
DataMartDataMartDataMartDataMart
Data Warehouse
Integration Broker
ERP/CRM/SCM/External Sources
Business Proc. Management
Content Management
Knowledge Management
Process
Integration
SAP NetWeaver
People
Integration
Information
Integration
Source: SAP