The requirement changed again.

You thought this one was finished.

Monday: orders over £10,000 need a credit check.

Wednesday: make it £7,500. Except for two customer groups.

Friday morning: finance has found another exception.

You know what happens next. Update the specification. Find the developer. Explain it all again. Wait. Test it. Send it back to the business.

And hope they don’t change their mind before lunch.

The requirement isn’t the problem

The business isn’t being difficult. Its rules are meant to change. The problem is where those rules live. Stored in custom tables and ABAP logic, every new requirement becomes a software change. And every software change takes the long road:

Business → Functional consultant → Specification → Developer → Code → Functional consultant → Test → Business

You haven’t finished testing Wednesday’s version, and Friday’s is already on its way.

Move the thing that changes

Control.

The business rules for credit checks move into BRF+. Your program provides all the necessary data and asks one question: does this order need a credit check? BRF+ answers, covering every scenario.

When the business changes its mind, you configure the change, simulate it, and send it through testing and transport. The road gets shorter:

Business ↔ Functional consultant ↔ Rule ↔ Test

The rule sits with you, the person who talks to the business every day. The custom tables and custom code logic disappear. The program stops deciding and starts asking.

You still need a developer. Just not every Wednesday.

Someone still builds what feeds BRF+ and what happens with the answer. And if the business wants to decide on something completely new, requiring information the program has never passed to BRF+ before, that’s a development job.

But moving the threshold from £10,000 to £7,500? That’s yours.

Try it: build a decision table yourself on the Play page.