We’ve never conducted any kind of formal or official poll on this. But we’re willing to bet that if we asked most insurers and their employees if they considered their software to be an asset to their organizations and their people — or some kind of threat or liability — the majority would say the latter. Notwithstanding our own (hurt) feelings, that’s just not right. And vendors may be as much or more responsible for those sentiments as insurers.

What if, on the other hand, insurers considered their software to be an unconditional asset? And what if, rather than a threat of a liability, their people viewed the company’s software as helping them to make more valuable contributions to the organization? What if they saw the software, in fact, as a source of job security, helping them to make more valuable contributions to the organization, thereby increasing their value, their longevity, and their satisfaction? Would that be some kind of a pipedream? It shouldn’t be.

Higher Table Stakes

Insurance technology has advanced to the point at which configurability is an entry card. If their software doesn’t come with configuration tools, vendors won’t get a seat at the table, let alone be in the game. Those configurations tools free the people in IT departments to create business value — assess technologies, align IT with business goals, develop and maintain resilient, secure infrastructures. Given the rate at which configuration tools continue to advance, it’s not hard to imagine a day in which any BA can install any core-processing software in any insurance company. Another pipedream? Don’t be so sure.

The efficiencies enabled by software already reduce redundant data entry, while the portals provided by software allow increasing degrees of self-service and reduce the need for heavily staffed customer service departments. And if those efficiencies reduce the need for people to perform mundane, menial, and administrative tasks (they do), that means those same people can contribute more value to their organizations in higher-level, revenue-generating, risk-managing, and loss-mitigating positions. Call that a pipedream if you like. But it’s as inevitable as it is desirable.

Here It Comes

That sensation you feel is the rush of progress. The pipedreams are over. The future is here. And it brought reality with it.

Get ready, or get left behind.

In the insurance industry, which is highly regulated but stubbornly non-standard, we seem to spend a lot of time explaining ourselves, don’t we? Do you ever wonder why? We have a theory:

We think it’s because of human nature.

As human beings, we’re not terribly interested in smallest, slowest, oldest, least capable, or most common. Give us bigger, faster, newer, most powerful, and avant-garde and we’ll be there every time. And so it is we find ourselves having to explain terms like insurtech, innovation, and disruption.

Words Matter

The insurance industry has been using technology for decades — from the mainframes of the 1940s to the databases of the 1960s, from Univac to IBM, from COBOL to Java, from client/server networks to the cloud. Insurance may not have been the first industry to adopt it. But adopt it we did. In that context, insurtech is just another term for what has always been insurance technology.

And pardon us for saying so, but — while the insurance industry is gradually adopting technologies available to all industries (AI, robotics, machine learning, and telematics) — there hasn’t been any new processing technology to speak of in insurance for at least a decade. And even if there were, we wouldn’t know what to do with it yet, given the nature of technology adoption and the (justifiably) conservative nature of the insurance industry.

We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run. (Amara’s Law)

Give Us Our Change

And then we have innovation and disruption. We don’t mean to make light of this war of withering words. But in circumstances like these, we have to leave room for a little humor, don’t we? If not humor, at least a little curiosity. So, here’s an experiment you can try at the next conference you attend:

Walk into the session entitled, “Disruptive Innovation in InsurTech”. Let everyone in the room off the hook by not asking them to define insurtech. Give them the benefit of the doubt and presume their perspectives on disruption are positive; that is, they generally assume disruption to have a positive outcome, rather than a calamitous one. Then ask them if they can tell you how innovation and disruption are different from change.

In the ensuring silence, tell them you’d like your change back.

We Have Work To Do

Our facetious levity notwithstanding, there’s serious work to be done in the insurance industry. So, rather than trying to decide which came first — the chicken or the egg; insurtech or constructive pragmatism; innovation or change where it’s needed; disruption or calm, shared progress — maybe we should talk about what needs doing right now.

We have no idea what tomorrow’s jargon will be. But we’re positive insurers have to do business today.

Let’s put our faith in practical experience and plain language to get it done.

If we were given the choice of eliminating one word from the language, it might be proprietary. Aside from the fact that it could mean as many things as there are people who want to consider whatever it is they want to consider proprietary, the term is particularly problematic when it’s applied to data.

In the insurance industry, to cite just one example, system replacements are nightmares in part because of the data they contain. First that data has to be converted; that is, the data from System A has to be changed into a format that plays nice with System B. Then the data has to be normalized; that is, it has to be organized into columns (attributes) and tables (relations) to reduce redundancy and improve integrity. After that, it has to be standardized; that is, similar data in dissimilar formats has to be changed to a common format that enhances the comparison process. So, North might change to a value of N or n, without overwriting the original format: North.

Are We Nuts?

Albert Einstein once said, “In theory, theory and practice are the same. In practice, they’re different.” Given that, it might be safest to consider the possibility of one common data language for all insurance systems, companies, and transactions to be more theory than practice … at least for now. And it would almost certainly require the elimination of proprietary as it pertains to insurance data. (Proprietary should not be confused with private. Proprietary is a bugaboo and a detriment. Privacy is a necessity and an asset.)

Speaking of theory, what if someone developed an English-like, WYSIWYG language for creating and deploying business rules in your software? What if that language minimized data-entry and service-staff requirements? And what if that language enabled your data to say what it means and mean what it says?

The very suggestion might be nuts. But it can’t be any nuttier than the proprietary means by which the insurance industry has historically treated, converted, normalized, and standardized data.

One last question: What if that language were more practice than theory right now?