We want our software solution to be as flexible as possible.
It’s a request we hear in almost every project. And it’s a completely understandable need. In today’s fast-paced world, businesses need systems that can adapt to new suppliers, new products, and new processes without a complete overhaul. But there’s a paradox: sometimes, the most technically flexible solutions feel surprisingly rigid in practice.
This is the story of how a solution evolved from being technically clever to truly user-empowering, and what we learned about flexibility along the way.
The challenge: taming data chaos
Our journey began with a common business challenge. A client needed to automatically import product data from their many suppliers directly into their internal ERP (Enterprise Resource Planning) system. The problem was that the ERP system was highly structured and demanding, while the data coming from suppliers was anything but.
Each supplier had its own way of describing things. One might label a shoe color “NET BRUNTH,” while another used a different term in another language. The ERP, however, required a precise, consistent value.
To make matters even more difficult, suppliers would regularly create new values for characteristics like color or material, and the business team needed to be able to map these new values on the fly.
The first step: a “universal translator”
The initial solution was technically elegant. A system was designed to act as a “universal translator” using what we called “reference data”.
The idea was simple: the business could map a supplier’s unique value (e.g., “Cognac”) to a standardised internal value (e.g., “44-Cognac”), which could then be mapped to the required value in the ERP system (“44”).
This worked beautifully for managing product characteristics. The business team was no longer dependent on IT to handle new colors or styles. The problem seemed to be solved. But in fixing one challenge, we soon uncovered another, deeper one.
The hidden bottleneck
The new problem wasn’t about product data, but about the suppliers themselves. The names the business team used to refer to their suppliers were not the same as the technical IDs used in the ERP system. This relationship – linking the business name to the ERP name – had been configured directly in the software’s code.
This meant that every time the company wanted to onboard a new supplier, a developer had to step in. They had to open up the code, add a few new lines, run regression tests, and deploy an update.
From the client’s perspective, the “flexible” solution suddenly felt very rigid. A straightforward business task – adding a new partner – had become a technical project, creating delays and frustration. It was a classic case of a solution being dependent on a less optimal system it was connected to.
Redemption: moving from code to control
It became clear that true flexibility meant removing this final dependency. We needed to give the business team control over not just the product data, but the supplier configuration as well.
The answer? We had to create a new, dedicated database that was nothing more than a simple configuration table. This table linked the business supplier name, the supplier’s ID in the ERP system, and a few other useful settings.
With this change, the entire process was transformed. To onboard a new supplier, the business team simply had to add a new entry into a UI. No code change was needed, no developer intervention was required, and no lengthy testing cycle was triggered. Redemption had arrived.
The real meaning of “flexible”
Creating truly flexible solutions is a journey. As developers, it’s impossible to know or predict every scenario or future need at the start of a project. An implementation that seems perfect at first can suffer when faced with unexpected real-world problems.
This experience taught us a valuable lesson.
True flexibility isn’t just about sophisticated code; it’s about empowering people.
A system is only as dynamic as the users who operate it. The goal should always be to provide solutions where the people on the front lines have the autonomy to do their jobs effectively. By being willing to refactor, rethink, and rebuild, any challenge can be tackled, and any system can be made truly flexible.
