Last year I wrote about the emerging new round of the CRM wars following IBM’s decision to replace its Siebel implementation with SugarCRM. In particular, the increasing ease of switching between CRM systems at the end of your subscription encourages customers to continually switch in order to get the best new features. However with the true value of CRM increasingly being the custom developments done to the system and its integration with other enterprise systems, is there a way to reconcile these conflicting realities?
There are good reasons for you to be cautious about your future with any given CRM system, in particular the amount of custom development you’ll need to undertake to make it work with your unique business logic, the next steps once you have completed your implementation project, and the changing needs of your salesforce.
During the sales process, CRM vendors have been known on occasion to highlight and overplay the features that work very well in their system, while downplaying the elements that are lacking or that will cause you headaches later on. A very typical scenario is for a vendor to target non-technical sales or marketing directors, convince them that with this system, everything you’ll ever need is available right out of the box and use them as an entry point to the organisation.
Of course, once the system is implemented (itself a lengthy and expensive project) it’ll turn out that some of this functionality isn’t really present and needs to be custom-coded, or can only be accessed by purchasing the vendor’s add-on modules that again add cost and further tie you in to their ecosystem. It may be commercially easy to switch CRM at the end of your subscription, but this becomes harder with every extra module that you’ll lose access to, and custom-coding your business logic into your CRM means you’ll lose that if you switch.
The answer is to imagine your enterprise systems as a series of layers. The bottom layer is your actual systems, and currently this is where the data is held and worked on. However, we can lay a workflow layer above that and abstract your users’ tasks into that layer, by treating them as processes that flow through multiple systems. This means that you can have all your processes defined and just plug in your enterprise systems like Lego bricks, and like Lego bricks you can easily switch out one system in favour of another, regardless of vendor or deployment type (such as legacy mainframe or cloud).
This is the true value of a process-based integration platform: rather than coding your business logic into the CRM layer where it will be lost when you move, you can build your logic into the integration layer. Not only does working in the integration layer provide you with the flexibility to easily switch CRM systems, it also reduces your reliance on a specific vendor’s ecosystem: if you move, you can choose to keep some of your existing add-on modules, by simply integrating them to the platform layer.
What next?
Considering your next steps following your CRM implementation will help you choose the best system for your organisation. While most CRM vendors today advertise the ease of integrating their system, this typically means either to other plug-ins in their ecosystem or to email, maps and social tools. The real value comes from being able to integrate your CRM with your key systems such as ERP, HR, warehouse management, e-ticketing, collaboration tools, Big Data analytics, legacy databases or BI tools. This allows information to be shared and followed between systems, for example allowing all staff working on an opportunity to immediately receive and input updates on the customer through a single, friendly social tool such as Salesforce Chatter, directly into back-end systems like SAP financials.
Depending on which workflows are most important to your organisation, this information sharing could equally happen between other systems, for instance an events booking company could benefit from being able to present information from the e-ticketing system and social media channels to customer service staff; while a logistics company might be able to offer more competitive delivery SLAs by presenting the full item delivery lifecycle and location history, (while coincidentally reducing their insurance premium by being better able to track losses).
This is the concept of the “enterprise portal” which I have written about before: take the CRM as a central system and integrate into it to provide a flexible, customised view of corporate data to all users, with benefits across the business that increase productivity, reduce expenses, increase revenues, improve customer satisfaction, and increase collaboration.
Given that this concept of building your CRM into an enterprise portal is a long-term investment in business logic, processes and workflows, you need to ensure that you do not get tied to a single CRM system when designing it. Of course, you also want to maximise your flexibility around ERP, email, HR and finance systems, warehouse management and anything else that you would want integrated into your users’ single source of information, but the CRM is the system you are most likely to consider switching at the moment.
Essentially, this involves considering information flows in your organisation like plumbing in your house: ‚pipes‘ of data that need to flow between systems and users, with each workflow or business process representing a pipe. In this metaphor the actual systems would be represented by the furniture that you use: taps, sinks, showers and so on, and just like these you want to be able to replace enterprise systems as required, knowing that you just need to connect the pipes and they will work.
A process-based integration platform is the ideal way to handle this because it allows you to build your entire business logic into the platform layer, where it will remain even if you switch out various systems. All you need to do is ensure the new system is configured how you want, correctly integrated to the platform and just switch the data connections (“pipe”) when you’re ready.
Going mobile
The next logical step when choosing a CRM system is how to take it mobile. There are three main options, of which two will work well (and which you should choose depends on your needs), but the third should be avoided.
Today, CRM vendors are offering mobile platforms that are tied to their products, and these are often high quality offerings: the new Salesforce1 mobile platform is excellent, and SugarCRM also offers a very good mobile dashboard. Using the “vanilla” version of these mobile platforms is perfectly ok; while you won’t get all the functionality of your enterprise portal your users will at least have access to a very good tool.
If you do want to keep your customised environment available on mobile, remember that this means you now have not one but two “enterprise portals”: the desktop one and the mobile one. This is why the worst option is to try to rebuild this by ad-hoc coding in the mobile platform: doing so means you will risk losing this logic if you switch systems. This means that all the hard work you put into building your business logic and integrating your systems has to be redone for mobile. Again, using a process-based integration platform allows you to reuse the business logic and workflows that you already built as the basis for your corporate mobile apps.
Ideally, keep the majority of your development work in your integration layer. Either take a ‚vanilla‘ mobile platform, or take a smart application development platform and use this to push out your workflows to mobile, with the added benefit that using a platform can allow you to build in security and management capabilities, develop more easily across mobile channels and take the users’ context into account.
David Akka is Managing Director at Magic Software Enterprises UK. Follow David Akka on Twitter: www.twitter.com/davidakka
