There are several factors to consider when beginning a business intelligence implementation. Much depends on the maturity of the BI platform, according to Qasim Hussain, senior architect for the technology consulting firm X by 2.
Insurers also need to remember it’s better to start small rather than big, adds Hussain.
“There definitely is a learning curve when it comes to new tools and a comfort change needs to happen with business and IT,” he says. “In the past [business users] may have done a lot of one-off reports, but when you start talking about a modern BI platform it gives you the flexibility to do a lot of ad hoc reporting.”
Hussain also believes it is better to start BI from a departmental perspective and try to get those processes adapted to the new technology and the modern paradigms before you start to take on a huge initiative.
“If insurance carriers take on fairly large-scale initiatives there are a lot of learning curves,” he says. “Those implementations take longer and frustrate the business because they are promised something that will be useful to them within a year or so and the project often ends up taking years to build.”
Depending on the size of the carrier, most of their policy and claims data exists inside a legacy system, points out Hussain.
“Carriers should be mindful that trying to build an analytical platform would mean that they would have to go through some significant data cleansing—especially with legacy systems—because there is a lot of redundant data and the transactional systems don’t have good checks in place to ensure data integrity,” says Hussain. “As you build an analytical platform you face a lot of data quality issues. [Insurers] should not underestimate that effort. Data quality is the major issue that burdens the development of a business intelligence platform.”
Hussain believes insurers need to take measured steps to approach the business intelligence problem, suggesting the core domains are the first place to start.
For example, an insurance carrier might have three policy systems for different lines of business. The goal would be to bring them all together into one system.
“You can do some trending and analysis over lines [of business],” says Hussain. “If you have that situation, though, you should realize the biggest challenge is to bring together a common definition of policy because these three systems, even though they are all policy systems, have their own way of defining a policy. The tools will not help you there. You need to know the plan for that effort and put adequate resources in place so the problem can be solved the right way.
Defining terms like policy, defining a person, and defining other concepts are core foundations that the BI platform will be built on, so Hussain points out it is critical to get them right.
“The business doesn’t want to wait,” says Hussain. “They see [BI] as a competitive advantage and they are eager to get the modern platform in place so they can get rid of ad hoc reports. Ideally there should be one policy system so there can be one definition. In my experience, large carriers typically have multiple sources and trying to reconcile them is a challenge.”
Hussain has seen success stories where insurance carriers use industry-specific BI tools, but not in all cases.
“You can get a good running start, but what you have to be leery of is whether you have enough data to feed the model,” he says. “You have to make sure the models [vendors] offer align with the way you think of certain core domains like claims or policy. That upfront work will help you get a good running start or you’ll get stuck in the endless loop of merging two different worlds.”
The Best Way
From personal experience, Hussain believes starting small and then building up to something big is the best approach to BI rather than trying to solve the whole problem in one big step.
“In the BI world, traditionally it’s been more of the waterfall type development process,” he says. “By the time you get the requirements designed and the models done you’ve spent a significant amount of time thinking about the problem without actually delivering something that is useful to the business. The shift should be to a more agile or iterative approach where you take a small chunk, release it to the business, get early feedback as to whether it is meeting their expectation and adapt as you go along.”