PM2012_Berg_20questionstoaskwhen

Transcript PM2012_Berg_20questionstoaskwhen

20 Questions to Ask When Formulating a BI Strategy and Roadmap

Dr. Bjarne Berg COMERIT

In This Session …

• • • •

We will take a look at the top 20 questions that should be considered as part of a BI strategy We will look at project sizing, staffing, tool selection, and technical architecture We will explore BI self-service and service level agreements, and take a look at a real project’s way of demonstrating success After this session you will be able to start formulating your own BI strategy to guide your implementation

What We’ll Cover …

• • • • • • •

Planning, Scoping, and Sizing the SAP BI Initiative BI Program Training BI Service Level Agreements (SLAs) Picking the Right BI Tools BI Self-Service Implementation and Limitations Milestone Plans and Change Management Wrap-Up

#1: Align Your BI Strategy with Your Company’s Strategy

• • • •

What are the drivers for the project?

Why do you need visibility – increase revenue, decrease expenses, increase competitive advantage (how? And how do you measure this?) Who are the company’s customers – what do they have in common? Who are their vendors (your competitors)? How can the company’s customers be segmented? What changes are occurring in the customer base? Where is the company heading?

The enterprise data warehouse should set the stage for effective analysis of information to make strategic decisions and identify competitive advantages (proactive and not retroactive!)

#2: What Data Warehouse Strategy to Employ

• • •

Typically, the current state of Data Warehousing (DW) is a combination of centralized and decentralized warehouses resulting in inefficiencies Moving to a centralized DW should enable future projects to reduce costs by leveraging common hardware, standardizing on software, and leveraging a pool of technical resource (is your project a cost-saving project?) How can you provide information, not data, for decision making (KPIs?)

#2: What Data Warehouse Strategy to Employ (cont.)

• •    

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

Increased accuracy of reports Timely information in an interactive, easy-to-use manner Standardized reporting method and shared tools Access to enterprise-wide information



Continuous monitoring of KPIs; profitability and margin analysis The goal is to give users the information when they need it and in a format they understand so they can execute day-to-day decisions and be more productive

Defining the Scope

• •

For the first go-live, keep the scope as simple as possible, in an area with solid standard BW content (i.e., Accounts Payable, Accounts Receivable, G/L, or COPA) You have only three dimensions to work with: If one of these dimensions changes, you have to adjust at least one of the others or the quality of your BI initiative will suffer

#3: Writing the Strategic Plan for Your Enterprise BI Effort

• • • • •

Table of Contents Executive Summary Background Strategy

   

Motivator of change (why?) As-is state of systems and reporting To-be state of enterprise data warehouse Benefits of the enterprise data warehouse

   

Proposed scope Proposed architecture Proposed roll-out plan Proposed project organization



Proposed support organization Resources

 

Internal resource assessment External resource assessment

 

Training needs Recruitment The strategic plan should contain these sections:

• • • •

Vendor overview and/or selection



Hardware

 

Software Partners Budgets



Detailed budget



Proposed funding approval Limitations, Assumptions, and Risks References

The Living BI Strategy — How to Make It Work …

• • • •

A BI strategy is a living document that is subject to change It is not a one-time effort that is ignored after the first change (many create a strategy only to file it in a drawer) The strategy should be clearly communicated to all team members and the business community Change control approvals are needed to make the strategic planning process work in reality A periodic review should be scheduled (e.g., quarterly) to monitor how well the implementations follow the strategy

#4: Pick a Formal BI Methodology — You Have Many Choices

• •

Accelerated SAP (ASAP) methodology is not your only choice Even though they are harder to manage on a large BI project, consider RAD, JAD, or EP (Scrum/Agile) based on the time to delivery and impact of failure When to Select Different Methodologies

High

Time to Delivery Joint Application Design (JAD) Extreme Programming (EP) System development Life cycle based methodologies (SDLC) Rapid Application Development (RAD) Look at what your organizational partners have done You may know more about RAD than you think!

Low Low

Impact of Failure

High Source: Bjarne Berg, Data Management Review 2004 9

#5: The Project Scope and Project Sizing — What to Build

• •

