E-Business Suite Implementation Assessment :

Implementing the Oracle Applications

1 Software Implementation Methods
2 Understanding What Affects the Degree of Effort and Cost
3 Analyzing the Project
4 Converting Analysis into Solutions
5 Enabling the System

Software Implementation Methods:

Possible methodologies for implementing New Modules on Existing EBS suite

The following three methodologies could be considered for new implementation:1)
Oracle Application Implementation Method (AIM)
Oracle Unified Method(OUM)3)
Oracle Business Accelerators (OBA)
All the above three methods are proven and has been successfully adopted by enterprises, according tospecific needs and
demands. Each of the above methods has its advantages and challenges.Implementers take into account the following factors
before recommending a suitable methodology:
Size of the enterprise and its business
Existing application setup and application spread
Is it an upgrade, add on module, re-engineering effort
Time to implement and availability of ERP project teams with the client
Documentation effort
Cost and scalability
Interface requirementsGiven below or features of all the three methodologies, and recommendation:
1)
Oracle Application Implementation Method (AIM)
What Oracle says:
AIM brings a proven process to the table for implementing Oracle E-Business SuiteBusiness Solutions with
Highest degree of quality
Quick return on investment
Short time to benefit
ORACLE AIM is an effective toolkit which provides,
Deliverable Templates
Pre-seeded Content and Sample Data
Customizable Workplans
Project Management Support
Detailed Description
Online Context Sensitive Documentation
All delivered in an easy to use, web-bases interface.ORACLE AIM provides,templatesfor all the tasks that require them-ORACLE
AIM is a methodology showingwhat tasksrequired, whatorderthey should be completed in,andwhat resourcesare requiredThe
methodology ispurpose built for Oracle Applicationsand the detailed deliverables produced aredesigned with the Oracle
Application products in mind.

Understanding What Affects the Degree of Effort and Cost:

Using the Number and Type of Applications to Estimate Costs
Understanding the Relative Complexity of Each Application
Business Systems Complexity
Minimizing Customizations and Extensions to Lower Costs
Business Processes
Other Projects in Process
Capability of the Project Team
Packaged software implementation is expensive. However, progress is being made to lower the costs. In
the past seven years, consulting firms and Oracle have developed many techniques to control costs,
project scope, and complexity. The cost, scope, and risk of an ERP project are directly proportional to the
following items:

The degree of business complexity

The number of applications to be implemented
The amount of extensions to the package software
The nature of the business processes

There are trade-offs that you must make when implementing packaged ERP software. You can implement
your software rapidly, cheaply, or fully featured. Usually, you cannot capture all three benefits at the
same time. Because they do less, rapid implementations are often less expensive than full-featured,
customized implementations. If the rapid implementation must also be full-featured and customized, the
amount of implementation work is the same as the slower-paced, full-featured implementation. There
will be a large, coordinated, and expensive project team to accomplish both projects.
The project method you pick affects the costs and the skills required on the project. Oracle uses several
methods including the following:
Oracle Application Implementation Method (AIM)
Oracle Unified Method(OUM)3)
Oracle Business Accelerators (OBA)

Other consulting firms have a wide assortment of work plans, templates, methods, and techniques to
reduce cost and minimize the risks of these projects.
Tip
Remember, Oracle provides services to sell software. If you choose a low-cost implementation method,
make sure the technique will actually work in your company. For example, the preconfigured module
method might produce an inexpensive implementation, but if you require several interfaces to nonOracle systems, you might not meet your business requirements.

To understand cost drivers, BOSS Corporation analyzed a complex project to determine what factors
controlled the cost. The work plan for this project was over 300 consulting workdays and 400 client
workdays. The method chosen for the project was similar to Oracle AIM. The people at BOSS looked at
each task in the work plan, the cost factors controlling the task, and the number of planned days to
complete the task. Then, they weighted the results to determine which factors contributed the most to
implemented cost. Because multiple factors might contribute to the cost of a single task, results add to
more than 100%. Table 4.1 shows factors affecting the total cost.
Table 4.1. Factors Affecting Total Cost

Factor

Impact

Applications to be implemented

45%

Business complexity

40%

Customizations, interfaces, data conversion

31%

Business processes and reengineering

13%

Analyzing the Project:

Business Process Analysis
Determining Your Reporting Needs
Infrastructure Analysis
Customizations
Legacy Data and Conversion
Understanding Typical Tasks, Deliverables, and Milestones of the Analysis Phase

Business Process Analysis

A study of your business processes has four main activities:

Understanding the current business processes

Defining the business requirements for the new software
Assessing the fit and identify gaps
Developing a vision of future business processes

Determining Your Reporting Needs

The analysis phase of the project should determine the information flow and reporting requirements for
the new software. Reporting is a continuing problem with Oracle Applications implementations because

these information requirements can easily change the scope of the project. Without the familiar reports
and system outputs of the legacy system, end users and sponsors feel a sense of loss, and change in the
organization becomes difficult. If users don't see their familiar reports, you might have a gap list with
many items on it.
Infrastructure Analysis

