You are on page 1of 22

Contributed by Ranu

A Typical Software Implementation Cycle!!

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

http://apps2fusion.com
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

http://apps2fusion.com
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

http://apps2fusion.com
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

http://apps2fusion.com
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/SQL
Conversion 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.
http://apps2fusion.com
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.

http://apps2fusion.com
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).

http://apps2fusion.com
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.

http://apps2fusion.com
CV.080 – Conversion Programs

 Actual Conversion Code


 No document associated with this AIM process

http://apps2fusion.com
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.

http://apps2fusion.com
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.

http://apps2fusion.com
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

http://apps2fusion.com
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

http://apps2fusion.com
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.

http://apps2fusion.com
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

http://apps2fusion.com
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

http://apps2fusion.com
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.

http://apps2fusion.com
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.

http://apps2fusion.com
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.

http://apps2fusion.com
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.

http://apps2fusion.com
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.

http://apps2fusion.com
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.

http://apps2fusion.com

You might also like