© 2005 wellesley information services. all rights reserved. scope, prioritize, budget, and staff an...

© 2005 Wellesley Information Services. All rights reserved.

Scope, Prioritize, Budget, and Staff an SAP BW Implementation Project

Joyce RedmonInternational Paper

Dr.Bjarne BergLenoir-Rhyne College

2

What We’ll Cover …

• The project preparation phase• Organizing your team• Setting and managing project scope• Budgeting and prioritizing efforts• Customization vs. standard content• Ideas for quick-hit implementations• The drivers for your project and legacy systems• The strategic plan• Wrap-up

3



4

Introduction

• Planning an SAP BW project can be quite intimidating • It is hard to decide where to start and how to scope,

size, staff, and budget the project• You also have to put processes in place that minimize

the risks and leverage the standard content as much as possible• This session will give you some ideas on how to

approach the tasks of getting your BW project organized and create a strategic plan for your enterprise

data warehouse

We will keep a rapid pace and give you real examples to illustrate the topics.

5



6

• Developer training should start early for all project team members

• SAP R/3 skills are not easily transferable to BW; hands-on experience is needed (it is very hard to learn while being productive)

• Quality is much more important than the number of team members A skilled BW developer can accomplish in one day what

three novice developers can do in a week

Timelines and Staffing Plan: Lessons Learned …

7

• Project and cost estimates should be based on experience levels

• Plan on formal knowledge-transfer from external resources from day one. Link inexperienced with the experienced members.

• Have identified “go-to” resources available in all areas (make a list)

Timelines and Staffing Plan: Lessons Learned … (cont.)

Don't underestimate the benefits of having strong developer skills on your team – R/3 experience does not substitute for hands-on BW skills

8

Example: Small BW Project for Single Subject Area (e.g., Billing, Inventory, or Accounts Payable)

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

scope

Basis and functional R/3 support

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

Project Manager

Business team Technical team

Business analyst

Presentation developer

BW Architect

ETL developer

Detailed role descriptions are included with this presentation on the take-home Conference CD

9

Example: Mid-sized BW Project for Single Complex Subject Area (e.g., Cost and Profitability, Internal Billing)


8-10 team members and normally 2-4 months duration depending on scope

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

Project sponsor/

Steering Committee

Project Manager

BW

Architect

Business

Analyst(s)

Extract, Transforms

and Loads

Data Management

(InfoCubes & ODS)

Presentation

Developer(s)

Sr. Business analyst

Business analyst

Sr. ETL developer

ETL developer

Sr. BW developer

BW developer

Sr. Presentation dev

Presentation developer

10

Example: Large BW Project for Multiple Subject Areas (e.g., Sales, Finance, and Material Management)


15-25 team members and normally 6-18 months duration depending on scope

Portal developer(s)

BW Architect

Business analyst/(sub-team lead)BW developerPresentation developer(s)ETL developer

Sales Team


Finance Team


Material Mgmt. Team

Project Manager

Project sponsor/Steering Committee

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

11

On-Boarding and Training

Ideal Years Experience (minimum)

Training days (if new in the role )

In-house training

days

BW Developer 2+ 15 3-5

ETL Developer 3+ 15-20 3-5

Presentation Developer 1+ 5-10 3-5

Project Manager 5+ 10-15 3-5

Business Analysts 5+ 5-10 3-5

Don’t underestimate the value of in-house, hands-on training in addition to formal SAP training classes

Note

12



13

Why Use Change Control?

• Enforce consistency between business/process and development project plans (i.e., dates, case names)

• Ensure that previously approved scope is re-planned appropriately• Shows responsiveness and provides a forum for

new requests

• Accurate Resource Planning Reduces impact on other planned work Strategic staffing vs. reactive

staffing Make best use of resources

14

Defining the Scope

• For the first Go-Live, keep the scope as simple as possible, in an area with solid standard BW content (i.e., Accounts Payable, Accounts Receivable, G/L, or COPA)

