Establishing Guard Rails for Your CRM Strategy When Centralization Isn’t an Option
At Heller we frequently work with organizations that are in developmental stages of a larger CRM Strategy. For many organizations, our first recommendations are around centralization. Consolidating to as few systems as functionally possible is often the most direct path to reducing data silos, resolving integration problems, and aligning business processes through a shared system.
But, from time-to-time we find an organization that is unable to consolidate to a central hub. A compelling reason for parallel systems might be an affiliate organization with a disproportionately large chapter that can’t be easily brought into the single system. Or, as a CRM-strategy requires bringing together both operational (supporter) management and program (client) management, the wide variety of business processes may not be able to be accommodated in one software package. Instead, multiple integrated point-solutions may be necessary to meet all the functional needs.
When confronted with a scenario where a parallel, integrated architecture is the likely outcome, we often shift the conversation to establishing parameters that will enable integration, prevent data model drift, and ultimately enable a CRM Strategy – if not a singular CRM System. We refer to these parameters as “guard rails.” We have provided a few topics for consideration below:
Common understanding of the security model
Ultimately, integration of systems will likely occur as part of a CRM Strategy. Part of that strategy should define who has access to what data in each system. When data is integrated between systems, data becomes available to new users – users not accounted for in the original security design. The security model in both systems may need to change to accommodate these new circumstances. We recommend that the organization create organization-wide security guidelines to provide direction for these system-specific decisions. For some organizations, this guideline might as simple as “open by default.” In such a case all information can be seen by all users by default, and access is only restricted in special circumstances. Even the most open organization will collect certain information that must never be shared, however – non-disclosure agreements, personal information covered by HIPAA, sensitive meeting notes – and these information types should be specifically called out as exceptions to the default.
Consolidation to ‘as few as functionally possible’ and definition of what that means
In general, if there is redundancy in terms of features (or near compatibility), building on the same platform most often should be the first consideration. Consolidation will typically reduce architecture complexity as it will result in fewer external system requiring integration. If there is a clear feature set that must be met by an alternate software provider this might exceed what is “functionally possible” for a single system. Many organizations create a central vetting office either under IT or as part of a Project Management Office (PMO) that can objectively assess when parallel-integrated is the better option to build-upon the central platform.
Integration potential as a key qualifying criteria for new systems joining the architecture
When the decision has been made to bring in a new system to the architecture, that system’s integration potential should be weighed heavily in order to best bring the new system and data into the organization whole. Legacy systems with low-integration-potential should be targeted for phase-out or consolidation.
Shared design model
There’s a set of foundational considerations that can be recognized as new systems are brought online or feature-set is expanded. A tightly integrated system might validate critical data points right down to the field level (ex. a critical attribute used for segmentation that crosses multiple channels). A more generally integrated architecture might just share concepts on how individuals or organizations are handled. Where parallel configuration is required, close collaboration with the central structure will ultimately reduce technical integration complexity, may improve shared segmentation criteria, align shared terms within the operational model (ex. is a “member” defined the same way across the organization and its systems?).
Shared communication practices
A general set of rules should be in place for how to manage constituent preferences or interaction practices. One of the most common examples is the email “opt-out.” If someone opts-out of communication – how will that information quickly flow and reconcile across systems. Privacy concerns, sharing of sensitive information or volume of communications over a period of time are other practices that are best taken into consideration for unification.
Unified support effort
Ideally, at least support is centralized as at some point someone needs to mind the overall architecture. This might only be “level 1” (reset password, etc.), but having a single support path is most likely to not only meet internal users expectations, but also ensure there is a feedback loop for all of the other considerations.
Conceptually, guard rails can be a key component of enabling your CRM strategy where functionality or business needs might allow for consolidation around a single, central system. Ultimately, a good guard rail is one that reduces integration effort, ensures sharing comparable to single-system architectures, and ensures that your constituents do not experience the organization via separate systems.
Have you run into a project where you’ve had to implement guard rails?