Introduction

In the life of almost any growing enterprise, there comes a point in time when the systems and processes that served it since inception become insufficient. Early-stage businesses tend to grow up with basic and low-cost software systems and a heavy reliance upon the efforts and abilities of a few key administrative employees. However, at some point, the software can’t keep up with the business, and the trusted employees become overtaxed, causing a capability gap where the enterprise needs to take steps to meet business needs. If action isn’t taken to improve processes, this capability gap will expand and hinder the business’ ability to grow and compete.

For most enterprises at this key inflection point, a choice is made to implement robust Enterprise Resource Planning (ERP) software, which integrates all areas of the business and helps to overcome the aforementioned capability gap. This is a hugely consequential decision in the life of a business and must be approached with an uninterrupted focus on risk management. While ERP may not be sexy, it is of utmost importance for growing businesses and should not be ignored.

As a long-time financial controller and, more recently, a general manager of a business, I’ve worked on several implementations, using three different software packages at both the whole-system and the module level. It is clear that modern businesses need ERP, and I’m definitely in favor of leveraging it. However, it’s of paramount importance that leaders are focused on precise execution throughout the process. Since every outcome of a software implementation project will affect the business going forward, this article provides enterprise leaders with the benefits and risks of ERP as well as a detailed step-by-step implementation guide.

What Is ERP and Why Use It?

What Is ERP?

ERP refers to a set of systems that ties together all of the business processes of the enterprise and enables the flow of data between processes and functions. It helps to standardize, streamline, and integrate processes across HR, finance, distribution, supply chain—integrating a company’s varying facets into one comprehensive system. The underlying software uses an integrated platform and common data definitions. Today, ERP systems even provide business intelligence, sales force automation, and marketing automation. In fact, most eCommerce websites are now tightly linked to some form of ERP back-end. An effective ERP implementation requires not just the right software, but also thorough documentation, buy-in from key stakeholders, communication with vendors, and employee training.

While there isn’t a standard timeframe for an ERP implementation, it can take anywhere between six months and two years. Influences on the timeline vary by company but can include company size, transfer of data from legacy systems, and the complexity of the system being installed. Unlike many strategic decisions that can later be pivoted away from, it’s unusual for an enterprise to go through more than one ERP implementation.

What Are the Benefits of ERP?

ERP can provide everything from increased productivity and data security to scalability and cost savings, with the major reasons indicated below. When business processes and data are automated and centralized, employees will find that they have less manual work, gain easier reporting capabilities, and can proactively manage overall operations with far fewer disruptions.

A notable software implementation that I led was the addition of a bolt-on accounts payable (AP) automation module in an Oracle environment. The module was separate from the ERP system but used the same databases and was fully integrated. I was the new controller of a $500 million group of companies, and the existing system was archaic. I was shocked to find that the accounts payable team was shuffling literal paper around 20 different offices, checking for approval initials on paper, making 100% of payments on physical checks, and then having me hand-sign every check. Paper invoices were also stored in file boxes for seven years or more.

Overall, it was a clean implementation: We identified a clear opportunity to improve, decided to aggressively pursue it with the best available software solution, and then laid the early groundwork to manage risk by documenting our processes thoroughly and by seeking management buy-in. The outcomes included drastically reduced transaction cost and an improved ability to investigate the nature of expenses. I want to emphasize that buy-in was important. Though I was new to the organization and felt the accounting team should determine their own policy, the CFO rightfully made me sell the general managers of each constituent business on the implementation. We executed with the support of most key business leaders, particularly the ones who were not co-located with the accounting team. Eventually, that AP software, which in 2014 was only in scope for the US and Canada (65% of the total business), was later expanded globally across the company.

Now, let’s dive into the steps of ERP implementation.

Step 1 – Evaluating Your Readiness for ERP Implementation

As previously mentioned, sometimes an enterprise is at a clear inflection point where it’s obvious that ERP is necessary:

• The enterprise is experiencing rapid growth in revenue, inventory, or diversity of the product line. Generally, growth drives increased business complexity over time, and it can be a good idea to get ahead of a potential downstream problem.
• Legacy systems (especially ones which are very Excel- or Access-reliant) are collapsing under the weight of an increasingly complex business. If you didn’t implement appropriate systems while growth was occurring, you can reach a point where the business capability of your legacy system breaks down.
• The enterprise needs to demonstrate more robust processes, internal controls, or financial reporting capability to gain access to bank financing. Sometimes, banks will make the professionalization of the enterprise’s finance function a condition for new or increased borrowing. This can include the adoption of new systems as well as contracting for assurance services.
• The enterprise has added additional locations beyond its founding site. Having more than one location can make real-time data management very difficult, and ERP systems help a great deal with that.
• There are problems with the existing systems being used. Software vendors generally stop supporting or updating an older business system at some point, which can lead to functionality and security problems.

