Managing a BW project

1. Managing a BW project San Francisco, SAP, Business Objects and MIG conference August 2004 ….From the BW experts at myITgroup..

2. What we will cover The BW strategy, Business case, Methodology and Approach Getting the right requirements, organizing it, and determining scope (R/3 Vs. BW) Project organization and staffing (Examples) Managing the roll-out Reference Material (Detailed business case and detailed job descriptions)

3. Analytics Vs. reporting – where are you? • Decide early on how much analytics vs. basic reporting the team is going to deliver. • Balanced scorecards based on key performance indicators require more substantial more work than creating simple financial reports. -How will users access data in multiple areas? Analytics contains pre-developed rules to view or examine data

4. Real-time Inquiry Operational Reporting Management Information Lightly Summarized More Summarized More Ad Hoc R/3 BW Dividing Line How much do I put in the BW system?

5. Why have a BW Strategy? The use of BW as a reporting tool across business or functional units has several implications: • BW shares masterdata with other reporting areas • BW shares definitions and structures with other reporting areas • Presentation of data and data views has to be consistent • User training should be standardized and leveraged • Technical support is shared • User support is shared • Data should be loaded only once • Security has to be consistent • BW skills required should be leveraged in the company Without a strategic approach to BW, there are significant risks to the ability to deliver a consistent reporting solution at a reasonable cost of ownership.

6. Why complete BW and R/3 projects at the same time? Leveraging resources: The basis and the business knowledge is available at lower additional costs Avoid rework Avoid rework of standard content when the R/3 module is implemented. Many smaller configurations can be accommodated in without impact to the project team, Consequently, if extensions are made without regards to the BW implementation, rework may be required. Cost avoidance: Avoid creating ABAP and custom reports that is available in BW.

7. Why complete BW and R/3 projects at the same time? Increased customer satisfaction: While R/3 is optimized for transaction processing. BW is maximized for analysis and user access to the data. The available reports, features increases the user experience and thereby the project likelihood of success. Things to watch: Usually the BW implementation starts by lagging 4-6 weeks behind the R/3 team in the Prep, Blueprint and Realization phase. However, during the implementation phase, the BW and the R/3 team are both in-sync for the same go-live date. This lag allows the BW team to leverage the other team’s work without having to sit idle for the first few weeks of the project. It also allows the R/3 team to focus on the processes instead of the data in the beginning of each phase.

8. Summary of Business Benefits of BW (1 of 3)

9. Summary of Business Benefits of BW (2 of 3)

10. Summary of Business Benefits of BW (3 of 3)

11. Rapid Application Development (RAD) • Be flexible and consider using a RAD (Rapid Application development) approach to the initial information requirement gathering. Typical ways to conduct this include: • Ask for 1-2 days of uninterrupted time and provide lunch on-site • Remove cell phones, PDA and pagers and emails • Invite power users, casual users, today's report writers, and managers • Keep a rapid pace and the number manageable (no more than 20) • Focus on shared information needs and conduct multiple sessions if needed. • Don't get trapped in details, give people a chance to provide feedback in writing and follow-up later with individuals. • The benefits include: • Increased user involvement and less disruption to the business • More likely to avoid individual opinions and get more group consensus • You can use the session as an information sharing event and give a brief overview of what you are attempting to do.

12. What we will cover The BW strategy, Business case, Methodology and Approach Getting the right requirements, organizing it, and determining scope (R/3 Vs. BW) Project organization and staffing (Examples) Managing the roll-out Reference Material (Detailed business case and detailed job descriptions)

13. A process look at getting functional specs There are more than one way to collect this information, however, a formal process should exist to capture the requirements and also to communicate what is being developed.

14. Flow overview Reports Business Reporting Requirements BW Reports A real example from a very large manufacturing company

15. Flow overview Storage Storage Requirements BW InfoCubes A real example from a very large manufacturing company

16. Getting the "Right" Requirements • Gathering business requirements that will to establish a project scope that stays focused on user needs. • Use people close to the business that can help you clarify their needs • Ask for only the "top-5" reports from each department and all regulatory requirements • Obtain a copy of each of the current reports used today that are being requested to be developed in BW • Create a form that capture the core requirements in a structured format

