© 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
What We’ll Cover …
• Planning
• Organizing
• Getting the requirements
• Executing the project
• End user satisfaction
• 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
What We’ll Cover …
• Planning
• Organizing
• Getting the requirements
• Executing the project
• End user satisfaction
• 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
Basis and functional R/3 support
8-10 team members and normally 2-4 months duration depending on scope
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
Basis and functional R/3 support
15-25 team members and normally 6-18 months duration depending on scope
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
Business analyst/(sub-team lead)BW developerPresentation developer(s)ETL developer
Finance Team
Business analyst/(sub-team lead)BW developerPresentation developer(s)ETL developer
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
What We’ll Cover …
• Planning
• Organizing
• Getting the requirements
• Executing the project
• End user satisfaction
• 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
and documentedin doc. 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
R/3 is selected asRepor ting Tool
and documentedin doc. tool
D9R/ 3 Tool
SelectionProcess
No
BW is selected asReporting Tool anddocumented in doc.
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
Communicate finaldisposition
Communicate finaldisposition
Communicate finaldisposition
Communicate finaldisposition
R/3 team make final disposition
Communicat e finaldisposition
Communicate 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
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
and documentedin doc. 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
R/3 is selected asRepor ting Tool
and documentedin doc. tool
D9
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
and documentedin doc. 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
R/3 is selected asRepor ting Tool
and documentedin doc. tool
D9R/ 3 Tool
SelectionProcess
No
BW is selected asReporting Tool anddocumented in doc.
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
Communicate finaldisposition
Communicate finaldisposition
Communicate finaldisposition
Communicate finaldisposition
R/3 team make final disposition
Communicat e finaldisposition
Communicate 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
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
and documentedin doc. 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
R/3 is selected asRepor ting Tool
and documentedin doc. tool
D9R/ 3 Tool
SelectionProcess
No
BW is selected asReporting Tool anddocumented in doc.
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
Communicate finaldisposition
Communicate finaldisposition
Communicate finaldisposition
Communicate finaldisposition
R/3 team make final disposition
Communicat e finaldisposition
Communicate 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
Team starts by reviewing documentation tool fordocumentation 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
and documentedin doc. 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
R/3 is selected asRepor ting Tool
and documentedin doc. tool
D9
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
and documentedin doc. 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
R/3 is selected asRepor ting Tool
and documentedin doc. tool
D9R/ 3 Tool
SelectionProcess
No
BW is selected asReporting Tool anddocumented in doc.
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
Communicate finaldisposition
Communicate finaldisposition
Communicate finaldisposition
Communicate finaldisposition
R/3 team make final disposition
Communicat e finaldisposition
Communicate 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
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
documentationcomplete?
Request additionalinput from Business
Team member
ResponsibleTeam member
acquires/documentsadditional 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 Tool
and documentedin doc. tool
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/ODS
No
Yes
No
D1aIs this a truereporting
need
Yes
No Communicate tobus. leader
A2Total Cost of
OwnershipAnalysis
D8Is BW costeffective?
Yes
No
YesYes
R/3 is selected asReporting Tool
and documentedin doc. tool
D9R/3 ToolSelectionProcess
No
BW is selected asReporting Tool anddocumented in doc.
tool
StandardR/3
ABAP/Custom
ReportWriter
OtherQuery
Review requirements and identifycorresponding Data Model (InfoCube/ODS)
Communicate finaldisposition
Communicate finaldisposition
Communicate finaldisposition
Communicate finaldisposition
Communicate finaldisposition
R/3 team make final disposition
Communicate finaldisposition
Communicate finaldisposition
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
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
What We’ll Cover …
• Planning
• Organizing
• Getting the requirements
• Executing the project
• End user satisfaction
• 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
What We’ll Cover …
• Planning
• Organizing
• Getting the requirements
• Executing the project
• End user satisfaction
• 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
What We’ll Cover …
• Planning
• Organizing
• Getting the requirements
• Executing the project
• End user satisfaction
• 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