1. © 2004 Wellesley Information Services. All rights reserved. Dr. Bjarne Berg Comerit Inc. How to Manage a BW Project

2. © 2004 Wellesley Information Services. All rights reserved. Dr. Bjarne Berg Lenoir Rhyne College

3. 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. 4 Why have a BW Strategy? The use of BW as a reporting tool across business or functional units has several implications: 1.BW shares masterdata with other reporting areas 2.BW shares definitions and structures with other reporting areas 3.Presentation of data and data views has to be consistent 4.User training should be standardized and leveraged 5.Technical support is shared 6.User support is shared 7.Data should be loaded only once 8.Security has to be consistent 9.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. 5 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.

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

7. 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. 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. 9 Flow overview Business Reporting Requirements BW Reports Reports A real example from a very large manufacturing company

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

11. 11 Another example on how Companies have captured requirements

12. 12 More on reporting requirements capture

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

14. 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. 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. 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. 17 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". ++ = Many requirements can be met by a single BW report

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

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

24. 24 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. Tip Balancing technical considerations with user goals.

25. 25 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. Flat Reporting Formatted Formatted Print Print Form based Form based Static Static Predictable access Predictable access OLAP Reporting Drill Down Drill Down Slice and Dice Slice and Dice Analyse Analyse Data Mining Data Mining Search and discover Search and discover KPI & Scorecard Formatted Simple Simple Easy to view Easy to view Limited nav Limited nav Aggregates Aggregates Don't underestimate the user's need to access the information in various ways. OR Balancing technical considerations with user goals.

26. 26 Source: SAP What do users really want?

27. 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. 28 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 The BW project organization

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

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

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

32. 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. 33 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. products time periods version

34. 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. Query Development BW security Data Management Web support This organization fit the BW support organization into the existing SAP organization and made it very centralized. When BW projects was started by the organizational units, the developers from the central organization was “loaned” to the projects in a full-time on-site capacity for the duration of the project and did not report to the support organization for the project duration New Central Support Model Example

35. 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. BW Support Portal support End-user support Developer pool New Central Support Model Environment Management Shared service center Basis support Security Group Developer pool IT company Example 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. Developer pool Acquired company

36. 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. 37 The BW Support Organization Company D: A large global European telecom company with a very decentralized IT staff. They have been live on BW since 1998. Example Corporate Group Production CompanySales Organization Corporate Finance 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.

38. 38 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. Co. ACo. BCo. CCo. D Development Support Development Effort End-User Support System administration Environment support = Centralized = Decentralized 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. 39 A Paradox and an Issue 80-85% of the BW project effort is spent on getting requirements, building the right data stores, extract programs and the operational data stores 99% of the BW project success will be judged based on the look and functionality of the queries and web reports. The BW project paradox: However: If users can get to the data easily, they do not care where the data resides.

40. 40 Replacing Decision Support Systems (DSS) Source: Fredrik Hoogren Swedish Civil Economist Association 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.

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

43. 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. 44 Some Benchmark Indications on Ambassadors.. Survey of 84 companies: The Conference Board. Increased business involvement, increases the probability for data warehouse project success.

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

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

47. 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. 48 Your Turn! Dr. Bjarne Berg Comerit Inc bergb@comeritinc.com

49. © 2004 Wellesley Information Services. All rights reserved. Reference Material Dr. Bjarne Berg Comerit Inc.

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

51. 51 BW DEVELOPER The BW developer is responsible for creating the data objects for the reporting areas. This includes designing all structures within BW that supports the reporting, such as ODS objects, InfoCubes and drill-through cubes (views). This also include creating data models for the subject areas, as well as the formal approval process for each object. The data structures are based on the user requirements gathered during the project’s interview phase, and enhanced during the blueprinting phase. core requirements for the data model comes from user inputs and the work conducted by the business analyst. Key deliverables include data models for each data structure developed, test planning and execution, and documentation of extensions to standard business content, a data dictionary and an implementation of master data, hierarchies and changing dimensions. In addition this individual is responsible for the performance testing and tuning and the development of aggregates, indexing strategies and partitions. The role of BW developer is a key to the overall project success, and the individual must have very strong BW skills with implementation experience from other BW systems. EXTRACT AND TRANSFORM DEVELOPERS The extract and transfer data developer is responsible for designing data extracts and reviewing the data available on the SAP R/3 legacy system. It involves reviewing existing load routines and validation programs, creating all objects and mappings from R/3 to BW, and validating standard content provided. The developer will create custom developed validation rules and generic extracts as needed to support the level of customization needed in the ODS and InfoCubes. The developer should also understand the nature and quality of the data and should provide a data dictionary of the source data, if this is not available from the source system. Key deliverables from this group is the source – target mapping of each field used in BW to SAP R/3 and automated extract, load, validation, cleansing and reconciliation programs from source system(s) to BW. During the realization phase, the extract and transform developers are designing each individual extract needed for moving data from R/3 components to InfoCubes, or ODS, that are being designed by the data architect. This includes validation of selection criteria, filtering, load logic (ABAP), data cleansing, source-target mapping validation, and documentation of each extract design for the InfoCubes, ODS objects in scope. The individuals staffed in these roles must have very strong R/3 and BW experience with solid understanding of ABAP coding as well. The BW Team Members – Role descriptions For your reference only!!

