Share this content

Interview: Ally Thomson, Lead Application Architect, Prudential UK

1st Nov 2005
Share this content

The IT architects drew breath, squared their shoulders and turned the handle of the meeting room door. A sea of faces watched them move to the head of the table. This was it; the new IT plans were ready, the die was cast, and now they had to tell the project owners. It wasn't going to be popular with some, and everyone knew it.

In early 2002 Prudential UK was integrating product aligned business units to improve competitiveness. Growth was imperative, and an efficient customer focus the way forward, but costs had to be drastically reduced. "One Pru" was the corporate strategy and had universal backing, but the how was more difficult.

A sound IT infrastructure was crucial and a fledgling IT architecture department set up. Their task, to provide design guidance to business, and establish a shared IT infrastructure that could be exploited across “One Pru”. Unfortunately that meant a large CRM project was going to have to be fundamentally redesigned; and a lot of work and vested interest overturned. People were not going to be happy.

They were even less happy when the CRM project was subsequently shelved by the Executive. The project had focussed on a large customer data warehouse, filled with all the data imaginable to support direct marketing. Although a very important means of customer development, there was a more urgent need to provide better customer service via the telephone.

Money was being wasted supporting 25 different contact centres; agents frequently had difficulty accessing data from the 26 policy admin systems sitting on everything from PCs to mainframes; and if a customer wanted access to a different policy they would have to call a different number. Apart from the cost, the customer experience was dire.

The business case for service was stronger than direct marketing, especially as the CRM project costs shot through the roof when scaled across the new organisation. In addition the board were concerned about the higher risk of CRM project failure rates. They wanted to reduce the number of call centres, move some offshore , and focus each on a different customer segment, with the ability to look at all policy holdings. The savings on costs and customer discontent combined with a better experience were compelling. Direct marketing would have to take a back seat for a while.

The architects put together development plans. Their 'Lego' approach to creating a customer centric infrastructure consisted of a build up of short interlocking projects.

1. The first job was architecture. The team had reservations about packaged CRM suites because of fixed processes and data models, so examined a more flexible option based on a Chordiant platform. However, they concluded that open integration was the name of the game, and decided on a BEA Weblogic application server platform.

2. Next came the delivery of a bespoke call centre application supported by good middleware connectivity using IBM MQ. Underpinning this application was a new operational customer database (OCDB). This contained a basic customer profile and most importantly pointers to relevant policy systems. Initially 4 of the 26 policy systems were linked - the others would be integrated at a later date. The quality of the data on this linchpin system was crucial and an ETL tool from Informatica was combined with a data quality application from Trillium Software (see the Trillium case study - Prudential creates a single view of the customer using Trillium Software).

3. Next came the building of a corporate information data warehouse to satisfy both management information and direct marketing needs. Using Oracle for storage this would have a variety of analysis tools, including query and reporting from Business Objects, and datamining from SPSS’s Clementine. The usual timescales for this project were shortened by the reuse of the logical data model designed for the original CRM project; and a policy to only fill the 'shelves' of the data warehouse for approved projects. Therefore all data in the warehouse would have a business case.

When I spoke to Ally I asked him where next? He said that work was needed on three fronts. Firstly, delivery of improved direct marketing capability based on the data warehouse, a Chordiant campaign management platform, and SPSS analytics.

Secondly, to go back and complete the OCDB so it covered all customers and all policies. "We need to finish the job," he said, "this tidying up work often gets left out."

Lastly is the issue of data quality. The data put on the OCDB is a high standard but they need to tackle the root causes of poor data collection. The format of data from the different policy systems needs to be standardised and data collectors in the business have to accept stewardship of data quality – they have to care about it.

The architects went through a baptism of fire to get their plans accepted; they had to overcome vendor shenanigans, project manager 'just get it in' mentality, and a frustrated marketing department but in the end they have triumphed - "with the help of some focussed input at key times from Deloittes," says Ally "its always useful to have an independent ally."

Jennifer Kirkby


Jennifer Kirkby
Strategy & Business Analyst

[email protected]

I would like to thank Harris Communications for introducing me to Ally Thomson.

We want to create a place where you can talk about the real issues you face, and share your views on techniques and technologies; what does and does not work.

Visit our new 'Interviews: Stories from the front-line' page »

If you are a marketing or CRM practioner and would like to share your story with us please email: [email protected]

If you are a CRM vendor and would like to be interviewed by Stuart Lauchlan please email: [email protected].

Replies (0)

Please login or register to join the discussion.

There are currently no replies, be the first to post a reply.