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 cover
The BW strategy, Business case, Methodology and Approach
Getting the right requirements, organizing it, and determining scope (R/3 Vs. BW)
Project organization and staffing (Examples)
Managing the roll-out
Reference Material (Detailed business case and detailed job descriptions)

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

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

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

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

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

8. Summary of Business Benefits of BW (1 of 3)
Area
Observation BW
Benefit
Cost of Ownership
Maintaining custom developed application is complex and expensive.
SAP is responsible for maintenance of the product.
Substantial maintenance cost savings
Cost Avoidance
Rehosting 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 strategy
Web 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 Effort
A 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 Access
Business 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. Summary of Business Benefits of BW (2 of 3)
Area
Observation BW
Benefit
Faster Deployment
Need 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 Products
SAP 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 speed
Business users need data fast
Through use of summaries, BW’s architecture lends itself to faster query performance
Users get faster access to information

10. Summary of Business Benefits of BW (3 of 3)
Area
Observation BW
Benefit
SAP Strategy
It 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 Standardization
the 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 Trend
the 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.

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. The BW strategy, Business case, Methodology and Approach
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. A real example from a very large manufacturing company
Flow overview
Reports
Business Reporting Requirements
BW Reports
A real example from a very large manufacturing company

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

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

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

18. 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
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
Post this plan on the walls in the hallways, don't hide it in the PM's office.
Keep it under 30 items!!

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

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

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

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

31. What do users really want?
Source:
SAP

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

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

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

35. 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 one
team member can fill more than one role)
Basis and functional R/3 support
4-5 team members and normally
3-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 one
team member can fill more than one role)
Basis and functional R/3 support
8-10 team members and normally
2-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 one
team member can fill more than one role)
Basis and functional R/3 support
15-25 team members and normally
6-18 months duration depending on scope

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

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

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

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

50. Business Benefits of BW – more details
E. Faster Deployment
The time to develop new systems, or enhance existing systems, has been identified as a critical area by many decision support users. BW will reduce this development time through leveraging the existing pre-delivered content from SAP. This includes standard extractors, common load routines, standard data stores, and pre-delivered reports and interface(s). Industry best practices estimates that up to 60-80% of the pre-delivered content may be used, while the remanding would be customized to meet the needs of an organization. The Garter Group, stated: “SAP supplied content significantly reduces the development efforts for customized applications” (P 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 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

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

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

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

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

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

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.