CUSTOMER

RELATION MANAGEMENT
SYSTEM

Submitted By:

Amit Gupta
Ankur De
Sachin Gupta
B.E.(Computer) Final Year
I.E.T.(DAVV) Indore
ABSTRACT

This paper has argued that whilst Customer Relationship Marketing is being
increasingly viewed as a major element of corporate strategy, there is confusion
about what it means in practice. Further, many organizations are adopting CRM
practices on a fragmented basis through a range of activities such as direct mail,
help desks, call centers and loyalty cards. These activities are often not properly
integrated.

Where CRM is well understood as a concept, many board-level managers are

still unclear as to how a particular CRM approach should be and what
technology options should be adopted.

The starting point for introducing or further developing CRM must be determined
from a strategic review of the organization’s current position. Companies need to
address four broad issues: what is our core business and how will this evolve in
the future; what form of CRM is appropriate for our business now and in the
future; what IT infrastructure do we have and what do we need to support the
future organization needs; and what vendors and partners do we need to
choose?

An organization should first examine its core business and consider how will it
evolve in the future. It then needs to consider the form of CRM that is
appropriate for their business now and in the future and what organization
resources does it have to support the business now and in the future.

Having identified the present and future focus of CRM, the organization then
needs to address the appropriate information architecture to enable their CRM
strategy to be implemented. Stated simply the task is how can we exploit
technology for improved CRM.

As organizations increase their sophistication they will need to creativity

integrate these technologies. "Planned evolution" is a good way of summarizing
the technology approach to building the backbone to support the relevant CRM
strategy that has been mapped out for the business.

An essential element of achieving successful implementation is to ensure that

their strategy is underpinned by viable and appropriate technology architecture.
This involves the selection of vendors and partners based on issues of
customization capability and other appropriate commercial factors including both
technological and commercial criteria.
CONTENTS

1. INTRODUCTION

2. TRADITIONAL APPROACH IS NO LONGER ENOUGH

3. ROLE OF DATA WAREHOUSING IN CRMS

4. PROCESS RE-ENGINEERING

5. CONCLUSION

6. BIBLIOGRAPHY

1. INTRODUCTION
Customer Relationship Management (CRM) is developing into a major element
of corporate strategy for many organisations. CRM, also known by other terms
such as relationship marketing and customer management, is concerned with
the creation, development and enhancement of individualized customer
relationships with carefully targeted customers and customer groups resulting in
maximizing their total customer life-time value.

Industry leaders are now addressing how to transform their approach to

customer management. Narrow functionally based traditional marketing is being
replaced by a new form of cross-functional marketing - CRM. The traditional
approach to marketing has been increasingly questioned in recent years. This
approach emphasized management of the key marketing mix elements such as
product, price, promotion and place within the functional context of the marketing
department.

The new CRM approach, whilst recognizing these key elements still need to be
addressed, reflects the need to create an integrated cross-functional focus on
marketing - one which emphasizes keeping as well as winning customers. Thus
the focus is shifting from customer acquisition to customer retention and
ensuring the appropriate amounts of time, money and managerial resources are
directed at both of these key tasks. The new CRM paradigm reflects a change
from traditional marketing to what is now being described as ‘customer
management’.

The adoption of CRM is being fuelled by recognition that long-term relationships

with customers are one of the most important assets of an organisation and that
information-enabled systems must be developed that will give them 'customer
ownership'. Successful customer ownership will create competitive advantage
and result in improved customer retention and profitability for the company.

This paper addresses: why traditional marketing is longer enough; the role of
information technology in CRM including understanding the economics of
customer acquisition and retention; developing appropriate metrics; and CRM
implementation issues.

The starting point for introducing or further developing CRM must be determined
from a strategic review of the organisation’s current position. Companies need to
address four broad issues: what is our core business and how will this evolve in
the future; what form of CRM is appropriate for our business now and in the
future; what IT infrastructure do we have and what do we need to support the
future organisation needs; and what vendors and partners do we need to
choose?

2. TRADITIONAL APPROACH IS NO LONGER ENOUGH

Many organisations, despite heavy investment in marketing departments and
marketing activities, have achieved poor results from their marketing effects;
quite a number of financial services companies fall into this category. We call
this "marketing trappings" marketing.

Relatively few organisations have adopted relationship marketing and CRM

approaches to effectively harness the tools of marketing to deliver real increased
customer value and, with the help of technology, developing appropriate long-
term relationships with customers.

