Kennisbank

Choosing a tool without regret starts with the order

The question asked too soon

Anyone who wants to choose a tool usually asks the wrong question first. Not "which tool suits us", but "what does that tool actually need to be able to do, given how our data currently flows". That second answer often does not yet exist at the moment the first question is asked. There is then a list of vendors, a few demos, perhaps an advisory report on market leaders. There is no answer to the question of which data point comes from which system, who is responsible for it, and what quality rules should apply to it.

The order that prevents regret is easy to formulate and hard to follow, because the pressure to buy something is usually greater than the calm needed to take stock first. First the data point register, the lineage from source to reporting, the ownership per data point. Only then the tool, and then as an answer to requirements that follow from that register. Which functional requirements come from your own process is therefore not a question that a vendor answers for you, but a question you must already have answered before you speak to a vendor.

What the reverse order costs

A tool that is bought before the process is in place gets configured on assumptions. The vendor's implementation team asks about data flows that nobody can precisely reconstruct, and the answer is then filled in based on what is probably correct. Those assumptions do not disappear, they become part of the configuration. The result is a tool that works, in the sense that it produces reports, but those reports rest on the same loose ends as before — now only hidden behind an interface that inspires confidence.

The costs of that reverse order are not just the license. It is the time it takes to discover, a year later, that a key figure has been built up incorrectly, and to sort that out in a system that was not built to make that sorting-out easier. What a tool costs on top of an unorganised process depends on how many data points there are, how many systems are involved and how long it goes unnoticed — but the cost item is real, even if it only becomes visible late.

Why this is not a matter of preference

It is tempting to see the order as a matter of approach, where one organisation prefers to test a tool first and another prefers to sort things out first. It is not. A tool can only fill in functional requirements properly if those requirements exist before the tool is chosen. Without a data point register there are no requirements, only wishes — faster, clearer, less Excel. Wishes are not selection criteria, they are mood boards. A vendor that meets mood boards meets something other than what the organisation will need six months later.

Buying a tool first or setting up the process first is therefore not a question with two equally valid answers. It is a question with an order determined by the nature of the problem: data that has not been mapped cannot be handed to a package as a requirement. That applies to every organisation, regardless of sector or size, although the scale of the sorting-out work differs. At an organisation where the sustainability data in construction is spread across project administrations, subcontractors and loose spreadsheets, that sorting-out work is greater than at an organisation with a few central systems. But the order does not change: first see where the data sits and who is responsible for it, only then a tool that fits that.

Regret is usually postponement, not a wrong choice

Regret after buying a tool is often described as a wrong choice between vendors. Usually it is something else: it is the regret of an organisation that has relocated a problem instead of solving it. The tool works exactly as bought, and that is the problem — it works based on a configuration that was never tested against the actual data flows. How you choose a tool without regret then does not depend on a longer shortlist or a more extensive demo process, but on the answer to a question that precedes the purchase: is there a register of data points, lineage and ownership against which the tool can be tested. Without that register, every choice is a gamble in a nice jacket.

The bridge to the work itself

Choosing a tool based on a well-organised process is one step. The other step is knowing which part of the work within it must still be done by people and which part can be taken over by automation, without the reliability of the figures suffering as a result. That question lies outside the scope of a data point register, but it does follow logically from it: only once it is clear what the tasks are — collecting data, validating, tracing back to the source, reporting — can it be determined per task which part of it can be left to AI. The werkscan of FTE TO AI calculates that per task, as the next step once the data and the process are in order.