BlackBerry Security vs Apple's Appstore – Will the PlayBook vs iPad split IT and Business?

BlackBerry Security vs Apple's Appstore – Will the PlayBook vs iPad split IT and Business?
There is no question that mobility and highly mobile devices will play a key role in insurance, both for customers but also as a means for conducting business. Apple have created a great deal of press with their iPhone and iPad products and are now making headway into insurance companies. Indeed in the last two weeks in the UK it was announced that Lloyds of London are now trialling iPads to enable electronic processes in a previously heavily paper based environment. Also in conversations with CIOs in the UK, the iPad and iPhone is proving popular with senior executives. Surely then BlackBerry have arrived too late with their not yet released PlayBook? Actually, BlackBerry may have arrived just in time as far as security specialists in insurers are concerned. Most people aren’t aware that the key reason BlackBerry is so popular with large corporates is the management and security features built into the platform. We’ve all read about the incidents where laptops have been left on trains and even read about organisations fined many millions of pounds through data loss events. Apple are investing in this area but are currently far behind BlackBerry in security features. Google’s Android platform is even further behind. It may well be that internal security teams are banking on PlayBook’s success as a way of delivering something iPad like to an organisation but retaining the necessary controls and measures to avoid significant embarrassment to the organisation. So the race is on. Will Apple secure their first mover advantage and build in enough enterprise level requirements to their platform in time or will BlackBerry’s strong history in enterprise solutions allow them to recapture lost market share?

Regulation raise IT hackles

Regulation raise IT hackles
The much feared UK emergency budget speech was made yesterday, and amongst a raft of changes impacting every corner of the British society was an increase in the tax on insurance purchases. The rate is to increase to 6%. A new peculiarity to this system is that tax on insurance sales will rise to 17.5% where the insurance is sold by seller of another product e.g. mechanical breakdown insurance (eg on domestic electrical appliances and secondhand cars), travel insurance, and insurance sold with TV and car hire. The challenge for the IT department is to respond in a timely fashion. Older legacy systems will have charges codified in several places and this reflecting this increase is not a simple matter. And once the change is made in the several systems and many places, there is the round of testing that is required. This whole cycle of change can be up to 9 months depending on current workload and dedicated IT test slots. In a conversation with a CIO on a different set of regulations, Solvency II, she raised the prospect of potentially having to replace incumbent legacy systems if they could not capture the additional data elements required in a reasonable cost. Adding new data elements to a core system, and having this reflecting in the appropriate screens is no trivial matter. And once again, requires serious investment of IT staff for testing for production. These real life use cases highlight the need to IT systems to be able to keep up with the change of the business, without a crippling cost. In choosing new systems, IT folk must focus as much on functionality as on the cost of ownership. As this week has shown once more, fleet of foot should be a key mantra in new system investment.

The Power of Three Smart People

The Power of Three Smart People

I was talking to a CIO at the LOMA ACORD Systems Forum in Las Vegas recently. The conversation went something like this.

“What do you think of providing chat capability, so agents in the field and underwriters can interact directly in real time?”

“We’ve had that since 2004.”

“How about e-delivery of policy documents?”

“We’ve been doing that for a long time. We set agent-level preferences for who gets paper and who gets electronic copies, and our agents can update their profiles at their convenience via the portal.”

“How about faxing or emailing of correspondence and other documents?”

“CSRs can do that from their desktops, without ever printing a thing.”

These and other tidbits from our conversation suggested that the increased focus on building relationships with agents has resulted in service improvements. By paying attention to how people get things done, the industry is evolving.

But the interesting thing is that this was not a conversation with a visionary, Tier 1 carrier. I was talking to a Tier 5 carrier, with a staff of perhaps 100 people, total. And the solutions being discussed are nearly all custom builds, done on the cheap by smart, creative staff.

This story illustrates the Three Smart People theory. (Credit for articulating the theory goes to my brother Kevin, a technologist outside the insurance industry.) Three Smart People says that problems are best solved by putting three smart people in a room and turning them loose, unencumbered by layers of management and the mental constraints that companies often place on their staff. The alternative of throwing bodies at problems in proportion to their size introduces uncertainty and risk, and almost never improves solution quality. More heads are better than one, but only until you reach the count of three.

Proponents of mega projects tell me that TSP is naïve. But I think that if three smart people are not able to solve a problem, it is quite possible that the problem has not been defined at a sufficient level of granularity. Got a big problem, with sweeping implications for business processes and a host of integrated systems? Break it down into components that can be digested by groups of three people over a period of weeks, not months. Then stand back and watch your company’s evolution accelerate.

New competition for UK policy admin vendors and more choice for insurers

New competition for UK policy admin vendors and more choice for insurers
The PAS space is hotting up here in the UK. Talk of eviscerated IT investment spending has been vastly overstated. Before the crisis really kicked off, insurers around the world were looking at how to address legacy core systems, and the level of RFI activity and PAS deals supported this. The recent announcement of Allianz UK and TIA was an example of a large UK insurer taking on the challenge of the legacy drag effect. Today, this was followed by the announcment of Axa Commercial replacing the current mainframe system with Duck Creek’s Example platform. Deal activity levels in the UK have seen a lull in the last twelve months, but Celent sees these two deals as a sign of the new times. Insurers will look to get back on track in IT investment as soon as possible, and most will have to face the challenge of replacing outdated core systems or at the very least, consolidating to a few of the best systems in house. Both these examples highlight the investment that has been going on for sometime by policy admin vendors from outside the UK. Celent’s view is that the UK market has been underserved by PAS vendors for some time now, and an increase in competition can only mean more choices for the insurer.

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.