With around 1,300 different brands of credit card now available in the UK, from around 50 different issuers, card penetration is much higher than that of the rest of Europe, and rapidly catching up with the the US.
In this highly competitive market card companies are seeking to offer more attractive, more flexible products and services (such as extended loyalty schemes, self-build, and variable interest rates) as routes, not only to winning new business, but also to retaining their
existing customers.
Because the system changes that would enable such products to be brought to market are subject to long lead times and high costs, issuers are increasingly finding it difficult to respond in a timely and cost effective manner. This is forcing them to investigate the best way to react and many are considering converting to new or emerging platforms. Indeed, a number of issuers have, over the past couple of years, already transferred their processor allegiances despite the known complexity of undertaking a conversion.
Historically the poor track record for implementing new processing facilities in the UK has been a significant worry to anyone thinking of taking on such a project. So what has changed? Through a combination of greatly enhanced platform functionality and best of breed project disciplines, there is now every reason to believe conversions can be delivered to plan and budget.
Issuers converting to new processing platforms have, in the past, admitted to a variety of costly and unsuccessful implementations, statistically in line with the experiences most businesses
have faced with complex IT projects. These ‘failures to deliver to expectations’ have placed huge burdens and constraints on operations and impacted business performance. Issuers who have
attempted to develop their own in-house platforms have fared little better and have encountered similar delivery cost and operational problems.
There are two key reasons why the risk of conversion failure is high:
• Conversions are unique programmes requiring specific and increasingly scarce skills
• Traditional implementation approaches are too narrowly focused on the IT related activities
Platform conversions are ‘one-off’ projects
As processing arrangements are typically long-term service contracts with third party providers (often for ten years), many issuers have almost entirely lost the expertise and knowledge of previous conversions, as their key staff have moved on (or even moved to the service provider under TUPE). This alone would be a serious enough issue if the conversion process was simple and straightforward, but this is rarely the case.
The processing platform is at the very heart of the card issuer, supporting all the major customer touchpoints and interfacing to multiple systems both within (such as settlement/ accounting/treasury etc) and outside (such as card production/credit scoring etc) the
operation.
The training impact of the conversion is daunting as the introduction of the new platform will affect the ways of working across the whole of the issuing value chain –one major issuer expended in excess of 12,000 man days on training alone!
Vast numbers of interfaces need to be replaced and/or de-commissioned at the time of conversion - this task is further complicated by the age and lack of documentation of many of the related systems and their interfaces.
The data migration activities are complex and time-consuming, as the mapping between old and new platforms needs to be comprehensively codified for every element. The conversion routines
need to be written and tested, and the converted data and balances, running into millions, if not billions of euros, repeatedly checked and verified at numerous ‘mock’ and ‘dress rehearsal’ conversions. The whole process is made even more difficult by the need to achieve all this within a pre-defined time window to minimise customer impact.
Traditional approaches are too narrowly focused
On the surface it appears attractive from a risk mitigation perspective to structure the conversion project on the basis of:
• Focusing initially on the technical aspects of the conversion (the argument goes – ‘suppliers do this all the time so let them take the lead’)
• Exploiting, after conversion the benefits of the new, flexible and functionally rich platform.
But this approach is flawed for two reasons. First, the focus of attention is disproportionately skewed towards the supplier-led activties, such as:
• Planning and executing the conversion of customer, transaction and historical data from old to new platform
• Building and testing the software to ensure that it satisfies interface and customisation requirements
• Introducing users to, and familiarising them with the new platform.
However, this leaves a huge burden with issuers to test the solution and train their staff in its use in the context of their wider business systems. This can be challenging, even when business process documentation, test scripts and training material are in existence and up to date. More often than not this is not the case.
Secondly, unless the underlying business systems and processes are refreshed and simplified, the prospects for longer-term value gain are stifled because:
• The solution that results will be a replay of most of the old characteristics and inefficiencies of
the legacy environment.
• The opportunities to optimise the performance of the new factory processes are not properly exploited.
In addition, staff morale is seriously affected by this approach as they can usually see the opportunities that are being misssed when existing ways of working are simply replicated in the new environment. This, in turn, directly affects the level of commitment to the change, and the willingness to adopt the new platform.
The answer is to adopt an approach that:
• Is primarily driven by the objective of creating value for the business
• Focuses on the conversion, and on delivering a solution that the business needs and wants
• Actively manages down the risks, as far as possible, that are inherent in ‘one-off’ conversion projects.
So what does this mean in practice?
The business case for conversion needs to be clearly and unambiguously expressed.
The rationale for conversion must be defined upfront - setting clear and measurable business targets in terms of the expected operational cost savings (eg headcount or platform costs), and the corresponding benefits such as improvements in the quality of customer acquired, marketing and the time to market for new products and services.
In setting these goals, the issuer must focus on its strengths, ambitions and aspirations. The planned role and scope of the operation and all third parties (eg those supporting card production or printing) must be clarified as soon as possible to ensure that the future operations, as designed, will deliver the business case.
Design the solution and the programme of activity around delivery of the business case.
Without taking a fresh look at service levels, peripheral activities and processing complexity, it is unlikely that real value will be derived from converting to a new platform. It is therefore vital that the programme is set up to challenge existing norms. Further, it must be made clear to all
parties involved that success is inextricably linked to the achievement of the platform conversion event and the delivery of the associated business benefits.
Thus, the programme must be explicitly designed and scoped to ensure that:
• The new operation is designed to deliver the signed-off benefits
• There is a clearly defined method for planning operational changes, and that there is visibility of the business benefits to be derived from those changes
• The blueprint for new operations, and ways of working, is the same one that is used for the design of the new platform, staff training and acceptance testing
• Customer impact is minimised during the conversion event.
Use a proven methodology to manage down risk.
Based on PA’s experience of working with clients to plan, manage and deliver successful platform conversions, the company has developed a proven and repeatable approach in the form of a conversion blueprint or ‘route-map’. The company’s experience demonstrates that programmes of this kind are always under extreme time and budget pressures – creating the temptation to cut corners and forget about defining the organisation’s ‘ways of working’. The
route-map enables clients to understand the full scope of programme activity, and visualise the interdependencies between the many business - and platform - related activities. It demonstrates, for example, the importance of not only understanding the organisation’s ‘way’s of working’ as a cornerstone for training, testing and the preparation of essential procedure
manuals, but also as the foundation for subsequent improvement activities that will support the cards business following cut-over.
It’s generally accepted that it is essential to maintain a ruthless control of scope, quality, cost and time and manage risks - and adhering throughout to these basic principles is important and
necessary.
Equally important, however, in the management of the programme, is the need to adopt an approach that delivers the right balance between firm central control and flexibility. A rigorous minute-by-minute command and control approach is, for example, needed for the conversion event itself but is inappropriate for managing the design and development of the programme.
At the heart of this approach is the recognition, gained through experience, that ‘one size does not fit all’ - explicit methodologies and controls are both the norm and entirely appropriate for key
technical IT aspects of the programme, whilst softer techniques need to be applied to managing the the business change aspects. Also, the structures and accountabilities for delivering the project must be regularly reassessed and fine tuned to suit the particular phases of the work.
Achieving all this requires a fully engaged and committed business.
The ability of the business to support and lead the conversion process is critical to success – despite the temptation at the outset to view the programme as a system dominated initiative.
Challenges to current ways of working will often need to be made. It is therefore vital that the ‘business-as-usual’ management team is deeply involved in the decision making and is responsible for delivery as they will have to live with the system in the long run.
In many instances the implications of design decisions will cut across functional boundaries and so active and participative sponsorship from the top is essential. An overall governance structure that balances business, IT, supplier and other interests, and that ties in the key stakeholder interests, is necessary to ensure that decisions, once fully accepted, are made to
stick.
Finally, it is important to ensure that any sense that the programme is taking place ‘behind closed doors’ is minimised. An open, collaborative approach to communication is needed that creates interest, informs and is seen as believable.
To conclude, delivery on time and to budget is an entirely realistic and achievable objective in converting portfolios to new platforms.
