Professional Documents
Culture Documents
EBS Assessment PDF
EBS Assessment PDF
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%
31%
13%
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
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.
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:
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.
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.
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.
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.
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
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.