Software Application Testing in Insurance, Part II: Getting Test Data

Software Application Testing in Insurance, Part II: Getting Test Data
Previous posts about testing Topic 1: Automated Testing Topic 2: Getting Test Data Bad test data can mean that the best tests fail to predict real world problems. While many test topics apply to all industries, insurance carriers face some unique issues when it comes to getting good test data. Due to HIPAA and other industry regulations, utilizing real data for testing is a gray area, as the test team does not necessarily need to be working with real data to do their jobs. It’s a difficult task to take real data and “clean” it for testing. It’s also a difficult task to generate good test data from scratch, though this is really the best solution. An insurer should take the time to have a developer create a small application/utility that generates test data specifically for the application being tested. This utility should be generating random data but follow a set of rules to keep the data within the bounds of reality. It should intentionally create “edge cases” that might stress the system and reveal errors. It should be easily adjusted to create small data sets for simple tests and very large data sets for performance/scalability tests. While it may take a few days to implement this utility, it will save a lot of time later. Instead of struggling for a half a day every time tests need to be run (a common complaint), the work to manage this will be completed up front. Unfortunately, since every software application has different data needs, this kind of utility will likely have to be written separately (or at least significantly rewritten) for each new application that needs to be tested. 90% or more of tests should be run against a very small set of data. Running tests against a huge database is unnecessary, will slow down the tests themselves, and will complicate things. Most tests are meant to verify very specific issues and there is no reason the database needs to contain any more than the bare minimum of data. Only a very small number of tests need to be run against a large database. Many insurers simply copy over their entire real-world database and then run tests against it. This not only creates security issues but makes the job harder for development and quality assurance teams.

Micro-insurance — Thinking innovatively in targeting the uninsured

Micro-insurance — Thinking innovatively in targeting the uninsured
On a recent trip to South Africa, I was interested to see some innovative ideas targeted at the uninsured, currently around 90% of the population. South Africa, along with other emerging economies, face many structural challenges impeding the broad adoption of insurance. Remote areas of the country have poor road and communication infrastructure. Almost two-thirds of the population have no bank account. Accessibility to financial services is low as is the understanding of the value of such offerings. In a bid to rectify this, the government put in place targets back in 2003 for the financial services industry. The banking sector had to introduce a low cost bank account, now in place, and the insurers had to commit to massively increasing accessibility to insurance. The low cost bank account, called Mzanzi, is standard debit-card based account attracting no service fees. The insurers have accepted the challenge and plan to increase current penetration rates by 180% over the next five or so years.

In my conversations with South African insurers, it’s clear that whilst committed to these targets, tapping into the previously uninsured market remains immensely challenging. The innovation is mostly occurring in the area of products and premium collection. Tying product requirements to the needs of the uninsured is a sure-fire way of garnering interest. House, motor policies have little relevance for those who own none of these assets. However, household contents policies, funeral policies and term life are of interest.

One of the constraints for insurers has been and still is the collection of premiums. With many people not having bank accounts, credit/debit payments or direct debits are just not possible. Mobile phones are being used in one or two cases to purchase insurance. Voucher cards, paid for by cash upfront, offering term life insurance can be bought at supermarkets and other consumer outlets.

Technology can play a role in supporting this small but growing market. Low-cost policy administration and claims systems can form the heart beat of such an operation supported by a flexible product configuration tool. There is little need for broker/agent or consumer portal technology. Products in these markets such as shack insurance, life insurance for a month, or crop insurance may seem unusual but can be supported through the use of modern packaged tools. One of the more unusual product characteristics is the method of premium collection. For example, premium paid upfront, or monthly, or paid via a mobile phone account (or other third party collector). This flexibility needs to be supported a modern product configuration tool.

In South Africa, as in some other emerging countries, tapping the previously uninsured is a government enforced social objective and this has focused insurer’s attention on this challenging area. Micro-insurance is unchartered territory and as such it’s not possible for insurers to look to established markets for best practices. Successful insurers in these markets will continue to innovate in areas of product design and premium collection and this analyst will be keeping an eye on how this market evolves.

Software Application Testing in Insurance, Part I: Automated Testing

