Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Managing a BW project ….From the BW experts at myITgroup.. San Francisco, SAP, Business Objects and MIG conference August 2004."— Presentation transcript:

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

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 –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 Analytics Vs. reporting – where are you?

4 Operational Reporting More Summarized More Ad Hoc Management Information Lightly Summarized Real-time Inquiry Dividing Line R/3BW 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: 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.

6 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. Why complete BW and R/3 projects at the same time?

7 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. Why complete BW and R/3 projects at the same time?

8 Summary of Business Benefits of BW (1 of 3) AreaObservationBWBenefit Cost of OwnershipMaintaining custom developed application is complex and expensive. SAP is responsible for maintenance of the product. Substantial maintenance cost savings Cost AvoidanceRehosting extract programs from R/3 when upgrading R/3 is expensive. BW follows the upgrade path with R/3 Substantial cost savings by not having to redevelop new extract programs for each SAP upgrade Web strategyWeb delivery requires rapid data delivery of high consistency with the source system. BW is closely integrated with R/3 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 EffortA 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 on analyzing it. Information AccessBusiness users need a high availability of data Load times in BW is reduced compared with traditional custom developed data warehouses Users get earlier access to information

9 AreaObservationBWBenefit Faster DeploymentNeed to increase time to delivery of new applications and enhancements to existing areas Use of 60-80% of pre- delivered content increased development speed Reduced development time for new decision support areas Integrated ProductsSAP is offering a variety of new products and modules that the organization might want to leverage in the future BW is the “corner stone” in SAP’s New Dimension product offerings Enables closer integration with other SAP modules Query speedBusiness users need data fastThrough use of summaries, BW’s architecture lends itself to faster query performance Users get faster access to information Summary of Business Benefits of BW (2 of 3)

10 AreaObservationBWBenefit SAP StrategyIt is the organization’s SAP strategy to leverage investments in the SAP to the fullest extent. BW is a SAP product that fits the organization’s strategy. We can also leverage the organization’s Basis and ABAP people in BW projects. Strategic fit and synergy with SAP. Tool Standardizationthe organization must be able to leverage industry standards to enable business users to access data in a variety of ways Microsoft’s ODBO application interface is supported by a variety of major presentation and web tools. Simplifies user access to data and provides higher flexibility to leverage presentation and web tools. Industry Trendthe organization’s competitors and some of the organization’s business areas are installing BW Increased industry resource pool and knowledge of BW Enables the organization to leverage industry solutions and know-how. 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 s 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 Business Reporting Requirements BW Reports Reports A real example from a very large manufacturing company

15 Flow overview Storage Requirements BW InfoCubes Storage 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 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

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

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 1.Is this really a reporting need or a "want"? 2.Is the data going to be in BW at a frequency that solves the user's request (intraday reporting)? 3.Is the data needed for this report already in our BW scope? 4.Are there already a report available in R/3 ? 5.Does standard BW content exist? 6.Is it less expensive to create in R/3? 7.Are there a significant number of users? 8.Is the reporting need resource intensive? 9.Is BW cost effective in the long-run (ownership)?

29 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 (printed version is easier to read)

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

31 Source: SAP What do users really want?

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

35 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)

36 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-4 months duration depending on scope These are roles not positions. (sometimes one team member can fill more than one role)

37 Some examples: A large BW project for multiple subject areas (i.e. sales, finance and material management) Basis and functional R/3 support 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)

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

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

43 For more information contact: Dr. Bjarne Berg, Assistant Professor Lenoir-Rhyne College (704)

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 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 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 Business Benefits of BW – more details

50 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 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). Business Benefits of BW – more details

51 F. Faster Decision Making Information Access Today, any non-BW data warehouse must load data from the R/3 system in stages throughout the evening in order to complete the load within a 24 hours time period. This is due to the lack of any mechanisms for tracking only changed records by non-SAP tools. The load time is also increasing as more data is captured in the source system. From a management perspective, this means that data may not always be available to the end-users in a timely manner. BW provides for a substantial reduction of the load time through processing only the changed records for most of the extractors. This means that data can be loaded at pre-set intervals and the data load time would decrease. From a management perspective this increases the data delivery speed to the warehouse and thereby assures the users with more timely access to new data. Data could also be processed at short intervals and be used to support more “near time” applications. Benefit: Users and managers gets earlier access to information Query Speed Improvement Through the use of pre-aggregates suggested by BW, the organization will be able to reduce query performance substantially. This is accomplished through the use of system defined and recommended pre-aggregates based on observed usage patterns, and automatic routing of queries to these aggregates. Thereby, BW may substantially reduce the query delivery time to the end-user. Benefit: Users gets faster access to information Business Benefits of BW – more details

52 F. Faster Decision Making (continued) Reduced Reconciliation Effort A substantial portion of a data warehouse effort is spent on reconciling data from the source system. During a data warehouse development project, one objective is to move “closer” to the transactional data. This means sharing definitions across the enterprise and groups, assuring that the transaction system captures the correct data in an appropriate format, while spending less time on stabilization and reconciliation efforts. Custom-made extract routines and complex logic is needed to capture data across many modules in SAP, to be able to see the whole process flow from a record perspective. BW will move the organization closer to the source in terms of definitions and in load logic via standard extract programs created by SAP. Data integration may therefore occur at many stages, including during the data load, cleansing or during querying of the data structures. The extractors will be maintained by SAP and the data warehouse team can focus on the internal organization of the data stores and the load logic rather than the complex extract programs within R/3. This leads to a simplified environment where the data provided will more closely reflect what is in the R/3 system. This area of the business case can therefore be summarized as a reduction in the technical effort of reconciliation of data across R/3 modules and a closer alignment to shared definitions between the transactional and the decision support environment. Benefits: Users spend less time on reconciling data and more on analyzing it Business Benefits of BW – more details

53 G. Improved Customer Service Leveraging the SAP architecture will allow the organization to externalize the data easier in an integrated DSS environment. This include allowing customers to review their orders on-line, checking on their shipment records, as well as reviewing items such as their payment and maybe even the organization’s inventory. The externalizing of the data is a dramatic increase in customer service and reduces the paper documents needed to support the customer. However, before the organization can achieve this the organization must create the architectural infrastructure that will enable us to meet the data needs of the end-users. BW can be the foundation for web-enabling the data warehouse in a packaged solution that can rapidly be employed. Benefit:The ability to externalize the data over the web Business Benefits of BW – more details

54 I. Standardization of Tools As the industry matures, the use of standardized interfaces and protocols will increase. BW’s open-ended architecture is based on Microsoft’s ODBO standard. This emerging standard, is the application equivalent of the 1990s standardization of database interfaces via ODBC. Today most “best-of-breed” tools support this standard, including Microsoft, InSight, Business Objects, Brio, Arcplan, Cognos and others. This allows the users to choose between a variety of front-end tools, integrating new presentation tools are simplified, and users can leverage the best tool for their situation. Future application can be written using these industry standard tools, while costly complicated database and application integration efforts can be alleviated. Benefit:Simplified user access to data and higher flexibility of leveraging presentation and web tools. Business Benefits of BW – more details

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

56 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

57 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. The BW Team Members – Role descriptions

58 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. The BW Team Members – Role descriptions


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

Similar presentations


Ads by Google