Release 12 brings with it many significant changes and enhanced functionality that will eliminate many customizations, allow companies to operate globally, and streamline major business processes. The decision to upgrade Oracle E-Business Suite brings with it numerous business and technical issues along with a wealth of opportunities. The process of upgrading allows you to thoroughly examine your current application structure and re-architect it to support current and future business requirements, and to clean it up so that you can maximize your Oracle Apps investment and upgrade with confidence.

Planning for your upgrade should include reviewing your current environment and determining how you can operate more efficiently. As with every upgrade process, you will go through a number of test cycles before you determine how you want to implement, what you want from your current apps, and what you want to change. You will also go through several iterations before you have confidence that your implementation environment is stable, that all the patches work as promised, and that you have a smooth cutover to production. In order to make your E-Business Suite more nimble and capable of handling the Release 12 upgrade process with minimal hangups, there are a few recommended changes that you should undertake before you upgrade. Making such changes before the transition to Release 12 allows you to test those changes in an environment that you are familiar with and is stable. You can then test one change at a time and see the impact of that change, leaving a trail of breadcrumbs to follow in the event of an error. Your users will be able to test with confidence without having to learn the new functionality of Release 12 and without wondering whether the error is due to the complexity of Release 12, a bug, or whether it can be attributed to the change you just made.

When you implemented Oracle Apps, the tendency was to make it do everything the way you did it in your old system. You didn’t worry about making sure that you could access all the data, that it was consistent among all of the instances, or that you could structure your data to make reporting and queries easier. In fact, everyone in the organization wanted control over their own data. You accommodated their wishes by setting up multiple instances, multiple sets of books, multiple charts of accounts, and duplicate data everywhere. Your applications keep growing, requiring more maintenance and more hardware to support them. Before upgrading and adding even more complexity to your environment, here are some things that you can do to clean up (and save millions of dollars by not reimplementing).

Change your accounting flexfield.

With Subledger Accounting in Release 12, you can operate in several countries with different functional currencies. There is no need to have separate sets of books to accommodate different statutory and regulatory requirements or multiple currencies. Now is the time to review your chart of accounts, put the values in clean ranges, and standardize your accounting structure. Changing your chart of accounts will make your consolidated financial reporting easier (and may even reduce the need to do GL consolidations among sets of books), allow you to do more thorough analysis with standard reports, and reduce the maintenance of allocations, cross-validation rules, security rules, fsg reports, and summary accounts. Well-defined ranges simplify financial statement generator reports, streamline your budgeting, and simplify queries in business intelligence applications.

Consolidate multiple instances.

Maintaining multiple instances across a company requires numerous patches and increases maintenance, hardware, and license costs. Consolidating into a single instance forces consistent data across the enterprise (configuration and master) and decreases the pain of enabling future business changes (besides, if you consolidate your instances, you only need to do the Release 12 upgrade once).

Archive and purge your data.

Obsolete or inactive data sets create resource burdens, slow down the system, and frustrate the users. Inactive or obsolete data may be merely a result of time passing, or they may have occurred as a result of business changes such as selling off part of your company. Archiving and purging data related to inactive customers, suppliers, or old product catalogs will streamline your operations and result in large cost savings. For example, a company that has divested a portion of its business no longer needs the data belonging to the divested portion; such data only takes up space and adds clutter to day-to-day operations.

Eliminate Duplicate Data.

This one is easy - duplicate data creates costly problems for both companies and their customers, increasing the probability of error and annoyance. Duplicate data can mean sending multiple (or incorrect) statements to customers, not having a complete history of a customer’s buy patterns, having to enter information multiple times, having inconsistent terms with suppliers, keeping extra items in inventory, and paying too much in processing and maintenance costs. Cleaning duplicate data can help data exchange with other systems, assist with regulatory compliance and security, and add to the accuracy and value of the Apps.

The Bottom Line

The common denominator here is that getting rid of unnecessary, inconsistent, and inaccurate data helps an organization to perform more efficiently, often much more efficiently than its members realize (to the tune of millions of dollars a month). Before you make the transition to Release 12, consider the different ways that software may be able to help you reduce database clutter, cut expenses, and make your business more agile.