Management Blog and case study

Back

CRM – XRM, Back to the Future!

January 23rd 2013

BanNouNotProCTRL_EN-(1).png


During the past few years, I have had the opportunity to be invited to present the operational concepts behind CRMs (Customer Relationship Management), a conference during which I was asked to introduce the less familiar concept of XRMs (Extended Relationship Management).

It is very much intrigued that I had to answer basic questions relating to the operationalization of the tool instead of questions that focused, for example, on a vision, such as “What more could I do in the future with a CRM, what would be my next step?”.

Here are some conclusions based on these rewarding encounters, hoping that my remarks may be helpful within the framework of your current or future projects with CRMs/XRMs.

A Little History

The quest for business relationship management, as well as tools to support it, is not new. It is the extent and the importance of relationship management that has increased over time. Very briefly, here is the evolution of tools in this field in four key moments:

1980: The area of research known as CSCW (Computer Supported Cooperative Work) emerges simultaneously as the term "Groupware", associated more closely with the technology supporting the CSCW concepts.

1990: Structured commercial offers concretely take hold of the market with the promise to optimize communication in a work team. The "Lotus Notes" software is an ambassador from this period.

2000: The introduction of a clear CRM offer in the software world with the arrival, amongst others, of the now well-known company "Sales Force". The main goal expressed is to provide companies with a tool supporting the automation and optimization of the sales force. We see notions of the automation concepts of the sales force (SFA – Sales Force Automation) and the "360-degree" vision beginning to emerge, aimed at maximizing customer potential.

2007: The concept of the XRM platform appears. More commonly associated with a way of doing things rather than a specific technology, the main objective pursued becomes the automation and optimization of a company's business processes as a whole. New corporate performance perspectives are discovered and continue to be to this day.

We now live in an age where managing challenges and efficient exploitation of unstructured information are the optimal support strategy for our internal and external business relationships.

An Observation

It is no coincidence that the concepts of CSCW have first materialized in tools dedicated to the sales force. Sales are the sinews of war, as the saying goes. Naturally, it also goes to say that sales are primarily about relationship management. Therefore, it is not surprising that we have rapidly steered the communicational management possibilities of CRM tools toward this strategic component of any company.

Sales are also a fairly controlled management enclave, isolated, with a very clear objective. It is a human resources team relying on processes, a methodology, and a well-established marketing theory. I mean here that operational ambiguity is, in principle, less present.

I distinguish the “Marketing” component, where it is more a question of analysis, positioning, differentiation, and business strategy, and the “Sales Force” component that deploys the action plan in the field. In short, when you’re a part of a sales team, you must constantly remind yourself of the “Just do it!” mantra.

Therefore, concepts and tools in a controlled environment and yet, returning to my lectures, users express their will and their difficulties and reluctance to move forward with a CRM project even if it is limited to the sales team.

The fundamental reason is simple, and participants have expressed it very clearly. Obviously, each of them did so in their own way, in their own context, and according to the objectives, each of them pursuing their project. Even with a clear and precise marketing action plan, a sales force does not operate in a vacuum.

Some here will return to the concept of “360-degree vision”. If we limit ourselves only to the sales force, I say “not quite”. I say “okay”. However, if we talk about “Client” issues noticeable in all business interactions, regardless of the department, with its existing and potential customers.

In this latter approach, we can easily perceive the management complexity issued from interdepartmental momentum. Indeed, each department has its responsibilities and precise role, so, naturally, the respective visions of each department collide.

Here is an in-depth observation summarised by the participants regarding the difficulties they encounter in their current CRM project: the complexity of reaching interdepartmental consensus on a given method to achieve set objectives.

The Choice of Tool

Each CRM software abounds, and you, therefore, have a wide selection at your disposal. It is not the goal of this post to make a comparative analysis of the top products available on the market. For those interested, you can view a list of known CRMs online. Of course, remain cautious of the interpretation of rankings.

Beyond the usual functional characteristics, I suggest two in-depth validations if you plan to evolve towards an extended XRM platform gradually. Your CRM software should adhere to two principles:

