October 26, 2010, 4:51 PM — At last month's CIO Forum in San Francisco, I led a round-table discussion about the strategic way to think about CRM applications and their evolution in the enterprise. While everyone agreed that the most comprehensive CRM systems were built (actually, assembled), not bought, one CIO took it a step further. What really matters in a CRM system isn't the system at all. It's the data.
And in an enterprise of any real scale, that data won't ever live in any one system. It will be held in various CRM, call center, support, and Web systems. Even if these were all from the same vendor, the instances would be operating and managed fairly independently. Even with SaaS products (where by definition everyone is running the same code line), the data models and semantics used in the separate instances tend to drift apart. So the data will tend to be siloed unless there's strong governance to prevent it.
To misquote James Carville, "it's the data, stupid." CRM features are important for users, but what matters to IT -- and the health of the business -- is the quality, validity, and usability of the data held in the customer-related systems. From this data-centric perspective, there are a range of new criteria of how CRM systems should be evaluated.
As I wrote in July, in large organizations a decentralized approach is often needed for CRM systems. To make that practical, however, data must be accessible and usable from several of the federated systems. This means that the following must be available from CRM systems via APIs, Web services, or RESTful calls:
• Data values and data state (e.g., locked, stale, valid)
• Metadata (at least the object model and field constraints)
• Basic read and update operations (creates and deletes will probably require special privileges)
Not all access will be done via low-level coding, of course. The number and robustness of commercial adaptors is an important CRM selection criterion. Low-end adaptor vendors focus on ease of setup and low cost, and they are increasingly delivering their adaptors as a SaaS offering. For straightforward random access to records, the low-end approach works out well -- but watch out for throughput surcharges that may be part of their SaaS pricing model. At the high end, the focus is on either throughput (for ETL/DW use) or transactional complexity (for two-phase commit, workflow, etc.), so vendors deliver either dedicated integration software or information appliances. For popular CRM systems, open source integration servers are quite viable, but they typically don't have connectors to down-rev CRM products or home-brew systems written in "old" languages.