In-Depth

The Real ERP Fast Track: Forget ROI and Go Vanilla!

• 05/01/2000

ERP software packages are as popular as ever, but you wouldn’t know it, judging by some of the major vendors’ current stock prices and the grumblings of organizations that have implemented the systems.

What are the "frustration generators" for ERP customers? Some CIOs would argue that there are three interrelated issues:

• Justifying the initial purchase with return on investment (ROI)

• Struggling to implement the product itself

• Trying again to find the ROI after the implementation

As a result, some ERP buyers are now forgoing up-front ROI analysis, implementing the "vanilla" package, and simply trusting in the software to cure their business ills. And, guess what? It seems to be working! So, how can you make this contrary purchasing and implementation strategy work for you?

ERP software is designed to model and automate the processes that exist within the company. The goal of ERP vendors is to make you see that the real return is through integrating information across the company (and as a result, creating tight integration of business units themselves) while eliminating existing complex, expensive links between systems that were never meant to talk to each other. The software is designed to be a mirror image of your business processes, so it is easier to get your processes aligned with the software, not the other way around.

While in the early part of this decade, SAP had manufacturing companies scrambling to gain a competitive advantage, and acronyms like BPR, MPR and JIT ruled the boardrooms. ERP applications for the majority of companies have become an easy sell in recent years for two major reasons: Y2K compliance and the general trend toward client-server applications.

If non-manufacturing companies stopped their cost-justification right there, most would save time and consulting dollars by focusing on implementing the product, rather than retro-fitting the ROI tool to fit their specific needs. ROI generally does not paint an accurate picture of the real benefits of ERP. The difficulty becomes evident when trying to run the math on less revenue-generating functions, such as finance and human resources.

Mike Wright, former CIO for Lincoln Financial Group saw this firsthand as he attempted to purchase the Human Resources suite last year from PeopleSoft. "Decisions for major purchases like ERP packages are really based on timing – that is, how well is the company doing at the time, and is this purchase a ‘must have’ or a ‘nice to have?’ HR for us was not a ‘must have,’ except for those portions that were directly affected by Y2K."

But what Wright brings up is the paradox of ERP implementation: While the cost-benefit of ERP software in manufacturing is easily quantifiable, revenue-generation is not going to be the end result in the retail and service industries or in "support" functions, like HR and finance. While traditional ERP packages originated from the manufacturing world, more and more vendors have focused their efforts on these "support" functions.

How do you convince the steering committee to buy into something that does not produce revenue and may show little tangible cost savings? Emphasize the intangibles:

• A more user-friendly system

• Improved functionality and reporting capabilities

• Drilling down between integrated parts of your business

• Empowering end user computing (EUC) coupled with a reduction in IT effort

• And, maybe most importantly – ERP systems are necessary to compete in today’s business climate!

Professor Glen Larsen of Indiana University’s Kelly School of Business suggests, "Whether or not firms can justify ERP based on expected revenue increases is a common problem. Firms face much the same question when they decide on purchasing or upgrading PCs. In general, however, creating efficiencies and the ability to compete – or even stay in business – are the real points to consider."

Clearly, if a company is small and plans to stay small, then an ERP package is likely not for them. However, as John Nicholson of PRG LLC, a fast-growing multi-media production company, stated in a recent discussion about his Oracle implementation, "The ROI would be very hard to calculate, but given our recent acquisition mode, without the standardization of processes and procedures that an ERP requires, as well as the opportunity to look at ‘best practices,’ we would not be able to function [without our ERP system]."

Steve Schneider, CFO for The Finish Line Inc., concurs. "We did not run an ROI. Our existing vendor dropping support of the product we were using forced our purchase of PeopleSoft, but we are also adding over 50 stores this year. We knew we needed a new system to support the level of growth we continue to anticipate."

The market leaders have designed their software to accomplish two major tasks:

1. To be as generic as possible to "fit" a wide variety of companies’ needs, and

2. To include as many user-friendly and efficient processes as possible to make their product more marketable than the others.

The result: software with a breadth of built-in "best practices" – so why not start there! Rather than spending the time redesigning everything you do and then forcing it into an already powerful packaged application through months of customization, focus on letting the software itself guide your process redesign.

The idea of keeping an implementation "vanilla" might even be the key to getting the initial purchase approved. Professor Carol V. Brown of Indiana University’s Kelly School of Business offers an interesting perspective of why companies may be so sensitive when it comes to ERP purchases: "ERP is very quickly associated with reengineering, and BPR still has many leaders leery due to its past failures. In other firms, business reengineering projects failed because the IS organization couldn’t write the integrated systems to support implementing the new processes. ERP systems offer these companies another way to achieve their reengineering objectives."