• You have only three dimensions to work with:

If one of these dimensions changes, you have to adjust at least one of the others or the quality of your BW system will suffer

Caution

15

The Scope Agreement

• First, determine what the business drivers are and make sure you meet these objectives. Define the scope in terms of what is included, as well as what is not included.

• Make sure you obtain approval of the scope before you progress any further. All your work from now on will be driven based on what is agreed to at this stage.

RequirementsGathering

(Scope Planning)

Scope ChangeControl

ProjectInitiation

Scope Management Processes

Project ScopeStatement

(Scope Definition)

Project Committment(Scope Verification)

Source: PMI

16

The Scope Agreement (cont.)

• As part of the written scope agreement, make sure you implement a formal change request process. This typically includes a cost-benefit estimate for each change request and a formal approval process.

Change management is done to manage scope, timelines, and competing business requirements

17

Managing Scope – The Change Control

• Define change (what is a change?)• Establish procedures and when to use

change process• Documentation

Must be able to link to a requirement

Description Timing and dependencies Test case and data availability

• Establish procedures and when to use change process

Work effort to complete development

Date when available for test Resource availability Impact to schedule Impact to existing development

Risk Management Processes

Scope ChangeControl

RiskAssessment

ActionItems

!

BW is an integrated environment. Late changes in one area can have large impacts across the system

18

Change Control Process – Example

Identify change, evaluate need, and

submit, if valid.

Business Teams

Change Control DB

Assign to responsible Track.

Change Control DB

Operating Model Integration Team

Analyze request and estimate

impacts.

Change Control DB

Tracks

Escalate request to next level in

organization for decision/review.

Change Control DB

Make/review decision.

Tracks

PMC / PMOProject Integration Team

Team LeadTracks

Escalation Levels

1. Team Lead

2. Project Integration Team

3. Project Management Org

4. Project Management Council

Execute action plans and close change request.

Change Control DB

PMC / ESCPMO

EDGE Integration TeamTeam Lead

Tracks

Change Control DB

Current scope of work?

Update to relevant release and notify

Business. No further action at this time.

Change Control DB

No

Yes



Based onimpact, can a

decision be made at this level?

No

Yes

Communicate resolution to

Business.

Team LeadTracks

WouldBusiness like further

review?

Yes

Identify change, evaluate need and

assign to responsible Track.

Change Control DB

Tracks

No

Change control processes should be formal, with escalation rules that can be used if disputes occur.This example is from a large SAP project that included R/3 and BW and needed strong scope control.

19

Determining Scope Through a Release PlanJuly Aug Sept Oct Nov Dec Jan Feb MarApr May Jun July Aug Sept Oct Nov Dec Jan Feb Mar Apr May Jun July Aug Sept Oct Nov Dec

Procurement details & summary receipts

Contracts

Settlements

Inventory

Sales

Master Agreements

Contractor

General Ledger

A/R & Credit Mgmt

SNOP

Cost

Procurement

Inventory Planning

Source Analysis (enhancements)Sales opportunity

Blueprinting Realization Cutover and go-live

2005 20062004

Tax-severance & processor

Plan multiple implementations and write a long-term outline that may change (using a formal change request process).

20

Determining Scope Through a Release Plan (cont.)

Project Timeline Dev Effort 2005 2005 2005 2005 2005 2005 2005 2005 2005 2005 2005 2005 2006Months Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan

Dev Begins

Test Begins Go-Live

Jun-04 Oct-04 Mar-05 Version A 23.40 1.46 5.85 2.93Jun-04 Oct-04 Mar-05 Version B 5.00 0.31 1.25 0.63

28.40 1.78 7.10 3.55

5Sep-04 Feb-05 Jul-05 Version C 32.86 6.57 2.05 2.05 2.05 2.05 8.22 4.11Sep-04 Feb-05 Jul-05 Version D 19.10 3.82 1.19 1.19 1.19 1.19 4.78 2.39Sep-04 Feb-05 Jul-05 Version E 5.00 1.00 0.31 0.31 0.31 0.31 1.25 0.63Sep-04 Feb-05 Jul-05 Version F 5.00 1.00 0.31 0.31 0.31 0.31 1.25 0.63

