managing sap bw projects part-2
DESCRIPTION
Managing SAP BW Projects Part-2TRANSCRIPT
© 2004 Wellesley Information Services. All rights reserved.
Dr. Bjarne BergLenoir-Rhyne College.
An A-Z Guide to Planning, Managing, and Executing an SAP BW Project
Part 2
2
What We Covered So Far (in Part 1)…
• Writing The business case • Defining the scope• Writing the milestone plan• Timelines and staffing plan• Budgeting• On-boarding and training• Writing the workplan• Monitoring progress• Monitoring quality and a formal approval process• The user acceptance group and their role
3
What We’ll Cover (Part 2)…
• Approach
• The blueprinting phase
• The realization phase
• The implementation phase
• Wrap-up
4
What We’ll Cover (Part 2)…
• The approach
Methodology
Lessons learned
Requirements and approvals
• The blueprinting phase
• The realization phase
• The implementation phase
• Wrap-up
5
Source: SAP
What Do Users Really Want?
6
Project Preparation: Some Key Observations
Core Activities
1.1 Initial Project Planning
1.2 Project Procedures
1.3 Training Preparation
1.4 Project Kickoff
1.5 Technical Requirements Planning
1.6 Quality Check Project Preparation
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 project.Scope: 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
(This is what we covered in Part 1)
Note
7
A Brief Look at ASAP
• ASAP for BW is based on many of the same ideas and approaches that are found in the ASAP methodology for R/3
• We will take a look at some core differences….
• SAP standard
• Single, pragmatic, and standardized methodology
• Evolved out of 20 years of experience
• Manageable scope, cost, and common expectations
• Common language
• Preconfigure documentation and tools
8
What is ASAP?
• Project Plan, Estimating
• Design Strategies, Scope Definition
• Documentation, Issues Db
• Workshop Agenda
• Questionnaires
• End-User Procedures
• Test Plans
• Technical Procedures
• Made Easy guidebooks (printout, data transfer, system administration…)
Fill in the BlankVersus
Start from Scratch
Fill in the BlankVersus
Start from Scratch
Examples for Accelerators:
9
What are the Core SAP Benefits?
• The main reasons for SAP BW and R/3 implementations are to provide better access to information
• The BW system being built cannot be slower, less user-friendly or harder to learn than the one it is replacing!
Source: CEO Survey - Monash University
10
Critical Success Factors to a 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 re-invent the wheel but learn from others.Note
11
SAP Solution Manager
Service Delivery Platform
SAP Support
Services
Best Practice Documents
Implementation Content
Roadmaps
Test Organizer Support Desk
Solution Monitoring
Service Level Reporting
Customizing Synchronization
Implementation Platform
Gateway to SAP
Landscape Reporting
Tool
Content
e-Learning
Upgrade ProjectsChange Request
ManagementNew inNew in20042004
Source: SAP
12
Don't Forget
A Process Look at Getting Functional Specifications
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.
We will now examine the most common form of RAD (Rapid Application Development).
Create contact group and contact list for business input and requirements
Create a tool to collect inforequestsand businessinput
Conduct information gathering using the tool
Disposition the info. requests to BW or R/3
Consolidate requirements and write functional specs
Build storage objects and load programs
Construct reports and navigation features
Name Organization Phone Number Joe Jones MYORG Ltd 918-123-1234 Joseph Jones Your ORG Ltd 918-123-1234 Joe Jones MYORG Ltd 123-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1238 Joseph Jones Your ORG Ltd 918-123-1239 Joe Jones MYORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joseph Jones Your ORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joseph Jones Your ORG Ltd 918-123-1234 Joe Jones MYORG Ltd 123-123-1234
Team starts by reviewing documentation tool fordocumentation completeness
D1Is report
documentationcomplete?
Request additionalinput from BusinessTeam member
ResponsibleTeam memberacquires/documentsadditional information
D2Is this
an Intradayreport?
D3Significantnumberof 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 ofOwnershipAnalysis
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
Team starts by reviewing documentation tool fordocumentation completeness
D1Is report
documentationcomplete?
Request additionalinput from BusinessTeam member
ResponsibleTeam memberacquires/documentsadditional information
D2Is this
an Intradayreport?
D3Significantnumberof 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 ofOwnershipAnalysis
D8Is BW costeffective?
Yes
No
YesYes
R/3 is selected asReporting Tool
and documentedin doc. tool
D9
Team starts by reviewing documentation tool fordocumentation completeness
D1Is report
documentationcomplete?
Request additionalinput from BusinessTeam member
ResponsibleTeam memberacquires/documentsadditional information
D2Is this
an Intradayreport?
D3Significantnumberof 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 ofOwnershipAnalysis
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
Create contact group and contact list for business input and requirements
Create a tool to collect inforequestsand businessinput
Conduct information gathering using the tool
Disposition the info. requests to BW or R/3
Consolidate requirements and write functional specs
Build storage objects and load programs
Construct reports and navigation features
Name Organization Phone Number Joe Jones MYORG Ltd 918-123-1234 Joseph Jones Your ORG Ltd 918-123-1234 Joe Jones MYORG Ltd 123-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1238 Joseph Jones Your ORG Ltd 918-123-1239 Joe Jones MYORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joseph Jones Your ORG Ltd 918-123-1234 Joe Jones MYORG Ltd 918-123-1234 Joseph Jones Your ORG Ltd 918-123-1234 Joe Jones MYORG Ltd 123-123-1234
Team starts by reviewing documentation tool fordocumentation completeness
D1Is report
documentationcomplete?
Request additionalinput from BusinessTeam member
ResponsibleTeam memberacquires/documentsadditional information
D2Is this
an Intradayreport?
D3Significantnumberof 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 ofOwnershipAnalysis
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
Team s tarts by re vie wing doc um e ntation tool fordocumentation completeness
D1Is report
documentationcomplete?
Request additionalinput from BusinessTeam member
ResponsibleTeam memberacquires/documentsadditional information
D2Is this
an Intradayreport?
D3Significantnumberof 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 ofOwnershipAnalysis
D8Is BW costeffective?
Yes
No
YesYes
R/3 is selected asReporting Tool
and documentedin doc. tool
D9
Team starts by reviewing documentation tool fordocumentation completeness
D1Is report
documentationcomplete?
Request additionalinput from BusinessTeam member
ResponsibleTeam memberacquires/documentsadditional information
D2Is this
an Intradayreport?
D3Significantnumberof 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 s e le c te d 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 ofOwnershipAnalysis
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
13
Rapid Application Development (RAD)
• Be flexible and consider using a RAD (Rapid Application development) approach to the initial information requirement gathering. Typical ways to conduct this include: Ask for 1-2 days of uninterrupted time and provide lunch on-site Remove cell phones, PDA and pagers and emails Invite power users, casual users, today's report writers, and
managers Keep a rapid pace and 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
14
Rapid Application Development (cont.)
• 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
15
Getting the Functional Specifications
• Avoid creating a total inventory of all reports in the organization. The "top-5" (most used) sales, distribution, inventory etc. reports from each department will cover the vast majority of the reporting needs.
• A single BW "report" may satisfy dozens of today's static reports. It is therefore impossible to map each individual legacy report to a single BW report.
Avoid attempting to replicate each report based on what you might have in place today. Accept new ways of accessing data.
Best Practice
Note
16
Getting the Functional Specs (cont.)
• Create a form that captures the core requirements in a structured format
Create a simple form called "information request form" and use
it to gather the core relevant information about each report being requested by the business community. This should include at least the following fields:
- Contact info about the requestor - Data currency (yesterday/today)- Department - Security requirements- Name of report - How is this reporting done today- Purpose of report - Comments- Description of report - Type of users (mgr./analyst/casual) - Number of users expected - Frequency of report (daily/monthly)
Tip
17
• Document requirements in a standardized format
• Prioritize requirements• Consolidate requirements• Support follow-up
discussions and reviews.
P1 of 2
Tool
Sample Information Request Form
18
• Other uses: Post form on the intranet
and thereby 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
Tool
Sample Information Request Form
19
Report Dispositioning: 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 belongs in R/3 and which would not be cost effective to move to BW
• Make cost-effective decisions; just because the report is not in BW does not mean it cannot be in a portal or on the web
• Not all reports belong in BW; avoid using 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
20
Key Questions for Report Dispositioning
• Is this really a reporting need or a "want"?• Is the data going to be in BW at a frequency that solves
the user's request (intraday reporting)?• Is the data needed for this report already in our BW
scope?• Are there already a report available in R/3 ?• Does standard 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 BW cost effective in the long run (ownership)?
21
cu
Team starts by reviewing documentation tool for documentation completeness
D1Is report
documentation complete?
Request additional input from Business
Team member
Responsible Team member
acquires/documents additional information
D2Is this
an Intraday report?
D3Significant
numberof users?
D4 Is the report
system resource
intensive?
D5Does
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 Tool
and documented
No
Yes
No
No
Yes
Yes
Yes
No
Yes
No
D2.5 Does data exist
in "in-scope" modelsInfocube/ODS
No
Yes
No
D1a Is this a true
reportingneed
Yes
NoCommunicate 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)
A4 Baseline reports
Tool
An example of how to decide which reports should be in R/3 or the legacy system (printed version is easier to read)
22
Now That You Have Identified the In-Scope Reports, 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
+ + =Great
Feature
Many requirements can be met by a single BW report
23
Flow Overview
BW Report object:
When: Fall-03 to Jan-12, 2004.Who: Process teamsPurpose: Functional requirementsQuantity: 167
Business Reporting Requirements
BW Query Detailed Specification (used by Information Delivery)
Query Name:
Query Technical Name:
Subject area:
Fixed format:
Free format:
Number of users:
Target Users:
Time Granularity
Historical data:
Peak time usage:
Data Volume:
Frequency:
SAP Roles:
Test Criteria:
Jump Targets:
BW detailed query specs
When: Fall-03 to Jan-12, 2004.Who: Information deliveryPurpose: Functional requirementsQuantity: 167
BW Reports
Reports
An example from a very large manufacturing company
24
An Example
25
An Example
26
Deliver reports in a consistent manner to users (one version of the "truth"), but use different mechanisms to do so.
Managers and executives tends to prefer simple and directed interfaces
Casual users tends to prefer predictable structured access to the data
Analysts and power users tends to prefer high flexibility and unstructured access to the data.
Flat ReportingFlat Reporting• FormattedFormatted• PrintPrint• Form basedForm based• StaticStatic• Predictable accessPredictable access
OLAP ReportingOLAP Reporting• Drill DownDrill Down• Slice and DiceSlice and Dice• AnalyseAnalyse• Data Mining Data Mining • Search and discoverSearch and discover
KPI & ScorecardKPI & Scorecard FormattedFormatted• SimpleSimple• Easy to viewEasy to view• Limited navLimited nav• AggregatesAggregates
Don't underestimate the user's need to access the information in various ways.
OR OR
Consider Multiple Ways of Displaying the Same Data!!
27
What We’ll Cover (Part 2)…
• The approach
• The blueprinting phase
Leveraging the standard content
Modeling your solution
Deliverables
• The realization phase
• The implementation phase
• Wrap-up
28
Blueprinting Phase: Some Key Observations
Core Activities
2.1 Project Management Business Blueprint
2.2 Organizational Change Management
2.3 Project Team Training Business Blueprint
2.4 Develop System Environment
2.5 Organizational Structure Definition
2.6 Business Process Definition
2.7 Quality Check Business Blueprint
Deciding what will be developed in BW and what will be maintained as R/3 reports.
Deciding what will be developed in BW and what will be maintained as R/3 reports.
Getting the right requirements: Finding out the detailed functional specs of what the users really need and not just what they want.
Getting the right requirements: Finding out the detailed functional specs of what the users really need and not just what they want.
Map the functional requirements to the standard content and see what can be leveraged and what needs to be extended.
Map the functional requirements to the standard content and see what can be leveraged and what needs to be extended.
Create user acceptance group(s) and have them review and give feedback on the system as it is developed.
Create user acceptance group(s) and have them review and give feedback on the system as it is developed.
Create detailed technical specifications and designs of infocubes, masterdata, ODSs and high-level architectural designs.
Create detailed technical specifications and designs of infocubes, masterdata, ODSs and high-level architectural designs.
29
The Blueprinting Phase: Leveraging 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 customization
Highly customized storage objects
An example from a large manufacturing company
30
Standard content
The Blueprinting Phase: Modeling Your Solution
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
BW InfoCubes
Storage
A real example from a very large manufacturing company
+
31
Modeling Your Solution
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
1. Write functional requirements
2. Create a model based on pre-delivered BW content
3. Map your requirements to the delivered content and identify gaps.
32
What We’ll Cover (Part 2)…
• The approach
• The blueprinting phase
• The realization phase Building ODSs and InfoCubes Planning, Managing and executing system test Planning, Managing and executing integration and performance test Issue resolution, logs, sign-off and approvals
• The implementation phase
• Wrap-up
33
Realization Phase: Some Key Observations
Core Activities
3.1 Project Management Realization
3.2 Organizational Change Management
3.3 Training Realization
3.4 Baseline Configuration and reviews
3.5 System Management
3.6 Final Configuration and Confirmation
3.7 Prepare & Coordinate interface development
3.8 Develop Data Conversion Programs (if any)
3.9 Develop Queries
3.10 Develop User interface enhancements
3.11 Determine additional reporting requirements
3.12 Create structured reports
3.13 Establish Authorization Concept
3.14 Establish Data Archiving plan (if applicable)
3.15 Final Integration Test
3.16 Quality Check Realization
Configuration and Testing Plans: Define how the configuration will be implemented and how it will be tested
Configuration and Testing Plans: Define how the configuration will be implemented and how it will be tested
Development Programs: Provide details of added programming structures
Development Programs: Provide details of added programming structures
End User Training MaterialEnd User Training Material
Source: Pauline Woods-Wilson
34
Building ODSs 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” do not take precedence and becomes 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 a 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 test on all their work and personally sign-off on their storage object.
TIPS
35
The BW Test Methodology
Methodology used for System and Integration tests
Test Strategy
Test Plan
Test Execution
Problem Resolution
R/3 and BW testing is not different from a methodology standpoint, but the execution is….
36
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
112
2
3
45
67
8
9
10
11
Timing
"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.
37
System Test Scheduling: Example
• Each team has dedicated time in the test room.
• Food will be provided (pastry, doughnuts etc)
• At least 2 testers (preferably 3) 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
38
System Test: Checklist
• Preparations Functional requirements complete Prioritize data source/cubes/ODS/queries for testing Identify critical path for testing Queries developed and available in BW test environment Modify test script to suit each track Track specific test plans created using existing test template Test cases written
39
System Test: Checklist (cont.)
• People Individuals (testers) to perform the test identified Testers invited to complete BW web-based training Availability of testers ensured Roles to be used by testers determined Security roles tested User ID’s for testers created and available
• Logisitics Familiarize test results recording tools – LN database, issues
log Identify test location, and ensure availability of logistics
(rooms, computers, sapgui, network connections, phone, etc..) Plan for problem resolution
40
Integration Test: Planning
• Progress meeting Held daily to monitor progress and resolve common issues Attendees:
Business analysts, back-end developers, query developers, test coordinator, and Test Problem Report (TPR) administrator
Purpose:Discuss common issues, monitor progress, discuss plan changes
Duration:30 minutes
Tasks\Dates March 2004 29-Mar 5-Apr 12-Apr 19-Apr 26-Apr 3-May 10-May 17-May
Identify People for Testing
Schedule Facilities
Prioritize Test Areas (Queries)
Send out Meeting Notice
Execute System Test
Document Results
Problem Resolution
41
Performance Testing
• Performance test execution Identify queries to be performance tuned Determine cutoff load for load test – e.g. 40% of actual users
(not named) Schedule queries to run in background Execute each query while load scripts are running to simulate
“real” users Monitor 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 all Meet with developers everyday to discuss issues/progress Problem resolution
42
Test Signoffs
• 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
43
What We’ll Cover (Part 2)…
• The approach
• The blueprinting phase
• The realization phase
• The implementation phase
Executing cut-over to production
Conducting end-user and power user training
Establishing end-user support organization
Post-implementation review and next steps
• Wrap-up
44
Final Preparation Phase: Some Key Observations
Core Activities
4.1 Project Management Final Preparation
4.2 Training Final Preparation
4.3 Acceptance Testing
4.4 System Management
4.5 Detailed Project Planning
4.6 Cutover
4.7 Quality Check Final Preparation
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 document describes the delivery of the necessary levels of SAP training prior to going live
The End User Training document describes 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
45
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
46
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, on-going projects may get “bogged down” with basic support of reports.
Establishing End-User Support Organization
47
CO
NT
INU
EC
ON
TIN
UE
TOP-DOWN APPROACH
Building a global data warehouse for and proceed sourcing data from legacy systems driven from a top -down approach where reports are also created centrally.
CH
AN
GE
CH
AN
GE
BOTTOM-UP APPROACH
Focus on a bottom -up approach where the DW project will prioritize supporting and delivering DW solutions, but where businesses are actively involved in developing reports.
A BW Data Warehouse Approach at a Company
Should a set of Ambassadors be part of the rollout-strategy?
BW Data Warehouse Alternatives
Issue
How can this be done with minimal organizational disruption?
Issue
The core issue was if the support organization should be centralized, or if the local organizations should be involved.Note
[company X]
48
Some Benchmark Indications Regarding Ambassadors
5 0 % S u c c e s s f u l
5 0 % S u c c e s s f u l
7 0 % S u c c e s s f u l
7 0 % S u c c e s s f u l
N o( 1 0 % )
Y e s( 9 0 % )
B u s i n e s s U n i t s I n v o l v e d i n D e v e l o p m e n t
Increased business involvement increases the probability for data warehouse project success.Note
Can you use a BW ambassador in your user organization?
49
Go-Live: Some Key Observations
Core Activities
5.1 Production Support
5.2 Project End
The last deliverable for the implementation ensures high system performance through monitoring and feedback
The last deliverable for the implementation ensures high system performance through monitoring and feedback
Source: Pauline Woods-Wilson
We need to execute issue resolution plans and contingency plans
We need to execute issue resolution plans and contingency plans
A “lessons learned” session should be held at the end of the project to assure organizational awareness and education
A “lessons learned” session should be held at the end of the project to assure organizational awareness and education
The support organization will take over the system after a pre-determined time period. Some team members may transition into their new roles as support staff
The support organization will take over the system after a pre-determined time period. Some team members may transition into their new roles as support staff
This is a critical time when a “SWAT” team that quickly addresses user concerns can make all the difference in how the system is received among the users
This is a critical time when a “SWAT” team that quickly addresses user concerns can make all the difference in how the system is received among the users
50
Go-live: 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?
51
What We’ll Cover (Part 2)…
• The approach
• The blueprinting phase
• The realization phase
• The implementation phase
• Wrap-up
52
7 Key Points to Take Home
• Keep the team relatively small and focused
• Size your projects based on the team experience
• Make the implementations interactive instead of “Big-Bang”
• Do not cram all reports into BW (some belong in R/3)
• Follow a proven methodology
• Track quality and create a formal approval process
• Involve power users and ambassadors in the development
DB and OS Abstraction
.NET WebSphere…
People Integration
Co
mp
osit
e A
pp
lic
ati
on
Fra
me
wo
rk
Process IntegrationIntegration
BrokerBusiness Process
Management
Information IntegrationBusiness
IntelligenceKnowledge
Management
Life
Cyc
le M
an
ag
em
en
t
Portal Collaboration
J2EE ABAP
Application Platform
Multi-Channel Access
SAP SAP NetWeaver™™
DB and OS Abstraction
Master Data Management
DB and OS Abstraction
.NET WebSphere…
People Integration
Co
mp
osit
e A
pp
lic
ati
on
Fra
me
wo
rk
Process IntegrationIntegration
BrokerBusiness Process
Management
Information IntegrationBusiness
IntelligenceKnowledge
Management
Life
Cyc
le M
an
ag
em
en
t
Portal Collaboration
J2EE ABAP
Application Platform
Multi-Channel Access
SAP SAP NetWeaver™™
DB and OS Abstraction
Master Data Management
53
Resources
a) Rapid Development by Steve McConnell Paperback: 680 pages ; Publisher: Microsoft Press; ISBN: 1556159005
b) Start to Finish Guide to IT Project Management by Jeremy Kadlec
Digital: 109 pages. Publisher: NetImpress; ISBN: B0000W86H2
Download it at: