I was recently asked by a client about the difference between CRM and ERP solutions. In particular I was asked whether a particular custom solution we were trying to implement fell more neatly into a CRM or ERP framework. As the answer I provided quickly evolved into a brief history of CRM or XRM (according to yours truly), I decided to share in this post -
Generally CRM is considered to be “front office” and ERP is considered to be “back office”. And what you’ll find is that the definition of what is front office and what is back office will vary from company to company depending on their business model. You’ll similarly find that CRM and ERP products have areas of overlap where a particular function can be achieved in either system. Which system to do it will ultimately depend on where it makes sense to perform the hand off between front office and back office. If they’re both equal, then you’d typically look to the system that’s traditionally more geared towards handling the requirement. For example – take payments. Typically that’s geared to the back office because the minute you enter something like this, you’re entering a world of credit memos, taxes, recogition, collections etc. But there’ll be many cases where clients would need to handle such a requirement directly from within their CRM application.
Another good example – which is more to the point – is inventory or product management. That is more typically handled by the back office applications as inventory movement is inherently an accounting activity which ERP systems handle quite well. But again you’ll find that there are areas of overlap here too.
I think all the above though is somewhat beside the point. Because I think the XXX (Customer Requirement) that we are talking about is not a typical ERP function. In fact, I’d venture to say that it is neither an ERP function nor a CRM function.
So why are we looking at CRM for this? To answer that question you’ll have to go back to our first session where I presented it not as a "CRM" solution but rather as an "XRM" solution. CRM stands for Customer Relationship Management and grew out of the need to manage the selling process. As being able to sell is inherently linked to performance on the operations side, it was necessary for sales folk to have insight into the service delivery organization. Such as support and ticketing to understand how things were proceeding on that front (as information is power in terms of being able to anticipate and predict the customer’s overall level of satisfaction). And of course, marketing is just the flip side of sales i.e. one feeds the other and vice versa, so a CRM solution is not complete without a marketing module. This is why the classic definition of CRM is an application that covers sales, marketing and service.
But then as a CRM solution essentially became an application that deals with the “front office” as driven by the need to understand the customer’s or prospect’s overall experience, there were always going to be cases where in a particular business model, other types of information would be essential to this visibility. For example, a sales person going to a client meeting might need to be able to easily access information housed in a home grown application, medical records, or purchase history. As such – being a front office application – a CRM solution became something that needs to essentially be something that can model a business in whichever shape or form it takes i.e. CRM solutions needed to be flexible enough to be configured to model a particular business model.
At this point, a CRM solution is in effect doing a whole lot more than just Customer Relationship Management. Not only might the “customer” be a vendor, partner, reseller etc. (i.e. not the strict definition of “customer”), but also the platform became highly configurable such that it is more common than not to incorporate functionality that does not fit into even a loose definition of “customer relationship management”. Hence the term “XRM” was born which unofficially stands for “anything relationship management” attempting to reflect the fact that the platform is not just limited to “customer relationship management”. Of course even the “R” in XRM might neither be relevant based on the above description since we don’t need to necessarily even be dealing with a “relationship”. But as far as I know, from a naming standard convention, we haven’t yet evolved beyond “XRM”.
In contradistinction to the above, ERP solutions are typically (at least at this point in time) more standardized than CRM solutions. This is because the “back office” tends to be more standardized from business to business than the front office. To be sure, back office systems have deep and complex functionality but in my humble opinion (from a non-accountant) standard accounting practices have in principle not changed all that much since the double entry system was first invented (perhaps a little over-simplified) and therefore companies are more likely to be modifying their business practices to model the “best practice” of the ERP solution they are implementing than the other way round. Whether the last statement is true or not, I think you’ll definitely find that CRM solutions are much more flexible solutions than their older ERP counterpart due to the nature of the business problem they are trying to solve.
In summary, although I don’t think the XXX requirement is either a classic CRM or ERP type application, I do believe that it is a great candidate for the XRM model. And we definitely require the flexibility of the XRM platform in order to accommodate the requirements.
