Standard or custom software? Test the same process

Start by checking whether your existing software can handle the process that matters. A new product and custom development become comparable when you assess the same rules, data and exceptions. A general tour of the interface cannot establish that fit.

The test case: an expense request changes

A fictional business receives request R-17 for 180 EUR. A manager must approve it; amounts of 250 EUR or more also require finance approval. This is an invented internal rule, not a tax threshold. After approval, the amount changes to 320 EUR. The earlier approval must not automatically cover the new amount.

The process needs a request, amount, receipt, requester, approver and processing status. Use invented names and test receipts. Ask for the normal case and these exceptions to be demonstrated:

Apply the same conditions to each option

Begin with the module in your existing ERP. Then test a suitable standard product, including the ERP connection it would need. For both, distinguish what works already, what needs configuration and what needs additional development.

Custom development is initially a proposal with a defined scope. Features that have not been built remain unproven. A sketch should not carry the same evidential weight as a completed test.

A worked example of the findings

In an entirely fictional test record, option A in the existing system passes all four cases after the deputy is configured. Option B, an additional product, handles the normal request but retains the earlier approval at 320 EUR. It also reports success when the budget service is unavailable. These are illustrative findings, not claims about real suppliers.

For this example business, A stays on the shortlist. For B, establish whether configuration or a modification resolves the two failures. Include another test and the extra work in the proposal. An easier interface does not resolve missing process rules.

Compare costs for the same scope

Assess setup, migration, ERP integration, recurring fees, operation, maintenance and a later move to another solution over the same period, such as three years. Record your assumptions about user numbers and future changes. The GOV.UK Service Standard also connects technology choices with total ownership cost and the ability to change direction.

If the existing module meets the required rules, the implementation may end there. If an important case remains unsupported across the products tested, describe that case as the scope for a targeted extension or custom application. That gives the development decision a requirement you can verify.

Sources

• GOV.UK: Choose the right tools and technology