17. Getting the "Right" Requirements • Avoid creating a total inventory of all reports in the organization. The "top-5" (most used) sales, distribution, inventory etc. reports from each department will cover the vast majority of the reporting needs. • A single BW "report" may satisfy dozens of today's static reports. It is therefore impossible to map each legacy report to a BW report. Avoid attempting to replicate each report based on what you might have in place today. Accept new ways of accessing data

18. Many requirements can be met by a single BW report + + = Getting the "Right" Requirements • Obtain a copy of each of the current reports used today that are being requested to be developed in BW • Legacy reports may be a great source to document the data needs. They can be used to illustrate how data is being summarized and viewed in the organization. • Create a physical folder with paper copies of "in-scope" legacy reports. Make sure that the development team have access to them and reduce the time spent in meetings with the business community. • Consolidate the requirements and look for "low-hanging fruit".

19. Getting the "Right" Requirements • Create a form that capture the core requirements in a structured format Create a simple form called "information request form" and use it to gather the core relevant information about each report being requested by the business community. This should include at least the following fields: - Contact info about the requestor - Data currency (yesterday/today) - Department - Security requirements - Name of report - How is this reporting done today - Purpose of report - Comments - Description of report - Type of users (mgr./analyst/casual) - Number of users expected - Frequency of report (daily/monthly)

20. Report Dispositioning • Deciding which reports should stay in R/3 or the legacy system. • Not all reports belong in BW. Avoid using BW as a "dumping group" • Make cost effective decisions. Just because the report is not in BW does not mean it cannot be in a portal or on the web • You need to make conscious decisions on what reporting needs you are going to need and how you want to accomplish this. We will now take a look at an approach to a formal report dispositioning that has been used by a few companies.

21. Getting the "Right" Requirements Create a form that capture the core requirements in a structured format Create a simple form called "information request form" and use it to gather the core relevant information about each report being requested by the business community. This should include at least the following fields: - Contact info about the requestor - Data currency (yesterday/today) - Department - Security requirements - Name of report - How is this reporting done today - Purpose of report - Comments - Description of report - Type of users (mgr./analyst/casual) - Number of users expected - Frequency of report (daily/monthly)

22. An example of a simple information request form (from a large oil company) • Used to document requirements in a standardized format • Used to prioritize requirements. • Used to consolidate requirements. • Used for follow-up discussions and reviews. P1 of 2

23. An example (page 2) • You can also post such a form on the intranet and thereby give stakeholders an easy way to communicate with the project team. • You might use the comment section for security requirements, or add a separate section for this. • Note the section for dispositioning the requirement P2 of 2

24. Another example on how Companies have captured requirements

25. More on reporting requirements capture

26. Use a Milestone plan Use a milestone plan to illustrate dependencies and high-level tasks Post this plan on the walls in the hallways, don't hide it in the PM's office. Keep it under 30 items!!

27. Report Dispositioning Deciding which reports should stay in R/3 or the legacy system. • Not all reports belong in BW. Avoid using BW as a "dumping group" • Make cost effective decisions. Just because the report is not in BW does not mean it cannot be in a portal or on the web • You need to make conscious decisions on what reporting needs you are going to need and how you want to accomplish this. We will now take a look at an approach to a formal report dispositioning that has been used by a few companies.

28. Key questions for report dispositioning • Is this really a reporting need or a "want"? • Is the data going to be in BW at a frequency that solves the user's request (intraday reporting)? • Is the data needed for this report already in our BW scope? • Are there already a report available in R/3 ? • Does standard BW content exist? • Is it less expensive to create in R/3? • Are there a significant number of users? • Is the reporting need resource intensive? • Is BW cost effective in the long-run (ownership)?

29. Team starts by reviewing documentation tool for An example on how to decide which reports should be in R/3 or the legacy system (printed version is easier to read) documentation completeness 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 R/3 is selected as Yes Reporting Tool R/3 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 R/3 is selected as Communicate final Reporting Tool D8 and documented disposition No Is BW cost in doc. tool effective? Yes BW is selected as D5 Communicate final Reporting Tool Does Yes disposition and documented No Yes Standard R/3 in the documentation tool content D9 exist? BW is selected as R/3 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? R/3? Standard Report R/3 Writer Yes Yes ABAP/ BW is selected as BW is selected as Communicate final R/3 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 R/3 team make final disposition BW Team to forward completed detailed report specifications A4 based on selected Reporting Tool - BW or R/3 Baseline reports

