AIM methodology for

Oracle eBusiness Suite

Author: Abhijit Ray

1
Overview of AIM
(Applications Implementation Method)
• Where Used - New implementations & re-implementations of Oracle’s 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/FastForwardRPM/FastForward Flows
– Projects generally Fixed Time/Fixed Scope/Fixed Cost (RPM’s only)
• Related Advantage Offerings - AIM Advantage

2
Overview of AIM
(Applications Implementation Method)
contd.
• Where Used - New implementations & re-implementations
of Oracle’s 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 don’t miss something important
• so we don’t dwell on something that is unimportant
• so we don’t 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 Tasks
in output of a single deliverable
or revision of an existing deliverable. Definition Operations Solution Build Transition Production
Analysis Design

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
Method Concepts: Phase
Phases are a grouping of tasks that Phases
lead to a major project deliverable
or milestone
Definition Operations Solution Build Transition Production
Analysis Design

• Phases cut vertically through

project activities
• Are natural points to establish
milestones for progress checkpoint

7
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

Definition Operations Solution Build Transition Production

Analysis Design

Processes

8
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
Definition Elaboration Build Transition Production
Determine Exception Determine Exception
Dispositions Dispositions Prepare
Project Production
Planning Update Flows Update Flows Environment

Update Procedures Update Procedures

Conduct Update Setups Update Setups

CRP 1.1 Convert and
(Familiarization) Update Test Script Update Test Script Verify Data

Prepare CRP 2.0 Prepare CRP 3.0

Environment Environment

Conduct Conduct CRP 2.0 Conduct CRP 3.0 Perform

CRP 1.2 Acceptance
(Mapping) Identify Exceptions Identify Exceptions Test

Identify Perform Systems Begin Maintain

Design
Exceptions Integration Production System
Extensions
Test

Conduct Prepare Create and test Propose

Business Custom Custom Future
Architecture Test Scripts Extensions Direction
Workshops

10
Classic Phases

Analysis Build Production

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

11
AIM Business Flow

12
Common AIM documentation
• Conversion standard documentation

• Testing standard documentation

• Customization standard documentation

13
CV.010 – Conversion Requirements
and Strategy
• Conversion Scope
• Resources, skills and tools required
• Conversion approach
• Conversion process flows
Sample CV.10
• Data cleanup and testing strategies
• Acceptance criteria
• Issue Tracking and Versioning procedures
• Change and Quality management
• Also review CV.020 for Conversion Standards

14
CV.040 – Conversion Data Mapping

• 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 Sample CV.40
• Data Cleanup Issues

15
CV.060 – Conversion Program Design

• Processing Rules
• Translation Rules
• Filter Rules
• Foreign Key Rules
• Derivation Rules Sample CV.60
• Default Values
• Validation Logic
• Conversion Modules Listing

16
CV.070, CV.090 – Conversion Test
Plans, Test Results

• 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

17
CV.080 – Conversion Programs

• Actual Conversion Code

• No document associated with this AIM
process

18
CV.120 – Conversion Programs
Installation
• Pre-Installation Steps
• Installation Steps
• Verification
• Make sure that Uninstall steps and uninstall
verification steps are provided

Sample CV.120

19
CV.130 – Convert and Verify Data

• Conversion Execution and Verification

Log
• Prepared by the onsite team during go-
live

Sample CV.130

20
Most common AIM Documents
(Customizations)
• 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
21
MD.030, MD.040 – Define Design
and Build Standards
• MD.030 defines design standards for
– Design documents
– Forms
– Reports
– Database Design
Sample MD.30
– Naming
• MD.040 defines coding standards for
– File Headers
– Forms
– Reports
– SQL Sample MD.40
– PL/SQL
– Installation Routines

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

23
MD.070 – Application Extensions
Technical Design
• 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

24
MD.110 – Create Application
Extension Modules
• Actual Application Extension Code
• No document associated with this AIM
process

25
MD.120 – Installation Procedures

• Pre-Installation Steps
• Installation Steps
• Verification
• Make sure that Uninstall steps and uninstall
verification steps are provided

Sample MD.120

26
TE.020, TE.030 – Unit / Link Test Script

• Checklist of items to be checked in the

deliverable
• Detailed instructions on how to test the object
• Defect Log

Sample TE.20

27
TE.040 – System Test Script

• Defines the difference scenarios (flows)

to be tested
• Defines Navigation Path, Actions, Data
Required and Expected Results

Sample TE.40

28
TE.070, TE.080 – Unit / Link Test
Results
• Document test plans with test results /
observations
• Make sure the observations are detailed

Sample TE.70

29
Ensuring Delivery Quality
(Its your responsibility !! Not the SQAs !!)
 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)

30
AIM Processes

31
Thank you
The author would love to get your comments on

abhijit673 @

32