SOUND INTERNET SOLUTIONS

By John Ashenhurst

HYBRID MANAGEMENT SYSTEMS

Have traditional agency management systems become obsolete?

Perhaps the real reason interface hasn't ever operated as advertised is that it simply isn't possible ... for two decades we've been barking up the wrong tree.

Twenty-five years ago, my little Boulder-based software company put together the industry's first multi-user micro-computer-based agency management system. It later became known as the CAIR Evolution system and was eventually adopted by hundreds of agencies--some fairly large. While current agency management systems use graphical rather than character-based user interfaces, there's a remarkable similarity in architecture and functionality between today's system and the one I created a quarter of a century ago. From my point of view, agency management systems were invented in the 1970s, and we've been polishing that same apple ever since.

For the last 25 years agents have focused on management systems as their core agency technology. The rise of the Internet and the availability of data and functionality through carrier and other Web sites suggests that a new generation of agency technology is both possible and necessary for agency success.

Over the last few years, I've spent some time wondering whether technology and industry developments have obviated the need for traditional agency management systems. Perhaps you've been wondering the same thing. It may be time to rethink what's possible and what's needed for agency technology. This column is an attempt to assist that thinking process.

A little history

Before micro- or even mini-computers were invented, agents enjoyed the benefits of computers by sharing remote mainframe models. Tens of thousands of agencies used batch service bureaus, mailing in copies of invoices, checks, and other paper documents that were then keypunched and processed. Statements, receivable lists, general ledger, expiration and other reports came back to the agency at the beginning of the month. The process was efficient and relatively inexpensive but wasn't timely or responsive.

One enterprising group, Insurnet, used time-sharing computers to allow agents immediate access to data and reports, thus foreshadowing today's ASPs; however, everyone in an Insurnet agency had to share one slow and clumsy terminal.

One service bureau, ARC, developed a hybrid environment, with a micro-computer in the agency that communicated with the service bureau mainframe. The delays in mailing were eliminated, at least for some items, and some access could be electronic rather than just paper-based. Some agencies continued to use this service as well as traditional batch service bureaus until the turn of the century. Amazing!

Besides not being timely and not readily accessible to agency staff, service bureaus and eventually the in-agency mini-based accounting systems they evolved into were viewed by agents as having two significant failings: They didn't provide for the storage and retrieval of policy detail (thus requiring continuing reliance on paper), and they didn't provide a way to see all the data for one customer grouped together. In short they were not agency management systems.

Agency management systems and interface

At least as imagined more than two decades ago, agency management systems would house all the information that agencies needed to conduct their business and service their customers, making it possible for agencies to dispense with paper altogether. Some agencies today are relatively paperless and their management systems are the core of their daily operation.

In the ideal case, an agency management system makes an agency self-sufficient and independent of carrier, customer, or business partner technology and data. But as agents noticed early on, having their own complete agency database was a mixed blessing. It was useful for marketing, sales, and service work but tedious to build and maintain. Further, carriers wanted agents to provide them that same data but in a format required by the company--which meant double (or more) keying the same data.

It didn't take long before agents, carriers, and vendors began talking about and then experimenting with computer-to-computer communication, that is, interface. ACORD, IVANS, and the idea of SEMCI were an attempt to develop an industry-wide approach. Conventional wisdom had it that agents and carriers each needed to store the same policy information, each for different purposes, and thus the task was to find a way to synchronize data in these different storage venues with the least amount of re-handling. Thus the need for upload, download, real-time interface, and straight-through processing--all artifacts of the era of agency management systems.

The problem

Even after nearly 20 years of development, agency-company interface today is a pale imitation of the once imagined ideal. Fingers point in all directions: Critics claim that carriers and vendors can't see beyond their immediate self-interest, the ACORD standards aren't practical, agents are lazy, and producer groups are more interested in politics than substance.

All that may be true--but perhaps the real reason interface hasn't ever operated as advertised is that it simply isn't possible. It's been a mistake all along to assume that it's really feasible to synchronize tens of thousands of agency systems with hundreds of carrier systems. Perhaps the truth is that for two decades we've been barking up the wrong tree.

The new opportunity--hybrid management systems

It has seemed obvious that agencies need their own policy databases and therefore the problem is to connect agency and carrier databases. But what if agencies really no longer need their own policy databases? What if they could just make convenient use of their carriers' systems? With data stored only once, in the carrier system, the need for interface would evaporate.

Though this idea has been in the air for years, sometimes as an industry database, sometimes with carriers sharing agency storage, and sometimes with agencies sharing carriers' storage, it's only recently--because of the rise of the Internet and the proliferation of carrier sites providing data and functionality to agents--that shared storage can be taken seriously.

Today, it makes sense to think about the possibility of agents dispensing with local policy detail storage altogether and linking to carrier storage when policy detail is required. One could call this new concept and successor to traditional agency management systems "hybrid management systems."

