Inside an SAP Business Intelligence Project, Part 1: Best Practices for Planning and Project Management

Inside an SAP Business Intelligence Project, Part 1: Best Practices for Planning and Project Management Dr. Bjarne Berg COMERIT

In This Session … • Get expert advice on how to budget, scope, and manage an SAP business intelligence project – Ranging from SAP BusinessObjects implementations to leveraging portals • Hear best practices for writing a solid business case for your BI initiative, defining reasonable scope agreements, creating a rollout strategy, developing budgets, picking the right front-end tools, and creating a project organization that matches scope and delivery plans

In This Session … (cont.) Walk through real examples of four SAP customers that have implemented SAP BusinessObjects dashboards and cockpits, and learn how to avoid their top 10 project pitfalls, including performance and user interface deployment Explore functional specifications and requirements, and glean insight into which reports should remain in SAP ERP and which can be leveraged by your SAP business intelligence and SAP BusinessObjects front-end tools Take home best-practice functional specification templates, staffing templates including roles and responsibilities, and decision flow charts for SAP business intelligence projects

What We’ll Cover … • Planning your SAP business intelligence project • Organizing your BI initiative • Top 10 lessons learned by four SAP customers that have implemented SAP BusinessObjects dashboards • Getting started with your BI project • Wrap-up

Planning Your SAP Business Intelligence Project The business case Scope agreement Milestones Steering committee

Writing the Business Case • The business case must be aligned with some concrete business benefits • The best way to write a business case is to align it with one of these areas: • Money • Strategy • Reducing time and effort of delivery • Improved information quality and access for end users

Area Area Observation Observation SAP BI BI Benefit Benefit Cost of Ownership Cost of Ownership Maintaining a custom developed SAP is responsible for Substantial maintenance cost savings BI solution is complex and maintenance of the expensive product Cost Avoidance Cost Avoidance Updating extract programs BW – ERP integration points are maintained and tested by SAP Substantial cost savings, by when upgrading ERP is not having to redevelop new expensive extract programs for each SAP upgrade Web strategy Web strategy Web delivery requires rapid data BW is closely integrated Enables web initiatives to get delivery of high consistency with with ERP and can deliver closer to the source data, the source system data that reflects the both in time and consistency source system at short time intervals Reconciliation Effort Reconciliation Effort A substantial portion of the data BW is “ closer ” to the Users spend less time on warehouse effort is spent on source system, and more reconciling data, and more reconciling information accurately reflects data time analyzing it Information Access Information Access Business users need a high Load times in BW are Users get earlier access to availability solution less than traditional, information custom- developed data warehouses Business Case Ideas

More Business Case Examples

Three More Business Case Examples

The Scope Agreement Dimensions • For the first go-live, keep the scope as small as possible • For example, 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 Scope Resources (people, technology, and money) Time There is a limit to how far you can compress timelines: Brooks law states that "Nine women cannot make a baby in one month“* * Frederick Brooks, The Mythical Man-Month, Addison-Wesley, 1975)

The Scope Agreement — A Discovery Exercise • Determining the scope is done in a variety of ways, depending on which methodology you employ. It is a complex process involving: • Discovery and education • Formal communication • Reviews • Final approvals An SAP BI implementation involves more than black-and-white technical decisions; just because something is technically feasible, doesn’t mean it is wise or desirable from a business perspective. Source: Gooy_GUI, 2007

Defining The Scope Of Your SAP BI Implementation • First, determine what the business drivers are; Then 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 based on what is agreed to at this stage. • As part of the written scope agreement, make sure you implement a formal change requestprocess. This typically includes a benefit-cost estimate for each change request and a formal approval process. Source: Gooy_GUI, 2007

Change Management Process IT responsible Change Request form Approved? Integration tested QA environment No Business responsible Sr. mgmt. responsible Yes Yes Approved? Moved to production No Submission No Approved? System tested Dev. Environment Complete? Scheduled No Yes Yes Change Request form Review Recom-mended? Developed Unit Tested Dev. environment No Yes Approved? No Yes

The Change Management Form — Page 1 • To make this process work, you need a formal instrument • The instrument can be online (i.e., a Web page), electronic (Word document), or a paper-based system • The form should contain at least these fields The front page that the requestor fills out

The Change Management Form — Page 2 • This page is used by the system administrator or the project team • The purpose is to have controlled changes that are scheduled and tested appropriately The back page that the system admin and approver fill out 15

Do You Have a Plan? The Six Dimensions of BI Management • There are six core global dimensions you must consider before embarking on a BI project • Project management is important, but it’s only one of these dimensions • Failure to account for the others may result in project failures. Source: Peter Grottendieck, Siemens For each dimension, articulate an approach, constraints, limitations, and assumptions before you start your project.

Organizing your BI initiative Budgeting Project team organization User Acceptance Testing (UAT) and Rapid Application Development (RAD)

