managing a bw project

Managing a BW project

….From the BW experts at myITgroup..

San Francisco, SAP, Business Objects and MIG conference August 2004

What we will cover

The BW strategy, Business case, Methodology and Approach

Getting the right requirements, organizing it, and determining scope (R/3 Vs. BW)

Project organization and staffing (Examples)

Managing the roll-out

Reference Material (Detailed business case and detailed job descriptions)

Level of Project Delivered Content

Tools andaccelerators

Industry and process specific solutions

Leve

l of E

mbe

d de d

Ana

lyti c

s

Complex analytics(balanced score-cards, budgeting, planning, KPI)

Interactive Mgmt. reporting

(OLAP, MQE)

Alternative Approached to ERP iAnalytics

ERP Data warehouse(1st generation)

Enhanced data warehouse(2nd generation)

Custom analytics(2nd generation)

Integrated analytics(3rd generation)

–Decide early on howmuch analytics vs.basic reporting the teamis going to deliver.

–Balanced scorecardsbased on key performanceindicators require more substantial more workthan creating simple financial reports.

-How will users access data in multiple areas?

Analytics contains pre-developed rules to view or examine data

Analytics Vs. reporting – where are you?

OperationalReporting

More SummarizedMore Ad Hoc

Management InformationLightly Summarized

Real-timeInquiry

Dividing LineDividing LineR/3R/3 BWBW

How much do I put in the BW system?

Why have a BW Strategy?

The use of BW as a reporting tool across business or functional units has several implications:

1. BW shares masterdata with other reporting areas2. BW shares definitions and structures with other reporting areas3. Presentation of data and data views has to be consistent4. User training should be standardized and leveraged

5. Technical support is shared6. User support is shared7. Data should be loaded only once8. Security has to be consistent9. BW skills required should be leveraged in the company

Without a strategic approach to BW, there are significant risks to the ability to deliver a consistent reporting solution at a reasonable cost of ownership.

Leveraging resources: The basis and the business knowledge is available at lower additional costs

Avoid rework Avoid rework of standard content when the R/3 module is implemented. Many smaller configurations can be accommodated in without impact to the project team, Consequently, if extensions are made without regards to the BW implementation, rework may be required.

Cost avoidance: Avoid creating ABAP and custom reports that is available in BW.

Why complete BW and R/3 projects at the same time?

Increased customer satisfaction: While R/3 is optimized for transaction processing. BW is maximized for analysis and user access to the data. The available reports, features increases the user experience and thereby the project likelihood of success.

Things to watch: Usually the BW implementation starts by lagging 4-6 weeks behind the R/3 team in the Prep, Blueprint and Realization phase. However, during the implementation phase, the BW and the R/3 team are both in-sync for the same go-live date.

This lag allows the BW team to leverage the other team’s work without having to sit idle for the first few weeks of the project. It also allows the R/3 team to focus on the processes instead of the data in the beginning of each phase.

Why complete BW and R/3 projects at the same time?

Summary of Business Benefits of BW (1 of 3)

Area Observation BW Benefit

Cost of Ownership Maintaining custom developed application is complex and expensive.

SAP is responsible for maintenance of the product.

Substantial maintenance cost savings

Cost Avoidance Rehosting extract programs from R/3 when upgrading R/3 is expensive.

BW follows the upgrade path with R/3

Substantial cost savings by not having to redevelop new extract programs for each SAP upgrade

Web strategy Web delivery requires rapid data delivery of high consistency with the source system.

BW is closely integrated with R/3 and can deliver data that reflects the source system at short time intervals.

Enables web initiatives to get “closer” to the source data both in time and consistency.

Reconciliation Effort A substantial portion of the data warehouse effort is spent on reconciling information

BW is “closer” to the source system and more accurately reflects data

Users spend less time on reconciling data and more on analyzing it.

Information Access Business users need a high availability of data

Load times in BW is reduced compared with traditional custom developed data warehouses

Users get earlier access to information


Faster Deployment Need to increase time to delivery of new applications and enhancements to existing areas

Use of 60-80% of pre-delivered content increased development speed

Reduced development time for new decision support areas

Integrated Products SAP is offering a variety of new products and modules that the organization might want to leverage in the future

BW is the “corner stone” in SAP’s New Dimension product offerings

Enables closer integration with other SAP modules

Query speed Business users need data fast Through use of summaries, BW’s architecture lends itself to faster query performance

Users get faster access to information



SAP Strategy It is the organization’s SAP strategy to leverage investments in the SAP to the fullest extent.

BW is a SAP product that fits the organization’s strategy. We can also leverage the organization’s Basis and ABAP people in BW projects.

Strategic fit and synergy with SAP.

Tool Standardization the organization must be able to leverage industry standards to enable business users to access data in a variety of ways

Microsoft’s ODBO application interface is supported by a variety of major presentation and web tools.