30. KPI & Scorecard Formatted • Simple • Easy to view • Limited nav • Aggregates • Flat Reporting • Formatted • Print • Form based • Static • Predictable access • OLAP Reporting • Drill Down • Slice and Dice • Analyse • Data Mining • Search and discover OR OR Balancing technical considerations with user goals. Consider multiple ways to display the same data!! • Deliver your reports in a consistent manner to the users (one version of the "truth"), but use different mechanisms to do so. • Managers and executives tends to prefer simple and directed interfaces • Casual users tends to prefer predictable structured access to the data • Analysts and Power users tends to prefer high flexibility and unstructured access to the data. Don't underestimate the user's need to access the information in various ways.

31. What do users really want? Source: SAP

32. What we will cover The BW strategy, Business case, Methodology and Approach Getting the right requirements, organizing it, and determining scope (R/3 Vs. BW) Project organization and staffing (Examples) Managing the roll-out Reference Material (Detailed business case and detailed job descriptions)

33. The BW project organization The BW project consists of five distinct parts of work: 1. Getting the data out of the R/3 system -done by the Extract & transform developer. 2. Storing the data in BW – done by the BW developer 3. Presenting the data – done by the presentation and the portal developer(s) 4. Working with the business – done by the business analyst 5. Managing the project – done by the project manager and the BW architect BW is very much like a traditional data warehouse project with very different technology– unfortunately is has a steep learning curve

34. The BW project organization So how many people do I need and what are they all doing? Determining how many people you need is based on the scope and the timeframe of the development effort. It is just as risky to “over staff” a project as it is to not have the right people on-board. When it comes to BW projects, quality is more important than quantity. – a good BW developer can achieve in one hour what is takes a novice days to figure out. However some good examples from what other companies have done exists and we have included them in this presentation So, is this going to like another two year R/3 project? BW projects, like all other data warehouse projects should be interactive in nature. This means that it is important to show value to the business rapidly. It would be a mistake extend the period between each go-live past 6 months. We therefore recommend the increasingly popular Rapid Application Development (RAD). This allows you to deliver a BW solution often in less than 2-4 months. –BW projects are very different from R/3 projects

35. Basis and functional R/3 support Some examples: A small BW project for single subject area (i.e. billing, inventory or accounts payable). These are roles not positions. (sometimes one team member can fill more than one role) 4-5 team members and normally 3-6 months duration depending on scope

36. Basis and functional R/3 support Some examples: A mid-sized BW project for single complex subject area(i.e. cost and profitability, internal billing). These are roles not positions. (sometimes one team member can fill more than one role) 8-10 team members and normally 2-4 months duration depending on scope

37. Basis and functional R/3 support Some examples: A large BW project for multiple subject areas(i.e. sales, finance and material management) These are roles not positions. (sometimes one team member can fill more than one role) 15-25 team members and normally 6-18 months duration depending on scope

38. What we will cover The BW strategy, Business case, Methodology and Approach Getting the right requirements, organizing it, and determining scope (R/3 Vs. BW) Project organization and staffing (Examples) Managing the roll-out Reference Material (Detailed business case and detailed job descriptions)

39. The Use of “Ambassadors” Getting the PowerUsers involved early is important to the overall success of a Data Warehousing project To help support the businesses that already has gone-live, a strong local community of “ambassadors” is needed. If you don’t have them, on-going projects may get “bogged down” with basic support of reports.

40. The company A BW Data Warehouse Approach at a Company Many regional data warehouses Strong data knowledge in the organizations Experienced non-BW Report writers BW Data Warehouse Alternatives Should a set of Ambassadors be part of the rollout-strategy? How can this be done with minimal organizational disruption?

41. Lessons Learned – Local Resources Of the total work of 7,061 hours for presentation development from August though October, 58% of the enhancement work was performed by local resources. This allowed the central team to change their focus on the next implementation, while ensuring local support and empowered Ambassadors to help the users in each organization.

42. Some Benchmark Indications on Ambassadors.. Increased business involvement, increases the probability for data warehouse project success. Survey of 84 companies: The Conference Board.

43. For more information contact: Dr. Bjarne Berg, Assistant Professor Lenoir-Rhyne College bergb@lrc.edu (704) 604-0010

