Should I change my processes to match the database or make the database change to match mine?

 

This is a very common question I am asked: When I get a new database, should I change my processes to match the database and how it works, or should I make the database change to meet our processes? My views have actually changed on this over the last ten years and my own beliefs are now as follows:

First, It Depends...
First, there are a few "it depends" factors in this answer; the most important being:

• Why your current processes are as they are. In my experience, there are three common answers when I ask "why do you do process X that way?": (i) "I've no idea, we've always done it that way…"; (ii) "Because the current database makes us do it that way"; and (iii) "We've thought it through carefully and this is the best approach for us". Sadly, the latter answer is rare and the first two, and a combination/variation of those is more likely.
• Legal issues; e.g. gift aid, monitoring restricted funds etc. In these instances, the processes are going to have to reflect what is legally required anyway (although even here there could well be different ways to approach some of them).
• The type of database you are implementing; i.e. fundamentally whether it is a vertical-sector (traditional) fundraising database package, or if it is one of the newer breed of generic CRM systems. Although this difference is blurring a bit as I will explain below.

Why Wouldn't You Review Your Processes?
Secondly, when you implement a new database, whatever you buy, reviewing your processes is one of the most useful things you can do. As I said above, unless you already know you are in the "This is definitely the best process for us" category (which is rare), then this is a great opportunity to review why you do something, how, what's good about it, what's bad, what takes time, what could be automated, what you don't need to do and so on. And then you can take all that knowledge to the database implementation so that you can review the best way forward with your new system.

What if you are implementing a Traditional (vertical-sector) Fundraising Database package? e.g. Raiser's Edge, thankQ, Redbourn etc.
Many of these systems have been designed and adapted with many years of experience of what the NFP sector requires. And most which are still being sold today (if not all) are still selling and being used because they do the fundamentals perfectly well. And therefore, if you are buying into them as a software package, as a system, then it would seem to make sense to me to adapt your processes to how the packages have been designed. If you aren't going to do that, then why have you bought that package in the first place? There may be tweaks to do, but I wouldn't recommend changing the systems themselves except for the bare minimum and definitely within any parameters which the supplier suggests.

What about "generic CRM systems" such as Microsoft Dynamics and Salesforce, which you are implementing from a "vanilla" version (i.e. 'out of the box')?
These systems will give you an incredible amount of flexibility - which unfortunately is a double-edged sword. On the one hand, that means you can probably adapt the system to whatever process you prefer (within reason), so if your process review identifies some potentially great benefits by doing a process a whole new way, then this might be a great opportunity. Although that will also have the potential of higher cost, longer time, more arguments (sorry!) and a more complicated system than you might have needed. You need to be very good at keeping a lid on the amount of change you plan. And also: if you can do (nearly) anything then where do you start?! How will you know if your new process really is the best approach? How far should you go when changing the database system? And if you end up with vast swathes of changes then do not underestimate the Change Management you will need to introduce to your organisation. 

What about generic CRM system with a "fundraising/membership template"? e.g. Supporter360, Silverbear.
There are now quite a few "templates" which suppliers have created to sit on top of Dynamics and Salesforce in particular. In this instance, you are probably somewhere between still being able to change your processes if you really want to, but because the templates will have their own starting point, it would still be sensible to be using them as a starting point for reviewing your processes. Otherwise, as with packages, why buy them?

So What Is My Final Answer...?
My personal belief is to keep change as simple as possible, to use the software as it is supposed to be used as much as possible and if necessary, to start simple with the changes and fine tune them (or change them more dramatically) over time. i.e. Unless there are good reasons not to, adapt your processes to the software.

As I've discussed before, it is only after you really get to know your new software that you will truly understand what it can do, how and the benefits it can bring, so I wouldn't advocate spending huge amounts of time and money on it until you know what you really want from it.