Simplifies user access to data and provides higher flexibility to leverage presentation and web tools.

Industry Trend the organization’s competitors and some of the organization’s business areas are installing BW

Increased industry resource pool and knowledge of BW

Enables the organization to leverage industry solutions and know-how.


Rapid Application Development (RAD)

– Be flexible and consider using a RAD (Rapid Application development) approach to the initial information requirement gathering. Typical ways to conduct this include:

• Ask for 1-2 days of uninterrupted time and provide lunch on-site• Remove cell phones, PDA and pagers and emails• Invite power users, casual users, today's report writers, and managers

• Keep a rapid pace and the number manageable (no more than 20) • Focus on shared information needs and conduct multiple sessions if needed.• Don't get trapped in details, give people a chance to provide feedback in

writing and follow-up later with individuals.

– The benefits include:• Increased user involvement and less disruption to the business• More likely to avoid individual opinions and get more group consensus• You can use the session as an information sharing event and give a brief

overview of what you are attempting to do.

What we will cover






A process look at getting functional specs

There are more than one way to collect this information, however, a formal process should exist to capture the requirements and also to communicate what is being developed.

Create contact group and contact list for business input and requirements

Create a tool to collect inforequestsand businessinput

Conduct information gathering using the tool

Disposition the info. requests to BW or R/3

Consolidate requirements and write functional specs

Build storage objects and load programs

Construct reports and navigation features

Name Organization Phone Number Joe Jones MYORG Ltd 918-123-1234 Joseph Jones Your ORG Ltd 918-123-1234 Joe Jones MYORG Ltd 123-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1238 Joseph Jones Your ORG Ltd 918-123-1239 Joe Jones MYORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joseph Jones Your ORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joseph Jones Your ORG Ltd 918-123-1234 Joe Jones MYORG Ltd 123-123-1234

Team starts by reviewing documentation tool fordocumentation completeness

D1Is report

documentationcomplete?

Request additionalinput from BusinessTeam member

ResponsibleTeam memberacquires/documents

additional information

D2Is this

an Intradayreport?

D3Significant

numberof users?

D4Is the report

systemresourceintensive?

D5Does

Standard R/3contentexist?

D6Does

Standard BWcontentexist?

D7Is it less

expensive tocreate in

R/3?

R/3 is selected asReporting Tool

and documentedin doc. tool

BW is selected asReporting Tool anddocumented in doc.

tool

BW is selected asReporting Tooland documented

in the documentation tool

BW is selected asreporting tool and ChangeRequest is submitted ifthe scope changed



R/3 is selected asReporting Tooland documented

No

Yes

No

No

Yes

Yes

Yes

No

Yes

No

D2.5Does data existin "in-scope" models

Infocube/ODSNo

Yes

No

D1aIs this a truereporting

need

Yes

No Communicate tobus. leader

A2Total Cost ofOwnershipAnalysis

D8Is BW costeffective?

Yes

No

YesYes



D9R/3 ToolSelectionProcess

No


tool

StandardR/3

ABAP/Custom

ReportWriter

OtherQuery

Review requirements and identifycorresponding Data Model (InfoCube/ODS)

Communicate finaldisposition





R/3 team make final disposition



BW Team to forward completed detailed report specifications based on selected Reporting Tool -BW or R/3

A3Sub-Process Report Consolidation &eliminate if appropriate (winnowing)

A4Baseline reports


D1Is report





D2Is this

an Intradayreport?

D3Significant

numberof users?

D4Is the report


D5Does


D6Does


D7Is it less


R/3?




tool







No

Yes

No

No

Yes

Yes

Yes

No

Yes

No


Infocube/ODSNo

Yes

No


need

Yes




Yes

No

YesYes



D9


D1Is report





D2Is this

an Intradayreport?

D3Significant

numberof users?

D4Is the report


D5Does


D6Does


D7Is it less


R/3?




tool







No

Yes

No

No

Yes

Yes

Yes

No

Yes

No


Infocube/ODSNo

Yes

No


need

Yes




Yes

No

YesYes




No


tool

StandardR/3

ABAP/Custom

ReportWriter

OtherQuery












A4Baseline reports

Create contact group and contact list for business input and requirements

Create a tool to collect inforequestsand businessinput

Conduct information gathering using the tool

Disposition the info. requests to BW or R/3

Consolidate requirements and write functional specs

Build storage objects and load programs

Construct reports and navigation features

Name Organization Phone Number Joe Jones MYORG Ltd 918-123-1234 Joseph Jones Your ORG Ltd 918-123-1234 Joe Jones MYORG Ltd 123-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1238 Joseph Jones Your ORG Ltd 918-123-1239 Joe Jones MYORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joseph Jones Your ORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joseph Jones Your ORG Ltd 918-123-1234 Joe Jones MYORG Ltd 123-123-1234