Most implementation projects acquire x and install the server hardware and the Oracle applications early
in the project. Often, in simple organizations, you can easily specify and acquire the infrastructure your
systems will need from the information you received when you were evaluating the purchase of the
applications. However, you should still consider studying the infrastructure. The infrastructure analysis
helps determine the system requirements.
Customizations

The analysis phase of the project is concerned with identifying customizations to the Applications. After
you understand the business requirements and have a gap list, you can begin to address the
customizations you will require. Perform a high-level analysis of each customization before you finalize
the project scope and work plan. If you decide to extend the Oracle applications, you will want to add and
track tasks for design, build, unit test, integration test, CRPs, and document to the project work plan.
Because customizations change the scope, cost, and schedule for the implementation, your steering
committee and project sponsor should be aware of all customizations.
Legacy Data and Conversion

During the analysis phase of the project, you should understand and develop a strategy for each major
data entity you are going to load into the new applications. Also, consider the shared entities, such as
customers and vendors, from all perspectives. For example, the purchasing and payables departments
often have a completely different view of vendor data, but this data is shared by both departments when
using Oracle Applications. Understand both departments' vendor data requirements prior to data
conversion.
First, determine what to convert from the legacy system. Look at the table of contents of the reference
manuals and find nouns that name objects in your business. These are the entities you will want to
estimate. For example, in the table of contents for the Receivables user's guide, you will find transactions
(invoices and memos), customers, receipts, and so forth. The following is a list of major business entities
you might want to convert during your applications implementation project:

GL Balances
GL Transactions
Customers
Vendors
Items
Inventory Balances
AP Open Items
AR Open Items
Open Purchase Orders
Open Purchase Order Requisitions
Open Sales Orders
WIP Balances
Bills of Material

Routings
AP History
AR History
Inventory Transaction History
Employees
Year-to-Date Payroll Balances

Understanding Typical Tasks, Deliverables, and Milestones of the Analysis Phase

You should prepare several documents during the analysis phase of the project. These tasks and
deliverables will provide a foundation for the rest of the project implementation activity. These project
deliverables document the current processes and requirements, the new processes, the system
architecture, the degree of fit, the data conversion strategy, and the system interface strategy. You will
use these documents to support your configuration choices, conference room pilots, test plans,
customization designs, and end-user training.

Converting Analysis into Solutions:

Designing Customizations
The Solution/Conceptual Design Document
Estimating Customizations
Initial Project Documentation
Preparing for System Test
Performance Testing Preparation
Designing the Support Organization
Designing Customizations

Designing customizations is one of the main objectives of this phase. Your team's focus will be to produce
design documents for Oracle Application customizations that meet the functional requirements of the
businessfunctionally, technically, and financially. You will design customizations to fill the gaps between
the Oracle Applications, legacy systems, third-party applications, and your organization's business
requirements. The overall customization approach is defined in the customization strategy prepared
earlier in the project. Each design specification must be created in a way so that it promotes and supports
the future maintenance and support of the system. These design documents must also take into
consideration the application setups and test plans for each Oracle Application module. You also need to
consider your organization's security, database, and network requirements because these create
additional constraints on the design of your customizations.
Customizations to the Oracle Applications can be categorized in three ways:

Extensions

Modifications
Interfaces

Some project activities that can be considered customizations are the following:

Creating a new report or form

Renaming or modifying a copy of a standard Oracle report or form
Creating a one-time interface to convert legacy data
Creating a recurring inbound or outbound interface to a non-Oracle application
Creating an Oracle Application Alert
Renaming or modifying a copy of an Oracle Workflow
Creating a database trigger, package, or program to perform or automate some business function

The Solution/Conceptual Design Document

This design document summarizes your business requirements that are not addressed by a specific
application module and recommends one or more solution(s) for each requirement. The document is
created as one of the last tasks in the Analyzing the Project phase of the implementation but is reviewed
in detail prior to beginning the next step of design tasks assigned to your team. It serves as a confirmation
that your project team understands your business requirements and documents the solution and
assumptions that are the foundation for the level of effort estimates.
The High-Level/Functional Design Document

This design document is developed in layman terms and is normally written by the functional project
team members. It is used as a bridging document between the end users' business requirements and the
technical team design documents.
The Low-Level/Technical Design Document

The technical design documents are complex in nature and are not meant to be reviewed with your end
users. These documents are very technical and provide a level of detail required only by the technical
team. This document defines the components required to support and implement the customizations. It
serves as the bridge between the functional design document discussed earlier and the actual code that
will be required to support the business requirement. Both documents should be considered a complete
detailed design.
Estimating Customizations

Providing cost and time estimates for customizations is always difficult. This section can be used to help
devise a way to estimate your project customizations or other uncertain activities.
When providing estimates, consider many different factors that may affect your time to completion.
Understand the business objectives behind what you are estimating.

Initial Project Documentation

During this phase of the project, you create the initial designs for the custom user guide and reference
manual, as well as the technical manual and system guide. The need and time to develop these documents
is often underestimated, which leads to poor or no documentation being developed. The following
sections discuss the need for training and transitioning your organization to the production environment.

