9. * 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.
10. 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
11. 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
12. 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
13. 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
14. 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
15. • A proven implementation
•
•
•
approach
Complete toolkit
Highly tailorable to
project-specific
requirements
Addresses your
objectives
– People
– Processes
– Technology
16. * 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
17. * 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)
18. 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.
19.
20. * 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
21. * High-Level Process Designs
* Current Business Baseline
* Preliminary Conceptual Architecture
* Project Readiness Roadmap
* Communication Campaign
22. * 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
23. 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.
24.
25. * 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
26. * Future Process Model
* Business Requirements
Scenarios
* Mapped Business
Requirements
* Mapped Business Data
* Confirmed Business
Solutions
* Conceptual Architecture
* Application Extension
Definition and Estimates
27. * 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
28. 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.
29.
30. * 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
31. * Application Setup Documents
* Approved Designs
* Conversion Data Mapping
* System Test Script
* Systems Integration Test Script
* User Learning Plan
32. * 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.
33.
34. * 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.
35. * 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
36. * 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
37.
38. * 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
39. * Converted and Verified Data
* Acceptance Test Results
* Skilled Users
* Production System
* Production Support
Infrastructure
40. * 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.
41. 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.
42.
43. * 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
44. * 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.
45. *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
46. * 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
47.
48. * 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
53. 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
55. 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
57. 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
59. 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
61. 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
62. 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
64. 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
66. 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
69. 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.
71. 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
73. 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
75. 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
76. 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.
Notes de l'éditeur
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).