Budgeting Process Steps • Size the SAP BI effort based on the scope • Prioritize the effort • Map the effort to the delivery schedule • Plan for number of resources needed based on the scope, delivery schedule, and the effort Create the Milestone Plan and Scope Statement first, before attacking the budgeting process Start the budgeting process by estimating the workload in terms of the development effort. Refine based on the team’s skill experience and skill level

1. Size the SAP BI Effort Based on the Scope — Real Example Remember that your sizing also has to be based on the team’s experience and skill level.

2. Prioritize the Effort The next step is to prioritize and outline the effort on a strategic timeline Make sure your sponsor and the business community agree with your delivery schedule

3. Use Project Estimates and the Timeline to Create Project Load Plan There are 480 available work hours per project member per quarter. Knowing this, we can plan the number of team members we need…

4. Result: Good Input for the Staffing Costs and Planning Use this information to plan for training, on-boarding, and staffing This spike in resource needs is due to an overlap in the delivery schedule Now might be a good time to review that decision Many companies plan a 60%- 40% mix of internal and external resources for a first go-live. Also, most use $50-$90 per hr for internal budgeting and $90-$170 per hr for external resources.

Coordination of Multiple Business Intelligence Projects Tight Central Control (24%) Loose Cooperation (38%) Independent (38%) 88% Successful 30% Successful 100% Successful How Tightly Should Multiple BI Projects be Controlled? The relationship between control and success according to a conference Board Survey of 89 BI projects. Source: The Conference Board Survey

Six Ways to Organize your BI Project Team The more distributed the BI development effort becomes, the more difficult it is to maintain communication and get cohesive requirements.

Project Sponsor Project Manager Business Team Technical Team Business Analyst BI Architect Presentation Developer ETL Developer BI Basis and functional SAP ERP support Example 1 — Small Project Team Organization • These are roles, not positions • Sometimes one team member can fill more than one role Many companies fail to formally assign roles and responsibilities. As a result, they have many “jack of all trades” and “masters of none.” Four to five team members and normally three to six months duration on each go-live depending on scope ETL = Extract, Transform, and Load

Project sponsor/ Steering Committee Project Manager SAP BI Architect Business Analyst(s) Extract, Transforms and Loads Data Management (InfoCubes & ODS) Presentation Developer(s) - cockpits & queries Basis and functional ERP support Sr. Business analyst Sr. ETL developer Sr. SAP BI developer Sr. Presentation developer Business analyst ETL developer SAP BI developer Presentation developer Example 2 — Medium Project Team Organization This model scales well to teams of up to 12-15 people 8-10 team members and normally 2-4 months duration depending on scope

Project Sponsor/ Steering Committee Project Manager BI Architect Portal Developer(s) Sales Team Finance Team Material Mgmt. Team Business Analyst/(sub-team lead) Business Analyst/(sub-team lead) Business Analyst/(sub-team lead) BI Developer BI Developer BI Developer Presentation Developer(s) Presentation Developer(s) Presentation Developer(s) ETL Developer ETL Developer ETL Developer BI Basis and functional SAP ERP support Example 3 — Large Project Team Organization In larger teams, you need to create functional teams, instead of the previous technical team models. This is to avoid “islands” of teams that are not really integrated 15-30 team members and normally 6-18 months duration between each go-live

On-Boarding ,Training, and SAP Courses Don’t underestimate the value of in-house, hands-on training in addition to formal SAP training classes.

The User Acceptance Group and Its Role • Create a user acceptance team consisting of five to seven members from the various business departments or organizations • Keep the number odd to assist with votes when decisions need to be made. With fewer than 5 members, it can be hard to get enough members present at each meeting • Make this team the focus of your requirements gathering in the early phase, then let this team perform user acceptance testing during the Realization phase • Meet with the team at least once a month during realization to refine requirements as you are building, and have something to show them This approach is hard to execute when also managing scope, but is essential to make sure that the system meets users’ requirements

RAD Approach For Smaller BI and Cockpit Projects • In Rapid Application Development (RAD), keep the scope focused and use a simple approach In- scope? Make enhancements Activate standard content Request for modifications Yes No Load InfoCube User acceptance session Test In-future scope? No Review data quality issues Deploy Create 2-3 sample queries Rejection In RAD, no functional or technical specs are used in this approach. Over 8-16 weeks, multiple user acceptance sessions are used to refine requirements and multiple prototypes are built (think rapid interactive prototyping).

Example 1 — Build on a Solid Foundation • In this company, the data volumes were very high • Therefore, a set of summary cubes were used instead of building dashboards on top of large InfoProviders Lessons # 1: Make sure you build dashboards on top of summary cubes and data stores where the volume is small and queries can run fast.

Example 1 — Build on a Solid Foundation (cont.) • Lesson #2: Modularize the data and always leverage MultiProviders. • This reduces data replication, decreases the number of data updates, and makes the data available to the end user faster. • You can also use the MultiProviders for other summary reports beyond the dashboards.