Software Application Testing in Insurance, Part I: Automated Testing
In my last post I talked about the vendor proof of concept as a way for insurers to avoid buying “a lemon”. The same risk management needs to apply when an insurer develops software internally, and that’s achieved with strong testing practices. Software testing is a huge topic, and I’m going to split the discussion up over a series of blog posts. There are a lot of great books and articles out there about software testing, but in these posts I’ll try to give it an insurance industry spin. You might run into different issues depending on whether you are building web portals, data-heavy applications, server utilities, or mainframe applications, though in general the same methodologies still apply. Topic 1: Automated Testing From the lowest to highest level, test cases can be broken into the following three categories 1. Unit Tests: Code-based test cases that developers write to test their own code. Typically these are written using developer tools such as the open source JUnit. 2. Automated System Tests: Test scripts that can be run against the entire system, and can be created by developers or test teams. These are typically written with applications that are specifically geared to help write tests for web-based, Windows-based, or Java-based applications. 3. Manual Tests: Test scripts that are manually executed by a test or QA team. The biggest testing issue I see at insurance companies is that there are too many manual test processes and not enough automated testing. Manual tests are important, but they are slow, difficult to reproduce reliably, costly, and aren’t scalable. Plus, it’s much more likely that previously fixed bugs will pop up again without being noticed. With a full suite of Automated System Tests and Unit Tests, large changes can be made to a software application with confidence. Many developers complain about writing unit tests or skip this step, claiming the responsibility lies with the QA team, or saying they will take care of it later (and then never do). The more unit tests written, the easier it gets to write them, and the less time will be spent fixing bugs later. And, remember, the later a bug is discovered and fixed, the costlier it becomes, especially when the bug isn’t found until the system is in production. To increase the automated test footprint on a system built using only manual testing, start requiring new unit tests for all bug fixes going forward. Each time the test group discovers a bug, an Automated System Test or a Unit Test should be written to repeat that bug before the developer fixes the code. Once the code is changed, the team can verify that the bug has been fixed by running the new test case again and seeing that it now works. This also creates a repeatable automated test that prevents the bug from reintroduction.

The Potential Growth Segment of Rural China

The Potential Growth Segment of Rural China
Being a Celent insurance analyst based in China, I sometimes meet with Celent customers who visit Beijing and share my insights on China insurance market growth and technology development. Many customers are interested in the potential market size, the competitiveness of the market, and the progress of technology. But recently, when I meet Celent customers in Beijing, they ask me a new question: will the insurance industry in China continue its high growth? Consumer confidence is down because of the global financial crisis and the many countries in recession. Thus China’s exports are decreasing quickly, and because this influences other industries, we’re seeing China’s economic development slow down. Facing this, the Chinese government decided to stimulate internal investment and consumption. Since China has a population of 1.3 billion, it is a big market for its own products. At present, the rural areas in China are underdeveloped, and rural incomes are much lower. Some government policies are aimed to increase rural people’s income. So in the not too distant future, the rural area could be a large potential market for many industries, including insurance. The insurance premium from rural areas is very low. The market is dominated by a few large insurance companies and is still not highly competitive. The products being sold in rural areas are not specialized for rural people and thus couldn’t arouse their interest. The distribution channel is still dominated by sales agents. In June 2008, China insurance regulators started the micro-insurance experiment. To participate in the experiment, companies must develop simple products targeting low income people in rural areas, with payouts of RMB 10,000 Yuan to RMB 50,000 Yuan, low premiums, simple underwriting rules, and a simple claims process. The regulation also promotes the use of multichannel distribution and new technologies such as wireless solutions. By entering into the rural area, in the beginning, insurance companies may only get a very low premium from each client. However, as a mid-term to long-term investment, the rural area is a huge potential market for insurers, and future, rapid growth could still be expected.

References . . . Fonts . . . The Meaning of Cool

References . . . Fonts . . . The Meaning of Cool
References Whenever Celent publishes an ABCD vendor report, we always ask the vendors for references. We subsequently speak to these references and/or ask them to take a short online survey. When we help an insurer with a vendor selection process, we also contact references. In general, we expect references to be quite positive. There is a hope–since we do not live in the best of all possible worlds with the best of all possible software solutions–that references will also mention some things that they would like to see improved–either about the application or the vendor. But still, overall, the expectation is a bunch of A’s, A-‘s, and a couple of B+’s. Once in a while a reference will come out with a string of negatives–too slow, too expensive, too hard to implement or change, too much hassle working with this vendor’s staff. Enough negatives that the reference is basically saying caveat emptor–or even, you might want to take your business elsewhere. What gives? How could the vendor not know, in general, what the reference is thinking–and knowing that, just give another reference? I don’t have a good answer. But it looks like some vendor account managers need to do a better job of asking, listening, and getting broken things fixed. Fonts There is a school of thought in web design that small fonts are cool–and really teeny-tiny fonts are very cool. Personally I’m a “form and function” guy. Aesthetically pleasing forms are good, but only if the intended function is achieved. I’m not quite sure what is the function of website fonts too small to be read by anyone over the age of 40. Or maybe that is the function. The Meaning of Cool And while we are on the topic of cool. What does “cool” mean? It can mean “yes”–as in “It’s noon, let’s go get a sandwich.” “Cool.” It can also mean “good” — as in “Look, I can put a lot more text in this label with a 1.5 point font.” “Cool.” But at a deeper level, it seems to mean something more. It seems to mean “This statement / thing / activity is just my style, just my taste, just my thing. And . . . I don’t have to explain how or why that is.”

