Buying Software Won't Fix a Broken Process

When something hurts long enough, the natural reaction is to find a vendor whose marketing promises to make it stop. That works for commodities. It rarely works for operations.

Process problems are rarely solved by procurement. A team that spends three days a quarter reconciling two systems doesn't need a fancier reconciliation tool. They need a clear answer to why the two systems disagree in the first place. The tool just decides how the disagreement is logged.

The pattern repeats across institutional finance and mid-market operations:

Step one, someone identifies a painful process. Step two, a vendor demos a polished product that claims to handle exactly that pain. Step three, the contract is signed. Step four, six months in, the team is using ten percent of the platform, still doing the workarounds, and quietly maintaining the old spreadsheet alongside it. The new system inherits the same undocumented edge cases the old one had — only now they live behind a vendor's API.

The reason this happens isn't that the software is bad. Most of these products are well-built. The reason is that the process being automated was never written down clearly enough for any system — human or otherwise — to execute it consistently.

Before you sign anything, three exercises are worth more than the price of the platform:

Document the process you actually run, not the one in the deck.Sit with the person doing the work for a week. Write down every decision they make, including the ones that feel obvious. The gap between “here's how it works” and “here's what we actually do” is almost always larger than expected.

Identify the rules nobody owns. In most operations, a handful of decisions get made consistently but are not formally owned by any system or policy. Those rules are precisely the ones that break when the process moves to new software, because the buyer assumed the vendor handled them and the vendor assumed the buyer would configure them.

Decide what you would do if you couldn't buy anything.If the only option were to fix the process with the team you already have, what would the first move be? Usually it's standardizing inputs, writing down the rules, and cleaning a few canonical tables. That work makes any future software purchase cheaper, faster, and less likely to fail. It also frequently solves the original problem on its own.

Software is a powerful amplifier. Pointed at a process you understand, it makes you faster. Pointed at one you don't, it makes the confusion harder to see and more expensive to unwind.

The right time to buy is after the process is clear enough that the requirements doc reads like a spec, not a wish list. Until then, you're not buying a solution. You're buying a new place to keep the same problem.