61.96 12.39 3.87 3.87 3.87 3.87 15.49 7.75

5Jan-05 Jun-05 Nov-05 Version H 32.23 6.45 6.45 6.45 6.45 6.45 2.01 2.01 2.01 2.01 8.06 4.03Jan-05 Jun-05 Nov-05 Version I 10.70 2.14 2.14 2.14 2.14 2.14 0.67 0.67 0.67 0.67 2.68 1.34Jan-05 Jun-05 Nov-05 Version J 40.00 8.00 8.00 8.00 8.00 8.00 2.50 2.50 2.50 2.50 10.00 5.00

82.93 16.59 16.59 16.59 16.59 16.59 5.18 5.18 5.18 5.18 20.73 10.37

5May-05 Oct-05 Mar-06 Version K 30.00 1.50 1.50 1.50 6.00 6.00 6.00 6.00 6.00 1.88 1.88 1.88 1.88May-05 Oct-05 Mar-06 Version L 30.00 1.50 1.50 1.50 6.00 6.00 6.00 6.00 6.00 1.88 1.88 1.88 1.88

60.00 3.00 3.00 3.00 12.00 12.00 12.00 12.00 12.00 3.75 3.75 3.75 3.75

5Sep-05 Feb-06 Jul-06 Verison M 10.00 0.50 0.50 0.50 2.00 2.00 2.00 2.00 2.00Sep-05 Feb-06 Jul-06 Verison N 25.00 1.25 1.25 1.25 5.00 5.00 5.00 5.00 5.00

35.00 1.75 1.75 1.75 7.00 7.00 7.00 7.00 7.00

2005 2006Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan

Design 0.15 Effort months 30.8 30.6 27.0 23.5 32.5 34.4 26.7 18.9 24.2 31.5 21.1 10.8 10.8Test 0.25 FTEs 28.0 28.0 28.0 28.0 28.0 28.0 28.0 28.0 28.0 28.0 28.0 28.0 28.0Go-live 0.25 month ofGo-live 0.125 month after over -under supply (2.8) (2.6) 1.0 4.5 (4.5) (6.4) 1.3 9.1 3.8 (3.5) 6.9 17.3 17.3

Design

Test Go-Live

Develop

Develop Test Go-Live

Develop

Go-Live

Develop Test

Design

Test

21

Post this plan on the walls in the hallways. Don't hide it in the PM's office!

Keep it under 30 items!

V1 Wave 2 V1 Wave 3 V1 Wave 4Blueprint

End of Blueprint 11/1/2004 11/1/2004 2/4/2005

RealizationStart of Prototype Cycle 1 10/18/2004 10/18/2004 12/27/2004End of Prototype Cycle 1 11/12/2004 11/12/2004 2/11/2005Start of Prototype Cycle 2 10/18/2004 11/15/2004 2/14/2005End of Prototype Cycle 2 11/12/2004 1/28/2005 4/8/2005Start of Integrated Unit Test 11/15/2004 1/31/2005 4/11/2005End of Integrated Unit Test 12/10/2004 3/4/2005 5/13/2005Start of System Test Cycle 1 12/13/2004 3/7/2005 6/13/2005End of System Test Cycle 1 1/28/2004 4/29/2005 7/29/2005

Final PrepStart of Integration Test Cycle 1 1/31/2005 5/2/2005 8/1/2005End of Integration Test Cycle 1 3/11/2005 6/3/2005 9/2/2005

Milestones

Writing the Milestone Plan

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

22

Example: Infrastructure to Meet the Milestone Dates

Week starting 7/25

8/1

8/8

8/15

8/22

8/29

9/5

9/12

9/19

9/26

10/3

10/1

0

10/1

7

