Cause and Effect

Since we’re in the insurance-technology business, we tend to bristle a bit when we hear and read things about the insurance industry’s ostensible lagging behind some other industries in the adoption of technology. Granting the existence of such lagging, why do people assume it’s a symptom of technology aversion, as opposed to, say, good business sense?

“Well, if you look at retail, that industry uses technology for data acquisition, marketing, consumer targeting, customer acquisition, and increased sales. Retail even uses video surveillance and facial recognition to monitor customer behavior!” Point made. But …

How Do You Spell Risk?

Some people might put life, auto, and homeowner’s insurance on their shopping lists. But it’s not likely any large commercial risks or core administration systems will appear on those lists. By the same token, retailers surely have product-liability standards to uphold and commensurate liabilities to disclaim. But they don’t have to comply with stringent national and state-specific regulatory requirements to which insurers are beholden. And while retailers certainly have to manage risks to inventory and customer safety, those risks are of a completely different nature from the ones that define insurance.

In addition to having to take into consideration such things as behavioral trends, actuarial tables, risk profiles, geographic locations, and more, insurers have to protect policyholders’ privacy. Neither do they have the luxury of imposing retail mark-ups or selling policies at bargain basement rates, given the fact that, among the regulatory requirements they have to fulfill is mandatory reserves against claims not yet incurred.

Reality Check

“Well, insurance hasn’t changed much in the past 50 years.”Right again. In fact, it hasn’t changed much since Hammurabi invented it. But a peek below the rhetoric reveals there are reasons for that:

Stability and caution breed the trustworthiness that equates to longevity in the insurance industry. The expression, “Insurance is sold, not bought,” remains stubbornly true, regardless of the fact that most of us need it. And policyholders (understandably) demand more, requiring insurers to provide more, with attendant costs, from already thin margins.

So, yeah. Insurance lags behind some other industries in piling on the technology bandwagon. It’s true. But before we say that disparagingly, let’s understand why it’s true.

After all the benefits of good business sense get passed on to us in the premiums we pay and loss protection we get.

Keep the Change

We’re nearing the end of 2018. If you’re a regular reader of this blog, you might be tempted to think legacy replacements are behind us by now. But you’d be wrong, in part because technology is the least of the challenges we face. A bigger one is change management. And change management is all about people.

Here’s the short list of things that need to be managed with people in change:

  • It’s one of the more frustrating parts of human psychology that we prefer devils we know to those we don’t. That’s why our Suite is developed with input from our users.
  • If people prefer to do things thisway, they’ll resist doing them thatway. That’s why our Suite is easily configurable.
  • Legacy systems are likely to be connected to myriad systems, data sources, and people. That’s why we do our homework before the contracts are signed.
  • Expiration Dates. Nothing lasts forever. But if you didn’t plan to replace your legacy system, the change is that much harder. That’s why we earned our development and delivery stripes before we founded Finys.
  • The Secret Code. Okay. It’s not really secret. But building, adding, and automating business rules can seem daunting. That’s why we created an English-like common language to preclude the need for translating terminology and data and to eliminate inefficient layers of communication.
  • Investing in a new system doesn’t negate the value of legacy IP. That’s why we enable our customers to fully leverage our IP, even as we migrate their legacy IP and data.
  • Idle Hands. Downtime, non-productive people, and lost revenue are significant challenges. That’s why we work with our customers in our virtual Design Lab to create workflows, establish functional objectives, and teach them how to configure the Suite, products, and LOBs.
  • Fear of change can be paralyzing. That’s why we dedicate teams to our customers before, during, and after implementation to support the roles of their people and to make sure they know everything they want to know when they want to know it.

Go With the Flow

In a 1789 letter, Benjamin Franklin wrote, “In this world nothing can be said to be certain, except death and taxes.” In the 21st-century world, we can safely add change to Dr. Franklin’s list. It’s as unavoidable as it is inevitable. Its pace will only quicken and its magnitude increase.

Since we have to keep the change, we may as well manage it effectively.

Digital Transformation? Really?

We recently came across the 2018 edition of Top Issues: An Annual Report from PwC. Given the accelerating rate of change, we were quite interested to see what might have transpired since the Report was issued in December of 2017. On page 5, we found this:

The companies that … design and implement digital platforms … will be the most likely to quickly adjust and grow as the industry continues to become more digital.

