Kool-Aid, Configuration and CF

Weekly Rant - Kool-Aid, Configuration and CF

Created by Chet Gladkowski at 17 Jun 2013 @ 23:01

In the web sites, blogs, sales literature and completion of many an RFP, the near universal and ubiquitous answer to just about every functionality question is "part of base system, achieved through configuration." In a recent interview, a prominent industry consultant stated that we have "drunk from the kool-aid of configuration" as the solution for insurance specific functionality.

While configuration tools are an important component of an overall insurance software solution, they are not the end-all solution. They windup being a "hammer" while every problem looks like a nail.

In this week’s rant, we explore configuration, its pros and cons in light of an overall approach. But knowing where the problem is does not equal a solution.

Have you looked at various tools? Tell me about your experiences with them. Join in on the conversation!

You do not have permission to post on this Chatter.
Login Create Account
Thanks Alex - I call it the "consigliere" role (from The Godfather) when I help insurance organizations and vendors accomplish clear communication, ask the tough follow-up question, call someone out on a "BS" answer. I "make them an offer they can't refuse."
Bingo - it cuts both ways. Vendors will always take advantage of a question that is too vague so the buyer needs to be more definitive in the way they ask
Sam - while the vendors are "guilty as charged" about what systems actually "do" and "don't do" the buying insurance industry (companies, agencies, MGA's) need to do a much better job at (1) asking the right functional questions and (2) probing/pushing for greater clarity. Example - I was in a meeting where an insurance executive asked a vendor if they handled reinsurance. The vendor responded that they did and the conversation moved on. I later asked the insurance exec what they thought handling reinsurance meant and they wanted the system to automatically calculate both the ceded premium and potential claim recovery through multiple layers of various types of agreements/contracts, sending and reconciling reinsurance reports and bills. The vendor's definition of handling reinsurance was to identify policies for reinsurance, no reports or bills, no claims, no interfaces to financials. Needless to say that there was a very heated conversation later on
Samantha and Chet - you are both correct. Vendors no doubt use the configuration "excuse" to cover gaps, flaws and missing functionality. I've see it many times. But as Chet mentions there are also very legitimate uses of config that are best for company specific requirements. If vendors were more forthright about their system capabilities it would be easier to distinguish the two scenarios.
Samatha - it's a bit more subtle than that. Here's an example: A policy system allows you to rate and issue policies, but your company does not write certain coverages along the coast. And the distance to the shore that you use might be different than another company. How do you make your system do that? Answer - configuration. Vendors allow companies to write "business rules" that look at data and make decisions (if more than 4 miles from the coast - then underwrite, if less than - don't.) Does this make sense?
Seems like "configuration" is just another way of saying: "we don't do that now, but we could."
thanks Jeff - yes, there is a balance and the pendulum has certainly swung towards "configuration" as the cure-all. It's the only way to assure that a solution is not eliminated from a selection process due to saying that they don't do something. Insurance organizations (carriers, MGA's, agencies) need to change the way they do business to a more simple, straight-forward approach in order to become more efficient, leveraging technology more effectively across their organization and throughout the insurance ecosystem.
Right on Chet. My former company built software that was very impressive because it was highly configurable and rules driven. That was both the good news and the bad news! While the product could certainly be "taught" to do just about anything, it seemed that it had to be taught to do just about anything! And that meant too much time and too much money for the vendor and the client. And testing/QA was always a struggle because business rules and configuration require a lot of documentation and case-construction for testing. Some things just work better "out of the box" and as vendors we need to default to that position once in a while as well, especially for the industry-standard core processes.
Title Kool-Aid, Configuration and CF
Creator Chet Gladkowski
ML ID 12241
Printer Friendly View
PDF Version View
Email This View
Created 17 Jun 2013
Updated 01 Sep 2014