"You need to have an 'improve precision of forecasting' project, or an 'improve underwriting criteria' project," said Paul Theriault, senior vice president of marketing at Pinpoint Solutions. "What does that mean? It means a specific project that targets a significant pain-point. It means realizing that we're not analyzing losses at a detailed enough level to find the characteristics of winners and losers [and] what that's costing us. If pricing can be fine tuned across these factors, that will impact the bottom line. And then you...get sponsorship by marketing, sales, actuarial, and then you have your warehouse."

In other words, think strategically. A successful data warehousing project only starts with the creation of the warehouse itself. "It's about using your most basic asset to solve business problems," said David VanDenEynde, area vice president of insurance and health care at NCR's Teradata division. "You need to start with a specific business objective and then decide how, or if, a data warehouse can support the achievement of that objective. You can't start building a warehouse and then decide how you are going to use it. That's a hallmark of a company that's divided."

Communicate. Hardly a revolutionary concept, communication is a key to the success of most IT projects. But it's particularly important in data warehousing. Unlike transactional systems in which users have no choice but to use the technology once it's implemented, data warehouses must attract their user base. "If IT develops [the warehouse] without business involvement and throws it over the wall to the business users, it will fail," said VanDenEynde.

Repeat after me: communication, communication, communication. "The reasons projects fail most is because that isn't done," said Sid Adelman, data warehouse implementation consultant and instructor at the Data Warehousing Institute. "That's communicating expectations of performance, response time, availability, the type of function users will actually have, the ease of use of tools, timeliness of data, everything."
Involve and align the staff. Communication will go a long way toward aligning business and IT, which is indispensable in a warehousing project. "In a data warehouse, you're building something for which the requirements aren't fully understood in advance, so you need a much stronger partnership [between business and IT]," said Gohsler.

Insurers who have forged that partnership have done so by balancing centralized and decentralized control, creating joint steering committees, and giving true decision-making authority to line-level staff while having a member of upper management champion the project. "The best model in the world is a dual project manager role where they walk together in lock step," Gohsler said, "but ultimately, there needs to be a sponsor-a well-placed, politically savvy person. Someone who has [control of] the money and will make decisions quickly and mow down all the roadblocks that are encountered."

While there are good tools, know that there is no silver bullet. Data warehousing will not lower your IT costs; rather, it will increase them through hardware, software, consulting, training, and ongoing maintenance demands. It will not allow you to cut your analyst staff. It will not fix bad business models, poor system designs, or data problems. And there are generally no quick solutions-experts are wary of middleware promising to pull data from disparate systems, and shrink-wrapped solutions often disappoint.

That said, the evolution of data warehousing has led to technologies that can make your project more successful. As the prime example, vendors offer insurance-specific, prearchitected data models and automated data dictionaries. These differ from fully packaged systems in that they are customizable to better meet the needs of a specific installation.

"The best approach [to warehouse implementation] is between the 'blank page and good tools' method and a fully shrink-wrapped solution," said Bob McCarthy, director of product marketing for business intelligence at Sybase. "We've developed [prearchitected data] models over time, but they are not fixed and rigid. They're a structure that's there to be extended, and we deliver them with a modeling and design tool that allows customers to add and modify tables as they implement them."

Ideally, tools insurers choose should be database-agnostic, capable of integrating with any database that an insurer or department within an insurer may use.

Cost justify the warehouse. In this respect, the data warehouse is no different than any other IT project. But determining a cost benefit, let alone an ROI, can be difficult. "The value of gaining better access to data is nebulous, so it's difficult to get to an ROI, and therefore some companies don't even try," said Gohsler. "So when a CFO looks at a bill and asks, 'What are we getting for this?' and there's no answer, the project is often cut. If there is a cost-benefit supporting the project, or at least a high level concept of benefits that has been shared with the business community, continued support for the effort is more likely."

