Finally after spending a lot of time and money, your organization has just launched a new ERP (Enterprise Resource Planning) system. The feedback from UAT (User Acceptance Testing) was positive and you think all of your employees are excited to start working in the new system. Afterall the new system is going to make it so your teams no longer have to produce basic financial reports in Excel, complex contracting arrangements will now be invoiced by the new accounts receivable module, and consolidations will be a breeze. Then you have your first month-end close.
The reports do not provide all of the information needed, so the team exports them into Excel from the new system and make the necessary adjustments and tie-outs so they can then send them to management a day late. More than half of the complex contracting arrangements did not invoice properly within the new system and an additional handful did not post to the correct accounts. And to top it all off consolidations is out of balance. You find out it is because the team in Japan created a new account that pulls into the wrong account category which is using the wrong exchange rate and they did a prior-year adjustment because of an audit that just wrapped up in Japan. The adjustment was posted into their old system but was not posted into the new system or included in the beginning balances that came from the old Excel spreadsheet used to consolidate and convert balances to reporting currency before the new system was put into place. So, what went wrong? And why was it not caught before the new system went live?
I wish I could say that the above is just a worst-case scenario, but I have actually encountered the above and more during my career. As painful or as embarrassing as it may sound it is not uncommon to hear that a new ERP system implemented ultimately did not provide the improvements expected. All the workarounds the organization was going to magically get rid of are just replaced by new ones. But it does not have to continue to be that way. We can learn from those mistakes. Often the common mistakes made leading up to and during implementation can be avoided if an organization invests in the right resources, takes the time needed to prepare, and provides the training and documentation needed for staff to successfully use the new system.
The five most common mistakes can be classified as follows:
1. Underutilization
Purchasing a new system is exciting and can be rewarding, but do you know what it is really capable of? If you do not fully understand the functionality of the system, then there will be a lack of optimization of key processes. But what if our organization hired third-party implementers? They must know all of the functionality of the system, right? Unfortunately, the answer is no. Third-party implementers are not always aware of all the functionality available within a system.
I had a client that was told by their third-party implementers that the new system the organization was putting in would not be able to do consolidations the way the organization needed. I did some research and found that the system was indeed able to do exactly what the client wanted if the module was activated. We learned that the lead for the third-party implementers had never worked with that module before, so they were unaware of the functionality.
Asking questions and researching solutions for similar scenarios to your own is a great way to prevent this mistake. Many of the ERP systems available provide free training courses that give an in-depth look at the functionality currently available as well as new functionality about to be rolled-out. Some of them also have communities and support available to answer questions on functionality too.
2. Misaligned Functionality
Letting the third-party implementers decide the structure of the system sounds like an easy, reliable path forward. After all they are well versed in the best practices for the system. However, they are not well versed in the day-to-day operations and current pain-points of your organization. Letting the third-party implementers decide the process that is being built often fails to capture the true functionality needed to improve the current processes. If you have to manually process certain activities outside of your current system and will have to continue processing them manually in the new system, then what was the value in putting in the new system to begin with?
I was building forecasting and planning models for one of my clients and had asked the accounting department for access to the financial reports so I could pull in actual amounts which would then be used by the model to calculate the forecast and plan. The reports I received were in an Excel file. Upon further inspection it was clear that the reports were not exported out of their ERP system but had been manually created in Excel. When I talked with the accounting contact that sent me the reports to confirm my findings, I was shocked to learn that the new top-of-the-line ERP system the organization had just implemented was not configured in a way that would allow them to pull the financial reports they needed. I am very familiar with the system they were using, and it is more than capable of providing what the organization needed. I then learned it was because they followed the third-party implementers recommendations which were based on best practices and not industry or company expectations.
When designing system functionality, it is important to understand best practices, but it is even more important to understand how a business operates. Some processes can and should be changed when implementing a new system, but when they cannot or should not be changed, then the system should be made to work for your organization. Making sure the right organization resources (see Inadequate Partner below) are on the implementation team is a great first step in preventing this mistake. Even better if you have someone on the implementation team that understands accounting systems and your organization.
3. Inadequate Partner
Evaluating all of the systems available, deciding which one to go with, and then overseeing the implementation from a business perspective is a lot of work and there is also the expectation that this will solve all of the accounting and finance departments woes, which adds to the pressure. Picking the right partners internally and externally can either guarantee success or failure. Determining who will represent the company with this pursuit is very important, so naturally the company picks the most knowledgeable staff member who has a thorough understanding of current processes and an intermediate understanding of how the current systems function right? Wrong. Instead, companies often select a very senior level person who has not been in weeds of the day-to-day operations in years, if ever, or the new hire that has more time than everyone else because they have more time than the other critical staff.
One of my clients was implementing a new accounting ecosystem and the Controller of the company had been tasked with leading the charge. He had a great understanding of how the company overall functioned, but when it came to how the modules within the systems need to interact or how the detailed processes were actually executed, he was wasn’t up to the task. They had spent hundreds of thousands of dollars before bringing in someone that could bridge the gap for them. Most of that expense could have been mitigated if they had brought in the right partner at the beginning of the project.
Often the people on the implementation team do not encompass all of the stakeholders that should be on the team or they are so far removed from the day-to-day activities that they do not fully understand all of the detailed actions taken to perform key responsibilities. Taking the time to determine what type of skills will be needed on the team, vetting the team, and brining together a strong team up front can not only save time and money, but also improves the chances of a successful implementation.
4. Problems in Migration of Data
Your current system does not quite capture all the data you need to make decisions and often requires enhancement outside of the system for management reporting. This should all be fixed by getting a new advanced system, right? Well in theory yes, but often in practice not quite. Historical data migrated from your old system into your new system will still be the same data you had in the old system. And if you do not update your processes accordingly, then the inputs into the new systems will still be missing the information you need. Bad data in will result in bad data out no matter how many "bells and whistles" the new system came with. The new system cannot fix your old data.
When I first started a role, the company was utilizing QuickBooks Desktop. While doing an analysis of the ledger balances, I noticed there was a lot of historical data that had been classified differently then the more recent transactions and it missed some key information necessary for management reporting and revenue analysis. I decided to dig deeper since it was skewing a lot of the reports. What I learned is that the company had switched from NetSuite to QuickBooks Desktop not too long before I started. During the conversion it was decided to change some of the accounting practices, but not to modify the data brought in from the old system to reflect those updates nor the ancillary systems. This led to data being reported in profit centers that did not exist in the new system and the expense reporting that was loaded into QuickBooks Desktop to still go to the old coding. It took months of cleanup to get things reclassed where they needed to be and to clean up the master data in the system.
One of the misconceptions around importing historical data into a new system is that the additional fields and new master data structure will magically align with the historical data once it is imported. It is important when bridging between the old system to the new system to map out the changes that are occurring and to map historical data accordingly. Once that is done, you can use the mapping to enhance old data to align with the new master data structure. Another thing to keep in mind is to do as much of the cleanup work that is necessary in the old system prior to conversion. This will eliminate a lot of the enhancement work and allow for reconciliations to occur with the new structure prior to importing into the new system.
5. Failure to Launch
The organization has finished building the shell of the new system, the applicable historical data has been imported, and UAT testing was successful so now you are ready to go-live. Now all that needs to happen is to roll-out communications to the impacted groups and to provide training on how to use the new system. It should be smooth sailing from here. Except it isn’t. For some reason, the first close is a mess. Things were not recorded in the proper places, a critical entry was missed, and the accounting team had to post additional manual entries because a few of the automations built did not record all the information expected. So, what happened? The training missed the mark. Often the training provided gives a great overview of the functionality of the system and how some transactions should flow, but it did not convey the change in process necessary to record some transactions or how to troubleshoot the one-off transactions that really are not as one-off as the implementation team thought.
One of the organizations I was working with needed to update their system workflows due to staff changes and needed to change how some transactions recorded in their system. However, no one on the team knew how the workflows were setup beyond the fact that they worked most of the time. On top of this no one knew how to access the information to see what would need to be updated. As I asked questions, I learned that their system was a copy of the system that was put in by the parent company right before their company was spun-off and that they really had no training that told them this information. Most of the team’s knowledge of the system came from trial-and-error and one-on-one sessions with the implementers when issues arose. On top of this the implementers did not document how the custom workflows were setup and the necessary steps needed to make updates to customizations, so when asked they had to review the system configuration to figure it out.
It is common for communication to go out to the organization describing the new system and some basic guidance on how to use it, but it often misses the mark since it does not reflect how the system really impacts the current business processes. The training and documentation provided is either inadequate or completely missing. Spending time ensuring that thorough training and documentation is provided prior to go-live with a strong plan for post go-live support can help eliminate this issue before it ever becomes one.
Closing Thoughts
Investing in the right resources, spending the time necessary to prepare the organization for the system implementation, and providing thorough and relevant training and documentation can prevent the organization from making the common mistakes outlined above. This is true whether your organization is a non-profit, private enterprise, publicly traded, or a government agency.
Comments