Breadcrumbs
Home / Blog / Data Quality / Finding the Business Value of ConsolidationTuesday, August 18 2009
The specific business value of business consolidation can be understood by using two different but related analytical frameworks: one that focuses on data quality and quantity, and the second, as termed by EAC, the Do or Die framework. The former focuses ROI analysis on the business issues that can be addressed by having the right kind and amount of data to support business requirements, while the latter focuses on the problems that companies have in meeting legal and regulatory requirements, regardless of whether a specific ROI case can be established or is even needed.
Data quality and quantity issues, although generally related, are best analyzed separately. Data quality is an area that has been well studied by the likes of the Data Warehousing Institute, which in a recent study showed that business drivers related to improved analysis and customer satisfaction – as well as other business issues relating to having a single version of the truth – were among the top five benefits from having high quality data.

The ROI from high quality data extends broadly across every industry vertical. In service industries such as financial services, insurance, and telecommunications, the ability to work from a single customer instance and provide a synchronized set of buying and service options to customers has an enormous potential value, one that is hard to calculate from an ROI standpoint only, because it represents opportunities that simply didn’t exist previously.
High quality, consolidated data also provide ROI benefits due to the exposure of hidden costs or expenses that are simply unknowable without a truly consolidated system. A good example comes from an insurance vendor interviewed by EAC that was able uncover a pattern of fraudulent policy sales by its agents, following a business consolidation project. This company, which requested anonymity due to the sensitive nature of the problem, consolidated previously separate renewals, cancellations, and new policy databases, and in doing so, revealed a pattern of fraudulent activity that was costing the company $14 million per year.
The issue of data quantity is a more complex issue to analyze, largely because most consolidations throw out the majority of historical data, retaining one or two years’ worth at best, and there is therefore a paucity of information on which to build an ROI case related to data quantity. Nonetheless, there are good examples of the negative impact of not maintaining the correct quantity of data, particularly historical data that may no longer be relevant in a transactional sense, but have a high value in terms of reporting and analytics.
The issue of data quantity can best be seen in the context of regulatory compliance. The FDA-regulated industry requirements under 24 CFR 11 are a good case in point: Among other things, this regulatory regime required that pharmaceutical, consumer products, and other FDA-regulated companies maintain six years of data relating to research and clinical trials. The practical aspects of implementing these regulations can be daunting to companies that are merging, acquiring, divesting, or otherwise altering the database infrastructures that underlie and support their research and development efforts. Often, these databases are multiple terabytes in size, and considering the high degree of M&A activity in these markets, the requirement for data and business consolidation is virtually continuous. Furthermore, the nature of the FDA’s inspection and enforcement efforts are such that requests for information – often historical information going back the mandatory six years – must be filled in a matter of hours, if not days.
The risks of failing to meet 24 CFR 11 requirements for a pharmaceutical company are a classic case of do or die. With the cost of bringing a new drug to market approaching $1 billion in many cases, and the relatively short timeframe in which patent protection provides maximum profitability – while patents are typically awarded for 20 year periods, much of that time can be taken up in discovery, research and development – lost time due to regulatory non-compliance can cost pharmaceutical companies enormous sums. The Clinical Data Interchange Standards Consortium (CDISC), a pharmaceutical industry standards group, estimates that delays in FDA approval can cost pharmaceutical manufacturers up to $1 million per day.
This kind of do or die scenario is, in fact, replicated across all regulated industries, whether the regulation involves existing SEC regulations like Sarbanes-Oxley, global manufacturing standards like ROHS-WEEE, or forthcoming regulations like those likely to be imposed on carbon-based emissions. Accordingly, every company must plan for its response to a do or die scenario, and, as explained below, business consolidation that includes retention of historical data offers vast savings in comparison to other alternatives, thereby creating a separate quasi-ROI component for that form of consolidation.
Consider again the choice between full business consolidation that retains all history, brute force business consolidation that moves over a limited amount of history, and mere technical consolidation. Without full business consolidation and data retention, the needed response to a “do or die” requirement would be made by maintaining and reviving to active status otherwise unused data systems, culling the information from those systems, adding the data to post-consolidation data that is stored in the revamped (but incomplete) system, and preparing the report. This process is costly, time-consuming, and potentially fraught with error.
By contrast, a company that undertook a business consolidation that retained history would have a much different process, with a much lower attendant on-going cost. The data needed for the report would be available by a fairly routine query of the integrated system that houses complete, consistent, and correct data – with an effort and time to response no different than any other ad hoc query, and with a level of accuracy that cannot be matched by any other consolidation method.
In that way, a business consolidation effort that retains and integrates all historical data can offer an ROI in several ways. The first component of ROI comes from the fact that the old systems do not need to be warehoused or archived and then revived to meet the needs of queries against historical data. The second ROI component comes from the rapidity with which a response can be generated without the need for an extraordinary expenditure of resources. The third ROI component comes from the far greater guarantee of accuracy – and therefore compliance – due to the completeness of the data consolidation effort and the resulting simplicity of the query and reporting process.
Again, the contrast between technical consolidations, limited business consolidations, and full business consolidations is clear. Companies that fall under the many regulatory regimes that govern business processes are subject to enormous risk if they fail to execute a business consolidation that includes historical data. Absent a business consolidation effort, companies must maintain extremely complex and inefficient database environments – at an enormous cost – in order to be ready to meet vital regulatory and other business requirements. The kinds of technical consolidation, data migration, or data integration projects that predominate in other industries – which at best move forward one or two years worth of historical data – are simply inadequate to meet these requirements.
Thus, the ROI of maintaining the data essential for meeting the reporting requirements of regulations is largely incalculable in the face of the consequences of non-compliance, which can mean the loss of production capability, profitability, market availability, and in the most extreme cases, legal sanctions that can largely cripple an otherwise vibrant company.
© 2009 EAC
Joshua Greenbaum has over 25 years of experience in the industry as a computer programmer, systems analyst, author, consultant, and industry analyst. He spent three years in Europe as an industry analyst and as European correspondent for Information Week and other industry publications.
In his role as an industry analyst, Josh regularly consults with leading public and private enterprise software, database, and infrastructure companies, and advises end-users on technology infrastructure and applications selection, development, and implementation issues.
An award-winning columnist, Josh is widely quoted in the trade and business press, blogs on ZDNet, and is a regular columnist for Managing Automation, Datamation.com, NetWeaver Magazine, and Redmond Channel Partner magazine. Other opinions by Josh may be found on his blog at http://ematters.wordpress.com/ or on his website http://www.eaconsult.com/.
| < Prev | Next > |
|---|
Related Articles
Enter your email address to sign up for our Newsletter
May Puzzle
David is often referred to as Rainman due to his peculiar ability to effortlessly figure out a certain date's day of the week. He recently displayed this talent when I asked him if there was a conflict with the upcoming Fuzzy Dice Conference and our weekly court-ordered community service. He asked the date of the convention. It was April 20th, 2012.
"Oh, that’s a Friday," he said, effortlessly. "And your sentences have you committed for the next few dozen Wednesdays so you'll be able to go." And of course he was right.
One day a few weeks ago I asked out loud in the office about the date June 5th. And of all people, my brother Tommy piped up and said "Oh, that's a Tuesday."
"That's right," said David.
Well how about Otcober 3rd?
"That's a Wednesday," said Tommy. Then I asked about Christmas Day 2012.
"Oh, that's a Tuesday." David nodded in agreement.
Do we now have two rainmen? Or had Tommy figured something out?
Solution
Here's what was going on. Tommy was using something called anchor dates. And these dates apply to each and every year. April 4th, or 4/4 we’ll call it from now on, June 6th or 6/6, 8/8, 10/10, 12/12, are all the same day of the week, each and every year.
So too are 5/9 and 9/5, May 9th and September 5th. So too are 7/11 and 11/7, and all the above dates are the same day of the week, as is the last day in February, Leap Year or not. And they’re all the same day as January 4th, it would otherwise be January 3rd, but this was a leap year, and that’s changes the anchor day from January 3rd to January 4th.
Tommy also knew that New Year's Day was a Sunday. He was sobered up by then. And he knew it was a Sunday because Christmas was a Sunday in 2011, so New Year's Day is a Sunday, so the Anchor Day for 2012, January 4th, has to be a Wednesday!
So if that's a Wednesday, then 4/4, 6/6, 8/8, 10/10, 12/12, 5/9, 9/5, 7/11, 11/7, and February 29th are all the same day of the week, and they're all Wednesdays. So when I ask for example, about October 3rd, he knew October 10th was a Wednesday, 10/10. So 10/3 must also be a Wednesday. 12/12 is a Wednesday in 2012, so it’s 12/26, which is two weeks later. So 12/25, or Christmas Day, must be a Tuesday.
Success Tips for Oracle Project Management
- Create a standard for documentation at the beginning of your project, and hold team members accountable for completing documentation requirements as well as keeping them at and above the standards required.
- Before promulgating user documentation or training, it’s also a good idea to choose a representative from the among the business users base to review materials first.
- If you are not sure about the resources and budget required, obtain several estimates from people that have experience with the same size and scope of your project.
- Be explicit, before beginning the project, what internal resources are required for execution. This includes people, infrastructure, hardware, and software.
- Help the project champion understand the impact your project will have on the organization and how its successful completion will make him or her an internal hero or heroine for supporting it.
- Break up your project into smaller projects (try for projects that can be completed in 4-6 months, especially early on) to get success and demonstrate momentum.
- Make sure that your testing includes reports, upstream and downstream interfaces, customizations, enhancements, and workflows.
- Ensure that comprehensive transition reports and meetings between departing and incoming personnel are completed.
- Instead of spending time and resources implementing third-party reporting, consider consolidating multiple instances, moving to a global chart of accounts (CoA), and/or standardizing on a consistent calendar.
- Include governance, risk, and compliance management as part of the project plan.
- Finally, celebrate the successes. Too many projects focus on defects, failures, or small cost over-runs without looking at the big picture and what was accomplished.
The Analyst Corner
John Van Decker, Research VP of Gartner, states:
"A single chart of accounts allows consistency in financial reporting across the enterprise by standardizing on common metrics and reporting structures, reduces dependencies on a separate financial consolidation system, and significantly reduces the costs incurred with ongoing, complex conversions and translations."
Popular Articles
- Organization Setup in R12
- If IFRS...Then, Part 2: 5 Best Practices in Designing a Chart of Accounts in Oracle E-Business Suite
- 11i to R12 Decision: Upgrade or Reimplement?
- Designing a Global Chart of Accounts and Taking Advantage of Oracle® E-Business Suite Release 12
- Moving from GAAP to IFRS with Oracle EBS





