By Brent Martin
It’s tempting for large, long-established companies to want to throw out old systems and trade them in for something new on the fly. After all, startups can create a new company and have grand, efficient systems in place in a matter of months. So why should it take an established corporation sometimes years to modernize your enterprise? Well, a number of issues plague the incumbent.
As a seasoned company with hundreds or even thousands of employees, you’re not inventing something from the ground up. Systems and contracts have been in place for decades, or as in the case of Hertz, a century. The processes have been working—whether efficiently or not—for many years and your employees have gotten used to them. Old systems typically have fairly efficient (if not brittle) processes. Sometimes, IT has helped optimize those processes, but often your business has built bolt-on tools using whatever technology is available (MS Access and Excel are popular). IT has found ways to write macros to automate formerly manual data loads. Little documentation typically exists for such things, putting the you at a disadvantage.
Those processes can’t be tossed out overnight and replaced with something new the next morning. You have to consider the way employees work and how departments interact with each other. Those processes have to be thoroughly understood in order to be reworked.
Hard-coded business rules that are in the code itself are tough to unwind. You need someone familiar with the older programing languages and with the business processes well enough to understand what these rules are and how they might be implemented in a more modern system.
Many times, legacy applications have taken on functionalities that they shouldn’t be supporting. Over the years, they have been tweaked to do things they were never designed to do. Maybe a kind programmer in the early 90s figured out a way to make the system perform a task that it wasn’t designed for, saving the company money at the time but kicking the need for a better system down the road.
For example, consider a straightforward hotel planning system that manages budgets and forecasts in a straightforward manner. At some point in the past it may have been extended to manage the hotel catering business because an influential hotel owner insisted on it and a benevolent programmer just wanted to help. Now that it’s time to replace the system, those changes have become necessary functions that will need a home in the new system.
In fact, these changes have contributed to what has come to be known as technical debt, a term coined in 1992 by Ward Cunningham, who is the programmer credited with creating the first Wiki. Modernization projects have the option to either do a quick workaround to get things up and running as soon as possible or to spend more time upfront to create a long-term solution. According to Techopedia, “In development, releasing code as a quick and easy approach is like incurring debt – it comes with the obligation of interest, which, for technical debt, comes in the form of extra work in the future.”
In any modernization project, it’s natural to want to push to have things done as quickly as possible. In the case of incumbents, it looks like those new guys are beating you at the efficiency game. But remember the lesson of the Rabbit and the tortoise. Even in today’s fast-paced business and computing world, that lesson still holds true. Slow and steady has its advantages. And remember that your company has many advantages that startups don’t: name recognition, long-time employees with years of expertise and know-how, capital assets, strong business relationships, established credit channels, and more. Sure, new companies may be nimbler, and it may take more time to turn your ship around, but you’ll want to do it right.
Startups may be incurring their own technical debt, and in the long run, they will fall behind because they lack the advantages Incumbents have. Avoid incurring any more technical debt and take the long-term view of the game, realizing that technical debt can be incurred by good programmers working under unrealistic deadlines.
New startups don’t have to worry about managing a lot of historical data, but you do. Existing systems contain huge amounts of data that must be maintained to fulfill certain legal obligations. The Sarbannes-Oxely Act requires organizations to retain data for seven years in the U.S. and ten years in Europe. You need to figure out ways to make sure that data is converted to the new system that you plan to implement, or at least archived in a way that is easy to retrieve and that will satisfy end-users and auditors alike.
Data in these legacy systems is typically poor. You can typically expect problems with referential integrity. For example, there can be multiple fields that mean the same thing in a single application. And different legacy systems may call the same thing by different names (or worse yet they may even use different values). If you want to replace all these systems, you have to understand that the lack of standardization will be an impediment that significantly slows down the process of any new ERP project.
Additionally, existing purchase orders have to be fulfilled and customers have to be converted to the new system. You can’t just drop the data regarding these orders and existing customers. You’ll never get them back. A smooth transition into the new system must be made so that your current customers and existing business are not adversely affected. Otherwise, they may go running to the new guys who don’t face the same obstacles that you do.
As with applications, existing technology can’t just be tossed aside. You’re already significantly invested in that server and networking system. And your IT department is familiar with it and adept at fixing any problems that come up, even though the versions may be older than your first child who just graduated from college. Some of your team is trying to keep the lights on with that stuff until you work your way to the new system. You can’t just rip it all out and start over, no matter how old it is. Startups have the advantage of starting with the latest and greatest from the ground up to the cloud.
Large corporations have the competitive advantage of name recognition in many markets worldwide. However, when it comes to modernization, the flipside of the coin is that each location around the world may have developed its own processes for doing things. In Dublin, the process for renting out cars may vary significantly from the same process in Sydney. London may have a different Identity Management system and Singapore may enjoy a robust AP Automation package that brings its own integration challenges. Those differences in localities have to be understood and taken into account in corporate-wide modernization efforts.
Unlike a new startup, incumbent corporations aren’t hiring new resources to fill roles that are perfectly suited to a shiny new software system. You have folks who have been working hard for many years under the same system and have grown accustomed to it. As you know, people are often creatures of habit. Many like to have things done a certain way, and they will become uncomfortable if too many changes happen all at once.
Therefore, managing organizational changes is a big part of any modernization project. You have to offer training and say, “Here’s what we’ve been doing, here’s what we are working towards.” You’ll need to offer re-training keeping in mind the old adage that it’s often harder to unlearn something than it is to learn something new. It will be a large part of the job to bring your employees on the journey along with you.
Of course, it is a worthwhile and necessary journey. One that will not be easy, to be sure, but one that must happen nonetheless if you are to stay competitive in the world that seems to favor the startup.