Contributed by Ranu A Typical Software Implementation Cycle!!

Definition Project Planning Elaboration Determine Exception Dispositions Build Determine Exception Dispositions Transition Prepare Production Environment Production Update Flows Update Procedures Update Flows Update Procedures Update Setups Update Test Script Prepare CRP 3.0 Environment Conduct CRP 3.0 Identify Exceptions Conduct CRP 1.1 (Familiarization) Update Setups Update Test Script Prepare CRP 2.0 Environment Convert and Verify Data Conduct CRP 1.2 (Mapping) Conduct CRP 2.0 Identify Exceptions Perform Acceptance Test Identify Exceptions Design Extensions Perform Systems Integration Test Begin Production Maintain System Conduct Business Architecture Workshops Prepare Custom Test Scripts Create and test Custom Extensions Propose Future Direction http://apps2fusion.com

Applications Implementation Method AIM, 'aims' to fit implementation tasks aroun d 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 implemen ted is a good fit for business needs,then define requirements,design system,buil d & 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 output s. A task can belong to only process. AIM has 11 processes: Project Management, Business Process Architecture, Business Requirements Definition, Business Requir ements Mapping, Application and Technical Architecture, Module Design and Build, Data Conversion, Documentation, Business System Testing, Performance Testing, A doption and Learning and Production Migration Examples of AIM tasks : MD.010 MD.050 TE.070 Define Application Extension Strategy Define Application Extensions Functional D esign 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 a nd Verify Data http://apps2fusion.com

CV.010 Conversion Requirements and Strategy

Conversion Scope Resources, skills and tools required Conversion approach Conver sion 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 conve rsion. This document should have been prepared by the onshore team prior to conv ersion. A good strategy document should identify all the conversions that need t o 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 i n which objects will be converted? How many years of data will be converted? Wil l open and closed objects be converted? Data cleanup and testing strategies Iden tify data that needs to be clean up and prepare a strategy for the cleanup eg. C ustomer address data, phone numbers. Testing Strategies To identify how the data will be tested after the conversion is done eg. Record counts, run aging report s to validate invoices etc. Acceptance Criteria Acceptance Criteria need to be c learly defined for each of the conversions. This is basically to set the expecta tions 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 te sted. Issue Tracking and Versioning Procedures Define what tools will be used fo r 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 a nd 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 e tc. Also defines the quality process that will be followed to ensure completenes s 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 c onversion project file and extract naming conventions, delimiters that will be u sed 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 t heir pre-requisites Map external data to Oracle Applications tables / APIs Extra ct 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 vo lumes.Also it lists all the pre-requisite objects that need to be setup or conve rted before this conversion can be performed. Eg. In order to convert AP Invoice s, you need to convert vendors first and setup bank accounts.The next section ma ps the data in the flat file (from the legacy system) into the Oracle applicatio n open interface tables or Oracle Apps APIs. Open Interface tables are tables wh ere 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 t ake 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 v alidation/lookup that needs to be done needs to be identified.The extract file l ayout defines the number of fields the can be found in the flat file from the le gacy system. It also provides information on the length of the field, short desc ription 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 Ora cle Applications. Eg. Before customer address data is loaded into Oracle Apps, n eed 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 Rul es Default Values Validation Logic Conversion Modules Listing CV.060 defines the conversion programs, the tables associated with the conversio n and dependencies.Processing Rules eg. If 2 customers have different start date s 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 the n PAYMENT_HOLD = N,Filter Rules eg. Ignore all the records with a prefix of * Fo reign Key Rules eg. Dervie the value of EXTERNAL_BANK_ACCOUNT_ID in the PO_VENDO RS table from AP_BANK_ACCOUNT_USES_ALL.Derivation Rules eg. The first 3 characte rs of the supplier number are used to derive the payment group .Default Values e g. Invoice currency code will be defaulted to USD,Validation Logic Pseudo code o f the conversion program, including the validations that need to be performed be fore the data gets loaded. This section should also include the output formats i n which error reports will be generated.Conversion Modules Listing Listing of al l the modules that are involved in the conversion (including SQL*Loader files, P L/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 Tes t 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 recor d the results of the conversion tests.A good CV070 should explain the testing pr ocess 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 b e included in the conversion test plan. Eg. For Vendors, test if all the bank ac counts 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 pr ovide the pre-installation steps, installation steps, and the verification steps for the install.Also it is very important that uninstall information be provide d to enable the customer to uninstall the conversion programs. Also provide veri fication 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 golive 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 du ring production conversion. http://apps2fusion.com

Most common AIM Documents (Customizations)

MD.030, MD.040 Define Design and Build Standards MD.050 Application Extensions F unctional Design MD.070 Application Extensions Technical Design MD.110 Create Ap plication Extension Modules MD.120 Installation Procedures TE.020, TE.030 Unit T est/Link Test Script TE.040 System Test Script TE.070, TE.080 Unit / Link Test R esults 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 cust omization project. MD.030 defines the design standards for Design documents List s the contents of the design document,Forms during the customization eg. Layouts , procedure calls etc Forms standards that will be adopted Reports Report standards that list the conventions used for boilerplate text, re port titles, cover page, page headers and footers, column ordering etc.Database design Object naming standards,Naming Standards for customization files MD.040 d efines the coding standards for the customization relating to File Headers Stand ard headers that will be included with every source file,Forms eg. Forms 6i codi ng standards Reports eg. Headers, footers, titles that will be used in reports,SQL uppercase, PL/SQL eg. All cursors will be named starting with a c_ Installation Routines eg. All SQL reserved words will be in Standards followed for installation routines to install seed data, DB objects et c. 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 functio nal design, list the detailed functional flow that is related to the customizati on, list the important features of the customization and the reasons for the cus tomization . In addition, it will be good to list an illustration of the busines s scenarios that might be tested after the customization is complete, list all t he user procedures that are involved in testing the customization. Most importan tly, it should identify the functional setups that should be performed as a prerequisite to implementing this customization. http://apps2fusion.com

MD.050 Application Extensions Functional Design

A good MD.050 document should define Assumptions Functional flow Features Il lustrate all the Business Scenarios List User Procedures Functional Setups req uired 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 stat ements, Performance considerations Integration Issues Database Design Table cha nges, DFFs, ValueSets, new database objects Installation Requirements Design, Co ding and Testing requirements http://apps2fusion.com

MD70 Should be a detailed document listing the technical design components of th e customization. Should be at such a detailed level that any coder should be abl e 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 relatio nships between the blocks, list all the tables that will be modified/validated b y the form and give a detailed description of all the fields that will be displa yed 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 w hich data will be selected, validation to be performed, SQL statements that will be used in the report and also performance considerations when running the repo rt.MD070 should also list out the integration issues involved in the customizati on, if any. Eg. If doing this customization would affect any standard features o r 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 sh ould list out all the pre-requisites to install and run the customization.The De sign, 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 th is 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 preinstallation steps, installation steps and the verification steps for th e install. Also it is very important that uninstall information be provided to e nable the customer to uninstall the customizations. Also provide verification st eps 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 na vigation and the test data to be used.Also provide a section for a defect log to be used during the peerreview process to capture defects. http://apps2fusion.com

TE.040 System Test Script

Defines the difference scenarios (flows) to be tested Defines Navigation Path, A ctions, Data Required and Expected Results System test scripts lists the different business scenarios to be tested after th e customization is complete.Should define the navigation path, actions to be per formed, data required to execute the test.It also should list the results that a re 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.Mak e 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 inter action with the tester. http://apps2fusion.com