Written by Helene Abrams Saturday, October 20 2007
As businesses grow and become more complex, the information systems that support them require continuous updates to keep up with the changes. Moving to an ERP (Enterprise Resource Planning) system doesn’t reduce the need to change. The implementation of the ERP system reflects a static point in time, and supports the business processes and data requirements at the time of implementation. Supporting these “dated” business practices costs money, and more importantly doesn’t allow a company the agility to change as the business environment changes. The difficulty of changing the myriad of complex systems, and the interrelationship among the many enterprise systems, leads many companies to just leave things as they are, quickly giving the current ERP system the characteristics of a legacy system. When do ERP systems become legacy systems?
Legacy systems are often thought of as green-screened hardware comprised of applications that required hard-coding and continuous additions to that code to provide new features, lack of documentation for the changes, and unenforced data integrity. For example, database field formats may differ in many of the different applications or modules. Consider that a large part of the Y2K crisis was a result of format inconsistencies in the “date” field of legacy applications across the globe. Billions of dollars were spent making this single modification, and thousands of similar issues exist across the many systems of today’s enterprises. Forrester Research reports that “76 percent of IT budgets [are] earmarked to maintain existing applications.”1
Both the complexity and lack of quality of these systems force an abundance of ongoing maintenance and make it difficult for them to support agile business changes. Even within a single system, there may be over 2 million columns, each of which could be related to any other creating a cascading maintenance effort that results from making a single change to a specific part of the system. Making one change requires making changes everywhere in the system due to the multiple relationships, potentially resulting in millions of changes that must be made if a company, for example, changes its business from a product business to a service business. This complexity is exacerbated many times over when companies have not just one ERP system, but many integrated systems with inconsistent data. A change in one system impacts many different systems, often in unpredictable, undocumented ways.
“The Hackett Group estimates that the average $1 billion company maintains 48 financial programs, along with nearly three ERP systems,” according to CFO magazine. “So it’s little wonder,” says Randy Whitchurch, CFO at bar-code maker Zebra Technologies, that “if you’ve got a lot of far-flung locations on disparate accounting systems, [documenting controls is] a problem.”2
It can easily take hundreds of people to extract and refine data from multiple sources, or coax the information from multiple modules within the ERP system and reconcile them to the current business processes. Employees build elaborate spreadsheets, reports, and data warehouses that need to be maintained, compounding the initial reporting expense over time.
Expensive, time-consuming changes make an organization rigid and not agile enough to accommodate the ongoing nature of change.
The problem is, once an ERP system has been implemented, changes to the system are necessary if the data is to correctly represent the business and its processes. There is no way around it. So, when do ERP systems become legacy systems? I think the clear answer is the moment after implementation.
1 Murphy, Phil. “APM Tools Will Reach $500 Million to $700 Million By 2008.” Forrester Research. July 22, 2005.
2 Goff, John. “Sarboxing.” CFO Magazine. February 1, 2004.
| < 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."