10/2

4

10/3

1

11/7

11/1

4

11/2

1

11/2

8

12/5

12/1

2

12/1

9

12/2

6

1/2

1/9

1/16

1/23

1/30

2/6

2/13

2/20

Mth.End

Conv. Mock

Mock

Cut Over

Mth End

Mockx0V

Mock

MockMth End

Erly Ordr

x0V Conv.

x0Q Conv.Integrated Unit Test

Regression Prior Waves

I/G x0V/x0Q Mig & Rgrs.

R04V1W4

BW 3.5 UpgradeBreak-Fix Window

P x0V/x0Q Mig& Rgrs.

System Test 1Month.End

Integration Test 2

I/G x0V/x0Q Mig & Rgrs.

Month End

x0V Conv.

Prod. Conv

Early Orders

Integration Test 2

March 2006 / R05Project W1Project X (1)

Nov. 2005 / R04V1W4BW 3.5 Upgrade

Data/Mig

Proto 2 Support Pk

Integration Test 1

Prod. Conv

P x0V/x0Q Mig& Rgrs.

System Test

x0Q Conv.

x0V Mock

Regression Prior Waves Integration Test 1Conversions

Conv.

Training Conv. Training Data Staging

Conversions

Proto 1 Support Pk Apply/Tst

TPR Fix Support Pk

Month. End

Conversions

Mock

P

I

P

P I

P I

I G

PI G

I/GP

G

G

G

7/28-7/29R04I xTS

9/7-9/8 R04P x0V

9/17-9/18R04P x01

10/15-10/16R04I x01

10/5-10/6 R04I x0V

9/14-9/15 R04P x0Q

10/12-10/13 R04I x0V

10/4

9/5R05P xT0 9/22-9/23

R05I xT0

10/18-10/20R05P+spt pk xTS

10/17 spt. Pk xT0

11/10-11/11R05I xT0

12/15-12/16R05I ITC2 Mock Prep

In a complex project with multiple development environments and releases, it is important to have a well-communicated and detailed chart to make sure everyone is in-sync at all times

23



24

Budgeting Process Steps

We will now take a look at how each of these steps can be done in practice

• Create the milestone plan and the scope statement first before attacking the budgeting process!

• Start the budgeting process by estimating the workload in terms of the development effort

• Budgeting Process Steps:1. Size the BW effort based on the scope 2. Prioritize the effort3. Map the effort to the delivery schedule4. Plan for number of resources needed based

on the scope, delivery schedule. and the effort

25

1. Size the BW Effort Based on the Scope (Real Example)

Customization

Tech. Dev. infocube

Extraction and transforms

Report and roles

Security and scheduling

Web develop-

ment

User support/ planning

Project mgmt and admin

System docs & manuals

Tech infra-structure

Bus. Analysis, training, req.

gathering, change mgmt.

Total Hours

FinancialsL General ledger line item (ODS) 216 229 188 101 132 134 100 79 150 403 1,732M COPA 158 286 153 127 153 152 120 94 180 470 1,893L Prod cost planning released cost

estimates (COPC_C09)216 229 188 101 133 135 100 79 150 403 1,734

M Exploded itemization standard product cost (COPC_C10)

238 286 216 126 153 152 120 94 180 470 2,035

L Cost and allocations (COOM_C02)

216 1144 188 101 132 135 100 79 150 403 2,648

M Cost object controlling (0PC_C01)

238 286 216 137 153 152 120 94 180 470 2,046

Order L Billing 216 229 187 101 132 135 100 79 150 403 1,732L Sales order 216 229 187 101 132 135 100 79 150 403 1,732L Acct. Rec. (0FIAR_C03) 216 229 187 101 132 135 100 79 150 403 1,732

Deliver L Shipment cost details

(0LES_C02)216 229 187 101 132 135 100 79 150 403 1,732

L Shipment header (0LES_C11) 216 228 187 101 132 135 100 79 150 403 1,731L Stages of shipment (0LES_C12) 216 228 187 101 132 135 100 79 150 403 1,731

