Presentation on theme: "Managing a BW project ….From the BW experts at myITgroup.."— Presentation transcript:
1 Managing a BW project ….From the BW experts at myITgroup.. San Francisco, SAP, Business Objects and MIG conference August 2004….From the BW experts at myITgroup..
2 The BW strategy, Business case, Methodology and Approach What we will coverThe BW strategy, Business case, Methodology and ApproachGetting the right requirements, organizing it, and determining scope (R/3 Vs. BW)Project organization and staffing (Examples)Managing the roll-outReference Material (Detailed business case and detailed job descriptions)
3 Analytics contains pre-developed rules to view or examine data Analytics Vs. reporting – where are you?Decide early on howmuch analytics vs.basic reporting the teamis going to deliver.Balanced scorecardsbased on key performanceindicators require moresubstantial more workthan creating simplefinancial reports.-How will users accessdata in multiple areas?Analytics contains pre-developedrules to view or examine data
4 How much do I put in the BW system? OperationalReportingMore SummarizedMore Ad HocManagement InformationLightly SummarizedReal-timeInquiryDividing LineR/3BW
5 Why have a BW Strategy?The use of BW as a reporting tool across business or functional units has several implications:BW shares masterdata with other reporting areasBW shares definitions and structures with other reporting areasPresentation of data and data views has to be consistentUser training should be standardized and leveragedTechnical support is sharedUser support is sharedData should be loaded only onceSecurity has to be consistentBW skills required should be leveraged in the companyWithout a strategic approach to BW, there are significant risks to the ability to deliver a consistent reporting solution at a reasonable cost of ownership.
6 Why complete BW and R/3 projects at the same time? Leveraging resources:The basis and the business knowledge is available at lower additional costsAvoid reworkAvoid rework of standard content when the R/3 module is implemented. Many smaller configurations can be accommodated in without impact to the project team, Consequently, if extensions are made without regards to the BW implementation, rework may be required.Cost avoidance:Avoid creating ABAP and custom reports that is available in BW.
7 Why complete BW and R/3 projects at the same time? Increased customer satisfaction:While R/3 is optimized for transaction processing. BW is maximized for analysis and user access to the data. The available reports, features increases the user experience and thereby the project likelihood of success.Things to watch:Usually the BW implementation starts by lagging 4-6 weeks behind the R/3 team in the Prep, Blueprint and Realization phase. However, during the implementation phase, the BW and the R/3 team are both in-sync for the same go-live date.This lag allows the BW team to leverage the other team’s work without having to sit idle for the first few weeks of the project. It also allows the R/3 team to focus on the processes instead of the data in the beginning of each phase.
8 Summary of Business Benefits of BW (1 of 3) AreaObservationBWBenefitCost of OwnershipMaintaining custom developed application is complex and expensive.SAP is responsible for maintenance of the product.Substantial maintenance cost savingsCost AvoidanceRehosting extract programs from R/3 when upgrading R/3 is expensive.BW follows the upgrade path with R/3Substantial cost savings by not having to redevelop new extract programs for each SAP upgradeWeb 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 informationBW is “closer” to the source system and more accurately reflects dataUsers spend less time on reconciling data and more on analyzing it.Information AccessBusiness users need a high availability of dataLoad times in BW is reduced compared with traditional custom developed data warehousesUsers get earlier access to information
9 Summary of Business Benefits of BW (2 of 3) AreaObservationBWBenefitFaster DeploymentNeed to increase time to delivery of new applications and enhancements to existing areasUse of 60-80% of pre-delivered content increased development speedReduced development time for new decision support areasIntegrated ProductsSAP is offering a variety of new products and modules that the organization might want to leverage in the futureBW is the “corner stone” in SAP’s New Dimension product offeringsEnables closer integration with other SAP modulesQuery speedBusiness users need data fastThrough use of summaries, BW’s architecture lends itself to faster query performanceUsers get faster access to information
10 Summary of Business Benefits of BW (3 of 3) AreaObservationBWBenefitSAP 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 waysMicrosoft’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 BWIncreased industry resource pool and knowledge of BWEnables the organization to leverage industry solutions and know-how.
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-siteRemove cell phones, PDA and pagers and sInvite power users, casual users, today's report writers, and managersKeep 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 businessMore likely to avoid individual opinions and get more group consensusYou can use the session as an information sharing event and give a brief overview of what you are attempting to do.
12 The BW strategy, Business case, Methodology and Approach What we will coverThe BW strategy, Business case, Methodology and ApproachGetting the right requirements, organizing it, and determining scope (R/3 Vs. BW)Project organization and staffing (Examples)Managing the roll-outReference 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 A real example from a very large manufacturing company Flow overviewReportsBusiness Reporting RequirementsBW ReportsA real example from a very large manufacturing company
15 A real example from a very large manufacturing company Flow overviewStorageStorage RequirementsBW InfoCubesA 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 needsAsk for only the "top-5" reports from each department and all regulatory requirementsObtain a copy of each of the current reports used today that are being requested to be developed in BWCreate 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 BWLegacy 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 formatCreate a simple form called "information request form" and use it togather the core relevant information about each report beingrequested by the business community. This should include at leastthe 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 webYou 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 formatCreate 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 documentrequirements in astandardized formatUsed to prioritizerequirements.Used to consolidateUsed for follow-updiscussions and reviews.P1 of 2
23 An example (page 2) You can also post such a form on the intranet and thereby give stakeholdersan easy way tocommunicate with theproject team.You might use thecomment section forsecurity requirements, oradd a separate sectionfor this.Note the section fordispositioning therequirementP2 of 2
26 Use a milestone plan to illustrate dependencies and high-level tasks Post this plan on the walls in the hallways, don't hide it in the PM's office.Keep it under 30 items!!
27 Report Dispositioning Deciding which reports should stay in R/3 or the legacy system.Not all reports belong in BW. Avoid using BW as a "dumping group"Make cost effective decisions. Just because the report is not in BW does not mean it cannot be in a portal or on the webYou need to make conscious decisions on what reporting needs you are going to need and how you want to accomplish this.We will now take a look at an approach to a formal report dispositioning that has been used by a few companies.
28 Key questions for report dispositioning Is this really a reporting need or a "want"?Is the data going to be in BW at a frequency that solves the user's request (intraday reporting)?Is the data needed for this report already in our BW scope?Are there already a report available in R/3 ?Does standard BW content exist?Is it less expensive to create in R/3?Are there a significant number of users?Is the reporting need resource intensive?Is BW cost effective in the long-run (ownership)?
29 Team starts by reviewing documentation tool for An example on how to decide which reports should be in R/3 or the legacy system (printed version is easier to read)documentation completenessReview requirements and identifycorresponding Data Model (InfoCube/ODS)D1D1aIs reportYesIs this a trueNoCommunicate todocumentationreportingbus. leadercomplete?needYesNoD2D2.5D3D4Is thisDoes data existIs the reportan IntradayNoin "in-scope" modelsNoSignificantnumberNosystemRequest additionalreport?Infocube/ODSof users?resourceintensive?Noinput from BusinessTeam memberYesYesYesR/3is selected asReporting ToolR/3is selected asand documentedReporting ToolA2in doc. tooland documentedTotal Cost ofResponsibleOwnershipTeam memberAnalysisacquires/documentsadditional informationR/3is selected asCommunicate finalReporting TooldispositionD8Noand documentedIs BW costin doc. toolYeseffective?D5BWis selected asDoesReporting ToolCommunicate finalYesStandard R/3Noand documentedYesdispositioncontentin the documentation toolexist?D9BWis selected asR/3 ToolD6D7reporting tool and ChangeSelectionDoesIs it lessCommunicate finalRequest is submitted ifProcessStandard BWNoexpensive todispositionthe scope changedcontentcreate inexist?R/3?NoStandardReportYesYesR/3WriterBWis selected asR/3is selected asBWis selected asCommunicate finalABAP/QueryOtherReporting Tool andReporting ToolReporting Tool anddispositionCustomdocumented in doc.and documenteddocumented in doc.toolin doc. tooltoolA3Sub-Process Report Consolidation &Communicate finalCommunicate finalCommunicate finaleliminate if appropriate (winnowing)dispositiondispositiondispositionR/3 team make final dispositionBW Team to forward completed detailed report specificationsbased on selected Reporting Tool - BW or R/3A4Baseline reports
30 Balancing technical considerations with user goals. Consider multiple ways to display the same data!!Deliver your reports in a consistent mannerto the users (one version of the "truth"), butuse different mechanisms to do so.Managers and executives tends to prefer simpleand directed interfacesCasual users tends to prefer predictable structuredaccess to the dataAnalysts and Power users tends to prefer highflexibility and unstructured access to the data.Flat ReportingFormattedPrintForm basedStaticPredictable accessOLAP ReportingDrill DownSlice and DiceAnalyseData MiningSearch and discoverKPI & Scorecard FormattedSimpleEasy to viewLimited navAggregatesORDon't underestimate the user's need to access the information in various ways.
32 The BW strategy, Business case, Methodology and Approach What we will coverThe BW strategy, Business case, Methodology and ApproachGetting the right requirements, organizing it, and determining scope (R/3 Vs. BW)Project organization and staffing (Examples)Managing the roll-outReference 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 developer3. Presenting the data – done by the presentation and the portal developer(s)4. Working with the business – done by the business analyst5. Managing the project – done by the project manager and the BW architectBW is very much like a traditional data warehouse project with very different technology – unfortunately is has a steep learning curve
34 The BW project organization So how many people do I need and what are they all doing?Determining how many people you need is based on the scope and the timeframe of the development effort. It is just as risky to “over staff” a project as it is to not have the right people on-board. When it comes to BW projects, quality is more important than quantity. – a good BW developer can achieve in one hour what is takes a novice days to figure out.However some good examples from what other companies have done exists and we have included them in this presentationSo, is this going to like another two year R/3 project?BW projects, like all other data warehouse projects should be interactive in nature. This means that it is important to show value to the business rapidly. It would be a mistake extend the period between each go-live past 6 months. We therefore recommend the increasingly popular Rapid Application Development (RAD). This allows you to deliver a BW solution often in less than 2-4 months. – BW projects are very different from R/3 projects
35 Some examples: A small BW project for single subject area (i. e Some examples: A small BW project for single subject area (i.e. billing, inventory or accounts payable).These are roles not positions. (sometimes oneteam member can fill more than one role)Basis and functional R/3 support4-5 team members and normally3-6 months duration depending on scope
36 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 oneteam member can fill more than one role)Basis and functional R/3 support8-10 team members and normally2-4 months duration depending on scope
37 Some examples: A large BW project for multiple subject areas (i. e Some examples: A large BW project for multiple subject areas (i.e. sales, finance and material management)These are roles not positions. (sometimes oneteam member can fill more than one role)Basis and functional R/3 support15-25 team members and normally6-18 months duration depending on scope
38 The BW strategy, Business case, Methodology and Approach What we will coverThe BW strategy, Business case, Methodology and ApproachGetting the right requirements, organizing it, and determining scope (R/3 Vs. BW)Project organization and staffing (Examples)Managing the roll-outReference 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 projectTo 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 Many regional data warehousesStrong data knowledge in the organizationsExperienced non-BW Report writersBW Data Warehouse AlternativesThe companyShould a set of Ambassadors be part of the rollout-strategy?How can this be done with minimal organizational disruption?
41 Lessons Learned – Local Resources Of the total work of 7,061 hours for presentation development from August though October, 58% of the enhancement work was performed by local resources.This allowed the central team to change their focus on the next implementation, while ensuring local support and empowered Ambassadors to help the users in each organization.
42 Some Benchmark Indications on Ambassadors.. Increased business involvement, increases the probability for data warehouse project success.Survey of 84 companies: The Conference Board.
43 Dr. Bjarne Berg, For more information contact: Assistant Professor Lenoir-Rhyne College(704)
44 The BW strategy, Business case, Methodology and Approach What we will coverThe BW strategy, Business case, Methodology and ApproachGetting the right requirements, organizing it, and determining scope (R/3 Vs. BW)Project organization and staffing (Examples)Managing the roll-outReference 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 PracticeAccording 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 AvoidanceMost 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 StrategyThe 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 andpackages and maximizes the strategic investments made in SAP.
48 Business Benefits of BW – more details D. Savings from Other SAP Offerings (continued)Integrated Product Offerings: Another observation is the integral part BW plays in SAP’s future, and current, decision support and e-commerce strategy. BW introduces the opportunity for the organization to have an increased spectrum of support capabilities, it also may become a cornerstone in a larger decision support architecture that encompasses e-consumer business, business to business sales, strategic enterprise management, advanced planning and optimization, and a variety of other modules and initiatives from SAP..
49 Business Benefits of BW – more details D. Savings from Other SAP Offerings (continued)Industry trendsTwo major observations in this area can be made. First, the fact that many public sectors are moving towards installing BW as an integral part of their decision support architecture. This indicates that BW might become the industry standard of the future for governmental organizations who are using SAP.The costs of not being part of this trend is hard to quantify, but include the cost of training resources on the custom system, versus being able to leverage knowledge of people in the industry, as well as a potential more complex integration of these systems in the future if the organization is moving towards data sharing and decision support sharing with other governmental organizations.Benefit: Enables the organization to leverage future solutions
50 Business Benefits of BW – more details E. Faster DeploymentThe 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).
51 Business Benefits of BW – more details F. Faster Decision MakingInformation AccessToday, 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 informationQuery Speed ImprovementThrough 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
52 Business Benefits of BW – more details F. Faster Decision Making (continued)Reduced Reconciliation EffortA 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
53 Business Benefits of BW – more details G. Improved Customer ServiceLeveraging 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
54 Business Benefits of BW – more details I. Standardization of ToolsAs 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.
55 The BW Team Members – Role descriptions BW PROJECT MANAGERThe 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 ARCHITECTThe 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 systemsSupervising 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 assuranceReviewing and participating in testing of data design, tool design, data loads and presentation system design.Transformations, gateways, networks, and hardware selection and sizing.
56 The BW Team Members – Role descriptions BW DEVELOPERThe 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 DEVELOPERSThe 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.
57 The BW Team Members – Role descriptions BUSINESS ANALYSTThe 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 DEVELOPERThe 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.
58 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.