Knowing when it’s time to replace your aging enterprise software

All enterprise software eventually becomes obsolete. Here’s how to decide exactly when enterprise software should be replaced

Recently a client asked if they should keep their existing ERP software or consider replacing it. Like many companies, they had purchased various software products over the years to tackle different problems in their environment. These purchases inevitably resulted in creating silos where it is hard to keep duplicated information synchronized. Old software meant new hires had no experience in that technology (think green screen terminals) and needed extensive training. Also, reporting was simply so much work that the business didn’t get the information they wanted when they needed it. The client’s question was this: Do they add something like a business intelligence layer over the top of the existing systems, or is it time to consider upgrading to a modern ERP?

Jack Welch once said that “If the rate of change on the outside exceeds the rate of change on the inside, the end is near.” The question faced by companies in this position is whether existing systems can scale up to accommodate planned growth, or will their limitations constrict growth? Even if current systems can scale up in the short term, what are the prospects in the medium and long term?

Given the rate of change in business today, there will come a point at which the existing collection of systems just can’t accommodate the organization’s needs.  For example, can those applications support new governmental regulations? With natural attrition, there is a growing gap between new and existing employees. Do they really want to invest in training new employees on obsolete applications?  Therefore, the question becomes not “Should we change?”, but “When should we change?”

One way to answer this question is to seek out experienced opinion, but opinions are always biased. There is no way to avoid bias because everybody is limited to their experience. Given how comprehensive ERP software is, that experience will be either broad or deep, but almost never both. Experience is also current or old, and given the rate of change in the market, experience gets old very quickly.

The way to overcome bias is to measure how well existing software meets requirements and compare this with potential replacement systems. If the current system scores close to those of potential replacements, there is little pressure to change. On the other hand, if there is a large gap between current and potential new system scores, that suggests the change should be sooner rather than later.

Start with the foundation

The first step in answering the “keep or replace” question is to create a comprehensive list of requirements. Since ERP is being considered, this will run into thousands of requirements.

An inadequate analysis can lead to the wrong answer to the question.  Should the client decide on a new ERP system, any significant requirements that were not discovered during the initial analysis phase will be discovered during implementation. If too many significant requirements are missed during the analysis, it is entirely possible to select the wrong software. Even if best-fit software is selected, every “new” requirement discovered that can’t be met “out of the box” means more implementation work and associated costs. Requirements that should have been discovered during the requirements analysis phase are the primary cause of implementations that are late and go over budget.

When it comes to developing requirements, start by examining the features of the existing software that are used, and rewriting them as requirements. This process is also called reverse engineering requirements from features. It is critical to use this same technique on several potential replacement systems because that is how you find requirements you don’t know you need. The kind of requirements where people look at them and say “Hmm, never thought of that. But I can see where it would be critical to…”

Once you have a comprehensive list of requirements, you need to rate them for importance to your organization. This means capturing who wants a requirement, why they want it and how important it is to them. When you have completed this, you will have developed your requirements profile, which is the foundation for making the best decision for your particular circumstances.

Measure the gap

With the requirements profile complete, you can measure how well current and potential software meets the needs. Start by using the requirements profile to create RFIs or RFPs which are sent to potential vendors. Use the completed RFI or RFP to do the gap analysis.

Using a normalized scoring system where 100% means a perfect match with your requirements, you might find that your existing system scores around 85%, whereas the best new systems score around 90%. That suggests that not much would be gained by doing the project now. On the other hand, if the existing systems come in at 65% and the best new systems score around 90%, that makes a strong case for starting the project now. If a new project is on the cards, double check your analysis by estimating the project’s ROI.

Recommendation

Let me emphasize how important it is to reverse engineer requirements from multiple products. If you don’t have enough requirements created from the features of potential new products, the current system will score too high on the gap analysis. Although you will have gathered requirements based on pain points of the existing software, you need the features of new products to help you discover the requirements you don’t know you need.

To gather adequate requirements is a lot of work, but to quote our client: “Software selection is like painting a building. The real work is in the preparation, not the selection.” For this client, using a gap analysis to measure how well the current and potential products meet their requirements profile leads to a rational, data-driven decision of if and when to replace their existing ERP system.

Source : https://www.cio.com