Each business has its own successes and challenges; therefore, they all value change differently. This guide provides an overview of common areas that businesses can expect returns from upgrading their legacy systems. A word of caution – anyone can make a pet project look like it has a mountain of phony ROI. There are opportunities for tactical improvements to existing systems rather than wholesale changes that should be factored into any ROI comparison.
Very few businesses can survive without software. Businesses that grow quickly are also quick to out pace their previous software needs.
Our systems empower a process, magnifying its benefits and its failures. Growing businesses are frequently busting at their process seams, and established businesses find it tougher to challenge the status quo. Taking the time to evaluate and measure our systems encourages us to look at the process as well. Even by taking the leap of asking the question “Should I replace this system?” leads us down different lines of thinking. As an example, sometimes at Kopis we run into requests to put certain features in place into a new system. As we dive deeper into the reasoning, the requests stem out of a learned behavior due to a flaw in the previous system.
During our discovery and design engagements, we also witness these “ah-ha” moments when two people in two different roles are challenged to be critical about the current process. The excitement generated motivates others to think about their processes differently.
LEAN and Six Sigma are helpful practices for approaching process improvement. They provide a framework for evaluating improvements in a systematic way, including challenging estimates of cost savings for improvements. Take, for instance, the Theory of Constraints from LEAN. If you are not improving at your constraint, then you are wasting your money.
Performance could fall into many categories listed in this article. On one hand, employees could be wasting time waiting around for pages to load or worse yet, getting distracted on other tasks. I know I am certainly guilty of task switching if a system takes too long. This could lead to morale issues if the system is a major part of your employees’ job function.
Performance is ultimately a scaling problem because its limits your business’s ability to achieve its objectives. Want to add more clients? Well, our client onboarding process is manual and takes hours.
Want to increase manufacturing production? Well, we are generating so much data, that we cannot create the reports we need by the time we need the next set of reports.
Poor performance can also increase your infrastructure spend. Throwing hardware at a performance problem is a quick solution, but poor performance doesn’t scale in your favor long term. In fact, most performance problems show hockey stick growth, and not the good kind your business is hoping to achieve.
As companies grow, the chance that the major system and processes only work because key employees know how to make it work increases. Could those employees be doing something more valuable to the system? Codifying their own processes into institutional knowledge can reduce the constraints put on the company growth. We worked with a company recently who client onboarding process was ad-hoc and time consuming. The process challenged the Ops team because of the pressure they were under to get it done quickly – increasing the risk of a missed step, unplanned work, and poor perception by the client. On the flip side, the process made sales more difficult since they had to explain to the prospect there would be a delay to onboard. Even though there were differences in onboarding clients, creating a standard, repeatable process enables them to scale quicker because it the knowledge to onboard is no longer held in one person’s mind allowing them to perform other high value tasks.
As your business becomes more valuable, your legacy systems put more of your hard earned equity at risk.
How hard is it to make changes to the system and how hard is it to find someone to make changes to the system? Do common changes require high skilled resources to implement the changes? Earlier this year, we ran across a system that the owner of the company had to request the addition of new employees from his developer who had to make changes to multiple source files of the application which he did on the production system. The system was written in classic ASP so it wasn’t impossible to find people to maintain the system, but it was starting to get a little more difficult. The problem is sometimes you do not know how hard it is to find someone until it is too late. Our client in the example above was not in the business of finding classic ASP developers, so he didn’t know how hard it was to find one until he needed one…badly.
Legacy systems also tend to carry large amounts of technical debt. When a support incident comes up that requires a change, there isn’t always time to do it The Right Way ™. Whether it is due to capacity constraints or the high cost of downtime, this technical debt adds up over time to make changes even more difficult. Compounding the problem is that each passing year, your developers are less familiar with the system as they move onto other projects.
Technical debt comes in all forms. Sometimes it even includes the underlying infrastructure supporting the application. Is the system dependent on a particular operating system, database, or library? If you find yourself tied to a particular version of a dependency, that dependency has a finite support lifespan.
Disaster Prevention & Recovery
What is the cost of downtime for the application? Or worse, what would be the cost of an unrecoverable failure? The higher the impact a non-functioning or under-performing system, the more it is costing in right now. Does the current system provide high availability and if it doesn’t, is it even capable of a Service Level Agreement that your business users would accept?
Does the application fail regularly now? Failing applications are huge generators of unplanned work. One of the tallest tasks for Bill in The Phoenix Project, by Gene Kim, Kevin Behr, and George Spafford, is to reduce unplanned work. Legacy applications are notorious for building knowledge silos. When they break, it’s typically your most skilled resources who must fix them. Since it is unplanned work, the fixes are rarely documented, and the cycle reinforces itself.
As your company grows and the laws change, so do the audit requirements. The question is whether you are capturing the data that proves you have been following company policies and/or the laws that govern your company. Note that I did not ask specifically if the system was capturing the data. Not all audits requirements have to be performed by the system. Even when it doesn’t, it sure does make those reports easier. If the data model is sound, then adding audit capabilities to a legacy application might not be all that bad. In other cases, the band-aid approach just won’t cut it or isn’t best long term.
Just as audit risks are important and costly, your system must continue to prevent problems in the present and future. In fact, because of the data breaches that have occurred, compliance penalties have become quite steep. HIPAA violations, for instance, can cost up to $50,000 per incident. In fact, some laws carry criminal penalties to individuals in addition to the fines imposed on the business. Are you sure your system is handling those social security or credit card numbers appropriately?
Whether it is partner access, employees working remotely, or cloud hosted services, companies are finding it harder and harder to be both functional and secure. As their systems become less isolated, legacy systems become more exposed to threats both internal and external. The older the systems are the less likely they have the appropriate countermeasures in place to reasonably protect the data.
Security risks can come from a variety of different places, typically called attack vectors. Some attack vectors are systemic – attacking a vulnerability of an older operating system or code that isn’t written defensively. Others are manual attacks preying upon our psychology – an email attempting to dupe an employee into divulging a password. Some are external attacks and others come from inside the organization.
As the value of new sources of valuable data increases, the amount of risk people are willing to take to get the data increases. Thus, the number and complexity of threats on your proprietary data will likely increase as well.
If your clients interact with your systems, then they are a factor in how your clients feel about your brand. All your touches should reflect the brand lest they negatively influence a key interaction. In some cases, it might be that competitors are innovating and your systems are holding you back. A recent client told us that their client liked their process hands down over the competition. They did a better job at what they were being paid to do. The problem was their system was so bad, they had to pay an incredible amount of overtime to their people just to get the data analysis to their client a day later than the competition. Competitors will never stop attempting to beat you at your own game, and clients will always expect more. Are your systems preventing you from staying on top?
This one is hard to explicitly correlate to your legacy systems unless it is really obvious – a high turnover rate, poor morale or direct feedback from your employees. While your systems with high user counts are certainly important, it is also important to think about the knowledge value walking out the door. It might be that those few key employees that manage those teams with that archaic order management system get fed up.
There is just something about using an elegant system that makes me more efficient. Unfortunately, according to the Kano Model, the features themselves are depreciating assets. Just like a home, the features that excite us today drift towards basic needs over time, and eventually the system needs some maintenance. Given the pace of technology, how many of those basic needs is your system meeting?
Most of the risks named above can also impact the brand image if the consequence is public enough. This can have a compounding effect that leads to lower sales and lost revenues.
Minimize the risk of growth. Can you monetize something you already have or are within short reach?
Adjacent Services or Products
Is your existing system holding you back from further monetizing your client or extending your process into a different market? A recent client explained that he had found a niche and built a service around that highly targeted market. Once they felt they had matured the business process, he started thinking about other markets that his process could apply – and found one. The problem was the system wasn’t designed to handle the slight differences in the other market, and changing the system might put the existing process at risk.
Monetizing the data generated by your business
You have been generating data for years. In fact, that is part of the reason why this system is slow – you have so much data. The quickest solution is typically to purge or archive the data. But, before you start purging to make those processes run faster, have you thought about how much that data might be worth? Consider what it would take to both efficiently run your daily operations and leverage the data generated in new opportunities. Would your clients want to know how they compared to the leaders in their industry? Would they be willing to pay for it?
Let’s say your system isn’t generating enough detail to monetize just yet. Don’t be quick to discount data that your system currently doesn’t have. There could be ways to calculate the missing data or modify the system to begin capturing that data. Forget about the system itself for a moment, how would the process or the input need to change for you to generate the data in a granular enough format to be valuable to other parts of your business or other businesses? Be careful not to impact efficiency or any of the other benefits listed at the cost of capturing everything. Remember, every input is a small barrier to entry.
Many of the recent high profile acquisitions have been driven by the prospect of further monetizing a captured audience, maximizing Customer Lifetime Value. The acquired companies are garnering enormous goodwill additions to what their balance sheets might depict. Could your systems capture the information necessary to be valuable to a potential acquirer?
Evaluating a critical legacy can be a daunting task if it isn’t painfully obvious that it needs to be replaced. Taking the time to document your evaluation can help keep the replacement process focused on what is driving the value you see in a new system, rather than the cool new features that are possible.