To achieve success, businesses need to have the appropiate measurement

systems and marketing metrics in place to ensure their are effective in terms of
their use of customer-focused resources. Over the past two decades businesses
have developed sophisticated approaches to measurement in other functional
activities within their business - in Operations, Finance, IT and Human
Resources. However, the Marketing function may be the last bastion of
inadequate and inappropriate metrics. Lord Leaverhume is reputed to have said,
" Half the money I spend on advertising is wasted - the trouble is I never know
which half it is." This approach to marketing is not acceptable. Organisations
would not tolerate an HR manager who recruited two people due to lack of
knowledge of which one would work out; or an operations director who built two
plants because he was not sure which one would operate effectively!
3. ROLE OF DATA WAREHOUSING IN CRMS
3.1 INTRODUCTION
Data Warehouse systems 1 are established as a new middleware layer of
applications. Such a middleware layer is necessary because the direct,
individual access of Decision Support applications to data of operational,
transaction oriented applications has proved to be technically or economically
infeasible: Data quality problems and complex integration requirements usually
make it impossible to supply consistent, integrated data real-time to various
Decision Support applications. Even if technically feasible, the development and
maintenance of mn interfaces between m Decision Support applications and n
transactional applications cannot be economically useful. As an intermediate
systems layer, the Data Warehouse system is decoupling Decision Support
applications and operational applications, thereby reusing integration
mechanisms and derived data for various Decision Support applications and
allowing maintenance to be focussed on few, well-defined interfaces. The role of
the Data Warehouse system as middleware layer is illustrated by Figure 1.

3.2 APPLICATION ARCHITECTURE

Information Systems architecture should comprise specifications and

documentation of applications and their relationships with regard to all relevant
aspects (e.g. data flow, control flow, roles and responsibilities) as well as
appropriate construction rules.
In most cases, every functional area or business area maintains separate
customer data and product data. As a consequence, customers receive different
bills from different applications, have to report inquiries or address changes to
different contact points, and are bothered by marketing campaigns for products
that they already bought. From the viewpoint of the company, redundant data
create inefficiencies and inconsistencies, cross-selling potentials cannot be
exploited and customer knowledge is distributed over numerous applications. A
simple application architecture model represents applications as cubes along the
dimensions ‘function’, ‘product (group)’, and ‘process’. The dimension ‘function’
lines up the various functional areas of the corporation (e.g. order processing,
materials management, financials). The dimension ‘product (group)’ lines up the
various divisions or product groups of the corporation (e.g. loans, cash deposits,
custody). The dimension ‘process’ represents the course of business processes
(e.g. information request, negotiation, contract, fulfillment/clearing, archiving).
APPLICATION ARCHITECTURES :
 Figure 1 Figure
2

Figure 3 Figure 4

Figure 1 illustrates the positioning of most traditional operational applications in

such a three dimensional space. Most applications comprise modules that cover
all functional aspects of a (more or less) complete business process for a
specific product, product group, or division. Hence, the application architecture
comprises a relatively small number of components that can be designated
‘vertical’ applications due to their optical appearance in our model.

In Figure 2, a first important extension of’vertical’ application architecture is the

transfer of selected, cross product functions into dedicated applications. E.g.,
customer management should be transferred from vertical applications and
integrated into one single, cross product ‘partner management application’ to
avoid the problems of redundant customer data management and create
opportunities for cross-selling and customer bonus programs. Similar effects can
be created by transferring all configuration and pricing functions into a single,
cross-product ‘product management application’ or by transferring all reporting
functions into a single, cross product reporting application [6][8][14]. Al-though
the data managed by such cross-product applications are processed by all other
applications and thereby be- come ‘reference data’, they should be treated as
operational data. The extended application architecture
model resulting from the separation of cross-product applications is illustrated by
Figure 2.

In the application architecture model, channel-specific applications are

represented by cubes that comprise various products for selected functions and
for a certain portion of the underlying business processes. Due to their optical
appearance, channel-specific applications can be designated as ‘horizontal’
applications. The positioning of horizontal
applications in the application architecture model is illustrated by Figure 3. In
principle, the introduction of horizontal applications has no influence on the
positioning of Data Warehouse systems in the corporate application architecture:
Like vertical applications and cross-product applications, horizontal applications
are operational, transaction-oriented applications and, therefore, create
operational data. The same intermediate layer that transforms operational data
created by vertical applications and cross-product applications can be used to
transform data created by horizontal applications into input for Decision Support
applications.