However, ERP implementation is a fundamentally risky endeavor. A complete failure can cripple a business for a lengthy period of time while a partial failure can create inefficiencies that are difficult to remedy. The best way I can explain the enormity of the ERP decision is that it’s almost certainly going to be a permanent fixture for the company. The monetary investment is typically quite high, though it can range, generally in line with the largest capital expenditures that a business has made to date. For a small company that moves out of Excel spreadsheets and implements Microsoft Dynamics GP, maybe it’s $100,000. For a bigger company, it can cost several million dollars. In addition, it is a major investment from the employees, in terms of emotional toll and expenditure of extra effort.

STEP 1A: IDENTIFY WHAT YOU HAVE TO GAIN

Think in terms of risk management and soberly identify what you hope to gain from an ERP implementation. Measure it against the cost of a failed implementation. It’s possible that the right answer is to stick with your current processes and to defer the implementation of ERP. There are times when lower tech makes sense, and the gain associated with new software doesn’t justify the cost. For example, I once chose instead to utilize a freelance programmer based internationally to automate an existing, tedious expense processing method. Fortunately, this effort only yielded a one-time charge of $50, including a $20 tip—instead of a lengthy and expensive system upgrade.

If you do decide on an ERP implementation, I recommend that you answer the following questions in writing:

• What does the business look like 90 days post-launch?
• What business problems would be solved as a result of the implementation?

Take those answers and use them to explicitly craft the goals of the implementation project. There will be times during the process where you’ll be told that an assumption needs to be changed or that a compromise needs to be made. By having a clear view of the requirements of the project, you’ll be much less likely to make a compromise that causes significant damage.

STEP 1B: UNDERSTAND WHAT FAILURE MIGHT LOOK LIKE

Once you’ve clearly articulated why you’re implementing ERP, and you’ve determined that doing so is worth the inherent risks, it’s crucial that you choose the right ERP tool and that you implement it successfully. As many as 75% of ERP implementations fail to fully meet their goals, and we’re going to do everything we can to improve the odds of success through the use of best practices.

Step 2 – Document Business Processes

Once you’ve decided to pursue ERP, the most important task is ensuring that your business processes are well-documented and that it’s compiled in one place. This includes the obvious major processes like procure-to-pay and order-to-cash, but should also cover even the most granular recurring activities such as employee onboarding or approval of timecards. You must do this before you take any other steps because every undocumented process becomes an assumption, and every assumption carries risk. In addition, this documentation provides leadership with a clear view of the scope, complexity, and minimum requirements of the project.

A key element of your documentation project is the explicit identification of the information stakeholders at each step of each business process. Implementations fail at the lowest levels of companies when processes don’t fully translate or when the executive leadership team doesn’t consider downstream effects. I’ve seen this type of failure countless times. In my most recent implementation, the customer service team emphasized that there was a key customer preference field in the legacy system that was vital to providing our customary high level of service. However, the IT project manager incorrectly assumed that the field was non-essential, dropping the requirement. This directly led to multiple customer service problems by removing key functionality from the quality assurance process.

Most early-stage businesses don’t have adequate documentation, and it’s advisable to seek outside help from professional CPAs or consultants to get this information together. It’s likely that your internal team lacks the time and the capability do it, especially since lean and agile private businesses view the exercise as antithetical to agility.

Providing Documentation to Your Value-added Reseller (VAR)

In addition, you need to clearly spell out everything that the business does because you’re going to pass that information to your value-added reseller (VAR), who manages the technical side of the implementation and helps you customize your software. The more information you can give a VAR, the better job they’ll do. If you don’t give a VAR much information, they’ll make assumptions to fill the gap in knowledge. These assumptions could be based on their own experiences or on a brief conversation with an employee who doesn’t have the whole picture. VARs have tight timelines and it’s imperative for them that they get resources in and out of jobs. And, since most companies typically only implement ERP once, they aren’t necessarily motivated by repeat business.

Think of the risk like this: a VAR who only understands 30% of your business is likely to deliver a solution that meets 30% of your needs. Through the production of complete and accurate documentation before finalizing the contract with a VAR, you minimize this risk. This occurs in several important ways:

• The VAR is left to make fewer assumptions.
• Key process requirements are planned for and executed throughout the process.
• Your internal resources feel heard, and their input is considered.
• You can be very precise in contracting with the VAR.

In one of my more unfortunate experiences, the business team failed to specify implementation requirements for a tightly linked ERP/eCommerce solution. We received a website that was basically unusable for our customers. The VAR’s assumption was that the look and feel of our customer-facing site didn’t matter as long as it was tightly linked to the ERP system. At the business level, we didn’t see the site until two weeks after it was supposed to go live. To correct for this, we spent months doing enhancement work and tens of thousands of dollars in additional cost. Don’t ever let the VAR assume.

