ERP Implementation Methodology


This article will cover the different stages involved in implementing an ERP solution like Oracle E-Business Suit (EBS).

Business Understanding

Business Understanding means to have a detailed analysis of business processes. For this purpose a term AS-IS analysis is used. An AS-IS analysis defines the current state of the business processes in an organization. This analysis is done to clarify exactly how the business process works today. All the business processes are documented to do Gap Analysis. These processes are documented as per modules of Oracle EBS so that these can be easily compared. Mainly following are business processes in any organization:

  • Sourcing process
  • Procurement process for goods and Fixed Assets
  • Inventory Management
  • Payment Process
  • Sales Order Management
  • Receipt and Collection process
  • Cash Management

As a result of this analysis a document is prepared which includes detail of all processes along with the process flow diagrams. This documentation is a baseline for preparing the further documents during Oracle EBS Implementation.


Gap analysis

Oracle EBS supports solutions for standard business processes such as financial, sales, procurement and warehouse. In order to improve the understandability and efficiency of their implementation, Oracle EBS vendors have introduced reference models that describe the processes and underlying structure of the system. To select and successfully implement Oracle EBS, its capabilities have to be compared with an organization’s business needs. Based on a comparison, all of the fits and gaps must be identified and further analyzed. This step usually forms part of Oracle EBS implementation methodology and is called gap analysis. The document theoretically overviews methods for applying reference models and describes gap analysis processes in detail. The document’s first contribution is its presentation of a gap analysis using standard business process modeling. The second contribution is the demonstration of a process-based comparison approach between a process and Oracle EBS process reference model. In addition to its theoretical contributions, the results can also be practically applied to projects involving the selection and implementation of Oracle EBS.

Following are some key factors which should be considered while conducting GAP Analysis:

  • The primary step is to make a note of the existing business system which we covered in AS-IS Analysis. Then list out the flaws and positive aspects. This is an attempt to have an idea of what is currently happening given the scenario in question so as to help in Oracle EBS implementation.
  • Evaluate and decide the additions that need to be made to the business in view of Oracle EBS implementation. The aim is to make sure that there is not even a thin line of difference between Oracle EBS and the organizations commercial activities.
  • Rating the existing level of performance to set a benchmark or standards for the business as on date. This will help in finding out the benefit of Oracle EBS.
  • Having an in-depth study of the regulations and statements in the organizations and suggesting modifications. This also will decide Oracle EBS implementation.
  • Clearly defining the roles of individuals in the organization so that the priorities are met and the structure remains undisturbed. This is to make things clear for Oracle functionalities.
  • Checking if the objective in discharging duties are met because it is the ultimate solution to any issue. If they are not met, the gaps should be known and corrected. Only then the organization can achieve the benefit of ERP.
  • Similarly comparisons are to be made for every other factor that draws relation in one way or other. These results are to be complied for Oracle EBS gap analysis.
  • The gap analysis takes into account all the factors of study and gives the results. It either recommends the implementation of an ERP system or rejects the idea in totality.

All these factors are documented and analyzed so that the decision for ERP Customization or Business Process Reengineering (discussed in next step) can be easily taken.


Business Process Reengineering or ERP Customization

Business Process Reengineering (BPR) is the analysis and redesign of workflows within and between enterprises in order to optimize end-to-end processes and automate non-value-added tasks.

Business Process Reengineering (BPR) is the practice of rethinking and redesigning the way work is done to better support an organization’s mission and reduce costs. Reengineering starts with a high-level assessment of the organization’s mission, strategic goals and client needs. An organization may find that it is operating on questionable assumptions, particularly in terms of the wants and needs of its clients. Only after the organization rethinks what it should be doing, does it go on to decide how best to do it.

Within the framework of this basic assessment of mission and goals, reengineering focuses on the organization’s business processes. As a structured ordering of work steps across time and place, a business process can be decomposed into specific activities then measured, modeled and improved. It can also be completely redesigned or eliminated altogether. Re-engineering identifies, analyzes and re-designs an organization’s core business processes with the aim of achieving dramatic improvements in critical performance measures, such as cost, quality, service and speed.

Reengineering recognizes that an organization’s business processes are usually fragmented into sub-processes and tasks that are carried out by several specialized functional areas within the organization. Reengineering maintains that optimizing the performance of sub-processes can result in some benefits, but cannot yield dramatic improvements if the process itself is fundamentally inefficient and outmoded. For that reason, reengineering focuses on redesigning the process as a whole in order to achieve the greatest possible benefits to the organization and their clients. This drive for realizing dramatic improvements by fundamentally re-thinking how the organization’s work should be done distinguishes re-engineering from process improvement efforts that focus on functional or incremental improvement.

ERP Customization is anything other than standard Oracle EBS product(s). This is done to align the business process with Oracle EBS modules.

Oracle EBS is theoretically based on industry best practices and their makers intend that organizations deploy them as it is. Oracle EBS vendors do offer clients configuration options that let organizations incorporate their own business rules, but still gaps remain even after configuration is complete.

Oracle EBS clients have several options to reconcile these gaps through ERP Customization. This is a technical solution. These technical solutions include rewriting part of the delivered software, writing a homegrown module to work within the Oracle EBS or interfacing to an external system. These three options constitute varying degrees of system customization with the first being the most invasive and costly to maintain. Alternatively, there are non-technical options (already discussed in under Business Process Reengineering) such as changing business practices or organizational policies to better match the delivered ERP feature set.

