Although every ERP implementation is different, a number of characteristics and best practices are common to many successful implementations. Albert Segars has consulted with firms such as Bank of America and Apple on using technology and ERP systems to drive business improvements. As a University of North Carolina business school professor, he’s researched projects and documented and translated them into courses such as “Differentiation Through Technology and Business Innovation.”

Based on your research and experience, what are the most common traits among companies that have the most successful ERP implementations? And what are the common traits of the unsuccessful ones?

Ironically, companies that have a “history of success” find it much harder to implement ERP programs because there is no driving sense of urgency to make changes in process and technology. In contrast, companies that have less of a legacy can change faster. Companies need the right amount of process discipline to make ERP work. Too much process discipline invites firms to optimize processes locally thereby sub-optimizing a global process. Too little process discipline results in rising costs as consultants and integrators attempt to map and define process.

Companies that realize the 80/20 rule of process usually do well in ERP. According to that rule, 80 percent of business activity is driven by 20 percent of the processes. So it is best to focus ERP on those processes. The most critical trait is to realize that ERP is a program of business transformation, not an IT project. SAP and other technologies work very well when cast as an enabler of business transformation. When cast as the driver of business transformation these projects become troubled.

Do you see any correlation between the size of the company or industry and the success of the ERP project?

Yes, smaller firms are better at implementation because they have less complexity in process and can coordinate much more efficiently than larger firms. Organizationally, the silos or “cylinders of excellence” are not as well entrenched. Many large firms tend to break up ERP projects hoping to achieve the benefits of small firm implementation. However, these projects need to be integrated at some point, which is very expensive, so subdividing the ERP effort is not a path to success for larger firms.

Typically, companies with commodity-like products or fewer products, centralized managerial structures, and good process discipline have a great head start. Technical knowledge was not a noticeable advantage.

Which organization within the enterprise is responsible for selling the overall value of ERP to end users?

Definitely senior management. I cannot overstate this as a factor of ERP success. If senior management does not endorse or understand the ERP project and its goals, then it will be a runaway initiative. The key success measure of ERP is simplicity, meaning both fewer processes and less IT. When you are out to make the organization simpler, only senior management can set the tone. All other roads lead to frustration and expense. In our research, we were shocked at how little senior executives understood the focus and intent of ERP. They were passed on to IT management as another systems project.

What is the role of IT leadership?

The primary role of IT leadership is to shape and translate the business vision of the firm into a technical strategy. Importantly, this is a give and take proposition. The mistake that most firms make is not realizing how strategic a project like ERP can be to the firm and the important role IT has in that. They view it as a systems upgrade and do not consider how the firm can be remolded and “reset” by ERP technology. In these instances, the IT group is viewed as less strategic and charged with replacing old systems with ERP technology but the underlying processes and models of the firm remain unchanged. These projects have some upside but eventually turn very negative and are often stopped. 

If IT is viewed as a strategic partner in this transformation and IT leadership is involved in developing both adjustments to business processes as well as reshaping technology then the firm can realize the full benefits of the ERP investment. In return, IT leadership has to develop a business vision as well as a technological vision for the ERP project. Mistakes can be made on both sides of the aisle. And when business leaders and IT leaders view the project as an upgrade, this is the “perfect storm.”

In contrast, both parties can view the project as a “reset” of the organization in terms of process and technology. Approaching the project from this perspective yields incredible benefit. 

In the majority of successful ERP projects, IT leadership was defined in a business transformation rather than a technical role. These project teams were charged with finding new models of business through technology and innovation. The task was far greater and more strategic than just systems implementation. The people that filled these roles had technical and business knowledge, were adept in people skills, and were respected in the organization. They also drove very good results. In contrast, a technical organization, focused on systems implementation and insular, had little or no chance of driving “game changing” benefit for the firm.

During ERP implementations, how are unique processes within business units differentiated from those processes that should be rationalized across businesses? And what are some gray areas where decisions need to be made? 

This is the toughest part of an ERP implementation. The best way to approach the problem is to start work at the extremes. Define fundamental processes that can be shared and processes that are unique. Shared processes typically fall into buckets such as benefits, HR, financials, transportation, and procurement. Unique buckets may include recruitment, product design, and customer engagement. And if you keep the 80/20 rule in mind, you’ll only drive the ERP towards high-impact processes. Gray areas include things such as supplier management, billing/cash management, and product stewardship/tracking.

It gets complicated when business units want to have access to process and technology that addresses their suppliers and customers. In some instances, this is good. However, in many instances these relationships are neither unique nor strategic to this business unit. This is where objective metrics can help. That means reviewing financial metrics such as revenue, growth, and ROI as guides for determining the strategic nature of the business process.

What are the signs that an ERP implementation is becoming a “runaway” project?

The most dramatic sign we noticed was the inconsistency between IT metrics and business metrics. IT metrics such as number of installations, users, as well as operational systems and databases would all register positive. However, productivity measures and spending would all register negative. That indicates the firm is spending money and implementing systems but they are not realizing the improvements in business operations. This is a productivity paradox and foreshadows a looming financial disaster. Simple metrics such as process and system count can also foreshadow a runaway. If you are a year or two into implementation and still have not reduced system or process count, then you are riding a runaway train. In every project we studied these metrics were obvious — no one was caught by surprise. The problem is that no one wanted to believe the obvious.

What’s a more common mistake — pulling the plug on an ERP implementation too soon or not soon enough?

That’s a tough question. I think the more common mistake is allowing the project to go on too long without guidance. The most successful firms applied managerial intervention at key moments. They also understood the end game. Early in the projects they knew they were dealing with organizational design not IT. When resistance appeared in the organizations they did not allow the project to disappear into the silos. They expected tough conversations and scare tactics from the protectors of bad processes. They knew that ERP was a tool for creating a better organization, not the mechanism for doing it. Bad implementations drifted and changed form. Managers looked for short-term fixes that were based on IT rather than good process design. It is important to know how much change a firm can take and when to apply compliance and when to apply slack. Overall, it is a matter of knowing when to intervene and keeping everyone focused on the end game.