ERP Systems on Steroids

By Brian Sommer, Techventive

Enterprise architects first conceived of and created ERP solutions in the mid-1980s, and their predictive genius was praised during successive dot-com eras as a Nostradamus-like reading of the future market’s thirst for transactional-driven solutions. Bolting on data marts and analytics engines to support new demands for customized reporting; providing armies of service consultants to rearchitect for best practice business processes…. ERP customers seemed bedazzled (if not broke) by the steady stream of new products and technologies proffered by the leaders.

Today, those transactional systems look like aging athletes on steroids—over-bulked, overpaid and with a very real worry that they’ll be found out.

Over the past 25 years, the geopolitical situation, capital markets and businesses worldwide have changed in innumerable ways. Companies now want the ability to contract services and manufacturing globally, enter new markets with ease and wring out every dollar of savings possible by changing business processes and operations. The thing is, their ERP infrastructure supports a business environment more like 1981’s than 2006’s.

The World Has Moved On; Why Not Them?

ERP software was built on the premise that companies would tailor or configure the solution before they installed it…not after. Like custom-developed code, once these solutions were installed, few expected them to get reworked, reconfigured and reinstalled during the product’s useful life. These old systems were developed by IT professionals who frequently changed companies; documentation was lost, and the replacement workforce had no skills in the coding of old software.

Is it any wonder that companies would defer or avoid major software repairs or reconfigurations whenever possible? The cost of these efforts was huge relative to the benefits derived from the new configuration or functionality. The organizational trauma was worse. And if cost and trauma weren’t enough, the risk that planned changes might backfire into new and unknown tech problems meant the real possibility of career suicide for operational/IT executives.

Transformational change, therefore, might be popular in business books and board rooms, but it is met with snickers if not downright guffaws by those in the technology know when it comes to ERP solutions. This is not a change management problem. It’s a product design problem—one born of software developed for yesterday’s static business environments.

The bottom line? When it comes to invoking new business processes and strategies, businesses are carrying on “in denial,” as psychologists would say, and without the infrastructure they need in today’s environment. This means they remain wedded to past methods and practices, blindly enter bad deals, miss business opportunities, offer substandard service to customers and under-perform against Wall Street and investor expectations.

Lie Detector or Blood Tests—Something Has to Give

ERP vendors have over-promised and under-delivered for decades. Remember how XML, Unix/client server, object-oriented programming, Web applications, Web integration technologies, etc., were each going to make ERP applications easier to implement? Service-oriented architecture (SOA) is the current flavor of the month, and virtually every vendor has hopped on that bandwagon. A healthy dose of skepticism is in order.

Claims of ERP flexibility are more or less upheld with varying degrees of time and expense, but post-implementation agility is quite another story—and a tall tale at that. Evidence that the ERP leaders have been able to quickly, cheaply and accurately alter their installed systems is rare to nonexistent. What is even more remarkable is the difficulty that some major vendors are having just getting existing users to migrate to newer architectures.

This isn’t to say that SOA or other silver bullets won’t improve the flow of information from disparate systems. But it’s no panacea, and it’s only as good as the architecture it sits upon. If, however, a vendor has a product that was designed for post-implementation agility, SOA will make these changes much easier to implement.

Agility is an easy word to say, but a really tough capability to build into ERP software. Why? Most products use some sort of data dictionary. These tools define technical attributes about the data fields within an ERP system. Most ERP products now include a work-flow tool. However, what is really needed is a way to embed deep, meaningful business rules and logic down to the data/field level. For example, a great ERP solution wouldn’t let someone reconfigure a work flow if a number of Sarbanes-Oxley compliance steps would be disregarded. Likewise, a great system would not permit someone to move the capture of a specific field to a different panel if that information is required for some other critical processing.

Data and logic must be more tightly connected so that “intelligent” adaptations can be quickly, easily and correctly made to ERP solutions. Agility requires nothing less.

What’s fascinating is to see how some vendors intentionally keep much of their embedded business intelligence hidden behind some black box. They do this because their solutions are so fragile and unmovable that they dare not let a customer reach inside the product and use it in a way they didn’t envision. And then they call themselves “open” and wonder why most of us would prefer to meet their sales folk at the door with some sort of test that will prove they are as “clean” as they say.

The Impact of Change—Today

So how important is agility to ERP users today? Let’s look at professional service firms for an example. Programming, architectural drawing work, TRIZ engineering, X-ray and MRI reading are all being performed in low-cost countries like Russia, China and India. Service companies have to move from collections of local, in-country practices that barely shared resources even with other offices within their firm. These companies rarely collaborated with other service firms.

Now, they are trying to build out global service delivery models where projects are staffed with a mix of low-cost country service providers and in-country service professionals. New service offerings, like business process outsourcing, are requiring organizations to partner with technology companies, capital equity firms, specialized service providers and more. Collaboration capabilities and more are needed to make service companies more agile and more responsive in a global services economy. Does the average ERP solution permit rapid teaming, collaborative project work, dynamic partner or joint venture support? No.

The changes affecting professional service firms have left most ERP solution providers in an embarrassing hole. Service firms need low-cost back and front office processes and software that allows them to shrink the total elapsed time required to complete projects. Today’s projects and their corresponding organizational teams are a blend of non-stop, overlapping cooperation. Jobs are completed 24/7 utilizing project teams working around the world. The information warehouse, business processes and analytics/reporting engines required to make service firms move nimbly and in lockstep are a must-have—not a nice-to-have.

Agility, the ability to change constantly and quickly, is not what ERP developers envisioned decades ago, but it is most relevant now. It’s time for some fresh blood and a new no-tolerance policy on thinly backed promises from the traditional leaders.

Brian Sommer is a research analyst and president of Techventive, a research group that provides strategic guidance and content on the technology sector.