When business software needs to fit the operation

Software rarely stops fitting all at once. More often, the signs show up around it: a spreadsheet that tracks what the system cannot, an inbox that quietly becomes an approval queue, or a colleague everyone consults because they know which exception comes next.

Those workarounds can look harmless on their own. Together, they may be evidence that the operation has changed while its tools and rules have not. The answer is not automatically custom software. First, find out where the gap is, how often it matters and what it costs the business.

Look at the work around the software

A product can perform exactly as designed and still leave a process poorly served. The useful test is not whether the software has an impressive feature list. It is whether people can move work forward with a clear status, an accountable owner and a known next step—and whether the information remains trustworthy along the way.

Watch for recurring patterns:

• Repeated entry or reconciliation: the same facts are typed into multiple systems, or someone regularly compares records to determine which one is correct.
• Shadow tracking: a spreadsheet, chat thread or personal task list has become necessary to see what is waiting, overdue or approved.
• Unclear handoffs: work stalls because the next owner, required information or decision rule is not visible.
• Exceptions handled by memory: experienced staff know the workaround, but the process does not explain it or make it repeatable.
• Volume creates coordination work: more customers or transactions mean more chasing, checking and status meetings rather than a proportionate increase in useful output.

One workaround does not prove a system is wrong for the business. It may be a sensible local fix. The question is whether these workarounds are frequent, risky or expensive enough to affect service, control, decision-making or the team’s capacity.

Map one process from trigger to outcome

Start with a process that matters: a customer order, a service request, a procurement approval, an onboarding journey. Follow a real case from the moment work begins to the point the business considers it complete. Include the ordinary path and the cases that take a detour.

For each step, record:

• Who does the work and who owns the next decision?
• What event starts the step, and what must be true for it to finish?
• Which system holds the relevant information?
• What information is missing, re-entered or checked by hand?
• Where does work wait, and how does someone know it is waiting?
• What happens when the usual path does not apply?

Then separate the problem from the proposed solution. “We need a new platform” is a solution hypothesis. “Orders with a pricing exception wait two days because the approval owner is not assigned and the sales system does not show the finance decision” is a gap a team can investigate.

That distinction matters. The cause might be a missing rule, a confusing interface, poor data, an integration that fails silently, a staffing issue or a tool that genuinely cannot support the process. Each points to a different remedy.

Measure the friction before choosing a tool

You do not need a perfect analytics program to establish a useful baseline. Pick a few measures that reflect the problem: time from trigger to completion, number of handoffs, cases reopened, manual corrections, missed commitments, exception frequency or staff time spent chasing status.

Use a representative sample and agree on what counts. For example, define when the clock starts and stops, and count rework consistently. A short period of observation may reveal that the suspected bottleneck is not the step people complain about most. It may be an earlier decision, missing information or an unclear queue.

Also consider the consequences of getting the process wrong. A delay in an internal request does not carry the same impact as a pricing error, an uncontrolled payment or a missed customer commitment. Security, auditability, privacy and regulatory duties belong in the requirements from the start, not as a late checklist.

Buy, adapt or build

Once the gap is concrete, compare the available approaches against the same requirements.

Buy

A standard product is often the strongest choice when the process is common, the vendor’s model matches the way the business needs to operate, and the product supports the necessary controls and integrations. Compare the actual workflow in a realistic demonstration, including exceptions—not just the polished happy path.

Understand the full commitment: configuration, implementation, migration, integration, user training, subscription changes, support and the work required to leave later. Check which capabilities are included, which require add-ons and which depend on a partner or custom code.

Adapt

Adapting can make sense when the core system is useful but the gap sits in configuration, integration, reporting or a focused workflow around it. Before adding a layer, decide which system owns each important piece of information, how updates move between systems, and what should happen when a connection or sync fails.

A small extension can remove repeated work while preserving a sound system of record. A pile of loosely connected automations can create a new kind of fragility. Make ownership, failure handling and ongoing maintenance part of the design.

Build

Building is worth evaluating when the process is strategically important, happens often, differs materially from standard workflows and cannot be supported well through a reasonable configuration or integration. It can also be justified when the operation needs a coherent experience across several systems and that coordination is itself a meaningful capability.

A custom system comes with continuing responsibilities: product decisions, security updates, infrastructure, support, documentation and adaptation as the business changes. Estimate these costs over the life of the system and decide who will own it. A bespoke tool without a clear owner can become another legacy system surprisingly quickly.

Make the decision reversible where you can

Big replacement projects are difficult to learn from because too many assumptions land at once. Where possible, start with one process, one team or one well-bounded workflow. Agree on the baseline, define what improvement would count, and test the operational fit before expanding.

Write down the assumptions that could change the decision: expected volume, exception rates, data quality, vendor capabilities, implementation effort and the cost of keeping the current process. Revisit them as evidence arrives. The right choice may change once the team sees how the work behaves in practice.

The point is not to eliminate every manual step. Some checks protect the business; some exceptions need human judgment. The goal is to make the important work visible and dependable, and to stop relying on hidden knowledge and avoidable coordination to keep it moving.

A practical decision checklist

• Can the team describe the operating gap with a real example?
• Do you understand the standard path and the most important exceptions?
• Have you identified the owner and source of truth for each critical decision and data item?
• Can a standard product meet the requirements without forcing harmful process changes?
• Could configuration or a focused integration close the gap with clear failure handling?
• If building, is the process valuable and distinctive enough to justify lifetime ownership?
• Have you defined a baseline and a measurable outcome for the change?

If those answers are still fuzzy, the next investment should be in understanding the process—not choosing a technology. Once the gap is clear, the choice between buying, adapting and building becomes far more grounded.