P & C Technology Blog

Grieve Spouts Off on Billing

2008-03-14T13:01:18-07:00

From time to time I get involved in webinars on various subjects. I recent spoke on the subject of billing and the growing need to replace legacy billing systems with modern, flexible software. The major themes of this talk were to do with enhancing customer service (for both insureds and agents), supporting profitable business growth and creating a more efficient business operation. If you would like to hear more please follow the link below. If you do I hope you find it interesting.

https://www1.gotomeeting.com/register/169610931

Talk with you soon.

Nothing Suceeds Like........

2008-03-06T07:38:26-08:00

When it comes to legacy systems replacement the definition of success varies from company to company. And the criteria for success and how those criteria are measured varies from pretty low to …………………….not very high.

Let’s consider four key criteria that might be appropriate to measure the degree of success of a core legacy system replacement:

· the new system was implemented into production where it meets the functional, technical and quality requirements as defined

· the replaced legacy assets were decommissioned and no longer run

· the project was completed roughly within time and cost parameters

· the estimated business benefits which were used to justify the cost of the project were substantially realized.

Clearly these criteria are cumulative with the first being the most basic measure. Indeed it tends to be this basic measure, and only this basic measure, which most carriers invoke when declaring success, or ……..putting the project on hold. And even by this basic measure it is generally agreed that at least half of all such projects fail, as in they don’t result in an implemented system, or result in only a partially implemented system. This low level of success criteria and its corresponding high level of failure is yet another indication of how hard it is to succeed at transformational change. In fact it is not uncommon for carriers to try two or three or more times to replace a core legacy system before finally succeeding. Consider the following time line which is real but has de-personalised to protect the honest folks who put it together:

· 1998 – Carrier’s “Replacement Project” convenes with its number one recommendation endorsed by CEO – Replace the current Claim System!!

· 1998 – IT commences a huge project to build its own claim system – X is the lead BA; Y is the sole SME

· 1999 – The project fails miserably; the CIO is fired. X and Y get to keep their jobs

· 2000 – After Y2K, an RFP team (led by Y) chooses a Software vendor to replace all systems

· 2001 – The project commences to implement the vendor’s Commercial Lines System

· 2002 – The project commences to build with the vendor a new claim system

· 2003 – Both efforts (led by Y) fail miserably

· 2003 – And yet another RFP commences to find another Claim system (led by X)

· 2004 – The RFP team concludes there’s nothing out there and Carrier should build its own system!!

· 2004 – The project to build a system begins; a screen-scrape of the old system for claims occurs in the meantime

· 2004 – Both projects (led by X) fail miserably

· 2005 – Carrier contracts with a new vendor and begins (in July) the first of three phases to replace the claims system

· 2006 – Phase 1 goes in on schedule

· 2007 – Phase 2 goes in on schedule

· 2008 – Phase 3 goes in on schedule

· 2008 – Ten years after Replacement II, carrier replaces a core operating system!!

The striking thing to me is that this story is not unique, it is common. Many carriers fail multiple times before they succeed at transformational change. The interesting thing in this instance is that having got it right, the carrier got it really right. The phases of the implementation went in on schedule, and by implication pretty much on budget as well. Now the legacy claims system has been “completely replaced”, allowing for legacy retirement. I don’t know the extent to which the stated benefits are being realized in this specific instance but as the song (almost) goes: “three out four ain’t bad”.

So are there any lessons that can be generalized from this particular story? Yes indeed.

They at least include the following:

· most carriers have no rational case for getting involved in trying to build core insurance applications. The apps are too complex and the carrier will almost certainly fail

· if you do not select a vendor partner carefully and thoroughly a “package” implementation is also likely to fail

· if you are involved in a build failure or “package” failure learn from it like the folks in the timeline did

· just because there wasn’t a good third party solution the last time you looked, doesn’t mean there isn’t now

And finally, this is a story with a happy ending. And happy endings are not guaranteed.

As we have said before, transformational change is a risky business.

Big Brother Is Not Watching

2008-02-07T18:52:09-08:00

Please excuse my recent absence. I’d love to report that my silence was due to a prolonged stay on a tropical island with no internet access. Unfortunately, that’s not anywhere near the truth. In fact I’ve been in Canada ….. so look out for hockey analogies in the coming weeks. Anyway, let’s not dwell on the frozen north, lets talk about …….. your car.

An EDR, or Event Data Recorder, is a computer chip which sits in the driver’s airbag housing in an automobile. The chances are that if you have a newer car or truck you have an EDR onboard. So, what is an EDR? Well first off, what it is not is a GPS system. It is not an electronic “Big Brother” that tracks where you go, when you go and how fast to go. In fact most of the time an EDR does nothing. It just sits there. However, if you brake hard, swerve, hit a speed bump or accelerate rapidly your EDR will wake up and start recording all kinds of interesting information.

