Customer relationship management is one example of the over-hyped,
under-delivering software booms of the late 1990s. Danny Bradbury
investigates why so many integration projects to support CRM
systems went wrong, and unearths some sure-fire ways of knitting
your systems together.
Customer relationship management (CRM) has become a dirty word in
the IT sector. At the height of the dotcom boom, almost every
supplier had a CRM product, and all of them were promising huge
benefits to organisations which were willing to use these products
to gain a holistic view of their customer base. Three or four years
later, CRM has joined a growing pile of other once-popular
three-word concepts that failed to deliver, such as application
service provision and wireless application protocol.
There are many things that went wrong with CRM, but one of the most
common problems was a lack of integration at both a cultural level
and a technological one. Many consultancies selling CRM as a
business proposition in the late 1990s took an all-or-nothing
approach. Gaining a company-wide view of the customer called for
company-wide integration of your systems, went the philosophy. The
problem was that integration was much harder than people thought.
Even in 2002, when you would think that basic management theory
would have filtered through to even the most provincial of
organisations, one of the biggest problems with integrating systems
to support CRM is that companies still do not understand what they
need to integrate, says Chris Wakerley, managing consultant at CRM
consultancy Cobalt Technologies.
Taking the wholesale integration approach and tying everything
together at once is complex and expensive, and fails to deliver the
most value for businesses at an early stage, he explains. The early
return on investment is particularly important in today's economic
climate, making it more critical than ever for CRM implementers to
be selective in the data they integrate.
Nick Rhodes, principal consultant at Extraprise, another CRM
consultancy, recalls an energy customer with whom he was dealing.
The IT department knew the system configuration that it wanted, but
the company did not have a business roadmap against which to
validate the proposed system. "IT over the past 20 or 30 years has
been forced to take a disciplined approach to project management,
but I don't think that the front-end on the business side has that
discipline," Rhodes says.
In building a long-term business plan for IT, business managers
must ask themselves which elements of data are most important to
them when building a long-term relationship with the customer, says
Wakerley. Different things matter to different customers at
different times, and all of these data elements must be available
to call centre staff, who must also possess good customer-facing
skills.
In trying to bring the IT department in line with the needs of
business managers, companies need to base their business blueprint
- the document that sets out the short- and long-term goals for
creating a customer-centric view - on business processes, argues
Wakerley.
Understanding how a customer charts a path through the
organisation, which activities they are likely to take part in and
which teams they are likely to deal with in various logistical
areas will enable you to better define the data that you need to
integrate at an early stage.
At the same time, says Rhodes, it is important not to go too far
the other way; working to understand what the business needs will
help you to get your integration process right, but on the other
hand if you spend too long examining your data structure to try and
pluck low hanging fruit, you may find yourself stuck in analysis
paralysis. Structuring your analysis around business processes will
help you to become more focused.
Mathew Stewart, head of CRM strategy at Cap Gemini Ernst &
Young, says that deciding which data elements to integrate is only
a small part of the battle. Different people within your
organisation will own different sets of data residing on disparate
systems.
This raises both technical and political questions that need
answering before a project can be completed. For example, should
two different systems be rolled into a single one? If not, then one
system will have to be the master with the most up-to-date records,
and the other the slave that reads from the master's file. Are the
owners of both systems prepared to accept the decision, and if they
are, do they understand the technical challenge involved in
carrying it through?
"If you're putting in a champion system for CRM, you can make a
strong case for holding the customer file in that system," says
Stewart. "But then you may get three-quarters of the way down, and
find that the legacy people can't handle passing off the ownership
of that data," often because they haven't understood the
implications on their own systems.
Things become even more complicated when politics and technology
mix. Stuart explains that often, technically capable people will be
unable to agree about the interfaces that they should implement for
political reasons. For example, a call centre manager may be
unhappy at a request from another business unit to conduct
validation checks on data produced by his department if this
validation increases the length of the average call.
It is for these reasons that it is important to secure the buy-in
of senior management in any integration project. This is especially
true for an integration project supporting a CRM system because the
latter is so business focused. "Sometimes you need to get to the
chief executive to understand his priorities: is it cheap, low-cost
services; premium, quality service; better company information or
better cross-selling? If you try to take these decisions in a
vacuum, that's not going to get you the best system," warns
Stewart.
Unfortunately, IT departments wanting to integrate systems to
support a CRM project are stuck in a catch-22 situation, because
getting senior management buy-in relies heavily on quick results.
This is another reason to take baby steps with your CRM project,
adopting modest integration goals to start with and building up to
a grander project later by garnering management support through
early successes.
At the same time, it is still important to maintain your long-term
vision, says Jonathan Radcliffe, an analyst at Gartner Research.
Failure to maintain a wider view can affect your long-term
integration strategy, creating a loosely coupled CRM project with
isolated silos of information.
If you're planning to focus heavily on analytical CRM where data
will be mined extensively, you should pull all of the necessary
data into a single warehouse that can be used to feed the CRM
system, says Ian Dunsire, managing director of Atos KPMG
Consulting. You must have such a view of your data to understand
the business from a customer perspective, he explains.
There are some processes that you will have to go through to build
such a datawarehouse. Renovating a house properly requires a
thorough overhaul of its basic infrastructure, checking everything
from wiring to plumbing. Without this, anything that you build on
top of it will be vulnerable to failure. Similarly, data modelling
is a vital part of any integration process.
It is important that you use physical data models that map the
various elements of your data to physical resources and entity
relationship diagrams that help you to visualise your data
structure logically and match it to business processes.
Unfortunately, it is a time-consuming and expensive undertaking,
which won't deliver any immediate return on investment, making it
invisible to the board.
On the other hand, modelling your data gives you a good opportunity
to identify those data elements that are dispensable, and which
pose a drain on the organisation. Eliminating them - effectively
spring-cleaning your data structure - will ease the integration
task ahead, especially if your fledgling CRM project gets off the
ground and develops into something grand. It also means you can
assess your data quality, and do something about it if it isn't up
to par.
Dunsire says he has known banks that have tried to merge databases
and ended up sending mailouts to customers containing the wrong
data. Nothing is likely to destroy your customer relationships
faster than that, so this is a critical issue. "Data cleansing
needs to be done on a regular basis, but the big problem is to go
right back to the source of that data," he warns. "You need proper
rules in place, so that you understand that when you catch a piece
of data, you go to a master customer file and then change that
file."
Astute readers may notice a conflict between the idea of a
datawarehouse - generally perceived as a huge bucket of data in
which the value comes from the sheer scope of the data covered -
and the "gently does it" approach advocated earlier, in which
integration happens on a piecemeal basis. Dunsire argues that the
two are not mutually exclusive.
When he worked at the TSB bank, he explains that the company
decided to build a static datawarehouse with basic demographic data
first, to prove its worth. This gave the company useful information
about the way that the customer base split down. When the bank felt
ready to start storing dynamic data in the warehouse, documenting
every contact that the customer had with the bank, it became 10
times more powerful. But it learned to walk before it broke into a
run.
Jennifer Kirby, analyst at Gartner Research, argues that for
integration to truly succeed, it should happen at a cultural level
as well as a technological one. She explains that some companies
she is working with are now experimenting with fluid teams, where
people with different competencies come together to service the
customer in different areas.
This move away from a purely product-centric view of a company, to
one in which teams try to see things from a customer perspective
stretching across different product areas, supports a
customer-centric view which should always have been a central tenet
of any CRM project.
In the post-dotcom fall-out, many product categories and industry
sectors will die out altogether, or least be severely pruned back.
Others, which had a basically good philosophy but which suffered
from a lack of good implementation, may well survive. CRM is likely
to fall into the latter category, but some of the companies that
have tried to implement it and some of the suppliers that have been
selling it need to adopt a more mature approach to supporting the
integration process at a cultural and a technical level.
Ten tips for integrating business processes
- Talk to your business managers and make sure that you have a
clear understanding of your integration goals as part of the
business blueprint
- Use data modelling techniques to understand where your data is
located, and who is using it
- Take baby steps - don't try and solve all your company's
customer relationship management problems at once. Pick specific
business processes that can be integrated relatively easily for a
high return
- Don't make the mistake of isolating these small steps too much.
You want them to form a cohesive whole further down the line
- Make sure that your CRM system is supported by business
processes that stretch throughout the organisation. CRM is no good
if it is not supported by logistics, for example
- Be aware of internal politics between different business units
that may hinder your integration process
- Let the business requirements guide your choice of integration
tool, rather than the other way around
- Try to find a balance between meeting the needs of the business
and falling into the analysis paralysis trap, where you spend all
your time evaluating integration requirements and never get around
to implementation
- Support the technical integration underlying your business
processes with a cultural one, tailoring your business so that it
can support a customer-centric view, rather than simply a
product-centric one
- Make sure that you get senior management support before you
begin your integration project.