738 Tips and Tricks For Using Sap Netweaver Business As Edw

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)
1
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
2
Evolution of Data Warehousing
Complex (score cards,

budgeting, planning, KPI)
Horizontal approach Integrated analytical

(2nd generation) (3rd generation)
Emerging
(1st generation)
Emerging Vertical approach
(1st generation) (2nd generation)
Interactive Mgmt.
reporting (OLAP, MQE)
Toolsets &
Level of Pre-delivered Content Analytical applications
accelerators
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
3
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 DB Service
JDBC XMLA ODBO Data Warehouse BAPI File XML/A
Query Connect API
Source: SAP AG
SAPs EDW Enablers - Query optimization
SAP Any
BW tool
Analytic
The SAP BI
Engine
accelerator makes
query response time
50-10,000 faster.
You use process InfoCubes

HPA Engine/Adaptive Computing
chains to maintain the
HPA engine after each Data 1. In-memory processing
data load 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) 6
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. 7
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
8
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 9

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
10
What Well Cover
Wrap-up
11
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
12
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 workgroup focus
Summarized data
Often used for operational Narrow scope
Tuned to optimize query
reporting
performance Customized or stand alone
Detailed, atomic data analysis
Multiple departments or
Huge data volumes processes Interactive query
Integrated, clean data May act as staging area for Highly summarized
data marts
Cross-functional and cross- Single subject and
departmental Uses dimensional data department oriented
modeling
Supports data mining Uses dimensional data
modeling
May use denormalized form
modeling (NOT dimensional)
13
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.
14
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.
15
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.
16
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.
17
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.
18
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 19
What Well Cover
Wrap-up
20
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.
21
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
22
What Well Cover
Wrap-up
23
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. 24
Leveraging SAP Standard Content in The EDW
As a guiding principle, Mostly standard storage objects
Some customization
map requirements to Highly customized storage objects
standard content 31% 36%

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

ODSs and InfoCubes BW Content available (BI 7.0)
Customizing lower

level objects will cause
Cockpits
Workbooks 2,211
???
higher level standard Queries 4,325

objects to not work,
Roles 934
MultiProviders 402
unless you are willing
InfoCube
to customize these DSO objects 687
783
also. InfoObjects 14,368

