Establishing the core competencies of an insurance carrier maysound like a great deal of work involving research andself-examination. However, Donald Light, senior analyst in theinsurance group for Celent, contends it all comes down to two majorquestions insurers need to answer concerning the amount of internaldevelopment capability they require: "Do you want to write a lot ofapplications with your own staff? Or do you have a preference tobuy applications from software vendors and view your own staff asdoing integration, maintenance work, or minor kinds ofdevelopment?"

The answers will help carriers determine their corecompetencies, particularly within the IT department, where staffingissues and changing business processes present a challenge toCIOs.

But where does an assessment of internal capabilities begin?Bill Jenkins, CIO of Penn National Insurance, explains anyassessment should start with what the company is good at. Beinggood at something isn't necessarily the same as having a corecompetency in that area, though. "If you are good at payroll andpayroll is not a differentiator for you, so what?" he says. "That'ssomething you easily can outsource."

Steve Haas, associate principal with the consultants at EverestGroup, agrees with Jenkins and adds core competencies need to beviewed from a strategic level. "Too often, people think of corecompetencies as something they do very well," he says. "There arecompanies that have outstanding HR departments. They get a lot ofwork done with very few people. While I'm sure they are very proudof [their HR efforts], I'm not sure that would be a corecompetency."

Any assessment of a carrier's core competencies can be doneinternally. "In some sense, it's always done internally bydefault," Light says. "If you are using little or no outsideresources, that means you've made a decision."

The classic definition of core competency is an activity orcapability within an organization that distinguishes it from itscompetitors and gives a competitive advantage, according to Haas."It's something that is hard for others to imitate and gives thecompany the capability in which it can develop and launch newproducts and services," he says. When looking at an insurancecompany, Haas is of the opinion core competencies center aroundcustomer service, channel management, and the ability to developnew products quickly and efficiently.

Core competencies can be developed in different ways, hesuggests. For example, "a company decides consciously throughstrategic planning activities–which may or may not require hiring aconsulting firm–that the two or three things it wants to make sureit does extraordinarily well are going to distinguish it in themarketplace," he says. "Or over time, [companies] have developed acore competency without knowing it, and it wasn't until someonelabeled it a core competency that they discovered this wassomething that gave them a competitive advantage."

Most companies have just two or three core competencies, reportsHaas. A company may be competent at a lot of things, but he feelsfor a skill to rise to the level of a core competency, it needs toprovide the company leverage in the market–a source of competitiveadvantage and something that offers benefits to consumers of theproduct.

Haas worries the term core competency is starting to lose someof its edge, though. "The view of core competency in the lexicon ismigrating more to 'something we do pretty darn well,'" heobserves.

Hard as it is to believe, CastleBay Consulting CEO George Grievehas learned many insurance CIOs aren't clear on what their job inlife might be. "We'll ask CIOs, 'What are you here for?'" he says."'Are you integrators? Are you builders? Are you purchasers ofsoftware?'"

In some cases, Grieve notes, companies have failed to answerthese questions, which creates complications as carriers move fromone major situation to the next and decisions are needed on how toapproach each situation strategically. "My personal opinion is thevast majority of insurance carriers should have nothing to do withbuilding software unless it absolutely is a last resort," hesays.

His reasons for buying rather than building include the beliefmost IT shops aren't big enough or sophisticated enough to do thejob well. Second, he claims the vendor marketplace has improveddramatically over the last five years to such an extent it'sunlikely a carrier could build software equal to or better thanwhat vendors have built already.

There are problem areas, though. Grieve believes for somesegments of the industry, such as excess and surplus lines andspecialty lines, it is difficult for carriers to find off-the-shelfsolutions, so those insurers are more inclined to build. But forthe most part, "unless you are one of the big companies with atremendous amount of resources and a lot of reach, you probablyshould look to buy before you ever think about building," hemaintains. "What [a carrier's] main objective should be is tointegrate purchased products with the legacy assets."

The skill sets and the head count needed to develop functionsinternally or either buy or outsource them are very different,points out Light. "Larger companies will do all of those things andalso have significant numbers of developers on board," he says."Smaller companies tend to fall under the category of buyers."

Large-tier insurance carriers believe their business model andthe complexity of their legacy environment make building solutionsa more attractive alternative, states Light. "When you get into theworld of top-tier companies, they feel no package that has beenwritten to appeal to a broad range of insurance companies possiblycould do all the things they need it to do to maintain acompetitive differential," he says.

