25 indispensable tips and tricks for planning and...

© 2005 Wellesley Information Services. All rights reserved.

25 Indispensable Tips and Tricks For Planning and Executing Your Next SAP BW Project

Bjarne BergMyITgroup

2

Session Objectives

• In this session, we will examine 25 essential tips to overcome the challenges of managing SAP BW projects

• Walk through a successful SAP BW project – from planning to post-go-live

• Provide real-world examples and discuss some not-so-successful implementations

• Finally, we will look at some formal tools for getting requirements, dispositioning reports, selecting methodology, and more …

3

What We’ll Cover …

• Planning

• Organizing

• Getting the requirements

• Executing the project

• End user satisfaction

• Wrap-up

4


• Planning

• Organizing




• Wrap-up

5

TIP #1: Don’t “Jump” Into a BW Project

1.5 Technical Requirements Planning1.4 Project Kickoff1.3 Training Preparation1.2 Project Procedures1.1 Initial Project Planning

1.6 Quality Check Project Preparation

Core Activities

Project plan: This is the first cut. It focuses on milestones and work packages

Project plan: This is the first cut. It focuses on milestones and work packages

Project charter: Represents an agreement on, and commitment to the deliverables of the project, as well as the time constraints, resources, standards, and budget of the project

Project charter: Represents an agreement on, and commitment to the deliverables of the project, as well as the time constraints, resources, standards, and budget of the project

Scope: Sets the initial definition of the projectScope: Sets the initial definition of the project

Project team organization: Sets the “who” of the project. This decides who will be involved and what is their goal

Project team organization: Sets the “who” of the project. This decides who will be involved and what is their goal

Standards and procedures: Sets the “why” and “how” of the project. Standardizing how meetings are run, documents are handled, etc., means that everyone understands what is going on

Standards and procedures: Sets the “why” and “how” of the project. Standardizing how meetings are run, documents are handled, etc., means that everyone understands what is going on

Source: Pauline Woods-Wilson

6

TIP #2: Review Critical Success Factors for a SAP BW Project

Individual Organisational Technological Methodology The best people End users on the team Platform sizing Proper scope

Backfilling Communication with users

Testing tools Leadership and commitment

Single location Documentation and training internal

Integration testing before releasing

changes

Budget for consulting and

training

Good SAP consultants

Breadth and depth of training

Do not modify code Overseas contacts

Source: Lee Schlenker

These are lessons learned the hard way! Don’t reinvent the wheel, but learn from others

7

TIP #3: Know What Your Users Want

The SAP BW system being built must be faster, more user-friendly, and easier to

learn than the one it is replacing!

Source: CEO Survey - Monash University

67%

61%

51%

38%

24%

15%

4%Other

Haven’t done it yet

Grow revenue

Upgrade technology

Reduce cost/improveefficiency

Improve managementdecision making

Improve informationaccuracy and availability

The main reasons for SAP BW and R/3 implementations are to provide

better information access

8

TIP #4: Think Big – Even When Executing Small

Stop looking at infrastructure and technology …

Start looking at the big picture …

How are you going to make it all work together?

Source: SAP, Léo Apotheker

If SAP is your strategic choice, it is hard to ignore SAP NetWeaver

9

TIP #5: Create Scope Statements and Change Control Rules

• 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

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

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

10

TIP #6: Know What Resources You Control

1. For the first go-live, keep the scope as small as possible, i.e., Accounts Payable, Accounts Receivable, G/L or COPA

2. You have only 3 dimensions to work with:

Which one of these dimensions do you have leverage on?How might changes impact quality?

Time

Scope

Resources(People, Technology,

and Money)

11

TIP #7: Size the BW Effort Based on the Scope – 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 ( C C )

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

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

( S C )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,731L 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,904M 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

HINT: Project sizing has to be based on the team’s experience and skill levelTip

A sizing example by work area and storage object (ODS/InfoCubes)

12

TIP #8: Prioritize the Reporting Areas – ExampleJuly 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