25
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
Requirements
Cancel indicator
Number of billing documents
Customer Output medium
Number biling line items ~ Batch billing indicator
Billed item quantity Debit/credit reason 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
Subtotal 4 Divison for the order header
Customer class
Customer group Subtotal 5 Pricing procedure
Subtotal 6
+
~ Customer country
~ Customer region Subtotal A Document details
~ Customer postal code Net value
~ Customer industry code 1 Cost
End user Tax amount Sales order document type
Volume Sales deal
Sales docuement
Organization
Company code
Division
Personnel Accounting
Time Storage
Standard content
Distribution channel
Sales organization
Sales group
Sales rep number Cost center
Profit center
Controlling area
Calendar
Calendar
year
month
Objects
Account assignment 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 26
Common EDW Mistakes No Tailored Approach
TOP-DOWN APPROACH BOTTOM-UP APPROACH
CONTINUE
CHANGE
Build a global data warehouse Focus on a bottom-up approach where
for the company, and proceed the BW project will prioritize supporting
sourcing data from old legacy and delivering local BW solutions,
systems driven from a top- thereby setting the actual establishment
down approach. 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. 27
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.
AA Z0986 Query
28
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 EDWs are like marriages between IT and
reporting systems is the Business. You have to work at it constantly,
rule, not the exception. give it attention, and be faithful to the solution.
29
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
30
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
31
What Well Cover
Wrap-up
32
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 Company 4 Company 5 Company 6
Industry Insurance Oil & Gas Oil & Gas Manufact. High-Tech Gov.
System BW 3.5 BI 7.0 BI 7.0 BI 7.0 BW 3.5 BI 7.0
Number of Executive Users* 25 34 22 11 42 6
Number of Casual users* 952 3,118 2,480 1,398 1,122 409
Number of Power users* 34 14 46 23 89 7
Number of non-SAP sources 6 4 11 3 13 24
Number of SAP sources 31 107 86 24 144 9
EDW data content (0-100%)** 80% 70% 75% 50% 50% 30%
Lessons learned "Start with content "Have strong "Spend serious "Shut-down "Users look at the "Data integration is
in finance and do executive support time on end user competing query tools & 70% of the project.
few enhancements and think very long- training and reporting don't care about Look at source
in the beginning" term; 3-10 years" support. Sell the systems; don't the EDW. Use systems early"
EDW internally" allow access web tools"
databases"
Overall satisfaction*** 7 8 8 8 7 9
BI Accelerator and Global rollout Global rollout Add new Rollout and add Rollout to the
web cockpits (Asia & Europe) (Europe) divisions in US & subsidiarie's whole organization
Future Plans 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)
33
SAP as the EDW in an Insurance Company
Organization Company 1
Industry Insurance Go-live Year: 2003 (BW v. 3.0b)
System BW 3.5
Number of Executive Users* 25
Number of Casual users* 952 Mistakes Made: Under estimated the time it would
take to get the staff up to speed and trained in
Number of Power users* 34
Number of non-SAP sources 6
Number of SAP sources
EDW data content (0-100%)**
31
80%
BW. Had no SAP web skills in-house and went
Lessons learned "Start with content with the wrong portal choice (non-SAP)
in finance and do
few enhancements
in the beginning"
Successes: Built foundation data stores first (AP,
AR, GL, etc. before we started the individual
Overall satisfaction*** 7
BI Accelerator and department needs. This created a real EDW
Future Plans
web cockpits
foundation instead of data marts. Now we are
* = actual users logged in within a 30 days period building more multiproviders and fewer new
data stores. Because we built the EDW first, we
** = estimated % of org. reporting done with EDW data
can now deliver solutions faster.
Technology Challenges: Needed 3 app servers and

Next Steps: Performance more memory than first anticipated.
tuning (BIA) and cockpits
34
SAP as the EDW in Oil & Gas Company
Go-live Year: 2001 (BW v. 2.1c)
Industry Oil & Gas
System BI 7.0
Number of Casual users*
Number of Power users*
3,118
14
Mistakes Made: Stated with wrong area (MM). Should
Number of non-SAP sources 4 have done FI first and then HR. MM, APO and
107
70%
Motor Vehicle Fuel Tax reporting was too
Lessons learned "Have strong complex and ambitious for the first
executive support
and think very long- implementation when we were learning.
term; 3-10 years"
Successes: Met budgets, deliverables and timelines.

Global rollout User satisfaction was very high when we went
Future Plans
(Asia & Europe)
from only BEx workbooks to the web
* = actual users logged in within a 30 days period 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
subsidiaries and corporate
upgraded. They went from kilobytes to
entities in Asia and Europe
Megabytes. Needed on-line user training (CBT)
(650 more users) 35
SAP as the EDW in another Oil & Gas Company
Go-live Year: 2000 (BW v. 2.0b)
Industry Oil & Gas
System BI 7.0
Number of Executive Users* 22 Mistakes Made: No formal commitment to the EDW,
that evolved over time (3 years). Did not have
Number of Casual users* 2,480
Number of Power users* 46
Number of non-SAP sources 11 the top C-level commitment until 2003 and had
Number of SAP sources 86
EDW data content (0-100%)** 75% to do a lot of rework to accommodate the new
Lessons learned "Spend serious global vision.
time on end user
training and
support. Sell the
EDW internally" Successes: We are 8 years into the EDW and it has
been adapted as the core platform for global
Global rollout HR, finance and sales reporting. We have most
Future Plans
(Europe)
divisions on the system and have retired six
* = actual users logged in within a 30 days period legacy reporting environments.
Technology Challenges: Needed more HW than

originally planned. Performance was a real
Next Steps: Adding problem until 2006 when we started using the
Broadcaster and cached some reports in
European training and rollout
memory.
(2 more R/3 systems) 36
SAP as the EDW in a Manufacturing Company
Organization
Industry
Company 4
Manufact. Go-live Year: 1999 (BW v. 1.2b)
System BI 7.0
Number of Executive Users* 11 Mistakes Made: Started too early with too ambitious
1,398
23
scope. BW was not ready for EDW in 1999. Not
Number of non-SAP sources 3 until version 3.0b (2002) did we get a real ODS
24
50%
and could realize our earlier ideas of the EDW.
Lessons learned "Shut-down
Successes: We kept the scope small and manageable,

competing
reporting
systems; don't and had good consultants. The turnover rate
allow access
databases" on the project team has been low and the
Overall satisfaction*** 8 system was allowed to mature without
Add new
divisions in US &
business disruptions. We have consolidated
Future Plans purchasing three reporting groups into one and saved
hundred of thousands of dollars in licenses
each year.
Next Steps: Add more Technology Challenges: Data integration was the
functionality (purchasing) hardest. We had to spend most of our project
and rollout to purchasing time on masterdata mapping & consolidation.
group and the sales reps. 37
SAP as the EDW in a High-Tech Company
Go-live Year: 2003 (BW v. 3.1c)
Industry High-Tech
System BW 3.5
1,122
89
Mistakes Made: User interface was not prioritized
Number of non-SAP sources 13 high enough. Executives and casual users
Number of SAP sources 144 hated BEx workbooks. We had to relauch the
EDW data content (0-100%)** 50%
Lessons learned "Users look at the EDW in 2006 with a new web interface.
query tools &
don't care about
the EDW. Use
web tools"
Successes: After the relaunch we have had success
with user adaptation and have a functional
Overall satisfaction*** 7 steering committee and CFO sponsorship.
Rollout and add
subsidiarie's Closing the financial books have gone from 5
Future Plans content days to 3.
Technology Challenges: Was unsure on how to
interface our existing portal with SAP BI
Next Steps: Add 2 more content (SSO). Security setup was hard and
acquired companies to advise was too divergent. Process chains ran
SAP R/3 and BI. very slow until we tuned the ABAP.
38
SAP as the EDW in a Government Organization
Go-live Year: 2005 (BW v. 3.5)
Industry Gov.
System BI 7.0
409
7
Mistakes Made: Source data was in too many diverse
Number of non-SAP sources 24 old system with no real standards. We under
EDW data content (0-100%)** 30%
9
estimated the time it would take in integrate
Lessons learned "Data integration is nine different mainframes, some that was 20+
70% of the project.
Look at source
years old. Should not used a big-bang go-live.
systems early"
Successes: Civilian and uniformed personnel worked

Rollout to the
well together and training was well received.
whole organization The data collection and reporting that used to
take 14 days each month to produce, now
Future Plans
** = estimated % of org. reporting done with EDW data takes 30 minutes.
Technology Challenges: During the BI 7.0 upgrade,

Next Steps: Add another the unicode conversion took long (did not
maintenance organization complete over the weekend). The BSP web
and work on web cockpits. templates had to be rebuilt completely.
39
What Well Cover
Wrap-up
40
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 NetWeaver BI
41
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: mySAP PLM*1
Inv Factory FI
SOA / WS
Distributed
1. Reducing number of Apps

mySAP Web
mySAP ERP*1 mySAP Dist .
hardware servers
Order
SRM*1 FI/CO, CRM*1
HR
End-to-End
Service Other Enterprise Applications
Predictability mySAP SCM*1
2. Consolidates the
platform TCO =
needs for budgeting, Simplified

Integration
Enterprise Platform Cost
planning, forecasting and

+
Cost of Integrating
scheduling Portal Sec. EDW Enterprise
Platform
Apps & Platforms
+
Cost of Applications
SAP NetWeaver
2008
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 42
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.
Web Presentation/Portal/Mgmt Reporting SAP NetWeaver

Business Proc. Management
Knowledge Management
Information
Content Management
Integration
Consolidation
and Reporting
Plan/Forecast
Modeling and
Ad Hoc Query
Optimization
Scorecard
Reporting
Statutory
Balanced
Budget
People
Integration
Process
Integration
DataMart DataMart DataMart DataMart

EDW is an on-
Data Warehouse going activity
with continuous
Integration Broker investment
ERP/CRM/SCM/External Sources needs.
Source: SAP
43
What Well Cover
Wrap-up
44
Resources
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/d9144236bcda2ce1
0000000a1550b0/frameset.htm
45
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.

46
Your Turn!
How to contact me:

Dr. Bjarne Berg
bberg@comerit.net
47

738 Tips and Tricks For Using Sap Netweaver Business As Edw

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

738 Tips and Tricks For Using Sap Netweaver Business As Edw

Caricato da

Copyright:

Formati disponibili

Tips and tricks for using

SAP NetWeaver Business

Dr. Bjarne Berg

2008 Wellesley Information Services. All rights reserved.

Complex (score cards,

Horizontal approach Integrated analytical

Data Resource Management and Quality Assurance

BEx Query Designer

BI Platform Analytic Engine Meta Data Mgr

You use process InfoCubes

Source: SAP AG, Richard

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

- Data loads and transformations SAP NetWeaver

The SAP Message:

Source: SAP February 2008 9

Notice that SAP

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

Failure to break with the past can be

Data Store Objects (DSO) Data Warehouse Data Mart

Acts as source to populate Provides mgmt reporting Specific application or

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

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

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

D) Costs less than an EDW.

There are some great risks of succumbing to political pressures.

Business units that demand a quick hit and a stovepipe

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

The Gartner Group estimates that resources required to manage a

Built with Data Integrator, SAP Rapid Marts are ready-

SAP Rapids Marts also include content that is

1. We can use XML to fill the PSA directly

Note: XML documents creates

However, it works great for

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

When Sears examined why, they

You buy SAP NetWeaver for its pre-built content

The more you add to the standard solutions, the

map requirements to Highly customized storage objects

standard content 31% 36%

that require custom

higher level standard Queries 4,325

also. InfoObjects 14,368

Storage EAN/UPC Billing Billing date

Each organization has different corporate cultures and considerations.

This include InfoObject, DSO and InfoCube naming

As a result, these organizations often have a mess where

It may also lead to problems integrating data with different

Develop your data standard and have an architect

Some organization have a

Most companies have strong change management of their

BI is becoming a mission critical system for most

Dont allow quick-fixes and untested service packs and

If you want a stable BI system, you

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

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

Get substantial amount of memory for caching and make

#1 complaint of EDW is lack of performance.

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

can now deliver solutions faster.

Technology Challenges: Needed 3 app servers and