L Delivery data of shipment stages (0LES_C13)

216 228 187 101 132 135 100 79 150 403 1,731

L Delivery service (0SD_C05) 180 229 133 101 132 134 100 79 150 403 1,641Planning and Scheduling

L Material Movements (0IC_C03) 216 457 132 101 132 134 100 79 150 403 1,904

M APO Planning 277 832 216 127 153 152 120 94 180 470 2,621M SNP Integration 277 832 216 127 153 152 120 94 180 470 2,621

Manufacturing Processes M Production Orders 277 832 216 127 153 152 120 94 180 470 2,621M Cross Applications 277 832 216 127 153 152 120 94 180 470 2,621

Total Hours 4,298 8,074 3,587 2,110 2,656 2,681 2,040 1,606 3,060 8,126 38,238

Remember that your sizing also has to be based on the team’s experience and skill level

26

2. Prioritize the Effort

Financials qtr 1 qtr 2 qtr 3 qtr 4 qtr 1 qtr 2 qtr 3 qtr 4 qtr 1 qtr 2 qtr 3

General ledger line item (ODS)COPAProd cost planning released cost estimates (COPC_C09)Exploded itemization standard product cost (COPC_C10)Cost and allocations (COOM_C02)Cost object controlling (0PC_C01)Order Billing Sales orderAccounts receivables (0FIAR_C03)Deliver Shipment cost details (0LES_C02)Shipment header (0LES_C11)Stages of shipment (0LES_C12)Delivery data of shipment stages (0LES_C13)

Delivery service (0SD_C05)Planning and Scheduling Material Movements (0IC_C03)APO PlanningSNP IntegrationManufacturing Processes Production OrdersCross Applications

2005 2006 2007

The next step is to prioritize and outline the effort on a strategic timeline

Make sure your sponsor and the business community agree with your delivery schedule

27

3. Use Project Estimates and Timeline to Create Project Load Plan

There are 480 available work hours per project member per quarter. Knowing this, we can plan the number of team members we need.

Financials qtr 1 qtr 2 qtr 3 qtr 4 qtr 1 qtr 2 qtr 3 qtr 4 qtr 1 qtr 2 qtr 3

General ledger line item (ODS) 866 866 1,732COPA 946.5 947 1,893Prod cost planning released cost estimates (COPC_C09)

867 867 1,734

Exploded itemization standard product cost (COPC_C10)

1017.5 1017.5 2,035

Cost and allocations (COOM_C02) 1324 1324 2,648Cost object controlling (0PC_C01) 1023 1023 2,046Order Billing 866 866 1,732Sales order 866 866 1,732Accounts receivables (0FIAR_C03) 866 866 1,732Deliver Shipment cost details (0LES_C02) 866 866 1,732Shipment header (0LES_C11) 865.5 865.5 1,731Stages of shipment (0LES_C12) 865.5 865.5 1,731Delivery data of shipment stages (0LES_C13)

865.5 865.5 1,731

Delivery service (0SD_C05) 820.5 820.5 1,641Planning and Scheduling Material Movements (0IC_C03) 952 952 1,904APO Planning 1310.5 1311 2,621SNP Integration 1310.5 1311 2,621Manufacturing Processes Production Orders 1311 1,311 2,621Cross Applications 1311 1,311 2,621

Total 1,813 1,813 4,232 4,232 2,598 2,598 4,283 4,283 3,573 6,195 2,622 38,238

2005 2006 2007

Note

28

4. Result: Good Input for the Staffing Costs and Planning …

Many companies plan a 60%-40% mix of internal and external resources for a first Go-Live. Also, most use $50-$90 per/hr for internal budgeting and $90-$170 per/hr for external resources.

Number of team members

-

2

4

6

8

10

12

14

qtr 1 qtr 2 qtr 3 qtr 4 qtr 1 qtr 2 qtr 3 qtr 4 qtr 1 qtr 2 qtr 3

