At first glance, it may seem strange why such seemingly unrelated things are contrasted.
After all,
CRM is a customer relationship management system. It is widely known what it is, how it allows you to increase sales; what is worth waiting for from it, and what is not worth waiting for. Often the CRM system is not a separate system, but is included in the enterprise ERP system.
MDM is a master data management or regulatory reference system. It is considered that it is designed to centralize master data management, provides functional systems (CRM, ERP, WMS, TMS, etc.) with consistent and complete data, which are needed for reporting, business functions, etc. In other words, MDM performs a service provisioning function to collect, centrally store and distribute information about master data. But, in fact, this is only partly true.
')
In order not to go far for an example, I’ll give an example from the life of a company I am co-owner of (and it seems to me that this example is absolutely typical, and many of our partners and clients have encountered similar situations).
So, my company, engaging in the implementation of CRM and MDM systems from its customers, obviously had a need to somehow find, interest, and sell their products and services to them.
Initially, the company introduced an ERP system with a built-in CRM subsystem, in which information about contractors, their contact persons, sales opportunities, past and planned activities, etc. was maintained. The system also had BI capabilities.
Given that the work of sales managers was fully automated, however, there were problems because of which we could not say that we were managing customer relations correctly.
The point is this. In our ERP system (as well as the majority of ERP systems known to me), data on the company's clients were stored in the directory of counterparties, which are in fact not their company's clients, but their legal entities. If the client has several legal entities, then we have several entries in the counterparty directory. At the same time, all interactions, sales opportunities, contact persons, contractual relationships and all documents are tied specifically to counterparties (that is, to legal entities and contracts). Thus, the client as a management business entity that integrates all this data into itself was absent in the system.
The situation was similar with contact persons. The same person could be listed 10 times as a contact person for 10 legal entities, perhaps not even related to the same client. As a result, there was no connection between these 10 contact persons, and we simply could not imagine that in fact it was one and the same person. Needless to say, the contact information was also very controversial.
In addition, there was no large block of historical information necessary for understanding the client, which could not be transferred from the old systems due to the complete discrepancy between the structure and content of contractors and the nomenclature.
As a result, we often did not understand who our client was: what he did and what he does now, what he had and has a structure in the organization, who worked in him before and works now, what he was offered, where he was invited, and for what amount he bought from us, etc.
Without this information, we saw only a "part of the elephant" and could not properly establish relations with the client. Thus, we had to learn how to distinguish a client as a business entity and bind all data on a client to this business entity.
We considered various options, but the only possible solution to all the problems listed above was the implementation of the MDM system functionality in the Customer Data Integration (CDI) domain.
The reader will ask, why only? And why it was impossible to take in the implementation of the “tricked” Analytical CRM, where there is an opportunity to keep such “centralized” information on the client, and solve all the problems listed? I will answer.
Using MDM functionality to solve the problem of the Knowledge of Your Client has some significant advantages.
The main advantage of MDM is that usually CRM-systems do not have the normal means of working with customer data and the tools for normalizing this data. The data is collected from different systems, are scattered, they must be identified, standardized, enriched, deduplicated, synchronized, etc. In MDM systems, there are mechanisms for working with external databases (the Unified State Register of Companies, SPARK database), standardization mechanisms for addresses, full names, phones, and e-mails. Without these mechanisms, even the presence of the functional storage of these data in the CRM-system is absolutely useless.
Another significant advantage of MDM is that MDM systems allow for quite flexible customization of the structure for storing customer data. In each company, customer data that it considers important is very different. For example, in our company we keep data on all the software products of our customers, the types and terms of their support, even if they were purchased somewhere else. In addition, it is not enough to store this data, it is necessary to still version both the data itself and the structure of this data, since they change a lot over time.
Also, an undoubted advantage of MDM-systems is that MDM-systems can reveal explicit and implicit correspondences between individuals, between organizations, between individuals and organizations, as well as their changes. You can trace who, where, when and with whom he worked, who knows whom. It is also no secret that top managers of large organizations are visible to everyone and often change jobs. This information should be identified, recorded and create additional sales opportunities.
And the fourth, undoubtedly an important advantage, was the presence in MDM of built-in integration tools - ETL and ESB. These mechanisms are simply necessary to collect all customer information from different source systems. Especially in terms of the possibility of comparing data from other sources with data on customers.
Accordingly, using MDM for CDI, we solved the following tasks:1. In the shortest possible time, we were able to transform our scheme, where the central entity is the legal entity and the contract, into the scheme, where the central entity is the client. We have identified all clients, connected legal entities, contracts, contact persons, documents and all other information with them.
2. We were able to identify the "person" individuals, and associate them with customer contacts. Now we track the movement of not personal contact persons, but specific persons: where they work, where they go, etc. We can track implicit matches, who knows whom and who has ever worked with whom.
3. We were able to create flexible and complete repositories of additional information on customers and persons that are required for sale. In our case, this is information about projects and their parameters, information about the software used, etc.
4. We were able to aggregate data from various sources (for example, from the old system) and compare them with current data.
5. We have provided a mechanism for maintaining and maintaining customer data up to date.
In addition to all of the above, the introduction of MDM mechanisms has led us to look at the problem more comprehensively than when we implemented CRM. In fact, another project was initiated for this project to create a corporate data management policy (Data Governance). But you can write another great article about it.
Therefore, in our case, MDM is not a service and providing function for other systems, but a full-fledged system that carries its very specific business functionality for many departments:
1. The marketing department uses MDM data to build analytical reports. Now, in fact, in a single, all the data about customers: you can understand how many customers we have, what software products they use, which projects in which industries and regions have been implemented, what parameters these projects have, all income and expenditure indicators for clients and projects . It provides complete information for making strategic and tactical marketing decisions.
2. The telemarketing department (call center) uses MDM data to call and send letters. When the client was not singled out as a central entity, there were a lot of mistakes when they called the same client twice and three times (by the number of legal entities). In addition, there was no complete information (aggregated from different systems), which was required for customer segmentation and decision-making about inviting them to an event or offering them certain services. Now it is possible to send letters and ring up customers very accurately and addressfully (without repetitions and overlays), which significantly reduces customer dissatisfaction and saves our time.
3. Sales Department. The client manager from the sales department can now receive all the information on the client as a whole, which gives him more chances to offer the right product and competently build a sales strategy. In addition, there is now a separate monitoring and liaison with decision makers when they transfer to other companies.
4. Production departments can keep information about customers, their contacts and be aware of events. And also to form aggregated data on projects for further analysis.
Many IT colleagues ask me, and how can we justify the "business" of the need to implement MDM-system? After all, this is a technical support function. So - no, this is quite a specific functional business system, which in itself can bring a tremendous value added to many divisions.
And I want to make a reservation separately, for those who, perhaps, did not fully understand me:
1. I do not want to say that you need to implement MDM instead of CRM, I am writing about the role of MDM in building customer relationships and that this role is quite comparable with the role of CRM. It is clear that in our company, CRM functions perfectly, performing its functions.
2. Speaking about MDM as a business system, I do not mean that business users must work directly inside MDM (this, by the way, also happens, but not often), I mean that business users work with MDM functions and data. With us, for example, all user interfaces are implemented within ERP, so that the user is comfortable and does not need to switch between systems, but all functions and data are MDM care.
3. I write about my experience and the experience of many companies that have encountered such a task, and do not rule out that in nature there are situations in which this does not work.
Maxim Vlasov, Development Director