D1Is report





D2Is this

an Intradayreport?

D3Significant

numberof users?

D4Is the report


D5Does


D6Does


D7Is it less


R/3?




tool







No

Yes

No

No

Yes

Yes

Yes

No

Yes

No


Infocube/ODSNo

Yes

No


need

Yes




Yes

No

YesYes




No


tool

StandardR/3

ABAP/Custom

ReportWriter

OtherQuery












A4Baseline reports

T ea m s ta rt s by rev iewing do cum enta tio n to ol fordocumentation completeness

D1Is report





D2Is this

an Intradayreport?

D3Significant

numberof users?

D4Is the report


D5Does


D6Does


D7Is it less


R/3?




tool







No

Yes

No

No

Yes

Yes

Yes

No

Yes

No


Infocube/ODSNo

Yes

No


need

Yes




Yes

No

YesYes



D9


D1Is report





D2Is this

an Intradayreport?

D3Significant

numberof users?

D4Is the report


D5Does


D6Does


D7Is it less


R/3?




tool






R/3 is s e lec te d a sReporting Tooland documented

No

Yes

No

No

Yes

Yes

Yes

No

Yes

No


Infocube/ODSNo

Yes

No


need

Yes




Yes

No

YesYes




No


tool

StandardR/3

ABAP/Custom

ReportWriter

OtherQuery












A4Baseline reports

Flow overview

BW Report object:

When: Fall-03 to Jan-12, 2004.Who: Process teamsPurpose: Functional requirementsQuantity: 167

Business Reporting Requirements

BW Query Detailed Specification (used by Information Delivery)

Query Name:

Query Technical Name:

Subject area:

Fixed format:

Free format:

Number of users:

Target Users:

Time Granularity

Historical data:

Peak time usage:

Data Volume:

Frequency:

SAP Roles:

Test Criteria:

Jump Targets:

BW detailed query specs

When: Fall-03 to Jan-12, 2004.Who: Information deliveryPurpose: Functional requirementsQuantity: 167

BW Reports

Reports

A real example from a very large manufacturing company

Flow overview

BW functional requirement:

When: Fall-03 to Jan-12, 2004.Who: Information delivery teamPurpose: Storage object requirementsQuantity: 25

Billing

Number of bil ling documentsNumber biling line itemsBilled item quantityNet weightSubtotal 1Subtotal 2Subtotal 3Subtotal 4Subtotal 5Subtotal 6Subtotal ANet valueCostTax amountVolume

Customer

Sold-toShip-toBill-toPayerCustomer cla ssCustomer group~ Customer country~ Customer region~ Customer postal code~ Customer industry code 1End user

Material

Material numberMaterial enteredMaterial groupItem categoryProduct hierarchyEAN/UPC

Time

Calendar yearCalendar monthCalendar weekCalendar day

Unit

Currency KeyUnit of MeasureBase unit of measureSales unit of measureVolume unit of measureWeight unit of measure

Billing information

Billing documentBilling itemBilling typeBilling categoryBilling dateCreation dateCancel indicatorOutput medium~ Batch billing indicatorDebit/credit reason codeBiling categoryReference documentPayment termsCancelled billing documentDivison for the order headerPricing procedure

Organization

Company codeDivis ionDistribution channelSales organizationSales group

Logistics

PlantShipping/receiving point

Document details

Sa les order document typeSales dealSales docuement

Accounting

Cost centerProfit centerControlling areaAccount assignment group

Personnel

Sales rep number

LEGEND

Delivered in standard extractorsDelivered in LO extractorNot in delivered Content -but in R-3

BW logical model:

When: Fall-03 to Jan-12, 2004.Who: Information delivery teamPurpose: Storage object requirementsQuantity: 25

Storage Requirements

BW InfoCubes

Storage

A real example from a very large manufacturing company

Getting the "Right" Requirements

Gathering business requirements that will to establish a project scope that stays focused on user needs.

–Use people close to the business that can help you clarify their needs

–Ask for only the "top-5" reports from each department and all regulatory requirements

–Obtain a copy of each of the current reports used today that are being requested to be developed in BW

–Create a form that capture the core requirements in a structured format


– Avoid creating a total inventory of all reports in the organization. The "top-5" (most used) sales, distribution, inventory etc. reports from each department will cover the vast majority of the reporting needs.

– A single BW "report" may satisfy dozens of today's static reports. It is therefore impossible to map each legacy report to a BW report.

Avoid attempting to replicate each report based on what you might have in place today. Accept new ways of accessing data

Best Practice


Obtain a copy of each of the current reports used today that are being requested to be developed in BW

– Legacy reports may be a great source to document the data needs. They can be used to illustrate how data is being summarized and viewed in the organization.

– Create a physical folder with paper copies of "in-scope" legacy reports. Make sure that the development team have access to them and reduce the time spent in meetings with the business community.

