Home » Applications » Oracle Fusion Apps & E-Business Suite » different phases in implementation
|
|
 Re: different phases in implementation [message #230375 is a reply to message #230312] |
Wed, 11 April 2007 12:57   |
cnubandi
Messages: 21
Registered: October 2006
Location: Andhra Pradesh,Indai.
|
Junior Member |
|
|
AIM Phases
AIM projects are conducted in phases. These phases provide quality and control checkpoints to coordinate project activities that have a common goal. During a project phase, your project team will
simultaneously be executing tasks from several processes.
Definition
During Definition, you plan the project, review the organization’s business objectives, understand the business processes, and evaluate the feasibility of meeting those objectives under time, resource, and budget
constraints. The emphasis is on building an achievable work plan and introducing guidelines on how the organization will work to achieve common objectives. Establishing scope early in the implementation
gives the team a common reference point and an effective way to communicate. Strategies, objectives, and approaches are determined for each AIM process, providing the basis for the project plan.
To achieve an early understanding of current business operations and future processes, the team also performs base lining and process modeling during this phase. If business process change is applicable,
you review existing business processes and create high-level future process designs during this phase.
The goal is to identify future business and system requirements, propose the future business model, and determine the current application and information technology architecture. The information gathered provides input to downstream activities in subsequent phases. The team reviews financial, operational, technical, and administrative processes and leads workshops with representatives from the
organization’s staff to verify that all stakeholders understand and agree on the detailed business requirements. All business requirements are associated with planned future business processes. Sharing an accurate understanding of these requirements is a critical success factor for the
project. If business process change is applicable, then the project team develops
high-level process scenarios that are used to assess the level of fit between the idealized future processes for the organization and standard application functionality. Gaps are identified, and corresponding solutions developed. The analysis results in a high-level design for future business processes. This high-level design is developed into more detailed business process designs during the
Operations Analysis phase. During Definition, the executive management of the organization is
engaged in several interactive sessions. The project team is organized and oriented. A learning plan is developed and project team members are skilled in their appropriate areas. In addition, the Communication Campaign (AP.080) for the project is begun.
Operations Analysis
During Operations Analysis, the project team develops the Business Requirements Scenarios (RD.050) based on deliverables from Definition that are used to assess the level of fit between the detailed business
requirements and standard application functionality. Gaps are identified and new proposed solutions are developed. The analysis results in a proposal for conducting business operations under the envisioned application technical architecture. Proposed solutions for gaps evolve into detailed designs during the Solution Design phase. A model for the application architecture is created and the technical architecture is designed. The technical architecture includes high-level platform, software, and communications components to support the future business system. The Application and Technical Architecture
(TA) process documents are used to develop detailed designs during Solution Design.
To develop models of future business operations, you must verify your initial assumptions regarding proposed functionality for gaps. The new system may require only minor modifications to forms, reports, and programs. The team should explore workarounds to application gaps before considering custom modifications or new developments. If the new system requires custom development, the team prepares high-level design documents. These documents include general descriptions of the required features and a work estimate for each customization. The approach to be taken for the customizations and estimates are approved before detailed design begins during Solution Design. The Performance Testing team creates models for testing the performance characteristics of the new system. These models usually
focus on critical system processing associated with key business functions and transactions.
During this phase, work sessions are conducted for middle managers and first-line managers who are not on the project team, to assume their role in a successful implementation.
Finally, a Transition Strategy (PM.010) is developed for migrating the organization from the current system to the new production system.
Solution Design
The purpose of Solution Design is to develop the detailed designs for the new system to meet the future business requirements. During this phase, project team members create detailed Business Procedure
Documentation (BP.090). Supporting business requirements may require building application extensions to standard features — several alternative possibilities may have been defined during Operations Analysis. The project team carefully scrutinizes these possibilities and chooses the most cost
effective alternatives. To design effective business systems, you should make sure that planned user roles and job procedures are efficient. When designing new systems, consider organizational changes, process improvement, and reengineering initiatives to the extent that they are incorporated into the project scope. These initiatives often affect how application features should be utilized. While new system designs are being finalized, the application and technical architecture begins to take form. The technical staff designs a
technical architecture that can support the standard application configuration and customizations, and considers the future system architecture needs of the company. The technical staff also designs
performance testing programs and the environment for executing the performance tests.
Business process design is iterative. Tasks that span both the Operations Analysis and Solution Design phases may be performed as a unit by a design team.
Build
The coding and testing of all customizations and other custom software, including application extensions, data conversions, and interfaces, is done during the Build phase. Business system testing is performed to validate that the functionality meets business requirements. If customizations, extensions, or conversions are not required, the Build phase is still important because it includes the business system test,
which is commonly conducted as a formal conference room pilot (CRP) test. The business system test validates the configuration of the new system and is performed in an environment that closely resembles
production. As the new system is being created, you begin to develop custom application documentation and systems operating documentation. As the system is refined, the documentation is reviewed and revised. Developers produce unit-tested and link-tested program modules. System and systems integration tests are performed and a working, tested business system is delivered at the end of the phase. During Build, the Performance Testing team creates Performance Testing components and executes the performance tests. In addition, user learning ware is developed and a user learning environment is set
up. Finally, during Build the production support infrastructure is designed and a Transition and Contingency Plan (PM.030) is developed.
Transition
During Transition, the project team deploys the new system into the organization. All the elements of the implementation must come together to transition successfully to actual production. The project
team trains the users while the technical team configures the Production Environment and converts data.
During Transition, users perform an acceptance test of the new system. Transition is a demanding experience for the project team, and in particular, for the users who have to maintain exposure to two systems until a new production system is declared. Managing changes and buffering your organization from negative impacts must be top priority. Preparation and planning facilitate the transition process. Transition ends with the cut over to production, when users start performing their job duties using the new system. If a phased deployment is being employed, Transition may consist of multiple deployments where subsets of the applications may be deployed to various geographical sites and/or business units at
different times.
Production
Production begins immediately with the production cutover. It marks the last phase of the implementation and the beginning of the system support cycle. A series of refinements and performance measurement steps is included in this final phase. The information technology personnel work quickly to stabilize the new system and begin regular maintenance. They provide the ongoing support to the organization for the remaining life of the system. During Production, you compare actual results to project objectives and determine if improvements can be made. Controlled system refinement begins to minimize the impact to users. Finally, you start preliminary planning of the future business and technical direction of the company. If multiple deployments exist, Production will occur at different times for the various geographical sites and business units.
Regards.
cnubandi.
|
|
|
|
|
|
Goto Forum:
Current Time: Thu Nov 07 19:36:44 CST 2024
|
] 
Blog
Search
Help
Members
Register
Login
Home