When the need is for carriers to change the way they dobusiness, buying vendor products and sharing the vendor'sdevelopment team as an outsourcing partner can be a better option.In 1999, Buckeye Insurance Group purchased from Insuresoft theDiamond policy administration system. That brought about a majorchange in the way Buckeye did business, according to R. ChristopherHaines, assistant vice president, technical operations. "That was abig decision for us," he says. "This year we're a 128-year-oldcompany, but up until 1999–our first 120 years–we did everythingthe exact same way."

The changes Buckeye wanted to make forced the carrier to lookclosely at its operation and judge how well things were working.The IT team handled much of the assessment, visiting eachdepartment and eventually meeting every employee face to face tolearn how the employees were spending their days.

One thing the company discovered it was doing well was a processcalled expanded underwriting authority, explains Haines. "Weallowed our agents to make underwriting decisions to a pretty highlevel," he says. "We allowed the agents to accept the coverage, butthey still had to enter all the information manually. It was aneasy decision for us to go to real-time Web processing because itwasn't a change in our philosophy or methodology."

A major concern for Jenkins at Penn National is the availabilityof staff. In that regard, one of the strategic initiatives theentire organization currently is undertaking is a discussion ofstaffing, not only in IT but in underwriting and claims, as well."We are looking at the technical skills of the entireorganization," he says.

Penn National wants to identify the skills required by thecompany for the next three to five years. "There are steps we needto take in order to address this issue, and part of that is whatare our core competencies and what are our skill levels," he says.In recent years, Penn National has embraced a number of newtechnologies for the organization, such as business rules engines,which allow the carrier to compete. Therefore, examining staffingneeds and the skill level of the business users is somethingJenkins feels needs to be done posthaste.

Penn National has established IT operating principles, and oneprinciple states the carrier will reuse before it buys and buybefore it builds. "As we go through the process of evaluating whatis needed by the business, we go through the thought process[concerning the IT principles]," says Jenkins. In many cases, hefinds there are not many solutions the carrier can buy off theshelf, particularly when it comes to areas such as automating theupfront underwriting process, predictive analytics, scorecards, andworkflow. "As a result, we have to rely on external contractorsthat have the skill set to come in and not only address the systemswe need but also [be on board] for skill transfer," he says. "We'veembraced what I call a 'construct philosophy.' We are buyingcomponents and cobbling them together, but we need the skills to dothat and build out our components."

Part of what Penn National has done is to examine how thecarrier breaks up the IT delivery system. "We look at what skillswe have and what we need and then determine how we get the skillsto sustain ourselves going forward," he explains.

The personnel issue, particularly attracting and retainingprogrammers, is an area of concern for Buckeye, as well. Thecarrier is located near Dayton in western Ohio, and Haines says,"The challenge we have is how do you keep [programmers] fromquitting? You treat them well, but things happen you can't control.You lose a lot of knowledge when [programmers] leave. You get themup to speed, and something happens in their life, and they aregone."