1. A high customizability and information processing capacity based on your strategic challenges. You must be able to reconcile, analyze, and quickly exploit strategic information for each department.

2. A great configuration capability of access to information. I am not addressing the security aspect here, which must, of course, be present, but rather your technological tool’s capacity to modulate the access to information based on the operational needs of each department.

In other words, if you want to maximize the leverage of your configurations, make sure that each department can access the information it needs, but only the required information. Otherwise, you could reduce the operational focus of every department and instead generate a loss of productivity, obviously an effect to avoid.

Centralization of Information

When it comes to implementing a CRM, a majority of the failed attempts, or efforts attaining limited success, come from the difficulty to define centralized reference information. Of course, if you opt for a ''Cloud'' solution, there is no need to go any further as, de facto, you would typically operate in a centralized mode.

For those who currently have or would consider a local solution, remember that it is imperative to create a centralized informational reference. You must lose the reflex of accessing information locally (on a given workstation) for any information related to a client. Otherwise, your CRM project is in jeopardy from its first days of existence.

As minimal as this information may be at first, for example, customer contact information, to quickly generate a reflex to adhere to the centralized information is paramount.

This step will enable you, amongst others things, to raise and live the whole issue of standardization of the codification of crucial information. This standardization is strategic to stimulate ownership of the tool by its users and generate analysis leverage and decisional leverage after that. Consequently, if necessary, do not neglect the mobilization efforts of your team on the issue of centralization of information.

The Hidden Face of Success

Whether you wish to limit your CRM project to your sales team only or want to expand the use of your software to form an XRM platform, the whole question of the analysis of the management processes involved remains a critical issue.

As with any other computerized management project, implementing a CRM-XRM solution is a privileged moment to improve the efficiency of your existing processes without denaturing and losing sight of the methods that have created your success. With this in mind, you should never forget that rigorous project management is always your best ally.

Now, there is an additional aspect that I wish to bring to your attention at the deployment and operationalization stage of your CRM-XRM tool.

Based on the concept of CSCW, some fundamental operational principles must be respected and implemented to ensure the generation of the leverage you are seeking. Unfortunately, they are often forgotten or neglected.

Time-space-matrix-Johansen-1988

I will first refer to Johansen’s (1988) “Time-Space” matrix, a historical, theoretical reference for Groupware. This matrix shows the communications and interactions in a work team based on the possible combinations of two parameters, space and time.