Traditional agency management systems are self-sufficient, with policy detail stored locally (or remotely by the agency's ASP). Traditional management systems create duplication with carrier systems and require interface. Hybrid management systems, on the other hand, depend on and are interconnected with other storage and functionality sources. They're integration platforms rather than stand-alone islands of computing. Hybrid management systems eliminate duplication and the need for interface altogether. Hybrid management systems have the advantages of traditional management systems, that is, a single view of customers and their policies, without the implied unhappy choice between the waste of double-entry and the impossibility of universal interface.

What would a hybrid management system look like?

It might look a great deal like an existing management system, or at least the emerging ASP versions that follow browser user interface paradigms. The agent's system would hold general customer information, policy headers, and some accounting detail (for instance, agency billed information, payables, commission, and general ledger).

As in today's systems, indexes would hold name, account number, policy number and other keys for easy lookup. The systems would be able to display policy lists for each customer and then allow drill-down into the detail for each policy (e.g., coverage, claims, and billing). But unlike today's management systems, the drill-down function would cause the system to go to the carrier's database (directly or through the carrier's Web site) to retrieve the relevant information. In other words, rather than storing the actual policy-related data, the hybrid management system would store the link to the actual data--wherever it happened to be.

In its simplest form a hybrid management system would show the links to underlying policy detail. The user would click on the link and be taken to the appropriate populated Web page in the carrier's site. The carrier site would "show through" into the management system. In a more elaborate version, the hybrid management system would reformat carrier data so that it had the same screen format no matter which carrier it came from. While the latter approach favors the agency and makes its life a bit simpler, reformatting requires the vendor to keep up with changes in carrier sites, and that might turn out to be too difficult and expensive in relation to its real value to the agent.

What's wrong with the hybrid management system idea?

At least on the surface, plenty. Let's take a look at some apparent issues.

Who owns the data? If agents don't store the policy detail and depend on carriers to do that for them, what's to stop the carrier from claiming it owns the expirations? First of all, my suggestion (made above) is that agents do retain high-level policy information (including expirations) in their own systems (whether local or ASP). It's only the detail the agency wouldn't hold. Second, the location of the policy detail (or expiration information) is immaterial to the question of ownership of the expiration. That question has been around since before the invention of computers, and generally the contractual arrangement is that the agent owns the expiration. From my point of view, the question of who owns the data is entirely separate from where it resides and it was addressed years ago.

Could an agent move a policy or book of business? If an agency depends on the carrier to store the policy detail, will the agency have contractual problems pulling the detail out of one carrier's system and then putting it into another's? Or pushing the question a bit further, will an agency be allowed to pull all of its policies from one carrier and then move them someplace else? Today, agents certainly can and do move policies and whole books. The difference in the hybrid management system case is that the original carrier would be complicit in losing business to its competitor. The issue is connected to a more general question of whether carriers will be willing to accept responsibility to be, in effect, ASPs for their agents (as well as themselves). To the extent they already provide portals or extranets to their agents, the answer seems to be yes. But I don't think the issue has been widely recognized or discussed.

What if a carrier doesn't have online access? It's fine to imagine hybrid management systems existing in a context in which each carrier provides online all the data and functionality its agents need, but in fact some carriers provide none and many only a subset of what's required. Today a hybrid management system arrangement would be possible only for some, not all carriers. Though the observation is true, it isn't really much of an objection to the concept. For an interim period, perhaps a decade, hybrid management systems would need the capacity to store data locally (when that was required) and link to remote sources (when that was possible). But the agent wouldn't have to pay any attention to the resolution of data sources--the system would take care of it. But would a mix and match, evolving hybrid management system have more value than today's agency management systems? Yes. At least in some cases, interface simply wouldn't be necessary, thus saving carriers, agents, and vendors a great deal of expense and trouble.

So then what?

Could vendors create hybrid management systems? Absolutely. Current efforts by IVANS/Applied, ebix, and AMS Services to provide real-time direct bill and claims inquiry into carrier Web sites or mainframes are practical examples of how management systems can in effect access and present remotely stored information. As these vendors work to provide policy inquiry, then new policy and policy change hybrid transactions, storing policy detail in the agency system will become irrelevant and with it the need for traditional interface, data duplication, and all the problems of synchronizing tens of thousands of agency systems to hundreds of carrier systems.

Besides addressing the perennial problems of interface, hybrid management systems would provide solutions to other serious insurance technology shortcomings--among them the increasingly unacceptable product and service constraints of traditional management systems. They were designed and built at a time when agents focused almost exclusively on traditional personal and commercial lines business. But agents have changed the rules, expanded their charters, and now operate in a broader world. Traditional agency management systems haven't kept pace and increasingly stifle the agents they're intended to serve.

Once the hybrid management system question is raised, a number of issues come into view. What's the role of ACORD in the future? What are the implications for agency workflow? How can XML-based intelligent documents play a role?

Further discussion of the potential of hybrid management systems will have to wait for another time. We'll continue our look at hybrid management systems, the expanding charter of independent agents, and broader implications in a future column. Stay tuned. *

The author

John Ashenhurst publishes Sounding Line, an electronic newsletter focused on insurance technology as well as a Weblog, johnashenhurst.com. For more information, see www.soundingline.com. He can be reached at johnashenhurst@soundingline.com or (360) 376-1090.