52. 52 The BW Team Members – Role descriptions BUSINESS ANALYST The Business analyst is responsible for the overall development of reports that supports the functional of the project from an BW perspective. During blueprinting, this individual is responsible for gathering detailed reporting requirements from the business users and existing reporting groups within the organization. A key deliverable from this effort are detailed reporting requirements for areas such as the general ledger, accounts payable, accounts receivable, reconciliation efforts, closing procedures, cost and profit center accounting, and overhead management. The ideal candidate for this position should have detailed knowledge of the industry that the company operates in, and a solid understanding of the reporting needs of such an organization. The individual should also have strong communication skills and the ability to plan, conduct and document interviews with managers and users. This analyst will also be managing the user acceptance testing and feedback process from representatives for the user community, and assure that those requirements are being met by the reporting system being built. During the roll-out of the system the business analyst are engaged in the user documentation development as well as the development and execution of the user training. PORTAL DEVELOPER The developer in this position is responsible for the design and development of user roles for accessing the SAP BW environment. This includes the creation of security requirements for the user interface, BW role reconciliation, as well and integration of reporting help features, collection of external data for reporting purposes and the integration between BW reports and jump-points to the transactional system. The individual in this role is also responsible for the design and development of standard templates for reports delivered by the development teams, as well as the user acceptance process for these templates. In a SAP Portals environment, the individual is also responsible for the content management section of the portal and the configuration on the navigation bars and initial launch pad. The individual staffed in this technical position should have a strong reporting and design background from SAP BW as well as development knowledge of portals and the integration of standardized reporting environments. Prior industry experience would also be helpful. The individual must also have solid programming experience in HTML, Java and XML. For your reference only!!

53. 53 The BW Team Members – Role descriptions PRESENTATION DEVELOPERS (a.k.a. report writers) The presentation developer is responsible for designing core reports for the functional area that they support. This includes reviewing business requirements, existing reports, and working with the BW developers to assure that the business requirements are supported in the cube and/or the ODS design, and creating template reports for user acceptance based on requirements. The presentation developer is also an individual who has a specific tool background. The developer may later work on 3rd party presentation tools and SAP’s Business Explorer. The developers must assure data security, user friendly reports, "drill-down" features, as well as a flexible design of data hierarchies and a logical and easy to use Graphical Unit Interface (GUI) for end-users. Finally, the developer must assure that the front-end tool provides all functionalities supported by the logical data model(s) and that the tool takes advantage of the physical database design features. The design work also includes a detailed description of each access point, the navigation of access points, as well as a detailed role description with association to the pertinent reports. The presentation developers also work with the portal developer to integrate roles with the existing roles in the web portal. For your reference only!!

54. 54 Lessons Learned - Project Management A User Acceptance Team (UAT) of 3-5 people should be created from the first day, and all acceptance criteria should be established well in advance of the implementation Use of Rapid Application Development is the preferred development way Use a phased business content approach with standard delivered content first, then customize if absolutely needed. It is hard to accurately estimate the data movement effort, 80% of delays and surprises occur in this area, and this work is often under-estimated

55. 55 Lessons Learned - Project Management An estimated 35% of all BW projects are delayed due to poor planning (source: SAP BI Conference Hamburg) The focus should be on the work to be completed and not on the work plan itself - treat the work plan only as a tool and adjust as needed Spend less time on the project preparation phase and as much as possible on the realization phase. Many issues cannot be planned, but time can be set aside to deal with them.

56. 56 Lessons Learned - Team Composition Developer training should start early for all project team members SAP R/3 skills are not easily transferable to BW, hands-on experience is needed (it is very hard to learn while being productive) The quality of the team members are much more important than the number of members. A skilled BW developer can accomplish in one day, what 3 novice developers can do in a week (the tool has a steep learning curve). Project time and cost estimates should be based on teams experience level Plan on formal knowledge-transfer from external resources from day one. Link inexperienced members with experienced ones Have identified “go-to” resources available for in all areas (make a list)