Before 1996, The St. Paul Cos. was a paper-pushing insurance company like any other. Unlike most of its counterparts, St. Paul took the technology plunge in the mid-1990s and has been floating with the currents of change ever since.It was in 1995 that the nearly 150-year-old commercial property/liability insurer began the mammoth task of creating a more efficient, automated means of delivering policy information to its army of independent agents.
"Before, our agents sent (paper) applications to us," says Charles Coon, assistant vice president in charge of application development at the St. Paul, Minn.-based insurer. "Service was poor. If something was processed within 90 days that was considered good."
Realizing a solution to this dilemma probably rested with technology, St. Paul began to examine the feasibility of using a client/server system. Although the technology was not exactly cutting edge at the time, it was a rarity for insurers to express an interest in client/server capabilities on such a broad scale.
"We looked at the client/server vendors at the time, but most of them were only mainframe shops with DOS-based systems," explains Randy Horsburgh, director of application development. "We thought that we wanted seven years of life in the application. But back then, there really wasn't anyone out there who had what we wanted."
Forward-looking
From the start of this project, The St. Paul looked forward. If the insurer expected to get seven years out of the client/server system (which it did), DOS probably would not be the best way to go.
Therefore, the company took matters into its own hands and went about developing a policy system on its own.
One of the first steps was amassing a strong tech staff. St. Paul did some careful recruiting for its information systems group. At its peak, at least 100 people were working on the project. Various consultants were brought in at one time or another, but in the end, the insurer's IT people flew solo.
The project members did some homework and determined that the new system would be based on an object-oriented computer approach. That means software components would be built that represented physical components, or objects, such as a commercial insurance policy.
When these objects are used as the system's building blocks, very little has to change to put a user interface on it, explains Karen Hope, an application architect who worked on the project.
"When we started the project, we looked at why systems fail," Coon says. "Most of the success stories involved object-oriented programming. The process makes you start small, so it helps limit your risk."
A year of intense labor resulted in the creation of The St. Paul Business Foundation System (BFS), an insurance policy writing system that enables users to make queries about, receive information on, and manage policies. The client/server based application would be the first in an evolving line leading to its current Web-based descendant.
Starting from scratch
St. Paul started from scratch. There was no massive data migration from old mainframes to the new servers. Instead, all previously existing data was re-entered on the new client/server system.
"The data in the old process was not that clean," Horsburgh says. "We wanted to do a 'do over.' We took a short-term hit for moving all that data to the new system, but the information we have today is very accurate."
Additionally, St. Paul's 125 different coverage types were boiled down to five basic coverage types,"Coon explains. "If we were going to develop this new system right, we had to re-engineer our products and services too. It was a large simplification process," he says.
Along with whittling down products to a more manageable number, the system itself would focus only on the insurer's small-business customers. That segment has traditionally produced the greatest volume of transactions for the company. That meant potentially more profits for St. Paul's shareholders and a better tool for the company's agents. If these transactions can be completed more quickly and efficiently, the insurer, agents and clients all come out ahead.
But don't think of this seemingly narrow focus on smaller businesses as neglecting the insurer's larger clients. "The large accounts would understand our taking 30 days to hand-craft a program for their individual business," Coon says. "What we are doing with BFS is like mass customization for smaller clients."
When BFS was finally rolled out in January 1996, agents were presented with a system that could speed requests to and from the carrier. However, in 2000, The St. Paul entered the Internet age and converted BFS into an even more fleet-footed Web-enabled application.
Today's BFS is a one-step process for selling, underwriting and processing insurance policies, explains Coon. "BFS uses messaging to go to each system to get information for users. All that information is then brought forward to the desktop."
If an agent sends a request for a quote, it takes 90 seconds for the electronically delivered query to yield an answer from St. Paul's underwriters. The company attributes this speedy response to the XML Translator service that the system employs. BFS can receive insurance industry standard format XML to create these real-time quotes. "Seventy-five percent of our quotes come through the system," claims Horsburgh. "I'd say that's pretty good."
Getting started
Deploying the Web-based system was as careful a process as deploying the client/server model. BFS was available only in one state with one product at first.
"Multistate policies were not covered on day one," says Horsburgh. "But at least we had something out there for some of our agents to use."
The system currently manages more than 120,000 policies with premiums totaling more than $500 million. Now, 8,500 users in 3,000 agencies access BFS, and the feedback has been favorable.
In fact, St. Paul established a user group when the very first version of BFS was released, which still actively provides feedback on the system. "They know what will make the system better because they're the ones using it," Coon says.
Keeping in mind the user group's comments, the company says the Web-based version of BFS was designed to be as easy to use as possible. Virtually no training was involved for users. "A 'mission card' was sent to agents showing how to log in and use the system," Horsburgh explains. "They were primarily self-taught. If we couldn't make it intuitive to use, then we failed in our mission."
Users access the secured site via St. Paul.com or a separate URL. The interface is in typical HTML format. There is also a portal within the site, called the Agency Resource Center. Agents can find information here on such topics as online billing, online policy inquiries and more.
So far, there have been 32 releases of BFS. Upgrades are made to the system every three months with some minor changes in the interim. These alterations can include improvements to the actual technology or additional insurance-related features and functionality.
"You're never done," Horsburgh says.
The next step
At press time, the next significant upgrade was slated for October, marking the official retirement of the original system architecture deployed in 1996. New features will include service options for endorsements and loss runs, in addition to new business quoting and request for policy issuance.
St. Paul executives declined to reveal the cost of this project. However, Horsburgh says the first release was probably over budget and a bit late. "After that, we've been on time and on budget," he asserts.
All this work has yielded favorable results. Cost savings related to issuing a policy on an average policy has dropped from $75 to $20. The company attributes this drop to the speed provided by the XML Translator.
Furthermore, 50% of the company's renewals are handled electronically. That has enabled the insurer to shift some of its staff from mundane, paper-intensive duties to more important aspects of customer service. "Insurance is a relationship business," says Horsburgh. "You want your people fulfilling customer needs, not filling out forms."
It took a great deal of effort and cooperation for St. Paul to attain the gains it has made. If any technology project is to succeed, it helps to have the right leadership to see it through-someone willing to let the IT people do their jobs, who doesn't expect miracles overnight, Horsburgh says.
So can any insurer go about creating its own technology to do what it needs? It's not mpossible, say those interviewed, but it takes a lot of effort. After all, this was a companywide venture, not a pet project for the IT department.
"Something like this takes an incredible amount of cohesion," Hope says. "We needed a 110% commitment from everyone. We had to jump in with both feet and not look back."
Maria Bruno Britz is a freelance writer based in St. Marys, Ga.