Key differences between customization and configuration include:

  • Customization is always optional, whereas the software must always be configured before use.
  • Oracle EBS is designed to handle various configurations and behaves predictably in any allowed configuration.
  • The effect of configuration changes on system behavior and performance is predictable and is the responsibility of the Oracle EBS vendor. The effect of customization is less predictable. It is the client’s responsibility, and increases testing activities.
  • Configuration changes survive upgrades to new software versions. Some customizations (e.g. code that uses pre–defined “hooks” that are called before/after displaying data screens) survive upgrades, though they require retesting. Other customizations (e.g. those involving changes to fundamental data structures) are overwritten during upgrades and must be re-implemented.

Both of the above options are to fit gaps between AS-IS Business Process and Oracle EBS solution. If there are control weaknesses, improper segregation of duties, redundancies in activities, etc. then to overcome these loopholes and shortcomings BPR is preferred over ERP Customization. But if an organization is following the processes for a longer period of time and those processes are standardized then such organizations prefer ERP customizations over BPR.


Design Documentation

A Design Documentation is done after finalizing the above three steps. This document gives the “TO-BE” processes in detail. “TO-BE” processes can be defined as “TO-BE” business process defines the future state of a business process in an organization. Typically its purpose is to clarify how the business process will work, at some point in the future, once changes are made. Those changes could be technology changes (ERP Customizations) or business process changes (BPR).

This document has several names like Functional Design Document, TO-BE Document, Solution Design Document, etc. and this gives:

  • Detailed functionality of each module of Oracle EBS which will be used
  • Gives the process flows for each business activity
  • Roles and responsibility of each user
  • Approval processes for relevant document
  • All fields which will be used
  • List of all Standard and Customized reports


Conference Room Pilot (CRP)

The purpose of CRP is to give demonstration of Oracle EBS. These sessions are conducted to present the functionalities of Oracle EBS to the power users. This demonstration is not training session for users. On the basis of Design Documents containing all TO-BE processes these sessions are planned.

Practically discussions on Design Document and these sessions are going parallel. Power users explain their requirement in detail during these sessions. On the basis of these discussions Design Documents are amended as per the user requirements. At the end of these sessions Design Documents are finalized and signed off so that further steps can be followed.

This is necessary that Power Users start preparing on Test Scripts from here onwards so that at the time of User Acceptance Testing (UAT) users have exhaustive list of there all business transactions required to be covered in Oracle EBS.

CRP sessions can be conducted at different stages during Oracle EBS implementation, like:

  1. At very initial level to show the best practices keeping the specific industry in mind
  2. After AS-IS analysis to show key business processes
  3. After TO-BE to show potential process model

Configuration Option Document

On the basis of TO-BE document and using vision server (a demo server with sample data) we prepare a document containing the configurational steps as per the specific needs of the client. Using this document we are able to configure different sub-systems (modules) of any ERP software like Oracle as per the business needs.

Configuration on Test Server

Once configuration option document is finalized and all processes are being mapped, we configure all sub-systems (modules) on Test Server. This server is used for testing and training purposes.

Uploading Master Data

Once configuration is completed on Test Server, we upload sample master data obtained from client. Master data mainly includes following (this is not an exhaustive list):

  1. Chat of accounts
  2. Addresses and locations
  3. List of employees
  4. Users
  5. Authorization Matrix
  6. Approval hierarchy
  7. Items
  8. Unit of measures and conversions
  9. Suppliers
  10. Customers
  11. Fixed assets, etc.

Uploading Transactional Data

After uploading master data we need to upload sample transactional data, for example:

  1. Opening trial balance
  2. Open purchase orders
  3. Unpaid invoices
  4. Sales orders
  5. Journal vouchers, etc.

System Integration Testing (SIT)

When we complete the configuration and uploading (Master and Transactional data) on test server, we test the complete business flow within the system within each module and across the modules. This is required before preparation of training manuals, test scripts and user trainings.

Test Scripts: These are used for the guidance of developers as well as for users. With help of these scripts we are able to ensure that all business scenarios are being covered and tested. Generally an excel file is prepared for this purpose.

Training Manuals: This is a user guide to have a walkthrough of software to ensure that all specific areas are covered. Generally these training manuals are prepared in word document and contain screen shots of each step.


Trainings are conducted for users to familiarize them with new ERP software and to help them that how things will work in future. Further trainings are helpful to give a detailed understanding to users that how existing process will be mapped in new ERP software.

User Acceptance Testing (UAT)

Once following are provided to users then they need to do acceptance testing to check if things are working as per their expectation:

  1. Test Scripts
  2. Training
  3. Training Manuals

Successful UAT shows that users are satisfied that all their requirements are covered in current system and they have given go ahead to developers to configure all processes on production server.

Configuration on production server and Go Live

Once user has given go ahead that all scenarios are covered then developers will do the configuration on production server, upload master and transactional data on production server and go live entry will be done on production server which means that from a specific date after first entry all entries will be made in production server.

Leave a Reply

Your email address will not be published. Required fields are marked *