Breadcrumbs
Home / Blog / Return on Investment Analysis / The Oracle Applications "Tax"Written by Helene Abrams Tuesday, September 18 2007
The only good thing about the corporate income tax is that a larger tax is a sign of larger revenue. In every company, there is also a "deadweight tax" levied on the company by Oracle EBS and other ERP (Enterprise Resource Planning) systems. You probably wonder why you've never heard of this tax. And you also likely wonder if there is a way to avoid paying it.
When you learn that the taxes might be as much as 25 percent of your revenue,1 it's time for a long talk with your IT director. This so-called tax is a cancer that grows in the IT organization because ERP systems can't change as the business changes. The real dollars are not the millions that you spent implementing your applications. The tax begins to accrue as your company grows and changes but the systems that you put in place several years ago haven't changed.
Yes, Oracle added new features and functions and even made the Applications easier to manage. But increased functionality alone does not support business changes such as mergers and acquisitions, Sarbanes-Oxley (SOX), the change to the Euro, etc. Even when functionality is present, the Aberdeen Group, in a study of more than 1,200 enterprises, found that on average companies use only about 43 percent of available ERP functionality.2
The deadweight ERP tax, as it will be called in this article, operates in several ways. In any sizeable company that has even a modest history of growth, this tax can be several million dollars per month. The tax can be attributed to several causes:
1. Silo mentality. A silo mentality increases complexity, duplication of efforts and different versions of the truth, which compromise the quality, reliability and accessibility of vital information.3
As Ken Jones, CEO of Accessible Technologies Inc. recalled, "Having to maintain and reconcile three databases was slowing production, especially in periods of strong growth and during peak season. Customer service was also hindered by the lack of system integration and an inflexible order configuration process."4
2. Inability to predict future business needs. This vulnerability is especially true at the time of implementation when the tendency is to put in a system that closely resembles the legacy system that it is replacing.
3. Inability to change ERP system set-up parameters. This factor is seen in a multitude of areas, such as the accounting structures or product IDs after the first transaction is entered.
Another element of the tax arises from the complexity of the underlying ERP system. Management needs information that is pertinent to how the business operates now. Suppose, for example, that management wants a customer-spending analysis across different operating entities and different systems. How is the information gathered?
The ERP tax is imposed by the need to employ tens or, more often, hundreds of people to extract and refine data from multiple sources, or even garner the information from multiple modules within the ERP system and reconcile them to the current business processes. These people build elaborate spreadsheets, reports, and data warehouses that then take on a maintenance life -- and expense -- of their own.
Think next about the cost of accurate regulatory reporting. Driven by the Sarbanes-Oxley Act, and other industry-specific regulations, achieving and maintaining regulatory compliance has become a high priority of critical business objectives. Consistency and manageability of business processes and information are critical components of compliance strategies. To achieve and maintain compliance, enterprises need a "single version of the truth."5 SOX requires full transaction tracing, and each different system has a unique approach to that requirement. Once again, another army of specialists must be hired to find and reconcile all of the relevant data to avoid making inaccurate reports. Violation of laws such as SOX is not an option. But absent a single source of truth for the enterprise data, the company must pay another form of the ERP tax.
Operationally, multiple applications and information silos impose another ERP tax. This tax takes the form of multiple license fees and support contracts for the same applications. The tax also accrues because technical differences among diverse applications require the hiring of experts to create, implement, maintain, update and secure the different applications. The ERP taxes mushroom with the need to maintain multiple backup, restore and replication functions with specialized hardware and software requirements.
Consider next the elephant in the room: the tax imposed by bad data quality. This tax is imposed by the business implications for having different terms with your suppliers, duplicate products with different prices, different credit limits for your customers, customers not being treated consistently across the organization and duplicate data entry. Most companies have between 10 percent and 60 percent of duplicate or inconsistent data in their systems, costing millions of dollars per month.
A major U.S. bank had tens of terabytes of redundant and overlapping data following a series of acquisitions. By cleaning up the duplicate data and consolidating their enterprise data, the bank reduced storage by $30 million per year on a single project.6
These data quality issues can cost a company as much as 25 percent of a company's revenue.7
Companies are spending millions of dollars on implementing a service-oriented architecture (SOA) to try and avoid some of these taxes, or at least lower their "tax bracket". The reason for moving to a new architecture like SOA may be for many different reasons. But generally speaking, companies justify moving to a SOA to reduce development costs, share data among different systems and enable business process change. To be clear, there is no "Tabula Rasa", no clean slate. Anything that is wrong with the original systems will carry over and be multiplied within the service-oriented architecture.
It is the digital version of Shakespeare's "the sins of the father are to be laid upon the children."
In many cases, implementing an SOA brings with it additional taxes in the form of maintenance and overhead. Information Week reported that about a quarter of SOA and Web-services projects that fell short of expectations usually did so because of business and IT alignment problems.8
Using an SOA to integrate technologies does not standardize the business processes or ensure that the SOA-based business components are widely accepted by different parts of the organization. Integrating systems that do not have consistent business rules or that have data conflicts among them leads to management and governance issues, increases the cost of implementing SOA and actually impedes change.
By now, it is evident that the deadweight ERP tax in its many forms is real and substantial. The high taxes resulting from silos of information, the implementation of multiple instances and the fragmented view of enterprise information added to the taxes imposed by data-quality issues and lack of business agility could easily negate the benefits of implementing an ERP system. What's more, applications could quickly turn into the dinosaur legacy applications of years past.
The sizable IT tax that your company may be paying, perhaps without your knowledge, is a vivid symptom of increasing ERP obsolescence. Put simply, the inability to change will eventually lead to extinction.
| < Prev |
|---|
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





