Considering CRM Consolidation Amid Corporate Merger Mania

Let’s face it: Wall Street rewards corporate combinations nearly as much as it does corporate divestitures and spinoffs. When companies merge and reorganize, it doesn’t take long before you hear the call for consolidating CRM systems. Indeed, we’ve come across several Fortune 100 companies with more than 100 separate CRM instances. We know of one with more than 500. You can bet they have task forces trying to figure out the system consolidation strategy.

You’d have to have flunked out of IT school if you couldn’t make a dozen arguments to support consolidating systems. Many of those arguments lose some of their heft in cloud systems, though, and many others focus on infrastructure services rather than highly customized applications.

[ How-to: 9 Ways to Improve Your Company’s CRM System ]

• In cloud systems, consolidation probably won’t save any license or support fees. Typically, cloud vendors charge per user, not per instance. Since user licenses are typically transferrable across instances, consolidation provides no magical reduction of license fees.
• Consolidating cloud applications typically won’t result in dramatic savings in system administration, either. Salesforce, Redhat and others have tools explicitly to make multi-instance administration an easier routine. In fact, it’s sometimes more complicated to administer one comprehensive system than a bunch of little ones, leading to reverse scalability (particularly if there’s politics or differing security needs among user teams).
• For user onboarding or training, the same argument applies. The ifs, ands and buts of a large comprehensive system usually make things harder for the user to learn and remember than a smaller, more tailored one.

If the cost containment argument isn’t a slam-dunk, what are the situational specifics we need to look for in advocating cloud app consolidation?

• Are user teams and their business processes ready for integration? You can merge systems much faster than some users will change their behavior, so starting a CRM merger too early can backfire. When working with sales teams, don’t underestimate the power of politics.
• Are the CRM systems the same brand? If not, the complexity of the system merge is compounded by a system and data conversion.
• Are the CRM systems the same basic release level? In the case of cloud CRM, you don’t need to ask this question. For on-premises software, the difference between versions’ data models and platform functionality can make consolidating systems a lot harder. Frequently, there’s a good reason why the version upgrade hasn’t happened yet. Better to avoid all that and get the systems on the same version before you start trying to consolidate them.
• Are there fundamental contradictions among the user groups regarding business model or business rules? For example, is one group’s competitor another group’s customer? Is one group using exclusively geographic territories and another using a named account model? Is one group using sales or service channel partners, and the other going all-direct? Is one group basically B2C and the other pure B2B? All of these contradictions can be accommodated in a single, large system, but it’s harder to build, evolve and maintain these business necessities in a single, large instance than in two or more specialized ones.
• Do different groups have different brands of marketing automation, configurator/quoting, ecommerce, billing, distribution or ERP systems that integrate with their CRM systems? Some of these integrations can collide in a unified system, causing painful choices or even forcing a vendor change for those auxiliary systems.
• Do different teams have different CRM security and access control needs? Life is easy if “everyone can edit everything” but can be really tough if some users shouldn’t even see other users’ information under some conditions. This issue alone will increase the size of the system consolidation project and make the system administrator’s job tougher every single quarter after the system goes live.
• Does one group have a territorial or political need to be “in charge” of the system? With one big system, there can only be one big Kahuna. If there are multiple control freaks, leaving each of them in charge of a smaller system can help avoid a bunch of political headaches.
• Does one group have an inherent need to change quickly, while other groups are highly resistant to change? This difference will cause both sets of managers no end of irritation as time goes on. Same goes for business units that are highly regulated or need to go through process audits on a regular basis.

Anti-Unification? Communication, Workflows Matter Even More

If all this points you away from consolidation, what’s the alternative? The first order of business is to give users extra visibility into records outside of their CRM instance. Typically, this is just reports or read-only views, and the answer is either a data mart or some clever query writing. If you can keep the use cases for this cross-system visibility fairly narrow, costs can be pretty well contained.

[ Related: Why the Last Mile of CRM Implementation Is the Hardest ]

The second functional requirement is often for alerts or reports to keep one user group apprised of relevant actions taken by another group. While there are a hundred variants of this requirement, most of them are overstated (and thus over-engineered as cross-system workflows or two-phase commit transactions). Look for ways to use email, the ubiquitous simple tech, as the alerting mechanism across your organization. You can go surprisingly far with workflows and some JavaScript.

Things get more interesting when there’s a functional requirement for transactions that span systems, particularly for use cases surrounding order entry and support cases. Thanks to the miracle of external keys, iFrames, JavaScript remoting and jQuery, a fairly usable cross-system window can be built pretty quickly.

To make all this happen across multiple systems, you need to develop common system administration practices, development tools, documentation (gasp!) and at least a weak form of customer master. There are tools to help with all of this, but the first order of business is a common set of management principles and incentives that will make the multiple systems work over time as an effective federation. Too much laissez-faire and you’ll see those multiple systems collapse into cacophony and confusion.