Sie sind auf Seite 1von 8

Oracle Implementation

Key Differences between AIM and OUM

If you already used AIM's methodology in your projects you will not find a very big difference, majority
of task and deliverable remain same, but they reclassified under different Process. Lets take a quick
look, if you take first on Phases then AIM was based out of 6 phases whereas OUM only 5.
When you compare the process, 12 Processes was mentioned in AIM, whereas 14 process is
documented in OUM (Implement Focus) as per list and figure below.
OUM is prepared in such a way to speak universal language in all their approach towards Phases,
Process and Templates. Now you can have one methodology to implement any kind of software
product, those can be within the umbrella of oracle or even out of that. Following OUM will be more
than sufficient to plan and process with a project.
Phase Difference:
AIM & OUM Phases:

AIM Process:

Project Management


Business Process architecture


Business Requirement Definition


Business Requirement Mapping


Application & Technical architecture


Module Design & Build


Data Conversion




Business System Testing


Performance Testing


Adoption & Learning


Production migration.

OUM Process:

Business Requirements


Requirements Analysis










Performance Management


Technical Architecture


Data Acquisition and Conversion




Organizational Change Management






Operations and Support

Even though there are more than 200 deliverable available with OUM, there are certain deliverable that
are most required to progress through the project, some of them are :

Different phases and processes of AIM

Phases :


Operation Analysis
Solution Design
Transition, And

Processes :


Project Management
Business Process Mapping
Application and Technical Architecture
Module Design and Build
Data Conversion
Business System Testing
performance Testing
Adoption and Learning
Production Migration

Standard templates are different depending upon the independent Phase and Process again depending upon the
business requirement. (RD 20, RD 50, MD50,MD60,MD70,TE40,BP80,BR100,BR110 etc..)

Oracle Unified Method (OUM)

Oracle is evolving the Oracle Unified Method (OUM) to achieve the vision of supporting the
entire Enterprise IT Lifecycle, including support for the successful implementation of every
Oracle product. OUM replaces the Legacy Methods, such as AIM Advantage, AIM for
Business Flows, EMM Advantage, PeopleSoft's Compass, and Siebel's Results
Roadmap. Oracle PartnerNetwork (OPN) Diamond, Platinum, and Gold Partners are
encouraged to transition to OUM.
OUM provides an implementation approach that is rapid, broadly adaptive, and businessfocused. OUM includes a comprehensive project and program management framework and
materials to support Oracle's growing focus on enterprise-level IT strategy, architecture,
and governance.
OUM includes three Focus Areas Manage, Envision, and Implement. OUM's Manage focus
area provides a framework in which all types of projects can be planned, estimated,
controlled, and completed in a consistent manner. OUMs Envision focus area deals with
development and maintenance of enterprise level IT strategy, architecture, and governance.
Envision also assists in the transition from enterprise-level planning and strategy

activities to the identification and initiation of specific projects. The Implement focus area
provides a framework to develop and implement Oracle-based business solutions with
precise development and rapid deployment.
The diagram below shows how the Envision, Manage, and Implement focus areas fit
together to form OUM:

OUM Approach
OUM is built on five main principles derived from the Unified Process, the Dynamic Systems Development
Method (DSDM), and Oracle's existing methods. Those are:

Iterative and Incremental

Business Process and Use Case-Driven


Flexible and Scalable


Why Use OUM?

More Focused Effort

Built-In Flexibility

Saves Time

Higher Quality

More Cost Effective

Reduce Project Risk

Work Products

Oracle Application Implementation Method (AIM)

Dear All,
I would like to share the Implementation Phase in a Oracle implementation project as I get lot of queries
regarding the Phases of Implementation as per Oracle AIM. 1.Definition 2.Operation Analysis 3.Solution
Design 4.Build 5.Transition 6.Production Process Overviews - Tasks & Deliverable
[BP] Business Process Architecture
[RD] Business Requirements Definition
[BR] Business Requirements Mapping
[TA] Application and Technical Architecture
[MD] Module Design and Build
[CV] Data Conversion
[DO] Documentation
[TE] Business System Testing
[PT] Performance Testing
[AP] Adoption and Learning
[PM] Production Migration
There are several deliverable from Oracle to deliver at the time of Implementation, But to provide all those
documents is not required for Sensible Project.
To my understanding required documents needed to be delivered are
RD - 20 -Requirement Gathering document
BP - 80 or 90 - Future Business Mapping Document
MD - 50 - Functional Specification for Application Customization.
MD - 70 - Technical Specification for Customization.
CV-40-CV-60 - Data Collection Template
UAT - Training Scripts TA - Training Documents
BR - 100 Application Setup Documents
Its better if you have the AIM document generator with you. So that you can have all the document
Templates handy. If I have my own server , I would post the AIM Document generator software too.