Sales opportunity

Blueprinting Realization Cutover and go-live

2005 20062004

Tax-severance & processor

Plan multiple implementations and write a long-term strategic plan

13

Time Periods

Example 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

Post the milestone plan on the walls in the hallways –don't hide it in the PM’s office!!

Keep it under 30 items!!

TIP #9: Write a Milestone Plan

14


• Planning

• Organizing




• Wrap-up

15

TIP #10: Use Project Estimates to Create Staffing Plan

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

Financials qtr 1 qtr 2 qtr 3 qtr 4 qtr 1 qtr 2 qtr 3 qtr 4 qtr 1 qtr 2 qtr 3General 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

16

Result: Good Input for Staffing, Training, and Budgeting

Many companies plan a 60/40 mix of internal and external resources for a first go-live. And many use $50-$90 per hour for internal budgeting

and $90-$170 per hour 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

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…

17

TIP #11: Organize Based on Project Size

• Three basic SAP BW project models exist:1. Small BW project for single subject area2. Mid-sized BW project for single complex subject area3. Large BW project for multiple subject areas

18

TIP #11: Organize Based on Project Size – Small Project

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

Example: Small SAP BW project for single subject area (i.e., Billing, Inventory, or Accounts Payable)

Note

19

Project sponsor/Steering Committee

Project Manager

BWArchitect

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 developer

Presentation developer



TIP #11: Organize Based on Project Size – Mid-Sized Project

Example: Mid-sized SAP BW project for single complex subject area (i.e., Cost and Profitability, Internal Billing)

These are roles, not positions. Sometimes one team member can fill more than one role

20



TIP #11: Organize Based on Project Size – Large Project

Example: Large SAP BW project for multiple subject areas (i.e., sales, finance, and material management)

Portal developer(s)

SAP 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

21

Plan for In-House and External Training

Ideal Yrs Experience (minimum)

Training days (if new in the

role)

In-house training

daysBW Developer 2+ 15 3-5ETL Developer 3+ 15-20 3-5Presentation Developer 1+ 5-10 3-5Project Manager 5+ 10-15 3-5Business Analysts 5+ 5-10 3-5

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

22

The Workplan

1. Write a detailed workplan that references the methodology (do you have one?)

2. Make sure the workplan is detailed enough to be able to track project progress

3. Progress can be measured by hours used vs. % of tasks completed

TIP #12: Write a WorkplanJ - DATA TRANSFORMATION SYSTEM DESIGN J1 - Develop High-level Data Transformation System Design

J1.1 - Develop a System Architecture Diagram for the broader system environment. J1.2 - Design data extract system component. J1.3 - Determine Uses of Pre-Configured InfoSources. J1.4 - Identify New InfoSources to be Created. J1.5 - Design data transform system component. J1.6 - Design data transfer system component. J1.7 - Design data refresh/update system component. J1.8 - Design end-of-period update system component. J1.9 - Determine the audit and monitoring requirements of the data transformation system. J1.10 - Evaluate data transformation system design. J2 - Develop Data Extract System Interface Design

J2.1 - Refine the interface requirements for data extraction from the source systems. J2.2 - Review interface source systems. J2.3 - Determine system interface approaches. J2.4 - Design each interface. J2.5 - Complete a structured walk-through of the extract system interface design. J3 - Develop Data Transformation System InfoSource Design Specifications

J3.1 - Design Communication Structure for Subject Area InfoSource. J3.2 - Identify/Design Data Source Transfer Structures. J3.3 - Prepare Edit/Validation Specifications for Local Transfer Routines. J3.4 - Develop Table Definitions. J3.5 - Develop Monitor Response for Edits/Validations. J3.6 - Prepare initial test plans for each InfoSource and component grouping. J3.7 - Conduct a structured walk-through of the InfoSource design specifications. J3.8 - Evaluate and resolve issues as required. J4 - Develop Data Conversion Design Specifications.

