System vs process: are you fixing the right problem?
System vs process: are you fixing the right problem?
The system is what you paid for. The process is how you use it. That's probably the simplest way I can explain the difference. And it's an important distinction, because when something isn't working in an organisation, particularly when a CRM is involved, it's very easy to blame the system;
The CRM is rubbish, it doesn't work, we need something new. Maybe. But before you start researching replacements, migrating data and spending money on another piece of software, I'd want to know something first ... What's actually broken?
Start with three questions:
Whenever somebody tells me their system doesn't work, there are three things I want to know:
What isn't it doing?
What do you need it to do?
What do you want it to do?
Those last two aren't necessarily the same thing. There might be something genuinely essential to the work that your current system simply cannot do - That's a system problem. But sometimes the functionality exists. The problem is how the organisation is trying to use it, the processes that have grown around it, or the fact that nobody has stopped for a very long time to ask why something is being done that way.
And sometimes? It's both. I've seen that too.
When the process is the problem
One of the biggest pieces of systems work I've done was within a counselling service. When I started looking at it, nothing flowed. There were processes with far more steps than they needed, different parts of the work were happening in different places and, as so often happens with processes that have existed for a long time, there was a fair amount of: "That's just how it needs to be done."
I refused to believe that.
So rather than starting with the technology, I started with what people actually needed to achieve. What information did they need? What did they need to be able to do with it? Where were things becoming difficult?
Once I understood that, I could start looking at the processes around the systems and working out what could be simplified. And a lot of it could ... But there was another problem.
Sometimes the system really IS the problem
The counselling service was using Lamplight because it was a system commonly used by counselling teams. But, that didn't automatically mean it was the right system for this counselling team. It wasn't doing what we needed it to do. At all!
Eventually, I migrated the service into Beacon, which was already being used elsewhere within the charity. But I didn't try to make Beacon do absolutely everything either. The service also needed a booking system, and Beacon didn't have the functionality we needed. So Setmore was introduced alongside it.
That's an important part of this conversation.
The answer isn't always finding one magical system that does everything. Sometimes it's about understanding what you actually need and creating the simplest setup that delivers it. And sometimes a workaround is perfectly reasonable!
The existence of a workaround doesn't automatically mean something is broken. The question is why the workaround exists.
Show me your spreadsheets 👀
Spreadsheets are usually one of my first clues. To be clear, I don't have a vendetta against spreadsheets. In fact, for anyone who knows me well, will know I LOVE a good spreadsheet! They absolutely have their place. But if someone is maintaining a spreadsheet alongside a CRM, I'm going to ask why. Nine times out of ten, there will be a reason; Maybe the system doesn't show them the information they need, maybe they can't easily find it, maybe they can't report on it, maybe the spreadsheet has become the only way they can see what's actually happening.
The spreadsheet isn't necessarily the problem. It's evidence of one. The same applies when something takes five steps that feels like it should take two. Or when everyone has developed their own way of doing the same task. Or when only one or two people know how a particular part of the system works. Or when somebody has a collection of instructions, notes and little workarounds because the official process doesn't reflect how the job actually happens. Those things interest me far more than whether somebody likes the CRM. Because that's where you start finding the actual problem.
Ask the people doing the work
If I walked into an organisation tomorrow and they told me: “Our CRM is a nightmare.” My first response would be: Show me why.
I don't want somebody to describe the problem to me from a meeting room. I want to see it. Show me what you do, show me where it becomes difficult, show me the information you're entering twice, show me the spreadsheet you've created, show me the thing that takes ten minutes every single time you do it. And, most importantly, I want to hear from the people who use the system every day. Because you can look at a process from management level and think everything works perfectly well. But, the person actually doing it might tell you something completely different.
The people using a system every day know where the friction is. They're the ones who have created the workarounds. They're the ones who know which parts make no sense.
And they're the people who will actually feel the difference when you fix it.
Don't recreate the old system in a shiny new one
I've migrated organisations between systems before, including Rosterfy to Beacon and Lamplight to Beacon and Setmore. And there's one thing I deliberately try not to do when implementing something new: Recreate the old system. I don't want to begin with a list of everything the old system did. I want a list, ideally created with the people actually using it, of what the new system needs to do. That's a very different starting point.
Because if you take every old process, every unnecessary step and every workaround and rebuild them inside a shiny new piece of software... What have you actually fixed? You've potentially spent a lot of money moving the same problems somewhere else.
New technology can feel like the easier answer
I understand why organisations do it. If you're not somebody who naturally looks at systems and processes, working out why something isn't working can be difficult. Meanwhile, buying another system feels tangible. You've found a product, you've seen the demo. There's a monthly cost attached to it. And there's a lovely list of features telling you all the things it can do.
Paying someone to come in and investigate your existing setup can feel like the more expensive option initially. But what if the system you've already got isn't actually the problem? What if changing the processes around it could save staff hours every week? What if there's functionality you're already paying for that nobody is using? What if a few relatively small changes could fix the problem without putting everybody through a system migration?
That initial piece of work could save an organisation an enormous amount of time and money in the long run. And if the conclusion really is that the current system isn't fit for purpose? Fine. Now you've got the evidence to know why. More importantly, you've got a much clearer idea of what its replacement actually needs to do.
So, system or process?
There isn't a universal answer. Sometimes the process is broken. Sometimes the system genuinely can't do what the organisation needs. Sometimes neither is particularly bad. They're simply a bad fit for each other. And sometimes you'll need to change a bit of both.
My job isn't to walk into an organisation and announce that it needs a new CRM. It's to understand what's happening, talk to the people doing the work, find the friction and give the organisation the evidence it needs to decide what happens next.
Because a new system won't fix your problems if you take the old problems with you.
Comments