More than 20 years ago, agency accounting systems gave way to agency management systems. More powerful, but also more demanding, management systems provided a way for agencies to store policy, claims, and transaction detail as well as accounting and expiration information. To be useful, the databases needed to be populated and that meant lots of key-entry and maintenance. At the same time, carriers required agents to fill out and submit forms or use standalone proprietary terminals.
Agents found themselves handling the same data over and over, keying it for themselves and then keying it for their carriers. It didn’t make sense. What was needed was some way to reuse the data, for instance, downloading carrier data to populate the agency database and then using the database as the source for subsequent policy change, renewal, and claims transactions sent to the carrier.
The key problem, it was imagined, was to find a way to synchronize agency and carrier databases, bringing them up to date and consistent with one another on a regular basis. In a fit of apparent forward thinking and cooperation, (at least some in) the industry imagined that ACORD would provide transaction standards and that IVANS would store and forward mail boxes to carry the traffic between agents and companies. The Big I named the process SEMCI — single-entry, multi-company interface.
Though the synchronization problem seemed real and the ACORD/IVANS/SEMCI solution appropriate 20 years ago, it hasn’t become a reality. Why not? Some blame the carriers — for talking the talk, but not walking the walk. Others point to the vendors — who claim support for the concept, but then use what amount to exclusive technologies to compete. Some say agents are apathetic and unwilling to band together to force the carriers and vendors to a shared solution. Still others insist that producer and user groups’ lack of leadership is the culprit. And sometimes ACORD is flogged for being more interested in the formalities of standards generation than the practicalities of their implementation and use.
What’s the real cause of interface failure? Who knows? I think is obvious that the project was untenable from the beginning. It was utopian in the worst sense. It made naïve assumptions about human motivation and utterly failed to appreciate the enormous practical difficulties of harmonizing tens of thousands of agency systems with hundreds of carriers’ systems. It couldn’t possibly work.
Carrier Web sites and hybrid interface
But something important has changed in the last few years. Carriers have begun to make access to their databases and functionality directly available to agents through the Internet and carrier Web sites. Viewed through SEMCI spectacles, carrier Web sites are an insult heaped on the injury of failed standard interface.
But as I suggested a year ago, carrier Web site lemons can be changed into hybrid interface lemonade. Carrier Web sites needn’t be the bane of agents; they can be a boon instead. For the first time, with the Internet, HTML, HTTP, and other global standards, agents can actually have common, direct access to carrier data. The trick is to see the opportunity and then encourage vendors to build management system/carrier Web site bridges.
And, by gosh it’s already happening. In a very short time (by interface standards), thousands of agencies are getting significant daily benefit from real-time inquiry management system/carrier Web site bridges. And that’s a good thing.
But interface of any kind really isn’t the answer
But in a way, it’s also beside the point. Hybrid interface is nothing more than a quick and dirty solution to the problems of interface. With management system bridges into carrier Web sites moving data up to carriers and overnight download moving data back to the agency and thus closing the loop, the synchronization/double entry problem is apparently solved — though not in the ideal and elegant way imagined twenty years ago.
Hybrid interface is an opportunistic way to approach the problem ACORD/IVANS/SEMCI addressed, but didn’t solve, over the last 20 years. It can provide some short-term success, but it doesn’t change the fact that we’re still barking up the wrong tree. Double-entry isn’t the problem; double-storage is the problem. Double-entry is the symptom of a mistaken business and technical model; namely, the proliferation of competing repositories for the same data.
As long as the industry is blinded by the paradigm of self-sufficient islands of computing, interface will be necessary. And because it can never work as desired, agents and carriers will continue to be frustrated and waste money.
The answer isn’t more and better interface; it’s dispensing with the need for interface at all. The answer is to store data only once with carriers, agents, customers, adjusters, and others sharing — not replicating the data.
Hybrid management systems
Hybrid interface demonstrates the practicality of agents relying on carriers for policy detail, claims information, billing information, rating and other data, business rules, and functionality. Only a small conceptual leap is needed to see that management systems could in fact dispense with detail policy storage — with the result that interface as we’ve imagined it simply wouldn’t be necessary.
To say that hybrid management systems would not store policy detail — but only links (for instance) to the data in the carrier environment — isn’t to say that agents don’t need management systems or that the management systems shouldn’t contain appropriate customer and policy information. They should. The agent needs to know a good deal about each customer that’s not relevant to the carrier, including an overview of current and past policies and the transactions surrounding them.
The key concept of hybrid management systems — and their difference from classic management systems — is that the former looks at the entire insurance system, including the carrier, and attempts to minimize duplication and redundancy. The latter looks at each node in the system and tries to make it self-sufficient. In the former case, the network is primary; in the latter, it’s secondary.
Data sharing and re-use among parties to insurance transactions isn’t a new idea. The producer associations and vendors have floated the idea a number of times over the last twenty-five years — usually envisioning an industry policy warehouse that all parties could share. But it’s not likely that carriers would or should agree to such an arrangement. And, at least until recently, the imagined project wasn’t even technically feasible. It makes more sense, I think, for agents to ride the coattails of their carriers and make use of the storage and functionality carriers create and maintain.
Just getting started
In the paragraphs above, I’ve tried to describe the model that lies behind the need for interface (islands of computing), suggested why ideal interface will never happen as imagined (much too complicated), and shown that, in principle, interface really isn’t necessary if agency management systems are reconceived as being integration platforms in rich networks (thus minimizing the duplication of storage and functionality).
But as you’ve already begun to imagine on your own, the concept of
hybrid management systems raises a number of issues — some very difficult
and perhaps a few damning. In future installments we’ll look at these
issues and report what agents, carriers, and vendors have to say about the
idea of hybrid management systems.
© Copyright 2003 by Sound Internet Strategy. All rights reserved
But as I suggested a year ago, carrier Web site lemons can be changed into hybrid interface lemonade.
The answer isn’t more and better interface; it’s dispensing with the need for interface at all.