Over the last two decades, companies have plowed many billions of dollars into enterprise resource planning (ERP) systems and the hardware required to run them, and the largest purveyors of the complex software packages, notably SAP and Oracle, continue to earn billions every year selling and maintaining the systems. But what, in the long run, will be the legacy of enterprise systems? Will ERP be viewed as it has been promoted by its marketers: as a milestone in business automation that allowed companies to integrate their previously fragmented information systems and simplify their data flows? Or will it be viewed as a stopgap that largely backfired by tangling companies in even more systems complexity and even higher IT costs?
In The Trouble with Enterprise Software, an article in new issue of the MIT Sloan Management Review, Cynthia Rettig deftly lays out the case for the latter view. Enterprise systems, argues Rettig, not only failed to deliver on their grand promise, but often simply aggravated the problems they were supposed to solve. “The triumphant vision many buy into is that enterprise software in large organizations is fully integrated and intelligently controls infinitely complex business processes while remaining flexible enough to adapt to changing business needs,” she writes. The reality is very different, says Rettig:
But these massive programs, with millions of lines of code, thousands of installation options and countless interrelated pieces, introduced new levels of complexity, often without eliminating the older systems (known as “legacy” systems) they were designed to replace. In addition, concurrent technological and business changes made closed ERP systems organized around products less than a perfect solution: Just as companies were undertaking multiyear ERP implementations, the Internet was evolving into a major new force, changing the way companies transacted business with their customers, suppliers and partners. At the same time, businesses were realizing that organizing their information around customers and services – and using newly available customer relationship management systems – was critical to their success.
The concept of a single monolithic system failed for many companies. Different divisions or facilities often made independent purchases, and other systems were inherited through mergers and acquisitions. Thus, many companies ended up having several instances of the same ERP systems or a variety of different ERP systems altogether, further complicating their IT landscape. In the end, ERP systems became just another subset of the legacy systems they were supposed to replace.
Given the high cost of the systems – around $15 million on average for a big company – it’s unsurprising, writes Rettig, that despite much study, researchers have yet to demonstrate that “the benefits of ERP implementations outweigh the costs and risks.” In fact, in a revealing twist, the mere ability to install an ERP system without suffering a major disaster or disruption has come to be viewed as a relative triumph: “It seems that ERPs, which had looked like the true path to revolutionary business process reengineering, introduced so many complex, difficult technical and business issues that just making it to the finish line with one’s shirt on was considered a win.”
Rettig’s conclusion is a dark one:
enterprise systems were supposed to streamline and simplify business processes. Instead, they have brought high risks, uncertainty and a deeply worrying level of complexity. Rather than agility they have produced rigidity and unexpected barriers to change, a veritable glut of information containing myriad hidden errors, and a cloud of questions regarding their overall benefits.
Rettig doesn’t see any quick fix on the horizon. Realizing the promise of a more modular and flexible service-oriented architecture (SOA), she argues, may take decades and will itself be fraught with peril. “The timeline itself for this kind of transformation may just be too long to be realistically sustainable and successful,” she writes. “And to the extent that these service-oriented architectures use subsets of code from within ERP and other enterprise systems, they do not escape the mire of complexity built over the past 15 years or so. Rather, they carry it along with them, incorporating code from existing applications into a fancy new remix. SOAs become additional layers of code superimposed on the existing layers.”
So what’s the solution? Rettig doesn’t offer one, beyond suggesting that top executives do more to educate themselves about the problem and to work more closely with their CIOs. That may be good advice, but it hardly addresses the underlying technical challenge. But Rettig nevertheless has provided a valuable service with her article. While some will argue that her indictment is at times overstated, she makes a compelling case that the traditional approach to corporate computing has become a dead end. We need to set a new course.
UPDATE: Harvard’s Andrew McAfee takes issue with Rettig’s article, arguing that managers have been rational in investing large amounts of cash in enterprise systems and pointing to a recent study which indicates that, for the customers of one ERP vendor at least, the successful installation of a system produces, on average, subsequent performance gains. McAfee’s critique, however, doesn’t address Rettig’s larger point, which concerns the effect of ERP’s complexity on companies’ choices going forward.
To get SOA right, IT managers should adopt a rule of thumb, which I’ll try to express. (I wish I saw how to say this more concisely.)
With an SOA IT architecture, your enterprise IT is defined as a “circuit” of services, connected up over a network.
We know all the cheerleading stuff: that those component services will become commodities; that services will be commoditized in such a way that hardware provisioning becomes, itself a (software driven) service; that the resulting circuits can be cheaply reconfigured, on the fly, perhaps even minute to minute.
The key rule of thumb that people need is that individual services need to be *human scale*. The way that a service component becomes a true commodity is if it is *easy and inexpensive to create replacements*. (And, you can see right there why open source is so important!) If replacements are easy to construct, the price of each component drops to the marginal cost of maintaining an installation (including maintaining readiness to replace it) and the license-free nature of the software parts of SOA components lowers those maintenance costs. It is the “human scale” of the components that make this possible.
In contrast, if you adopt an SOA component that can only be created and extended by an army of programmers at one of the big database companies then that’s it — you’re done — you can’t replace that component with anything less than an army of programmers.
It’s a technical challenge to convince more people that you can get better IT by building out of simple, human-scale components. IT managers are, I think, unaccustomed to the idea that there should be more programmers throughout the IT organization and, well, it’s hard to compete with the bullet-listed features of some of the beheamoth products. Still, examples like Google, who seem to take this approach internally, should tell you something.
-t
While I tend to agree with you, Nicholas, the one thing that troubles me is that little word “trillions.”
Can you back that up?
“Billions” I can believe. Trillions – not so fast.
Maybe every organization gets the IT it deserves? SOA by itself will not provide the solution either. Business should take its responsibility; see also, for example, David Sprott’s view (CBDI journal July/august 2007) on this.
Moreover, also in a service-oriented setting service providers can try to lock in users (individuals or organizations). It requires a benefits (and disbenefits) trade-off by the user, and strategies to mitigate the risks.
Until those systems are there someone has to sell them
See my small cartoon
Bye,
Oliver
Nicholas, you can also see this problem in the web-based (netsuite/intacct/salesforce) sofware-as-service systems for “small business”.
I know of two small businesses who use salesforce where a nice online spreadsheet would do. In addition, new employees must “train” to use the system which I find kind of funny.
I agree that less money is wasted though. ERP is a racket, let’s face it. But so is business consulting :)
Can you back that up?
You got me, John. I would say it’s at least a trillion (total enterprise systems – software plus hardware), but “trillions” may well be an overstatement. Then again, if you add in labor and consulting services . . .
Anyway, I’ve changed “trillions” to “many billions” in the first sentence.
Hi Nicholas,
ERP problem or solution?
Both:
Depends on the product A company wants me to help them to decide between SAP or Oracle. My answer, you have to go with the product most aligned to your business model.
Depends on the phase: At the beginning it is more a problem than a solution. After the implementation period, it helps to connect the departments that live as islands.
Depends on the technology: Techcrunch reported yesterday 34 web 2.0 social network companies that go to companies and replace the so famous intranet with a their software. When talking with the VP of Oracle for new developments, he expressed the desire to go into this model. Open standards are better than legacy.
Mario Ruiz
http://www.oursheet.com
I could not disagree with you more.
I agree ERP is not the end all solution, but it is certainly a method for improving overall business operations.
Failures is ERP are attributed far more to improper selection, implementation, and usage. I’ve watched way to many companies be sold on the wrong product or implement their selected package poorly.
ERP can be absolutely be a solution, but only if purchased and utilized correctly.
Rebecca Gill
Technology Group International
http://www.tgiltd.com
Gartner Joke (Dave McCoy) – “What’s the average lifecycle of an ERP implementation?” … wait for a few murmered numbers from audience … Answer -“2.5 CIO’s”.
But seriously, I seem to remember the head of Forrester predicting that anyone buying SAP was buying a legacy application around 10 years ago … that hasnt stopped anyone from doing it.
In the end, the appeal of a silver bullet is alluring. Executives continue to delude themselves that hard work and operational innovation can be bypassed on the road to achieving organizational agility and superior performance improvement.
In the end, the business itself has to start taking control of how it does things rather than abrogating responsibility for change to system integrators who are often only too willing to take the money and run. Most business people have little idea of how to think about their business processes — believing IT can work their magic and make it all better. Major application vendors have a vested interest in keeping the business change genie well and firmly stuffed in the IT bottle.
But coming back to the central point in this blog post–if your start point was 144 transactional systems (think Dow Chemical), then moving to a single integrated platform for accounting is a _major_ step forward.
But going forward from here–when everyone has a standardized CMM/BPMM Level 3 way of doing the core things, the challenge becomes how do you enable your knowledge workers to take control of their processes. And that’s a domain that even the most erudite BPM vendor is only just starting to grapple with.
Many people perhaps “forgot” that in choosing “the right” business solutions, the most important criteria is “workability” of the system, and NOT how many “integrated features” the system had.
Many people perhaps get “trapped” in this “siloic” view of choosing application based on “completeness, integratedness and best-practice-ness” of the solution … they probably got too excited about that, and unfortunately “forget” the most essential essence: that in choosing business systems, what matter the most is in choosing, implementing and adopting solution that really works!
Others might fall into the “trap” of “just follow the herd, or the stampede ahead” as their “consultant” (or “insultant”?) blindly advise them, … unfortunately they just don’t know many of the “herd” ahead is heading towards a treacherous cliff!!
Completeness, integratedness is nothing if the system doesn’t really work when being applied to the real business case and real business situation where people work and live everyday.
Business systems is not about “integration” of unworkable system modules as one. Rather it shall be about “integration” of truly workable system module at each time. That’s perhaps why WORKABILITY matters!
Workability is the key essence. To achieve that, the view and perspective in selecting, deciding and choosing the solution probably must “change” too. Perhaps it shall transform from the view and “blind-perspective” of “follow the herd”, or “join the ‘best practices’ stampede”, etc … into “choosing the process, system and solution that REALLY WORKS”.
Not all my above draft thoughts, perspective & opinion might be 100% correct. But hopefully could be useful. After all the process of wasting alot of money just to create “next step of troubled complexities” that doesn’t help the business at all shall stop.
More draft view, discussion and thoughts posted here: http://arvino.typepad.com/digital_living/2007/
08/erp-troubled-le.html
MBA program, Business schoolit is to rethink “the software skills ”
(1)According to the BusinessWeek magazine, it points out an MBA program at the business school that it is important to rethink “the software skills”.
(2)It says that there is a gap actually between the education contents which are being taught at the business school, and the knowledge and the skill that the costomers ask for.
(3)There are two kind of skills with this “the software skills”. The first one is the human resource management, and another one is the decision-making management.
(4)At this time, the survey to the program director with more than 8,600 managers, 373 business schools and 118 deans.
(5)According to this research Result, the six themes are mainly pointed out with the interest of the managers` issues.
(6)「human capital」,(b)「logistics and technology」,(c)「decision-making processes」,(d) 「administration and control」,(e)「strategy and innovation」、(f)「task environmen」
(7)Especially Customers would put on the high prioloties to the 「human capital」 and 「decision-making processes」,although the MBA program thought much of the “administration and control” most.
What I find missing from this discussion is: What is the alternative to ERP?
Of course ERP systems have problems, some of which can be overcome by using more modern technologies. But a lot of the criticism on this blog and in Rettig’s article seem unrelated to ERP and more related to the complexity of IT and software in general as it is applied to building business solutions.
Surely you are not arguing against using IT altogether? Rettig writes that complexity of software increases exponentially with complexity of the problem it solves. If this is a natural law, then I guess we have to deal with it. Going back to using paper for everything doesn’t seem like an alternative to me.
Maybe I am missing the point, but I’d like to see a discussion of the alternatives and why they are so much better.
Jesper: I think you’re right. ERP and related systems were probably the best approach to automating basic business processes at the time, given the constraints in computing, networking, databases, and storage. But they also brought a great expansion in the complexity and cost of IT systems and have often restricted comapnies’ flexibility. Now we have a new environment, with the fiber-optic internet and related protocols, much cheaper computing and storage, virtualization, multi-tenant systems, parallel processing grids, in-memory databases, etc., etc., and I believe we are seeing new and better models of corporate computing emerging as a result. (I’m actually more optimistic than Rettig.) Nevertheless, the big enterprise systems will likely slow companies in adopting the new models. In fairness, though, we shouldn’t lose sight of the achievements of SAP and others – landmarks in software engineering.