44. What we will cover The BW strategy, Business case, Methodology and Approach Getting the right requirements, organizing it, and determining scope (R/3 Vs. BW) Project organization and staffing (Examples) Managing the roll-out Reference Material (Detailed business case and detailed job descriptions)

45. What Is the Gartner Group Saying About BW? 1. On Alternatives: “Getting data from R/3 for analytical purposes is extremely difficult, requiring complete understanding of its 8000+ data models and all its embedded relationships.” Two alternatives exists; building a custom data warehouse or use Acta technologies Rapid Marts for R/3. Currently most organization rely on handwritten ABAP programs to get data out of R/3 for reporting.” 2. On when to use the product: Consider BW when “……. SAP business content represents at least 50% of the total needed” 3. On the future: “By 2008, more than 80% of SAP’s R/3 install base will implement BW to meet their operational focused decision support needs (80% probability).”

46. Business Benefits of BW – more details B. Best Practice According to the Gartner Group, organizations that are pursuing a SAP ERP strategy with the a high volume of transaction data processing in SAP, the logical choice for a decision support environment is SAP’s complimentary tool Business Information Warehouse. The Gartner Group estimates that “By 2008, more than 80% of SAP’s R/3 installed base will implement BW to meet their operational focused decision support needs (0.8 probability).” C. Cost Avoidance Most upgrades of the SAP system will change the underlying table structures and will require a rewrite of extract programs being used in an alternative data warehouse solution. Since any custom developed extract programs will continue to evolve, and will also include complex extract routines and logic, the work on analyzing the changes and recode any custom developed extract programs would require substantial resources, compared with an existing support for upgrade path between BW and R/3.

47. D. Savings from Other SAP Offerings Web delivery and SAP Strategy The opportunity costs of not rapidly being able deliver these solution to an organization is hard to quantify, but a decision support system must be able to support web initiatives quickly, and that an initiative will need data “closer” to the transactional system, both in time and in terms of data consistency and data quality. It also allows the organization to leverage the investments in R/3, and the organizational knowledge of SAP to the fullest extent as a strategic investment. This is done by leveraging the existing resources that includes Basic people and ABAP programmers and could also include a common platform for any web portal development. BW could provide for the foundation, as a data provider, for an web strategy that might also include other non-SAP industry tools and offerings. Benefit: As a data provider, BW enables the organization to leverage a variety of tools and packages and maximizes the strategic investments made in SAP.

48. Business Benefits of BW – more details D. Savings from Other SAP Offerings (continued) Integrated Product Offerings: Another observation is the integral part BW plays in SAP’s future, and current, decision support and e-commerce strategy. BW introduces the opportunity for the organization to have an increased spectrum of support capabilities, it also may become a cornerstone in a larger decision support architecture that encompasses e-consumer business, business to business sales, strategic enterprise management, advanced planning and optimization, and a variety of other modules and initiatives from SAP..

49. Business Benefits of BW – more details D. Savings from Other SAP Offerings (continued) Industry trends Two major observations in this area can be made. First, the fact that many public sectors are moving towards installing BW as an integral part of their decision support architecture. This indicates that BW might become the industry standard of the future for governmental organizations who are using SAP. The costs of not being part of this trend is hard to quantify, but include the cost of training resources on the custom system, versus being able to leverage knowledge of people in the industry, as well as a potential more complex integration of these systems in the future if the organization is moving towards data sharing and decision support sharing with other governmental organizations. Benefit: Enables the organization to leverage future solutions

50. Business Benefits of BW – more details E. Faster Deployment The time to develop new systems, or enhance existing systems, has been identified as a critical area by many decision support users. BW will reduce this development time through leveraging the existing pre-delivered content from SAP. This includes standard extractors, common load routines, standard data stores, and pre-delivered reports and interface(s). Industry best practices estimates that up to 60-80% of the pre-delivered content may be used, while the remanding would be customized to meet the needs of an organization. The Garter Group, stated: “SAP supplied content significantly reduces the development efforts for customized applications” (P-10-3024 research note). The leveraging of the business content, especially the standard extractors, provides the organization the ability to more quickly being able to respond to user needs and changing business requirements. As an example a common delivery cycle of an application area of BW is between four and six months, while a common data warehouse delivery cycle is between six and twelve months (almost twice as long).