20 Questions to Ask When Formulating a BI Strategy and Roadmap

1. 20 Questions to Ask When Formulating a BI Strategy and Roadmap Dr. Bjarne Berg COMERIT

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

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

4. #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!)

5. #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?)

6. #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

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

8. #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

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

10. When to Select Different Methodologies High System development Life cycle Joint Application Design based methodologies (JAD) (SDLC) Time to Delivery Rapid Application Development Extreme Programming (RAD) (EP) Low Low High Impact of Failure #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 Look at what your organizational partners have done You may know more about RAD than you think! Source: Bjarne Berg, Data Management Review 2004

11. #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 Real project example Fortune-20 Energy Company This preliminary estimate is based on a solid skill set of SAP NetWeaver BW and SAP BusinessObjects developers, a new BW implementation

12. 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 Real project example 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

13. #6: Look at a BI Project as a Holistic Effort Real project example 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.

14. #7: Give Estimated Labor Hours by Projects Real project example Project-1 Project-2 Project-3 This creates a “menu” that senior leadership can select from while seeing the overall relative size of the projects from an efforts perspective

15. Estimated Labor Hours by Activity — All Projects Real project example Presenting the data also by different tasks provides guidance on how to staff the project and how many resources may be required

16. Estimated Labor Hours by Track and Activity Real project example 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.

17. #8: Estimate the Full-Time Employee (FTE) by Project Real project example 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)

18. #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”

19. #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

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

21. #10: Plan for Developer Training Before the Project Starts • 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. • 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

22. #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!

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

24. #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

25. 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)

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

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

28. 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.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 Source: www.sla-world.com/check.htm , 2012

29. #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

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

31. #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

32. #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

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

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

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

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

37. 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!

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

39. #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

40. Demo — Documenting Project Success Using Dashboards Real project example Fortune-500 Company

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

42. #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 Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime Chinese Proverb

43. #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

44. The Text Module • Using the Text Module, we can add our comments and update them whenever we like • There are two options: • Regular text • HTML (allows you to use HTML tags to format your text)

45. 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!!

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

47. #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 15% 15% 10% Development and POC 40% 30% 45% Unit Testing 5% 5% 5% System Testing 5% 5% 5% Integration Testing 5% 10% 10% Performance Testing 5% 10% 5% User Acceptance Testing 15% 15% 10% Cut-Over/Rollout 10% 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).

48. Detailed Planning Is Required to Meet the Milestone Dates Real project example Fortune-500 Manufacturing company 2011, BW 7.3 and BI 4.0 Upgrade 2011, BW 7.3 and BI 4.0 Upgrade 2012, Global Dashboard and HANA Rollout 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

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

50. Change Control Process — Example Real project example Fortune-50 Manufacturing company 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.