Use this information to plan for training, on-boarding, and staffing:

Tip

This spike in resource needs is due to an overlap in the delivery schedule

Now might be a good time to review that decision …

29



30

Approximate Usage of Standard Content BW 3.5 (percentage of overall development effort)

0

20

40

60

80

100

* Rapidly improving content

Standard Content vs. Customization

• All functional areas are not equally supported by strong standard BW business content. Some areas have so much you can leverage, others will require more enhancements depending on your requirements.

The differences are often due to customization on the R/3 side by companies and/or industry solutions

31

Standard Content vs. Customization (cont.)

• Start gathering your requirements and break those down to data requirements

• Map the data functional requirements against standard content (InfoCubes)

• Take the standard model of that InfoCube (provided by BW admin workbench), and add your additional data fields into the model

• Map the new data fields to the source and hand the logical model to the BW developer

Billing

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

Customer

Sold-toShip-toBill-toPayerCustomer classCustomer 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 codeDivisionDistribution channelSales organizationSales group

Logistics

PlantShipping/receiving point

Document details

Sales 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

Do not remove fields from the standard cube, and do not rename objects (you will not be able to take advantage of current and future delivered queries and cockpits)

32



33

Ideas for “Quick-Hit” BW Implementations

• Limit the first Go-Live to one source system (easier to source)

• Think about quick visibility to enterprise consolidated data

Some easy InfoCubes to implement (document level)

Sales Orders

Deliveries

Billing

Accounts receiveables

Accounts payables

General ledger

Purchase orders

For a quick-hit Go-Live, limit yourself to as much standard content as possible in areas that have high-impact

34

Ideas for “Quick-Hit” BW Implementations (cont.)

Keep the scope focused and use a simple approach:

No functional or technical specs are used in this approach. The user acceptance session is used to refine requirements.

Activate standard content

Review data quality issues

Create 2-3 sample queries

Load infocubeUser

acceptance session

Request for modifications

In-

scope?

Rejection

In-future

scope?

Make enhancements

Test

Deploy

Yes

No

No

35



36

Your Company's Strategy

• What are the drivers for the project?• Why do you need visibility – increase revenue, decrease

expenses, increase competitive advantage (how? and how do you measure this?)

• Who are the company’s customers – what do they have in common? Who are their vendors (your competitors)?

• How can the company’s customers be segmented? What changes are occurring in the customer base? Where is the company heading?

The enterprise data warehouse should sets the stage for effective analysis of information to make strategic decisions and identify competitive advantages

(proactive and not retroactive!)Tip

37

Your Company's Strategy (cont.)

• Typically the current state of Data Warehousing (DW) is a combination of centralized and decentralized resulting in inefficiencies

• Moving to a centralized DW should enable future projects to reduce costs by leveraging common hardware, standardizing on software, and leveraging a pool of technical resource (is your project a cost-saving project?)

• How can you provide information not data for decision making (KPIs?)

38


• Is your company a low-cost provider, a research leader, a premium provider? The answer will drive what you should report on ...

• Is your company divesting or growing the business through mergers and acquisitions? The answer will drive how you prioritize the development

The need for integrated, historical, and accessible data across the enterprise is key to a

competitive advantage Note

39


• For example, project X provides an end-to-end BW solution that empowers decision making to help provide better customer service and deliveries to increase profitability – How?

1. Increased accuracy of reports2. Timely information in an interactive, easy to use manner3. Standardized reporting method and shared tools4. Access to enterprise-wide information5. Continuous monitoring of KPIs; profitability and

margin analysis • The goal is to give users the information when they need

it and in a format they understand so they can execute day-to-day decisions and be more productive

40

Why Build BW and R/3 at the Same Time?

• Leverage 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 without impact to the project team. Consequently, if extensions are made without regards to the BW implementation, rework may be required.

Building BW and R/3 at the same time is a challenge, but there are also benefits

41

