1
AIM methodology for Oracle eBusiness Suite
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 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 OperationsAnalysis
SolutionDesign
Build ProductionTransition
TasksTasks
Method Concepts: Phase
Phases are a grouping of tasks that lead to a major project deliverable or milestone
• Phases cut vertically throughproject activities
• Are natural points to establish milestones for progress checkpoint
7
Definition OperationsAnalysis
SolutionDesign
Build ProductionTransition
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 OperationsAnalysis
SolutionDesign
Build ProductionTransition
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 ExceptionDispositions
Update Flows
Update Procedures
Update Setups
Update Test Script
Prepare CRP 3.0Environment
Conduct CRP 3.0
Identify Exceptions
Determine ExceptionDispositions
Update Flows
Update Procedures
Update Setups
Update Test Script
Prepare CRP 2.0Environment
Conduct CRP 2.0
Identify Exceptions
Definition Build ProductionTransitionElaboration
Project Planning
ConductCRP 1.1
(Familiarization)
ConductCRP 1.2
(Mapping)
Identify Exceptions
ConductBusiness
Architecture Workshops
DesignExtensions
PrepareCustom
Test Scripts
Create and test Custom
Extensions
PrepareProduction
Environment
Convert and Verify Data
BeginProduction
MaintainSystem
ProposeFuture
Direction
Perform SystemsIntegration
Test
PerformAcceptance
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
Microsoft Word Document
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
Microsoft Word Document
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
Microsoft Word Document
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 Microsoft Word Document
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
Microsoft Word Document
Sample CV.120
CV.130 – Convert and Verify Data
20
• Conversion Execution and Verification Log
• Prepared by the onsite team during go-live
Microsoft Word Document
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
Rich Text Format
Rich Text Format
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
Microsoft Word Document
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
Microsoft Word Document
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
Microsoft Word Document
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
Microsoft Word Document
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
Microsoft Word Document
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
Microsoft Word Document
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