Way back when, I started my career at one of those Big 8, then Big 6, then Big 5, then Big 4 intergalactic consulting firms. Coming out of college with an engineering degree, it was natural to start in the manufacturing industry. Learning about bills of material, routings, design engineering, CAD/CAM…ah, yes, those were heady days. And all those vendor-packaged, manufacturing ERP systems that were starting to take the market by storm.
Eventually I found my way into the insurance industry. One of the first things that struck me was the lack of standard software packages in the industry. I don’t mean the lack of software vendors; there were plenty of those. But software solution was a “one-off.” Or custom. Or some hybrid combination. “Why?” I wondered.
The reasons, as we know now, were primarily reflected in an overall industry mindset:
- A “but-we-are-unique!” attitude was pervasive. Companies were convinced that if they all used the same software then there would be little to differentiate themselves from one another.
- There was also an accepted industry-wide one-off approach. Conversations went something like this: “XYZ is our vendor. We really don’t like them. Taking new versions just about kills us. We don’t know why we even pay for maintenance. But we do.”
But the chief reason for a lack of standard software was the inability to separate Product from Process. What does this mean?
Well you can certainly envision that your auto product in Minnesota is handled differently than your homeowners’ product in California. I’m not just referring to the obvious elements (limits, deductibles, rating attributes) but also the steps required for underwriting, and renewal, and cancellation. Separation of product from process must go beyond the obvious rate/rule/form variations to also encompass internal business and external compliance process variations.
But there’s still plenty of processing—the heavy lifting of transaction processing—that’s the same and does not vary. For example, out-of-sequence endorsement processing is not something that makes a company unique and therefore would not require a custom solution.
Where the rubber meets the road, and where vendor packages have really improved their architecture over the last several years is by providing the capability in their policy admin systems for companies to “drop” in very specific product information along with associated variations into a very generic transaction system.
What’s next? Once product “components” are separated from the insurance processing engine (digitizing), and once companies have a formal way to define them (standard language), they can truly start making their products “unique” with reuse and mass customization.
Much like those manufacturing bills of material and routings looked to me way back when.