Sometimes MDM is simple, sometimes it just looks simple and seemingly arbitrary choices may have important consequences.
Today I would like to talk about the definition of the data grain of your MDM solution. Hopefully it will not be a boring as it sounds. 😊
So, I’ve challenged the collaborative wisdom of LI 2 months ago with the following question:
With 6 votes one cannot draw too many conclusions, but there is an interesting tendency – the Party repository is usually mostly represented by the “customer” data (in terms of volume), the clear source of the customer data is CRM, but it does not seem we have to go and blindly take this data.
I’m happy this one is clear. The CRM is not used in the processes which need crystal clear vision of the information about clients (yes, it’s mostly about contacts – if you know, you know). Let’s go even further, if we just talk about B2B, the data in the CRM does not need to reflect perfectly the structure of the organizations we’re working with (https://ithealth.io/whats-wrong-with-data-modelling/).
Let’s try to address the “it depends” vision (“I reject binary logic”).
What is meant here is that the company can freely choose the grain as soon as the data goes through some kind of data quality check process. Argh!
Why do companies want to put their CRM pyramid into MDM?
- From what I gather it is a way to say “all transactions for this client can be traced back to the account in our CRM system”.
- You ask “who gives”… and the answer is “our sales representatives should know, who sold how much… it’s a question of their salaries”.
- I.e. it’s just a way to « join » financial transactions to the efforts of the sales representatives.
- So, in order to simplify one process, we complexify all other processes.
- Now, when your « party » is not an « oragization » (but a cartesian product or « organization » x « sales strcucture), you cannot freely migrate the data into MDM, you have to ask “what region it represents” or even “which CRM account it should be linked to”.
Go and do it for the legacy systems.
- You cannot enforce any kind of “uniqueness” in any simple way. VAT/DUNS/EORI/LEI/whatever code should be unique? Forget it. Always multiply by a number of regions.
- You have to have a plan for the changes in the regional structure of your sales.
- You have to complexify your “credit limit” processes.
- You have to… Why?
- Now, when your « party » is not an « oragization » (but a cartesian product or « organization » x « sales strcucture), you cannot freely migrate the data into MDM, you have to ask “what region it represents” or even “which CRM account it should be linked to”.
Another solution is just to say “there are contracts”. My MDM data will follow the reality as well as it can and my FI system has to track the association between the transactions/payments and the contracts signed by different sales representatives. That’s all, folks.
Now you don’t need to re-create the same client with the same VAT code as many times as you have it in your CRM, don’t need to think that these records may be de-synchronized, etc…
And… a bonus… you can model the roles as you want to – you can have a customer, which is also your supplier, if you wish so.
I do not say that you cannot have an additional structure “around” your main party grain, do it if necessary:
TL;DR The moral here is very simple – MDM is a common ground. The common ground should reflect the “reality” as well as it can. In this case you have less problems and you streamline the processes.
Good health to you and to your data models.