The Rise of the Capable Insurer

The Rise of the Capable Insurer

I was talking about the financial crisis to an executive at a large life insurer recently. Given the steady stream of dismal financial news over the past two months, you might have expected it to turn into a “woe is me!” conversation. But in fact, the opposite occurred.

“We’re doing fine,” the exec told me, “and quite frankly we’re patting ourselves on the back for sticking with our investment strategies.” Their CFO had apparently resisted the pressure to chase high returns and is now being hailed internally as a quiet hero. As a result of his tenacity, the company is well positioned to invest in technology, service innovation, and perhaps even acquisitions of some less fortunate (less lucky? less well-run?) companies.

This is one example of an insurer doing things right, and doing things well. Somehow the bad news about our industry blares from the rooftops, while success stories like this get little notice. We’ve tried to elevate the success stories through our annual Model Carrier research, which offers a series of short case studies on effective use of technology. But it is difficult to battle the perception that insurers are laggards in terms of their business and technology strategies.

This theme of the capable insurer came up again last week at a Celent breakfast event in London. My colleague from Oliver Wyman, Andy Rear, used the term to frame a discussion around the strategies of insurers poised for success. His thesis—that capable insurers are emerging, particularly those that effectively manage customers, create rational service models, maintain operational agility, and recycle capital rapidly—really struck a chord with me.

There will always be winners and losers in the battle for premium dollars and customer loyalty. And we agree with Andy that the winners will have clearly defined strategies that make them more nimble and responsive to constant market changes. Getting there, as always, will be a challenge. But examples are emerging, so we know it can be done.

Insurers Strategy Concerns: the big shift?

Insurers Strategy Concerns: the big shift?

American and European insurers are currently facing hard times. While everybody can explain now how we got into this situation, it is still unclear how precisely financial companies and notably insurers will change their strategy in the near future and particularly how they will align their IT resources in order to respond in this fast changing environment.

In a recent report (“Bad News on the Street: Insurance IT Strategy and the Financial Crisis”), Celent reviews the different aspects that might have an impact on insurers strategists in the near future and evaluates which IT projects might be the preferred choices in this period of financial uncertainty. Not long ago, CIOs were working on initiatives aiming at capturing growth in mature markets, trying to ease the way they were doing business and emphasizing agility in priority. Nowadays it seems that insurers get more concerned about their expense ratio. Indeed, when assets are shrinking and trigger above-average depreciations, it is important to have profitable insured risks and clients in its books. What has caused troubles to the insurance sector in 2008 is not directly the recession coming but more the rapid decrease of values in the financial markets worldwide. Of course many will say that both are related and they are right but what is making the problem more complicated for insurance companies is the sudden and strong drop of the financial markets (30% for the Dow Jones and the DJ Euro Stoxx 50 from September to October 2008). There are past examples that help us better understand what is currently happening. For instance, in mid-June 2002 CREDIT SUISSE was forced to bail out its insurance company Winterthur, whose financial strength had suffered from the general malaise in stock markets and from the low level of confidence in insurers shown by consumers.

As we all know, financial markets are generally good indicators to anticipate economic cycles and based on their recent performance, it seems that investors are seeing a hard and potentially long recession ahead. In this situation, Celent believes that insurers will have to focus on basics. In other words, we expect insurers to perform a big strategic shift, which will lead them to get back to more prudence in terms of asset investments and to launch initiatives aiming at improving return on their insurance portfolio in order to improve their overall loss and expense ratios. To win the battle for the good risks, business intelligence will be an important IT resource. In order to improve their expense ratio, Business Process Management (BPM) and alternatively Business Process Outsourcing (BPO) might emerge as key IT initiatives in the near future. For instance, Zurich Financial Services has announced last October their plan to outsource their data-centers currently based in the US and in Switzerland in the frame of a more general cost saving plan.

Celent will publish its traditional annual insurance CIO survey in the first quarter of 2009 (for the US, Europe and Asia). We are going to know much more about insurers’ intentions soon.

Riding out the market crisis

Riding out the market crisis

One of the job functions of an analyst is being asked to predict the future and no more so that in this current economic climate. As the year end approaches, I am being asked this question on a daily basis. The question usually masks a certain amount of personal concern about how 2009 might turn out.

Anecdotally, from conversations and interactions that we are having, there is some belt tightening, some teeth sucking, and grimacing all around. But as yet, we have not seen massive slashing of 2009 budgets.

In a recent poll of insurers (October 2008), we asked about the impact on IT investments in the current climate. The chart below summarise the results. It’s heartening to see that for most insurers, business cases are being revised or spend re-prioritised. For a handful, there is no impact. Admittedly, as the year progresses and as economies around the world appear to slide into deeper trouble, this data may seem out dated.