Why Build BW and R/3 at the Same Time? (cont.)

• Cost avoidance Avoid creating ABAP and custom reports that is

available in BW • Project success

While R/3 is optimized for transaction processing, BW is maximized for analysis and user access to the data. The available reports and features improve the the quality of user experience thereby increasing the project’s likelihood of success.

42

Why Build BW and R/3 at the Same Time? (cont.)

• 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.

43

Retiring Legacy Reporting Systems

• Building interim solutions while an implementation takes place is hard

• Interim reporting is expensive and the business need must be fully accessed and understood. However, if you must do this, be very careful. Duplicate reports leads to confusion and slow adoption.

• Politics – retool the legacy organization as soon as possible and develop advocates for the new tool set and process. You must involve legacy reporting groups to be successful.

??

Have a "sunset" plan for legacy reporting systems – "burn the boats"

44



45

Writing the Strategic Plan for Your Enterprise Data Warehouses

• Table of Content• Executive Summary• Background• Strategy

Motivator of change (why?) As-is state of systems and reporting To-be state of enterprise data warehouse Benefits of the enterprise data warehouse Proposed scope Proposed architecture Proposed rollout plan Proposed project organization Proposed support organization

• Resources Internal resource assessment External resource assessment Training needs Recruitment

The strategic plan should contain these sections:

• Vendor overview and /or selection Hardware Software Partners

• Budgets Detailed budget Proposed funding approval

• Limitations, Assumptions, and Risks• References

46

The Pitfalls of Many

• Failure to break from as-is environment Treating legacy systems as “requirements” Comparing and replicating old reports and

system functionality• Underestimating development effort of

complex requirements R/3 is different than most legacy systems, as is reporting Failing to understand sources of information. (i.e., sales

reporting) can come from sales orders, deliveries, billings, A/R, G/L, or COPA

• Single Sponsor Lack of corporate ownership and executive buy-in No succession plan and the Enterprise Data Warehouse

often becomes an “orphan”

47

The Pitfalls of Many (cont.)

• Failure to quickly disable legacy reporting systems

• Creates competing systems, politics, and no real cost savings

• Removes urgency and creates slow user adaptation• Overly complex architecture and lack of

enforcing of standards

Technology is seldom the reason why EDWs fail; organization and strong leadership is paramount

48

The Living Strategy – How to Make It Work …

• A strategy is a living document that is subject to change• It is not a one-time effort that is ignored after the first

change (many create a strategy only to file it in a drawer)• The strategy should be clearly communicated to all team

members and the business community• Change control approvals are needed to make the

strategic planning process work in reality

A periodic review should be scheduled (e.g., quarterly) to monitor how well the implementations follow the strategy

49



50

Resources

• SAP Planning – Best Practices in Implementations, by George W. Anderson

• The Complete Project management Office Handbook, by Gerard M. Hill

• Waltzing With Bears: Managing Risk on Software Projects, by Tom Demarco & Timothy Lister

• Mastering the SAP Business Information Warehouse, by Kevin McDonald, Andreas Wilmsmeier, David C. Dixon

51

7 Key Points to Take Home

• Write the business case around the areas of greatest benefit to your users. Do not use a “shot-gun” approach, but keep it focused.

• Define your scope in terms of what is included and state what is not included

• Establish a formal change control process that is well communicated

• Plan your project based on the hours required for the effort and the project team’s skill level

52

7 Key Points to Take Home (cont.)

• Establish milestone dates and map the work hours required to these dates

• Make sure you have a plan for retiring legacy reporting systems

• Evaluate staffing and training models periodically

53

Your Turn!

How to contact us:Joyce Redmon Dr. Bjarne Berg

[email protected] [email protected]

Questions?

© 2005 wellesley information services. all rights reserved. scope, prioritize, budget, and staff an...

Documents

project scopebudgeting

small bw project

large bw project

sap bw project

midsized bw project

team r3 experience

bw handson experience

handson bw skillsexample