You've bought software to manage orders, customers or jobs. Most of it works well, but one part of the business still depends on a spreadsheet or a manual workaround.

Perhaps staff have to enter the same information twice. A customer exception has to be handled outside the system. Someone spends an afternoon rebuilding a report every month.

Over time, that workaround becomes part of the business's normal operations.

Should you replace the software, build something custom or keep the process as it is?

The answer depends on what the workaround costs, how often it's needed and whether the existing product can be made to handle it.

An example: a wholesaler with an unusual allocation rule

Consider a fictional Auckland wholesaler supplying trade customers around New Zealand.

Its ordering system handles customer accounts, stock, invoices and most orders. But some long-standing customers have agreements guaranteeing minimum quantities when imported stock is scarce.

The ordering software allocates stock according to the order date. It has no way to apply those customer agreements.

On mornings when stock is short, staff export the open orders into a spreadsheet, work out the quantities manually and enter the results back into the ordering system. Customer confirmations have to wait until that work is finished.

The business has a specific problem. It needs to apply its allocation rule consistently and record the result in the ordering system.

Replacing the whole product would be expensive. The existing system already handles most of the work.

Before commissioning anything, the business needs to establish what options the product supports.

Check whether the existing software can do the job

The first step is to describe the workaround in enough detail for someone else to investigate it.

A useful description would be:

"When stock is short, two staff members export the open orders, apply the agreed customer minimums in a spreadsheet and re-enter the quantities before confirmations can be sent."

This identifies the trigger, the manual work and the effect on customers.

It also gives the software supplier something specific to examine.

The supplier might already offer a configuration option or extension that handles the rule. The business might be able to adjust the rule itself. Another product might support it as a standard feature.

If none of those options works, a custom component may be worth considering.

Build only what is missing

Suppose the ordering system provides an interface through which another application can read orders and submit allocations.

A small custom component could retrieve the open orders, apply the customer's allocation rules and return the quantities to the existing system.

Staff would still use the ordering product for stock management, invoicing and ordinary orders. The custom component would handle the specialised calculation.

This approach depends on the product's technical capabilities. An interface may be too limited, or the supplier may restrict how it can be used.

Those constraints need investigating before a developer promises an integration.

The cost of maintaining the custom component also needs to be included. If the ordering product changes its interface, the component may need updating.

When is custom development justified?

A workaround is a stronger candidate for development when it:

  • Happens frequently
  • Takes significant staff time or creates repeated errors
  • Affects customers or important business decisions
  • Represents an established rule that existing products cannot handle
  • Is likely to remain necessary

The wholesaler's allocation rule could meet those conditions. A spreadsheet used once a year for an unusual exception probably would not.

Some problems should be fixed in the business process first. If staff disagree about how an allocation should work, writing software will not settle the disagreement.

It is also worth asking whether the workaround has an acceptable cost. A manual task that takes ten minutes a month may be cheaper to keep than a system requiring ongoing maintenance.

Consider the cost after launch

Custom software needs someone to operate it, update it and investigate failures.

Before commissioning a component, establish who will control its source code and accounts, how it will be deployed and what happens if the original developer is unavailable.

For an integration, ask what happens when the connected product changes.

The full cost includes development, testing, hosting where required, updates and support. Compare that with the cost of the existing workaround and the alternatives available.

You do not need a complete specification for a replacement system to make this decision. Start with the troublesome process and find out what it would take to change that part.

For the fictional wholesaler, the result might be a configuration change, a small integration or a decision to keep the spreadsheet. The investigation should establish which option the business can justify.