15 Tips to a Successful ERP Implementation

During my time as a consultant I have traversed about a dozen ERP (Enterprise Resource Planning Software) implementations, all of which were Dynamics AX or Dynamics 365 Finance and Operations. I took a look back and tried to think things that I wish we (the project team) would have done better or differently that contributed to problems, and things that we did well that contributed to the success of the project.

I compiled a list of what I think are the 15 best tips to give your organization the greatest chance to succeed with your ERP implementation. These insights are based on real, on-the-ground experience. As you probably know ERP implementations are complex and this list is definitely not exhaustive, but I believe these tips will have the greatest positive impact on your implementation.

Start Data Migration Before the Implementation Starts

On most projects, data migration really does not start until after the analysis phase. To most this seems logical because you need to analyze and gather requirements to know which data migration elements will be in scope and what fields will be needed. However, what I have learned is that if you start the data migration process after the analysis phase, you’re already too late and the odds of your project timeline being delayed are dramatically increased. This is not always the case, but I would say in about 80% projects, if data migration does not start before the analysis phase, there will be delays later in the project due to the slow and complex nature of data migration.

This might raise two questions:

1. What do you mean by “start data migration”?

2. How can we start data migration if we do not first gather the data migration requirements?

What I mean by “start data migration” is during the pre-sales process before you have even committed to an ERP software or partner, you should determine your internal data migration strategy and gather your own internal data migration requirements instead of waiting for your partner to do it for you.

By the time the project starts you should know which data entities or elements you want/need to migrate over and you should have a repeatable and flexible process in place to extract and transform the data.

For example, one of the data elements you will probably need is the product master. Assuming your current ERP, PLM, or PIM software runs on a SQL database you should create an SSIS routine, SQL script, or other automated process to extract the data with the fields you need.

When you select a partner, you should ask them for all the data migration templates you think you will need based on your analysis and the partner’s discovery process. Then work with the partner to understand the data migration templates associated with the chosen ERP software and start modifying your SSIS routine or SQL script to match the extract format dictated by the template.

When the project begins and you have demo or test instances of your chosen ERP software available, start loading all your major data entities like customers, vendors, products, sales orders, purchase orders, etc.

This accomplishes two things. One, is you have actual data in the system that your users can relate to when they first start getting into the system. This helps with user adoption and it helps identify data issues earlier that can be fixed much easier in the early stages of a project.

The second thing this accomplishes is when you find data issues, if you have a repeatable process like an SSIS routine or a SQL script, you can just tweak the extraction and transformation script where necessary to fix the identified issues. If you find yourself having to manually extract the data into an Excel sheet and manually fix data issues you will inevitably run into issues down the line that will cause delays in the project timeline.

Identify Key Business Processes

Before an ERP implementation project begins it is important to understand what your critical or key business processes are, especially those that may be unique to your industry or even company. A key business process is one that if you could not complete the process, the firm could not earn revenue, pay vendors, or collect from customers. However, there could be other peripheral processes that may fall into the category of a key business process for various reasons.

Once you have the business processes identified, it is important to assign owners to those processes. If you do not already have a documented flow chart of the business process, that owner should document the process in a flow chart and become the expert on the process. The owner should know all the key users involved in the process, what they do, and why they do it.

The purpose of selecting owner and carefully documenting the process is to create a subject matter expert who knows the ins and outs of the process. So when the consulting partner begins analysis workshops you will already have the answers to their questions and you will avoid having two to three follow up meetings where each time you have to take action items and schedule a follow up meetings.

Identifying the key business processes can also give the consultants a better idea of the major business processes which will drive how they plan for analysis and design workshops.

Load Balance Responsibilities and Duties

On an ERP project most of the delays result from client based resourcing constraints. Consulting firms can always throw highly specialized consultants on a project to pick up the slack but that rarely is the case on the client side. Usually there is someone on the client side who is taking on too much work and falls behind.

Before the ERP implementation project begins you will build your core project team. This team should be comprised of subject matter experts from all departments of the organization that are in leadership positions, able to make business decisions for their department, and know their part of the business very well.

