If you find yourself underwhelmed by your current ERP system, you may have discussed replacing it. While this may be the right solution, let's first take a look at a few common causes of this to help determine whether moving is necessary and what can be done to avoid issues in the future.

1. Failed Initial Implementation

A poor or failed implementation is one of the top reasons for users being unhappy with their current solution. The are many possible reasons for a failed implementation but lack of buy-in is one of the most common.

Without buy-in, you are unlikely able to obtain the collaboration from end-users and other stakeholders that is required in order to select the correct software, configure and migrate it properly, or even train thoroughly and efficiently. Failure to do these things well on a software implementation project will lead to a product that is never fully implemented. You may go-live on time and budget, but you will likely never fully realize the software's potential in your organization unless everyone is onboard.

Obtaining buy-in needs to be a collaborative effort between the project sponsors, project leads, project managers, and the end-users. Change management is one of the most important activities organizations overlook when taking on software migrations or upgrades.

There is often a debate about who to include in steering committees, project teams, SME groups, etc. While this is necessary, it is often-times overlooked how much influence the end-users have on success. Organizations who choose to wait to include these important contributors into the process expose themselves to unnecessary risk.

Engaging these users early on not only helps obtain buy-in more easily and sooner, but truly listening to their stories can help you avoid pitfalls and landmines in the selection and implementation process. We recommend sitting down with each one and documenting their thoughts about your current solution, ideas they may have to improve it, and wish list items they may have for a new solution. Keep this document and reference it throughout the remainder of the project so that even if those users do not sit on a steering committee, they can watch their ideas being represented. This fosters trust and more collaboration as time goes on.

Having a point-person on a project is a good idea but be careful that this doesn't isolate the end-users and other key stakeholders from the vendor resources who are trying to collect information. Building direct relationships between these parties is essential to building trust and understanding so that the vendor has the most accurate information from which to configure the system.

Using an experienced third-party consultant to act on your behalf during both vendor selection and implementation can help bridge this gap, ensure that all voices are heard, and help your team get the most from your software.

2. Vendor Selection

Choosing the wrong vendor is another common reason your system may not do what you expected.

One of the main reasons organizations select the wrong vendor is the same as above, lack of user buy-in. This is addressed above so let's look at another common reason, and that is lack of specificity.

When a municipality issues an RFP for a new software vendor, they will generally choose between either representing themselves or hiring a consultant to guide and/or represent them throughout the process, or for selected activities during the process.

I have seen some leaders within communities do a fantastic job representing their organizations. The truth is however that most communities don't have someone with the prior experience to successfully lead a team through the selection process. Vendor selection typically involves the following basic activities:

1. Project Budgeting and Sponsorship

2. Purchasing Guidelines Review

3. Selection Committee Creation

4. Change Management Activities

5. Requirements Documentation

6. RFP Documentation Preparation

7. RFP Issuance

8. RFP Q&A Meetings

9. Vendor Short-listing

10. Vendor Demonstrations

11. Vendor Selection

12. Contract / Statement of Work Final Negotiations

13. Contract Execution

One of the most important steps in this process is the Requirements Documentation. This step is where you are defining in detail a list of features and functionality that you need and/or want from an ideal vendor. It's important to think both short and long-term here.

The most common issue with not seeking assistance during this step is failure to identify functionality that could improve your operations. Without knowing what new technology or industry best-practices exist, you may be qualifying a lot of vendors that won't meet your long-term needs. Also, you may end up with software that you cannot grow into, even if some features are things you may phase-in down the line.

On the other hand, when working with a third-party consultant, be sure requirements are identified specifically to your organizations needs. Some vendors will use templates that includes many requirements that do not apply to you. While they may augment it to include some of your specific requests, they can ultimately unintentionally disqualify vendors based on requirements that are not important to you. Technical documents that have thousands of listed requirements force vendors to spend days reviewing and responding, whether they will win the business or not. This may cause some vendors who you may have found to be a good fit to exclude themselves from the process. In the end, it's best not to overdo it here.

One other area where the right consultant can help is to prepare you to ask the right questions during vendor demonstrations. It is important for consultants to remain unbiased during this time but it is also important for them to help ensure that each of the stated claims by the vendor can be demonstrated. Many municipalities who are unhappy with their software later on oftentimes are not asking vendors to show them how functionality important to them actually works in the system. In my experience, most vendors are honest and do not intentionally mislead a potential client, however it is more common that what a client/user had in mind differs from the actual solution. Vetting this out during the demo phase can save a lot of frustration after go-live.

3. Staff Changes

The next reason is one we have seen quite often and this may be where you are at. If your software was selected and implemented by teams years ago with different visions, goals, and initiatives it is likely that the software isn't configured to fit your current team.

You may have completely rolled over positions since go-live, added staff, or are working with fewer staff members. You may need to review current-state and future-state processes to reassess how your system should be configured to best work for you.

Start by finding a system and domain expert within your organization who is capable of performing in-depth business process review, implementing the configuration changes within the software, and re-training your staff. Alternatively, contract with your software vendor or one of their authorized professional services vendors who have a combination of this experience and expertise to give you a hand.

4. Process Changes

Similar to staff changes, sometimes general process changes have occurred over time and your software wasn't configured to manage it properly. When organizations lack the experience to make configuration changes in their software as they become necessary, the required changes can pile up over time and become increasingly problematic. These usually manifest themselves as a feeling of frustration with the software in general or a feeling that too much manual management of data is required within overall processes.

When these symptoms begin to appear, it might be time to perform some wholesale business process review to establish a new baseline and reconfigure your system to accommodate.

Just like before, if you have the staff experienced in this area then sponsor a project internally to discover, document, and implement these changes. This is another area where an experienced vendor or professional services provider should be able to assist with.

5. New Features

Let's say you chose the right vendor, had a great implementation, have had minimal staff turnover and now you are a few years out wondering why your software isn't doing some of the things you expect it to. The first thing to consider...is that it may.

Good vendors are constantly updating their software. In many cases, regular updates with bug fixes and enhancements are included in an annual support and maintenance agreement you have with them. In some other cases, a new version may need to be purchased periodically which includes these.

In either case, it's possible that the functionality you desire is already available. The first thing we always recommend doing when wondering, is ask. Call or message the technical support line for your vendor and ask them whether a specific feature exists and even how to use it. It seems like an obvious reaction, but I was always surprised by how many municipalities were hesitant to do this. A great support team will quickly provide you information on configuring new features or even give you a hand doing so. If the feature is complex in nature, they may recommend having an implementation specialist or professional services partner work with you to implement it. Also ask them how and where new features and bug fixes are announced and whether or not there is documentation to accompany them.

Another great way to stay in the know on new features is to attend vendors user group meetings when available. Some vendors offer these remote or at a destination location and have sessions where new functionality, tips, and tricks are demonstrated. It can also be a good time to talk through ideas with other municipalities who are attending to learn or share ways to use your software more thoroughly.