I think XRM is awesome. And I also think it is dangerous. This post is about the dark side of XRM.
First of all, I think it’s not XRM itself which is dangerous. It’s how XRM is explained and sold to the clients – that’s what is making it dangerous.
We do like to repeat that mantra about the “out of the box CRM functionality which will cover 80% of what is needed”. We also like to conveniently forget the fact that the other 20% can cost a lot of efforts/time/money before the whole system is, finally, delivered. At least that’s how it works on the sales side.
That creates a couple of false expectations, though:
1. One may think that 80/20 also applies to the efforts. It’s not always true – more likely than not it’s going to be quite the opposite
2. One may think that 20% is not something to worry about. However, we are talking about XRM. Which means custom code. Which means we are talking about software development. However, how many clients will fail to realize that it is, actually, software development till it is a little too late? There will be plugins, but there will be no source codes. There will be javascript customizations, but they will be using unsupported features. There will be QA, UAT, and Production environments, but they will have different versions of the same plugin. There will be a black box system and no one will be able to explain why is it failing with a strange error, yet Microsoft support does not want to recognize that error as their fault.
It’s not all, however. There is another scenario which I find almost amusing. We don’t have to use plugins. We don’t have to use javascripts. We can just choose to create lots of custom entities.
Now, the problem is not that it’s unsupported, or complicated, or difficult to implement. The problem is that, with each custom entity we create, we are deviating further away from the out-of-the-box system which Microsoft keeps building, so, out of a sudden, we find ourselves not using a lot of CRM features since they have nothing to do with those custom entities.
What happens if we have 100 entities and only 10 of them are out-of-the-box entities? It’s very likely we will start having problems relating those entities to all the nice functionality Dynamics is offering: business processes, customer lookups, product catalogue.. pretty much everything starts falling apart since we are trying to squeeze a lot of custom data structures into the system. And, yet, surprisingly as it is, we can stay well within “80% out-of-the-box” rule since, technically, CRM gives us that option to create custom entities and to configure them. We do get relationships, we do get user interface, we do get workflows.. it’s just that we are not using any high-level abstractions like SLA-s, for example. Essentially, in this scenario we are using CRM in the same way MS Access used to be utilized.. to build a completely custom application. And, as a custom application framework, it covers 80% of our needs. Does it have anything to do with sales/marketing/service modules which are, actually, what CRM is for? Well, quite often those custom applications don’t care about that part of CRM, so the whole power behind those modules ends up being unutilized.
Does it all scare you? It does scare me, especially when I see projects where clients don’t realize those traps XRM has for them until it’s too late to change anything, and, so, I find myself on such projects constantly thinking: do we even know why we are using XRM here?
And yet, with all that said, I still think XRM is awesome! More on that in the next post.