← All insights

Nearly every small business I look at has software in it that somebody is disappointed by. It was bought to solve a real problem, it was not cheap, there was a rollout, and eighteen months later it is being used for perhaps a third of what it does while the original problem is still there in a slightly different shape.

The usual explanation is that the wrong tool was chosen, or that the team did not adopt it. Occasionally that is true. Far more often the tool was bought before anyone had written down how the work actually moved, and no piece of software can supply that.

What actually happens

The sequence is remarkably consistent.

1. Something is painful. Jobs are being missed, or invoicing takes too long, or nobody can see the status of anything.
2. Someone researches solutions. The category has a name, there are three or four well marketed options, and they demo impressively.
3. A tool is bought, because a purchase is a decisive and visible action, whereas mapping a process is neither.
4. Implementation begins, and the questions start. Who approves this? What happens when a job is on hold? Where does that exception get recorded?
5. Nobody has answers, because these questions were never settled. So defaults get chosen under time pressure by whoever is configuring it.
6. Those defaults do not match how the business runs. People work around them, exactly as they worked around the last thing.

The implementation surfaces every undefined decision in your operation, all at once, at the least convenient possible moment.

Why the mess gets more expensive, not less

A manual process with a broken handover costs you the handover. Automate that same process and you are now paying a monthly licence to have the handover break faster and more consistently, with a data trail that suggests everything is fine.

Software is very good at doing the specified thing reliably. It is completely indifferent to whether the specified thing is the right thing. If the sequence is wrong, you have bought speed in the wrong direction.

The order that works

First, map it

Write down how the job moves now, based on watching it happen. Every step, every handover, every point where somebody waits on somebody else. Not the ideal version. The real one, including the workarounds.

Second, decide what should change

Look at the map and settle the questions the software would otherwise force on you. Who owns each step. What triggers the next one. Where exceptions live. What happens when someone is out. These are business decisions and they belong to you, not to a configuration screen.

Third, fix what is free

A surprising number of findings need no purchase at all. Reorder two steps so work stops waiting on an approval that was never actually required. Name one owner for the handover that keeps failing. Delete the step nobody could justify. Do these first, because they cost nothing and they change the requirement.

Then, and only then, look at tools

By this point you know precisely what you need a tool to do, which turns a vague evaluation into a specific one. You can ask a vendor whether their system handles your particular exception, rather than watching a demo of a business that is not yours.

Often the requirement has shrunk enough that a much cheaper tool covers it, or that what you already own would do the job if it were configured against the real process. That happens more than vendors would like.

The honest summary

Software is a multiplier. It takes whatever process you have and runs it faster, more consistently and at greater volume. If the process is sound, that is transformative. If it is not, you have paid for a faster version of the thing that was already costing you money.

Map first. It takes days, not months, and it is the cheapest part of the whole exercise.