The transformation of operational data into input for Decision Support

applications by a Data Warehouse system consumes a certain amount of time
and creates non-volatile, aggregate information. However, often there is a strong
demand to access integrated and consistent data from operational applications
in real-time. Both the Data Warehouse and the operational data store are
decoupling application layers, it was proposed that operational data stores
should be implemented as a part of the Data Warehouse system or that the Data
Warehouse system should be directly utilized for operational services like
Customer Relationship Management or e-Commerce
4. PROCESS RE-ENGINEERING
We use a four-level hierarchy of work defined as, “activities (represented on the
previous pictographs),” “processes,” “steps” and “tasks.” While most process
professionals use some variant of these four levels, nomenclature is all over the
lot. For example, what we describe as “steps” are called “tasks” by many. So, if
you’re working with team members having prior process management
involvement, be careful to agree on terms before you confuse the daylights out
of each other. Emphasizing Customer Value Versus Internal Efficiency: The very
same issue exists here as in redesigning workflow—we have a natural tendency
to put efficiency first, often forgetting about adding value to the customer.
Because process engineering defines “how” we do things rather than the “what
we do” that’s defined by workflow, it’s by nature more internally focused than the
latter—which requires us to pay even more attention to discrete work processes
and even individual process steps to make sure we’re not making “number one,”
the customer, number two in importance. Process re-engineering breaks down
into three (or four) discrete steps:

1. Identifying individual work processes defined by new workflow maps.

2. (Optional) Mapping current work processes.
3. Mapping new processes.
4. Review and approval.

Identifying Individual Work Processes: Each workflow activity you’ve mapped

may represent a discrete process. However, you may find you have to break up
a workflow activity into two or even more discrete processes. In the back office,
individual work processes should not exceed six to eight process steps. The
more variable nature of front office work requires raising that ceiling. But try to
max out at twelve to fifteen steps.

(Optional) Process Mapping Current Activities: For reasons we’ll describe in

the following section on mapping new activities, avoid mapping current work
processes if at all possible. The criteria for determining that you can skip this
step is being able to clearly see down to the process step level from top line
workflow mapping. Essentially, that means not losing sight of critical steps that
have to be incorporated into new processes.

Mapping New Activities: Work process mapping, the foundation of process-re-

engineering, is tiresome, tedious work to all but the most afflicted process junkie.
But it has to be done—because without mapping, new work processes lack
sufficient detail to define work in a way someone can follow. Process mapping
itself is relatively simple, as long as workflow has been defined first.

Review and Approval: How high a level of management has to approve work
process changes depends on the depth of the changes. Most changes can be
blessed by functional level managers already on your team, either as core
members or resource members. But even in these situations be careful to
present the full impact to all involved. Don’t do it a department at a time. CRM
encourages cross-functional cooperation, and many of the process changes
may involve handoffs of work and information among departments. It helps to
have everyone know what everyone else will be doing—and that change is
affecting more than their functional area. Getting Down to Brass Tacks: The old
saying “the devil is in the details” is rarely more true than in CRM
implementations. Until you drill down to the work process level, you haven’t
defined what people are going to do, which in many cases will be much different
than what they’ve done. Sadly, many CRM implementations wind up with people
trying to do new work the old way, which only produces the old outcomes. And
which almost totally negates the value of the fancy new CRM software
purchased. Defining Technology Requirements: Technology doesn’t work in a
vacuum. It supports what people do. And once you’ve figured out what people
are going to do, you’ll pretty much know what your CRM technology has to do.
And you’ll probably discover that required CRM software functionality is much
different than you first assumed it would be—and very different than what a
software salesperson or three in a hurry for a close told you it would be.

5. CONCLUSION

CRMS requires a very clear understanding of the system & the organized data-
flow between sub-systems of the organization. Therefore, for implementing
CRMS system integration forms the core issue. This system integration is
effectively brought about by data warehousing which is pivotal to the success
of CRM.
In organizations where various systems have not been integrated in the first
place will require re-engineering as well as data warehousing.

6. BIBLIOGRAPHY

a. Four Steps to CRM Success - Dick Lee

b. CRM Primer - David Sims
c. The current & future role of
Data Warehousing in CRM - Prof. Dr. Robert
Winter
d. www.CRM-forum.com
e. www.SAP.com