ERP Systems: The Next Legacy Dinosaur?

PDFPrintE-mail

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.

Add comment


Security code
Refresh

Email Newsletter icon, E-mail Newsletter icon, Email List icon, E-mail List icon Enter your email address to sign up for our Newsletter

Sign up now

captcha
TEChanges - Agility by Design

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?

Show solution...

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."