In my previous blog, I compared insurance to manufacturing (to a degree) and talked about the key breakthrough in insurance software—the separation of product from policy. But what is an insurance product, at least in respect to systems automation?
The typical scenario to avoid goes something like this:
- The business people pore over their filings and manuals and say this is the product we sell and issue.
- The IT people pore over program code and say that’s the product we have automated.
- The business people write up a lot of text in their word processing documents. They find a business analyst to translate it into something more structured but still text.
- The business analyst finds a designer to make the leap from business text to IT data structures and object diagrams.
- The designer then finds a programmer to turn that into code.
One version of the truth? More like two ships passing and it’s more common than you may think. How can organizations expect success when the product development process is not aligned? Without alignment, how can organizations expect market and compliance responsiveness?
What’s the alternative? It revolves around an insurance “product model.” Much like general, industry-standard data models and object models, a product model uses a precise set of symbols and language to define insurance product rates, rules, and forms—the static or structural parts of an insurance product. Additionally, the product model must also define the allowed actions that can be taken within the policy during the life of the contract—the dynamic or behavioral aspect of the product model. So for example, on a commercial auto product in California, the model will direct the system to attach a particular form (structure) for new business issuance only (actions).
For those of you familiar with object and data modeling, you know there are well-defined standards for these all-purpose models. For insurance product modeling, at least currently, such standards are more proprietary. I am familiar with IBM’s and Camilion’s models and of course there are others. It is interesting to note that ACORD now has under its auspices the Product Schema as the result of IBM’s donation of aspects of IAA. Might this lead to more industry standardization?
With product modeling as an enabler, there’s yet another key element to address. Yes, that would be the product modeler—the people responsible for making it work. Product modeling gives us the lexicon or taxonomy to do product development work but who should perform that work? IT designers with sound business knowledge? Business people with analytical skills? Yes and yes. We must finally drop the history of disconnects where one side of the house fails to understand the other. I’m seeing this new combination of talents work very well at one of our clients.
With a foundation of product modeling and product modelers in place, we can move to a more agile or lean product lifecycle management approach. Cross-functional teams versus narrow, specialized skills. Ongoing team continuity versus ad hoc departmental members. Frequent, incremental product improvements versus slow, infrequent big product replacements.
It all sounds good but what about the product source supplier, the bureaus? We’ll examine that next time.