1

AIM methodology for Oracle

eBusiness Suite



Overview of AIM
(Applications Implementation Method)
Where Used - New implementations & re-implementations of Oracles E-
Business Suite
Defining Characteristics:
Developed exclusively for Oracle Applications
Core & Optional tasks provide flexibility
Projects are generally Time and Materials (Build to Suit)
Related Pre-Packaged Solutions -
FastForward/FastForward
RPM
/FastForward Flows
Projects generally Fixed Time/Fixed Scope/Fixed Cost (RPMs only)
Related Advantage Offerings - AIM Advantage

2
Overview of AIM
(Applications Implementation Method) contd.
Where Used - New implementations & re-implementations
of Oracles E-Business Suite

Defining Characteristics:
Developed exclusively for Oracle Applications
Core & Optional tasks provide flexibility
Projects are generally Time and Materials (Build to
Suit)

Base Approach Iterative Conference Room Pilots using
Information Engineering Approach for Extension
Development

Related Pre-Packaged Solutions Business Flow
Accelerator Service Offerings

Related Advantage Offerings - N/A

3
Methods What are They?
Road map for getting something done
so we dont miss something important
so we dont dwell on something that is unimportant
so we dont reinvent the wheel
Common language/process of communication
Common place to identify and document forward progress and decisions
A proven approach that can be consistently repeated
Representative of best practices
4
Benefits of Using a Method
Well defined work plans
Reduced learning curve
Pre-defined guidelines, standards, and deliverable templates
Higher quality results
Path to success
Reduced risk
Better communication
Projects delivered on time and on budget

5
Method Concepts: Task
A task is a unit of work that results
in output of a single deliverable
or revision of an existing deliverable.

Tasks may have one or more
outcomes/outputs:
Setup of an application
Creation or update of a document
Execution of an activity
(i.e Test Plan)

Two types of Tasks:
Core
Optional

6
Definition
Operations
Analysis
Solution
Design
Build Production Transition
Tasks
Method Concepts: Phase
Phases are a grouping of tasks that
lead to a major project deliverable
or milestone

Phases cut vertically through
project activities
Are natural points to establish
milestones for progress checkpoint
7
Definition
Operations
Analysis
Solution
Design
Build Production Transition
Phases
Method Concepts: Process
A process is a grouping of tasks within a method based on common
functions or disciplines which lead to one or more key deliverables
8
Definition
Operations
Analysis
Solution
Design
Build Production Transition
Processes
Method Concepts: Approach
1. An Approach is a variation or subset of a method, packaged in order to
efficiently support the delivery of a service or solution.
Examples:
Classic/Foundation Approach (can be tailored/ build to suit)
Pre-packaged Approach (e.g., pre-defined Solutions such as
FastForward)

2. An Approach also refers to the project management techniques/ concepts
embodied in a method.
Examples:
Traditional Information Engineering (IE)/(Structured Waterfall)
Dynamic Systems Development Method (DSDM)

9
AIM for Business Flows Top
Level Flow
10
Determine Exception
Dispositions
Update Flows
Update Procedures
Update Setups
Update Test Script
Prepare CRP 3.0
Environment
Conduct CRP 3.0
Identify Exceptions
Determine Exception
Dispositions
Update Flows
Update Procedures
Update Setups
Update Test Script
Prepare CRP 2.0
Environment
Conduct CRP 2.0
Identify Exceptions
Definition Build Production Transition

Elaboration
Project
Planning
Conduct
CRP 1.1
(Familiarization)
Conduct
CRP 1.2
(Mapping)
Identify
Exceptions
Conduct
Business
Architecture
Workshops
Design
Extensions
Prepare
Custom
Test Scripts
Create and test
Custom
Extensions
Prepare
Production
Environment
Convert and
Verify Data
Begin
Production
Maintain
System
Propose
Future
Direction
Perform Systems
Integration
Test
Perform
Acceptance
Test
Classic Phases
11
Business Requirements Definition
Existing Systems Examination
Technical Architecture
Database Design and Build
Module Design and Build
Data Conversion
Documentation
Testing
Training
Transition
Post-System Support
Analysis Build Production
AIM Business Flow
12
Common AIM documentation
Conversion standard documentation

