This article was originally published in the NTEN eBook “Collected Voices: Data-Informed Nonprofits” in January of 2014.
The reasons why we want to make data-driven decisions are clear. The challenge, in our cash-strapped, resource-shy environments is to install, configure and manage the systems that will allow us to easily and efficiently analyze, report on and visualize the data. This article will offer some insight into how that can be done, while being ever mindful that the money and time to invest is hard to come by. But we’ll also point out where those investments can pay off in more ways than just the critical one: the ability to justify our mission-effectiveness.
Right off the bat, acknowledge that it might be a long-term project to get there. But, acknowledge as well, that you are already collecting all sorts of data, and there is a lot more data available that can put your work in context. The challenge is to implement new systems without wasting earlier investments, and to funnel data to a central repository for reporting, as opposed to re-entering it all into a redundant system. Done correctly, this project should result in greater efficiency once it’s completed.
Consider these goals:
- An integrated data management and reporting system that can easily output metrics in the formats that constituents and funders desire;
- A streamlined process for managing data that increases the validity of the data entered while reducing the amount of data entry; and
- A broader, shared understanding of the effectiveness of our strategic plans.
Here are the steps you can take to accomplish these goals.
The first step in building the system involves ferreting out all of the systems that you store data in today. These will likely be applications, like case or client management systems, finance databases, human resources systems and constituent relationship management (CRM) systems. It will also include Access databases, Excel spreadsheets, Word documents, email, and, of course, paper. In most organizations (and this isn’t limited to nonprofits), data isn’t centrally managed. It’s stored by application and/or department, and by individuals.
The challenge is to identify the data that you need to report on, wherever it might be hidden, and catalogue it. Write down what it is, where it is, what format it is in, and who maintains it. Catalogue your information security: what content is subject to limited availability within the company (e.g., HR data and HIPAA-related information)? What can be seen organization-wide? What can be seen by the public?
|Traditionally, companies have defaulted to securing data by department. While this offers a high-level of security, it can stifle collaboration and result in data sprawl, as copies of secured documents are printed and emailed to those who need to see the information, but don’t have access. Consider a data strategy that keeps most things public (within the organization), and only secures documents when there is clear reason to do so.|
You’ll likely find a fair amount of redundant data. This, in particular, should be catalogued. For example, say that you work at a social services organization. When a new client comes on, they’re entered into the case management system, the CRM, a learning management system, and a security system database, because you’ve given them some kind of access card. Key to our data management strategy is to identify redundant data entry and remove it. We should be able to enter this client information once and have it automatically replicated in the other systems.
Chances are, of course, that all of your data is not in one system, and the systems that you do have (finance, CRM, etc.) don’t easily integrate with each other. The first question to ask is, how are we going to get all of our systems to share with each other? One approach, of course, is to replace all of your separate databases with one database. Fortune 500 companies use products from Oracle and SAP to do this, systems that incorporate finance, HR, CRM and inventory management. Chances are that these will not work at your nonprofit; the software is expensive and the developers that know how to customize it are, as well. More affordable options exist from companies like MicroSoft, Salesforce, NetSuite and IBM, at special pricing for 501(c)(3)’s.
A data platform is one of these systems that stores your data in a single database, but offers multiple ways of working with the data. Accordingly, a NetSuite platform can handle your finance, HR, CRM/Donor Management and e-commerce without maintaining separate data stores, allowing you to report on combined metrics on things like fundraiser effectiveness (Donor Management and HR) and mail vs online donations (E-commerce and Donor Management). Microsoft’s solution will incorporate separate products, such as Sharepoint, Dynamics CRM, and the Dynamics ERP applications (HR, Finance). Solutions like Salesforce and NetSuite are cloud only, whereas Microsoft and IBM can be installed locally or run from the cloud.
Getting from here to there
Of course, replacing all of your key systems overnight is neither a likely option nor an advisable one. Change like this has to be implemented over a period of time, possibly spanning years (for larger organizations where the system changes will be costly and complex). As part of the earlier system evaluation, you’ll want to factor in the state of each system. Are some approaching obsoletion? Are some not meeting your needs? Prioritize based on the natural life of the existing systems and the particular business requirements. Replacing major data systems can be difficult and complex — the point isn’t to gloss over this. You need to have a strong plan that factors in budget, resources, and change management. Replacing too many systems too quickly can overwhelm both the staff implementing the change and the users of the systems being changed. If you don’t have executive level IT Staff on board, working with consultants to accomplish this is highly recommended.
Business Process Mapping
The success of the conversion is less dependent on the platform you choose than it is on the way you configure it. Systems optimize and streamline data management; they don’t manage the data for you. In order to insure that this investment is realized, a prerequisite investment is one in understanding how you currently work with data and optimizing those processes for the new platform.
To do this, take a look at the key reports and types of information in the list that you compiled and draw the process that produces each piece, whether it’s a report, a chart, a list of addresses or a board report. Drawing processes, aka business process mapping, is best done with a flowcharting tool, such as Microsoft Visio. A simple process map will look like this:
In particular, look at the processes that are being done on paper, in Word, or in Excel that would benefit from being in a database. Aggregating information from individual documents is laborious; the goal is to store data in the data platform and make it available for combined reporting. If today’s process involves cataloguing data in an word processing table or a spreadsheet, then you will want to identify a data platform table that will store that information in the future.
Once you have catalogued your data stores and the processes in place to interact with the data, and you’ve identified the key relationships between sets of data and improved processes that reduce redundancy, improve data integrity and automate repetitive tasks, you can begin designing the data platform. This is likely best done with consulting help from vendors who have both expertise in the platform and knowledge of your business objectives and practices.
As much as possible, try and use the built-in functionality of the platform, as opposed to custom programming. A solid CRM like Salesforce or MS CRM will let you create custom objects that map to your data and then allow you to input, manage, and report on the data that is stored in them without resorting to actual programming in Java or .NET languages. Once you start developing new interfaces and adding functionality that isn’t native to the platform, things become more difficult to support. Custom training is required; developers have to be able to fully document what they’ve done, or swear that they’ll never quit, be laid off, or get hit by a bus. And you have to be sure that the data platform vendor won’t release updates that break the home-grown components.
The end game is to have one place where all staff working with your information can sign on and work with the data, without worrying about which version is current or where everything might have been stored. Ideally, it will be a cloud platform that allows secure access from any internet-accessible location, with mobile apps as well as browser-based. Further considerations might include restricted access for key constituents and integration with document management systems and business intelligence tools. But key to the effort is a systematic approach that includes a deep investment in taking stock of your needs and understanding what the system will do for you before the first keypress or mouse click occurs, and patience, so that you get it all and get it right. It’s not an impossible dream.