By outlining high-level deliverables, we can make a set of assumptions for a bottom-up project sizing in terms of labor hours, customization, and number of BI reports and dashboards This example is for a BI program with 3 projects Application Area Quantity (estimated)

4 4 3 4 5 5 4 3 3 4 4 3 3 2 4 1 1 1

Development Strategy

Enhancements New New New Redesign New Enhancements New Enhancements Enhancements New New New New New New New New Enhancements Enhancements Enhancements

BW enhancements (H/M/L)

ETL/DTP DSO IC Masterdata H M H H M H H H H H M H H L L L H H L L L H H L L L H L L L

Dashboards (#)

6 6 8 2 2 3 28 7 6 6 22 18 -

Analysis reports WebI reports (Estimated #)

Web Excel PPT Standard Ad-hoc Re-design 30 12 1 1 30 28 10 8 16 5 2 3 1 22 5 5 5 2 1 1 1 -

This preliminary estimate is based on a solid skill set of SAP NetWeaver BW and SAP BusinessObjects developers, a new BW implementation

Use Project Sizing Benchmarks

• •

We base our assumptions on average development time for each of the area based on complexity Naturally, some may finish earlier, while others may take longer, so these numbers are averaged based on experiences with 50 SAP NetWeaver BW and SAP BusinessObjects projects during the last decade High/New Medium Low BW Development Hours

ETL & mapping DSO/D TP IC 260 230 300 260 280 240 220 180 160 MD 180 140 68 Item

Dashboards Analysis WebI Front-end Hours (incl RAD sessions)

Require ments Build RAD sessions Cut-Over 110 32 11 14 280 24 21 4 24 7 11 2 Total

422 74 44 Many new BI program managers underestimate testing and changes of reports and dashboards during User Acceptance Testing (UAT) The testing time for the BW work is separated as its own estimate, while the RAD sessions are included in the SAP BusinessObjects assumptions

#6: Look at a BI Project as a Holistic Effort

1 2

Application Area

OpEx - ETL OpEx- DSO (LVL-1 w.o. & DTP) Development Tasks BW enhancements (hours) ETL/mappin DSO/DTP IC Masterdata g 1040 0 0 0 Dashboards (hrs) 0 920 1200 0 0 0 3 OpEx - DSO Reportable 0 0 840 0 0 Analysis reports (hrs) Web 0 0 Excel 0 0 PPT 0 0 WebI New & adhoc 0 0 ments 312 636 Supporting tasks Require Project mgmt 208 424 Basis 229 466 Unit test 89 182 Testing and Deployment System test 358 729 Integrati on test 394 802 Rollout 447 912

Initiative total hrs

3,077 6,272 0 0 0 0 252 168 185 72 289 318 361 2,485 4 OpEx - New Cubes 5 6 OpEx - Masterdata attribution OpEx - BOBJ and reporting FAST - ETL 7 8 9 FAST - DSO (LVL-1 w.o. & DTP) FAST - DSO reportable 10 FAST - Masterdata changes 11 FAST - InfoCubes 12 FAST - BOBJ and Reporting 13 Metrics - ETL 14 Metrics - DSO (LVL-1 w.o. & DTP) 15 Metrics - DSO reportable 16 Metrics - Masterdata changes 17 Metrics - InfoCubes 18 Metrics - BOBJ and Reporting 19 OpEx Phase -2 Enhancements 20 FAST Phase -2 Enhancements 21 Metrics Phase -2 Enhancements Total 0 0 0 920 780 0 0 0 0 1300 1040 0 0 0 0 220 220 220 0 0 0 0 900 900 0 0 0 0 1200 900 0 0 0 180 180 180 1120 0 0 0 0 0 0 1120 0 0 0 0 0 1120 0 160 160 160 0 900 0 0 0 0 280 0 0 0 0 0 540 0 0 68 68 68 0 0 2532 0 0 0 0 0 2532 0 0 0 0 0 3376 844 844 1266 0 0 1628 0 0 0 0 0 1332 0 0 0 0 0 2072 518 444 444 0 0 2220 0 0 0 0 0 888 0 0 0 0 0 1184 370 148 222 0 0 74 0 0 0 0 0 74 0 0 0 0 0 74 0 0 0 0 0 1760 0 0 0 0 0 1584 0 0 0 0 0 1056 264 264 264 336 270 760 276 504 270 84 336 760 390 672 270 162 336 1013 442 442 568 224 180 1643 184 336 180 56 224 1282 260 448 180 108 224 1552 525 466 565 246 198 0 202 370 198 62 246 0 286 493 198 119 246 0 138 138 138 96 77 531 79 144 77 24 96 423 112 193 77 46 96 516 186 169 205 385 310 2123 316 578 310 96 385 1690 447 771 310 186 385 2065 746 675 819 424 341 2336 348 636 341 106 424 1859 492 848 341 204 424 2272 820 742 901 482 387 2654 396 722 387 120 482 2113 559 963 387 232 482 2582 932 843 1024 3,313 2,663 18,260 2,722 4,970 2,663 828 3,313 14,537 3,846 6,627 2,663 1,598 3,313 17,763 6,413 5,802 7,044 6,660 5,640 4,680 1,924 11,394 6,438 5,032 222 5,192 9,089 9,436 4,159 3,493 13,973 15,371 17,467 120,171

This estimate is at a +/- 15% accuracy. A more detailed sizing exercise should be undertaken at the beginning of each phase and staffing plans updated accordingly.

#7: Give Estimated Labor Hours by Projects

19,259 , 16%

Estimated Labor Hours

36,070 , 30% 35,809 , 30% 29,033 , 24% Phase-2 enhancements (all tracks)

This creates a “menu” that senior leadership can select from while seeing the overall relative size of the projects from an efforts perspective

Estimated Labor Hours by Activity — All Projects

Estimated Labor Hours

9,436 , 8% 17,467 , 15% 18,904 , 16% 4,159 , 3% Backend BW and ETL BOBJ front-end Requirements Testing Basis Project management Roll-out 28,278 , 23% 32,837 , 27% 9,089 , 8%

Presenting the data also by different tasks provides guidance on how to staff the project and how many resources may be required

Estimated Labor Hours by Track and Activity

10,000 9,000 8,000 7,000 6,000 5,000 4,000 3,000 2,000 1,000 2,566 6,020 5,682 2,847 1,324 9,856 5,243 2,230

Estimated Labor Hours

4,900 6,410 2,262 1,070 7,933 4,220 3,726 6,100 7,762 2,772 1,342 9,785 5,205

This estimate is at a +/- 15% accuracy. A more detailed sizing exercise should be undertaken at the beginning of each phase and staffing plans updated accordingly.

#8: Estimate the Full-Time Employee (FTE) by Project

Activity

Project 1 - Requirements Project 1 - BW Development Project 1 - BOBJ Development Project 1 - Project management Project 1 - Basis Project 1 - Testing Project 1 - Rollout Project 2 - Requirements Project 2 - BW Development Project 2 - BOBJ Development Project 2 - Project management Project 2 - Basis Project 2 - Testing Project 2 - Rollout Project 3 - Requirements Project 3 - BW Development Project 3 - BOBJ Development Project 3 - Project management Project 3 - Basis Project 3 - Testing Project 3 - Rollout

Estimated Labor Hours

2,566 6,020 5,682 2,847 1,324 9,856 5,243 2,230 4,900 6,410 2,262 1,070 7,933 4,220 3,726 6,100 7,762 2,772 1,342 9,785 5,205 Project-3, 19.80 , 32% Project-2, 20.50 , 34%

FTE Equivalents

Project-1, 20.70 , 34%

Estimate the FTE by 1,620 hours available for real project work per employee, not the hours the employee works overall (i.e., 1,680 or 1,920)

#9: Be Aware of the Many Pitfalls of BI Efforts

• • •  

Failure to break from as-is environment Treating legacy systems as “requirements”



Comparing and replicating old reports and system functionality Underestimating development effort of complex requirements ERP is different than most legacy systems; as-is reporting

  

Failing to understand sources of information. (i.e., sales reporting) can come from sales orders, deliveries, billings, A/R, G/L, or COPA Single sponsor Lack of corporate ownership and executive buy-in No succession plan and the Enterprise BI Program often becomes an “orphan”

#9: Be Aware of the Many Pitfalls of BI Efforts (cont.)

• • 

Failure to quickly disable legacy reporting systems Creates competing systems, politics, and no real cost savings



Removes urgency and creates slow user adaptation Overly complex architecture and lack of enforcing of standards Technology is seldom the reason why BI programs fail; organization and strong leadership is paramount

What We’ll Cover …

• • • • • • •

#10: Plan for Developer Training Before the Project Starts

• • •

Make sure your internal staff is well trained before the project starts These 3 official SAP BusinessObjects classes should be taken by all project team members Schedule these together as a one week training class

• •

Dashboard Core – 2 days (BOX-310) This course is intended for inexperienced SAP BusinessObjects Dashboards 4.0 developers who need to create and distribute interactive and connected dashboards. Participants will gain the detailed knowledge necessary to design a dashboard that can be used to facilitate the decision making process. Participants will become familiar with methods for connecting their dashboards to popular live data sources. Participants will be able to shorten their development time using templates, themes, and best practices when designing dashboards.

• •

Analysis Edition for Microsoft Office 1-day (BOAN-10) Audience: Consultants, Project Team Members, Power Users. Learn the basic functions and navigation options of Analysis, edition for Microsoft Office. Learn the special functions and layout design options of Analysis, edition for Microsoft Office.

• •

BI 4.0 Web Intelligence Report 2-days (BOW-310) The target audience for this course is report designers who need to access and analyze information using Interactive Analysis and BI launch pad. Participants will gain the comprehensive skills and in-depth knowledge needed to access, analyze, and share data using SAP BusinessObjects Interactive Analysis and BI launch pad. After the course, participants will be able to efficiently and effectively manage personal and corporate documents to access the information they and report users need, when they need it. They will be able to design reports using Interactive Analysis and share their analysis with other users.

#11: Conduct Hands-On Workshops for Continued Education

• • • 

Plan for hands-on workshops 2-3 months after the formal training is completed to get advanced concepts answered WebI workshop – 2 days



Covers WebI development as basic, intermediate, and advanced development concepts. Client covering facilities and PCs and cost is based on consulting charges and travel costs for facilitator, regardless of how many attend (normally max. 12).

Xcelsius (Dashboard) workshop – 1 day Covers Dashboard development as basic, intermediate, and advanced development concepts. Client covering facilities and PCs and cost is based on consulting charges and travel costs for facilitator, regardless of how many attend (normally max. 12).

Many do not know what questions to ask during first-time training. It is important to have follow-up training after 2-3 months of hands-on working with the BI tools. This makes the team really productive!

What We’ll Cover …

• • • • • • •

#12: Selecting Objective Measures for the BI SLA

•    

Measures drive behavior, so be careful when selecting them. They should be: Simple to understand and easy to calculate Meaningful and drive the behavior you want to encourage Controllable and immune to manipulations Instruments that collect measures must be consistent overtime and as automated as possible Sites, such as the free online “KPI-Library,” have over 6,000 standard measure definitions based on the SEC, API, ISO, FASB, GAAP, IEEE, and other organizations

Standardized — BI SLA Performance Measures

•              

Standard measures exist for SLAs. These include: First-Level Call Resolution (FLCR) Average Call Answer Time (ACAT) Percentage Calls Re-opened within Two weeks (PCRT) Percentage of Training Type Calls (PTTC) Number of Tickets Escalated to level-2 support (NTE2) Percent of Tickets Escalated to level-2 support (PTE2) Number of Tickets per Service Employees (NTSE) Number of Service Employees per User (NSEU) Average Service Employees Training Level (ASET) Percent Service Employees Certified (PSEC) Turnover Rate of Service Employees (TRSE) End User Satisfaction Score (EUSS) Number of System Failures (NOSF) Number of Critical System Failures (NOCF)

More BI SLA Performance, More Measures

•             

Additional measures Mean Time between Failures (MTBF) Mean Time between Critical Failures (MTCF) Mean Time to Provision (MTTP) Mean Time to Repair (MTTR) Percent Up-time Per System (PUPS) Percent Down-Time Per System (PDPS) Percent Call-Back to Customers (PCBC) Cost per Service Ticket (CPST) Cost per Service Employee (CPSE) Cost per Serviced System (CPSS) SLA Operating Efficiency (SLAOE) SLA Operating Effectiveness (SLAOF) Employee Turnover Rate (EMTR ) You can create balanced BI-SLA scorecards by assigning weights.

Pick 10-12 initially and add more as the relationship matures

The BI SLA Components

•           

The BI SLA sections should include: Duration of SLA Party definitions Communication channels Roles and Responsibilities Legal obligations and jurisdiction Financial obligation and payment terms Service-level definitions

  

Systems and priorities Users and priorities Processes and priorities Security requirements Reporting and Escalations Termination clauses Contact lists for operations

Source: The SLA Toolkit, 2012 26

Secret: You Can Buy SLA Templates from Online Vendors

• 

Some vendors provide complete toolkits for generic SLA agreements that you can use to “fill in the blanks” Prices typically range from $199 to $999

Source: www.sla-world.com/check.htm , 2012 Source: www.service-level agreement.net , 2012 • • 

There are even detailed checklists to assure that you don’t forget to include critical items in your SLA, such as legal remedies, jurisdictions, intellectual property rights, etc.

Simpler, free templates can be also downloaded online at: www.continuityplantemplates.com/files/it-service-level agreement-templates.docx

#13: BI Users Also Have Responsibilities Under the SLA

•    

The BI users should also have specific responsibilities under the SLA. These should be spelled out in detail. This include: All BI users must read and sign a formal corporate security policy and enterprise data sharing rules BI users will use only specified telephone numbers, Web sites, and email addresses to request support (no “work around”) Each BI user must attend two hours of BI training sessions before receiving a log-on Each BI power user must attend a specific training session on Crystal, WebI, Analysis, Xcelsius, etc. (each software used) It is in the BI program and user’s best interest to have clearly defined user responsibilities

What We’ll Cover …

• • • • • • •

#14: Use Data Visualization — SAP BusinessObjects Dashboards

• •

Dashboards can be built using the SAP BusinessObjects Dashboards tool (formerly known as Xcelsius) It is an easy way to present data graphically and with simple navigation

#15: Design Your Mobile Dashboards Differently

•

Pick a mobile platform that you will support (Android, Apple, etc.) and design towards that platform

•

Mobile dashboards makes most sense when executives, managers, and leaders have mobile devices that have sufficient display area (not phones)

•

All dashboards are most useful when compared to something. This dashboard is relative to a business plan.

•

Notice that all graphs can be displayed many ways and that color coding is consistent across dashboards

Number-Based Dashboards

•

Dashboards can also be highly formatted and static with little user interaction

•

In this dashboard, we included some KPIs and only the balance sheet for an organization, instead of using Crystal reports for this sort of work Not all dashboards have a high degree of navigation and imagery. For finance dashboards, presenting the numbers in a meaningful way may be more important.

SAP BusinessObjects Analysis — Excel Interface

• • 

The SAP BusinessObjects Analysis tool exists in both: Microsoft Office edition



OLAP edition (Web) The Microsoft Office edition supports both Excel and PowerPoint

Image source SAP AG 33

SAP BusinessObjects Analysis — PowerPoint Interface

The tool has a query panel and can embed “live” BI analysis in the Microsoft Office applications Excel and PowerPoint

SAP BusinessObjects Analysis — Web Edition

• •

The edition for OLAP (Web edition) is great for analysts who want to interact with the data and also add their own calculations, formatting, and charts The output from this analysis can be shared with others within a department or a logical grouping of employees who need to see the information This is not a basic reporting tool, but an analysis tool

SAP BusinessObjects Explorer — Exploration Tool

• • •

SAP BusinessObjects Explorer is a tool that is intended for rapid interactive analysis of large volumes of data Think of it as a BI search engine The tool works by indexing large volume of data on dedicated server blades using SAP HANA or SAP NetWeaver BW Accelerator technology SAP BusinessObjects Explorer is accessed through pre-built Information Spaces. These define what fields are available in the exploration and what users can navigate on.

The core benefit of Explorer (accelerated version): It is really fast!

SAP Crystal Reports Is a Pixel Controlled Reporting Tool

• • •

Crystal Reports was one of the leading vendors that became part of Business Objects and, later, SAP Crystal, with its two versions, is a great tool for batch reporting of “pixel controlled” formatted reports There are some capabilities to do interactive analysis, but it is primarily a tool for structured information access

#16: Be Very Selective in What BI Tool to Deploy

• 

All SAP tools have strength and weaknesses This is a subjective summary of each of the major tools Tool Web Application Designer Dashboard Designer (Xcelsius) Target User Development Capabilities End User Power User Execu tives End User Power User Author IT Developer Graphing Navigation External data External web services Simplicity OLAP Ad-Hoc querying Long term Strategy Visual Composer Interactive Analysis ad-hoc (WebI) Analysis Edition for OLAP (web) Analysis MS edition Crystal Reports -

BO Explorer

- Limited Support

Some Support -

38 Good Support

Demo — Documenting Project Success Using Dashboards

What We’ll Cover …

• • • • • • •

#17: Give Employees the Ability to Build Their Own Reports

• • •

The major decision for an SAP BI-driven enterprise is to determine who gets access to each tool There is often a temptation in the IT community to want to keep the tools under their domain – that is a mistake The IT community should actively work with the power and casual users to improve human capabilities and thereby teach them to become more productive employees Chinese Proverb

#18: Teach Users to Build BI Workspaces and Modules

•

Deploy the BI launch pad and teach users to build their own BI Workspaces. This allows them to link many SAP BI tools in the same area, without the need to jump between them. In this workspace, we have three Dashboards, one WebI report, one Analysis report, and one Crystal report running at the same time

The Text Module

•  

There are two options: Regular text HTML (allows you to use HTML tags to format your text)

•

Using the Text Module, we can add our comments and update them whenever we like

The Compound Module with a Text Module

•

The Compound Module enables you to display many modules together, including text, dashboards, WebI reports, Crystal reports, and Analysis for OLAP Creating a compound module is so simple that anyone with Microsoft Word or PowerPoint skills can learn it in less than 5 minutes!!

What We’ll Cover …

• • • • • • •

#19: Align Project Scope and Milestones with Technology

•

The project scope is significant and the work should be tailored to getting to testing phase as soon as possible

•

Balance your effort with the following proportion: Task Analysis/WebI Dashboarding Crystal Report Requirements gathering Development and POC Unit Testing System Testing Integration Testing Performance Testing User Acceptance Testing Cut-Over/Rollout 15% 40% 5% 5% 5% 5% 15% 10% 15% 30% 5% 5% 10% 10% 15% 10% 10% 45% 5% 5% 10% 5% 10% 10% These are based on labor hours, not project duration. Staffing should be done accordingly. The key with a BI project is to get to testing as soon as possible and spend 40-50% of the time on testing and enhancements (JAD, RAD, or Agile).

Detailed Planning Is Required to Meet the Milestone Dates

Week starting 2011, BW 7.3 and BI 4.0 2012, March 2006 / R05 Global and HANA Rollout 9/14-9/15 R04P x0Q 10/5-10/6 R04I x0V 10/12-10/13 R04I x0V 9/7-9/8 R04P x0V P x0V/x0Q Mig& Rgrs. x0Q Conv.

I System Test G Mth.

End Conv. Mock Integration Test 1 Conv.

7/28-7/29 R04I xTS Mock Month End Integration Test 2 9/17-9/18 R04P x01 x0V Conv.

Prod. Conv x0V Mock I I/G x0V/x0Q Mig & Rgrs.

G Month. End Early Orders P I 10/15-10/16 R04I x01 Cut Over G 10/4 R04 V1W4 BW 3.5 Upgrade Break-Fix Window Proto 1 Support Pk Apply/Tst Proto 2 Support Pk TPR Fix Support Pk 11/10-11/11 R05I xT0 12/15-12/16 R05I ITC2 Mock Prep Integrated Unit Test 10/17 spt. Pk xT0 Mth End x0Q Conv.

9/5 R05P xT0 Data/Mig Conversions P Regression Prior Waves 9/22-9/23 R05I xT0 Mock System Test 1 I/G 10/18-10/20 R05P+spt pk xTS Training Conv.

Conversions P Regression Prior Waves I G Mock Month.

End Integration Test 1 Conversions Training Data Staging Mock x0V Conv.

P P x0V/x0Q Mig& Rgrs. Integration Test 2 I x0V Mock I/G x0V/x0Q Mig & Rgrs.

G Mth End Prod. Conv Erly Ordr

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

#20: Write a BI Scope Agreement and Implement Change Control

•

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. Scope Management Processes

• Project Initiation Requirements Gathering (Scope Planning) Project Scope Statement (Scope Definition) Project Committment (Scope Verification) Scope Change Control

Source: PMI 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 typically includes a cost-benefit estimate for each change request and a formal approval process

Change Control Process — Example

Business Teams

Identify change, evaluate need, and submit, if valid.

Change Control DB Operating Model Integration Team

Current scope of work?

Operating Model Integration Team

No Update to relevant release and notify Business. No further action at this time.

Yes

Operating Model Integration Team Change Control DB Tracks

Assign to responsible Track.

Analyze request and estimate impacts.

Change Control DB Change Control DB Escalation Levels

1. Team Lead 2. Project Integration Team 3. Project Management Org 4. Project Management Council

PMC / PMO Project Integration Team Team Lead Tracks

Based on impact, can a decision be made at this level?

No Escalate request to next level in organization for decision/review.

Yes

Change Control DB PMC / ESC PMO EDGE Integration Team Team Lead Tracks Team Lead Tracks Tracks

Identify change, evaluate need and assign to responsible Track.

Change Control DB

Make/review decision.

Change Control DB

Communicate resolution to Business.

Yes Would Business like further review?

Tracks

Execute action plans and close change request.

Change Control DB Change control processes should be formal, with escalation rules that can be used if disputes occur. This example is from a large SAP project that included BI and BW and which needed very strong scope control.

What We’ll Cover …

• • • • • • •

Where to Find More Information

• • • • •

Ralph Hughes, Agile Data Warehousing Project Management: Business Intelligence Systems Using Scrum (Morgan Kaufmann, October 2012).

David Lai and Xavier Hacking, SAP BusinessObjects Dashboards 4.0 Cookbook (Packt Publishing, 2011).

John Boyer, Bill Frank, Brian Green, Tracy Harris, and Kay Van De Vanter, Business Intelligence Strategy: A Practical Guide for Achieving BI Excellence (Mc Press, 2010).

Jim Brogden, Heather Sinkwitz, Mac Holden, Dallas Marks, and Gabriel Orthous, SAP BusinessObjects Web Intelligence: The Comprehensive Guide (SAP PRESS, 2012). Bjarne Berg and Penny Silvia, SAP HANA: An Introduction (SAP PRESS, 2012).

Where to Find More Information (cont.)

• •

Richard Martin, Data Warehouse 100 Success Secrets – 100 most

Asked questions on Data Warehouse Design, Projects, Business

Intelligence, Architecture, Software and Models (Emereo Publishing, July 2009).

Tom DeMarco and Timothy Lister, Waltzing with Bears: Managing Risk on Software Projects (Dorset House, 2003).

7 Key Points to Take Home

• • • • • • •

Spend serious time on creating a formal BI strategy that is aligned to your company’s overall objective Make sure your strategy has a set of solid sponsors (not one) Select multiple front-end tools for different users Size your project based on labor hours and base your budget on these Create a 24-36 month implementation strategy and get approvals for the delivery plan Staff your team with experienced resources and train inexperienced staff before the project starts Create a Program Management Office (PMO) and move all major BI projects under this management for coordination, standards, and quality assurance

Your Turn!

How to contact me: Dr. Bjarne Berg [email protected]

Continue the conversation! Post your questions in the BI-BW Forum on Insider Learning Network*

* bit.ly/BI-BWForum

Disclaimer

SAP, R/3, mySAP, mySAP.com, SAP NetWeaver SAP.

® , Duet ® , PartnerEdge, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Wellesley Information Services is neither owned nor controlled by 55