Application Implementation Methodology (AIM)


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • I’ll summarize AIM, the manual is around:356+504+520+160
  • chron·o·log·i·calWithin these phases are the various processes.Each process is made up of a number of tasks.Each task has a deliverable for which there is normally a documentation template.
  • The goal of the Definition phase is to determine the high-level business andinformation system requirements necessary to meet a set of definedbusiness objectives. The Definition phase results in a clear definition ofa project’s functional scope.The objectives of the Definition phase follow:• Obtain a clear understanding of the business processes,functions, and information required to meet the project’sdefined business objectives.• Identify unifying vision and business objectives.• Verify senior executives’ buy-in to the project.• Create a leadership pattern across the organization.• Initiate a sponsorship network.• Facilitate crucial informed project startup decisions.• Design an effective infrastructure for delegation.• Build consensus around project direction.• Review the organization’s existing processes and align themwith the capabilities of the relevant Oracle Applicationsmodules and other software.• Develop the Preliminary Conceptual Architecture (TA.030).• Determine the high-level architectural, technological, andconfiguration requirements to support the functional andinformation needs of the application system.• Define the project scope clearly.• Examine the existing business processes and informationsystems affected by the project’s defined business objectives.• Design improved high-level business processes.• Obtain management approval to proceed with OperationsAnalysis.
  • Project Readiness RoadmapA plan for addressing the human and organizational factors that impact the success of the implementation. It includes a readiness strategy, implementation decisions, a communication strategy, and a learning strategy for users.
  • PrerequisitesProcessesKey Deliverables
  • Project Readiness RoadmapA plan for addressing the human and organizational factors that impact the success of the implementation. It includes a readiness strategy, implementation decisions, a communication strategy, and a learning strategy for users.
  • The objectives of the Operations Analysis phase follow:• Produce accurate information, function, and process models forthe business areas being addressed.• Define the detailed function, data, and operational requirementsthat the new application system must support.• Design business processes in detail, covering the variants of thehigh-level processes developed in Definition.• Map business requirements to application capabilities andpropose solutions to gaps.• Demonstrate that the proposed business process design isfeasible for the organization.• Define a technical architecture of hardware and software inwhich the application system must perform.• Refine the technical architecture of hardware and software.• Propose a transition strategy for moving from the currentsystem to the new application system.• Identify audit and control reporting and application integrationrequirements.• Develop performance testing models and scenarios.
  • Business RequirementsScenariosA set of formal statements of thedetailed business requirements foreach business process, the source ofthese requirements, how theserequirements will be satisfied (eitherby the application, manual processsteps, workarounds, or by otherapplications), and what prototypingsteps must be taken to prove thedesigns.
  • Document the design specifications in a way that facilitates and supports future maintenance of the system.Develop functional and technical designs for custom extensions, interfaces, conversion programs, and database extensions
  • The mapping of the legacy systemfiles and data elements to the targetapplication tables and columns.
  • The Link Test Script (TE.030) is executed to test the detailed interaction between relatedapplication extension modules.Integration-Tested System: The integration between the target application system and other systems is tested.
  • Change Catalog : A catalog and initial analysis of thecosts, benefits, and risks of changingthe application or processes.High-Level Process Vision A general, high-level statement ofhow the new processes will operateto meet the organization’s objectives.
  • The Business Requirements Scenarios (RD.050) list the necessary stepsfor executing a business function within a business process; some of thesteps may be application-specific, and some may be manualCurrent Business Baseline: An analysis of the current businessprocesses and functions.
  • Application Architecture Addresses the deployment andconfiguration of applications acrossdata centers, servers, and hardwareplatforms.Technical Architecture Addresses the configuration andcapacity planning of the hardwareplatform and network infrastructureand system management issues.
  • Technical Reference Manual: Maintenance instructions for database extensions, custom programs, and upgrade considerations.System Management Guide: A set of procedures for managing the application system.
  • Reading from left to right, thediagram indicates that Documentation begins by defining yourDocumentation Requirements and Strategy (DO.010) to determinewhich documents you need to produce and your strategy for producingthem. Next, you specify the organization’s Documentation Standardsand Procedures (DO.020) to capture the expected look and feel of the newdocumentation. Throughout the project, project-specific terms arecaptured and described in the Glossary (DO.030). After theDocumentation Environment (DO.040) is prepared, you are ready tobegin building the Documentation Prototypes and Templates (DO.050)of the four main project documents. Ultimately, every documentationtask exists to contribute to the publication of the User Reference Manual(DO.060), User Guide (DO.070), Technical Reference Manual (DO.080),and System Management Guide (DO.090).
  • Reading from left to right, the figure shows thatthe testing process begins with defining the Testing Requirements andStrategy (TE.010). After the Testing Requirements and Strategy isprepared, testers begin developing unit, link, system, and systemsintegration test scripts (TE.020, TE.030, TE.040, and TE.050). These testscripts are used to guide testers through the various stages of the testingprocess. While test scripts are being prepared, one or more TestingEnvironments will be configured (TE.060). These Testing Environmentsare used by the testers to perform their unit, link, system and systemsintegration tests (TE.070, TE.080, TE.110, and TE.120). While the systemtest environment is being configured, key users receive theirinstructions (TE.100) and the Installation Routines (MD.120) are tested(TE.090) to verify that custom extensions will be properly loaded intothe Production Environment (PM.040). Once testing is completed in thetest environment, users are supported in their acceptance testing(TE.130) of the new production system.A conference room pilot (CRP) test refers to the technique of setting upa conference room where the testers’ workstations are arranged in aparticular order (usually by logical processes) and the test scripts arepassed down the line from one tester to the next according to thenatural flow of the business process. A CRP test usually involvesperforming a system test to check the validity of application setups, andthe integration of business system flows within the target applicationssystem. For more information on the CRP testing technique, seePerform System Test (TE.110).
  • Application Implementation Methodology (AIM)

    1. 1. Mohamad Abou Haouili
    2. 2. mohamadabouhaouili mohamadabouhaouili @abouhaouili
    3. 3. * * * * * *
    4. 4. * 3 pilot implementations. * 9 rollouts. * 24 modules implemented. * 185 custom components. * 18 Consultants. * 3 countries.
    5. 5. *What is AIM *AIM – Structure *AIM – Phases *AIM – Processes *AIM – Preview / Demo *Q&A
    6. 6. * Set of principles and guidelines that can be tailored and applied to specific situations. * Strategic approach that clearly defines an organization’s business needs at the beginning of implementation and offers validity till the completion. * Proven Methodology used for successful implementation.
    7. 7. AIM unlocks the mystery... • Provides a detailed roadmap for implementation • Leverages the experience of thousands of successful implementations • Encompasses all essential project steps 4th Generation of Oracle’s Application Implementation Methods
    8. 8. We need a rapid implementation... • Tailor the approach to specific project requirements • Only do what needs to be done • Effort is focused on relevant, high-value tasks resulting in – High return on investment – Quick time to benefit AIM Defines the Fastest Route to Implementation
    9. 9. Are we on target... • AIM leverages packagedenabled reengineering to incorporate leading practices • AIM supports prototyping during solution design • Quality built in from project inception Quality Checkpoints & Acceptance Certificates
    10. 10. How do we get buy-in... • AIM includes Adoption and Learning tasks throughout the project lifecycle – Build acceptance from project inception • AIM includes guidelines for facilitating communication throughout the organization Adoption and Learning Process
    11. 11. Deliverable Templates Pre-seeded Content and Sample Data Customizable Workplans Project Management Support Detailed Task Descriptions On-line, Context Sensitive Documentation All delivered in an easyto-use, web-based interface
    12. 12. • A proven implementation • • • approach Complete toolkit Highly tailorable to project-specific requirements Addresses your objectives – People – Processes – Technology
    13. 13. * Planning * Requirements definition * Business process alignment and modeling * Customization * Interfaces and integration between systems * Data conversion * Organization change management * Application and technical architecture * Reporting * Security and access control
    14. 14. * October 1994, Oracle launches AIM * July 1997, AIM 2.0, a refined version of the method * September 1999, Oracle introduced AIM Advantage 3.0 * 2007, Oracle has launched AIM's 3.1 version * AIM will be part of OUM ( Oracle Unified Method)
    15. 15. A phase is a chronological grouping of tasks. It enables a flexible way to organize tasks, schedule major deliverables, and deliver projects. A process is a closely related group of dependent tasks which meets a major objective. A process is usually based on a common discipline. A task is a unit of work, which results in a single deliverable. I. e reports, schedules, cod e, or test results for example.
    16. 16. * Obtain a clear understanding of the business processes * Plan the project * Review the organization's business objectives * Evaluate the feasibility of meeting those objectives under time, resource, and budget constraints * Emphasis is on building an achievable work plan and introducing it with guidelines. * Strategies, objectives, and approaches are determined for each AIM process
    17. 17. * High-Level Process Designs * Current Business Baseline * Preliminary Conceptual Architecture * Project Readiness Roadmap * Communication Campaign
    18. 18. * Sponsorship of senior management that is clear and visible to the project stakeholders * Clear definition of the business objectives * Active participation by key management and business users * Access to information related to the existing business processes and systems
    19. 19. Risk Mitigation Business strategy or business Process objectives are not sufficiently well understood. Confirm the organization’s business strategy. If necessary, run workshops to document and analyze the organization’s business processes. Unclear expectations. Define clear objectives and performance measures, and attach a timeline for realization of benefits. Communicate regularly to manage expectations.
    20. 20. * Develops Business Requirements Scenarios * Assess the level of fit between the business requirements and application functionality. * Gaps are identified and corresponding solutions developed * Provide a proposal for : * Future business processes * Technical architecture model * Application architecture model * Workarounds for application gaps * Performance testing models * Transition strategy to migrate to the new system * Solutions for gaps evolve into detailed designs during Solution Design
    21. 21. * Future Process Model * Business Requirements Scenarios * Mapped Business Requirements * Mapped Business Data * Confirmed Business Solutions * Conceptual Architecture * Application Extension Definition and Estimates
    22. 22. * Active participation by team management * Clear definition of the business objectives to be addressed by the project * Access to information related to the existing business processes and systems affected by the project
    23. 23. Risk Mitigation Insufficient consideration Consider alternatives that do given to resolving gaps with not require custom code alternative approaches. development, such as altering business processes to match system functionality, workarounds, cost/benefit analysis for all alternatives. Limited access to information about business areas and their processes Conduct frequent checkpoints that include a management review to verify that teams are not being blocked from gathering information.
    24. 24. * Develop the detailed designs to meet the future business requirements. * Document the design specifications properly. * Define proposed application setups and test plans. * Design the security architecture of the new system. * Develop functional and technical designs for custom components. * Develop unit, link, system, and system integration test scripts. * Analyze user learning needs and develop the User Learning Plan
    25. 25. * Application Setup Documents * Approved Designs * Conversion Data Mapping * System Test Script * Systems Integration Test Script * User Learning Plan
    26. 26. * Clearly documented application setups. * Designs that are traceable to business requirements. * Designs that remain within scopes. * Allocation of sufficient time resources. * Well-managed change control system. * Good framework for transition and contingency planning.
    27. 27. * Develop, test, and accept standard and custom software. * Develop and accept all documentation deliverables including: * User Reference Manual * User Guide * Technical Reference Manual * System Management Guide *Create, test, and accept database extension and installation routines.
    28. 28. * Application and Database Server Architecture * Platform and Network Architecture * User Guide * Link-Tested Modules * System-Tested Applications * Integration-Tested System * Performance Test Report * Transition and Contingency * Plan
    29. 29. * Accurate and complete design documentation * Clear design and testing of platform, network, and other technical considerations * Appropriate involvement of hardware vendors in the configuration of the hardware environment. * Adequate testing * Effective participation by executive and user management
    30. 30. * Convert and verify legacy data * Perform acceptance testing. * Prepare the production environment and configure the applications. * Project team delivers the finished solution to the enterprise * End-user training and support * Begin to use the Production System
    31. 31. * Converted and Verified Data * Acceptance Test Results * Skilled Users * Production System * Production Support Infrastructure
    32. 32. * Effective participation by business management. * Sufficient technical and application architecture. * Successful performance of acceptance testing * Successful completion of the production readiness plan. * Active listening and timely response to all concerns. * Evidence that all employees understand their new performance objectives and expectations. * Committed user involvement and ownership.
    33. 33. Risk Mitigation Changes made to application setups in the testing environment not documented in the production. Establish a procedure for migrating changes to application setups into the production environment. Users who are unprepared to use the production system. Provides incentives for system skill mastery, and prevents system use by people who have not demonstrated the proper level of qualification.
    34. 34. * Provide agreed upon levels of user support. * Measure system performance and enhance as required. * Retire the former systems. * Propose and plan the future business and technical direction. * Improve organizational knowledge and skills for the new environment. * Devote attention to post-implementation issues like user acceptance, productivity, and human performance support
    35. 35. * Effective use of change control tools and procedures. * Adequate staff and expertise. * Effective participation by business management and users. * Effective technical and application architecture. * Effective post-implementation environment to facilitate productivity.
    36. 36. *A process in AIM represents a related set of objectives, resource skill requirements, inputs, and deliverable outputs. *A task can belong to only one process. *Project team members are usually assigned to a process according to their specialization and background. *12 Processes as referred in AIM
    37. 37. * Project Management ( PJM) * Project Management itself is a comprehensive process and has separate way to handle it, i.e. PMBOK , Oracle PJM etc * PJM Processes. * Project Management life-cycle categories. Task ID CR: Control & Reporting , WM: Work Management, RM: Resource Management QM: Quality Management, CM: Configuration Management
    38. 38. * Controlling and reporting: - Determine the scope and approach of the project. - Manage change. - Control risks. - Control the Project Management Plan. - Report progress status. * Work Management * Define, monitor, and direct all work performed on the project. * Maintain a financial view of the project. * Resource Management * Quality Management * Implement quality measures * Project meets the organization’s purpose and expectations * Configuration Management * Store, organize, track, and control all items delivered to the project
    39. 39. Business Process Architecture
    40. 40. Business Process Architecture * Task Code/ID : BP * Identify the core processes of the organization. * Produce a vision and high-level designs of how processes would operate after implementation of the application. * Make business focused decisions either to change the current processes to suit the application or to customize the application. Commonly used templates
    41. 41. Business Requirements Definition
    42. 42. Business Requirements Definition * Task Code/ ID: RD * Defines the business needs that must be met by the implementation project. * Develop a complete set of business requirements scenarios that can be used to map business requirements to application functionality. * Analyze and identify the reporting requirements for the business * Carefully document audit and control requirements to satisfy financial and quality policies. Commonly used templates
    43. 43. Business Requirements Mapping
    44. 44. Business Requirements Mapping *Task Code/ ID: BR *Establish application fit to business requirements. *Identify gaps and propose initial alternatives; propose feasible bridges to gaps *Define detailed setup parameters. Commonly used templates
    45. 45. Application & Technical Architecture
    46. 46. Application & Technical Architecture * Task Code/ ID: TA * Design an information systems architecture to realize the business vision. * This process divide into two areas:- 1. Application Architecture, 2. Technical Architecture * The process develops a blueprint for deploying and configuring: * Oracle, third-party, and custom applications * Supporting application server environments * Critical interfaces and data distribution mechanisms between applications, servers, and sites * Computing hardware, including servers and client desktop platforms * Networks and communications infrastructure
    47. 47. Module Design & Build
    48. 48. Module Design & Build * Task Code/ ID: MD * Focus on the design and development of customizations to satisfy functionality gaps identified during Business Requirements Mapping (BR). * Modification — changes to the base Oracle Applications code * Extension — new forms, reports, programs, tables, interfaces and triggers that add functionality without changing the base application code * Configurable Extension — addition of functionality through flex fields, alerts, and other configuration options provided by the Applications Continue to Next Slide Commonly used templates
    49. 49. Module Design & Build RD050 – Identify Requirements and GAPS BR030- Mapping- Business Requirement Mapping for GAPS identified. MD020- Analysis and select best approach. Effort Estimation.  Review & Approval. MD050 & MD070 –Functional & Technical Design. One customization may include multiple modules TE020 & TE030 Technical Analyst prepare unit test script and Link Test Script for each module MD110 –Code- Developer create Module source Code i.e. procedure, form, alerts etc TE070 & TE080 Testers perform a unit test and link test
    50. 50. Data Conversion
    51. 51. Data Conversion * Task Code/ ID: CV * Convert and test all necessary legacy data for the operation of the new system. * Conversion Approaches * Manual Conversions * Programmatic Conversion with or w/o tools
    52. 52. Documentation
    53. 53. Documentation * Task Code/ ID: DO * Reference that shows the users how to use application functionality. * Set of procedures for using the application in response to day-to-day business events. * Documents that describe the technical details of the application for the maintenance staff. * Produce a set of procedures for managing the system. Continue to Next Slide
    54. 54. Documentation
    55. 55. Business System Testing
    56. 56. Business System Testing * Task Code/ ID: TE * Three main aspects of Business Testing – Planning, Early Introduction of Testing & CRP. * Business System Testing does not address performance testing or the testing of data conversion programs.
    57. 57. Performance Testing
    58. 58. Performance Testing * Task Code/ ID: PT * Enables you to define, build, and execute a performance test. * To make decisions if performance is acceptable for the business * Propose tactical or strategic changes to address the performance quality shortfall. * Automated V/s Manual * Types of Performance Testing * System Performance * Module/ Code Performance * Hardware and Networks
    59. 59. Adoption & Learning
    60. 60. Adoption & Learning * Task Code/ ID: AP * Focuses on the use and acceptance of new applications by all users and the optimization of organizational performance. * Adoption and Learning impacts the following five major audiences: * Executives * Implementation project teams * Functional managers * Users * Information technology groups
    61. 61. Production Migration
    62. 62. Production Migration * Task Code/ ID: PM * To migrate the organization, systems, & people to the new enterprise system. * Assessing readiness for transition to production. * Executing cutover to the new system. * conducting post-production support
    63. 63. Production Migration objectives: *Prepare the production environment according to the transition plan. *Move to the production environment. *Establish support for the production environment. *Measure actual performance against expectations and plans. *Refine and tune the system to reflect business process change. *Determine future direction for business and technology opportunities.