J4.1 - Determine the condition of the existing data. J4.2 - Map data elements. J4.3 - Determine volumes of all data for conversion. J4.4 - Determine the source data for conversion and the conversion method. J4.5 - Define required selection and purge criteria, creation and translation rules. J4.6 - Review data conversion requirements to determine error identification and cleansing strategies. J4.7 - Develop a strategy for reconciling converted data. J4.8 - Develop data conversion acceptance criteria and acceptance test strategy. J4.9 - Develop a System Diagram for the conversion sub-system. J4.10 - Define staff resources and project management required for conversion. J4.11 - Assemble the data conversion strategy and prepare a data conversion work plan. J4.12 - Submit and discuss the data conversion plan with management. J4.13 - Obtain formal written approval of the data conversion plan. J5 - Submit Data Transformation System Design Deliverable

J5.1 - Assemble data transformation system design deliverable. J5.2 - Conduct a structured walk-through of the design specification. J5.3 - Document and resolve issues as required. J5.4 - Submit and discuss the data transformation system design deliverable. J5.5 - Obtain formal written approval of the data transformation system design deliverable.K - PRESENTATION SYSTEM DESIGN K1 - Develop High-level Presentation System Design

K1.1 - Develop a system diagram for the broader system environment. K1.2 - Develop high-level system design for the presentation system components. K1.3 - Determine the query/report design requirements for the presentation system analysis tools. K1.4 - Develop high-level design for presentation tools. K1.5 - Discuss and obtain formal written approval for the high-level presentation system design. K2 - Create Authorization Detailed Design

K2.1 - Review the Organization's Security Policy K2.2 - Document Access Required Associated by Job Functions K2.3 - Conduct Authorization Interview with Data Owners K2.4 - Identify Information Access and Service Use K3 - Develop Presentation System Interface Design

K3.1 - Identify Presentation/Layout Preferences K3.2 - Determine Uses of Pre-Configured Reports K3.3 - Prepare Query Specifications. K3.4 - Assemble Business Explorer Object specifications. K3.5 - Conduct a structured walk-through of the Business Explorer Object specifications. K3.6 - Evaluate and resolve issues as required. K4 - Submit Presentation System Design Deliverable

K4.1 - Assemble presentation system design deliverable. K4.2 - Conduct a structured walk-through of the design specification. K4.3 - Document and resolve issues as required. K4.4 - Submit and discuss the presentation system design deliverable. K4.5 - Obtain formal written approval of the presentation system design deliverable.

L - DATA DESIGN L1 - Develop Logical Data Model L1.1 - Review the completeness of the inputs. L1.2 - Transform the CDM into a preliminary LDM. L1.3 - Place each entity into third normal form. L1.4 - Finalize the selection of primary and foreign keys. L1.5 - Finalize the definitions of attributes. L1.6 - Refine entity relationships. L1.7 - Estimate data volumes. L1.8 - Complete a preliminary analysis of performance efficiencies. (Optional) L2 - Develop Multidimensional Data Model L2.1 - Identify analytical dimensions. L2.2 - Define dimension tables. L2.3 - Define fact tables. L2.4 - Validate the dimension and fact tables. L2.5 - Develop a physical multidimensional data design. L2.6 - Complete a structured walk-through of the multidimensional data model. L3 - InfoCube Design L3.1 - Identify Key Figures Required for Each Subject Area L3.2 - Identify Characteristics Required for Each Subject Area L3.3 - Identify Dimensions Required for Each Subject Area L3.4 - Identify Compound Characteristics Required for Each Subject Area L3.5 - Identify Calculated Key Figures Required for Each Subject Area L3.6 - Identify Hierarchies Required for Each Subject Area L3.7 - Identify Aggregates Required for Each Subject Area L3.8 - Identify Business Rules by Field for Each Subject Area L3.9 - Identify Data and Retention Requirements L4 - Submit Data Design Deliverable L4.1 - Assemble data design deliverable. L4.2 - Conduct a structured walk-through of the design specification. L4.3 - Document and resolve issues as required. L4.4 - Submit and discuss the data design deliverable. L4.5 - Obtain formal written approval of the data design deliverable.