This is a step that happens in every ERP project implementation. However, in some projects the workload is not distributed evenly, and some subject matter experts take on much more of the project duties than others and when they fall behind, they become the bottleneck for certain work milestones to be completed.

Sometimes you have a situation where one subject matter expert is the de facto project manager, data migration lead, subject matter expert in their part of the business, and trying to do their day job on top of all of it. It is important for the project manager on both the partner and client side of the project to identify this and deploy an immediate action plan to try to offload some of the work to someone else.

If you can load balance the project work among all subject matter experts and keep everyone above water, you are eliminating a risk I have seen on almost all projects.

Commit to Avoid Modifications Where Possible

Unless you are building a home grown ERP system you are probably going to select a pre-built ERP software. In every implementation I have been in, there has been a statement in the request for proposal or statement of work document saying something to the effect of “We will commit to using standard functionality of the ERP software as dictated by industry best practice”. In reality however, when you get into the weeds and the detail of the requirements, there are always objections to the way the standard ERP software works and there is a call for a modification or enhancement to the software.

I am not against modifying the standard software per se, but all modifications should be viewed as a chunk of sunk time. It’s not just the time it takes to code and test the modification, it is also the time it takes to keep up with the custom code when you upgrade or when you have to support issues that arise from breaking other standard functionality.

That said, there are legitimate reasons to modify the standard ERP software. In cases where there is an extremely manual task and the time savings would justify the cost of the modification or the required functionality simply does not exist in the standard ERP system a modification is justified. In many projects I have witnessed requests for modifications to the ERP application simply because something took an extra one or two clicks or the users wanted some piece of functionality to work in a different way.

It is important that subject matter experts, project sponsors, and project managers step in to push back and really understand why the two clicks should warrant a large intrusive modification to the system. Avoiding unnecessary modifications can save you a lot of time, headaches, and money on an ERP implementation project.

Change Management

Until recently I did not have a very high opinion of the importance of change management. My opinion used to be, if we implement properly it doesn’t matter whether or not people accept the new ERP system, we have done our job. This was a very naïve view of the purpose of change management and the role that it plays not just after go-live but during the entirety of the project.

After being on projects with an organizational change management (OCM) team and projects without an OCM team I can tell you the difference is night and day.

Organizational change management is all about facilitating the change that the new ERP system will bring. To do this they also create a communication strategy to keep the business informed of project progress, news, quick tips and tricks, and other important topics that make end users feel informed and included.

The biggest way I have seen the impact of change management is in analysis and design workshops. Users are much more likely to participate and engage in conversation and in the workshop as a whole, if they are excited about the change and buy-in to the new ERP application. If you have subject matter experts that have a negative attitude toward the new ERP it can be infectious and create a negative attitude toward the ERP for all other users.

The change management team an also help with training planning. This can often take much of the logistical burden off the core project team and give the training planning the attention it deserves.

If you are planning on rolling out an ERP to multiple legal entities, the change management group can perform an organizational change readiness assessment to determine which companies are ready to go through the ERP implementation process and which need more time to adjust their culture.

If your implementation partner is suggesting that you purchase change management services, before you roll your eyes, hear them out and understand the value proposition and how it may help your implementation.

Status Updates Early and Often

It is important to know where the project is in relation to the project timeline and plan once sometimes twice per week. If you find that there is little to no progress being made it’s time to dig deeper and see where the blocker or bottleneck exists.

It is easy to go through the motions on status updates and just go around the table and get status updates from everyone and move on. I would suggest having notes or action items from previous meetings to ensure that there is a benchmark for progress. If someone is working on the same task at the end of the week that they were working on at the beginning of the week there may be something going on there.

If you are using project management software like Azure DevOps to manage the project, use that software to track the project progress. Figure out what key metrics and reports you need to keep an eye on to measure progress and hold people to those numbers.

Ask for estimated time to completion for tasks and hold people to those dates. As a consultant for many years, I hated that question because sometimes you just don’t know how long a task will take until you get into it, but if you don’t have a deadline to work with, project timelines will start to slip.