While a little vague, that seemed to make sense. After all, the Internet, on which business is increasingly conducted, is a digital medium. And the companies that don’t adapt to all channels of digital accessibility, including mobile, inevitably will be left behind.

But just five pages later, the Report said this:

Most of the industry has adopted digital agendas.

Okay. So, what’s left to do? Much.

Let’s Narrow it Down

One of the most constructive things we might do is ignore all the commotion about digital transformation. While organizations might need to transform (more likely they need to adapt and evolve), digital transformation has become all but indecipherable because it can’t be defined consistently. And it can’t be defined consistently because it’s too broad and, so, too vague.

More important, digital transformation is almost always interpreted to be about technology. It’s not. Here’s why: Unless we manage to experience some kind of once-in-a-millennium event sometime soon, there won’t be any technological transformations. But what we do have is a data transformation.

More specifically, with the digitalization of data — and with the technological progress we’re making in storing, extracting, analyzing, and applying data — that’s a transformation worth heeding and on which we should be capitalizing. And it feels like progress.

What Can We Accomplish?

From risk analysis to claims experience, from risk selection to loss mitigation, from consumer trends to policyholder profiles and more, everything we need to affect real transformation is in the data we collect and process every day.

Yes. We’ll require technology to aggregate that data, to extract and report what we need from it. But that won’t constitute a technological transformation any more than it’ll constitutes a digital one. It might, however, constitute an operational transformation.

Maybe that’s the perspective by which we’ll accomplish the most anyway.

SOC it To Me

Fact of life: Data and the processing and transactional functionality that makes use of that data has to reside in a secure environment. Given the number of data breaches that have occurred this year alone, that’s self-evident. So, when the organizations with which you work are reported to be compliant with SOC and other data-security requirements, that compliance is not to be taken lightly. Here’s why:

Who’s Watching?

Compliance indicates the processes and practices within the organization have required levels of oversight. Monitoring is in place for unusual activity, configuration changes are authorized, and access is granted only to approved users. Normal activity is baselined to make deviations readily apparent and to determine the presence of potential threats.

Compliance also indicates adequate alerts and audit procedures are in place to:

  1. Ensure awareness aberrant activity and to initiate a corrective response.
  2. Identify the root causes of aberrant activity to ensure appropriate remediation.
  3. Trace aberrant activity forensically to determine its source, its path in the system, the parts of the system affected, the nature of the affect, where it might go or what it might affect next.

But Who’s Accounting?

Compliance with SOC and other data-security requirements also means personnel within compliant organizations are accountable to their customers and to each other for upholding the terms of compliance. From preventing breaches to identifying potential weaknesses, from shoring up potential weaknesses to remediation if it’s required, the appropriate people in audited organizations are on notice and on the hook. They should also be responsible for conducting regular assessments on patch management, vulnerability management, and overall system-security management — and reporting the results of those assessments to all of their data- and system-security peers in the organization.

If you’re not sure if the organizations with which you work are compliant with data-security requirements, here are a few things you should do:

  • Ask if the organization has any data-security policies or procedures in place.
  • If so, ask what they are.
  • If not, worry … a lot … and find a new home for your data.

Some things are worth worrying about more than others. The security of your data is one of them.

Getting to Know You

Before people fully realize we’re an insurance-focused, software-development shop, they often think we’re Rogers and Hammerstein fans. For a while, we weren’t sure why that was. Then it hit us.

One day, we were on a conference call with a prospect. The discussion went something like this:

Prospect: What the most important thing to you?
Us: Getting to know you.
Prospect: I love that show!
Us: Huh?
Prospect: Never mind.

After the call, we looked up “Getting to Know You” and found out what all the confusion was about. Now we can’t get that darn tune out of our heads.

The Big Picture

Kidding aside, maybe we’re nosey or something; but we like to know our prospects’ businesses before we formalize relationships. To us, that seems more sensible and more productive than signing contracts — then trying to figure out what needs to be done.

So, over and above all the other activity it takes to be identified as their preferred vendor, we typically go to our prospects’ locations and spend three days with them. It gives us the chance to get acquainted with them. It lets us get to know their environments. It helps us to understand their cultures and the ways in which their people interact. It’s a more effective way to familiarize ourselves with their processes and to more completely identify their preferences and define their requirements. And we wouldn’t want this to get out, but it’s also fun.

A Word About Trust