400 to 1000 line-item workplans are not unusual for mid-size and large SAP BW implementations

23

• Developer training should start early for all project team members

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

• The quality of the team members is much more important than the number of members. A skilled SAP BW developer can accomplish in one day what three novice developers can do in a week (the tool has a steep learning curve)

TIP #13: Develop Timelines and a Staffing Plan: Lessons Learned

24

TIP #13: Develop Timelines and a Staffing Plan:Lessons Learned (cont.)

• Project time and cost estimates should be based on team’s experience level

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

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

25

Which Methodology Approach?Extreme Programming is gathering favor in the web community (a.k.a. "EP" or "XP")

Joint Application Designis popular in smaller projects

Rapid Application Development is in favor for BI applications

SDLC is the most common for large-scale projects Source: "A framework for picking right methodology" - Bjarne

Berg; http://csc-studentweb.lrc.edu/swp/Berg/BB_index_main.htm

26


• Planning

• Organizing




• Wrap-up

27

TIP #14: Get Functional Requirements

We will now examine the most common form of RAD (Rapid Application Development)

There is more than one way to collect this information; however, a formal process should exist to capture requirements and 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 f ordocumentation complet eness

D1Is report

documentationcomplete?

Request additionalinput from Business

Team member

ResponsibleT eam memberacquires/document s

additional information

D2Is this

an Int radayreport ?

D3Significant

numberof users?

D4Is the report

systemresourceintensive?

D5Does

Standard R/3contentexist?

D6Does

Standard BWcontent

exist?

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 T ooland documented

in the documentation tool

BW is selected asreport ing tool and ChangeRequest is submitted ift he scope changed

R/3 is selected asRepor ting Tool


R/3 is selected asReporting Tooland documented

No

Yes

No

No

Yes

Yes

Yes

No

Yes

No

D2.5Does data exist

in "in-scope" modelsInfocube/O DS

No

Yes

No

D1aIs this a true

reportingneed

Yes

No Communicate tobus. leader

A2Total Cost of

O wnershipAnalysis

D8Is BW cost

effect ive?

Yes

No

YesYes



D9R/ 3 Tool

SelectionProcess

No


t ool

StandardR/3

AB AP/Custom

Repor tW riter

O therQ uery

Review requirements and identifycorresponding Dat a Model (InfoCube/O DS)

Communicate finaldisposition





R/3 team make final disposition

Communicat e finaldisposition


BW Team to forward completed detailed report specif icat ions based on selected Reporting T ool - BW or R/3

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

A4Baseline report s


D1Is report



Team member



D2Is this


D3Significant

numberof users?

D4Is the report


D5Does


D6Does

Standard BWcontent

exist?

D7Is it less


R/3?




tool







No

Yes

No

No

Yes

Yes

Yes

No

Yes

No

D2.5Does data exist


No

Yes

No

D1aIs this a true

reportingneed

Yes


A2Total Cost of

O wnershipAnalysis

D8Is BW cost

effect ive?

Yes

No

YesYes



D9


D1Is report



Team member



D2Is this


D3Significant

numberof users?

D4Is the report


D5Does


D6Does

Standard BWcontent

exist?

D7Is it less


R/3?




tool







No

Yes

No

No

Yes

Yes

Yes

No

Yes

No

D2.5Does data exist


No

Yes

No

D1aIs this a true

reportingneed

Yes


A2Total Cost of

O wnershipAnalysis

D8Is BW cost

effect ive?

Yes

No

YesYes



D9R/ 3 Tool

SelectionProcess

No


t ool

StandardR/3

AB AP/Custom

Repor tW riter

O therQ uery












A4Baseline report s

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



Team member



D2Is this


D3Significant

numberof users?

D4Is the report


D5Does


D6Does

Standard BWcontent

exist?

D7Is it less


R/3?




