New Perspectives on Delivering Retail Financial Services
This white paper examines implications of new management theory and IT trends on the organisation and systems architecture of retail financial institutions
Introduction
The retail financial services industry is once again going through a period of great change and uncertainty, and not just as a result of the recent financial crisis. Customers are increasingly fickle and demanding. Unprecedented advances in technology are changing the rules of the game. New entrants to the industry are picking off profitable niche businesses. Regulatory scrutiny and compliance requirements are more onerous than ever. A combination of cost pressures, merger activity and globalisation will probably evolve into massive consolidation across the industry as a whole. No wonder banks, insurance companies and other retail financial institutions are uneasy.
One symptom of this unease is a preoccupation with delivery. Most large institutions are wrestling with a problem variously articulated as "delivery strategy", "integrated delivery", or achieving "the right mix of channels". The most immediate cause of this increased interest in delivery is the proliferation of new delivery channels enabled by new technologies. Long ago, institutions only had to worry about the branch network. Now, branches have been joined by ATMs, telephone call centres, the Internet and mobile phones as increasingly popular access methods, which all add costs, and raise complex problems such as ensuring that customers can move seamlessly across channels. There is much debate about the best way of managing these channels. One view is that the whole concept of "delivery" is unhelpful; rather than thinking in terms of delivering supplier-defined products to a passive customer base, the emphasis should be much more on the customer and allowing the customer access to products and services defined by the market and tailored to individual needs.
But the delivery issue may be part of a wider structural problem regarding how best to organise a large, full service institution. Most strategy on this subject starts from a consideration of the three pillars of retail financial services – Products, Delivery and Markets. Traditionally, institutions were organised primarily by product and this has resulted in well documented problems, primarily stemming from the difficulty of maintaining an integrated, enterprise-wide view of the individual customer when that customer's data is spread across several account-based systems and processes. Many institutions have responded, quite rightly, by moving towards an organisation structured primarily by markets, and this works well at a high level for full service groups where the most natural top level structure is one of retail, corporate and investment banking divisions. But drilling down a level reveals other issues. Should the branch network belong to the retail or corporate bank? Should banking and insurance operations be merged into a single unit serving the retail customer? Should branch based and direct delivery operations be separated out into distinctly branded organisations appealing to different customer groups with distinct delivery preferences? Or should the emphasis be on maximising integrated access via all delivery channels? In every case, it seems that the advantages of organising according to one principle - market, product, or delivery - are offset by the disadvantages of lack of integrated management of the other two.
Related to these questions are a set of difficult IT issues. How to migrate from product based, mainframe "legacy" systems? How to build an integrated customer database? How best to support an increasing array of new, electronic delivery channels? Should systems development and/or operations be devolved to business units or centralised across the group? Should the whole thing be outsourced?
The difficulty which most institutions have in resolving these issues, the variety of solutions which have been attempted, and the frequency of disruptive corporate reorganisations, suggests that maybe we are asking the wrong questions, or at least using the wrong language. Maybe the time is ripe to examine these issues from a fresh perspective. This paper presents such a perspective. We argue that:
- A "virtual value chain", comprising Content, Infrastructure, and Context components, may be a better organising principle than the traditional Product, Delivery, Market framework.
- A new generation of IT, based on Objects, Thin Clients, and 3-Tier Client/Server Architectures, has emerged to support the value chain.
- Large financial institutions may be best organised into a set of value chains with distinct business propositions, and integrated across Content, Infrastructure and Context. The objective of "integrated delivery" is subservient to this principle and might just be missing the point.
A New Business Model – the Virtual Value Chain
The virtual value chain, developed by John Sviokla of the Harvard Business School, is a simple but remarkably useful model for better understanding information-based industries (see related white paper). Industries involving physical goods operate through the familiar physical value chain (raw materials, production, distribution, marketing and sales) in a physical market place . Information-based industries – and financial services is almost entirely information based – operate in a market space, through a virtual value chain comprising Content (what is offered?), Context (how is it offered?),and Infrastructure (what enables the transaction to occur?), illustrated thus:
- For a financial services operation, Content is the bread and butter of the business. It includes: services such as credit, or interest on savings, or advice; financial data such as account details; and, significantly, customer information. Successfully managing Content calls for qualities such as creativity, speed of development and, perhaps most importantly, trust . Most customers trust their financial institutions to act with probity, fairness and integrity and to maintain the security and privacy of their financial data. As we shall see, this reputation for trust is a tremendously valuable asset which can be leveraged to address other shortcomings.
- Infrastructure corresponds to the institution's computers and networks, its back office operations, and the bricks and mortar of headquarters buildings and branches. Managing infrastructure is all about maximising reliability and minimising cost. Once again, financial institutions are traditionally good at this aspect of the business.
- Context is a less familiar concept. Defined as the overall customer experience in any particular situation, Context combines elements of both Content and Infrastructure, embracing qualities such as levels of service and support, the look and feel of a particular interface, pricing, branding, and a host of other largely subjective qualities as experienced by a particular customer in a particular environment. Managing Context calls for obsessive attention to changing customer needs and behaviours, differentiation from competitors, and often working with partners to create a compelling packaged service offering. Most traditional retail financial institutions are poor at managing Context.
Content, Infrastructure and Context are superficially similar to Product, Delivery and Market respectively, but the concepts are broader and richer. Content includes not just the products themselves but also the information associated with these products and the customers who use them. Infrastructure includes not just delivery channels but the whole complex of information systems and processes which enable a transaction to be processed reliably and efficiently. By default, Context should equate to market, but clearly the concept is much richer than that, embracing not just a particular segment of consumers, but how individual consumers feel and behave in a variety of different circumstances.
By analysing a retail financial operation in terms of the virtual value chain, we may generate useful insights which are not otherwise immediately obvious.
- The first point is that financial institutions, to be successful, must manage all three components of the value chain, and that this calls for three quite distinct sets of skills. We have seen that whereas financial institutions are usually good at managing Content and Infrastructure, they are often poor at managing Context.
- But Context is arguably the most important part of the value chain since whoever controls the Context controls the relationship with the customer and this is the key to most retail businesses. Once upon a time financial institutions were very good at customer relationships, but for a variety of reasons - lack of attention to changing customer needs; overemphasis on cost cutting, economies of scale, and shareholder value; and insufficient attention to the core asset of trust - the relationship has been severely eroded.
- Several types of non-financial companies are very good at managing Context - supermarkets such as Tesco, strongly branded consumer companies such as Virgin (the financial industry as a whole is remarkably weakly branded), and perhaps most importantly a new breed of technology companies such as Google, Facebook, Apple and Amazon. Not surprisingly, all these types of company are successfully challenging the franchise of the traditional retail financial industry.
- This raises the familiar spectre of disintermediation – if customer loyalty migrates to skillful Context players, then financial institutions could be cut off from their customer base and reduced to the status of providers of commodity products, competing mainly on price.
- The power of the virtual value chain becomes especially apparent in the world of the Internet, Web 2.0, social media and mobile communications. Significantly, the companies currently dominating this space are mainly Context specialists. Companies such as Google, Facebook, Apple and Amazon own little Content or Infrastructure but through a combination of ingenious technology and attention to their customers (or "members") have managed to create unique and strongly branded Contexts in a remarkably short time. Such companies are increasingly turning their attention to financial services.
- A feature of the virtual value chain is that it can be relatively easily disaggregated into its component parts. Thus one strategy for financial institutions may be to specialise on one component. Many insurance companies are effectively Product specialists, relying on a network of brokers and agents to distribute their product. Companies like Visa and Mastercard are good examples of Infrastructure specialists. There are few examples of Context specialists – American Express is a possible example – but with a little imagination this is by no means an unworkable option.
- Another strategy may be to attempt to manage the whole of the value chain but to do so through strategic alliances. For example in the UK the Scottish banks have successfully partnered with supermarkets to address Context and an increasing number of institutions are outsourcing their IT and other Infrastructure components to specialist processing companies.
The various value chain strategies open to retail financial institutions are illustrated below:
So what implications does this analysis have for "delivery strategy" in the conventional sense? Well firstly, delivery is just one part of a wider issue of how to manage across the whole of the value chain. But secondly, there are two aspects to delivery: an Infrastructure aspect, and a more subtle Context aspect. We deal with the Infrastructure aspect next and return later to the question of how to manage Context. Specifically, we argue that the best long term strategy for the industry as a whole may be to regain control of Context by returning to its roots and creating a new set of customer propositions based on trust.
A New Technology Model - Objects, Thin Clients, and Middleware
Every component of the value chain is very much dependent on IT:
- Content is almost entirely in digital form – managing accounts and customer records would be unthinkable without vast computer systems.
- Computer systems and networks form by far the most important part of an institution's Infrastructure, especially delivery systems.
- And the Context within which the customer interacts with an institution is increasingly mediated by technology - this is obviously the case with newer delivery channels such as ATMs, call centres, PCs, and mobile phones, but even branch transactions are now dependent on sophisticated terminal systems to support tellers, linked to central computer systems by high speed networks.
How should all this technology be managed to support the virtual value chain? As we have already noted, managing IT is a severe challenge for most financial institutions, especially large, well established groups which have invested substantially in old fashioned, so-called "legacy" systems. Three problems are particularly vexing:
- Systems maintenance. Big legacy systems contain tens of millions of lines of computer code written in old computer languages such as Cobol. Maintaining these systems – simply keeping them going – consumes vast resources, leaving little effort free to develop new systems to support new business opportunities.
- Interoperability. Most users are locked in to proprietary products from IT suppliers which do not easily work with different products from other suppliers. There is a need for more "open" standards.
- Flexible integration. As IT becomes more pervasive, there is an increasing need to integrate systems serving different functions. But large, highly integrated systems tend to be difficult to change and expand. There is a need for a new, flexible type of systems architecture which can grow with the business and allow components to be swapped in and out as circumstances change.
Over a period of time, several developments in IT have converged to provide potential solutions to these problems:
- A new type of software based on "objects" promises to solve the systems maintenance problem. Objects are essentially packages of program and data which mirror real objects in the real world. For example we might have an object representing a generic customer and another object representing a balance enquiry transaction. The idea is that a company creates an enterprise-wide "object model" of its business and can then create new systems or modify old ones as the business changes by simply selecting the appropriate objects from a library and bolting them together using standard interfaces.
- Systems are becoming increasingly "open" through the adoption of standards which allow products from different suppliers to work with each other and to communicate across networks using standard protocols. The Internet and the Web are the most triumphant examples of this principle. Another example is the "thin client". "Client" is jargon for a PC or terminal used to access a computer system. A "thin client" is a simple, standard client, which downloads appropriate standard software and data from a larger computer known as a "server", only when it needs to do a particular task. Another term for this is "network-centric computing". Considering a typical bank with, say, 100,000 clients in the form of branch terminals and ATMs, the benefits of this approach are substantial. It is no longer necessary to physically visit each device every time the software needs to be updated, the devices themselves are cheaper, and hardware and software can be replaced with standard products from other suppliers without having to change the whole system.
- "Three-tier client server" architectures build on the simple client/server model by using a middle tier of servers to integrate very large, industry-strength transactional systems into a flexible, easily modifiable whole. At the heart of such systems is a new breed of software called "middleware" which glues the whole architecture together securely, reliably and efficiently, allowing objects to talk to objects and clients to talk to servers in the most appropriate way to serve the business.
The important point for our purposes is that this new technology model maps remarkably well on to the value chain model described earlier, as illustrated below:
An institution's Content, mainly data, is held on large, mainframe computers at a data centre. For many years to come, these will be old fashioned, legacy systems, but using object technology it is possible to hide the complexity and proprietary nature of these systems by encapsulating them within an "object wrapper" which presents a standard interface to the rest of the architecture.
Each Context – which might be based around a branch terminal, ATM, call centre terminal, kiosk, PC or mobile phone – is supported by a client, probably a thin client, which is responsible for presenting an easy to use, intuitive interface to the user (either a customer or an agent such as a teller or call centre operator).
The institution's Infrastructure is supported by the whole architecture and by an enterprise-wide object model. By using objects to represent common modules of business logic, and by using middleware to allow all parts of the system to communicate with each other, it is possible to build a highly integrated yet highly flexible system.
We can now see how delivery integration becomes much easier, at least at the Infrastructure level. Each delivery channel has a distinct Context (Tier 1), but shares common business processes and data with other channels. The sensible approach is therefore to create in the middle tier a generic set of standard objects for the common business processes, of which each distinct type of client uses a sub-set. The data in Tier 3 is even more integrated – a customer will need to access the same personal details and account data irrespective of which channel is used. Thus there is a gradation of integration across the value chain, with high integration of Content, loose integration of Context, and sharing of common elements of infrastructure, thus:
Let's say I use an ATM to transfer funds from my current to my savings account. The system accomplishes this transaction using common objects representing the two types of account and the processes of crediting and debiting those accounts. If I now enter the branch and ask the teller for the balance on my account, he/she uses another type of terminal to access the same shared objects, which interrogate the Tier 3 server database to find out my balance which has been updated in real time as part of the ATM transaction. Now imagine that in the future a new type of delivery channel emerges, say banking via TV. No problem - we simply create a new type of client which uses the same business logic and the same data as other delivery channels.
Of course we have presented a highly simplified account of a very complex subject and glossed over the many technical and management challenges which actually implementing such an architecture will involve. Nevertheless, this type of architecture really does work (at least on a small scale) and several major institutions are building just such a system. Over the next few years we are confident that more and more institutions will adopt this approach at that it will become the technology model of choice to support the value chain business model described earlier.
The last corporate reorganisation?
We mentioned earlier that large financial institutions seem to have enormous difficulty in deciding how best to organise themselves. Regular and radical corporate reorganisations rarely improve matters and often cause new problems, in addition to being disruptive and sapping morale. We have argued that managing the value chain is the key to successfully delivering financial services, and that a new generation of IT tools and techniques now exist to support the value chain. In this section we extend this argument to suggest that organising around the value chain is the only logical way to structure a financial institution – more precisely, that institutions should organise themselves into a set of distinct value chains defined by Context, and that any Group level coordination should be across the three dimensions of Content, Infrastructure and Context.
Over the last several years a consensus has gradually formed that large corporate Group centres are a bad thing. Research from, for example, the Ashridge Strategic Management Centre has demonstrated persuasively that conglomerates are usually worth more when they are broken up into discrete business units. This philosophy has spread into the financial industry with most large institutions devolving into a set of fairly autonomous business units which are only lightly controlled by a much leaner corporate centre. But on what basis should the business units be defined? Should the organising principle be market, product, delivery channel, or some other factor?
The answer is almost certainly that each business unit should have a distinct, coherent and realistic "theory of the business". To quote Peter Drucker, who coined the phrase:
"Every organisation, whether a business or not, has a theory of the business. Indeed, a valid theory that is clear, consistent, and focused is extraordinarily powerful. ………In fact, what underlies the current malaise of so many large and successful organisations worldwide is that their theory of the business no longer works."
What, then, should be the theory of a retail financial services business? Clearly, the theory must be driven by customers – all businesses exist to meet some customer's need. We have seen that a few large institutions can thrive around a theory of the business built on the Content or Infrastructure components of the value chain (where the customer is another business). But most retail financial institutions will wish to control the Context – the interface with the retail customer – and it is Context which most logically defines the theory of the business and is therefore the basis around which the institution should be organised.
Specifically, the argument is that successful retail financial businesses are driven by a compelling customer proposition defined by a specific group of consumers with a specific set of Context preferences. The best examples of businesses organised on this principle, from the UK banking and insurance sectors respectively, are First Direct and Direct Line. Both deliver a distinctive set of financial services to customers who are defined in terms of their preference for a particular Context – in this case the convenience, value for money and 24 hour availability afforded by the telephone. Both First Direct and Direct Line are highly successful and can truly be said to have redefined their respective industries. The fact that most well established institutions are in the process of building similar direct operations is proof of this. But few have had the nerve to allow their direct operations the degree of autonomy which may be necessary for success.
It is often claimed that financial institutions will only succeed if they operate as a full service one-stop-shop, since most customers expect a comprehensive range of products accessible via every conceivable delivery channel. Even if significant numbers of customers have such expectations – which is highly debatable – then our model still holds. Provided there is a valid theory of the business predicated on the needs of such customers, then there will be scope for an institution to successfully operate a set of tightly integrated value chains supporting a range of linked Contexts. Moreover the technology exists to support such a model, as we have seen. But the idea that most institutions must be organised in this way is rather dubious.
Instead, according to our argument, most retail institutions should be organised as a small set of fairly autonomous value chains, each with a distinct and valid customer proposition or theory of the business, and each focused on a compelling Context. Choosing the right Context, and managing the value chain appropriately, then becomes the challenge facing management, and a prime source of competitive advantage. It is beyond the scope of this paper to address this point in any depth but we can provide some pointers. Some Contexts will be familiar, such as: providing tailored private banking services to high net worth individuals in a highly personal environment; or delivering simple insurance products over the telephone; or execution-only stockbroking over the phone and by mail. But many other Contexts might form the basis for a new theory of the business, such as: delivering low priced but personalised financial services over the Internet to technoliterate individuals; doing the same thing via user friendly web TV for technophobes; acting as a trusted retailer of financial Content manufactured by other institutions; packaging financial with non-financial Content to meet the needs of particular communities; selling digital certificates or other security services to meet the needs of the increasing number of consumers seeking privacy and security. Many such propositions, we believe, will be based on the important idea of financial institutions as mediating trust.
The next question is what role should the corporate centre have in an organisation of devolved value chains? The answer is as little as possible, apart from choosing which businesses to include in the portfolio, and then acting as a centre of excellence with respect to the three dimensions of Content, Infrastructure and Context, thus:
Group functions labelled Content, Infrastructure and Context may seem a little unfamiliar but actually make quite a lot of sense. While each value chain will have its own Content, there may well be overlap, especially when the same customer is served by different value chains for different Contexts, in which case a single customer database is essential, which at a certain level should be managed centrally. A Group Infrastructure function is also understandable; although each business will largely be responsible for its own IT applications, the underlying IT architecture, including the enterprise-wide object model, will naturally be the responsibility of Group. A Group Context function is more difficult to envisage. Loosely analogous with Marketing, it will certainly be focused on the needs of customers and the continuous development of new products and services. More grandly, this function might be primarily responsible for identifying new business propositions and establishing new value chains to deliver them – defining the what of an institution rather than the how. Traditional Group functions, on the other hand, such as risk management, finance, personnel and so on, are all best managed primarily at the level of the underlying business units.
Finally, what of delivery strategy? In the limited sense of how best to integrate the infrastructures underlying related value chains, we have shown that a new generation of IT is now available which enables optimal sharing of common business logic and data between different delivery channels. But more important is the concept of managing a retail financial business as a value chain, and managing across a set of value chains via the dimensions of Content, Infrastructure and Context. Integrated delivery is a part of this challenge, but only a part, and as is so often the case, cannot be properly addressed without adopting a new, higher level perspective such as the one described here.