In the wake of the past year’s usual crop of failed ERP implementations, I’ve read a couple of blogs that bemoan the fact that ERP 
In the wake of the past year’s usual crop of failed ERP implementations, I’ve read a couple of blogs that bemoan the fact that ERP
That may take some doing. In the current environment, several issues impede users in implementing changes to their ERP systems; some are easy to fix, but others are more intractable. Starting with the easier side, we note that smartphones and tablets have simplified some user interactions with core ERP functions. These mobile technologies enable the use of lightweight applications to automate edge processes that manage, for instance, travel and entertainment expenses, customer service or aspects of workforce management such as scheduling. However, examples don’t point to a future where an ERP system is cobbled together from a constellation of loosely coupled apps. Edge processes are those that can stand alone, have discrete boundaries and interact with a core ERP system by exchanging easily defined data such as amounts, status (for instance, where the individual is in a process) and dimensions (such as time, territory and product family). These applications are relatively easy to construct and use because the heavy lifting has already been done in designing and configuring the ERP system itself.
Trying to equate a smartphone app to a full-fledged ERP system is like comparing a paper airplane or one of those new hobby drones to a jetliner. The former is inexpensive and simple to operate, while by design the latter is not. A jetliner faces the real-world constraint that it must carry hundreds of people safely while handling the stresses of near-sonic flight and withstanding thousands of cycles of substantial pressure and thermal differentials. To be able to do this with utter reliability and safety requires a complex set of redundant systems. This means a passenger jet will never be simple to operate and inexpensive to create. In this analogy, that’s the intractable issue. Yet it’s noteworthy that today’s commercial jetliner is more reliable, easier to operate and less difficult and costly to maintain than the first generation of aircraft that emerged half a century ago. ERP vendors ought to be modernizing their products in a similar fashion.
The primary barrier to making ERP software easy to implement is the inherent complexity of the business processes the systems manage. ERP systems are designed to handle a diverse set of procedures that might span multiple business units in multiple industries in multiple locations and jurisdictions. In a word, its operation is business-critical. But it’s problematic that the final system design is often the result of multiple trade-offs that best reflect the needs of a variety of competing interests and priorities. These options must be considered, and then agreement must be reached on the mass of details that are baked into the final design. In this complicated process, mistakes are not uncommon, especially by inexperienced or incompetent consultants. Even using the best resources, it’s not hard to make mistakes. One of my favorite examples of how the provisioning of an ERP system can go wrong was the inventory management portion of an ERP system at an airline’s maintenance depot. The new system – designed by accountants and auditors – followed a standard, “common sense” process of requiring the defective part to be checked in before a new one could be checked out. However, the system it replaced allowed pilots to radio ahead when some piece of equipment or component failed so that replacement could start as soon as the plane arrived at the gate. From the perspective of a pilot or maintenance personnel, this approach was sensible. But when the airline changed over to the new system with a process designed for inventory control, very expensive aircraft and many grumpy passengers were left waiting at the gate while the old part was shuttled to the inventory cage and the replacement part was found and reissued. The lesson here is that different types of businesses have their own requirements of varying complexity. For ERP, it’s often the little stuff that trips up an implementation. Even within a given type of business, a company’s unique strategies and strengths may lead it to operate in a different manner. So the various competing interests within a company will always need to resolve trade-offs in implementing and operating a system, and ERP systems always will have a high level of complexity.
Still, not all of the complexity of ERP systems is necessary, and dealing with changes and adding new capabilities can be simplified. As the business software market, including ERP, increasingly moves to the cloud, a major challenge facing software vendors is designing their applications for maximum configurability. By this I don’t mean being able to select modules from a menu, but having the ability for only moderately trained line-of-business users to make more granular adjustments to process flow and data structures in a multitenant setting. This lack of flexibility is an important barrier inhibiting adoption of cloud-based ERP. Although user organizations that are better able to adapt to an as-is version of an ERP system are more likely to take the cloud-based option, this covers only some of the potential market. The cloud ERP vendors that offer greater flexibility in allowing individual customers to modify their implementation to suit their specific needs will have a competitive advantage.
An ERP system that can be more easily configured by end users would also confer a competitive advantage for on-premises deployments. Today, almost all ERP software aimed at large organizations, and many implementations designed for midsize companies, either have versions preconfigured for a specific industry (such as aerospace or automotive) or have evolved for use by some specific industry (beverages) or even a subset of an industry (beer distribution). This cuts down on the amount of work – and therefore the cost – required to set up a specific customer’s system.
This “verticalization” is necessary but insufficient. After an ERP system is installed, user organizations need to be able to simplify the process of making modifications. The elements of an ERP system that are inherently more standalone are the easiest to shift to a more self-service model. The hardest part for vendors will be in changing their architecture and design to make it easier (though probably never easy) for organizations to make modifications on their own or with limited assistance from consultants. Until multitenant cloud deployment came along, and with it the need to enable greater flexibility, vendors had little incentive to work on this issue.
The inability to easily make changes to an ERP system inhibits change and innovation in corporations. This is ironic, since one of the factors driving corporations to buy the first ERP systems in the 1990s was their desire to do business process re-engineering, a useful business strategy fad of the time. Today, few companies do anything more than tinker around the edges of their processes unless they are implementing a new ERP system and there is an urgent need to do so and is why it is part of my research agenda for 2014.