tool







No

Yes

No

No

Yes

Yes

Yes

No

Yes

No

D2.5Does data exist


No

Yes

No

D1aIs this a true

reportingneed

Yes


A2Total Cost of

O wnershipAnalysis

D8Is BW cost

effect ive?

Yes

No

YesYes



D9R/ 3 Tool

SelectionProcess

No


t ool

StandardR/3

AB AP/Custom

Repor tW riter

O therQ uery












A4Baseline report s

Team starts by reviewing documentation tool fordocumentation complet eness

D1Is report



Team member



D2Is this


D3Significant

numberof users?

D4Is the report


D5Does


D6Does

Standard BWcontent

exist?

D7Is it less


R/3?




tool







No

Yes

No

No

Yes

Yes

Yes

No

Yes

No

D2.5Does data exist


No

Yes

No

D1aIs this a true

reportingneed

Yes


A2Total Cost of

O wnershipAnalysis

D8Is BW cost

effect ive?

Yes

No

YesYes



D9


D1Is report



Team member



D2Is this


D3Significant

numberof users?

D4Is the report


D5Does


D6Does

Standard BWcontent

exist?

D7Is it less


R/3?




tool







No

Yes

No

No

Yes

Yes

Yes

No

Yes

No

D2.5Does data exist


No

Yes

No

D1aIs this a true

reportingneed

Yes


A2Total Cost of

O wnershipAnalysis

D8Is BW cost

effect ive?

Yes

No

YesYes



D9R/ 3 Tool

SelectionProcess

No


t ool

StandardR/3

AB AP/Custom

Repor tW riter

O therQ uery












A4Baseline report s

28

Rapid Application Development (RAD)

• Consider using a RAD approach to the initial requirement gathering. Typical ways to conduct this include:! Ask for 1-2 days of uninterrupted time and provide lunch onsite! Remove cell phones, PDAs, etc.! Invite power users, casual users, today’s report writers,

and managers! Keep a rapid pace and a manageable number of attendees

(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

29

Benefits of Rapid Application Development (RAD)

• 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

30

Getting the Functional Requirements

• 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 SAP BW “report” may satisfy dozens of today’s static reports. It is therefore impossible to map each individual legacy report to a single SAP BW report

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

Best Practice

31

Getting the Functional Requirements (cont.)

• Create a form that captures the core requirements in a structured format

TIP: Create a simple form called the “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 this reporting is done today- Purpose of report - Comments- Description of report- Type of users (mgr./analyst/casual) - Number of users expected - Frequency of report (daily/monthly)

32

• Document requirements in a standardized format

• Prioritize requirements

• Consolidate requirements

• Support follow-up discussions and reviews

P1 of 2

Sample Information Request Form

33

• Post form on the intranet and give stakeholders an easy way to communicate with the project team

• Use the comment section for security requirements, or add a separate section for this

• Note the section for dispositioning the requirement

P2 of 2

Sample Information Request Form (cont.)

34

TIP #15: Disposition Your Reports: What Goes in BW and What Stays in R/3?

• There are many tools that can report on R/3 data, and you might have static reports that truly belong in R/3 and that would not be cost-effective to move to SAP BW

• Make cost-effective decisions; just because the report is not in SAP BW does not mean it cannot be in a portal or on the Web

• Not all reports belong in SAP BW; avoid using SAP BW as a “dumping group”

• You need to make conscious decisions on what reporting needs you are going to meet 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.

Warning

35

• Is this really a reporting need or a want?• Is the data going to be in SAP BW at a frequency that solves the

user’s request (intraday reporting)?

• Is the data needed for this report already in our SAP BW scope?• Is there already a report available in R/3?• Does standard SAP BW content exist?

• Is it less expensive to create in R/3?• Are there a significant number of users?• Is the reporting need resource-intensive?• Is SAP BW cost-effective in the long run (ownership)?

Key Questions for Report Dispositioning

36

cuTeam starts by reviewing documentation tool for

documentation completeness

D1Is report



Team member

ResponsibleTeam member

acquires/documentsadditional information

D2Is this

an Intradayreport?

D3Significant

numberof users?

D4Is the report


D5Does


D6Does

Standard BWcontentexist?

D7Is it less


R/3?




tool

BW is selected asReporting Tooland documented


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




No

Yes

No

No

Yes

Yes

Yes

No

Yes

No

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

Infocube/ODS

No

Yes

No

D1aIs this a truereporting

need

Yes


A2Total Cost of

OwnershipAnalysis

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)









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