The other reason getting to know you (not the song) is so important to us is that it gives us the opportunity to establish mutual trust. Like honesty and integrity, trust is something that can’t be establishes through talk or writing. At least initially, it has to be earned, ideally face to face. Then it has to be demonstrated — early, often, and with absolute consistency.

So, yeah. Getting to know you is important. And while we might not be as musical as Rogers and Hammerstein, we’ll stick to this tune as long as it works for us … and for our customers.

And based on our customers’ feedback, we do seem to be hitting all the right notes.

Upgrades: What’s Timing Got to Do With It?

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.

Get in Their Interfaces

In a conversation about user interfaces the other day, we were reminded of the old saying, typically attributed to an unnamed doctor: “The operation was a success. But the patient died.”

We’re not equating software developers to doctors by any stretch. But it does occur to us that the best software (by any criteria) could give the effect of being DOA if it had an ineffective (by any criteria) user interface.

And there’s another important thing to consider.

Age Isn’t Just a Number

To those of us who aren’t getting any older, this may not seem like a big deal. But it would seem that users of software are getting younger. For the insurance industry, that means agents, CSRs, policyholders, claims adjusters, TPAs, and others that need access to our systems are already accustomed to newer, more intuitive, and very user-friendly technology. To them, legacy interfaces feel like trying to perform surgery with a dull butter knife.

That suggests that — aside from aesthetic appeal and clean simplicity — user interfaces should be:

  • Easy to use. The easier they are to use, the more work will be accomplished.
  • If users of interfaces can manipulate them to do what they need them to do, the way they want to do it, they’ll be more motivated and efficient, as well as more productive.
  • Whether it’s driving tasks in the workflow, completing routine tasks, escalating exceptions, or myriad other activities, automation enables people to spend less time engaged in mundane repetition and more time engaged in more strategic contributions to their organizations.

And there’s yet one more thing to consider.

Going Mobile

The Who might have been singing about an entirely different kind of mobility in 1971, but they were on the right track (so to speak). Interfaces that aren’t optimized for and responsive to mobile devices and their designs will be used less frequently. It’s as simple as that. And if your interfaces aren’t going mobile, your expectations should be lower because the number of users certainly will be.

If your constituents can’t access your systems on their smart phones, tablets, and other mobile devices to get updates, conduct transactions, and communicate with the requisite parties, they’ll work with someone else whose systems allow them to do all those things.

If we’re smart, we’ll be all up in their interfaces.

What Constitutes Your Infrastructure?

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.

Build vs. Buy … Still?

The insurance industry’s debate over whether it’s better to build systems or to buy them dates back almost 3,772 years to the reign of King Hammurabi in Babylon. Within the Code of Hammurabi, the first written insurance policy was inscribed into a Babylonian obelisk. It indemnified debtors against re-paying loans if some personal catastrophe made recompense impossible.

After the Babylonian Treasury had underwritten a number of risks and needed a way to administer them, Avil Kush, the kingdom’s CFO, CTO, COO, and CWW (chief worry wart) arrived at the palace to discuss the matter with the King:

Avil: Your Majesty, since the bar chart hasn’t been invented yet, we must build enormous columns of rocks with which to keep track of our premiums and claims.

Hammurabi: Wadda you, nuts? Why would be build it ourselves? Call Nargal-sar-ussur at Marduk Megasystems and have him implement it.

Okay. None of that actually happened. But the debate rages on. We think we can settle it once and for all.

Two Questions

To decide whether it’s better for insurers to build or buy their systems, we need to answer two questions:

  1. How do we define better? We won’t presume to answer that question. But we will suggest the perennial challenges of profitability, compounded by the changing nature of system requirements, might make it a little daunting for insurers to define better as DIY.
  2. As an insurer, would you rather be in the insurance business or the technology business? We won’t presume to answer that question, either. But we will state (proudly, if we may) that we put 22 percent of our annual revenue back into continual development and refinement of our product suite. That kind of investment on an annual basis might be a tough nut for insurance company shareholders, stakeholders, and employees to swallow.

To cite another ancient king, the resolutions of this dilemma might not require Solomon.

Leave It to the Pros

We can’t speak for everyone in the insurance technology vendor community. But it’s a fairly safe bet most of them don’t write insurance on themselves. It’s equally fair to imagine there are numerous good reasons for that. By the same logic, then, it’s probably better, short term and long, for insurers to buy their systems, rather than to build them.

If nothing else, it seems like an astute division of labor, with or without stone columns.

Software as Job Security

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.