0 Inside an SAP Business Intelligence Project, Part 1: Best Practices for Planning and Project Management Dr. Bjarne Berg COMERIT © 2010 Wellesley Information Services. All rights reserved. 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 2 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 3 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 4 Planning Your SAP Business Intelligence Project 1. 2. 3. 4. The business case Scope agreement Milestones Steering committee 5 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 6 Business Case Ideas Area Observation SAP BI BI Benefit Cost of Ownership Maintaining a custom developed BI solution is complex and expensive SAP is responsible for maintenance of the product Cost Avoidance Updating extract programs when upgrading ERP is expensive BW – ERP integration points are maintained and tested by SAP Substantial cost savings, by not having to redevelop new extract programs for each SAP upgrade Web strategy Web delivery requires rapid data delivery of high consistency with the source system BW is closely integrated with ERP and can deliver data that reflects the source system at short time intervals Enables web initiatives to get closer to the source data, both in time and consistency Reconciliation Effort A substantial portion of the data warehouse effort is spent on reconciling information BW is “closer” to the source system, and more accurately reflects data Users spend less time on reconciling data, and more time analyzing it Information Access Business users need a high availability solution Load times in BW are less than traditional, custom- developed data warehouses Users get earlier access to information Substantial maintenance cost savings 7 More Business Case Examples Area Observation SAP BI Benefit Faster Deployment Need to increase time to deliver new applications and enhancements to existing areas Typical use of 60-80% of predelivered content increases development speed Reduced development time for new decision support areas Integrated Products SAP continues to offer new products and modules that the organization might wish to leverage in the future SAP NetWeaver® BW is the “cornerstone” of SAP’s BI product offerings Enables closer integration with other SAP modules Query speed Business users need fast access to their data Through use of summaries and the SAP NetWeaver BW Accelerator, the blade architecture lends itself to faster inmemory query performance Users get the data they need quickly to perform their job functions 8 Three More Business Case Examples Area Observation SAP BI Benefit SAP Strategy It is the organization’s SAP strategy to leverage investments in SAP to the fullest extent, and maximize SAP resource utilization SAP BI is an SAP product, and is based on standard SAP NetWeaver® technologies (Basis, ABAP, kernels, etc.) Strategic fit and synergy with SAP. SAP Basis, ABAP, etc., resources can be used across SAP projects, including SAP BI Tool Standardization The organization must be able to leverage industry standards to enable business users to access data in a variety of ways Interfaces such as ODBO and MDX and Java are supported by a variety of major presentation and Web tools. SAP BusinessObjects tools can be integrated rapidly via “native: connections Simplifies user access to data; expands options for using standard presentation and Web tools or developing your own Industry Trend The organization’s competitors and some of the organization’s business areas are installing SAP BI Increased industry resource pool and knowledge of SAP BI Enables the organization to leverage industry solutions and know-how 9 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) 10 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: 1. Discovery and education An SAP BI implementation involves more than black-and-white technical decisions; 2. Formal communication just because something is technically 3. Reviews feasible, doesn’t mean it is wise or desirable from a business perspective. 4. Final approvals Source: Gooy_GUI, 2007 11 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 request process. This typically includes a benefit-cost estimate for each change request and a formal approval process. Source: Gooy_GUI, 2007 12 Change Management Process IT responsible Change Request form Integration tested QA environment Business responsible No Approved? Sr. mgmt. responsible Yes Approved? Submission No No Complete? No Approved? Yes Yes Moved to production System tested Scheduled Dev. Environment Yes Review Recommended? No Change Request form Unit Tested Developed Dev. environment Yes No 13 Approved? 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 Change Request Form Requestor Name: Department Phone number / email The front page that the requestor fills out Describe the change requested, be detailed Why is it needed How important is it that the change occur? (how would you manage if this is not done) TBD When is the change needed When possible Future release Date Break-fix (right now) 14 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 For internal use only Received date: Reviewed by: Comments/recommendation The back page that the system admin and approver fill out Pending Not-Approved Future release Approved Break-fix (right now) Pending Prototyped In QA Tested In Production Approval status: Approved by: Approved date: Assigned to: Due date: Development status: 15 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. 16 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 17 Organizing your BI initiative 1. Budgeting 2. Project team organization 3. User Acceptance Testing (UAT) and Rapid Application Development (RAD) 18 Budgeting Process Steps 1. 2. 3. 4. 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 19 1. Size the SAP BI Effort Based on the Scope — Real Example Customi zation L M L M L M L L L L L L L L L M M M M Tech. Dev. infocube Financials General ledger line item (ODS) COPA Prod cost planning released cost estimates (COPC_C09) Exploded itemization standard product cost (COPC_C10) Cost and allocations (COOM_C02) Cost object controlling (0PC_C01) Order Extraction and Report transforms and roles Security and scheduling Web development User support/ planning Project mgmt System docs Tech infraand admin & manuals structure Bus. Analysis, training, req. gathering, change mgmt. Total Hours 216 158 216 229 286 229 188 153 188 101 127 101 132 153 133 134 152 135 100 120 100 79 94 79 150 180 150 403 470 403 1,732 1,893 1,734 238 286 216 126 153 152 120 94 180 470 2,035 216 1144 188 101 132 135 100 79 150 403 2,648 238 286 216 137 153 152 120 94 180 470 2,046 216 216 216 229 229 229 187 187 187 101 101 101 132 132 132 135 135 135 100 100 100 79 79 79 150 150 150 403 403 403 1,732 1,732 1,732 216 229 187 101 132 135 100 79 150 403 1,732 216 216 228 228 187 187 101 101 132 132 135 135 100 100 79 79 150 150 403 403 1,731 1,731 Delivery data of shipment stages (0LES_C13) Delivery service (0SD_C05) Planning and Scheduling Material Movements (0IC_C03) 216 228 187 101 132 135 100 79 150 403 1,731 180 229 133 101 132 134 100 79 150 403 1,641 216 457 132 101 132 134 100 79 150 403 1,904 APO Planning SNP Integration Manufacturing Processes Production Orders Cross Applications Total Hours 277 277 832 832 216 216 127 127 153 153 152 152 120 120 94 94 180 180 470 470 2,621 2,621 277 277 4,298 832 832 8,074 216 216 3,587 127 127 2,110 153 153 2,656 152 152 2,681 120 120 2,040 94 94 1,606 180 180 3,060 470 470 8,126 2,621 2,621 38,238 Billing Sales order Acct. Rec. (0FIAR_C03) Deliver Shipment cost details (0LES_C02) Shipment header (0LES_C11) Stages of shipment (0LES_C12) Remember that your sizing also has to be based on the team’s experience and skill level. 20 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 21 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… 22 4. Result: Good Input for the Staffing Costs and Planning Use this information to plan for training, on-boarding, and staffing Number of team members This spike in resource needs is due to an overlap in the delivery schedule 14 12 10 8 6 Now might be a good time to review that decision 4 2 qtr 1 qtr 2 qtr 3 qtr 4 qtr 1 qtr 2 qtr 3 qtr 4 qtr 1 qtr 2 qtr 3 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. 23 How Tightly Should Multiple BI Projects be Controlled? The relationship between control and success according to a conference Board Survey of 89 BI projects. Coordination of Multiple Business Intelligence Projects Tight Central Control (24%) Loose Cooperation (38%) Independent (38%) 88% Successful 30% Successful 100% Successful Source: The Conference Board Survey 24 Six Ways to Organize your BI Project Team Option 1 Single site 2 Distributed analysis 3 Distributed analysis and design 4 Co-located analysis and design 5 Multiple co-located analysis and design 6 Fully distributed development Benefits Risks The more distributed the BI development effort becomes, the more difficult it is to maintain communication and get cohesive requirements. 25 Example 1 — Small Project Team Organization • These are roles, not positions Many companies fail to formally assign roles and responsibilities. Sometimes one team member can fill more than one role As a result, they have many “jack of all trades” and “masters of none.” Project Sponsor Project Manager Business Team Business Analyst Presentation Developer Technical Team BI Architect ETL Developer BI Basis and functional SAP ERP support Four to five team members and normally three to six months duration on each go-live depending on scope ETL = Extract, Transform, and Load 26 Example 2 — Medium Project Team Organization This model scales well to teams of up to 12-15 people Project sponsor/ Steering Committee Project Manager SAP BI Architect Extract, Transforms and Loads Business Analyst(s) Data Management (InfoCubes & ODS) Presentation Developer(s) - cockpits & queries Sr. Business analyst Sr. ETL developer Sr. SAP BI developer Sr. Presentation developer Business analyst ETL developer SAP BI developer Presentation developer Basis and functional ERP support 8-10 team members and normally 2-4 months duration depending on scope 27 Example 3 — Large Project Team Organization Project Sponsor/ Steering Committee Project Manager 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 BI Architect Portal Developer(s) Sales Team Finance Team Business Analyst/(sub-team lead) BI Developer Presentation Developer(s) ETL Developer Business Analyst/(sub-team lead) BI Developer Presentation Developer(s) ETL Developer Material Mgmt. Team Business Analyst/(sub-team lead) BI Developer Presentation Developer(s) ETL Developer BI Basis and functional SAP ERP support 15-30 team members and normally 6-18 months duration between each go-live 28 On-Boarding ,Training, and SAP Courses BW Developer ETL Developer Presentation Developer Project Manager Business Analysts Ref BW-310 BW-305 BW-350 BW-360 BW-361 BW-365 SAP-330 Course Intro to SAP BI BI Reporting & Analysis BI Data Acquisition BW Performance & Admin BW Accelerator BW Authorizations BW Modeling Ideal Yrs Experience (minimum) 2+ Training days In-house (if new in the training role) days 15 3-5 3+ 15-20 3-5 1+ 5-10 3-5 5+ 10-15 3-5 5+ 5-10 3-5 Who should take the training All End user support and Training Data loads and Fixes System admin System admin Information risk mgmt System admin Don’t underestimate the value of in-house, hands-on training in addition to formal SAP training classes. 29 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 30 RAD Approach For Smaller BI and Cockpit Projects • In Rapid Application Development (RAD), keep the scope focused and use a simple approach Activate standard content Request for modifications Inscope? Yes Make enhancements No Load InfoCube User acceptance session Test In-future scope? No Review data quality issues Create 2-3 sample queries Deploy 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). 31 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 32 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. 33 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. 34 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. 35 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. 36 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. 37 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®). 38 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 default values. 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. 39 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 40 Getting Started 1. Methodology and Functional Specs 2. Tool Selection 3. Report dispositioning 41 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 When to Select Different Methodologies High Joint Application Design (JAD) System development Lifecycle based methodologies (SDLC) Time to Delivery Extreme Programming (EP) Rapid Application Development (RAD) Look at what your organizational partners have done. You may know more about RAD than you think! Low Low High Impact of Failure Source: Bjarne Berg, Data Management Review 2004 42 Monitoring BI Quality and Formal Approval Process: Example Integration Testing Create Technical specs No Create Functional specs System Testing Complete? No Yes Unit Testing Complete? Yes Configuration Yes Peer Review No Approved? Peer Review Yes No Complete? Yes Approved? Structured walkthrough No No Complete? Yes Structured walkthrough 43 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 45 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 Development Capabilities Tool End User Power User Author IT Developer Graphing Navigation External data External web services Simplicity OLAP Ad-Hoc querying Longterm Stategy Web Application Designer Dashboard Designer (Xcelsius) Visual Composer Interactive Analysis (WebI) 46 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 47 Team starts by reviewing documentation tool for documentation completeness An example of how to decide which reports should be in ERP or the legacy system cu Review requirements and identify corresponding Data Model (InfoCube/ODS) D1 Is report documentation complete? Yes D1a Is this a true reporting need No (refer to printed version) Communicate to bus. leader Yes No D2 Is this an Intraday report? Request additional input from Business Team member No D2.5 Does data exist in "in-scope" models Infocube/ODS Yes Yes Yes D6 Does Standard BW content exist? Yes BW is selected as Reporting Tool and documented in doc. tool Communicate final disposition No D7 Is it less expensive to create in ERP? No BW is selected as Reporting Tool and documented in the documentation tool Communicate final disposition D8 Is BI cost effective? Communicate final disposition ERP is selected as Reporting Tool and documented in doc. tool Communicate final disposition Yes D9 ERP Tool Selection Process BW is selected as reporting tool and Change Request is submitted if the scope changed No Standard ERP Yes ERP is selected as Reporting Tool and documented in doc. tool No No ERP is selected as Reporting Tool and documented in doc. tool Yes A2 Total Cost of Ownership Analysis Communicate final disposition D5 Does Standard ERP content exist? D4 Is the report system resource intensive? No Yes ERP is selected as Reporting Tool and documented Responsible Team member acquires/documents additional information No D3 Significant number of users? BW is selected as Reporting Tool and documented in doc. tool Communicate final disposition 48 BW Team to forward completed detailed report specifications based on selected Reporting Tool - BI or ERP Communicate final disposition ABAP/ Custom Report Writer Query Other A3 Sub-Process Report Consolidation & eliminate if appropriate (winnowing) ERP team make final disposition A4 Baseline reports 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 49 Resources • Evan Delodder and Ray Li, Creating Dashboards with Xcelsius: Practical Guide, SAP PRESS, 1st Edition; (September 15, 2010) • Boris Otto and Jörg Wolter, Implementing SAP Customer Competence Center, SAP PRESS, 1st edition; 1st edition (December 1, 2008) • by Frank K. Wolf and Stefan Yamada, Data Modeling in SAP NetWeaver BW 7.1, SAP PRESS, 1st Edition; (August 1, 2010) 50 7 Key Points to Take Home • • • • • • • Do not jump into a dashboard project. Create a formal strategy, plan, budgets, and scope, and train your staff before you start. Have a formal organization, but do not overstaff. Skills are more important than numbers. Spend serious time on the backend BI system. Not all systems are ready for dashboards – Performance is essential. Consider SAP NetWeaver BW Accelerator as part of your dashboard project. Rollout interactive analysis (SAP BusinessObjects Web Intelligence) as part of the dashboard project – Details are important and users want drill-down capabilities. Make the first rollout short and focused (12-16 weeks max). Use Rapid Application Development (RAD) as you methodology – Anything else does not make sense! 51 Your Turn! How to contact me: Dr. Berg Bberg@ComeritInc.com 52 Disclaimer SAP, ERP, mySAP, mySAP.com, SAP NetWeaver®, 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 SAP. 53