(Image credit: Shutterstock.)
Are you on the hook to deliver a major business system replacement? Or are you pondering the possibility of making one happen? Then let’s consider one of the challenges that sneak up on you when you decide to modernize and upgrade your mission-critical applications and systems.
How do these situations arise? For the purposes of this article, I’m going to talk about replacing an abstract “downstream” system—a dependent system, a system that consumes data—as opposed to an “upstream” system—a core or foundational system that defines the pillars of the business. The poster children for upstream systems in insurance are producer and policy management systems, but there are others—G/L and HR systems also qualify. They are the systems of record for their particular domains. They own their own processes and data. They don’t depend on any other systems or processes to function.
An example of a downstream system might be your incentive compensation management system that calculates commissions and bonuses for your producers. The incentive comp system must consume data from several core systems and other downstream systems in order to work. Reporting systems and data warehouses are also downstream systems, not to mention the book-of-business management system that is so near and dear to my heart. Architecting solutions for downstream systems shines a brighter light on the unexpected challenges of system upgrades and replacements. But while I’m talking about a downstream system replacement in this article, the same considerations also apply to an upstream system replacement.
So, let’s assume there are some inefficiencies in your IT ecosystem that cause enough heartburn and pain that you finally decide that SystemX has gone as far as it’s going to, and that it’s starting to be a speed bump for the rest of your processes. Time to pull out SystemX and put in your favorite vendor’s hot new HyperTurboMatrix product that does what SystemX does, only better, faster, cheaper, and easier. It’s an investment in the future, and it’ll streamline all the processes around SystemX with newer, more modern thinking and design. The vendor said so, so it must be true. Great—let’s get started on the SystemX replacement project, then! But before we install any new software, let’s take a moment to look at how SystemX came to look the way it does.
When SystemX was implemented by either a vendor, an integrator, or your own staff, it was the right tool at the right time in the right place. It did what it was designed to do, and presumably it did it pretty well, or at least as well as a system from its era could do it.
Genesis of a Complex Ecosystem
But systems don’t live in a vacuum—they have to coexist with all the other business systems they touch. Even if SystemX was a lean, mean revenue-drivin’ machine when it first got plugged in, the systems and processes around it necessarily changed over time to reflect changes to the business and the market the company addresses, and SystemX necessarily changed to reflect those changes too. Systems swing their elbows to make room for themselves, and they reach accommodations with other systems to play and share well with each other. And business processes grow around the limitations and idiosyncrasies of the systems they use to manage their functions. A complex ecosystem arises, and, given time, it starts twisting itself together organically to move the business forward.
Now, let’s pull out the SystemX puzzle piece and drop that shiny new Hypo-Turbo-Matrix into the picture. A system so well designed and built that it can’t help but make your business more efficient than you ever imagined possible.
Unfortunately, there might be a bit of a problem here. The HyperTurboMatrix was architected and built around best industry practices, sensible data modeling, and modern workflows. The business processes and system interactions that organically grew around SystemX, with all the data transformations that were built, all the business policies and procedures written around SystemX operations—well, they don’t fit as neatly inside the HyperTurboMatrix as they did when SystemX was in place—the systems aren’t the same shape and size. Not that anyone would ever say SystemX was better than the new ‘Matrix software – it wasn’t. But now half your business policies and procedures aren’t applicable anymore, some of them are actively counterproductive, and the ‘Matrix is not happy with the data it’s getting. Maybe the ‘Matrix would fit your situation more neatly if we knocked a corner off and glommed it onto the lower edge with duct tape to hold it in place, but, then again, it might not. More importantly, why would you vandalize a brand-new system to make it look exactly like your old one?
Be Cognizant of Disruptions—Good or Bad
Start the modernization process by examining the business operations, policies, and procedures wrapped around your existing SystemX. Think about whether they are in place because that’s how you want your business to run, or whether they are there only because SystemX couldn’t function in the same time zone as SystemQ without them. In other words, figure out which unexpected bits you are going to break while you are fixing your operations. Then think about defining your future state to reflect best practices and business optimizations, not system limitations. You might not be able to get all the way there during this project, but this kind of thinking will prove to be valuable as you move forward. No one—least of all a company trying to sell you modern and enhanced business systems—would ever suggest that you shouldn’t do system modernization and upgrades. You absolutely should replace systems when you see the opportunity to enhance operational efficiency or compliance, produce additional revenue, or limit expenses. But go into it with your eyes open, and don’t treat one SystemX as a drop-in replacement for a different SystemX. You have business processes and system interactions that are built directly on top of your existing SystemX, and you have to be cognizant of the disruptions—good and bad—that replacing it will bring.
And here’s a pro-tip: the time for this analysis is before you assemble the implementation project team, not during User Acceptance Testing three days prior to your system go-live date. The earlier you do it, the happier you’ll be!