Automating Something That Will Change Anyway

Stability is a selection criterion

We ask how long the process has worked the way it works now. If the answer is less than six months, or if two departments are still arguing about it, we will recommend waiting.

Automating a moving target does not settle the argument. It encodes one side of it in software and makes changing your mind expensive.

Configurable rather than coded

• Thresholds, tolerances and limits editable by your team, not by us
• Business rules in configuration where the rule is likely to move
• Routing and approval chains changeable without a deployment
• New product types, categories or sites added without code

The test we apply: which of these will you plausibly want to change in the next two years? Those go in configuration. Everything else can be code, which is simpler and cheaper.

What a change actually costs

The annual review

We ask, once a year: does this still reflect how you work, is the output still used, what exceptions are being handled manually that could now be automated, and should this still exist at all.

We have recommended switching things off. An automation that no longer matches the business still costs maintenance and still occasionally fails.

The parts we deliberately leave manual

Anything still being argued about, anything with fewer than a handful of instances a week, and anything where the rule genuinely depends on judgement that varies case by case.

Leaving those alone is not incompleteness. It is what keeps the automated part stable enough to trust.

Frequently asked questions