ERP Myths: Simple Truths that Management Needs to Know
A wealth of knowledge has accumulated about enterprise resource planning systems. However, many myths have also emerged—and little has been done to debunk them.
Careers and fortunes have been built and lost because of enterprise resource planning (ERP) systems, and in the process, some reliable advice has emerged on how best to address the challenges and capture the benefits of a standardized system. These teachings and best practices synthesize fact-based experiences from countless implementations and provide clear guidance on how to succeed (see sidebar: Ten ERP Best Practices).
However, as knowledge has grown so too have the ERP misconceptions, which often reflect trade-offs and constraints that applied in the early days of ERP systems or stem from fallacies perpetrated by overzealous software vendors and systems integrators. Many of these myths persist today and often dissuade potential purchasers of ERP systems, despite significant investments and innovative products.
The following are six ERP myths generally accepted as fact. We highlight the myth, offer a challenge (myth buster) to the generally accepted fact, and recommend actions that will help ensure a successful ERP implementation.
Myth 1: ERP Systems Are Expensive and Take a Long Time to Implement
ERP projects are notorious for their huge capital investment requirements and multi-year schedules. As experienced managers know, time and cost are inextricably linked in project delivery and are functions of scope, technical complexity, and resources. Yet time and again, companies set an overly ambitious scope, over-engineer the solution, or select the wrong systems integrator. Such missteps are often the result of attempts to make the business case more attractive, to get stakeholders on board by promising additional functionality, or simply to get started quickly. Consequently, the ERP investment grows, requires more resources, and takes longer to deliver.
One of the arguments for using an off-the-shelf ERP system instead of a homegrown one is that the software only requires configuration. Because software licensing costs about one tenth of the total implementation, most spending is in fees to a systems integrator to tailor the standard system to the company's requirements. Yet even an off-the-shelf system requires work, from aligning cross-functional and multi-stakeholder requirements, and managing the change in user roles and work activities, to migrating data, documenting the solution, and integrating the system into the existing technical environment. But the main task is to configure the "vanilla" system, and this requires strong product knowledge and implementation experience—skills typically sourced from a third-party specialist.
Myth buster: Configuring an ERP system takes only one to two days if clear and agreed-upon business requirements are in place.
From the setup of the enterprise structure in the system to establishing module-specific parameters in the ERP database tables, configuration can be swift—just one to two days—assuming specific business requirements have been articulated and agreement with all stakeholders has been reached (see figure 1). This timeline also assumes zero coding that otherwise needs months-long software development, and support of a skilled configuration consultant. Testing the system and training users is important and adds extra lead time, although these activities unfortunately often get economized as the project progresses.
Management and decision making can consume up to 30 percent of time and effort on a project, and although necessary, these activities can be streamlined. For example, we fast-tracked the ERP implementation at a leading European retailer by establishing a planning and design phase in which stakeholders made all essential policy, operating model, and deployment decisions in advance.
Documentation is not a feature of an agile implementation, and although essential for regulatory and support reasons, it often becomes an unnecessary burden and an end in itself. For example, one ERP implementation project produced more than 750 deliverables. Each had undergone rigorous approval processes, yet only 30 were either relevant or usable a year after implementation. Although such inefficiencies cannot be completely eliminated, they can be reduced by understanding where additional project time is incurred and then taking appropriate actions.
Don't just look at the usual cost-reduction methods such as negotiating with systems integrators to drop their rates or to offshore more resources. Instead, break down the underlying work structure. Challenge the scope and complexity of the first system release, and ask why certain bells and whistles are needed and what is sufficient to get the job done efficiently.
Also, it is wise to confirm the expertise of the systems integrator's resources, and align the commercial strategy to the delivery strategy as well as establish a lean management style that can make the right decisions quickly (and use prototypes to minimize documentation). Above all, be clear about what the system is supposed to do, and make sure everyone involved understands and agrees on the requirements.
Myth 2: ERP Projects Deliver Business Benefits
Two interrelated—and entirely misplaced—ideas are behind this myth: the first that ERP is a project, the second that an ERP system delivers benefits. ERP is not a one-time project. It is a platform for continuous improvement that requires a sustainable change in mindset, behaviors, and ways of working.
During an ERP project, teams from departments that seldom interact work together to define processes and resolve information dependencies. These diverse players establish a common language, break down functional silos, and create a culture that is responsive to change. When the system goes live, business processes are simplified and integrated, and islands of automation are all but gone. System users are part of a continual workflow up and down the supply chain, and enterprise-wide information is available to support analytical and fact-based decision making.
Unfortunately, the go-live phase is often followed by "go-leave." The project team is dissolved, and the stars of the show go back to their day jobs or leave the organization to seek new opportunities. When the period of vast insights, momentum, and change ends the ability to leverage the opportunities diminishes. The ERP system becomes just another IT application depreciating on the asset register.
Myth buster: Benefits are derived because of the ERP system, not from it.
An ERP investment is founded on business returns that outweigh implementation costs. Simply put, ERP does not print money—it only tells you where to find it.
ERP is a platform for future initiatives that improves business practices and reduces inefficiencies. At the same time, it is necessary to develop user capabilities to sustain the change and safeguard data quality. IT-related savings can accrue from a system replacement, whether from consolidating applications and lowering the total cost of ownership or rationalizing IT resources. Intangible benefits result from improved compliance and customer satisfaction. In most cases, however, IT housekeeping is not enough to warrant an ERP investment. This is where the business case becomes especially important to clarify and quantify sources of value in a structured way.
A rudimentary view of benefits only considers automation and simplification-related savings—that is, those that stem from reduced headcount, increased productivity, and cost savings. A more rigorous approach includes innovation-related savings from new ways of working, new user capabilities, and improved information management (see figure 2). One of our clients charted more than 100 change initiatives enabled by a new ERP system, accounting for nearly 70 percent of the overall ERP value case.
Focus on benefits that are ERP-enabled and not just inherent to the system, and detail these in project charters. Implement from a benefits standpoint using the business case—not just as a means to get a green light but also as a document that informs decisions on scope and release priorities. Assign benefits to owners, tie these benefits to performance objectives and incentives, and hold owners accountable for realizing them. And don't stop once the system is live. Form a smaller, high-caliber team to identify new opportunities for improving the business.
Myth 3: Smaller Business Units Need a Different ERP System
In an ideal world, a single corporate-wide ERP system supports all business units, geographies, and back-office functions. In the real world, however, companies are littered with multiple ERP systems that are specific to a location, business line, or even a business function. To make matters worse, these systems can include different versions of the same ERP suite or a mix of ERP systems from different vendors.
Modern ERP systems are designed to be versatile: They are built on industry best practices and can satisfy a broad spectrum of business requirements. Too often, the ideal is compromised for expediency and then paid for later. The reason: it is harder to build and deploy a single ERP template solution, more painful to secure and sustain the commitment of a diverse stakeholder community, and more challenging to harmonize processes and data standards.
In looking at the installed base, many industry analysts have wrongly concluded that a singular approach to ERP is impossible—it's rarely achieved so why not just settle for multiple ERP systems from the outset. For example, an ERP system used in a company's large business units is not viable for its smaller units because of barriers that require a different ERP solution. We often hear problems about affordability, specifically that recharged implementation costs and ERP running costs are prohibitive and that smaller sites did not get to provide input, which leads to a poor fit and gaps that take time, resources, and money to close. Many companies face additional hurdles, including fears about losing autonomy, complaints about inflexibility to suit the work environments of smaller sites, benefits that are not compelling enough to justify the necessary time and resources, and criticisms about smaller sites' needs getting low priority.
Myth buster: A single ERP solution can be implemented across an entire company—if management can endure a little short-term pain.
An argument can be made for not using a common ERP system on the grounds of scope, but this argument is shaky at best. Indeed, having more than one ERP system risks investing twice what is needed, duplicating support costs, causing more information fragmentation, and increasing IT complexity.
Assessing the needs of smaller country-based units usually reveals that their requirements are similar to the rest of the business. So exclusion is seldom justified. Still, specific challenges must be overcome, and smaller units will require special treatment to address restrictions in size and organizational significance. Companies can and do implement template ERP solutions across all their sites and reap enormous benefits in standardization and business integration. Tough decisions and governance are required—and some pain is involved—but the vision and associated benefits of a single enterprise template can be achieved.
Evaluate the merits of a one-size-fits-all approach against the needs of each business group. Not all business units operate in the same markets or have the same business processes, in which case a single ERP solution makes little sense. A differentiated ERP approach can also be appropriate in other circumstances, such as a stepping stone to an eventual enterprise-wide solution. An informed ERP strategy must be able to answer three questions:
- How similar are the organization's business practices, and to what extent should they be connected?
- Is a common ERP system the only way to realize potential organization-wide synergies?
- Can stakeholders agree to work together in the near term?
If a single ERP solution is appropriate, then proven techniques can overcome the challenges that smaller sites face (see figure 3).
Myth 4: An ERP System Enables Enterprise Resource Planning
Why has such an important enabler of business operations and such a successful software concept generated so much misunderstanding? To some extent, ERP has been a victim of its own success. There will always be advocates of best-of-breed applications who favor modular applications and claim ERP is "bloatware" run amok. Several high-profile implementation disasters have also tarnished the ERP image.
However, the main cause for these misconceptions is the name: Enterprise resource planning is a misnomer. IT analysts coined the term in the early 1990s, mistakenly seeing ERP as an offshoot of manufacturing resource planning (MRP). But ERP systems could hardly be more inaccurately named: The systems are not necessarily deployed throughout an entire enterprise, have little concept of resources, and feature only minimal planning functionality.
Myth buster: Other types of systems along with ERP can be necessary to address all business requirements.
As ERP vendors strengthened their core product, they developed complementary, function-specific solutions to sit alongside ERP. Today, leading ERP vendors also provide software for customer relationship management, business intelligence, supply chain planning, master data management, and product lifecycle management. These and other software integrate fully with the core ERP system but can run as standalones.
When selecting an ERP system, be clear about business requirements and use a selection process that considers functional fit and ease of integration with the company's legacy applications. Don't over-engineer the initial implementation with all the new modules; instead, devise a roadmap of future releases to introduce additional functionality and related systems over time. And never judge software by its label.
Myth 5: "Standardized Processes" Means One Way of Working
Standardization is one of the central reasons for implementing an ERP system: to establish common ways of working that permit comparability and interoperability. Standardization is a means to simplify processes, eliminate inefficiencies and unneeded variability, and reduce operating costs. Outputs become more consistent and repeatable and there are fewer errors. As a technology standard, ERP defines the enterprise architecture and data model, and for users, ERP provides a common language, work environment, and transferable skill set. Yet, the quest to standardize is often a major challenge for project teams, can alienate business stakeholders, and can result in an inappropriate solution or one that users fail to accept.
Myth buster: Standardization simply means fewer alternatives.
Standardization does not mean singularity. ERP systems are incredibly versatile and highly flexible—they do not constrain business processing. Order types, planning strategies, and number ranges are used in the same ERP solution to cater to a variety of business scenarios. What's particularly vital to standardization is knowing how much uniformity is needed and recognizing that most benefits are derived from process simplification.
Ultimately, the extent to which various process models are supported is a function of user capabilities. If users understand the business process and can fluidly switch to a different workflow, managers can minimize the impact on lead times, quality, and cost. However, if the goal of an ERP implementation is to outsource the back office, then new users will need more time to become proficient.
Take a pragmatic approach to standardization. Use the ERP implementation as an opportunity to simplify processes and move toward best practices. Take into account users' capabilities and the extent to which they can realistically tolerate variability. Avoid trying to cram everything into a singular model. Even if initial resistance is overcome, a breakdown could occur later on. Invest in a process to transfer knowledge to users and to improve their understanding of the content needed in their jobs. Incorporating ERP training into new-hire orientation programs will ensure that competency levels are embedded and sustained.
Myth 6: ERP is an IT System that Belongs in the IT Department
An ERP system once implemented is woven deeply into the fabric of business operations. As a packaged system, ERP minimizes the need for extensive technical input and elevates attention to what the application does, rather than its technology. ERP is frequently dismissed as just another IT system that gets relegated to the IT department, which shifts the focus from value creation to cost management.
Myth buster: ERP is a business asset that requires business ownership and input.
An ERP project should be run as a business initiative, sponsored by the business, and staffed with the organization's best people—and that philosophy should remain even after implementation. Successful organizations recognize ERP's potential and migrate the project into a more permanent entity—a center of excellence or competency center—to sustain the change and maximize the investment. These centers can become vehicles for educating the firm's future business leaders, arming them with a cross-functional, process-centric understanding of the company's operations. Simply put, dismissing ERP as an IT system and relegating it to the IT department prevents the insights, controls, and efficiencies that ERP offers.
Make ERP an integral part of the business, working in conjunction with the IT department or a third-party service provider. Establish a center of excellence or a competency center to manage the ERP system and oversee its evolution. Engage the larger business on improvement opportunities enabled by the system, and partner with them to ensure that the ERP system reflects ongoing business requirements.
Challenge Conventional Thinking
Few business applications have attracted as much management attention over the years as ERP systems, and the line between fact and fiction or myth and best practice can be difficult to discern. In today's mature ERP market, buyers must take control of their journey by specifying requirements, managing for value, and making ERP a platform for continuous improvement. Forward-thinking companies understand what it takes—and what it doesn't take—to implement an ERP system successfully. Those that challenge conventional thinking can gain immediate impact and long-term value.
The authors wish to thank Hannan Ikram for his help in writing this paper.