You Can Only Analyze What’s There: The Downside of a Reimplementation
Analyzing data quickly for the most relevant information allows you to make informed decisions at the time they matter most: In the moments before a promising prospect turns into a lost opportunity. But the sheer volume of data involved in making business decisions continues to grow exponentially by the day. In addition, the ability to access pertinent information quickly depends on how the data in your Oracle E-Business Suite (EBS) is structured, and whether it is complete, consistent and correct.
Rapidly accessing data was an attribute that was significantly considered in Oracle EBS Release 12. With valuable new features, including improved reporting and analysis, executives can make timely decisions by seeing integrated system information in real time. This allows for improved planning, forecasting, scorecards, consolidations, analysis and modeling. But in order to take advantage of such capabilities in R12, most companies think they are forced to reimplement. While that may seem to be a viable option, there is a major concern that comes with a reimplementation – what happens to your history?
For all enterprises that have been conducting operations for any significant amount of time, history matters. But when you reimplement, you’ll typically only bring over a year’s worth of history and keep the “old” instances as a sunset instance. If you are using a business intelligence system, you may need to get data from multiple places, including the sunset instance. Even with the history instance available, the data is not the same. The data needs to be extracted, translated and aggregated. It has to be loaded into the new environment and is only as accurate as the coding, reconciliation and testing at the point of conversion. Access requires a reverse translation, reconciliation and coding. And the more complex the source environments, the more expensive it is to produce analytics that have any meaning.
The truth of the matter is that there is no easy way to access disparate systems with different types of data. When data is inconsistent, the high costs of maintaining or reconciling that data, reorganizing the data, and supporting, consolidating, analyzing or separating the data means that a very high percentage of the budget is directed toward running the business, rather than being spent on new initiatives. Besides, how trustworthy can you expect different sources of data to be?
Dealing with data history will be a significant part of your reimplementation project. The issues that come from a reimplementation include:
Translation and Reconciliation Complexity
When you need to access the history in the old instance, it is generally in a different format (which affects the chart of accounts, organizational structure, etc.), and so there is ongoing translation and reconciliation needed for year-over-year reports, data warehouse loads and other standard business matters. The way it works is that when beginning a reimplementation, you will need to decide what history to load and what to do with the remainder. The usual choices include the most recent and current financial year, the current year and then only open transactions, and a policy for each different type of data is needed. You will keep the 11i instance in “legacy” mode – making it a sunset instance – and typically it must be frozen and restricted to read-only access. You will devise reporting mechanisms to span the legacy 11i and operational R12 instances, which will include translations, reconciliations, mappings and external reporting environments. If you have a business intelligence environment or data warehouse, you will need to make changes to incorporate the frozen legacy 11i and operational R12 environments. The data structures in the history instance aren’t going to be the same as those in the new R12. In order to report on, make an adjustment to or process a return in the “old” 11i data, the format of the old data will then have to be translated into the new data structure. That also means that there are translation tables to maintain and pointers to continually update.
Trouble Accessing “Old” Transactions
A reimplementation also affects the activity that was reported on “old” transactions – those done prior to reimplementing. These transactions might have already been closed but may still need to be referred to when doing business. For example, if there is a return or a credit memo on an invoice from a year ago, then to effectively do the transaction, the customer has to bring the “old” invoice transaction into the new (reimplemented) system. Reporting gets messed up because the original invoice was reported on in the old system, but is now being replicated in the new system, and you don’t want to report on it twice.
Loss of Constituent History
Another issue is the loss of customer buying history, supplier purchasing history and employee history. Yet, many statutory requirements in other countries require that you keep 10-15 years of history on file and actively maintain three to five years of history – a major concern if you are only bringing over a year’s worth of history.
It is difficult to come up with beginning balances in the new system that are auditable and reconcilable. The balances are kept in Oracle by code combination, and there are currency conversion issues, already depreciated assets, pre-paid amounts, ongoing projects and service contracts that don’t easily “convert” to a clean beginning balance at the point in time that you do the conversion to the new system.
Even though data conversion tools these days are powerful and programmers in the global data centers are themselves inexpensive, a sunset instance still costs money to maintain. It still needs support, patches, storage, backup and a method to retrieve it. Security and access still need to be controlled. The stories that I have heard are that users access the old instances many more times than what they had budgeted. For example, a company might budget to access the old system and do the translation two times a month, only to find that the users are accessing the systems closer to 40 times a month – or more than 20 times what was originally budgeted for!
In the end, you can only analyze what’s there – even if it doesn’t include everything you need or comes from different sources – and that can jeopardize the integrity or validity of your data, and therefore it will affect critical business decisions. If a reimplementation means compromising the integrity of your data, how can you maintain your history and still take advantage of R12 without reimplementing? The answer is to remodel your 11i EBS instance to change the setups that don’t support your business, and then do a technical upgrade. Customers using 11i can upgrade instead of reimplement and shorten the time-to-value at a lower cost, use fewer resources than in a reimplementation, and provide a better R12 result for both the business and IT.
Your history matters. A sunset instance costs money to maintain and retrieve, and it doesn’t provide the all the data from a single source. It’s almost as though the data is not there because it’s not accessible, it’s not consistent with your current production data, and the quality of the data can’t be trusted.