A4Baseline reports

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

37

You Have Identified the In-Scope Reports, So What’s Next?

Obtain a copy of each of the current reports that are “in-scope” (not all) ! Legacy reports may be a great source to document the data needs;

they can be used to illustrate how data is currently being summarized and viewed in the organization

! Consolidate the requirements and look for “low-hanging fruit”

! Create a physical folder with paper copies of “in-scope” legacy reports; make sure that the development team has access to them and reduce the time spent in meetings with the business community

38

TIP #16: Think Process Flow

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

An example from a very large manufacturing company

39

An Example

An access database to gather query requirements

and specifications

A Tool to Organize Functional Requirements

40

An Example

The Query Specification Details

An access database to gather query requirements

and specifications

41


• Planning

• Organizing




• Wrap-up

42

TIP #17: Monitor Progress and Quality

• Manage the workplan from a percent-complete standpoint on a weekly basis

• Create weekly status reports with core progress metrics and send to all team members (keep it high-level and tangible)

• Require monthly status reports from all team members in a fixed format

• Keep a close eye on the deadlines for the deliverables and make sure to follow-up personally on late tasks

Warning

SAP BW is a complex environment that has many dependencies. Late tasks can have significant impacts on the overall project

43

Monitoring SAP BW Quality and Formal Approval Process: Example

Create Functional specs

Peer Review

Complete?

Complete?

Peer Review

Complete?

Complete?Structured

walkthrough

Approved?

Configuration

Unit Testing

Integration Testing

System Testing

Structured walkthrough

Approved?

No

No

No

No

No

Yes

Yes

Yes

Yes

Yes

Yes

No

Create Technical specs

44

• Create a user acceptance team with a total of five to seven members from the various business departments or organizations

• Keep the number odd to assist with votes when decisions are made. With fewer than five members it can be hard to get enough members present during a certain meeting time

• Make them the focus of the requirements gathering in the early phase, and later let this team become the user acceptance team (testing) in the realization phase

• Meet with the team at least once a month during realization to refine requirements as you are building and have something to show the team

Issue

This approach is hard to execute when also managing scope, but is essential to make sure the system meets the requirements

TIP #18: Create a User Acceptance Group

45

TIP #19: Execution: Leverage Standard Content

• As a guiding principle we map requirements to standard content before we start customizing

• However, we may also have external data sources that require custom ODSs and InfoCubes

• Some observations on higher-level objects …

BW Content available:BW Content available:

• InfoObjects 11,772• ODS objects 349 • InfoCube 605• MultiCubes 121• Roles 861• Queries 3,299• Workbooks 1,979

36%

33%

31%

Mostly standard storage objectsSome customizationHighly customized storage objects

An example from a large manufacturing company

46

Standard content

Mapping Your Requirements to Standard Content

BW functional requirement:

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

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

BW logical model:

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

Storage Requirements

SAP BW InfoCubes

Storage

+

47

An Example: How to Map Requirements to Standard Content

Billing

Num ber of billing docum entsNum ber biling l ine item sBilled item quantityNet weightSubtotal 1Subtotal 2Subtotal 3Subtotal 4Subtotal 5Subtotal 6Subtota l ANet valueCos tTax am ountVolum e

Custom er

Sold-toShip-toBill-toPayerCustom er cla ssCus tomer group~ Custom e r country~ Custom e r reg ion~ Custom e r posta l code~ Custom e r industry code 1End user

