The Myth of Uniqueness / Data Integration

Michelle Murrain (http://murrain.net) gets it right and the below guest blog echoes our own experience - we have seen that while each nonprofit has a unique combination of technology issues and problems, the specific problems recur from organization to organization.   

 --------------------------------------------------

[On] my list of things that keep the sector from having a suite of open source tools to do varied things around CRM/Fundraising/Advocacy, is what I call the "myth of uniqueness."

Of course, each nonprofit *is* unique - unique in its relationship to its mission, the personalities of the staff and leadership, where it's located, its quirks and dysfunctions... But the uniqueness should really not be reflected in the software it uses.

For most organizations, their perception of uniqueness center around their data ecosystem started way back in 1995, when someone (perhaps the ED, perhaps the CFO) got tired of dealing with paper, and having to generate painstaking reports manually. It would take them days and days. They were fed up. They hired a database guru (I used to be one of these back then) or they drafted an accidental techie, or they found out that their Board Chair's high school child knew their way around a database.

And they built their first database in Access/FoxPro/Paradox/Filemaker. And it wasn't pretty, but at least the ED could get five reports quickly and easily. They weren't quite the reports she really optimally needed, but that was what the system generated, and it worked.  And the staff stopped grumbling about the fact that the tool would lose data in the middle of data entry, and had only a certain size for fields, but they suggested that their workflow and system be modified to make it easier to avoid those problems and the limitations of the database. And the whole organization, over time, wrapped it's workflow around this imperfect tool.

Five years later, or thereabouts, they realize that they are outgrowing this tool, and need a new one. And so they write up the requirements of the tool. For instance, and it has to generate the same five reports that everyone forgot were imperfect. The tool has to fit into their workflow... the workflow they forgot they built around the unique, imperfect tool that they built first.

We all are unique human beings, but organs like our hearts and stomachs look and work pretty much the same. (And no, the data ecosystem of an organization is not it's brain - it's brain is the people.) Good tools work like organs. I can say from personal experience that CiviCRM works very well for the very small, scrappy food justice organization I'm on the board of. I also hear it works well for the multi-million dollar and huge, huge donor/volunteer organization, Wikimedia Foundation. Pretty good odds it will work for a lot of organizations in the middle. I can say from personal consultant experience (believe it or not) that Salesforce can work for a Fortune 100 financial services corporation with thousands of users, gazillions of deals catrillions of dollars in size, as well as it does for a small educational nonprofit with one user and tens of donors and hundreds of students to track. Good tools can do that.

The key to integration, which Salesforce managed to get right, is build a solid base, a great platform for customization, and screamingly great APIs (OK, they are not really screamingly great, but they are far better than any API that I know of that exists in the nonprofit CRM space.) So you get to hook that data into other systems which, you hope, have really good APIs, too. That's always been the optimal - use the best-in-breed for the functions you have, and hook them together so that they can work well together.

And, what's also true in my experience is that after the agony of moving from a tool that an organization has wrapped it's workflow around, to a powerful tool that it just barely scratches the surface of using its functionality, that it begins to notice things it can do that it never could before, and could never actually even envision, because of the previous limitations of their "unique" tools. And those things become, later, mission-critical (really, I've seen it happen.) That's where the innovation is - having to move out of your comfort zone, to learn what's possible.

-- email:  This e-mail address is being protected from spambots. You need JavaScript enabled to view it.

web: http://murrain.net

twitter: @pearlbear

• Next >