A vendor will ask, sooner or later: what should the system be able to do? The answer does not lie with the vendor, and not with a list of features that other companies have also ticked off. The answer lies in your own process: which data points you collect, who supplies them, where they come from, and what goes wrong when no one is watching.
The common route is: select a tool, configure the tool, and only then discover which data needs to come from where. That order works against you, because a tool has no opinion about your process. It asks for input, and that input has to come from something. If that something — the data point register, the ownership, the sources — does not yet exist, configuring the tool becomes a search that no one had planned for.
The other order starts with the process. First map out which data points are needed, who supplies them, from which system or spreadsheet they come, and which quality rules apply to them. Only afterwards does it become clear which requirements a tool actually needs to meet. Not abstract requirements such as "user-friendly" or "scalable", but concrete requirements such as: must connect to this specific source system, must be able to distinguish three owners within a single data point, must flag a deviation when a figure falls outside a predetermined margin.
The order is not a matter of methodological preference; it follows from what functionally precedes the tool. A tool can only be given requirements once there is something to derive requirements from. That something is the process: the flow of data from source to report, with all the manual steps, handovers and assumptions that go along with it. Without that overview, an organisation sets requirements based on what a tool can do, not on what the process needs. That sounds like a subtle difference, but it determines whether the tool will later align with reality or end up standing next to it.
This connects to the question of how you choose a tool without regretting it afterwards: regret often arises not from a bad tool, but from a tool that had to guess at requirements because no one had written them down.
If the tool comes first and the process later, two kinds of costs arise. The first is direct rework: functionality that does not fit, integrations that still need to be built, fields that remain empty because no one knows who is supposed to fill them in. The second cost is less visible but heavier: the tool starts producing reports that look neater, while the figures behind them still cannot be traced back to a source or an owner. This risk is described in more detail on the page about what it costs to place a tool above an unorganised process: the tool hides the problem instead of solving it.
Which order turns out cheaper depends on how many data points, systems and owners already exist and how many of these have not yet been documented. For a small process with few sources, the damage from the reversed order is limited. For a process spread across multiple departments, systems and spreadsheets, that damage grows with every data point that has not been sorted out before the tool asks for it. This trade-off is worked out on the page buy a tool first or set up the process first: what that difference costs.
Before a tool can be given requirements, there needs to be an overview of which data points are needed for the reporting, where each data point comes from, who is responsible for its accuracy, and which rule determines whether a value is plausible. That overview is not a technical document and not a tool in itself; it is a register that forms the basis for every subsequent step, whether that next step is a tool, a manual process, or a combination of both.
The question of which functional requirements follow from that is, in effect, the question: what is in that register, and what is still missing? As long as that question remains unanswered, every requirement placed on a tool stays a guess. This connection between requirements and the underlying process is worked out further on the page about which functional requirements follow from your own process and what a wrong order costs in this regard.
Once the data point register and the ownership are in order, the question shifts from what a tool should be able to do to what happens to the people currently doing this work: collecting, checking and retyping figures from spreadsheets and systems. Part of these tasks is repetitive and follows fixed rules, and that is precisely the kind of work of which a portion can be taken over by AI. The [work scan by FTE TO AI](https://ftetoai.nl) calculates per task which part of it can be automated, making it clear where people remain necessary and where the work can be handed over to a system that checks and supplies according to fixed rules.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.