Example 2 — Compare to Plans Lesson #3: Adding forward looking dashboards that are linked to Business Plans (BP), Rolling Estimates (RE), and Prior Year (PY) makes the dashboard more meaningful. Lesson #4: Create charts that “predict” where the sales will be each month if the trend continues. This makes the dashboard actionable and tells the users what needs to be done.

Example 3 — Provide Numbers, not Just Graphs Lesson #5: Almost all dashboards should have graphs as well as numbers. Do not create a visually pleasing dashboard with just images. People are visual as well as numerical oriented. In this example, users can toggle between tables and graphs. This means that the same information does not consume a large space.

Example 4 — Create Drill Downs from Dashboards Lesson #6: Users want to see the details without having to log-on to a separate system. It is not advisable to try to cram too much details in a single management cockpit (max. 500-1000 rows). Instead, create jump-to reports from the dashboard. This can be to Interactive Analysis (SAP BusinessObjects Web Intelligence ) or to existing BW Web queries.

Example Four — Online Help and Metadata • Lesson #7: When presenting numbers on charts and complex graphs, you should always provide an online explanation for: • What the numbers mean • How they are calculated • How you read the graphs • This can be developed inside SAP BusinessObjects Dashboard Builder (formerly Xcelsius®).

It Is All About Performance, Performance, Performance Lesson #8: It is hard to build a fast dashboard with many queries and panels without SAP NetWeaver BW Accelerator. This provides in-memory processing of queries that is 10-100x faster. Lesson #9: Pre-running queries into cache via BEx Broadcaster requires more memory than the 200MB defaultvalues. Analyze your server and consider increasing the cache to 400MB+. Lesson #10: MDX cache is for OLAP Universes, OLAP cache is for BICS connectors used by SAP BusinessObjects Dashboard Builder. Think how you are accessing the data before you performance tune the system and always conduct a stress test before deploying any dashboards.

Getting Started Methodology and Functional Specs Tool Selection Report dispositioning

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 Pick a Formal Methodology — You Have Many Choices • Accelerated SAP (ASAP) methodology is not your only choice • Even though they are harder to manage on a global project due to long communication lines, consider RAD, JAD, or EP 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

Monitoring BI Quality and Formal Approval Process: Example Integration Testing Create Technical specs Create Functional specs No System Testing Complete? No Yes Unit Testing Complete? Yes Configuration Peer Review Yes Peer Review Approved? No Yes Approved? No Structured walkthrough Complete? Yes Structured walkthrough No Complete? No Yes

Sample Info Request Form • Documents requirements in a standardized format and allows for a large comment section • Prioritizes requirements • Consolidates requirements • Supports follow-up discussions and reviews

Sample Info Request Form (cont.) • Other uses • Post the form on the intranet, thereby giving stakeholders an easy way to communicate with the project team • Use the Comment section for language and security requirements, or add a separate section for this • Note the section for dispositioning the requirement

What Dashboard and Cockpit Tool to Select • All SAP tools have strength and weaknesses • This is a subjective summary of each of the major dashboard tools

SAP's Vision — Who Should Do What … .. • SAP has a vision of which SAP BusinessObjects tools are appropriate for the different user groups Source: SAP

Team starts by reviewing documentation tool for An example of how to decide which reports should be in ERP or the legacy system (refer to printed version) documentation completeness cu Review requirements and identify corresponding Data Model (InfoCube/ODS) D1a D1 Communicate to Is this a true Is report No Yes bus. leader documentation reporting need complete? Yes D4 No D2 D2.5 D3 Is the report Is this Does data exist Significant No No No system an Intraday in "in-scope" models number resource report? Infocube/ODS of users? Request additional No intensive? input from Business Team member Yes Yes ERP is selected as Yes Reporting Tool ERP is selected as and documented A2 Reporting Tool in doc. tool Total Cost of and documented Ownership Responsible Analysis Team member acquires/documents additional information ERP is selected as Communicate final Reporting Tool D8 and documented disposition No Is BI cost in doc. tool effective? Yes BW is selected as D5 Communicate final Reporting Tool Does Yes disposition and documented No Yes Standard ERP in the documentation tool content D9 exist? BW is selected as ERP Tool D6 reporting tool and Change Selection D7 Does Request is submitted if Communicate final Process Is it less the scope changed Standard BW disposition No expensive to content create in No exist? ERP? Standard Report ERP Writer Yes Yes ABAP/ BW is selected as BW is selected as Communicate final ERP is selected as Query Other Custom Reporting Tool and Reporting Tool and disposition Reporting Tool documented in doc. documented in doc. and documented tool tool in doc. tool A3 Sub-Process Report Consolidation & eliminate if appropriate (winnowing) Communicate final Communicate final Communicate final disposition disposition disposition ERP team make final disposition BW Team to forward completed detailed report specifications A4 based on selected Reporting Tool - BI or ERP Baseline reports

Inside an SAP Business Intelligence Project, Part 1: Best Practices for Planning and Project Management