Dr. Bjarne Berg Comerit Inc.

1. How to Manage a BW Project Dr. Bjarne Berg Comerit Inc.

2. Dr. Bjarne Berg Lenoir Rhyne College

3. What We’ll Cover … • Getting the job done – RAD, ASAP, SDLC and Strategy • Gathering of requirements from SAP BW and UAT • Project organization • Go-live support organization (a few examples)

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

5. Why complete BW and R/3 projectsat 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.

6. Why complete BW and R/3 projectsat 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.

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

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

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

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

11. Another example on how Companies have captured requirements

12. More on reporting requirements capture

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

14. What We’ll Cover … • Methodology. - RAD, ASAP, SDLC and Strategy • Gathering of requirements from SAP BW & UAT • Project organization • Go-live support organization (a few examples)

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

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

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

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

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

20. Team starts by reviewing documentation tool for An example on how to decide which reports should be in R/3 or the legacy system. 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

21. 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)?

22. User Acceptance Testing (UAT) Involving relevant business departments, regardless of organizational and geographical boundaries. • Create a user acceptance team with a total of 5-7 members from the various business departments or organizations. Keep the number odd to assist with votes when decisions are made. With fewer than 5 members it can be hard to get enough members present during a certain meeting. • Make them the focus of the requirements gathering in the early phase and later let this team become the user acceptance team (testing) in 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 the team. . This approach is hard to execute when also managing scope, but essential to make sure the system meets the requirements

23. Evolution of ERP Data Warehousing Complex (score cards, budgeting, planning, KPI) Horizontal approach (2nd generation) Integrated analytical (3rd generation) Level of Embedded Analytics Emerging (1st generation) Vertical approach (2nd generation) Interactive Mgmt. reporting (OLAP, MQE) Toolsets & accelerators Analytical applications for specific industries Level of Pre-delivered Content Source: Bjarne Berg, DM Review, 2000

24. Tip Balancing technical considerations with user goals. • Determine early how the new system will have to interact with other ERP and web delivery mechanisms. • Determine early what you leverage & what requirement gathering effort has already been started (issue logs)? • What has to be upgraded? • How well do they like what they have? Very early in the project, sit down with a user and let him/her walk you through the current system and shown you the current features and limitations.

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

26. What do users really want? Source: SAP

27. What We’ll Cover … • Methodology. - Compare the highly iterative Rapid Application Development (RAD) approach to more traditional R/3 project approaches. • Gathering of requirements from SAP BW & UAT • Project organization • Go-live support organization

28. 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. 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-8 months. We therefore recommend the increasingly popular Rapid Application Development (RAD). This allows you to deliver a BW solution often in less than 2-6 months. –BW projects are very different from R/3 projects

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

30. 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-12 months duration depending on scope

31. 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-30 team members and normally 6-18 months duration depending on scope

32. What We’ll Cover … • Methodology. - Compare the highly iterative Rapid Application Development (RAD) approach to more traditional R/3 project approaches. • Gathering of requirements from SAP BW & UAT • Project organization • Go-live support organization ( a few examples)

33. products time periods version The BW Support Organization There are several ways to organize a BW support team. The following is examples from real companies and their lessons learned. Company A: A large Insurance company located in the US, with many distributed IT support organizations across the country. They have been live on BW since 2001. Company B: A large oil and gas company with a central IT infrastructure and been live on BW since 1999. Company C: A mid-sized home builder with a decentralized IT organization and has been live on BW since 2001. Company D: A large global European telecom company with a very decentralized IT staff. They have been live on BW since 1998.

34. The BW Support Organization Company A: A large Insurance company located in the US, and had many distributed IT support organizations across the country. They have been live on BW since 2001. Example New Central Support Model