– Consolidate the requirements and look for "low-hanging fruit".

+ + =Great

Feature

Many requirements can be met by a single BW report

Getting the "Right" Requirements Create a form that capture the core requirements in a structured format

Create a simple form called "information request form" and use it to gather the core relevant information about each report being requested by the business community. This should include at least the following fields:

- Contact info about the requestor - Data currency (yesterday/today)- Department - Security requirements- Name of report - How is this reporting done today- Purpose of report - Comments- Description of report - Type of users (mgr./analyst/casual) - Number of users expected - Frequency of report (daily/monthly)

Tip

Report Dispositioning Deciding which reports should stay in R/3 or the legacy system.

– Not all reports belong in BW. Avoid using BW as a "dumping group"

– Make cost effective decisions. Just because the report is not in BW does not mean it cannot be in a portal or on the web

– You need to make conscious decisions on what reporting needs you are going to need and how you want to accomplish this.

We will now take a look at an approach to a formal report dispositioning that has been used by a few companies.


Create a form that capture the core requirements in a structured format

Create a simple form called "information request form" and use it to gather the core relevant information about each report being requested by the business community. This should include at least the following fields:

- Contact info about the requestor - Data currency (yesterday/today)- Department - Security requirements- Name of report - How is this reporting done today- Purpose of report - Comments- Description of report - Type of users (mgr./analyst/casual) - Number of users expected - Frequency of report (daily/monthly) Tip

An example of a simple informationrequest form (from a large oil company)

– Used to documentrequirements in a standardized format

– Used to prioritizerequirements.

– Used to consolidate requirements.

– Used for follow-up discussions and reviews.

P1 of 2

Tool

An example (page 2)

–You can also post such a form on the intranet and thereby give stakeholdersan easy way to communicate with the project team.

–You might use the comment section for security requirements, or add a separate section for this.

–Note the section fordispositioning the requirement

P2 of 2

Tool

Another example on how

Companies have

captured requirements

More on reporting

requirementscapture

Time PeriodsExample Strategy Plan Milestones 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25Setup, on-boarding and kick-off sessionTechnical AssessmentTechnical assessment of Infocube designTechnical assessment of infrastructureTechnical assessment of ETL Technical assessment of security and role designTechnical assessment of BeX queries and viewsTechnical assessment of web delivery approachBusiness Assessment Organizational needs assessmentReporting process assessmentConversion assessmentOrganizational impact statementReview of support organizationTechnical support resource needs assessmentDevelopment approach and standardsTraining planning (project, support and end-users)Migration PlanningAnalysis reportsStatic reportsKnowledge transfer planningTechnical workshops planningTraining planDeliverable completionTechnical assessment documentBusiness assessment documentProposed scope and rollout plan for future deliveryWorkplan for proposed next stepsStaffing plan for next stepInfrastructure plan for next stepProposed budget for next stepPresentation of proposal

Use a milestone plan to illustrate dependencies and high-level tasks

Use a Milestone plan

Post this plan on the walls in the hallways,

don't hide it in the PM's

office.

Keep it under 30 items!!

Report Dispositioning

Deciding which reports should stay in R/3 or the legacy system.

–Not all reports belong in BW. Avoid using BW as a "dumping group"

–Make cost effective decisions. Just because the report is not in BW does not mean it cannot be in a portal or on the web

–You need to make conscious decisions on what reporting needs you are going to need and how you want to accomplish this.

We will now take a look at an approach to a formal report dispositioning that has been used by a few companies.

Key questions for report dispositioning

1. Is this really a reporting need or a "want"?

2. Is the data going to be in BW at a frequency that solves the user's request (intraday reporting)?

3. Is the data needed for this report already in our BW scope?

4. Are there already a report available in R/3 ?

5. Does standard BW content exist?

6. Is it less expensive to create in R/3?

7. Are there a significant number of users?

8. Is the reporting need resource intensive?

9. Is BW cost effective in the long-run (ownership)?

Team starts by reviewing documentation tool for documentation completeness

D1Is report

documentation complete?

Request additional input from Business

Team member

Responsible Team member

acquires/documents additional information

D2Is this

an Intraday report?

D3Significant

numberof users?

D4 Is the report

system resource

intensive?

D5Does


D6Does


D7Is it less


R/3?




tool







and documented

No

Yes

No

No

Yes

Yes

Yes

No

Yes

No

D2.5 Does data exist

in "in-scope" modelsInfocube/ODS

No

Yes

No

D1a Is this a true

reportingneed

Yes


A2Total Cost of

OwnershipAnalysis


Yes

No

YesYes




No


tool

StandardR/3

ABAP/Custom

ReportWriter

OtherQuery










BW Team to forward completed detailed report specifications based on selected Reporting Tool - BW or R/3


A4 Baseline reports

Tool

