Why we fix the process before the software
Software does not fix a broken process, it makes it faster and harder to change. Why the mapping step that looks like a delay is the one that saves the money.
When a business comes to us wanting new software, the first thing we do is often frustrating for them: we ask to see how the work is done now, before we talk about tools at all. It looks like a delay. It is the opposite. It is the step that stops you spending money digitising a mess.
Software does not fix a broken process. It makes the broken process faster, more consistent, and much harder to change. If the underlying way of working is muddled, all technology does is set the muddle in concrete.
Technology copies whatever you give it
A new system takes your current process and reproduces it at speed and scale. If that process has three unnecessary approval steps, the software now enforces three unnecessary approval steps on every single job, and takes an argument and a change request to remove them.
Doing the process work first means you build the improved version into the software, instead of building the old version and paying again to fix it later.
The cheapest improvements need no software at all
When we map a process, we often find steps that exist only out of habit: a form nobody reads, a sign-off from someone who always says yes, a report that gets produced and filed and never opened. Removing those costs nothing and frequently delivers most of the benefit people expected from the new system.
The best time to delete a pointless step is before you pay to automate it.
It is not unusual for a business to arrive certain they need a build, and leave with a simpler process and a much smaller project, or none at all.
A clear process makes a cheaper build
Even when you do need software, doing the process work first makes the build faster and cheaper. The people scoping it are working from a clean, agreed description instead of guessing, and there is far less rework, because you are not discovering halfway through that two departments do the same job differently.
This is where a lot of business process optimisation quietly pays for itself. The tidier the process going in, the smaller the surprise going out.
How to do it without a consultant in the room
You can start this yourself. Pick one process, write down every step as it actually happens, then mark each step: does this add value for the customer, or does it exist for us. Question everything in the second group. What is left is a process worth building on, and often you will have improved it before anyone writes a line of code.
Fix the process first. Then, if you still need the software, you will build the right thing once.
Not sure whether your process passes?
Tell us what it is and we will walk through the questions with you. No charge, no obligation.
Before you automate anything
Four questions worth answering about a process before you spend a dollar automating it. Most of the automation projects we are asked to rescue skipped at least two of them.
Spreadsheets are not the problem
For a lot of what SMEs do, a good spreadsheet is the right tool. This is how to tell when yours has quietly become a liability.