One advantage Buckeye has obtained from its contracts withvendors Insuresoft and Interactive Business Systems (Buckeye's Webdevelopment vendor) is personnel issues can be handled with aminimum of problems. "There have been times when a programmer oranalyst assigned to [the Buckeye account] has taken another job,but the vendor trains people to move into the role," saysHaines.

Recently, Buckeye's lead analyst from Insuresoft was given threeweeks off to spend time with her husband, who just had completedhis third tour of duty in Iraq. At the same time, the vendor's leadprogrammer went on a maternity leave. "But we haven't missed abeat," says Haines. "[Insuresoft] has slid people over onto ouraccount. If the same thing happened [in Buckeye's IT department], Ican't imagine losing that number of resources. We'd be in a worldof hurt."

Having access to the vendor personnel also allows Buckeye toleverage training issues. When Haines informed Interactive BusinessSystems that Insuresoft was moving from .NET Framework 1.1 to .NETFramework 2.0, he was told there would not be any major problem."But if we were doing our own Web coding, I'd have to get our Webresources to a training class somehow and pull them off whateverwork they were doing," he says.

Vendors can cycle people through training, which is difficultfor smaller carriers such as Buckeye. "Both of our vendors areMicrosoft Gold Partners," continues Haines. "They can haveMicrosoft come in and do in-house training. We're basicallyempowered with that knowledge because of our partners. Those arethe things we are able to leverage by outsourcing."

Penn National has begun to do more outsourcing in recent yearsfor a combination of reasons, indicates Jenkins. One reason is toobtain the skills the carrier does not have on staff to meet thebusiness requirements of the systems that have been installed. Theability to manage the outsourcing is important, too. "I'm not goingto outsource something I can't manage properly because that's aprescription for disaster," he says.

For example, Penn National purchased the Pegasystems rulesengine. Jenkins knew he didn't have the skill sets internally atthe time the carrier bought that particular tool, so Penn Nationalis using Pegasystems personnel to help build the workflow,underwriting workstation, and scorecard using business rules. Thecarrier also benefits by getting the staff up-to-date on the use ofthat tool going forward. "We are bringing outsourcers in to help uswith that skill transfer," notes Jenkins.

With its broad spectrum of services, insurance is a difficultbusiness for IT to be able to raise itself to a level that would beviewed as a core competency for a carrier, Haas believes. However,IT is critical to the successful operation of an insurance company,he adds. "A lot of the functions that are good candidates for corecompetency in insurance cannot be performed without a highlycapable IT structure delivering the support and services," heemphasizes.

The gamut of IT services runs from the management of theindividual hardware, platforms, servers, and mainframes to thehigher-level points of business analysis and systems architecture.To a large degree, all of these services function as a part of thebusiness operation. Haas doesn't recommend Everest's clientsoutsource these functions because those services have such a tightintegration and linkage to business operations.

At the other end of the IT scale, Haas contends software is rifefor consideration of outsourcing. "There are plenty ofopportunities for companies to determine they need some kind ofleverage to improve quality, be more agile and flexible, or tolower their operational budget," he says. "There are a lot of IToutsourcers out there that can provide that service."

On the technical side of Buckeye's IT department, resources arelimited, according to Haines. The company has established anotherdivision within IT that serves as an operations department, though."As we were automating processes for underwriting, people becameexpendable," he says. "Rather than let them go, we transferred themto the operations part of the IT department to do systems testingand outside Web site support for our agencies. We were able toleverage their underwriting knowledge."

This was important because Buckeye doesn't like to use itsoutside vendors for front-line testing. Haines believes the outsidevendors actually slow down the process. "As good as [vendors] are,they don't know Buckeye products like Buckeye employees do," hesays. "To have [vendors] do front-line testing is no benefit tous."

In Grieve's experience, outsourcing is more dangerous and a lotmore sensitive than many business people give it credit for. Hepoints to examples of carriers declaring they outsource all theirlegacy maintenance so their internal staff can do development work."That makes sense on the surface, but there are significantproblems with that scenario," he asserts. Whoever is going to takeresponsibility for running the legacy systems is going to have tolearn the details of that system, and that's not always easybecause some legacy systems have poorly written code and are badlylacking in documentation, he explains. "Having other people becomeresponsible for [maintenance] probably takes longer than mostpeople assume because of the learning curve," he says. "Theredefinitely are carriers that have been disappointed in the amountof time and energy it takes to transfer legacy systems to anoffshore support vendor. [The carriers] haven't gotten rid of theseissues because the vendor that has acquired responsibility forrunning those systems cannot understand everything about thesystems, and [the carriers] potentially are losing a lot ofinstitutional knowledge."

Another area carriers often don't think about is the number ofyears they are going to need to keep those legacy systemsfunctioning. "[Carriers] are not replacing all the functions thelegacy systems perform, so they have to keep those systemsfunctioning for an extended period of time," Grieve continues."Outsourcing clearly works when something is more like autility–running the help desk or communication servers. Those kindsof things seem to be the place where it is the leastproblematic."

Haas doesn't advise clients to be afraid of the outsourcingoption, but he urges caution. "[Carriers] need to move forwardslowly and methodically and take advantage of best practice when itcomes to outsourcing," he says. "They can't rush into it. They needto understand outsourcing brings new risk they might notnecessarily be familiar with."

Risk can be managed and mitigated, however. "One of the phraseswe use is 'fear, uncertainty, and doubt' about the risks ofoutsourcing," says Haas. "There are areas where things can gowrong. But if you listen to the experience of others and the bestpractices in the industry, the risks are known and are manageablealong that path."

Determining the best strategy to take all boils down to carriershaving to determine what the differentiators are between themselvesand the competition, Jenkins believes. "There are those things thatare useful commodities and those things that could bedifferentiators," he says.

When a carrier decides to outsource a function or a commodity,Jenkins warns not to neglect all the implications for thatparticular system or function. "If you outsource something anddon't understand the implications to other systems, you may have aproblem," he concludes.