AIM Overview

http://apps2fusion.com

Definition Build ProductionTransitionElaboration

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

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

A Typical Software Implementation Cycle!!

Contributed by Ranu


Applications Implementation Method AIM, 'aims' to fit implementation tasks around processes to provide a structural approach for implementing oracle applications.Though it's oracle methodology but structurally it's not very different from any other Project management Method ie you demonstrate if the module to be implemented is a good fit for business needs,then define requirements,design system,build & test system,gain user acceptance,begin production & finally support/enhance the application using Structured waterfall approach.

Each AIM process represents a set of objectives, resource skill requirements, inputs and deliverable outputs. A task can belong to only process. AIM has 11 processes: Project Management, Business Process Architecture, Business Requirements Definition, Business Requirements Mapping, Application and Technical Architecture, Module Design and Build, Data Conversion, Documentation, Business System Testing, Performance Testing, Adoption and Learning and Production Migration

Examples of AIM tasks : MD.010 – Define Application Extension Strategy

MD.050 – Define Application Extensions Functional Design

TE.070 – Perform Unit Test

Let's take a deeper dive into the ‘Oracle Implementation Common Sense' called AIM


Most common AIM Documents (Conversions)

CV.010 – Data Conversion Requirements and Strategy CV.040 – Conversion Data Mapping CV.060 – Conversion Program Design CV.070, CV.090 – Conversion Test Plans, Test Results CV.080 – Conversion Programs CV.120 – Conversion Programs Installation CV.130 – Convert and Verify Data


CV.010 – Conversion Requirements and Strategy

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


CV.010 is one of the important documents to review before the start of the conversion.This document should have been prepared by the onshore team prior to conversion. A good strategy document should identify all the conversions that need to be performed and the order in which they should be done.Conversion Scope – what is included and what is not.Resources, skills and tools – What are the resource requirements for the conversion eg. 5 resources for 5 weeks, Skills required eg. Technical resource with AP knowledge, tools required eg. SQL*Loader, Dataload, PL/SQLConversion Approach – Answers the following questions - What is the order in which objects will be converted? How many years of data will be converted? Will open and closed objects be converted?Data cleanup and testing strategies – Identify data that needs to be clean up and prepare a strategy for the cleanup eg. Customer address data, phone numbers. Testing Strategies – To identify how the data will be tested after the conversion is done eg. Record counts, run aging reports to validate invoices etc.Acceptance Criteria – Acceptance Criteria need to be clearly defined for each of the conversions. This is basically to set the expectations on what would signal the completion of a successful conversion. Eg. 80% of the legacy data will be converted and the flows relating to the data will be tested.Issue Tracking and Versioning Procedures – Define what tools will be used for issue tracking and versioning as a part of this conversion process.Change and Quality Management – Define how changes to the conversion scope will be handled and how they will be accommodated. Eg. There could be scope changes due to delays in the delivery of the extract from the customer, delays in application setup etc.Also defines the quality process that will be followed to ensure completeness and appropriateness of deliverables.Contents of a CV.020 are usually included in the the CV.010 document. It defines the standards that will be used in the conversion project – file and extract naming conventions, delimiters that will be used during extract, date formats etc.


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 Data Cleanup Issues This is one version of this document for every object that needs to be converted.This contains

assumptions specific to a conversion and their associated data volumes.Also it lists all the pre-requisite objects that need to be setup or converted before this conversion can be performed. Eg. In order to convert AP Invoices, you need to convert vendors first and setup bank accounts.The next section maps the data in the flat file (from the legacy system) into the Oracle application open interface tables or Oracle Apps APIs. Open Interface tables are tables where you load the data, and then run a separate process which validates the data and uploads it into the standard apps tables. APIs are PL/SQL procedures which take the data in the form of input parameters. These procedures then validate the data and upload it into Oracle Apps tables. Also during the mapping, any data validation/lookup that needs to be done needs to be identified.The extract file layout defines the number of fields the can be found in the flat file from the legacy system. It also provides information on the length of the field, short description of the field and the data type.

Data Cleanup issues will include any pre-processing that the extract file has to go through before being loaded into Oracle Applications. Eg. Before customer address data is loaded into Oracle Apps, need to clean up the zip codes and phone numbers.


CV.060 – Conversion Program Design

Processing Rules Translation Rules Filter Rules Foreign Key Rules Derivation Rules Default Values Validation Logic Conversion Modules Listing

CV.060 defines the conversion programs, the tables associated with the conversion and dependencies.Processing Rules – eg. If 2 customers have different start dates in the extract, use the one with the most current start date Translation Rules – eg. Translate value of 0 in column 5 to PAYMENT_HOLD = Y, if the value is 1 then PAYMENT_HOLD = N,Filter Rules – eg. Ignore all the records with a prefix of *

Foreign Key Rules – eg. Dervie the value of EXTERNAL_BANK_ACCOUNT_ID in the PO_VENDORS table from AP_BANK_ACCOUNT_USES_ALL.Derivation Rules – eg. The first 3 characters of the supplier number are used to derive the payment group .Default Values – eg. Invoice currency code will be defaulted to USD,Validation Logic – Pseudo code of the conversion program, including the validations that need to be performed before the data gets loaded. This section should also include the output formats in which error reports will be generated.Conversion Modules Listing – Listing of all the modules that are involved in the conversion (including SQL*Loader files, PL/SQL procedures, Shell Scripts etc).


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