Preparing for System Test

At this stage in the project, you need to be developing a test strategy that encompasses all testing tasks.
This document should include an overview of your testing approach, the test scripts to be created, a
testing plan that includes resources and responsibilities, and a step-by-step review of the issue resolution
process. The objective of the testing strategy is to provide overall direction and guidelines for testing all
aspects of the system. This includes developing an overall approach to the testing effort, organizing and
scheduling testing resources and the execution of test scripts, installing and configuring the test
environment and tools as needed, and establishing the issues management process.
You should develop the testing strategy based on the characteristics of the customizations. You need to
take into consideration how many custom modules are being developed, how much data is being
converted, any system performance concerns, the number of interfaces, the scope and types of testing to
be performed, and the level of importance of the system to the business.

Performance Testing Preparation

When designing the performance testing approach, you need a test database and a method for populating
the instance. You need to identify special loading programs and testing transactions to load and test the
application. Often, organizations use a simplistic approach to stressing the applications using minimal
data. As part of performance testing, be sure to use valid volumes of data when stress testing the
applications, the database, and the technical architecture. Involve your users in this effort; they can add
tremendous value and credibility to your testing. You also should develop performance monitoring
scripts or take advantage of tools offered by Oracle such as Enterprise Manager. Establish a baseline for
acceptable performance and measure how well the system does against that baseline after the systems go
live.

Enabling the System

Customizations
Managing the Phase
Some Alternatives to Customizations
The next phase of your implementation project is to prepare the system and your company for a change
to the new software applications. The primary objective of this phase is to "code and test" customizations,
conversions of data, interfaces, and modifications that have been identified and determined to be in scope
for your project. If there are no customizations, data conversion, interfaces, or modifications, this phase is

still important because of the business system test, or the conference room pilot (CRP). The CRP validates
solutions and simulates your production environment and configuration. Other key tasks during this
phase are the development and execution of performance test scripts, unit tests, and integration tests.
Each of these tasks is vital to the success of this phase as well as the overall project.
This phase may overlap the Converting Analysis into Solutions phase of the project . You don't want
developers waiting around until the analysts have completed all the design documents for every
customization before building the customizations. This overlapping schedule approach saves time and
money. In many cases, you will have several developers on your project, each with his own skills and
work pace. Don't feel as if each developer has to be synchronized, task by task, on the project. As long as
the team is managed appropriately, customizations have been approved by the steering committee, and
milestones are being met, let them work at their own pace and construct successful customizations to the
applications.
This phase of the project should also be used to validate any documentation associated with tasks
mentioned previously. Make sure that you receive supporting documentation for each customization that
is within the scope of your project. Often, organizations are left without supporting documentation and
must bring resources back to finish; make sure that documentation is reviewed at the same time.
Also during this phase, refine and update the documentation for any policies and procedures that were
developed during the early phases of the project.

R12 Upgrades
Upgrading to Oracle R12 once was a matter of choice. Nowadays, streamlining Finance, HR, Supply Chain
and Manufacturing and other back office processes has become a necessity for companies that need to
maximize their IT and Business investments.
Key benefits:
Lowers your upgrade risk
Shortens your project timeline
360 view of enterprise impacts
Provides a baseline upgrade project plan
Free assessment
Key features:
Utilizes Oracle's point release changes as Metadata
Catalogues all of the enterprise customizations
Shows complete impacts and how to correct
Identifies code impacts at a detail level
Spans the AOL, DB and O/S level

Moving Forward with Oracle E-Business Suite R12.2

Understand Whats New
Get Informed

Like most Oracle EBS releases, Release 12.2 includes many new bells and whistles, including online
patching, Weblogic Server and a streamlined installation. What does this mean for you? Well, no more
downtime and extended support are just acouple of the significant benefits that come to mind
It also means new product functionality, Fusion Middleware and database components, along with tools
for installing, configuring and maintaining E-Business Suite environments
all designed to help you leverage Oracle EBS applications to make better decisions, reduce costs and
increase
overall performance.
Determine How an Upgrade is Going to
Impact Your Business Whats it going to take to get there?
Upgrading Oracle EBS can be a difficult, complex process requiring careful planning, specialized
expertise and dedicated owners. In most organizations, where each team member is critical to day-to-day
operations, pulling resources in to manage an upgrade of this magnitude means making sacrifices your
business cant necessarily afford.
Along with any upgrade comes an evaluation and overall assessment of the impact it will have on your
current application environment, along with an understanding of the associated risks. You may be able to
do this on your own. However, these tasks are often resource-heavy and we are more than happy to take
them on. We have the necessary skills and resources to help you determine how an upgrade to R12.2 is
going to affect your overall business
Although the migration path to 12.2 from 11i, 12, and 12.1 is essentially a direct path, be sure to work
with your partner to understand the steps involved to get you easily and quickly to 12.2. A good partner
will successfully connect your people, processes and technology at the high level while taking on the
tactical heavy lifting of an upgrade project planning, implementation, execution, training, support and
beyond.