Customer Relation Managment

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 longterm 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 :

2

Figure 1

Figure 3

Figure

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-reengineering, 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 dataflow 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. a. b. c.

BIBLIOGRAPHY Four Steps to CRM Success CRM Primer The current & future role of Data Warehousing in CRM

-

-

Dick Lee David Sims -

Prof. Dr. Robert

Winter d. www.CRM-forum.com e. www.SAP.com