(Insurers upgrading policy administration systems are increasingly avoiding the above outcome, especially if they have modern systems, according to a new Celent report. Photo credit: Minnesota Historical Society.)
Good news abounds in Celent’s new study, “Benchmarking Policy Administration Upgrades,” co-authored by Mike Fitzgerald and Karlyn Carnahan. Based on a survey of 44 North American insurance carriers, the study found that the great majority of carriers either met budget (60.7%) or came below budget (10.7%), and most upgrade projects (64.3%) came in on time. Of the 28 upgrades covered in the study, all but five were reported as successful. “The unsuccessful efforts were all on legacy platforms, indicating that modern systems do indeed ease upgrade pain,” Celent concluded.
Mike Fitzgerald, Celent.
“A distinguishing feature of modern systems is a multi-tiered architecture – the separation of data from business rules (logic) from the user interface, etc.,” notes co-author Mike Fitzgerald. “Based on this architecture, it is logical that upgrades to the base system would be easier and this is what vendors of modern systems have claimed. This research is the first quantitative, objective validation of that claim.”
Among the reasons for challenged upgrade projects was skipping upgrades, which the survey found happened three times as many times as either point (e.g., 4.0 to 4.1) or next version upgrades. While more than a third (36.4%) of respondents had not upgraded their policy administration systems, the majority of respondents did point upgrades, which succeeded in all but one of 12 cases. Thirty percent of skipped version upgrades were unsuccessful.
Another key finding of the Celent study was that few carriers depend on internal resources (10.7%), preferring instead to ramp up their capabilities with assistance from vendors. The most commonly used vendor services were coding, configuration and testing according to Celent. “Some upgrade efforts use the package software vendor resources for coding and configuration and a separate, independent third-party organization to test the deliverable as a risk-mitigation approach,” the authors clarify.
About a third of Celent’s respondents noted that testing was the biggest difficulty associated with an upgrade, with an emphasis on user acceptance testing by the business. The study quotes a carrier respondent saying, “Unexpected integration errors and retrofits of existing modifications took longer and required more testing than planned.”
Source: Celent Policy Administration Upgrade Survey, Aug. 2014.
Other technical issues raised by respondents to the Celent survey included restructuring the technology to be browser-agnostic, dealing with database changes an implementing a new screen emulator. Some respondents reported complications complications from new bugs introduced over the course of the upgrade, and a carrier who skipped a version said its biggest difficulty was “plowing through several years of release upgrades at one time.”
Celent offered the following “key learnings” from the study:
- Avoid skipped upgrades. Several upgrades reported in the survey were still in progress, and these dealt with multiple version steps. The data indicates that the longer you put it off, the more challenging it will become.
- Leverage external services for assistance. Most respondents supplement their staff with resources from their software package vendor, a third party organization, or both.
- Testing, planning, and assuring a complete understanding of the impact of any functional modifications (configuration or coding) is critical.
- Testing and user acceptance always takes longer than programming changes. Plan the test plan accordingly.
- Make sure you include all your business partners in the planning and expectation setting.
Jim,
Thanks for your thoughtful and very interesting comment. I would like to note that my “commentary” is confined to observations Celent made in its report. That said, I’m intrigued by your analysis and the comparisons it suggests.
Anthony,
Thank you for bringing this study forward with your additional commentary. I would like to offer an alternative view to this which from an Insurity perspective, we don’t believe has been considered in this study nor in your commentary. And while we understand you are covering a common software upgrade model, this is definitely not the only one and we believe alternatives should have at least be mentioned.
Some specifics:
• Your premise is not incorrect from what we see in that Upgrading (to a new version within a product) is easier with newer technologies than it has been. We believe what your premise is showing however is that organizations are better able to project the costs and budget for them versus being surprised by them. That’s not an indicator of ease of upgrade but one of repeatable process with defined costs.
• What’s interesting is that the comparison is driven by designs from those vendors that require regular upgrades vs. cumulative point releases like we deliver. Regardless of the number or frequency of point upgrades (“Service Packs” to us), their designs force a regular rhythm of full version upgrades that require reimplementation of customizations and configurations. Our slipstream approach to new functionality delivered through Service Packs eliminates that in all but the most extreme cases (e.g. from Windows to .NET). Even within the point release process, the cumulative nature of our service packs allow users to skip them (up to 10) and not have to install all intervening releases when coming current.
• We understand some other vendor clients with a standard upgrade requirement, budget 20-30% of initial project implementation costs for upgrades every 3 years. That is not something that is openly considered by Carriers as part of the cost to license and implement and clearly it should.
• In general, Companies should not have to do the type of upgrade you are referencing to their Policy Administration System. The vendor they choose should have as part of what they pay for maintenance, the continuous addition of functionality and corrections over time in small doses, to be applied as they choose and avoiding a need for major disruptive and costly upgrades. There is enough of a disruption in implementing the system, the disruption should not continue past the deployment.
Thank you for bringing up the topic. We are very hopeful that beyond looking at how a an upgrade is “getting easier”, the Carriers will consider the unnecessary burden still being put onto them by those software models that require those upgrades and realize there are alternatives to that pathway.