Configuring versus customising: why the difference matters for operations software

Two ways of making software fit

Configuration means changing how a system behaves through options the system was designed to offer: names of fields, steps in a workflow, approval limits, who can see what. Customisation means changing the system itself, usually by writing new code for one customer. Both can make software fit. They carry very different long-term consequences.

An Industry Operating System is meant to be configured. The domain logic is already shaped for one industry, so what remains for you to decide is vocabulary, limits, owners and sequence. Those are business decisions, not programming tasks.

What you can usually configure

• Terminology, so screens and reports use the words your people already speak.
• Workflow steps, including which approvals are needed and in what order.
• Approval limits by role, value and type of action.
• Who can see, edit or only view each record.
• Which exceptions raise an alert and who receives it.
• The documents and evidence required before a step can close.

What customisation tends to cost

Custom code is quick to promise and slow to carry. Every change has to be tested again when the product improves. Knowledge sits with whoever wrote it. When the person leaves, or the business changes its process, the code becomes a constraint rather than a help.

There is also a subtler cost. A heavily customised system stops being comparable with the product it started as, so improvements the vendor makes may not reach you without extra work.

A simple test for any request

When someone asks for a change, ask three questions:

• Is this a rule or a limit that can be set by a person with the right role?
• Would another company in the same industry want the same behaviour?
• Does it change what the record means, or only how it is shown?

If the answer to the first is yes, configure it. If the second is yes, it probably belongs in the product itself. Only changes that alter the meaning of the record deserve careful, separate design.

Why this matters for control

Approvals and evidence are only as good as the rules behind them. When rules live in settings, a manager can read them, review them and change them with a record of who changed what. When rules live in code, only a developer can answer the question of why the system did something.

Configuring in practice

Start with the common path of one workflow. Set the approvals and evidence you actually need, run it for a few cycles, then adjust. Our post on starting with one workflow describes this in more detail. Treat the first configuration as a draft that the work itself will refine.

Who should own the settings

Configuration works best when it has an owner. Choose a person in each function who can propose changes to limits, steps and alerts, and one senior person who approves them. Keep a short note of why each rule exists. When a rule is questioned a year later, the reason should be easy to find, and the person reviewing it should be able to change it with confidence rather than fear of breaking something.

It also helps to review settings on a schedule, for example after each quarter of use, so that rules written for an earlier way of working do not linger.

A closing thought

The aim is not to avoid change but to keep change visible and reversible. Settings that a named owner can review achieve that. A system that can be reshaped by the people who run the business, without a development project, stays useful for longer.

Want to see how this applies to your industry? Browse the seven Kramvyu products or book a demo.