An example on how to decide which reports should be in R/3 or the legacy system (printed version is easier to read)

Consider multiple ways to display the same data!!

– Deliver your reports in a consistent manner to the users (one version of the "truth"), but use different mechanisms to do so.

• Managers and executives tends to prefer simple and directed interfaces

• Casual users tends to prefer predictable structured access to the data

• Analysts and Power users tends to prefer high flexibility and unstructured access to the data.

Flat ReportingFlat Reporting• FormattedFormatted• PrintPrint• Form basedForm based• StaticStatic• Predictable accessPredictable access

OLAP ReportingOLAP Reporting• Drill DownDrill Down• Slice and DiceSlice and Dice• AnalyseAnalyse• Data Mining Data Mining • Search and discoverSearch and discover

KPI & ScorecardKPI & Scorecard FormattedFormatted• SimpleSimple• Easy to viewEasy to view• Limited navLimited nav• AggregatesAggregates

Don't underestimate the user's need to access the information in various ways.

OR OR

Balancing technical considerations with user goals.

Source: SAP

What do users really want?

What we will cover






The BW project organization

The BW project consists of five distinct parts of work:

1. Getting the data out of the R/3 system -done by the Extract & transform developer.

2. Storing the data in BW – done by the BW developer

3. Presenting the data – done by the presentation and the portal developer(s)

4. Working with the business – done by the business analyst

5. Managing the project – done by the project manager and the BW architect

BW is very much like a traditional data warehouse project with very different technology – unfortunately is has a steep learning curve

So how many people do I need and what are they all doing?

Determining how many people you need is based on the scope and the timeframe of the development effort. It is just as risky to “over staff” a project as it is to not have the right people on-board. When it comes to BW projects, quality is more important than quantity. – a good BW developer can achieve in one hour what is takes a novice days to figure out.

However some good examples from what other companies have done exists and we have included them in this presentation

So, is this going to like another two year R/3 project?

BW projects, like all other data warehouse projects should be interactive in nature. This means that it is important to show value to the business rapidly. It would be a mistake extend the period between each go-live past 6 months. We therefore recommend the increasingly popular Rapid Application Development (RAD). This allows you to deliver a BW solution often in less than 2-4 months. – BW projects are very different from R/3 projects

The BW project organization

Some examples: A small BW project for single subject area (i.e. billing, inventory or accounts payable).

4-5 team members and normally 3-6 months duration depending on scope

Basis and functional R/3 support

B us iness ana lys tP resen ta tion deve lope r

B us iness team

B W A rch itec tE T L deve loper

T echn ica l team

P ro jec t M anager.

P ro jec t sponsor

These are roles not positions. (sometimes one team member can fill more than one role)

Some examples: A mid-sized BW project for single complex subject area (i.e. cost and profitability, internal billing).


B WA rch itec t

S r. B us iness anay s tB us ines s ana lys t

B us inessA na lys t(s )

S r. ET L dev e loperE T L deve loper

E x trac t, T rans form sand Loads

S r. B W deve loperB W deve loper

D ata M anagem ent(In foC ubes & O D S )

S r. P res enta tion dev loperP resenta tion deve loper

P resen ta tionD eve loper(s )

P ro jec t M anager

P ro jec t sponsor/S teering C om ittee



Some examples: A large BW project for multiple subject areas (i.e. sales, finance and material management)



P orta l deve lope r(s )

B W A rc h itec t

B us ines s ana lys t/(s ub -team lead)B W dev e lope rP res en ta tion deve loper(s )E T L dev e lope r

S a les T eam

B us iness ana ly s t/(s ub-team lead )B W deve lope rP resen ta tion deve lope r(s )E T L deve lope r

F inanc e T eam

B us iness ana lys t/(s ub -team lead )B W deve loperP res enta tion dev e loper(s )E T L dev e loper

M ate ria l M gm t. T eam

P ro jec t M anager

P ro jec t spons or/S teering C om ittee


What we will cover






The Use of “Ambassadors”

Getting the PowerUsers involved early is important to the overall success of a Data Warehousing project

To help support the businesses that already has gone-live, a strong local community of

“ambassadors” is needed. If you don’t have them, on-going projects may get “bogged down” with

basic support of reports.

A BW Data Warehouse Approach at a Company

Should a set of Ambassadors be part of the rollout-strategy?

Many regional data warehousesStrong data knowledge in the organizationsExperienced non-BW Report writers

BW Data Warehouse Alternatives

Issue

How can this be done with minimal organizational disruption?

Issue

CONTIN

UECON

TINUE

TOP-DOWN APPROACH

Building a global data warehouse for Ericsson.,and proceed sourcing data from legacysystems driven from a top-down approach where reports are also created centerally.

CHANG

ECHA

NGE

BOTTOM-UP APPROACH

Focus on a bottom-up approach where the DW project will prioritize supporting and delivering DW solutions, but where businesses are activly involved in developing reports.