Material

M aterial num berM aterial enteredM aterial groupItem categoryProduc t hierarchyEA N/UPC

Tim e

Calendar yearCalendar monthCalendar weekCalendar day

Unit

Currency KeyUnit of M easureBase unit of measureSales unit of m easureVolum e unit of m easureW eight unit of m eas ure

B illing information

B ill ing docum entB ill ing itemB ill ing typeB ill ing categoryB ill ing dateCreation dateCancel indicatorOutput m e dium~ Batch billing indica torDebit/cre dit re ason codeB iling categoryReference documentP aym e nt te rm sCance lle d b illing docum e ntDivis on for the order headerP ricing proce dure

Organization

Com pany codeDivis ionDistribution channelSales organizationSales group

Logist ic s

P lantShipping/rec eiving point

Doc um ent details

Sa les order docum e nt typeSales dealSales docuem ent

Accounting

Cos t centerProfit ce nterControlling areaAccount a ssignm e nt group

Pers onnel

Sales rep num ber

LEGEND

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

1. Write functional requirements

2. Create a model based on pre-delivered SAP BW content

3. Map your requirements to the delivered content and identify gaps

48

TIP #20: Follow Practical Execution Tips for Building ODS and InfoCubes

1 Review the functional requirements and the technical design

6 Do not allow exceptions to the naming conventions

2 Make sure you have established data stewards for the masterdata and assigned the masterdata to specific developers

7 Make sure that “putting out fires” does not take precedence and become the “defaulted”architecture and standard

3 Have your ETL developers report functionally to an individual who is responsible for creating process chains

8 Try new ideas in a sandbox environment and do not contaminate the development environment

4 Avoid nested ODS layers and keep the architecture as pristine as possible

9 Keep details for multi-use in the ODS and do not design the ODS based on the needs of a single InfoCube

5 Make your transformations as part of update rules into infocubes if you need to be able to reconcile to the source system. Keep the details in the ODS

10 Developers must perform unit tests on all their work and personally sign off on their storage object

TIPS

49

TIP #21: Use a Formal SAP BW Test Methodology

Methodology used for System and Integration tests

Test Strategy

Test Plan

Test Execution

Problem Resolution

R/3 and SAP BW testing is not different from a methodology standpoint, but the execution is

50

System Test: Planning

Activities

Tasks\Dates December 2003 January 2004 February 2004 1-Mar 8-Mar 15-Mar 22-Mar 29-Mar 5-Apr

Identify People for Testing

Schedule Facilities

Prioritize Test Areas (Queries)

Send out Meeting Notice

Execute System Test

Document Results

Problem Resolution

1 Create test script 6 Identify key contacts 2 Identify roles to be used 7 Communicate about transports3 Documentation on using test tools 8 Arrange time for progress control4 Procedure for documenting test results 9 Schedule facilities5 Training sessions for using test scripts

Tasks

"There's no time to stop for gas,

we're already late"

Business analysts are responsible for planning, coordinating, and executing the system testing of queries.

51

System Test Scheduling: Large Project Example

• Each team has dedicated time in the test room• Food will be provided (pastry, doughnuts, etc.)• At least two testers (preferably three) should be

assigned to test each query• All test results to be logged

3/1

3/2

3/3

3/4

3/5

3/6

3/7

3/8

3/9

3/10

3/11

3/12

3/13

3/14

3/15

3/16

3/17

3/18

3/19

3/20

3/21

3/22

3/23

3/24

3/25

3/26

3/27

3/28

3/29

3/30

3/31

4/1

4/2

DeliverCost and ProfitabilityOrderManufacturingPlan and schedulingDemand planningSource

Resolving outstanding

issues and re-testing

= Morning session 8:30 - noon= Evening session 12:30 - 5:00

Environment preparation

52

TIP #22: Execute Performance Tests