Unlike a transactional system, where concrete increases in the numbers of claims that are handled or policies that are issued can be tracked and evaluated, data warehouse gains require an understanding of the strategic importance of the ultimate system. Look for productivity gains, assess marketing opportunities, and evaluate the results of precision pricing.

"Right now analysts...probably spend 80 percent of their time looking for data and integrating data, but only 20 percent of the time doing analysis," Adelman said. "We're trying to flip those numbers so we can point to some real productivity benefits. But there are other areas as well. If what you're trying to do is increase your customer base, and each customer is worth $200, you can attribute a tangible number to them."

Invest for the future. A well-designed warehouse will attract users-you don't want poor performance turning them away. You'll be spending a lot of money on your system, so take some time to kick the tires and look under the hood.

Start with a relational database management system (RDBMS) that can support not only scheduled analyses but also the ad hoc queries users will come to demand. "When you have someone with a 70-million-policy data warehouse, and they want to look at every single policy on 20 dimensions, the general database will be a dog," said Theriault, "but an ad hoc data engine will do it. That's the difference between seven hours run time and 30 seconds."

So plan for growth. "Am I buying a platform and a database that has true scalability, so when I grow from 100 to 300 GB, I can get roughly the same response time?" asked VanDenEynde. "You don't want to hit a magical number, in terms of gigabytes or number of users, where the system crashes or the response time is so bad no one wants to use it."

When it comes to performance promises, don't take the vendor's word for it. "Use a database-independent query tool, talk to the database vendors you have in mind, and tell them you want to do a bakeoff," Theriault explained. "Once you do that, you'd knock out a couple contenders in the marketplace."

Commit to-and budget for-ongoing maintenance and development. "In any other [IT] project, there's a beginning, a middle, and an end," VanDenEynde explained. "Business people might be involved, but IT people generally run the project. And when the project's done, everyone goes off onto other projects. And that's not what a data warehouse is about. A data warehouse is a dynamic, ongoing resource that, if done correctly, will continue to grow and provide measurable business value to the enterprise."

Set a realistic schedule/be patient. How? By involving technologists who know the requirements. "In one of the classes I teach, I always ask the question, 'How many have schedules imposed on you?' And every hand goes up. Almost always these are unrealistic schedules," Adelman said.

An understanding of scheduling is critical for data warehousing because of the 80/20 rule: 80 percent of the work involved in implementing a warehouse involves examination and preparation of source data, while only 20 percent is required to extract, transform, and load the data into the warehouse, according to Conning's report. Without a clear understanding that no benefit will be received until after the bulk of the work has been done, many insurers lose patience with the warehousing project, and often the project is stopped before it is ever completed.

Why does preparation take so long? Because regardless of what you think, your data are dirty. Front-end edits don't catch everything, and even if they do, creative data entry can get around them. What's good enough to work for transaction processing often won't work for data analysis.

So plan carefully. Test the data mart with sample data before you load it. Build a small-scale data warehouse to vet the system and uncover problems. In short, just because the warehouse won't cause your policies to stop being issued or your Web site to crash doesn't mean it's time to abandon those good ol' best practices.
Assign-or hire-staff with the right skill sets. Vendors' latest offerings have made it easier to manage the warehouse, but they are not a panacea for lack of knowledge. "As the old saying goes: At the end of the day, a fool with a tool is still a fool," said Adelman.

Your database administrator (DBA) is obviously critical, performing the heavy lifting of the project-design, monitoring, tuning, backup, recovery. Your data administrator handles data modeling; the logical representation of the data; as well as metadata, descriptions of the data itself.

"There's another key person, the 'ETL jockey'," Adelman said-someone responsible for extract, transform, and load. "Whether you're using an ETL tool or not, there's a lot of work involved," he explained. Between IT and business, you also need an access and analysis staffer who knows the business reporting tools, is involved in user training, monitors use of the tool, and makes sure people are using it the way they should.

