Considerations and Best Practices for CRM Implementation

Posted by Sambeet Patra under Customer Relationship Management (CRM), e-Business Software Solutions

Customer Relationship Management is commonly touted as an electronic business solution that brings people, process and technology together to provide seamless customer-related functions. Since CRM has been a proven strategy, companies, over the past few years have made substantial investments in deploying CRM solutions.

However it has been observed that more than half of these CRM implementations fail as the stakeholders of the deployment report negative ROIs. In this article, we provide best practices from our experience in planning  and deployment of CRM systems.

(A) Identify the Nature of Application

One of the primary but often ignored considerations for planning a CRM deployment is identifying the business scope. A CRM system can be looked at as an effective contact management tool, a platform for business process integration, a collaboration management solution providing easy to use features for communication and data handling. While it is nice to have a system that does all this, it is much more practical and economical to correctly categorize the proposed system. Although organizations have disparate requirements, a typical CRM deployment may be categorized as the followings:

CRM as a Contact Management Tool: The system is primarily conceived to maintain client and prospect information. This is typically used by Sales force to maintain list of contacts and the history of communication. The system may not provide complex business processes. However, the users want rich / easy to use interfaces and are likely to maintain huge amount of data. The system is expected to be used for bulk messaging / campaign activities.

CRM as a Collaboration Management System: In this scenario the CRM system is seen as a tool for internal / external communication. It is used as a one stop solution to track and manage customer communications and intra-organization activities involving customers. Users expect features like e-mail integration / information sharing / notification etc.

CRM as a Business Process Integration Platform: The system is expected to automate in house business processes for sales / service / order fulfillment / customer management etc. This is a solution that helps execute process flows across disparate groups in the organization. Such systems are seen as the backbone of the organization that uses it.

It is imperative that we identify the nature of the system before making decisions on the deployment.

• This impacts all the key decisions for planning, design and implementation of the CRM system.
• It helps identify the correct product in the market [if products are being evaluated]
• Provides guidance to the deployment team about management expectations.

(B) Product or Project?

Once the vision is identified, people tend to evaluate the options available in the market. There are CRM products available for all business sizes. These products may be distinguished in regards to hosting and may be grouped in two categories.

• Hosted solutions: Web / Web Service based solutions usually with a rich client layer. The data is hosted by 3rd party.
• Desktop / LAN based applications: Data / Software hosted by the organization itself.

In a happy-day scenario, we would probably find a product that meets the primary vision of the conceived CRM system. Unfortunately this will not be the case in most of the implementations. We need to consider the driving factors and their impacts on each option.

Cost considerations: The option of purchasing and deploying products has a predictable cost associated with it. The product prices are standardized and during the discovery phase it is usually easy to identify the deployment cost. For a custom development project, the management may not have good visibility for the cost involved. Developing custom applications require a detailed plan in place and the right group of resources needs to be identified to execute the project.  There are greater risks involved in regards to completing the project within schedule and within budgeted cost.

In the other hand, most of the leading CRM products available in market are highly extensible and provide framework for deployments to customize the functionality. While such capabilities are highly desirable, one needs to consider the overhead of the deployment cost associated. Decision makers are often misguided looking at the base cost of the products and they do not consider the cost associated with customization and support.

In summary, while products are generally preferred from a cost predictability standpoint, it is critical that we try to identify the customization, deployment and support cost.

Managing Change: A well planned implementation should be flexible enough to accommodate changes. A change may be related to a new business process,  change in the type of users intended for the application, change in functional requirement or a change in organization policies on software deployment. Most of these changes require the existing application to be modified.

Flexibility in accommodating changes plays a major role when deciding between product and custom development for the CRM deployment. Keep in mind that while it is almost impossible to predict the extent of changes, asking some of these questions to the involved business teams helps the deployment team gain valuable information

• How big and diverse is the user base?
• Has the sales process changed over the years?
• What kind of service / product do we provide to the customers? Which of these are tracked in CRM? Is there a well documented history behind these products / service offerings?
• What is the growth strategy for the company?

While products, by definition may seem to have an obvious disadvantage in accommodating changes, a closer look at the extensibility features provides a better understanding of the strengths of the product in consideration.

Integration Requirements: As discussed in the previous section, the CRM system may be conceived as a bridge between disparate business functions. In such situations, the ability for the solution to integrate seamlessly with other systems may be more critical than the ability to provide CRM specific features. Choosing a CRM product [especially a product that is designed as a standalone CRM application] may have limitations on integration capabilities.

(C) Focus on Business Process first…

Often, a CRM system is seen as an intelligent technology that defines and automates the Customer Relationship functions. During the initial discovery phase, people consider it as a one stop solution that can replace various stand alone legacy systems used by different groups in an organization. While there is no argument with the expectation, it is a better practice to consider the proposed CRM application as a system that merely “facilitates” the business processes. Once this expectation is set, the deployment team should focus on identifying “What exactly are the processes” in stead of jumping to “How we can implement the process”. To drive this argument further, let us consider the typical approach to understand and stabilize the business process