Currently more than two thirds of all new cars, SUVs and light trucks are equipped with an EDR. By 2010 this figure is estimated to be as high as 85%. So it is increasingly likely that if you are involved in a car accident that at least one of the vehicles involved will have an EDR. So what? Well let’s go back to the triggering event that causes the EDR to “wake up”. Events like hard breaking, swerving, or violent acceleration are often followed by a car crash. So when such a triggering event wakes the EDR it starts collecting data that can be used in the analysis of a claim event. Among other things, the EDR will record acceleration/deceleration, vehicle speed, engine throttle and braking, engine RPM count and seatbelt usage. This information can also be recorded twice for two separate events (think of a multi-vehicle event where your car is rear-ended and then is propelled into the car in front of you). With this information in hand a qualified analyst can build an accurate picture of the collision which can determine the nature and at-fault characteristics of a collision and also the extent to which various types of soft tissue injury are consistent with the accident characteristics.

In fact courts have consistently found EDR data to be scientifically reliable and relevant and to meet admissibility criteria. In other words an EDR is a trusted witness to the collision event. The data collected can establish or identify the at-fault nature, severity and injury causation or relatedness of a crash; questionable or fraudulent soft tissue injuries; collision sequence in a multi-vehicle accident; staged collisions and validation of “phantom collisions” and whether the collision occurred during the policy period and is therefore a covered loss.

Given the huge potential of EDR data to reduce litigation and fraud some predictions are obvious: the plaintiff’s lawyers will (and indeed have all ready started to) try to scare and confuse state legislators and regulators into banning EDR data from the courtroom and into convincing the public that EDRs are a threat to our privacy; availability and admissibility of EDR data will vary from state to state; and, despite the issues raised here, EDR data will become a key part of every auto accident claim file over the next few years. EDR technology is about to radically change the multi-billion dollar business of automobile insurance claims handling.

Unfortunately, Anonymous

2008-01-09T14:35:59-08:00

Dear Unfortunately Anonymous,

This blog is not a forum for anonymous accusations, so unfortunately I have removed your comment.

If you wish to comment in future, please identify yourself.

Thank you,

George Grieve

Happy New Year from Accenture

2007-12-31T13:26:40-08:00

As many of you know, especially those of you who are Guidewire clients, Accenture filed a lawsuit recently alleging that Guidewire Software, has infringed the U.S. patent protecting the Accenture Claim Components solution and has misappropriated trade secrets related to the design, coding and implementation of the Accenture software. Here is the body of the original press coverage:

Accenture Sues Guidewire for Alleged Patent Infringement
By Anthony O'Donnell

Accenture alleges claims software rival Guidewire deliberately used intellectual property associated with Accenture Claim Components.

Click here to read more...

Guidewire’s initial response (http://www.guidewire.com/news_events/pr/071218) was followed on Friday, December 21^st by a more strongly worded reaction which includes the following from CEO John Raguin:

“The Guidewire team takes immense pride in the quality of our products and how quickly ClaimCenter has become the best modern claims system in the world,” said John Raguin

, chief executive officer, Guidewire Software. “We have grown from the status of entrant to market leader by hiring the best people, using innovative software development techniques and most importantly, working closely with our customers. Our customers and the industry as a whole, appreciate Guidewire’s reputation for integrity and fair competition. While we continue to review our litigation options, we can assure them that we have not misappropriated any Accenture trade secrets and we are confident that we have not infringed Accenture’s patent. We view these allegations as a tactic intended to disrupt our business.”

So, what do we make of this?

As you all know Guidewire sponsors this blog. Additionally, my company, CastleBay Consulting, has a long established relationship with Guidewire. I know many people at the company, including the founders, and have always enjoyed working with them for their high standards of professionalism and ethics. So, I am probably biased, but even allowing for that possibility, here are a couple of observations which make me scratch my head:

Accenture’s software is written in .Net, while ClaimsCenter is written in Java, so how much code and/or design IP could Guidewire have actually appropriated? Anything which Guidewire stole would have to be redesigned and rewritten from the ground up.
Accenture claims that Guidewire developed and brought ClaimsCenter to market so quickly that they must have stolen code and or ideas. How then do they explain the development and launch of BillingCenter which took about the same amount of time as ClaimsCenter, and the ongoing rapid evolution of PolicyCenter? Accenture does not have either piece of software.

It will be interesting to see how this plays out. There are of course always two sides to every story and apparently Accenture thinks they have a case, but this just doesn’t make sense to me. We will continue to follow this closely and I am interested in your comments, especially those of you who are Guidewire clients. It speaks to the character of the Guidewire founders and principles that they are more surprised and bemused than angry. I am sure they would appreciate any statements of support, regardless of the way in which they are communicated.

On this sobering note I wish you all a prosperous, litigation-free New Year.