Start small, think big. Warehouse projects that offer quick, intermittent deliverables to key departments can help overcome the 80/20 scheduling problem. "Companies get too bogged down...wanting to solve world hunger in the first phase, making it such a huge project that it takes 12 or 18 months. Business folks are waiting for the first sample of data," said VanDenEynde. "Coming back with a small- to medium-sized win in six months is critical. If you build correctly, a small win does not preclude you from a larger win down the road. At the same time, you're returning value, getting business folks interested, getting positive chatter around the warehouse."

That strategy works as long as the early deliverable doesn't turn the warehouse into a pet project. "Say we're developing an application for underwriting; you might be tempted to get something up quickly that doesn't consider claims," VanDenEynde continues. "You might say, 'Why do we want to architect a database to include claims?'[But you need to] plan for the whole house even if you only put furniture in a couple of rooms."
Also, to combat long deliverable times, insurers frequently deploy data marts to meet point objectives such as a quick claims analysis or targeted marketing program, with the intention of later connecting those marts into a larger, federated data mall. Without a forward-looking plan, however, insurers can be left instead with independent systems that are redundant, or worse, incompatible.

"The data mart is not good to the extent that [it] presents a buy-down, but-to the extent that the data mart is an intermediate point to a more global view of customer data, premium data, and so on-it can work well," Gohsler said. The key is to define a single conceptual data model of products and customers across all the data marts. That's no small task when dealing with independent departments, each potentially with its own IT budget, customized systems, and equally empowered directors. It points again to the need of a highly placed data warehouse sponsor.

The best data mart strategy is to first build the larger warehouse, and then build dependent data marts that attach to the centralized repository. In that way, common data definitions between data marts aren't an issue. An ancillary benefit is that individual departments can perform heavier analytical tasks using their own systems without affecting the response time.

Keep your eyes on the road ahead. Analysts and actuaries who dream of pulling years of historical data will be disappointed because the cleansing requirements are simply too stringent. Business acquisitions and mergers, code changes, and legacy system migrations have all resulted in what Conning calls a "conglomeration" of data at many insurers: inconsistent, poorly documented, and error prone.
"Some of the data you use today weren't even captured five years ago," said VanDenEynde. "So the easiest way to do it is to start right now-to capture data today."

If you absolutely, positively, have to have a longer historical view, minimize problems by focusing on analysis priorities. What's a reasonable mark for pulling historical data into the warehouse? Two years is the point of some agreement, although no rigid rules apply. "If you're trying to analyze loss trends over several years, you need several years worth of history, but if you're a sales person...you're more interested in what you sold last year," VanDenEynde said. "Let the...associated business value dictate the specifics of your data warehouse."

RDBMS
IBM: DB2 (www.ibm.com)
NCR: Teradata Warehouse (www.ncr.com)
Oracle: Oracle9i (www.oracle.com)
Sybase: IQ Multiplex (www.sybase.com)

Modeling
Computer Associates: Erwin (www.cai.com)
Oracle: Designer (www.oracle.com)
Sybase: Industry Warehouse Studio (www.sybase.com)

ETL
Ascential Software: Datastage (www.ascentialsoftware.com)
Evolutionary Technologies International: ETI Extract (www.eti.com)
Informatica: Informatica Applications (www.informatica.com)

Query and Reporting
Brio: Brio.Report (www.brio.com)
Business Objects: InfoView (www.businessobjects.com)
Cognos: Cognos Query (www.cognos.com)

Insurance Analysis Suites
Insight Decision Solutions: Insight Warehouse (www.insightdecision.com)
Pinpoint Solutions: ProfitCube (www.pinpnt.com)
Thazar Solutions Corporation: InsSight Business Intelligence Suite (www.thazar.com)

References and Resources
Conning (www.conning.com)
DataWarehouse.com (www.datawarehouse.com)
The Data Warehousing Institute (www.dw-institute.com)
Sid Adelman & Associates (www.sideadelman.com)