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.
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 |
|---|
Related Articles
Related Pages
Enter your email address to sign up for our Newsletter
January Puzzle
A traveler gets lost on a deserted island and finds himself surrounded by a group of n cannibals.
Each cannibal wants to eat the traveler but, as each knows, there is a risk. A cannibal that attacks and eats the traveler would become tired and defenseless. After he eats, he would become an easy target for another cannibal (who would also become tired and defenseless after eating).
The cannibals are all hungry, but they cannot trust each other to cooperate. The cannibals happen to be well versed in game theory, so they will think before making a move.
Does the nearest cannibal, or any cannibal in the group, devour the lost traveler?
Solution
The short answer is the traveler’s fate depends on the parity of the group. If there is an odd number of canibals, the traveler will be eaten, but if there is an even number, the traveler will survive.
To prove this, we will consider small groups and use mathematical induction to explain the solution for larger groups.
Case n = 1: this is an obvious case. If there is one cannibal, the traveler will be eaten. It doesn’t matter that the cannibal will get tired because there are no other cannibals around as a threat.
Case n = 2: this is a more interesting case. Each cannibal wishes to each the traveler, but each knows he cannot. If either cannibal eats the traveler, then he will become defenseless and the other one will eat him. So each cannibal uses backwards induction to realize that the only strategy is to not eat the traveler. The hapless traveler finds a bit of luck, therefore, and actually survives.
Case n = 3: this is where the problem gets interesting. The best strategy is for the closest cannibal to make a move and eat the traveler. The cannibal will be defenseless after eating, but ultimately he will be safe. Why is that? The reasoning is due to induction: once the cannibal eats the traveler, the resulting situation has 2 unfed cannibals and the 1 defenseless cannibal. But as we just showed above, when there are 2 unfed cannibals, neither will make a move for fear of being eaten by the other! Thus the first cannibal to make a move will be safe as the remaining 2 cannibals block each other.
We can prove the higher cases using mathematical induction. If the number n is odd, then the closest cannibal can safely eat the traveler because the remaining number of unfed cannibals is even (and by induction, with an even number of unfed cannibals no one makes a move). If the number n is even, then no cannibal will eat the traveler, for if he did, the remaining number of cannibals would be odd, meaning he will get eaten by the induction hypothesis.
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."