So as the financial news changes daily, as new presidents are inaugurated, and current prime ministers grapple with the limits of Keynesian economics in a global downturn, Celent will continue to keep a beady eye on IT spend and budgets. As a team, we are in the process of collecting data from CIOs from the across the globe as I type. We’ll have more quantitative data at the year end in our regional CIO survey reports. Watch this space for the update.

Best Practices for a Vendor Proof-of-Concept

Best Practices for a Vendor Proof-of-Concept
Insurers who have been through the arduous process of whittling a long list of policy admin system vendors down to a short list, and then whittling a short list of vendors down to an even shorter list, often ask us how they can be sure they’ve made the right choice before investing potentially millions of dollars and multiple years in their decision. Engaging in an extended proof-of-concept is one way to test out a vendor, but it needs to be done the right way if it is going to truly demonstrate the system’s value. For a proof-of-concept to be successful, you need to make sure that you’re testing enough functionality, but also to keep it limited so that the goals are realistic. While Celent regularly works with insurers to define the scope and requirements of proofs-of-concept, in this post I’d like to talk about some of the more intangible factors for success. There are two ways to approach a vendor proof-of-concept, depending on whether you have selected one vendor and are putting them through a final test, or if you are still comparing multiple vendors and therefore have two proofs-of-concept going on at the same time. You’re better off if you can work with one vendor, as you can take the tests to a deeper level and have your resources focus exclusively on making it a success. You should consider installing the vendor’s system in your own data center, even if some of the development work they do during the POC is at their own site. It’s crucial to dedicate a full resource from your staff to be involved with the entire POC, ideally doing some of the modeling or integration work. It doesn’t help you if the vendor goes away for a month and returns with a finished model and tells you that it was “easy to do.” You need to understand exactly what kind of work is involved, how difficult it will be to manage once the vendor is no longer consulting with you, and how much time it will take to train business users on the system. In terms of duration, I’ve seen proofs-of-concept take anywhere from two weeks to three months. Any longer than three months and it’s no longer a proof-of-concept, but just a normal implementation with an “escape clause.” With one vendor, you should schedule the proof-of-concept phase for at least two months, but plan the work so that whatever you do can be put towards the true implementation if and when you choose to continue. Finally–especially if you are working with a single vendor–Celent is in favor of paying a fair price for the proof-of-concept phase. Paid proofs-of-concept are more successful. Committing money as well as resources signifies to the vendor that there is true involvement from the client, and it positions you to dedicate true resources. An unpaid POC is like playing poker without having to pay the ante. You might start off interested in the game but you won’t care as much about your cards. The reality is that a proof-of-concept won’t be successful without both the carrier and vendor working together, regardless of how strong a solution the vendor offers.

Update to "Bad News on the Street, Insurance IT Strategy and the Financial Crisis"

Update to "Bad News on the Street, Insurance IT Strategy and the Financial Crisis"

Since we published Bad News on the Street, Insurance IT Strategy and the Financial Crisis in early October, the economic roller coaster continues to twist and gyrate. One assumption in that report, that there will be a “mild to moderate” recession, is being severely challenged. The mortgage meltdown morphed into a credit confidence crisis which precipitated a consumer confidence downturn, increasing job losses, accelerated by an auto industry meltdown. Suddenly, a question that seemed ridiculous a short time ago seems prudent: “Is $750 billion enough?”

Strange actions have been seen on the street. “Traditional” insurance companies are courting and marrying tiny banks so that they can meet at the TARP alter. Other insurers are vehemently rejecting any government assistance and the resultant “strings” attached. Foreign-owned insurers are directly petitioning the US government for assistance.

Since the report, third quarter numbers have been released and the results are not kind. The third quarter 2008 net income of the largest 25 Property/Casualty and Life/Annuity/Health insurers is 97% below that of last year. (These numbers exclude AIG.)

Discussing the situation with insurers in North America, Celent finds that most are taking a “wait and see” approach to IT budgeting. Strategic projects that are already underway are not being cancelled, but those that were planned to be launched in late 2008 are being delayed. In late October, Celent surveyed CIOs at North American insurance companies about projections for their 2009 budgets. No one reported a decline and 34% said their budgets would remain flat at 2008 levels. When asked to rate this amount against the strategic business and technology objectives they expected, most (75%) characterized this as “adequate”.

Barring economic catastrophe, the next game-changing event will be modifications in regulation. Two central questions loom. First, to what extent will the insurance industry be included in general financial reforms targeted toward banking institutions? Second, which way will the ongoing tug of war between Federal and State oversight go?

A slim ray of optimism exists in rumors that a hard market is coming for commercial Property/Casualty products. We will keep our ears to the ground and our radar on scan for additional developments.