ERP Application Consolidation: When It's Time to Cut
Consolidating ERP apps can be an unpopular strategy -- it's expensive and difficult. But a Forrester Research case study of one company's travails offers insights into why such consolidation might be absolutely necessary.
Mon, March 22, 2010
CIO — Remember Aron Ralston? He was the mountain climber who, back in 2003, was forced to cut off his own arm, which was trapped under a boulder, to save his life. Ralston had recklessly hiked alone and neglected to tell anyone where he was headed. His grave six-day ordeal was extraordinary and captivating.
Who among us would have the will to sever one's own arm to free oneself from a deteriorating and deadly situation?
Today, many enterprises find themselves in an analogous situation: They're trapped under the suffocating weight of too many applications—some that are siloed, some that play nicely with others, and some that are...well, no one knows exactly what that app is for, who is using it or why it was purchased in the first place.
These are some of the lessons within a new Forrester Research report: "Loss of Historical Financial Data Triggered This Application Consolidation Program." In it, principal analyst Phil Murphy uses the case study of an energy company (he doesn't name) to illustrate just how foolhardy and dangerous it is for companies to ignore application-consolidation measures.
"Bloated application portfolios are a severe tax on the very resources that would otherwise enable new projects and innovation," Murphy writes. "Bloat consumes hardware and software maintenance dollars, is a multiplier on every technology upgrade, and subjects firms to excess business risk, as one energy company discovered the hard way."
The Snowball Effect
The energy utility's story starts off with the director of applications standing before the CFO, attempting to explain why two years' worth of production data had been lost, according to Murphy.
In short, here's what happened: A prior IT administration had wanted to save time and money during an ERP rollout and allowed the previous ERP app to keep running in "inquiry mode," to ensure that business users would still have access to the financial and other administrative data. The project manager saved time on the new ERP implementation (hero!) but also opened the company up to the disaster it now had on its hands (zero!). Murphy observes: A bad precedent was set. (The road to hell, after all, is paved with the best intentions.)
The myopic IT strategy soon created a "proliferation of inquiry-only applications" that, in turn, created "ERP sprawl." Each succeeding ERP upgrade snowballed, adding more "inquiry-only" business applications.
"Over time, the problem mushroomed to the point where the company had several unsupported ERP releases from multiple vendors in addition to the new system of record," Murphy writes. "It also had several custom-built ERP and financial applications acquired via merger. The result was ERP sprawl: The company was running and maintaining literally dozens of ERP applications—many for the sole purpose of occasional inquiry against historical data."
Complexity soon riddled the company's financial systems and set the stage for the ultimate data-loss event. At one point, IT deep-sixed one ERP application that had not been accessed in months. "The purge went unnoticed until the CFO needed some historical data to develop a tax analysis and found that two years of data were missing," Murphy writes.