Should industrial software companies say no to customer customization?

In industrial software projects, there is a saying that is not entirely agreeable:

Whenever a customer mentions customisation, the vendor advises: try not to change the code, solve it with configuration.

This sounds very professional, but sometimes it is experience, and sometimes it may be a sign of insufficient product capability.

A factory spends money to buy software and hopes the software will adapt to its business – what is wrong with that?
But if every special requirement requires the vendor to change the code, what is ultimately produced – a software product, or a special version developed exclusively for one factory?
The difference between these two is significant.

For example.
A factory wants to adjust its production reporting process. The vendor says it can be configured without changing the code.
If the system inherently supports flexible configuration and changing a few rules can solve the problem, then of course there is no need to touch the code.

But if the vendor's so-called configuration can only change fields and permissions, and cannot handle slightly more complex business logic, then not all problems can be attributed to the factory's requirements being unreasonable.

What should be configurable cannot be configured, and everything ends up relying on customisation – this is not because the customer is too difficult to serve, but possibly because the product capability is too weak.

01First, Distinguish Clearly: What Is Configuration, What Is Customisation

So factory managers must first distinguish clearly between configuration and customisation.

Configuration is adjusting rules, processes, and parameters within the capabilities already designed into the software.Customisation is developing functions that did not exist before in order to meet specific requirements, and even changing the core logic of the software.

Configuration is generally easier to maintain and upgrade, but not all configuration is good; customisation is not necessarily bad either – the key is what exactly you are customising.

02Three Criteria for Judgment

First, is this requirement commonly needed by the industry, or unique to your company?
If peers and other branches also need it, don't rush to have the vendor change the code separately. Push for it to become a standard product capability.

Second, is this requirement truly your core competitiveness?
If it involves unique processes, special quality control, or key scheduling rules, it is worth carefully evaluating customisation.
But if it is only because this is how it has always been done, or a certain leader is used to operating this way, and the software is required to replicate it exactly, it is advisable not to rush to touch the code.

Do not lock down future management improvements just to replicate today's working habits.

Third, have you calculated the long-term cost of this customisation?
Don't just ask how much the development fee is – also ask what happens with future upgrades, who is responsible for maintenance, what happens if the original programmer leaves, and what happens if you change vendors in the future.
Just because you paid for a function today does not mean this function will be maintained for free in the coming years.
Especially once the core code has been changed beyond recognition, the software's original vendor may not be able to ensure direct compatibility during upgrades, and subsequent maintenance will become increasingly troublesome.

03What Should Be Done?

The recommendation is simple:

First require the vendor to demonstrate configuration capabilities on-site, then decide whether customisation is needed.

Don't just listen to the salesperson say "it supports configuration" – ask them to configure a form, a process, a report, or a set of permissions on the spot.
If simple business changes cannot be achieved, then carefully evaluate whether this product is suitable for you at all, rather than turning every problem into a customisation project.

If customisation is truly necessary, try to place special logic in relatively independent extension modules, minimise modifications to the product core, and clarify upgrade and maintenance responsibilities in advance.

04Industrial Software Is More Like a Standard Machine Tool with Special Fixtures

Industrial software is more like a standard machine tool with special fixtures than a fully tailor-made suit.
A truly good product should have a stable standard foundation and sufficiently strong configuration and extension capabilities.

What the factory needs to do is not to make the software replicate today's processes one hundred percent, but to think clearly about:

which rules must be adhered to, which habits should be changed, and which special capabilities are worth paying for.

Finally, a question for friends who have truly worked on industrial software projects:

How do you usually handle customisation requirements? When a factory insists on changing the process and the vendor insists on not changing the code, how is it ultimately resolved? Are there any experiences or lessons worth sharing?