Encourage people to raise issues and blockers. Encourage team members to come prepared to the status meeting with issues they are facing or blockers that are stopping certain tasks from being completed. This will enable you to facilitate and free up bottlenecks and blockers or at least ask the right questions to be able to plan around those bottlenecks.

Avoid Scope Creep

All ERP implementations begin with a defined scope and from that we derive the budget, project timeline, and resource scheduling. If scope continues to be expanded through true scope expansion or if there was not a meeting of the minds between the partner and client on how the scope was defined, delays to the project will occur.

All brands of ERP software come with a vast array of functionalities and features that are very interrelated as you would expect from a fully integrated ERP solution. During the pre-sales and sales process the preliminary scope will be defined with the chosen partner. It is important to know what specific features are being included in the project scope and especially what are not. If you’re not sure ask questions and then ask more questions until your partner can adequately explain the features that they have marked out of scope. If you suddenly realize halfway through the project that you need to implement a module previously defined as out of scope you will be presented with a change order that will detail the additional cost and time that will be added to the project if the module or even feature (if it is a complex one) is to be included in the scope of the project.

If you are a subject matter expert or a project sponsor and you are attending an analysis or design workshop and you witness scope creep, it is important to understand where the new requirement is coming from, if it can be part of a phase two project, and why it was not called out earlier.

There are many causes of scope creep but there are a few that seem to be the most common among ERP implementation projects.

The first is ambiguous or poorly worded requirements. When you have two people shaking their heads “Yes” but are talking about completely different things you will tend to find scope creep. One person is talking about something that is very simple while the other is talking about something very complex and the estimate to meet the requirement is based on the simple understanding. This is a very subtle form of scope creep, but it is the most common.

The second cause of scope creep is too many participants in a meeting. Although is it great to get many perspectives on a business process or procedure if there are too many people pulling in too many different directions, you tend to lose sight of the problem we are trying to solve. The conversation tends to stray into out of bounds territory and if it is not reigned in quickly people’s expectations shift toward what they now think is an expanded scope. It is the responsibility of project managers, client project sponsors, and client subject matter experts to politely and professionally keep everyone within the bounds of scope.

The third cause is one I have been guilty of and it’s called “Gold-plating”. This occurs where the consultant or developer goes out of their way to deliver features, functionality, deliverables, or material that they feel benefits or adds value to the client beyond what is defined as in scope. Clients rarely, if ever, push back on this kind of scope creep because it greatly benefits them, but if it is done too often on a project and the resource falls behind on deliverables that actually are in scope, it can lead to project delays and finger pointing.

Take Ownership

This is a big one. If you are currently looking for an ERP implementation partner or have already chosen one, make sure you ask them what their strategy is for transition of ownership from partner to client. On many ERP projects clients are paying top dollar for highly skilled consultants to help them with an ERP implementation but the word “help” often gets turned into the word “do”. By that I mean sometimes the client just wants the partner to “do” the implementation for them instead of their organization’s power users and subject matter experts taking the initiative, learning the new application, and really leading the implementation internally.

In the initial stages the partner will have most of the ownership in terms of guiding you through and running the analysis and design workshops. However, through these workshops and the progression of the project, there should be some level of transition of ownership where users begin to get into the system and start to drive some of the conversation and testing of different business processes and scenarios. This continues throughout the project lifecycle until you get to UAT (User Acceptance Testing) where the majority of ownership should fall on the client, where the client plans, organizes, and executes UAT with the partner only there for guidance if needed.

Then when you get to end user training, your subject matter experts can lead these training sessions and take ownership of the training for their departments. This ensures that all training is done in the context of your business instead of some generic surface level training.

After go-live you should be at a point where you can completely own the system and have power users and subject matter experts that can triage and troubleshoot the majority of issues that arise, leaving only major or complex issues for the partner to be responsible for resolving.