• Identify the subject matter experts who can explain the intended business process.
• Analyze and suggest changes to the process without considering the CRM system.
• Once the stake holders approve the suggestions, implement the process across groups without thinking about the CRM application yet. This way we ensure that all the business rules, roles, responsibilities have been adequately defined. This will greatly reduce the unknown issues and possible rework when actually implementing the solution.

(D) Manual Policies Vs System Rules

It is ideal to implement a CRM system that will completely automate the business process. There are issues achieving complete automation because

• Rules can change over time
• Management can change and new policies may be put in place. This affects the already implemented system.

So how do we design a system that can survive such changes? A simple approach is, “Not all rules need to be implemented in the system”. Keep in mind that CRM should “facilitate” processes and integration. The implementation team needs to identify the areas and policies that are likely to change over time and should make an attempt to implement these policies as working instructions for the users. The following example will clarify this:

The sales team often uses CRM to create and manage product offerings and customer quotes. Usually there are rules on pricing / discounting options for the product offerings. It is a common practice in the Sales department to change the rules around discount / pricing.

A short sighted implementation will translate all these rules in to the system implemented. This will then force the deployment team to make changes every time the sales department comes up with new policies.

A better approach is to explore the possibility to allow the sales team to adhere to these rules through proper working instructions. Further, to ensure the conformance to the rules, the team managers may be appointed to review the quotes before it goes out to customers. This way, the system is merely used to track and manage the work done whereas some of the dynamic rules can still be performed manually by the users.

(E) The Driving Committee

If you have managed a deployment project at the client’s location, you would have interacted with the management that gave you directions, discussed status and approved the work done for the project.

CRM projects are usually stakeholder-driven. It is their vision and interests that determine the course of the projects. But who are the stakeholders? People often interact with the senior management to understand the requirements. The senior management may have better visibility on high level goals such as revenue, but there are some obvious shortcomings if you deal only with senior management.

• Detailed requirements are not easily captured. The senior management may not be able to provide correct and accurate input when it comes to finer details.
• At the end of the project, when you are ready to formally obtain user acceptance, it is difficult to get Senior Management to accurately provide feedback.
• Project plan is likely to suffer as sometimes the deployment team needs timely advice and guidance from the Management.

You need some representation from end users. It is a much better practice to form a “driving committee” that comprises of various types of users. In a typical organization structure, you would look for the following people in the team that identify requirements, approve project plan, approve changes, etc:

• Representation from Senior Management
• Supervisors that manage team of users in support / implementation and other user groups using CRM. They create a bridge between management and end users and are the best people to provide detailed inputs / review work done.
• System Administrators as they will play a vital role in providing inputs on corporate strategy for software deployment / security / infrastructure.

(F) First Thing’s First

Often, CRM projects are driven with a top down approach. Management wants visibility through sales reports, revenue projection and sales forecast. They want to achieve this through the system being deployed. What they do not realize is that such analysis is done only if complete and qualified data is entered and maintained in the system. This approach then requires the low end users to put additional effort in entering all the data required. This results in lack of interest on the user’s part to adopt the new system. Also, users tend to get away with entering minimum possible data to get their job done.

An alternative approach is to understand the requirements of the management and at the same time pay attention to the low end users. During the initial phases, focus on building a system that is acceptable to the low end users. Once they adopt the system and realize the potential, you should make gradual attempts to build in additional features requested by the Management.

The success of a CRM system usually depends on the end users who access the system frequently. It is imperative that you gain their support and acceptance for a successful deployment.

(G) Iterative Approach

If you are planning to achieve all functionalities in a single iteration of the deployment, you are brewing recipe for disaster.

CRM deployment is a learning experience for all people involved. While the management may think that they have all the requirements in sight, they start discovering rules and patterns as things progress. As the representative of the deployment team, you need to help the business “learn and apply the learning”. Plan the deployment in small phases and make it a point to achieve few critical goals through every iteration. Obtain timely user feedbacks and do not be afraid of rework. Keep in mind that the business is used to identify the right approach only when they see something tangible. Instead of creating and reviewing huge requirements document, it is relatively simpler to keep adding functionalities gradually and make changes per user feedback.

Summary

There has been an increased focus on maximizing customer satisfaction. CRM is projected as the answer to issues concerning customer satisfaction. But improper implementation just adds to the already existing worries the organization has to deal with.

Detailed planning, setting long term visions and effective participation of end users will help ensure a successful deployment thereby achieving greater degree of customer satisfaction.

About the Author

The author is a seasoned Electronic Business Solutions architect at Silicus Technologies (An Offshore Software Development Company) and has lead several large scale software development projects for e-Commerce, CRM and Business Process Management solutions across multiple industries.