Professor Brown suggests looking at the scope of the project before making decisions on reengineering: "Scope is important. When you read the headlines about ERP projects failing, you may lose sight of what these companies were attempting. When you get outside of the value-chain of manufacturing and you look at the support functions like finance and HR, these areas are not direct contributors to the bottom line. In these situations, I would suggest getting the package in and then working to continuously improve it. For implementations involving value-chain modules, a ‘good enough’ reengineering approach may work best for the initial implementation."

Do you need other reasons to stay vanilla – other than drastically reducing your implementation time, that is? Fewer implementation hours and less reengineering results in reductions in training time and costs, service provider and consulting fees, the level of customization and the ongoing support costs.

Ken DeWitt, Vice President of Corporate IS for Sears Roebuck and Co., mentioned in a recent interview: "You really need to minimize customization. Don’t try to turn the ERP system into something unique for your company, but change processes to work around the ERP system." Remember that the more you change, the more difficult and expensive the support will be for the package over time, ultimately reducing your ROI.

Schneider decided to stick with the KISS (Keep It Simple, Stupid) principle in The Finish Line’s implementation of PeopleSoft’s financial software: "We had heard the horror stories of two- and three-year projects and the out-of-control costs associated with ERP implementations. Our goal was to get our existing structure into their [PeopleSoft’s] ‘basic box.’ We now have people familiar with the new system and we can begin making improvements." The result was a general ledger and payables implementation in less than five months – on time and within budget.

Let’s say you got budget approval on your ERP project, you implemented the vanilla package and you successfully met your project time line, and now you have a full six months "live" under your belt. Your CEO and CFO are now trying to find out why the bills are still coming in, yet the "efficiencies" that you were promised by the vendor do not seem to be coming to fruition – that is, your new system does not seem to have had a significant positive effect on the bottom line.

Most of these efficiencies are difficult to measure in the short term. It may take a two- to three-year horizon to really see them fall to the bottom line:

• User-satisfaction

• Improved functionality

• Analytical and reporting tools for end-user computing

• Improved workflow design and approval levels

• Greater security and control

• Hierarchical relationships for data for easier change management

• User access to accurate data from valid sources

• Ad hoc online analytical tools and inquiries

• Acquisitions are easily attainable

In the meantime, can you still work on redesigning processes and procedures after your new package is in? Sure! How can you justify spending more money when your original investment is showing nominal gains, or none at all? Look at all of the money and time you saved resisting the temptation to redesign all of your processes, prior to knowing the system and how your existing structure fits into it.

Some CIOs are suggesting they have seen a vanilla implementation cost one-third of the cost of a full-blown redesign. Would it cost more to do some redesign in post-implementation? The Finish Line’s Schneider, suggests "maybe … but, I am not fully convinced … and the risk we avoided would make it worth it, anyway."

Here’s some good news: It does not take a team of 20 consultants to find areas for improvement in your processes! As you implemented the software, there should have been some very natural opportunities for improvement staring your implementers in the face – so make them document, document, document. And now, guess what? With a little time on the new system, your users should know their business structure, processes and now, the software.

It makes a lot more sense for ideas to begin flowing on structure and process improvement when everyone is on the same page. Before implementation, the issue is complicated by the fact that much of the software’s capability will never be used. This fact gets in the way when analyzing ERP’s fit within the organization. By implementing the core functionality first, only those processes critical to running your business are used, and from that baseline, other useful features naturally become evident in post-implementation.

As for the implementation team, documented opportunities should have been weighed for their advantages and disadvantages for adding to the initial implementation or saved for your redesign phase. The majority of these "tweaks" add up to significant savings over time. Those tweaks that have to wait are probably best implemented separately, anyway, leading to reduced change management when your new system goes live.

Use ROI as it relates to ERP and IT projects in general, as a means to an end, not as the end itself. There are too many good implementations that have successfully and strategically moved companies in the right direction without showing amazing returns. Mike Howard may sum it up best: "I have no idea what our ROI is. I have no idea even what the ‘I’ is … it has been so long. But, I do know my gut feeling is that we would be in a worse situation now if we had not invested in ERP."

Reengineering your processes prior to implementing the software is the step most likely to put your ERP project plan behind schedule, at best – and at worst, making it susceptible to failure.

Business leaders are now realizing that investing in ERP has simply become a cost of doing business. The key is to make the transition as painless, timely and cost-effective as possible. Implementing a vanilla package is quickly becoming the popular method of choice.

About the Author: Vince Vickers is a Senior Manager for ONEX’s Inc.’s Consulting Solutions practice (Indianapolis). He can be reached at vvickers@onexinc.com.