Extensive academic research shows that the majority of mergers fail to increase shareholder value, often because the integration of acquired business units takes longer than anyone planned. So the ability to effectively integrate the information systems of merged business units is a key success factor for any acquirer. Even though there are a lot of corporate integration consultants, the execution of their strategic plans seems to go awry... particularly when it comes to CRM systems.
If you've been following these articles or read my book, you know some of the reasons why:
- CRM systems are different. Unlike most Enterprise software, they cannot work without happy and participative users.
- The metric of success for a CRM system is its credibility: how often management actually makes decisions based on its data. It matters less how many people are using the system than how representative the CRM system is of the state of business relationships and transactions.
- CRM systems are more vulnerable to data quality problems than are other types of enterprise software. In most companies, most CRM data is typed in (directly or indirectly through integration points) manually. Beyond simple data quality, the big headache of merging CRM systems is getting the data to mean something.
- The more advanced your CRM system is, the more likely it is to be integrated to a large number of internal and external systems. Unless you've used a comprehensive integration broker, SOA, or ESB, extricating a CRM system involves a lot of technical risk.
OK fine. So what are you supposed to do? Here are the basic alternatives.
Keep both CRM systems indefinitely
Since CRM systems tend to have a relatively short life (5 years isn't unusual), "indefinitely" here may mean "until the next system transition," which may be 18 months away.
Keeping both systems alive indefinitely makes sense if the CRM systems are really serving different masters. Look at your corporate org chart: is each CRM system focused on a different chain of command? Next, examine your supply chain and demand channels. If the acquired business unit is a separate product line, selling to a different customer base, or working with a different channel or sales model, there's less intrinsic advantage to integrating the CRM systems.
Finally, look at the feature set of the two systems. Are they really comparable? Do they support very similar business processes? Is one of them antique and the other Web 3.0? If the users think that the two systems are night and day, the system transition will be tougher.
Of course, if both the CRM systems are the same brand and version, this decision to consolidate seems a no-brainer. Not so fast: if the systems have been heavily customised or have large and disjoint data sets, running in parallel-play mode really is the safe bet.
If you decide to follow this path, develop a short-term integration plan (at the API/service level) and a report-consolidation approach for senior executives. Be very wary of differences in semantics (e.g., "what does it mean to be at pipeline stage 3?") across the systems, and be willing to invest in a small data warehouse to get meaningful corporate reports out of the parallel systems.
Dump one system immediately
This strategy makes the most sense if the acquired company is going to be fully merged into the existing sales and marketing organisation. If the answers to the "separate business unit" questions discussed above are "no," there is little justification for keeping two CRM systems alive.
As most of the CRM system users typically work in sales or marketing, the word "immediately" means "starting this quarter and showing serious results by the end of next quarter." This can be a tall order, so manage expectations accordingly.
A classic temptation is to have the acquiring company's CRM system be the default survivor. All too often, this is not a good plan. Don't be seduced by a sexy user interface: focus on which system has the most credibility and the best flexibility to accommodate requirements.
System conversions and data migrations are tough, and typically involve a "slash cutover." But that doesn't mean everything can be done in one pass. If you've got the right people, Agile sprints are the way to make sure that each level of the object model, data set, and system functions is built out on a solid, tested base.
Do something different
This is the path that says "both systems are wrong, we need to use this merger as a forcing function to make a change we need anyway." While politically powerful, this path can involve exorbitant levels of risk, particularly if the deadlines are non-negotiable.
Moving both your CRM systems to a new one will require significant analysis and planning, with really tight project management. Be particularly wary of "clean slate" thinking that can lead to scope creep and the political baggage of proposals for policy or business process changes.
The "all new" approach will require a thorough plan (it's really two system migrations) and a very strong project management function. It is critical to avoid irrevocable decisions, as there will be unforeseen requirements and ramifications. As you execute the plan, we recommend very frequent milestones and management reviews. Again, if you have the personnel for it these conversions are best done with Agile techniques.