We love the periodic notices we get from various entities with which we work in our personal lives, entities like banks, mortgage companies, auto-finance companies, credit-card companies, and others. They typically go something like this:

PLEASE NOTE: Our system will be shut down for the Holidays. As a result, it will be offline from New Year’s Day to Christmas Day, during which time you’ll be unable to check anything, schedule anything, pay anything, or withdraw anything. We apologize for any inconveniences this may cause you, including but not limited to headaches, bouts of anxiety, defaults, foreclosures, repossessions, liens, derogatory credit reports, or Nasty-Grams from any of your creditors. Have a nice day.

We’re a software shop. We get the fact that software and systems upgrades are necessary and always will be. But does their timing have to be arbitrarily predetermined? And if we extend the necessity of upgrades from our personal lives to our businesses, what does that timing actually have to do with your business and its needs?

Everything.

It’s About Time

Every provider of every kind of software or system to any kind of business in any industry has to provide things on occasion — upgrades, updates, patches, bug-fixes, new versions, and whatever else might be necessary. If those providers ask you anything at all (sometimes they don’t), they usually ask just two questions:

1. Are you ready?
2. How ‘bout now?

We think a few other questions might be in order:

• Do you need it?
• Do you need it now?
• Do you have other, more important operational considerations right now?
• Do you know when the upgrade will help you the most or be most advantageous?
• Will you let us know?

That might not be the best way to go about things, but it seems to be the most beneficial.

Common Sense

We don’t know why common sense seems to be so uncommon. But we do know it makes sense to let customers have upgrades at the right time and to let them determine the right time.

Upgrades on your time. That seems pretty common-sensible.

According to dictionary.com, infrastructure is defined as:

1. The basic, underlying framework or features of a system or organization
2. The fundamental facilities and systems serving a country, city, or area, as transportation and communication systems, power plants, and schools.

The insurance industry typically considers infrastructure to mean the technological architectures within which hardware and software are purchased, deployed, run, and maintained.

Considering the fact that we couldn’t find any people in that definition — and since we haven’t reached the point at which AI and RPA enable hardware to purchase and install itself or software to program and implement itself — we think it’s a little narrow. Nor does it allow for the fact that software enables people to contribute to their organizations intellectually, as opposed to menially and mechanically, by automating menial, repetitively mechanical processes.

Infrastructure v2

We think we can (and should) give infrastructure a broader, more all-encompassing definition. Something more like this:

The resources, human, financial, and technological, by which the enterprise constitutes, operates, and sustains itself.

If we choose to define infrastructure that way (life is about choices), a number of productively beneficial things will happen:

• We’ll define requirements for hardware and software more completely and accurately because we won’t forget the people who have to use the hardware and software we procure and deploy.
• We’ll be more likely to procure the hardware and software that will be most beneficial their respective organizations because we won’t forget the people who have to use the hardware and software we procure and deploy.
• We’ll achieve more favorable outcomes because we won’t forget the people who have to define, procure, and use the hardware and software we procure and deploy.

One More Thing

The notion of people, product, process used to be so popular there were graphics and videos created to promote it. What happened? We don’t have any intentions of selling products short — ours or anyone else’s. But the idea of products without people to buy, use, and benefit from them is curious and shortsighted at best.

“The bots are coming! The bots are coming!” has become the latter-day equivalent of “The sky is falling.” We know the bots are coming. They’re inevitable. They’re even beneficial. But the activities they perform are programmed — by people. They’re not the result of spontaneous, inventive, electronic ingenuity.

We don’t have to broaden or our horizons all that much to make sure our definition of infrastructure is adequately inclusive. All we have to do is include people.

That’s just one more thing. But that one more thing is the most important element in the definition.

Let’s do it.

—
People, product, process image © videoblocks.com.

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?