Regular readers of my blog will not be surprised to read that correctly configuring your CRM is critical to a successful implementation, but you may be surprised to learn just how different this process can be across different CRM systems. While one CRM systems is often seen as much the same as any other, these differences mean that selecting the one that works best for you can give your organisation a head start in its implementation and integration project.
The company I work for has a long experience of integrating many CRM systems including Salesforce, SugarCRM, Siebel, Dynamics, Peoplesoft and more. As such I have no agenda to push one system over another, but I do want to help CRM customers make decisions that help their businesses.
For the purposes of this blog, the key difference between CRM systems is the way in which configuration is achieved: either through customisation or pre-built modules. It’s worth stressing that neither route is necessarily “better”, as both have advantages and disadvantages, however one may well offer a significantly better fit to your organisation depending on the size of your support team and existing CRM experience.
CRM vendors will often say that their software can be used “out of the box” with very little configuration, but in the real world this rarely works quite as expected. Essentially, it’s true that the software “will work” without any modifications, but that doesn’t mean it will necessarily plug into your business with all its processes and people. This is why you often find that companies which decide to go for the “vanilla” CRM discover that staff have to jump through hoops in order to complete fairly simple processes: that functionality just isn’t available as standard.
It’s surprising that this isn’t more widely discussed, because the market for CRM software goes all the way from the world’s largest companies down to small organisations that need something more sophisticated than an Excel spreadsheet to keep track of their customers. Since this same software is sold across multiple industry sectors, it should be apparent that the standard software package is only ever going to be a core set of functionalities, probably the most frequently demanded.
This means that you are almost certainly going to need some degree of configuration, even before you integrate the CRM with other business systems. Your choice typically comes down to customisation of the software or deploying plug-in modules.
Customisation is endlessly flexible, involving modifying the CRM software to work exactly how you want. Remember the variety of CRM customers: large enterprises may have hundreds or thousands of individual CRM users working in different divisions or verticals, and these may have different needs or even need specific functionality for a particular project. Software customisation is one way of handling this requirement, and as large enterprises often have a large CRM support team (which may well include full-time resources who can customise the software) this can suit them very well.
The modular approach to CRM configuration is very different, as rather than customising the software, you use a plug-in module to add particular functionality to your CRM. Since the vendor, your in-house teams and third parties can all release modules, this is a good way of delivering functionality in a way that will work for many companies with a specific need. The modular approach is especially useful if you are a smaller CRM user without the constantly changing requirements or support team of a larger organisation, as the modules are simple to add to your CRM and don’t require much extra work.
It’s clear that using a CRM system “out of the box” is unlikely to be entirely successful, and depending on your organisation’s size and requirements a CRM that needs to be customised or one that is configured via modules may be more effective. However, in the current round of CRM wars the key is to avoid getting locked into any vendor’s ecosystem so that you can take advantage of emerging technologies and even special offers. Is configuration just another way of locking you in?
I’m not saying that this is the vendors’ intention, but from the customers’ perspective it could certainly seem like this, and that fear could discourage them from investing in CRM configuration and thus getting the most out of the system. It also raises an interesting question about licenses: today’s CRMs are sold on a SaaS basis, which we are told is cheaper than traditional software, but does the ongoing subscription, added to the configuration costs, actually mean that we pay more in the long term?
My advice is to factor this into your thinking, and place as much of your configuration as possible where it will continue to work for you even if you do switch CRM vendor. In short, use configuration as a way to get what you need, but avoid investing so much time and effort on it that you can’t get back if you move.
The key to this is to think beyond your CRM: the business processes CRM users are trying to complete typically stretch into other systems, and by using smart business platforms for integration and mobile apps you can switch out systems without affecting your users. Mapping out your business workflows and finding the integration touchpoints shows you what needs to remain consistent when you change systems. This way you can present actionable information from multiple systems to your users in a way that makes sense on whatever device they are using.
When designing processes, consider which ones actually need to sit at the core of the CRM, and which can sit elsewhere and be applied to the CRM (or any other system). What we are creating in most cases is a set of business rules, using a business rules engine in an integration platform and this can be re-used throughout the organisation.
For example, it is useful to have the quotation system (business rules) in the CRM, but the product management tree that sits behind this could be located elsewhere and the data presented in the CRM. If you use unique identifiers for each product, it’s quite simple to apply the rules engine of the quotation system to the product tree data. Likewise, discounting and authentication don’t need to sit in the CRM (the financial system may be a better place) and as long as the information can be presented in the CRM this doesn’t change the user experience; and once you have an authentication system for discounting you can easily reuse this authentication system elsewhere.
While configuring your CRM is very useful, be wary of getting locked in by using the CRM as a development platform: it’s far more flexible to have a development platform that works across not only all CRM systems but all enterprise systems, and treat your CRM as a module in that. Avoid being dragged inadvertently into a corner by your CRM vendor and their implementation partner: enter negotiations with your eyes open, ascertain the amount of configuration that will be needed.
Once you have determined that it will not be just a few days of consultancy time, bring in an integration expert and get their perspective on how you can make the CRM even more central to your business without getting locked in.
However, this does not mean that CRM configuration is no longer relevant. All the points above about customisation and modules still remain; a smart platform simply lets you take your CRM a step further. First, it lets your users work even more effectively than any configuration alone can, and second, it makes your entire CRM a module.
The post CRM: Death by configuration? appeared first on David Akka Blog.