35. The BW Support Organization Company B: A large oil and gas company with a central IT infrastructure and been live on BW since 1999. New Central Support Model Acquired company Shared service center Developer pool IT company Environment Management Developer pool Basis support This organization had two BW developer groups. One was with the financial group (they went first live with BW, and one was with the IT company (each had about 6 developers). When they merged with another large oil company, they inherited a third BW development group (with about 9 more developers). After running this model with 3 development groups and once central support organization it was decided that the coordination effort grew to large, and standards were to hard to enforce, and a decision was made to merge all three groups into one BW developer pool with under the same manager and the same organization. Example Security Group

36. The BW Support Organization Company C: A mid-sized home builder with a decentralized IT organization and has been live on BW since 2001. Example This company had a small BW staff with consisting of 4 employees. Two of these functioned as backend and front-end architects. Project teams were allowed to use consultants to develop what they wanted, but all had to pass the structured walkthrough and approval of the BW architects. This was done to enforce standards and make sure that the system developed conformed to the shared environment constraints. The BW architects spent at least 75% of their time assigned with the project teams and was physically assigned to offices sitting next to the consultants on the project teams.

37. The BW Support Organization This company used a shared BW development staff consisted of the BW central “global business model group” and distributed support for their operating companies in Germany and Holland. The central group did all projects with input and collaboration with the operating companies, but training and power user support was conducted by employees in the operating companies under the existing reporting managers. The result was a centralized development effort, but a scalable distributed support organization. Company D: A large global European telecom company with a very decentralized IT staff. They have been live on BW since 1998. Corporate Group Example Production Company Sales Organization Corporate Finance

38. = Centralized = Decentralized The BW Support Organization Company A: A large Insurance company located in the US, with many distributed IT support organizations across the country. They have been live on BW since 2001. Company B: A large oil and gas company with a central IT infrastructure and been live on BW since 1999. Company C: A mid-sized home builder with a decentralized IT organization and has been live on BW since 2001. Company D: A large global European telecom company with a very decentralized IT staff. They have been live on BW since 1998. The tendency in for these companies has to centralize as much as possible. The development effort tends to supported by pool resources from a centralized group, but be assigned for a substantial amount of time with the project teams on-site, either as architects, or as developers.

39. A Paradox and an Issue The BW project paradox: 80-85% of the BW project effort is spent on getting requirements, building the right data stores, extract programs and the operational data stores However: 99% of the BW project success will be judged based on the look and functionality of the queries and web reports. If users can get to the data easily, they do not care where the data resides.

40. Replacing Decision Support Systems (DSS) BW, as a data warehousing tool, will replace many decision support systems and reports in use today. Local support is therefore imperative to assure organizational adoption and a high degree of flexibility. Source: Fredrik Hoogren Swedish Civil Economist Association

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

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

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

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

45. BW as emerging technology BW as emerging technology are not well understood therefore user experimentation unlocks value. Ambassadors assists experimentation.

46. Resources • In the back of your presentation booklet you will find : • Staffing descriptions, roles and responsibilities. • Lessons learned from project management and team composition • Rapid Development by Steve McConnell Paperback: 680 pages ; Publisher: Microsoft Press; ISBN: 1556159005 • Start to Finish Guide to IT Project Management by Jeremy Kadlec Digital: 109 pages. Publisher: NetImpress; ISBN: B0000W86H2 You can download it at:

47. 7 Key Points to Take Home • Review the high-level requirements and map them to the standard business content provided in BW • Make an assessment on how much enhancements will be needed and the effort of those enhancements • Build business case for the project with high level milestones and a high-level budget • Develop a detailed staffing plan, start “on-boarding” and training • Begin hardware and software analysis (operating system, database and servers). • Plan initial data scoping (volumes, network and data cleansing needs) and review need for additional presentation tools • Write a high-level work plan with interim deadlines (to be refined with the project team) • Start project and have fun…….

48. Your Turn! Dr. Bjarne Berg Comerit Inc bergb@comeritinc.com

49. Reference Material Dr. Bjarne Berg Comerit Inc.

50. The BW Team Members – Role descriptions BW PROJECT MANAGER The project manager should be a dedicated resource, and not be involved in other major projects. This role is the key to the project's success. The manager is responsible for: • Creating and maintaining all project plans and organizing the work environment. • Making timely decisions and delegating tasks. • Effectively communicating with all members of the team. • Facilitating project meetings. • Understanding key concepts of Data Warehousing and their implications. • Managing "crisis" and issues effectively. • Assuring that dead lines are met and quality is delivered. • Managing time and expense. BW ARCHITECT The data warehouse architect should be an individual who is familiar with all technology aspects of data warehousing. The data warehouse architect should have participated on more than one successful data warehouse project in a key technical role, and should have a thorough understanding of front-end tools, load tools, data base engines, data design and the technical infrastructure. The data warehouse architect is responsible for: • Integrating all applied technologies and design the technology architecture for all integrated systems • Supervising the technical aspect of the data warehouse. • Leading tool evaluations and provide recommendations to the project leader. • Providing input and recommendations on technical issues to the project leader. • Reviewing technical work of other team members for quality assurance • Reviewing and participating in testing of data design, tool design, data loads and presentation system design. • Transformations, gateways, networks, and hardware selection and sizing. For your reference only!!