ERP Implementation Strategies | Top four components of a successful plan

At a high level, the most common ERP implementation strategies are either a “big bang” or a phased implementation approach. Whichever overall strategy you choose, it’s important to consider other critical components of your ERP implementation planning. Many factors have to be considered when implementing ERP – that is part of the reason these projects are so complex. If we had to narrow it down to the top four critical components of a successful implementation plan they would be:

• Making the business case
• Building the right project team
• Planning for transitions and cutovers
• Using realistic timelines

When we talk about business case, we refer to the driving forces that are trying to be achieved when doing an ERP implementation. It’s important that everybody within the organization and the project team understands those business cases. And by business case, we talk about the rationale and some of the benefits expected to be achieved. Many times, project managers and project executives will put together a project charter at the beginning of a project detailing all the benefits and cost savings that will be achieved with the project. But then as the project progresses through the different phases, many times, those goals, opportunities, or cost savings are not realized. It’s important that as the project progresses though the different phases, a keen eye is kept on what those business cases are and ensure the project stays on track to achieve those when completed.

A good example of this is cost savings due to workforce reduction in your plants. Many times, there’s automation that’s done in a plant in order to reduce head counts and to reduce labor charges. But in the opposite, many times, that workforce reduction causes a workforce increase in other areas. It’s good to ensure, and as you go through each phase of the project, that you truly are going to be realizing some of those business case benefits that you detailed out in the charter.

Part of the initial setup for the business case is to understand where those benefits are going to be across the entire organization. The impetus or where the idea to get a new ERP comes from could be from several functional areas within an organization. It could come from finance; it could come from operations. But really, the benefits have a wide-ranging scope according to different functional groups. The idea is to look at it as a whole and not to focus benefits on any one functional group at the expense of others. There’s a natural give-and-take. There’s going to be some work that is increased in some areas. But as a whole, the idea is to ensure that your organization understands at different levels why this is taking place, why there’s going to be a new technology implemented, and then to track those throughout the life of the implementation.

PREPARING FOR AN ERP IMPLEMENTATION? | DOWNLOAD YOUR COMPREHENSIVE SUCCESS GUIDE

There is often a misconception that an ERP implementation project is going to be a minor disruption to normal work for a project team. It is underestimated, the amount of work that not only consultants undertake (if you bring in consultants to help with the implementation) but, also the involvement of the internal project team. From a business user standpoint, ensuring there is proper bandwidth to complete the project is essential. If you plan on hiring third-party consultants or will need any specialized resources, before you embark on the ERP project, make sure that you are going to be able to secure those resources when you need them.

Your project team should represent a good cross-function of your organization. Having an organizational chart with a management structure that mirrors the existing organizational structure can aid in this.It is best to choose some members that are potentially more junior, tech-savvy, up-and-coming, folks that are not afraid to challenge the existing procedures, are going to think of the best way to achieve the project objectives, and are not too tied to the status quo. Essentially, ensuring that you have a good mixture of team members that are going to add to the project and doesn’t always align with who reports to who in which department.

ERP implementations almost never exist in a vacuum. There are other things going on with companies, other projects, so it is vital to understand the allocation of the resources that are going to be in that project. Engineering the resources’ time requirement throughout the life of the project and ensuring you have the correct resources, and those resources have the time, so you understand, in advance, if you need to backfill resources to accommodate the project.

It is important to establish a budget and scope in advance, especially with a multi-location environment, to determine which areas are going to be implemented in what phases. Ensuring a realistic scope in terms of all the technology that’s going to be changing, and being mindful, of things like headcount reductions. It is advised though, not to publish that type of calculation, it a surefire way of reducing engagement in the project. In some cases, there are reductions in one area and increases in another. In terms of operations, it’s important to consider hard quantifiable benefits versus softer benefits. Getting the full mixture of all opportunities into the process and ensuring that it’s communicated widely.

It it never too early to start thinking about master data. Master data consists of your items, vendors, customers, and other miscellaneous things. Typically, in an implementation, master data is a constraint or issue that requires more time than what is estimated. Developing the master data governance even before implementation starts is a great technique. It is as simple as understanding who has control of specific functions. Putting some form of approval structure in place so your organization gets into the habit of controlling the data that’s flowing into your systems so that when you get into user-based permissions in the ERP system, you’ll already have those habits formed.

But it’s rare that I encounter an implementation where master data is not a constraint or an issue that requires more time than what people typically estimate. So it’s never too early to start thinking about that. In fact, developing the master data governance even before implementation starts is really a good technique. And that could be just as simple as who has the keys, or who has the control to enter a new item or a new vendor, and putting some form of approval structure in place so that your organization gets into the habit of controlling the data that’s flowing into your systems so that when you get into user-based permissions in the ERP, you’ll already have those habits formed.

When you’re taking the steps to ensure a smooth transition, it is important to make sure that any type of data cleansing is done prior to the project. You should understand what your data retention policies are for both legal and company requirements, because as you’re transitioning data from a legacy system to your new ERP system, you don’t want to bring over all the data. This is especially true with some of the older data that has data integrity issues.

If there’s any plans of departmental restructuring, it’s best to do that prior to your ERP implementation project just to eliminate any type of disruptions or confusion that could happen. Additionally, if you’ve got other large projects that are going to be going on, it’s best to minimize those. When reaching point in time that you are implementing your ERP system, it’s important to eliminate other projects that could cause confusion or cause conflicts with your ERP project to ensure that things go as smoothly as possible.

This is an area of a bit of crystal ball and experience that really goes into understanding the longer ERP implementation. It might be tempting to get everything a hundred percent before go-live, and that’s usually the goal. The reality is that things do change, and you need to build in buffers. A common example of things that come up are restructuring of your chart of accounts. Oftentimes, especially if you’re coming out of an accounting environment that is not dimensional in nature and you’re going into a new ERP, there’s a lot more flexibility specifically with your chart of accounts that you can organize, and slice and dice based on dimensions. That realization often comes about while you’re in implementation, but we encourage to get that sorted out in advance, to start thinking about the impacts of dimensional accounting and how that could streamline the organization.

There’s often times a short window of go live that is desired. It is always cautioned to not fixate on this too much and really look at the project, with all its components, and make a realistic timeframe that’s going to accommodate for any inevitable setbacks. It is important to include some buffer time to consider any delays. Taking these delays into account in your overall timeframe allows you to determine the impact on the business.

Not incorporating a buffer into your timeline can lead to shortcuts in testing or other functional aspects. Taking short cuts in sufficient testing, to meet a tight timeline, can backfire on you during go-live.

There are a few different shades of business case. There is the full-blown return on investment, which is quantified, and is typically something that might be required to get the project budget approved. But the remedy for that is a case for change, which is a slight twist on the business case. It’s not as numbers-driven and includes questions like, ‘what does this new technology enable us to match with our strategic goals?’ An example of this is if you’re opening a new channel and your existing technology limits that capability, but it’s something on the horizon. It may be difficult to quantify what that looks like in the form of a business case, but the fact that the transformation is now going to allow for a new channel to be open, whether it be e-commerce or different mechanisms, newer technology will enable you to do that. It’s not always a requirement to have a very specific return investment calculation but understanding what potentials a new system opens is quite valuable.

Most companies are embarking on projects of this type with specific benefits in mind, and it’s important for you to detail that out. It’s important that you share that with the project team and keep a close eye on those business cases to ensure that the opportunities and benefits are realized at the end of the project. Many times, they’re not because they lose track or lose sight of what the overall or original purpose was of embarking on that project.