The company

Lessons Learned – Local Resources

Of the total work of 7,061 hours for presentation development from August though October, 58% of the enhancement work was performed by local resources.

This allowed the central team to change their focus on the next implementation, while ensuring local support and empowered Ambassadors to help the users in each organization.

Great

Feature

Business Content

Oct. 01Jan. 02

Mar. 02May. 02

Jun. 02

Germany, Holland

USA

Austria

Spain

Italy

TASKS (partial list):

• Customize for local needs• Reconcile old and new reports• Local support and delivery • Ensure reusability of solutions• Ensure change management

1. Presentation developer

2. User requirements analyst

Ambassadors(PowerUser)

Ambassadors(PowerUser)

Some Benchmark Indications on Ambassadors..

Survey of 84 companies: The Conference Board.

5 0 % S u c c e s s f u l




N o( 1 0 % )

Y e s( 9 0 % )

B u s i n e s s U n i t s I n v o l v e d i n D e v e l o p m e n tIncreased business involvement, increases the probability for data warehouse project success.

Note

Can you use a BW Ambassador

in your user organizations?

For more information contact:

Dr. Bjarne Berg,Assistant Professor

Lenoir-Rhyne College

[email protected](704) 604-0010

What we will cover






What Is the Gartner Group Saying About BW?

1. On Alternatives:“Getting data from R/3 for analytical purposes is extremely difficult, requiring complete understanding of its 8000+ data models and all its embedded relationships.” Two alternatives exists; building a custom data warehouse or use Acta technologies Rapid Marts for R/3. Currently most organization rely on handwritten ABAP programs to get data out of R/3 for reporting.”

2. On when to use the product:Consider BW when “……. SAP business content represents at least 50% of the total needed”

3. On the future:“By 2008, more than 80% of SAP’s R/3 install base will implement BW to meet their operational focused decision support needs (80% probability).”

Business Benefits of BW – more detailsB. Best PracticeAccording to the Gartner Group, organizations that are pursuing a SAP ERP strategy with the a high volume of transaction data processing in SAP, the logical choice for a decision support environment is SAP’s complimentary tool Business Information Warehouse. The Gartner Group estimates that “By 2008, more than 80% of SAP’s R/3 installed base will implement BW to meet their operational focused decision support needs (0.8 probability).”

C. Cost AvoidanceMost upgrades of the SAP system will change the underlying table structures and will require a rewrite of extract programs being used in an alternative data warehouse solution. Since any custom developed extract programs will continue to evolve, and will also include complex extract routines and logic, the work on analyzing the changes and recode any custom developed extract programs would require substantial resources, compared with an existing support for upgrade path between BW and R/3.

D. Savings from Other SAP Offerings

Web delivery and SAP StrategyThe opportunity costs of not rapidly being able deliver these solution to an organization is hard to quantify, but a decision support system must be able to support web initiatives quickly, and that an initiative will need data “closer” to the transactional system, both in time and in terms of data consistency and data quality.

It also allows the organization to leverage the investments in R/3, and the organizational knowledge of SAP to the fullest extent as a strategic investment. This is done by leveraging the existing resources that includes Basic people and ABAP programmers and could also include a common platform for any web portal development. BW could provide for the foundation, as a data provider, for an web strategy that might also include other non-SAP industry tools and offerings.

Benefit: As a data provider, BW enables the organization to leverage a variety of tools and packages and maximizes the strategic investments made in SAP.

Business Benefits of BW – more details

D. Savings from Other SAP Offerings (continued)Integrated Product Offerings: Another observation is the integral part BW plays in SAP’s future, and current, decision support and e-commerce strategy. BW introduces the opportunity for the organization to have an increased spectrum of support capabilities, it also may become a cornerstone in a larger decision support architecture that encompasses e-consumer business, business to business sales, strategic enterprise management, advanced planning and optimization, and a variety of other modules and initiatives from SAP..

D. Savings from Other SAP Offerings (continued)

Industry trendsTwo major observations in this area can be made. First, the fact that many public sectors are moving towards installing BW as an integral part of their decision support architecture. This indicates that BW might become the industry standard of the future for governmental organizations who are using SAP.

The costs of not being part of this trend is hard to quantify, but include the cost of training resources on the custom system, versus being able to leverage knowledge of people in the industry, as well as a potential more complex integration of these systems in the future if the organization is moving towards data sharing and decision support sharing with other governmental organizations.

Benefit: Enables the organization to leverage future solutions


E. Faster DeploymentThe time to develop new systems, or enhance existing systems, has been identified as a critical area by many decision support users. BW will reduce this development time through leveraging the existing pre-delivered content from SAP. This includes standard extractors, common load routines, standard data stores, and pre-delivered reports and interface(s). Industry best practices estimates that up to 60-80% of the pre-delivered content may be used, while the remanding would be customized to meet the needs of an organization. The Garter Group, stated: “SAP supplied content significantly reduces the development efforts for customized applications” (P-10-3024 research note).

