Those who want to buy tend to be those who cant build. Theyre likely to be smaller firms (less cash and time, fewer IT resources); they perceive less risk in buying (We dont have the technical resources in-house. What will the ROI be? We wont have anyone to blame!); they know they can touch and feel a purchased product, analyze its effects on the business, and have an attributable source for ROI projections; and they understand the 80/20 rule: 80 percent of the needed capabilities can be had out of the box, and the rest can be customized through applications and integration.

Because both these situations can come up, the more critical issue is not whether its more astute to build or to buy a system. Rather, the heart of the matter is the heart of the systems effectivenessand the lions share of its functionality: its content.

Taking Charge

Heres something to ponder: As programming languages become simplified to the point that business people (as opposed to IT people) can develop, configure, and distribute products, the folks at the wheel may not fully understand what makes up much of their insurance products.

Needless to say, thats not an excerpt from How to Win Friends and Influence People. Its also not as uncharitable as it sounds. In fact, most commercial insurance policies include rates, rules and/or forms developed by institutions other than the insurers writing the policies (ISO, NCCI, myriad state authorities, etc.). Companies use these baseline components because they are aggregated from real premium and loss data provided by insurance companies all over the country. Most insurers use the various rates, algorithms, policy language, and forms in any combination they choose (custom rates, factors, forms, etc.), then amend them in whatever ways they also choose. But for any one insurer, taking on the task of recreating the baseline data would be cost- and risk-prohibitive. And then theres the little matter of maintenance.

Many companies are re-inventing the wheel by tracking, programming, testing, and implementing the bureau-generated rates, rules, tables, and policy forms within their policy processing systems. While some larger organizations may have the horsepower to pull such loads, consider this: Last year alone, Insurity processed 24,000 regulatory/bureau changes on behalf of its customers, for commercial-insurance lines of business only. Those included rate, rule, and form changes; state and bureau reporting-requirement changes; and all lines of business for all 50 states. That kind of labor-intensity is not just a systems challenge, its a human-resources challenge. And its by no means an anomaly. Over the past three years, there has been an average of 20,000 such changes per year.

Its hard to know which question to ask first How can companies manage all of this data? Why would they want to?

One more thought: It can get worse. Think of all the ways in which we can be bombarded with dataimaging systems, electronic interfaces, data warehouses, Web links, database messages, etc. Without the proper resources and services, this is a case of agita waiting to happen. Fail to keep up with it, and there are more treats in storeinaccurate or inadequate pricing, cancellations, downturns in market share and profitability, non-compliance fines. Pass the Pepto, Sammyits gonna be a long night.

A Byte is Just a Nibble

The truth is the maintenance of that much data is not a software challenge. All the bytes in the world wont help a bit if they dont have current content to chew. Were talking about a content-management challenge. If systems providersin-house or outsourcedarent also providing content management, all the processing power on the planet wont prevent bad rates, faulty coverages, and regulatory non-compliance. If, on the other hand, systems providers do provide content management, carriers can focus their limited IT budgets on projects that help differentiate them from their competitors. Technology is having a major influence on the ability to utilize content-management services. But it cant provide intelligent content assessment and management.

With that said, processing and content do show the potential to dovetail at some point. While older, proprietary systems and languages made interface difficult, new programming languages like XML are allowing systems to share data through the adoption of common tongues. Middleware platforms and Web services are breaking down other barriers. These and other technological changes are allowing carriers to integrate regulatory-compliance applications into their policy processing systems, to take advantage of those providers who can help them manage the content of the thousands of bureau rate/rule/form changes that affectif not determinetheir business results.

Choose Wisely

When selecting a content management partner, you need only ask the same two questions you might ask before a first kiss: Have you ever done this kind of thing before? And if so, with whom?

Beyond that, make sure your partner knows how to act after the first date. If insurance expertise isnt on the rsum, say good night.

Make sure your partner isnt afraid of commitment. If the deal starts to feel like a buy and bye-bye proposition, move on.

Make sure your partner knows a little something about long-term relationships. If a brief history and a dubious balance sheet have you thinking your suitor wont be aroundlet alone respect youin the morning, it wasnt meant to be.

Whatever you do, youll make your times significantly less interesting if your search for an insurance-processing system centers on full functionality and fully managed content. The search may be difficult, but it need not be a curse.

Dorrie Pighetti is vice president and chief insurance officer at Insurity (www.insurity.com). Tony Reisz is Insuritys vice president of sales, marketing, and business development.