I will not go into further detail about the underlying operational theory. For the theorist in you, I suggest an additional 2007 publication endorsed by Elsevier (http://www.elsevier.com/) and titled "A Classification Method for CSCW Systems".

The structural principle to grasp here is that a CRM-XRM tool acts as a management differential. Think of it instead as the role played by your car's differential when taking a curve and having to manage the rotation difference between the inner wheel and the outer wheel.

In fact, the key to CRM-XRM is that they manage the differences in availability, speed of execution, processes, etc., which represent challenges that a company's resources face daily throughout their internal and external interrelations. All deviations or operational desynchronizations to be managed here always being linked to notions of time and space.

To activate the magic of CRM-XRM's, I draw your attention to the simplified structure of an interrelation between two resources:

trigger-transmitter-doer.png


We are always in the presence of a “Trigger” who requests a “Doer”, a “Transmitter” who ensures that the request is forwarded to the right person at the right time (your CRM-XRM tool) and, finally, the “Doer” himself. Note the feedback loop that highlights the possibility of an iterative process if necessary to complete a task.

So that’s the mechanics based on the operational magic of CRM-XRM’s. Now, here are the fundamental principles that are frequently forgotten, unknown or neglected in the framework of the use of these tools according to each participant in the process:

The Trigger’s Responsibilities

1. He must make sure that the request is clear and precise. Otherwise, he automatically increases the processing and implementation time because the doer will automatically ask for specifications on the action to be taken. A widespread shortcoming related to the fact that the requester always feels that what he wrote, or dictated, is perfectly clear. It is indeed clear for him but not necessarily always so for the doer.

We well perceive here the importance of establishing codification standards for requests.

2. Send the request to the right doer, implying it is the right resource possessing the qualifications, skills and responsibilities to meet the demand. Otherwise, it is clear that processing delays will be introduced in the implementation times.

3. He must precisely indicate the processing priority that must be granted to his request. Remember here that when everything is urgent, the possibility to prioritize no longer exists; there is no effective emergency management anymore. What is implied here is to pay special attention to the definition of what constitutes an emergency as a prerequisite.

The Transmitter’s Responsibilities

The transmission medium is the management differential as such. The reliability and performance of the technological tool are critical parameters. Otherwise, the credibility of the system is automatically attacked.

The Doer’s Responsibilities

1. Immediately validate that he represents the necessary player to meet the demand in terms of his role and functions and his skills and knowledge. We quickly see here the effectiveness of a CRM to detect the possible continued training needs of a team.

2. Take an immediate decision concerning the request as to whether it must be fulfilled now or later. If the action can or should be postponed, its execution or follow-up must immediately be planned in the work schedule.

The greatest shortcoming encountered in the context of the implementation of CRM-XRM tools is the absence of a decision on a request. For there to be effective management of a situation, an informed decision must be taken and, since an informed decision is no mere coincidence, a minimum analysis process must therefore take place in the treatment of any given request.

Note that you must distinguish “taking a decision” from “meeting the demand”. These are two completely different things. A decision may be to do nothing now, but in this case, I repeat, a follow-up or intervention date must immediately be scheduled in the work calendar.

Therefore, the classic mistake is to leave requests pending without having subjected them to a minimal management assessment. In addition to not being in action, you accumulate potential problems in the future.
Take a few moments to think about this principle. It is the keystone for generating leverage with a CRM. Everything lies solely in this principle.

If each request received is not subject to an immediate minimal analysis, you do not manage, even if you think you do and think you are very busy!

Let us now take this principle the other way around to reveal the other classic problematic situation. As we can well imagine, if not leaving anything pending is the idea here, then we must satisfy all requests immediately

And so, a reactive management mode is now amplified by a tool that was initially dedicated to more accurate and efficient management.

Assuming we are operating at finite operational capacity, the informed decision process is greatly affected in responsive management mode if not inexistent. For example, we no longer ponder on which request requires priority treatment when facing two demands of equivalent priority.

As odd as it may seem, by wanting to do everything immediately, a work team can reduce its effectiveness simply because it does not do the right things at the right time.

3. Upon satisfying the demand, to respond adequately, the doer must make sure to document his actions with clarity and precision since he represents the last link in the process and, even more so, if he must return the summary of his intervention to the trigger.

Therefore, the doer is faced with the same responsibility as the trigger to produce clear and precise documentation.

Note that clarity and precision of the documentation, from both the trigger and the doer, is a safe investment to prepare the future leverage of your CRM-XRM tool. If you wish, this documentation can become the cornerstone of a potential corporate knowledge bank. The latter can then constitute the basis for the business rules supporting the automation process.

Conclusion

It is quite interesting to ascertain that the collaborative management software field once again highlights rules such as that a technological tool cannot correct a bad management process, a wrong way of doing things. As such, a CRM is a tool, not a solution.

Moreover, due to the usually larger number of users, collaborative software further amplifies management shortcomings more than any other type of software. The more effective the tool you will choose, the quicker you will get feedback on your operational deficiencies.

My recommendations made in this post are, in their essence, of course, focused on fieldwork. Unfortunately, it is often at the level of common basic principles that we find the most frequent errors. Therefore, there that CRM-XRM projects are jeopardized even before they took their momentum.

Once these basic principles are mastered, you will effortlessly move on to the subsequent stages, such as BI (Business Intelligence), to extract additional leverage from your CRM platform and progress towards an XRM platform.

Good management!

Back
Frequently Asked QuestionsContact MeGet In Touch With Us