The leveraging of the business content, especially the standard extractors, provides the organization the ability to more quickly being able to respond to user needs and changing business requirements. As an example a common delivery cycle of an application area of BW is between four and six months, while a common data warehouse delivery cycle is between six and twelve months (almost twice as long).


F. Faster Decision MakingInformation AccessToday, any non-BW data warehouse must load data from the R/3 system in stages throughout the evening in order to complete the load within a 24 hours time period. This is due to the lack of any mechanisms for tracking only changed records by non-SAP tools. The load time is also increasing as more data is captured in the source system. From a management perspective, this means that data may not always be available to the end-users in a timely manner.

BW provides for a substantial reduction of the load time through processing only the changed records for most of the extractors. This means that data can be loaded at pre-set intervals and the data load time would decrease. From a management perspective this increases the data delivery speed to the warehouse and thereby assures the users with more timely access to new data. Data could also be processed at short intervals and be used to support more “near time” applications. Benefit: Users and managers gets earlier access to information

Query Speed ImprovementThrough the use of pre-aggregates suggested by BW, the organization will be able to reduce query performance substantially. This is accomplished through the use of system defined and recommended pre-aggregates based on observed usage patterns, and automatic routing of queries to these aggregates. Thereby, BW may substantially reduce the query delivery time to the end-user. Benefit: Users gets faster access to information


F. Faster Decision Making (continued)Reduced Reconciliation EffortA substantial portion of a data warehouse effort is spent on reconciling data from the source system. During a data warehouse development project, one objective is to move “closer” to the transactional data. This means sharing definitions across the enterprise and groups, assuring that the transaction system captures the correct data in an appropriate format, while spending less time on stabilization and reconciliation efforts. Custom-made extract routines and complex logic is needed to capture data across many modules in SAP, to be able to see the whole process flow from a record perspective.

BW will move the organization closer to the source in terms of definitions and in load logic via standard extract programs created by SAP. Data integration may therefore occur at many stages, including during the data load, cleansing or during querying of the data structures. The extractors will be maintained by SAP and the data warehouse team can focus on the internal organization of the data stores and the load logic rather than the complex extract programs within R/3. This leads to a simplified environment where the data provided will more closely reflect what is in the R/3 system.

This area of the business case can therefore be summarized as a reduction in the technical effort of reconciliation of data across R/3 modules and a closer alignment to shared definitions between the transactional and the decision support environment. Benefits: Users spend less time on reconciling data and more on analyzing it


G. Improved Customer ServiceLeveraging the SAP architecture will allow the organization to externalize the data easier in an integrated DSS environment. This include allowing customers to review their orders on-line, checking on their shipment records, as well as reviewing items such as their payment and maybe even the organization’s inventory.

The externalizing of the data is a dramatic increase in customer service and reduces the paper documents needed to support the customer. However, before the organization can achieve this the organization must create the architectural infrastructure that will enable us to meet the data needs of the end-users. BW can be the foundation for web-enabling the data warehouse in a packaged solution that can rapidly be employed.

Benefit: The ability to externalize the data over the web


I. Standardization of Tools As the industry matures, the use of standardized interfaces and protocols will increase. BW’s open-ended architecture is based on Microsoft’s ODBO standard. This emerging standard, is the application equivalent of the 1990s standardization of database interfaces via ODBC. Today most “best-of-breed” tools support this standard, including Microsoft, InSight, Business Objects, Brio, Arcplan, Cognos and others.

This allows the users to choose between a variety of front-end tools, integrating new presentation tools are simplified, and users can leverage the best tool for their situation. Future application can be written using these industry standard tools, while costly complicated database and application integration efforts can be alleviated.

Benefit: Simplified user access to data and higher flexibility of leveraging presentation and web tools.


The BW Team Members – Role descriptionsBW PROJECT MANAGERThe project manager should be a dedicated resource, and not be involved in other major projects. This role is the key to the project's success. The manager is responsible for:

•Creating and maintaining all project plans and organizing the work environment.•Making timely decisions and delegating tasks.•Effectively communicating with all members of the team.•Facilitating project meetings.•Understanding key concepts of Data Warehousing and their implications.•Managing "crisis" and issues effectively.•Assuring that dead lines are met and quality is delivered.•Managing time and expense.

BW ARCHITECTThe data warehouse architect should be an individual who is familiar with all technology aspects of data warehousing. The data warehouse architect should have participated on more than one successful data warehouse project in a key technical role, and should have a thorough understanding of front-end tools, load tools, data base engines, data design and the technical infrastructure. The data warehouse architect is responsible for:

