Since we launched Sentro, we’ve spoken with hundreds of insurers. Most of them feel trapped by old systems that they are using to run their business. They see their competitors innovating, and they are justifiably worried about losing market share. They truly want to make change and modernize their products and processes. But many of them don’t really know where to start.
The insurance sector is driven by mergers and acquisitions. The inevitable by-product of mergers and acquisitions is a patchwork quilt of overlapping systems and processes.
The green screen COBOL policy admin system from the 1980s over in the corner that has been chugging away for decades does what it does, but nobody really knows how it works anymore. Finding COBOL coders is near impossible, and even if the code is kept up to date, it is hard to integrate with other systems and processes.
Over time, insurers accumulate multiple systems. The ‘systems mega-rationalization projects’ often delay or fail, so then it falls to the operations teams to invent manual processes or work-arounds to keep business running.
Now, M&A is a perfectly valid business strategy in the insurance sector, so it won’t go away any time soon. Yet we see insurer after insurer fall into the trap of trying to unify every IT system in the business after an acquisition.
We believe your project success rate can improve by asking the right questions.
Insurers often get themselves into the legacy systems trap by writing their own custom systems. While it brings the benefit of full control, it also brings the full cost and obligation of ongoing maintenance and enhancement. (Yes, I’m looking at you, COBOL policy admin system in the corner).
We don’t find many insurers today looking to replace a custom-written administration system with another custom-written administration system. 9 times out of 10, the insurer will look for commercially available application software that can be configured or extended to meet their needs.
So far, so sensible. But change projects can often go off the rails as plans are made to integrate the newly acquired system with other systems and processes.
Just because you can integrate a system or a process, doesn’t always mean you should.
Integrating different systems is a serious undertaking. Now you need to ensure that different code bases work well together – changing something in one system could break the integration with the other system. It is not as heavy a burden as maintaining the entire application, but it is a burden nonetheless.
So before you take this burden on, it is worthwhile (and inexpensive!) to ask yourself a few key questions. These will often tell you if an integration is worth building.
Is it an enterprise architect? Is it a strategy executive? Is it the front-line operations team? Is it your legal team? These will give you important clues to the business motivation. There is no ‘wrong’ source for someone wanting more elegant integration between systems. However, the business reasons they will be advancing will often be very different.
This is where an open mind, empathy, and a solid knowledge of how your business actually works is critical. Ask open questions like ‘How would you cope if we didn’t build this?’, ‘How would this benefit a customer?’, ‘How would this reduce our business risk?’. Make sure you involve experts from different functional parts of your business in this process, in particular front-line teams that are dealing with your customers. Drill down and keep asking ‘why?’ until you are collectively really comfortable with the rationale.
This is where your technology team, vendors, and business teams really need to come together honestly. If the proposed integration is between a green screen COBOL system with no API capability and a flat-file data structure, and a new system with APIs and more modern data management methods, you could spend a year trying to build some integration capability into an old system that is likely slated for replacement anyways.
Here’s an example from our world of group insurance. Let’s imagine that the business imperative is to launch a new group cyber insurance product. The incumbent green-screen COBOL policy admin system runs a group life and a group health scheme, but it is not capable of being changed to support the new group cyber scheme. The customer selects our system to launch the new group cyber product, but doesn't want to launch it before building a full integration with the old incumbent COBOL system.
In a situation like that, we would often encourage the customer to run two group systems for a period of time. Run your existing group business on your existing platform, and run your new group product on our platform. Then, rather than build an integration, gradually migrate your existing life and health business onto the newer platform, at a time that makes business sense. That way, you get your new product into market more quickly, at lower risk. If the customer insisted on an integration, we would point out the time cost, financial cost, and opportunity cost of not being in market while an interface was being built.
Each situation is unique. My point here is “degree of difficulty” needs to part of the decision-making process around integrations. Systems with a range of integration options and a rich set of API services are low “degree of difficulty” integration candidates. Systems without these options and services are high “degree of difficulty” integration candidates.
Many business users incorrectly assume that today, any system can easily be integrated with any other system. Technology teams eager to serve the business often won’t say “it’s too hard and will take a year”, fearing that the project will just stop dead if they do.
A credible vendor or systems partner can often broker the difficult internal conversation about how hard or risky something might be technically.
It should be obvious that when choosing any new commercial system, you should always be looking for a “low degree of integration difficulty” application. As you gradually replace “high degree of integration difficulty” systems with “low degree of integration difficulty” applications, your overall business agility and responsiveness will improve.
Insurance is still quite a ‘batch-y’ kind of business. Policies renew, invoices get generated, on predictable and infrequent cycles. So the value of building “real-time” interfaces between systems should always be carefully considered. There are often different ways to achieve the result you want.
Maybe a better solution is to improve an existing feed to a data warehouse and business analytics tool, to provide the “joined up view”, rather than integrate systems. Maybe that annoying manual process can be semi-automated with a bit of effort, reducing the hassle. It is worth exploring all the options you have to get the job done before settling on an approach.
Will the integration improve quotation turnaround time from 6 days to 2 hours? Will it allow a service agent to support 50% more customer queries? Does it enable a business partner to self-serve and support your customers 24/7? Always look for the hard business metrics around a potential integration.
Early in my career, I saw a business spend $400,000 to automate an annual table update with three data values in it – something that a human would spend 10 minutes typing in once a year. If they had asked themselves the “how does this benefit the business” question they would have realized that the integration was a huge waste of money.
Remember, just because you can integrate something, doesn’t always mean that you should!
Integrations that noticeably improve the customer experience should get extra credit. Too often, integrations only focus on making the jobs of the internal teams easier. If an integration can enable a better customer experience – it can be golden. Just remember to involve some customers in that value assessment!
Just like countless sports stadiums worldwide, far too much emphasis is put on the cost of construction of an interface, and not enough is put on the cost of operation and maintenance.
Take the time to honestly understand what it will take to make your integration go, and what it will take to keep it up to date. Ensure that both technical and operational costs are considered.
This is of course difficult to forecast, but if the functional area of the business changes frequently (eg lots of product change, lots of regulatory change, lots of acquisition activity) then investing in a “high degree of difficulty” integration may not have such a good payback.
After really examining the business rationale for an integration, you may find that your projects actually need fewer of them. This will keep your project scope tighter and let you deliver value more quickly. Instead of trying to eat an entire elephant at one sitting, look for ways to keep the "change chunks" more manageable and digestible.
Once you feel the buzz of successfully implementing smaller scale change, your business will get better and better at implementing bigger scale change. Try to give yourself every chance of being successful when implementing change – it is not an easy thing to do well!