Road to Oracle EBS Release 12

June 16, 2010 – 9:37 am by Sankar Das

In today’s economy many organizations are committed to expanding their global footprint. Whether it’s through operational expansion or acquisitions, these companies have a common goal – reducing maintenance overhead. Reducing overhead is a term which is no longer exclusive to resources or operational costs. A variety of business and IT systems which are added to a company’s portfolio as a result of business expansion or acquisition are becoming a point of major concern as well. Organizations are looking for flexible and scalable business applications which offer maximum alignment with operational capabilities, seamless integration with existing family of applications and the lowest possible total cost of ownership. 

Many leading ERP vendors like SAP and NetSuite have taken the initiative to address these issues on one or more fronts. While some are offering improved business process alignment capabilities, others have increased focus on seamless integration. Oracle, on other hand, has been focusing not only on improving out-of-the-box business process capabilities and state-of-the-art integration capabilities, but also lowering the total cost of ownership of enterprise applications. 

Oracle released EBS Release 12 (R12) in February 2007 with quick wins in operational capabilities such as Sub Ledger Accounting (SLA), Convergence of Discrete & Process Manufacturing, and Multiple Organization Access Control (MOAC). This release has become the most reliable and adaptable global platform with the highest focus maximizing business capabilities and minimizing customizations.

Many existing customers of Oracle EBS have chosen to upgrade to R12 to obtain the maximum business value from the newly available functionality. The new business capabilities in R12 are now making enabling organizations to automate many of their manual processes (e.g. in the area of shared services). When it comes to mapping your road to Oracle R12, it is critical choose the right approach which takes into consideration scalability, maximum business process alignment, and lowest TCO.

In this article, we will discuss three possible roads to upgrading to R12: 1) Technical Upgrade; 2) Fresh Implementation; and 3) Hybrid. 

Option 1: Technical Upgrade 

In this approach, when the application is upgraded to R12, only existing business capabilities are tested to ensure that current business practices will be supported. The technical upgrade does not call for any changes to the business processes. In many cases IT is the key initiator of such upgrades and business involvement is minimal during the testing of the existing processes.

As the instance gets upgraded, it lays down the infrastructure and path to enable additional business capabilities that will be needed in the future. This is the most simple and cost efficient way of upgrading to R12. Unlike the fresh implementation and hybrid approaches, organizations will follow this path when

• They need to upgrade to the latest release to ensure adequate support from Oracle
• Additional R12 capabilities are not adding enough business value to the organization
• There are constraints of budget and / or resources for implementing additional functional capabilities
• The organization is not ready to accept or incorporate new business capabilities
• There is the possibility of breaking existing customization after the upgrade

Due to the changes in the user interfaces, proper end user training is required to ensure the application is used effectively. Training and adoption are critical components of any R12 upgrade, irrespective of the approach followed.

Option 2: Fresh Implementation

The fresh implementation approach requires the highest investment from both a cost and resource perspective, but it yields the highest returns by aligning the organization’s processes and systems to meet current and future business needs. If any of the situations below ring true for your organization, a fresh implementation is the best bet.

• We are still hanging on the old Oracle EBS release and there is so much new functionality available that can improve efficiency.
• We have heavily customized our Oracle EBS instance to align with our business capabilities.
• We are unable to scale our business due to systemic limitations and broken processes.
• Despite having an enterprise system, we often rely on manual processes because our enterprise system has limited functionality.
• Our chart of accounts needs major changes to meet our reporting needs.
• Our business model has recently changed due to a merger or acquisition.

This approach follows the same steps as a new implementation, including documenting business requirements, conducting a fit-gap analysis, executing multiple testing cycles, and converting data from the existing e-Business system. A comprehensive training must be provided to the end users. In this approach, the organization has the opportunity to improve their business processes and leverage the out-of-the-box functionality available in R12. The organization may also reduce many of its customizations by implementing standard functionality. This approach involves a significant time commitment, investment and change management. For many organizations it may be difficult to wait to achieve the benefits.

Option 3: Hybrid

Sometimes neither the technical upgrade nor the fresh implementation approaches are suitable for an organization because just doing a technical upgrade does not justify the investment, or there are insufficient resources and budget to execute a fresh implementation. In this case, a hybrid approach may be suitable for organizations that want to create the latest R12 infrastructure and derive certain focused benefits of R12 leading functionalities within a shorter period of time and with a limited budget.

In the hybrid approach, the instance is upgraded to R12 with the existing functionalities and customizations. Certain key process areas for improvement or customizations are identified to be replaced with new R12 functionality. Organizations may utilize this approach if they:

• Would like to take the advantage of certain new features and functionalities of R12 that would bring maximum value
• Don’t have excessive customizations in the existing instance
• Have the budget and resources to not only test existing processes but also new capabilities
• Are mature enough to accept or incorporate new functionalities without major scope creep

Many of the finance functionalities have been modified in R12. Organizations may choose to just revisit the finance-related processes and implement the latest functionality within the finance modules and just do a technical upgrade on the remaining modules. This way there is a higher return on investment for the upgrade. For organizations taking this hybrid path, it is important to identify all the required new functionalities and modules to be implemented in advance and tie them to specific business drivers and objectives. New test scripts and training documents to cover the existing and new functionalities must be created. There needs to be a strong change control process because it is easier to get carried away and try to implement additional new functionality that was not planned initially, leading to scope creep.

Compared to the technical upgrade, this approach will require more resources. This approach may not work when the existing instance is many releases behind R12. In many cases process reengineering may be required to use out-of-the-box functionality instead of existing customizations. Due to the addition of new functionalities, additional efforts are required for training and change management.

Establishing a Baseline

Whenever an organization plans to upgrade to release R12, it must compare the new and existing capabilities. Establishing a baseline and identifying future requirements of additional capabilities will help the organization make decisions effectively, whether in relation to the R12 upgrade or other improvements. Organizations need to document their current capabilities and business process flows if they have not already done so, and must create and capture test scripts either in a testing tool or in some other format.
Decision-Making Process

Determining which approach will best meet the organization’s needs is a complex process. Many factors affect this decision, including the organization’s future roadmap, current baseline, organizational priority, and resources and budget availability. Instead of depending on gut feeling, following a systematic process will help organizations determine which approach is right for them. A typical decision-making process flow chart used by many organizations is illustrated below. However, changes in the process flow may be required depending on the baseline and the complexity of business requirements.

Figure 1

 

Conclusion

Organizations with Oracle eBusiness instances will soon be upgrading to R12, and it is critical that they select an implementation approach that best suits the needs of the company. In order to make the best decision, organizations must carefully examine their maturity level, requirements of new business capabilities, organizational goals, and the availability of resources and budget. Establishing a current baseline and following a repeatable decision-making process will help the organization to select the most beneficial approach.

Contributors: Kamlesh Desai and Amit Chopra

PDF of Article: Road to Oracle EBS Release 12

Posted in Uncategorized | Permalink |