Who in the company should be able to change a process

How long does it take in your company from somebody saying „this process needs fixing” to the fix actually working? A week, a quarter, or never?

The answer does not depend on how good the system is. It depends on who holds the right to change it. There are two models and it is worth comparing them head to head, because the choice between them is made once, usually unconsciously, on the day the contract is signed.

Model one: the vendor makes the change

Every modification to a process, a field or a permission goes to the vendor as a request. It looks safe and orderly, and for the first year it even works that way.

Then the arithmetic sets in. A change has a price and a lead time, so it needs justifying and pushing through internal approval. Small improvements that would genuinely make people's work easier never clear that bar, because they are not worth fighting for. Only large and urgent items get raised.

Two years on, the system holds its go-live configuration and the company works differently from how it worked then. People bridge the gap with a spreadsheet and e-mail, which is precisely what the implementation set out to replace.

This model has genuine advantages and there is no point hiding them. Nobody breaks the invoice flow by accident, and responsibility for a correct configuration sits with the party that signed the contract. What you pay for it is speed.

Model two: the company makes the change

The second model moves the right to change inside the organisation. The fix is made by an analyst, an office manager or a controller, somebody who knows the process operationally rather than from the code side.

Speed improves immediately. A new field on a request form appears the same day rather than next quarter. The cost is a different risk: configuration debt. Three fields with nearly identical names, because each department added its own. A status dictionary holding five variants of the same stage. A process branch added by somebody who no longer works there, and nobody knows whether it can be removed.

Reporting from such a system stops meaning anything. If three departments describe the same thing with three fields, there is nothing common left to count.

The comparison, plainly

Four dimensions where the two models differ most sharply.

• Response time. The vendor model is counted in weeks and quarters, the in-house model in hours and days.

• Cost of a small fix. With the vendor, a small fix costs enough that it usually never gets raised at all. In house it costs one person's time.

• Risk of a mess. With the vendor it is low, because an outsider holds the gate. In house it is high if nobody watches the whole.

• Knowledge of the system. In the first model it stays with the vendor. In the second it stays in the company and does not leave when the contract does.

The third dimension is the only one where the in-house model comes off worse, and the only one that can be addressed organisationally. It takes one appointed role with the right to configure, a history of configuration changes, permissions narrower than all-or-nothing, and somewhere to check a change before it is published.

What an analyst changes in Opero without a developer

Opero is built for the second model, and it is worth saying plainly where the line runs. Without a line of code, in configuration alone, one trained person changes the following.

• Processes. The whole flow as stages and the transitions between them, together with conditions and permissions at every step.

• Forms. Which fields a user sees when creating, viewing and editing a record, separately for the requester and for the approver.

• Layouts. The arrangement of sections, tabs and fields on screen, with draft and published versions and a way back to an earlier one.

• Rules. Automation on the principle of „when a condition is met, run an action”: set a field, create a record, send a notification, block a transition. A rule is tested before it goes live.

• Dictionaries. Controlled lists of values feeding selection fields, with entries that can be imported and exported.

• Objects and fields. The data definitions themselves, with over twenty field types, designed in a draft of the structure before they reach production.

A developer is needed only for unusual logic, and that is what the script engine is for. Most of what a company wants to improve in the first year after go-live sits below that line.

Configuration being a separate permission has one more consequence, visible only at audit time. The right to change a process and access to the data inside that process are two different things, so an analyst can lay out an HR flow without reading employee files.

The test after a year

One number says more about this than any security policy: how many changes your company made to the system by itself over the last twelve months.

Zero means the first model at its worst, a frozen system that people work around. Two hundred means the second model with no discipline at all. A dozen or so, each with a name and a reason attached, means a system that matures alongside the company.

If that number is zero for you, it is worth seeing the Opero configuration from the inside. We show it on whichever process is currently causing friction.