Testing standard documentation

Customization standard documentation


13
CV.010 Conversion Requirements
and Strategy
14
Conversion Scope
Resources, skills and tools required
Conversion approach
Conversion process flows
Data cleanup and testing strategies
Acceptance criteria
Issue Tracking and Versioning procedures
Change and Quality management
Also review CV.020 for Conversion Standards
Sample CV.10
CV.040 Conversion Data Mapping
15
Assumptions specific to a conversion
Data Volumes
Entities to be converted and their pre-
requisites
Map external data to Oracle Applications
tables / APIs
Extract File Layout
Data Cleanup Issues
Sample CV.40
CV.060 Conversion Program Design
16
Processing Rules
Translation Rules
Filter Rules
Foreign Key Rules
Derivation Rules
Default Values
Validation Logic
Conversion Modules Listing
Sample CV.60
CV.070, CV.090 Conversion Test
Plans, Test Results
17
Check list for the tester
Should explain the testing process in detail
All data elements which are important for
business testing should be tested
Unit Test Test if all the data in the extract
has loaded
Object Test Verify if a transaction can be
executed with the loaded data
Sample CV.70
CV.080 Conversion Programs
18
Actual Conversion Code
No document associated with this AIM
process
CV.120 Conversion Programs
Installation
19
Pre-Installation Steps
Installation Steps
Verification
Make sure that Uninstall steps and uninstall
verification steps are provided
Sample CV.120
CV.130 Convert and Verify Data
20
Conversion Execution and Verification
Log
Prepared by the onsite team during go-
live
Sample CV.130
Most common AIM Documents
(Customizations)
21
MD.030, MD.040 Define Design and Build
Standards
MD.050 Application Extensions Functional
Design
MD.070 Application Extensions Technical
Design
MD.110 Create Application Extension Modules
MD.120 Installation Procedures
TE.020, TE.030 Unit Test/Link Test Script
TE.040 System Test Script
TE.070, TE.080 Unit / Link Test Results

MD.030, MD.040 Define Design
and Build Standards
22
MD.030 defines design standards for
Design documents
Forms
Reports
Database Design
Naming
MD.040 defines coding standards for
File Headers
Forms
Reports
SQL
PL/SQL
Installation Routines

Sample MD.30
Sample MD.40
MD.050 Application Extensions
Functional Design
23
A good MD.050 document should define
Assumptions
Functional flow
Features
Illustrate all the Business Scenarios
List User Procedures
Functional Setups required for implementing the
extension


Sample MD.50
MD.070 Application Extensions
Technical Design
24
Form Logic
Navigation, Block Relationships, Table Usage, Field
Summary
Program Logic
Arguments, Outputs, Pseudo Code, Data Sources, Validation
Logic, SQL statements, Performance considerations
Integration Issues
Database Design
Table changes, DFFs, ValueSets, new database objects
Installation Requirements
Design, Coding and Testing requirements




Sample MD.70
MD.110 Create Application
Extension Modules
25
Actual Application Extension Code
No document associated with this AIM
process




MD.120 Installation Procedures
26
Pre-Installation Steps
Installation Steps
Verification
Make sure that Uninstall steps and uninstall
verification steps are provided




Sample MD.120
TE.020, TE.030 Unit / Link Test Script
27
Checklist of items to be checked in the
deliverable
Detailed instructions on how to test the object
Defect Log




Sample TE.20
TE.040 System Test Script
28
Defines the difference scenarios (flows)
to be tested
Defines Navigation Path, Actions, Data
Required and Expected Results





Sample TE.40
TE.070, TE.080 Unit / Link Test
Results
29
Document test plans with test results /
observations
Make sure the observations are detailed





Sample TE.70
Ensuring Delivery Quality
(Its your responsibility !! Not the SQAs !!)
30
Check if version numbers have been updated when a
document is modified
Author, Creation Date, Last Updated, Document Reference
and Version are filled in correctly
Verify document versions are updated with each update
Maintain Change History
Verify Index page
Maintain Open / Closed Issues at the end of the document
Verify if the document can support itself
Peer Review Documents
Track Changes, if possible
Spill Cheek (Spell Check)
AIM Processes
31