Step 3 – Identify the VAR and the Software Solution You’ll Implement

Selecting the right software package is crucial to ERP success, yet it’s one of the more fraught parts of the process. It’s not easy to do research because it’s in the best interest of VARs to keep things opaque. Thus, I recommend turning your robust process documentation into a concise description of the specific requirements and asking VARs to speak specifically to those requirements in their presentations. Again, the more specific you are, the more specific the VAR will be.

I also suggest asking VARs what other similar companies use the software that they sell, and which ones the VAR has worked with. You should be listening for indications that the VAR understands your business, and has worked with similar requirements before. If the VAR tells you that a dissimilar business is similar, be skeptical.

Another key consideration is whether there something non-standard about your business model that will necessitate system customization. If so, is that nonstandard feature really necessary? A lot of suboptimal processes and practices tend to take hold in the early years of a small to midsize businesses. Think of customization in your ERP system as built-in risk and cost. That’s because, with every upgrade of the larger system, there’s likely to be one-off updates needed in the customized part of the software. Use this implementation as a moment to rethink, improve, and simplify existing processes.

Step 4 – Negotiate the Contract with the VAR

You can save yourself a lot of pain and dissatisfaction by negotiating the contract well. Because you invested in the documentation project, you can clearly articulate what “successful completion” looks like. I highly recommend that you explicitly define what success looks like in the contract, at least as an addendum—if it adds 50 pages with multiple flowcharts and diagrams, so be it. Typically, the VAR wants to keep the contracted requirements as vague as possible, and they want to bill you on an hourly basis. They also want to be the ones who declare completion of the process and are happy to charge additional fees to do the work that should have been done from the start. Try to avoid the VAR’s boilerplate agreement, and get your own counsel involved. An optimal outcome from your end would be a firm-fixed-price contract, with the final sign-off resting with you. But if a VAR is inflexible on terms, try to find a different provider of the same software that is more amenable to negotiation.

Step 5 – Define the Internal Strategy Clearly and Seek Broad Buy-in

At this point, a key project team should be formed to help with the rollout of the software. The team should include an executive sponsor and an internal project manager. The executive sponsor should be very senior, should maintain high-level oversight and responsibility for the project goals, and should articulate the overall strategy for the day-to-day team to execute. The internal project manager should be a person with demonstrated project management skills. Project management can be difficult because team members are generally drawn from a number of functional areas. The project manager typically lacks traditional supervisory authority over any of the people they are managing. An effective project manager is able to overcome this challenge and delivers on the goals of the project. A person who is certified as a Project Management Professional (PMP) by the Project Management Institute is likely to possess the necessary skills.

Even above the level of the executive sponsor, there must be a commitment to the implementation from the highest ranks in the organization. If a president or CEO is indifferent to the project or even noticeably disengaged, it signals to others in the organization that resistance may be acceptable and can create risk.

For example, in a financial controller position I held, I pushed for the implementation of automated accounts payable and gained consensus internal approval for it. As we rolled out the software and showed middle managers how to approve invoices, several refused to participate. The CEO declined to get involved and provide direction to these intransigent managers, and the result was that approval was delegated to non-managerial employees, who almost certainly lacked the knowledge or perspective to adequately evaluate the expenses to be paid.

The executive sponsor and project manager need to have clear goals and timelines to manage. You should aim for the slowest time of year in a seasonal business, and make the initial go-live date fall at the beginning of that period. The overall project is highly likely to run longer than original expectations, and you don’t want to be caught having to launch at a bad time of your year.

Step 6 – Focus on Key Priorities Before Go-live

The final time where you can minimize risk is in the time period just prior to go-live. Three crucial activities happen at this time (testing, training, and data version). Ensure that each is given sufficient attention.

Testing

The linkages between modules and systems need to be tested at length to ensure that data is created and transferred as intended. For example, when an invoice is generated to a customer on terms, you want to make sure that the Accounts Receivable module causes the correct entries to be made in the General Ledger module. It’s worthwhile to run parallel transactions in the legacy system, as well as in the new ERP solution, to ensure that equivalent functionality is in place. Be thorough with testing, and review the results in detail. If any part of the system isn’t working as planned, don’t commit to going live.

A classic case of a failed ERP was Hershey, which went live with an SAP solution, and two other bolt-on systems, beginning in 1996. The VAR recommended a 48-month process, but Hershey insisted on going live in 30 months, to complete the transition before Y2K. Implementing one ERP system is complicated enough, but to include a separate supply chain solution and a separate customer relationship management (CRM) solution all at once was also a sign of hubris. Hershey made the decision to sacrifice testing time to hit their ill-advised deadline. Their implementation was a disaster; Hershey was unable to fulfill customer orders during their peak season, and lost $100 million in sales in 1999 as a result.