• Performance test execution!Identify queries to be performance tuned !Determine cutoff load for test – i.e., 40% of actual users (not named)!Schedule queries to run in background!Execute each query while scripts are running to simulate “real” users!Monitor SAP BW system continuously !Attempt tuning at query level!Perform analysis based on benchmarks!Build aggregates, indexes, etc. if needed!Record findings in a formal tracking tool available to everyone!Meet with developers every day to discuss issues/progress

53

TIP #23: Create a Test Signoff Plan

• Signoff procedure! Document test feedback and update logs

! Review open issues

! Prioritize outstanding issues

! Agree on scope decisions and resolutions

! Obtain approvals from business representatives or steering committee

Have a combination of end users, developers, and the user acceptance team sign off formally before you implement the

system to a high number of users

54


• Planning

• Organizing




• Wrap-up

55

Final Preparation Phase: Some Key Observations

4.7 Quality Check Final Preparation

4.5 Detailed Project Planning4.4 System Management4.3 Acceptance Testing4.2 Training Final Preparation4.1 Project Management Final Preparation

4.6 Cutover

Core Activities

The Cutover Plan and the Technical Operations Manual describe the details on how to move to the production environment and go-live

The Cutover Plan and the Technical Operations Manual describe the details on how to move to the production environment and go-live

The End User Training documentdescribes the delivery of the necessary levels of SAP training prior to going live

The End User Training documentdescribes the delivery of the necessary levels of SAP training prior to going live

The Stress & Volume Tests confirm the production hardware’s capabilities

The Stress & Volume Tests confirm the production hardware’s capabilities

Source: Pauline Woods-Wilson

56

Conducting End-User and Power-User Training

Types of Training:! Web-based

! All users! Training ! Tutorials

! Instructor-led ! On-site! Power users! Executives

! Vendor-based ! Developers ! Support staff

57

Are we the only group

that can build reports ?

Who should be involved

from the businesses?How can others join ?

S hould we consider an

“Ambassador concept?”

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

To help support businesses that have already gone live, a strong local community of “ambassadors” is needed

If you don’t have them, ongoing projects may get “bogged down” with basic support of reports

TIP #24: Develop an End-User Support Organization

58

TIP #25: Conduct a Post-Implementation Review

The Information Paradox: John Thorp

AlignmentAlignment BenefitsBenefits

Capability/EfficiencyCapability/EfficiencyIntegrationIntegration

Are we doingthe right things?

Are we doingthem the right way?

Are we getting the benefits?

Are we getting them done well?

Maintain a log of issues two weeks before go-live until six weeks after. Review the log two months after the go-live in a formal post implementation review to learn from the project

59


• Planning

• Organizing




• Wrap-up

60

Resources

Five Core Metrics: The Intelligence Behind Successful Software Management by Lawrence H. Putnam & Ware Myers, Publisher: Dorset House, Paperback, ISBN: 0932633552

Waltzing with Bears: Managing Risk on Software Projectsby Tom Demarco & Timothy Lister, Publisher: Dorset House, Paperback, ISBN: 0932633609

Rapid Development by Steve McConnell, Publisher: Microsoft Press, Paperback, ISBN: 1556159005

Start-to-Finish Guide to IT Project Management by Jeremy Kadlec, Digital: 109 pages. Publisher: NetImpress, ISBN: B0000W86H2

Download it at:

61

7 Key Points to Take Home

• The trick to succeed with SAP BW is to treat it not as a reporting project, but as an application development project instead

• The planning and realistic commitment of resources is paramount to any success

• SAP BW projects require strong attention to details; “minor” issues can stop the whole system (i.e., master data loads in process chains)

62

7 Key Points to Take Home (cont.)

• Organization and a structured approach is the only way to get the “right” requirements

• Quality of team member’s SAP BW skills are more important than numbers

• You must have a change control process if you are delivering a long-term project

• SAP BW is not a reporting “dumping ground,” R/3 reports are still around

63

Your Turn!

How to Contact MeBjarne Berg

Director Business Intelligence, [email protected]

25 indispensable tips and tricks for planning and...

Documents