Why is the transition of ownership from client to partner so important? I think it should be clear by now but if it’s not let me quickly explain. The more you and your team take ownership the less you must rely on an external partner. As great as that partner might be, they will still be charging much more than your internal IT department.

Also, ownership of UAT is extremely important for a smooth go-live. The partner doesn’t know what they don’t know and for UAT to be meaningful and catch real showstopper issues before go-live, the UAT scenarios and processes tested must be as close to reality as possible. Only your subject matter experts and power users can truly set up and test the nuances and complexities of your business processes in a comprehensive manner.

Implementation Methodology

There’s a lot of debate and differences of opinion as to which implementation methodology is the best when it comes to ERP implementations. I don’t claim to have a one size fits all answer to that question, but I can tell you what I have seen from experience using different types of methodologies.

What I found however when using this approach was that there was a lot of upfront analysis and design work that was done without ever showing anything tangible to the client other than massive design documents or a requirement traceability matrix. The consultant would take the requirement mark it as a fit or a gap based on the functionality as compared with the requirement and move on. The consultant would configure the feature or functionality and continue the process until the system was ready for use. However, without the client actually being able to see the feature or functionality configured they did not have a sense of how the functionality would work and when they finally did get to see it demonstrated live with client data it was usually at the end of the Design or Build phase of the project. When the client gets to see it, there may be some gap or something that does not work as expected and even though the consultant was correct that the requirement was technically a fit, it does not work as expected in the client’s eyes. This leads to lots of rework, frustration, and wasted time.

The waterfall methodology also does not lend itself to a very successful ownership transition strategy. Because in a waterfall approach the client does not start testing until much later in the project life cycle, there is less time for training and ownership transition activities which leads ends users to feel under trained at the time of go-live.

The downside to a pure agile approach is that for these rapid sprints to occur, the partner needs a large time commitment from many of the subject matter experts who also have their own job responsibilities. If clients are not able to supply such large resource commitments, the sprints tend to flounder and fail, and the projects will suffer delay after delay and eventually the project turns to a waterfall project in practice and only an agile project in naming conventions of activities.

I think the right answer lies, as most things, somewhere in the middle for most organizations that cannot allocate the required resources for an agile project but do not want to follow the waterfall approach. Understand your partner’s methodology and ask them how their methodology avoids common pitfalls of each.

Understand Your Environment Strategy

On an ERP implementation project, you will have multiple environments for purposes such as testing, data migration, configuration, development, and automated code builds. Depending on the ERP application you end up using, you may have some or all these types of environments and depending on the technology stack underpinning the application they may also be hosted on premises or in the cloud.

The environment strategy defines how environments are used, how data and code is moved from one to another, schedules for data refreshes, schedules for code deployments, and schedules for downtime. Understanding this strategy can give you key insights into the time element that each of these activities require.

For example, let’s say you are planning UAT and you are trying to understand what needs to happen in order to have the UAT environment ready for users on Monday morning. If you know that a database refresh takes 6 hours to copy and restore the database and you know that consultants need to smoke test the environment which takes another 4 hours after, and the current scheduled database refresh is for Saturday night, you know you have a problem. You can intervene and change the scheduled database refresh to occur on Thursday night giving you plenty of time to restore and smoke test the environment before end users begin testing on Monday.

This is a specific example of how knowing the environment strategy will help you in terms of planning but knowing the environment strategy can also help you plan your budget. If you know how many environments, when they are needed, and for how long, you can more accurately plan your budget for cloud hosting costs or infrastructure costs associated with the environment requirements.

Plan UAT Early

User Acceptance Testing (UAT) is arguably the most important activity in an ERP implementation project. UAT is the last gate of testing before go-live to catch any critical issues or missed requirements. UAT is a highly coordinated and complex set of activities that must be intricately planned to ensure that all business processes, scenarios, and requirements that need to be tested are tested and that the data required to do the testing is available and is of high enough quality to successfully complete each test.

In my experience UAT planning is often underestimated and when it is, the result is apparent during UAT execution. My advice is to begin planning UAT as soon as analysis has concluded. UAT planning consists of several parts.