Training

Some training will occur simultaneously with testing, as a key user or two from each functional area will generally participate. It’s a mistake, though, to rely upon those testers to be the trainers of other workers in their areas. A well-planned training program needs to be conducted, with sufficient time allotted to allow all team members to learn. Understand that different people will have different learning styles. Typically, people learn best when they can relate the new system to old processes. Often, the activities are the same thing by a different name.

Don’t have blind faith that people are well-trained enough. More often than not, the first time that the VAR tells you the business is ready to go live, it isn’t. Also, don’t be surprised if a more robust system requires more clicks and time on task than the legacy systems. Processes may take longer and may require more people to execute them on a daily basis. It would be great if you could be assured that you were always buying labor cost savings with ERP, but sometimes, you’re not. You’re actually trading somewhat higher labor costs for improved capabilities and/or internal controls. For many businesses, that’s a trade that’s worthwhile, but expect that this is a possibility.

Data Conversion

There’s a process that happens toward the end of every ERP implementation called data conversion that sounds relatively straightforward and benign. It is usually much more problematic than expected, though, and it is a common cause of delays and post-launch problems. Data conversion is largely manual and tedious work, and it usually requires work from functional resources, who are most familiar with the nature of the data. Small mistakes can create large problems, once data is migrated, so it’s best to ensure that you have a robust approach to quality assurance.

In one implementation, we relied upon the internal IT team to take granular inventory data from the legacy system and map it correctly to equivalent fields in the newly-implemented ERP solution. As data was manipulated in a spreadsheet, elements of it became misaligned between rows, and completely incorrect attributes were assigned to thousands of specific inventory items. This caused day-to-day fulfillment inefficiencies as inventory was ordered, and an ongoing manual clean-up project that took six months to complete.

An important part of data conversion is data cleansing. Legacy systems have a way of accumulating useless data over time that’s not worth bringing into the new system environment. Some examples of this are uncompleted price quotes and information about obsolete products.

The other key part of the process is data translation. There are key pieces of information in the legacy system that have to be mapped to equivalent fields in the new system. A lot of times, the out-of-the-box alignment of the two systems isn’t perfect or simple. A good ERP system will have user-defined fields that will allow for necessary data capture and migration.

Quick Word of Warning

As upstream parts of the process take longer than expected, the total process usually becomes delayed. In most implementations, there is a temptation for the later-stage activities to be compressed. The VAR, which typically needs its people to move on to their next project, will often add pressure to rush. Don’t give in to this temptation and/or pressure. You should start with the mentality that the timeframe for testing, training, and data conversion cannot be shortened for any reason, and that it can be lengthened if needed.

By implication, this means that the go-live date can be freely extended, as necessary. The planned go-live date should also never be tied to any other key date, like the end of a quarter or fiscal year. Doing so is inviting massive risk. The best thing a CFO or other executive leader can do to minimize risk in an ERP implementation is to maintain discipline over the timeline and ensure that go-live occurs only when there is a lot of comfort that the people and the software are ready.

Step 7 – Go Live with the New Software

When it’s time to go live, it is best to communicate to the entire organization that everybody needs to be maximally flexible and available. I recommend letting everybody involved know that they’ll need to be available to work a lot of overtime during the first days, including the first weekend. No matter how good the preparation is, there will be some unexpected challenges.

In my most recent implementation (for an acquired business unit within a larger company), we discovered in mid-launch that item quantities could only go to two decimal places, because of a global system setting that had been set 20 years earlier. This forced us to change our pricing and unit-of-measure structure on the fly because we realized that we couldn’t accurately sell or track an ounce (0.0625 pounds) of our bulk product. This was a small detail that set us back several days.

You should prioritize the accurate and immediate loading of your beginning balance sheet at the cut-over date. There are many ways this can be challenging, because of the detail required to accurately and completely track the assets and liabilities in subsidiary ledgers. Inventory and accounts receivable tend to be the riskiest accounts.

Data uploads should be reviewed in granular detail because errors at this stage can be very difficult and time-consuming to correct.

Once you’re operating in the new ERP system, an enhanced ongoing support capability needs to be maintained at least for the first couple of months. It is appropriate to hold regular calls, where outstanding issues are discussed and updated.

Parting Thoughts

While there are many benefits to be gained from using an ERP system, its implementation is admittedly risky. However, by employing best practices and by managing the process well, the risks can be minimized. The takeaway from this post should not be a collection of reasons not to implement ERP, but rather, some ideas for improving the chances of success.

According to authors Howard Smith and Peter Fingar, “Not all process-integration problems are technical and not all about IT. Integrating computer systems is not the same as integrating the business.”