Responsibilities of an implementation project
For ex, Lets say If its a fresh implementation of BI or for that matter you are implementing SAP.
First and foremost will be your requirements gathering from the client. Depending upon the requirements you will creat a business blueprint of the project which is the entire process from the start to the end of an implementation.
After the blue print phase sign off we start off with the realization phase where the actual development happens. In our example after installing the necessary softwares, patches for BI we need to discuss with the end users who are going to use the system for inputs like how they want a report to look like and what are the Key Performance Indicators(KPI) for the reports etc., basically its a question and answer session with the business users.
After collecting those informations the development happens in the development servers.
After the development comes to an end the same objects are tested in quality servers for any bugs, errors etc., When all the tests are done we move all the objects to the production environment and test it again whether everything works fine.
The Go-Live of the project happens where the actually postings happen from the users and reports are generated based on those inputs which will be available as an analytical report for the management to take decisions.
The responsibilites vary depending on the requirement. Initially the business analyst will interact with the end users/managers etc., then on the requirements the software consultants do the development, testers do the testing and finally the go-live happens.
BW Data Architect Description:
The BW Data Architect is responsible
for the overall data design of the BW project. This includes the design
of the:
BW InfoCubes (Basic Cubes, Multi-cubes,
Remote cubes, and Aggregates) » BW ODS Objects » BW Datamarts
» Logical Models » BW Process Models » BW Enterprise
Models
The BW Data Architect plays a critical role in the BW project and is the link between the end user's business requirements and the data architecture solution that will satisfy these requirements. All other activities in the BW project are contingent upon the data design being sound and flexible enough to satisfy evolving business requirements.
Time Commitment
– the time which must be committed
to this Role to ensure the project requirements are met Project Complexity
Time Commitment Low If the BW project utilizes standard BW content and
InfoCubes, this role can be satisfied by the BW Application Consultant.
Medium
If the BW project requires enhancements
to the standard BW content and InfoCubes and/or requires the integration
of non-SAP data, this role may require a committed resource.
High
If the BW project requires significant
modification and enhancement to standard BW content and InfoCubes, it is
highly recommended that an experienced resource be committed full-time
to the project.
Key Attributes
The BW Data Architect must have:
An understanding of the BW data
architecture » An understanding of multidimensional modeling »
An understanding of the differences between operational systems data modeling
and data warehouse data modeling » An understanding of the end user's
data » An understanding of the integration points of the data (e.g.,
customer number, invoice number) » Excellent troubleshooting and
analytical skills » Excellent communication skills » Technical
competency in data modeling » Multi-language skills, if an international
implementation » Working knowledge of the BW and R/3 application(s)
» Experience with Data Modeling application software (i.e., ERWIN,
Oracle Designer, S-Designer, etc.)
Key Tasks
The BW Data Architect is responsible
for capturing the business requirements for the BW project. This effort
includes:
Planning the business requirements
gathering sessions and process » Coordinating all business requirements
gathering efforts with the BW Project Manager » Facilitating the
business requirements gathering sessions » Capturing the information
and producing the deliverables from the business requirements gathering
sessions » Understanding and documenting business definitions of
data » Developing the data model » Ensuring integration of
data from both SAP and non-SAP sources » Fielding questions concerning
the data content, definition and structure
This role should also address other
critical data design issues such as:
Granularity of data and the potential
for multiple levels of granularity » Use of degenerate dimensions
» InfoCube partitioning » Need for aggregation at multiple
levels » Need for storing derived BW data » Ensuring overall
integrity of all BW Models » Providing Data Administration development
standards for business requirements analysis and BW enterprise modeling
» Provide strategic planning for data management » Impact analysis
of data change requirements As stated above, the BW Data Architect is responsible
for the overall data design of the BW project.
This includes the design of the:
BW InfoCubes (Basic Cubes, Multi-cubes,
Remote cubes, and Aggregates) » BW ODS Objects » BW Datamarts
» Logical Models » BW Process Models » BW Enterprise
Models
BW Project Implementation and Rollout
Global IDs uses a modified version of the ASAP methodology to ensure a robust BW environment is implemented, tested, and delivered. The project milestones include the following:
Blueprinting
Realization
Roll Out
Post-Implementation Support
Organizational Change Management
BW Maintenance
*Phase 1: Upgrade Project Preparation -*
The purpose of this phase is to provide initial planning and preparation for your R/3 upgrade project. Although each upgrade project has unique objectives, scope and priorities, the steps in Phase 1 help identify and plan the primary topics that must be considered.
*Phase 2: Business Blueprint -*
The purpose of this phase is to establish a common understanding in your company about how the new R/3 release will handle your current business processes after the R/3 upgrade.
*Phase 3: Realization of DEV and QAS -*
The purpose of this phase is to
perform the upgrade of all non-production R/3 Systems, which normally include
development (DEV) and quality assurance
(QAS) systems, and to ensure the
quality of this upgrade process by comprehensive testing. You need to upgrade
your DEV and QAS systems before performing the upgrade for your production
system (PRD). Furthermore, you will develop your end user documentation
and training in this phase.
*Phase 4: Realization of Production -*
The purpose of this phase is to complete the final preparation for the upgrade of the production R/3 System, and end user training, if necessary. On the successful completion of this phase, you are ready to run your business in your upgraded production R/3 System.
*Phase 5: Go Live and Support -*
The purpose of this phase is the transition from your previous R/3 System to a newly upgraded and improved R/3 System. Be aware that you must set up an ongoing support organization to service your R/3 users, both during the first few days of your upgraded production operations, and on an ongoing basis.
