| |
|
| |
New Perspectives on Delivering Retail Financial
Services |
| |
|
| |
Introduction |
| |
The retail financial services industry
is going through a period of great change and uncertainty. 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.
A rash of mergers in the US will most probably evolve into massive
global consolidation across the industry as a whole. No wonder
banks, building societies and insurance companies 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,
PCs and the Internet 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. 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.
- Three types of non-financial companies are
very good at managing Context - supermarkets such as Tesco,
technology companies such as Microsoft, and strongly branded
consumer companies such as Virgin (the financial industry
as a whole is remarkably weakly branded). 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 and electronic
commerce. Significantly, the companies currently making
money out of e-commerce are mainly Context specialists.
Companies such as AOL, Amazon, CD-Now, Yahoo, and Cendant
(market capitalisation $35 billion) own no Content and no
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. A new term – "Portals"
– has been coined to describe these Context specialists
and they are currently the darlings of the US stock market.
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 and PCs, 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. The huge investment
currently devoted to fixing the "Year 2,000 problem"
is a case in point.
- 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 the last few years, a several
exciting 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 World Wide 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, or PC – 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 such
as Wells Fargo and Nomura 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.
Nick Collin, July 1998
|
| |
Interested? Please contact
Nick Collin on nick@ncollin.demon.co.uk
or +44 (0)207 833 8765 with comments or questions.
|
|
|