Organization Setup
Organization Setup Steps Follow the below steps in the order listed. These are the MINIMUM steps
necessary to successfully define an Organization for the Oracle Inventory module. Further information on
these steps and other optional steps can be found in the Oracle Manufacturing Implementation Manual
under Inventory Setup.
1. Define your set of books (GL function)
2. Define your Key Flexfields in the following order.

a. Navigate to Setup /Flexfields / Key. b. Setup the System Items, Item Categories, Item Catalog Group,
Stock Locators, Account Alias and Sales Order flexfields.
3. Define locations (used for a variety of functions including receiving and default delivery locations).
Note: If you populate the organization field of this form it will only show on the LOV for that organization.
4. Define a workday calendar, also called the manufacturing calendar. Eachorganization references this
calendar for planning and scheduling activities. Optionally; define the calendar exceptions sets. Once this
is completed, click on 'Special' and Build the calendar. It is suggested that the calendar start on the first
day of the work week. For example, if the primary work schedule consists of working Monday through
Friday with Saturday and Sunday off, then make the start date on the calendar coincide with a Monday
date and end with a Sunday date. Note: A calendar must have at least 1 shift and 1 workday pattern
defined. Use the Dates button to review the calendar for accuracy before building it.
5. Define organizations. Assign and enable the appropriate Organization classifications to each
organization defined (based on the desired structure). Note: Must have at least 1 INV and 1 GRE/Legal
entity Organization. The Business Group classification should not be used unless multi-org functionality
will be used.
6. Complete the minimum required 'other' information for each classification selected.
a. GRE/Legal entity: must define an employer identification number and Set of Books.
b. Operating Unit: must define a legal entity. Operating Units are optional.
c. Inventory Org:
i)Accounting information: Set of Books (SOB), Legal Entity,Operating unit (dependant).
ii) Inventory information: Org code, Item Master Org, and calendar, costing Org and method, and Account
information (this is located in the costing, inter-org, and other accounts zones), other settings are optional
based on the features the customer intends to use.
iii) The Receiving and Customer/Supplier information are optional.
7. Define the Unit of Measure classes. Then define the Units of Measure. Thendefine the Unit of Measure
conversions for the application. Note: Each class can only have one (l) base unit of measure. Base units
of measure should generally be the smallest unit of measure in the class. Units of measure should have a
logical connection to the class they are assigned. When disabling Units of Measure, disable the
conversions first, then the Unit of Measure. I it is a base unit, the class should be disabled also. Caution,
once an item has been defined in the Item Master, the primary unit of measure for that item cannot be
8. Define subinventories that represent the physical or logical locations for items within an org.anization.
Must complete name and description. All otherinformation is optional based on what features of the
application will be used. At least one subinventory per Organization must be defined.
9. The remaining Organization setup sections are optional, depending on what features and modules will
be utilized. a. Define locators that represent storage structures (for example, aisles or bins) within
subinventories. b. Define Shipping Networks and Methods to facilitate Inter-Org Transfers. c. Define
Freight Carriers. d. Define Organization Access. If any access information for an organization is defined in
this screen, access MUST be defined for ALL responsibilities that require access to that organization.
Failure to do this will cause the unlisted responsibilities to no longer function in that organization! e.

Define Inter-Company Relations for inter-company functionality. Once these steps are completed the
Organization is setup and usable. The user should then proceed with setting up the rest of the inventory
system. See the Oracle Manufacturing Implementation guide, or the Oracle Inventory User's guide for
instructions on setting up Items, Categories, Costs, Transaction Defaults, and other features of the Oracle
Inventory system. It is always advisable to consult Oracle Worldwide Support Services or Oracle Metalink
for the current critical patch list for the Inventory Module prior to implementing a new Inventory system.

Profile Options
HR:User Type = HR User This allows the Inventory responsibility to complete the organization setup.
HR:Business Group= {the users Business Group name}(Setup Business Group by default)This points the
responsibility to the appropriate Business Group. When multipleBusiness Groups are defined, each
responsibility must be associated with one and ONLY one Business Group. A responsibility cannot see
organization data from morethan one Business Group.
MO:Operating Unit= {the users Operating Unit name}Used primarily in a multi-org environment. This
points the responsibility to the appropriate Operating unit. Set the site level to the default operating unit. If
there is more than one Operating unit defined, this profile must be set at the responsibility level for each