Back

StrategyJun 13, 2011

Understanding the Technology Aspect of Your CRM Implementation

Matt Allen

In a previous blog series, we discussed ways to evaluate whether your organization is ready for an enterprise-wide CRM.  Now that you have evaluated your organization and determined it is ready, you need to implement the solution.  Previous posts discussed the governance, change management, and business process work required for a successful implementation.  This two-part installment will provide thoughts around the technology aspect of the implementation.

Love the Data

At the heart of any technological solution is the data being processed.  In fact, one sure way to ruin an otherwise perfect solution is to neglect the data involved.  The organization can be culturally ready to go with processes defined and well-documented.  Without a comprehensive data strategy, all will be for naught.

The data in your solution must be available (i.e., able to be collected), accurate, and accessible (i.e., able to be consumed by users).  A solution that factors in such data is more credible (and useful!) to the users.  Your tool selection will determine how to do this best.  For example, several SaaS providers have add-on apps that serve as data cleansing tools.  Many have somewhat robust analytics engines to aid in user presentation.  Design your solution such that data entry is quick and easy to ensure user-adoption.  Build in tools for cleansing and augmenting the data, and develop processes around the purchase of third-party data sets to enhance or expand your existing data sets.  Define your end goals and needs around data analysis and reporting to ensure you can deliver what your users require.

Underpinning the above data discussion is the assumption that your organization will develop (or maybe you already have) a strategy for a future-state data model.  You should also develop a plan to get there.  It will take time.  There are legacy systems throughout the enterprise, each with its own data model.  There are interfaces that fire back and forth between those systems with custom maps to transform the data from model to model. Review all of this!  Is this where the organization is going?  Does this technology support your new customer-centric focus?  Plan for time to build out your data solution, and it may be best to do this in a phased manner.  Document each data element in each affected system to ensure that each system manipulates your data appropriately throughout the solution.  In the end, data must be defined the same throughout the organization.  By this, I don’t necessarily mean the data elements representing each data concept must be identical (an MDM could be used for that).   Instead, when an employee uses a word (e.g., prospect, etc.), he or she must mean the same thing as everyone else.  Bottom line – the metadata must be consistent.

Often overlooked in system implementations is the centrality of the data.  Do not fall into the trap of believing that the data is secondary.  It is of first-order importance!  Treat it so.