After several complaints from readers that it was difficult or impossible to comment on the Celent blog, we’ve embraced a social web approach and have opened the comments up to everyone. Comments can be posted without a WordPress account, though they will be moderated by the Celent analyst team and may not appear on the site immediately. We invite you to share your thoughts and join the discussion.
Archives for February 2010
In a recent conversation with a vendor, I was asked if there was any way in which we [Celent] could encourage/support the standardization of request for information documents sent out by insurers. Think ACORD Standards for RFIs! At the heart of her question, was a sense of deep frustration at the evaluation process which inhibits the vendor from highlighting or differentiating themselves. I have some sympathy with this view.
IT departments have become very good at comparing the data for RFI/RFPs in two-dimensions. A structured, transparent evaluation process is an important step in choosing what it likely to be a significant IT investment in the case of a core system replacement. The evaluation process can be used to generate hard facts highlighting the differences in system functionality, company and delivery options.
For many insurers, the governance process requires a presentation to the project sponsors of a detailed quantitative analysis of vendor submissions, along with ranking and weightings. This is all well and good but this output can be incorrectly attributed the status of a statistically sound scientific evaluation. I have seen projects where a vendor has been chosen because they had 2 more points in the final analysis on paper.
Most of us would not buy a car based solely on a review of features and functions on the manufacture’s website or brochure. We’d be out there driving and deliberating the real experience of the open road, handling of corners, and comfort of the seats. All these factors are almost impossible to quantify in a brochure but vital in influencing our final choice.
And it’s similar in the world of core system evaluation. The proof of concept is vital addendum to the evaluation process. This is the time to put the vendor to the test. This stage of the evaluation should allow the buyer to really see how easy the product configurator might be, how well a vendor can understand requirements, how responsive/ organised the vendor is, or how much/little coding is required.
And in Celent’s view, proof of concepts should be paid for. It shows the commitment on part of the insurer, and it also encourages the vendor to be focused and committed to this important step. Being paid allows the vendor to justify allocating top staff otherwise committed to paid implementations. A recent evaluation project paid 4-figure sums to both short-listed vendors for a 3 month proof of concept.
The proof of concept is a great process by which to garner more buy-in from the business users, and to generate some excitement about what this change could bring to the organization. Adding the open road test to the brochure comparison will undoubtedly help the insurer make a more robust decision.
We have daily discussions with insurers about how to balance the tasks involved with the maintenance of a legacy system environment with those required for strategic system renewal. It brings to my mind the analogy of “fixing a plane in mid-flight”. Most IT shops have neither the capacity nor the skill sets to do both with their in house staff. These needs have created a large market for ITO, BPO, and system integration services. In observing this expanded sourcing model in action, it occurs to me that the whole organizational design of information areas is undergoing a change.
Most “shops” were built on a manufacturing design. The work was handled like this: “You, Mr/s. Insurance Business Person, tell me what you want (give me the specifications) and I will have my craftspersons (programmers) build it. We will then test it and deliver it to your “door”. “
Many efficiency and effectiveness improvements have been realized by insurance IT areas adopting production techniques such as TQM, Six Sigma, Lean, etc. However, instead of a manufacturing paradigm, the multiple vendor and relationship management challenges faced in 2010 brings to my mind more of an air traffic controller analogy – multiple planes in the air with the common objective of getting to the destination safely (first) and on time (second).
This would all be a cute analyst musing except that the skills involved with delivering in these two environments are very different. Manufacturing requires a technician’s precision; air traffic control requires a detailed understanding of flight (but you don’t have to be a pilot) and a keen sense of anticipation of what is likely to happen next. The people in the tower must be able to guide without their hands on the controls, must be able to see several steps ahead, and must have an effective guidance system.
For executive leadership in an insurance company, the analogy leads to a different search profile for a CIO. It is not necessary to fill these positions with the best technician, but is critical to have someone in place with the required “soft skills” to coordinate effectively.
(BTW, why are “soft” skills so hard to develop?)
I’ve been doing research for several reports on the topic of IT outsourcing, some about utilizing cloud computing for hardware and some about working with vendors to handle consulting and development. While these two areas are conceptually very different, the approach and business values are quite similar.
One misconception about both is that they are used for “replacement.” By this I mean that an insurer uses cloud computing to replace their data center or an insurer utilizes an IT service provider to replace their IT organization. While in some instances this might be true, it is rarely the case.
The other misconception is that an insurer uses cloud computing or consulting services to lower costs. Lower cost might be one reason, but shouldn’t the only reason. Many CIOs, however, do approach IT outsourcing primarily for the perceived cost benefit, and Celent sees this as a mistake. In many cases, some or all of the long term costs might actually be higher. This does not mean a cost-sensitive insurer should avoid IT outsourcing, but, rather, should proceed with an outsourcing project while looking at the overall business values associated with it.
The added business values are the other area of similarly for hardware and development outsourcing. Both help a company increase capacity, one with increased server capacity and the other with increased human capacity. Both help a company access new capabilities that they didn’t have earlier; cloud computing providing rapid server deployment and failover (among other things), development outsourcing providing resources with skills sets that did not exist in house. And, finally, both work best when thought of as a long-term strategy that will complement the existing IT and not just as a temporary measure or as a replacement for existing resources.
The takeaway is that any organization looking at IT outsourcing–whether for hardware, software, or people–should focus not on cost but on long term business value. Organizations that only care about cost are often disappointed by the outcome. Organizations that have a strategy to bring new capabilities and business value to users will be successful.