1. Define Entry and Exit Criteria – Entry and exit criteria precisely specifies criteria that must be met for UAT to commence and for UAT to come to an end. This is important because if UAT starts before certain criteria is met there is a good chance UAT will either run longer than scheduled or will users will face frustration and errors throughout the process. If UAT ends before the exit criteria is met the you are less likely to catch errors and issues that will cause headaches after go-live because not all testing has been completed.

2. Test Planning – Test planning consists of planning exactly what will be tested in terms of end to end business processes and scenarios, the data and setup required to support the required testing, ensuring comprehensive test cases and scripts have been written, and defining how test results will be captured and evaluated. This process is the most time consuming piece of the UAT planning and often requires collaboration among all subject matter experts and partners.

3. Resource Planning – Once you have the test plan created and you have a sense of how many business processes and scenarios will be tested, you can begin to determine which resources are needed and how much of their time is required. Then you can start to put dates and times against a certain resource to ensure they are available for their respective testing activities.

Define Collaboration Channels

In the modern workplace there are so many different collaboration platforms. For your ERP implementation it is very important to determine not only which collaboration channels will be used but also how they will be used. For example, it is common on projects for people to communicate, collaborate, and share documents through email. The problem with this is that you have different versions of documents floating around and no one quite knows what the latest version is. Another issue with using email exclusively is that a lot of times people do not answer email is a timely manner and in some cases, an unanswered question can be a work blocker for others.

I was on a project recently where all the participants were given an on-boarding package that explained each communication medium and what each was used for. We used Microsoft Teams for chats, document storage, versioning, and sharing, Azure DevOps comments were to be used for any communication dealing specifically with a requirement or work item, and emails were to be used sparingly with the project manager copied on all project related emails. This approach is not perfect but there was no confusion on how we should communicate, where to find information, and which document was the latest version of the document.

Don’t Neglect Security

On almost every project I have been on security has caused problems. The complexity of assigning users with the correct security can vary depending on the ERP application used. However, it is never a quick process. Security often requires trial and error and testing to get it tweaked and adjusted just right.

Security in an ERP project often times will require a dedicated team and treated as a separate workstream from Finance, Supply Chain, Manufacturing etc. The security team should be gathering its own requirements related to security and work closely with all other workstreams on the project to refine and allocate the correct security privileges to all users.

Security can also have regulatory and audit implications. If security is not properly tested, organizations could fail audits and be exposed to fraud.

Post Go-Live Support Strategy

The post go-live strategy is another neglected activity in some projects. The focus of the project is to get to the finish line, which for most of the project stakeholders is go-live but go-live is just the beginning. The severity of the issues you will face after go-live will be directly related to how well the project was planned, tested, and delivered. Even the most well run ERP implementations will have post go-live issues even if they are turn out to be minor. The complex nature of ERP systems makes this almost inevitable.

The near certainty of post go-live issues makes having a well structure and thought out post go-live support strategy even more important. Some critical questions to ask are:

• How will post go-live support issues be triaged, investigated, escalated, and resolved?

• What types of issues will be escalated to your partner and which issues should be handled by the internal IT team?

• How are we managing tickets, and communicating to users that submit tickets?

• What type of partner support agreement is required to support my business, one month after go-live? Six months? Two years?

Answering these questions will help to build your post go-live support strategy.

Upgrade Strategy

The upgrade strategy refers to how you will handle any ERP application updates to your new system after to go-live. You will need to understand what is required for you to upgrade your system, what is the down time and how will you ensure proper regression testing.

How has any modification that you may have done to the standard ERP system affected by the update and what resources are needed to conduct code merges and reviews of the updated code?

The upgrade strategy is a key to making sure that your ERP system is up to date and that updates do not break anything in your production system.

Takeaways

I had to learn some of these tips and best practices the hard way and the intent of this article is to help others avoid mistakes I have witnessed in past projects.

ERP implementations are an amazingly complex and time consuming marathon, but I hope I have given you some key insights and tips that will make your implementation a success so you can leverage the incredible insights a modern ERP system can provide.