By Bennett Donovan
I remember my first job as a software developer and how eager I was to code, test, and demo new functionality for applications used across campus. More than once toward the end of the development cycle, however, I learned that a senior leader needed a specific report, and that if our solution couldn’t support it exactly, we would need to rethink our strategy. It seemed backwards to me at the time. Shouldn’t the functional solution drive reporting, not vice-versa? Having been in the industry for 15 years now, I realize that it has to work both ways.
In enterprise software implementations, reporting is too often an afterthought. Sometimes it doesn’t even get a mention until late in the implementation process. The customer might bring up reports during requirements gathering, but it’s always so tempting for everyone to agree that the data will be available in the system and leave it at that.
I’m not a proponent of legacy reports driving functional requirements. It’s almost always better for an organization to adapt business practices to the strengths of the software as opposed to customizing the software to do something it wasn’t designed to do. That said, there are concrete steps that organizations can take to make sure that reporting needs are met as the new solution is designed and delivered.
Create a Report Inventory
More than anything else, reporting cuts across multiple departments at an organization. Finance, Direct Marketing, Digital, Major Giving, Volunteer Coordinators, and even the Board of Directors all want to see “their” reports. But who is tracking these reports across the entire organization? Organizations should consider creating an inventory. It can be as simple as an Excel spreadsheet that lists every recurring report in use. The list of reports should go along with its business owner, business purpose, distribution, frequency, the system or process that generates it, the directory or repository in which the output is stored, and links to further documentation containing detailed descriptions, layout, and business logic. Inventories are living documents that must be maintained, so ownership should exist at the operations level if possible.
Review your Report Inventory Annually
At least once a year, an organization should review its report inventory. Are there reporting gaps and a need for new reports? Are there reports that are obsolete and can be retired? Is there overlap or duplication of reports across departments that offers an opportunity to consolidate?
Develop a Business Intelligence Vision and Strategy
As all BI vendors will tell you, there are reports and then there is business intelligence. Beyond the delivery of key reports, where does your organization need to go in terms of analytics, big data, dashboards, and data visualization? The sales demos always look great. But what are the actual needs of the non-profit, and where would any investment in BI tools and platforms yield the most bang for the buck? I’ve seen a few atomic flyswatters in this area, where powerful and expensive tools are underutilized or delivering easily accessible data. Whether your organization commits to BI or sticks to spreadsheets, it should be a strategic decision that considers costs and benefits at an organizational level.
Discuss Reporting at the Beginning of Systems Requirements Gathering
Reports represent the end of a functional workflow, when the results of activities are calculated and shared. But reports should be discussed early in the requirements gathering process for any new system. It’s OK to say “this is what our board needs to see each month and any SOW must deliver it.” A report is a user story as much as any other critical organizational function, so make sure that your key reports are included in your user stories. Don’t ever assume that the same reports can be easily generated just because the same data will be migrated into a new system.
Consider Data Architecture & Testing
Running reports – especially with complex calculations and/or business logic – can require significant computational and processing power. It’s important that the data architecture behind your CRM or BI tool supports this, particularly if you have many concurrent users. When switching CRM systems, extensive testing of baseline reports at volume (which generally requires a full data migration into a sandbox environment) is critical to determining which reports will be successful in your new CRM environment. It’s important to recognize that the data structure behind a true CRM does not necessarily lend itself to reporting. Being realistic about what you can accomplish in your new CRM versus what you might need to find an alternative option for is critical to your organization’s long-term success.
No report exists only for its own sake. Reports exist to measure the success and advance the mission of an organization. So, “that’s how we’ve always done it” or “that’s what people are used to seeing” are never good reasons to customize software to replicate a legacy report. You’re investing in a new CRM or other system to move your organization forward, so don’t allow habit to hold you back. It may be that after careful analysis the way you’ve always done things is truly the best way to continue. But take the time to ask the question and see if the reports that your organization needs can be delivered in a way that aligns with the enterprise software that you are implementing.