CV.070, CV.090 are basically a conversion check list for the tester and to record the results of the conversion tests.A good CV070 should explain the testing process in detail, along with menu options to choose, data to enter and reports to run. All data elements that are important for the business to function should be included in the conversion test plan. Eg. For Vendors, test if all the bank accounts and addresses have been populated .Unit Test – Test to see if all the data in the flat file that was to be loaded was loaded into the base tables. Could be a cursory glance of the base tables to verify the information.Object Test – Test to verify if using the data loaded, a transaction can be executed.


CV.080 – Conversion Programs

Actual Conversion Code No document associated with this AIM process


CV.120 – Conversion Programs Installation

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

provided

CV.120 – Installation programs to install the conversion programs.Make sure you provide the pre-installation steps, installation steps, and the verification steps for the install.Also it is very important that uninstall information be provided to enable the customer to uninstall the conversion programs. Also provide verification steps to verify that the program has been uninstalled successfully.


CV.130 – Convert and Verify Data

Conversion Execution and Verification Log Prepared by the onsite team during go-live

CV.130 is a log of the conversion execution and verification. Keeps a log of the time the conversion was executed and the subsequent verification that was done after the conversion.This document is usually put together by the onsite team during production conversion.


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


MD.030, MD.040 – Define Design and Build Standards

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


MD.030 and MD.040 are important documents to review before the start of the customization project.

MD.030 defines the design standards for

Design documents – Lists the contents of the design document,Forms – Forms standards that will be adopted during the customization eg. Layouts, procedure calls etc

Reports – Report standards that list the conventions used for boilerplate text, report titles, cover page, page headers and footers, column ordering etc.Database design – Object naming standards,Naming – Standards for customization files

MD.040 defines the coding standards for the customization relating to

File Headers – Standard headers that will be included with every source file,Forms – eg. Forms 6i coding standards

Reports – eg. Headers, footers, titles that will be used in reports,SQL – eg. All SQL reserved words will be in uppercase,PL/SQL – eg. All cursors will be named starting with a c_

Installation Routines – Standards followed for installation routines to install seed data, DB objects etc.

MD.050 is by far the most important document to start the customization effort.

A good MD050 document should list all the assumptions that went into the functional design, list the detailed functional flow that is related to the customization, list the important features of the customization and the reasons for the customization .

In addition, it will be good to list an illustration of the business scenarios that might be tested after the customization is complete, list all the user procedures that are involved in testing the customization.

Most importantly, it should identify the functional setups that should be performed as a pre-requisite to implementing this customization.


MD.050 – Application Extensions Functional Design

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


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


MD70 Should be a detailed document listing the technical design components of the customization. Should be at such a detailed level that any coder should be able to pick up the document and start coding.

If the customization is a form, the form logic section should include navigation within the form, detail the relationships between the blocks, list all the tables that will be modified/validated by the form and give a detailed description of all the fields that will be displayed in the form.

If the customization is a report, include the calling arguments for the report, output formats, pseudo code for the report logic, tables from which data will be selected, validation to be performed, SQL statements that will be used in the report and also performance considerations when running the report.MD070 should also list out the integration issues involved in the customization, if any. Eg. If doing this customization would affect any standard features or other customizations.Database design section should include the changes to any of the standard tables, DFFs that need to be defined, valuesets that need to be created and the new database objects to be created.Installation requirements should list out all the pre-requisites to install and run the customization.The Design, Coding and Testing requirements section should list all the considerations that should be taken into account during the design, coding and testing phases.


MD.110 – Create Application Extension Modules

Actual Application Extension Code No document associated with this AIM process

MD.110 is the actual customization code, there is no document associated with this AIM process.


MD.120 – Installation Procedures

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

provided

MD.120 – Installation programs to install the customizations.Make sure you provide the pre-installation steps, installation steps and the verification steps for the install.

Also it is very important that uninstall information be provided to enable the customer to uninstall the customizations. Also provide verification steps to verify that the program has been uninstalled successfully.


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

TE.020, TE.030 provide a checklist of items to be checked in the deliverable. It should include detailed instructions on how to test an object, including the navigation and the test data to be used.Also provide a section for a defect log to be used during the peer-review process to capture defects.


TE.040 – System Test Script

Defines the difference scenarios (flows) to be tested Defines Navigation Path, Actions, Data Required and Expected Results System test scripts lists the different business scenarios to be tested after the

customization is complete.Should define the navigation path, actions to be performed, data required to execute the test.It also should list the results that are expected because of the actions.


TE.070, TE.080 – Unit / Link Test Results

Document test plans with test results / observations Make sure the observations are detailed

Test Results are a log of all the unit test that are performed on the object.Make sure that the observations that are logged in this document are as detailed as possible so that the coder can go back and correct the error with minimal interaction with the tester.

AIM Overview

Documents

Transcript of AIM Overview