•Integrating all applied technologies and design the technology architecture for all integrated systems•Supervising the technical aspect of the data warehouse.•Leading tool evaluations and provide recommendations to the project leader.•Providing input and recommendations on technical issues to the project leader.•Reviewing technical work of other team members for quality assurance•Reviewing and participating in testing of data design, tool design, data loads and presentation system design.•Transformations, gateways, networks, and hardware selection and sizing.

BW DEVELOPERThe BW developer is responsible for creating the data objects for the reporting areas. This includes designing all structures within BW that supports the reporting, such as ODS objects, InfoCubes and drill-through cubes (views). This also include creating data models for the subject areas, as well as the formal approval process for each object. The data structures are based on the user requirements gathered during the project’s interview phase, and enhanced during the blueprinting phase. core requirements for the data model comes from user inputs and the work conducted by the business analyst. Key deliverables include data models for each data structure developed, test planning and execution, and documentation of extensions to standard business content, a data dictionary and an implementation of master data, hierarchies and changing dimensions. In addition this individual is responsible for the performance testing and tuning and the development of aggregates, indexing strategies and partitions. The role of BW developer is a key to the overall project success, and the individual must have very strong BW skills with implementation experience from other BW systems.

EXTRACT AND TRANSFORM DEVELOPERS The extract and transfer data developer is responsible for designing data extracts and reviewing the data available on the SAP R/3 legacy system. It involves reviewing existing load routines and validation programs, creating all objects and mappings from R/3 to BW, and validating standard content provided. The developer will create custom developed validation rules and generic extracts as needed to support the level of customization needed in the ODS and InfoCubes.

The developer should also understand the nature and quality of the data and should provide a data dictionary of the source data, if this is not available from the source system. Key deliverables from this group is the source – target mapping of each field used in BW to SAP R/3 and automated extract, load, validation, cleansing and reconciliation programs from source system(s) to BW. During the realization phase, the extract and transform developers are designing each individual extract needed for moving data from R/3 components to InfoCubes, or ODS, that are being designed by the data architect. This includes validation of selection criteria, filtering, load logic (ABAP), data cleansing, source-target mapping validation, and documentation of each extract design for the InfoCubes, ODS objects in scope. The individuals staffed in these roles must have very strong R/3 and BW experience with solid understanding of ABAP coding as well.

The BW Team Members – Role descriptions

BUSINESS ANALYST The Business analyst is responsible for the overall development of reports that supports the functional of the project from an BW perspective. During blueprinting, this individual is responsible for gathering detailed reporting requirements from the business users and existing reporting groups within the organization. A key deliverable from this effort are detailed reporting requirements for areas such as the general ledger, accounts payable, accounts receivable, reconciliation efforts, closing procedures, cost and profit center accounting, and overhead management.

The ideal candidate for this position should have detailed knowledge of the industry that the company operates in, and a solid understanding of the reporting needs of such an organization. The individual should also have strong communication skills and the ability to plan, conduct and document interviews with managers and users. This analyst will also be managing the user acceptance testing and feedback process from representatives for the user community, and assure that those requirements are being met by the reporting system being built. During the roll-out of the system the business analyst are engaged in the user documentation development as well as the development and execution of the user training.

PORTAL DEVELOPERThe developer in this position is responsible for the design and development of user roles for accessing the SAP BW environment. This includes the creation of security requirements for the user interface, BW role reconciliation, as well and integration of reporting help features, collection of external data for reporting purposes and the integration between BW reports and jump-points to the transactional system. The individual in this role is also responsible for the design and development of standard templates for reports delivered by the development teams, as well as the user acceptance process for these templates. In a SAP Portals environment, the individual is also responsible for the content management section of the portal and the configuration on the navigation bars and initial launch pad.

The individual staffed in this technical position should have a strong reporting and design background from SAP BW as well as development knowledge of portals and the integration of standardized reporting environments. Prior industry experience would also be helpful. The individual must also have solid programming experience in HTML, Java and XML.


PRESENTATION DEVELOPERS (a.k.a. report writers)The presentation developer is responsible for designing core reports for the functional area that they support. This includes reviewing business requirements, existing reports, and working with the BW developers to assure that the business requirements are supported in the cube and/or the ODS design, and creating template reports for user acceptance based on requirements.

The presentation developer is also an individual who has a specific tool background. The developer may later work on 3rd party presentation tools and SAP’s Business Explorer. The developers must assure data security, user friendly reports, "drill-down" features, as well as a flexible design of data hierarchies and a logical and easy to use Graphical Unit Interface (GUI) for end-users. Finally, the developer must assure that the front-end tool provides all functionalities supported by the logical data model(s) and that the tool takes advantage of the physical database design features.

The design work also includes a detailed description of each access point, the navigation of access points, as well as a detailed role description with association to the pertinent reports. The presentation developers also work with the portal developer to integrate roles with the existing roles in the web portal.


managing a bw project

Documents