A few years ago, your organization decided to implement an enterprise-class CRM. Through a multi-year endeavor, your expert staff worked with the design team to make decisions about where every bit of information would be stored, yet some of it didn’t fit perfectly. As a result you may have made the decision to use the tool for a few years, and tweak the data structure as you go.
Fast forward to today, and you have been on a journey with your users as they became familiar with their new tool and new data management methodology - the ups and the downs. Now, it’s time to upgrade, and with their system familiarity comes the desire to change. Too many Attributes, customizations that are difficult to track and maintain, Code Tables that have exploded in size, and Security Roles that require substantial effort to manage, are indicators that it is time to reconsider the data decisions made during Design.
When planning for your upcoming re-implementation, start with the Top 10 candidates for re-engineering:
1. Customizations - Every. Single. One.
The initial implementation meant taking legacy data from one system, and trying to figure out where it should live in the other system. Your methodology for entering and understanding information was based on the structure provided by the old system. Because of that, attempting to map legacy data into the new application was a daunting task. Further, differentiating data elements which are valuable in setting your organization apart, did not already have a home in the new CRM.
The answer at the time was: Customize! Yet, customizations are expensive - they require resources and effort, and are yours to maintain as long as you keep them. So, take this opportunity to reconsider if you need them. Is there a way to capture the same information differently? Have there been enhancements to the CRM that would better allow you to capture the information out of the box?
If you ultimately need to customize, ensure that the customizations are written within the SDK. As long as the Software Developer’s Toolkit is used, the customizations should survive through Service Pack Updates and Upgrades in the future. That said, always test your customizations after updates.
2. Exploding Code Tables!
Options! Data entry means having options to catalog and categorize each record. Code tables establish the values available in drop-down menus system-wide, and offer ways to “slice and dice” your data for reporting purposes. Yet, drop-down menus tend to expand rapidly as your users understand the system better. Legacy values entered during the initial conversion must remain because they exist on the historical records, and new values appear as you develop different ways of identifying records.
Consider code tables as a way to limit the categorization options, for consistency of data entry and simpler reporting. In that way, perhaps some existing values can be combined (Contact Method of “Visit” and “In Person,” for example), or removed. Legacy values can be marked inactive, to remain on the historical records, but not used going forward.
3. Attributes... and the Kitchen Sink
Attributes represent characteristics which define each record in the system. Yet the characteristics from your legacy system may not have fit nicely into the fields available in CRM. Attributes are easy to create and allow for some data entry conformity, but provided a safe place to store all of the data remaining after conversion mapping the first time… and the kitchen sink!
When a new Attribute is created, it establishes a completely new table in the system. Since some records can have more than one of the same Attribute (think: one Giving Level value for each year, or multiple Program Interests), using Attributes for query or reporting can be tricky. Further, the need to pay attention to Start and End dates to indicate the most current value provides an obstacle for the users.
Think strategically about your use of Attributes. Can a report code or a different field house the same information (Funding Interest or Prospect Plan fields, for example)? Can another part of the system (Recognition Programs or Events) capture the data relationships without the need for additional Attributes? You will still need Attributes, of course, but using different areas of the system may support easier reporting and data access.
4. Documentation exchange
Documentation is most notably available to enter on the Constituent and Revenue records. But did you know that it can be added in many other places in CRM? Using unstructured data to support the data entry process can help provide context to your users, and ultimately encourage information exchange across teams and departments. Consider a business process to add Documentation in some of these areas of CRM:
Prospect Plans and Plan Steps
Event records
Fundraising Purposes associated with Designations
Memberships - Member records
Volunteer area (Constituent's Volunteer tab)
Planned Gift expectancy record
Worried about memory when adding Documentation? Rather than adding attachments directly into CRM, consider an external document repository. Users can upload documents to the external system, and link the system record directly to the document using Media Links in CRM.
5. Designations and the Fundraising Hierarchy
Full disclosure: this is pretty complicated, and might require data conversion, but worth revisiting nonetheless...
Are you using Revenue Attributes to capture mission-critical information? Do your users need to manipulate revenue data outside of the system in order to provide reports to the Financial team or Leadership? Do you find reconciliation never fully balancing? It may be time to rethink the Designation structure and Fundraising Hierarchy.
The Fundraising Hierarchy in CRM was designed to be as complex or as flat as needed for many different financial structures. Because the concepts are variable, many organizations decide to implement a flat structure for simplicity of mapping from their legacy systems. This means that each Designation is tied to a single Fundraising Purpose, and those records combine to relate to your financial systems. It is possible for CRM to better support the financial reporting, though, as a sub-ledger of additional detail about revenue and distributions.
With a re-implementation, you have an opportunity to consider the decisions you made in this area, and determine whether the structure is supporting your fiscal needs. In some cases, re-engineering the Hierarchy makes a lot of sense because it has the potential to offer multi-faceted reporting, as well as supporting the General Ledger Account structure, all directly within CRM.
6. General Ledger Account Structure
It may be complicated to maintain the distribution rules for different transaction types in CRM. The General Ledger is designed to use Revenue characteristics and relationships within the system to determine the debit and credit accounts, and post that information to your financial system. Here again, if reconciliation is a headache, it may be time to take a look at the Account Structure.
Many record types in CRM can be used to define the segment values in a GL Account code string. For example, the Fundraising Purpose, Designation, Appeal, or Event records associated with the Revenue transaction can automatically define the account codes to be used for GL distribution. Using these elements, you can define Account strings in the GL that contain more details than your financial systems. Assigning an Alias for each Account string ensures that your distributions will map correctly to your financial systems, and also provides a linkage to the additional details that you capture during revenue data entry.
7. Reporting - get that data OUT!
Periodically, it is a good idea to review the existing custom reports you have built to ensure that they are useful and used, and determine if there are ways to better support the users with information delivery options.
Calculations: Have you created reports that calculate data when the report executes? Consider instead building the calculations into the data using Smart Fields or (even better!) a Data Warehouse. Centralizing calculations and summary fields is important for consistency, but also to help reports run faster.
Reports vs. Tabs: Do your users love specific reports, and run them all the time? Perhaps “delivering” the information directly to them will improve the user experience. It is relatively easy to create a new Functional Area with your own tabs in CRM, and surfacing reports on those tabs could allow you to combine similar activities, or even offer the ability to take action on the information included in the report. (Take a look at Major Giving Management in the Prospects functional area for an example.)
Dashboards and Graphic Reporting: SSRS offers some graphic reporting options, but Business Intelligence reporting is advancing at lightning speed. Consider moving your statistical dashboards outside of CRM using a real-time direct-link OData connection. OData links can feed other reporting tools, providing a more flexible way to build and distribute graphic reports.
8. Prospect Plans: Manilla Folders and Legal Pads (digitized)
Prospect Plans represent the areas of the system intended to manage workflow and action, not only to record information. If your Fundraising teams are managing their work outside of the system, if you see that fundraising strategies are out of alignment across teams, or if your reporting team needs to ask for input in order to provide a Pipeline report, it is time to consider expanding your use of Prospect Plans.
With the full use of Prospect Plans, teams can manage their tasks, Fundraisers can stay abreast of the activity happening for and with their prospects, and Leadership can see the giving pipeline at any time. Reconsider the Plan Templates you have defined, and if they are realistic workflows, since strategies change. If you are preparing for the next campaign, take the time as an organization to lay the groundwork for the tasks and strategies to be used. Consider expanding into Stewardship Plans to ensure that your primary donors are consistently stewarded, and determine the best time for the next solicitation.
9. Security Roles - Simplify and Reorganize
You onboard a new staff person, and must give them access to CRM… How do you know which Security Roles to grant or deny? Have staff changed job roles, but maintained their old Security Roles alongside their new roles? Re-implementation is a chance to take a look at the roles you have in place, and the job requirements at your organization. Security Role management is manual once it is established, so any simplification or refinement is worth undertaking.
How do users obtain access? It may be worth asking users to take a training class in order to gain access to advanced functionality, such as Add/Edit records. If job roles are clearly defined in your organization, perhaps structuring the Security Roles to mirror job roles is a possibility.
Permissions are also available in areas of the system, which supercede the Security Roles, allowing you to be more general with your Security, and more specific with Permissions. Batch templates, Query run/edit, and each page and tab offer permissions specific to that functionality.
10. Expanded functionality
Go on… give it a try! As mentioned before, now may be the right time to test-drive some of the more advanced functionality available in CRM. Feeling more comfortable with the core functionality will allow your users the confidence to branch out and explore Design for areas such as Events, Research Requests, and Marketing Efforts. Perhaps you understand better how the data is stored and captured, so Recognition Programs, Named Recognition, Benefits, and Volunteer management are areas to explore.
When planning for your upgrade, allow your organization the opportunity to think about the decisions that drove your initial implementation of CRM. Some of those decisions have been solidified by continued use of the system as designed. Some decisions were based on business practices that have changed over time. And others are not sustainable for the long-term use of the system. With careful consideration of the Top 10 and other decisions, the effort to upgrade and re-engineer will align the tools with the business process, and stabilize and support your fundraising practice.
Contact the team at BrightVine Consulting to review the use of your CRM today, and for suggestions and options to consider for tomorrow.