The decision, not the dataset
Organizations that want data-driven decisions often discover that the hard part is delivery, not storage. Much writing about central data focuses on storing it well. This article looks at the other end: the moment a manager needs an answer. A pricing change, a hiring plan or a stock reorder depends on someone getting the right figures in time. Centralizing data can help that process, or it can turn into a queue.
The quality of a decision depends on four things the data arrangement affects: whether the right data exists, whether the decision-maker can reach it, how quickly it arrives, and whether they trust it enough to act.
What centralization can offer
When data from several systems is brought together and governed centrally, decision-makers can often get an answer that spans functions, such as comparing sales, stock and delivery performance, without assembling it by hand from separate exports. Shared definitions mean the answer is more likely to match what other teams are using. A central team may also have the skills to handle complicated joins, statistics and caveats that a busy manager lacks.
Those benefits are real, but they are conditional. They depend on the central arrangement being usable.
Where bottlenecks form
A central data or analytics team is a limited resource, and demand for its time usually grows faster than its headcount. Typical symptoms include:
- A request queue measured in weeks, so decisions are made without data or are delayed.
- Requests for small variations on an existing report taking as long as new ones.
- Business users unable to explain what they need, leading to repeated rounds of clarification.
- The team spending most of its time on routine requests, leaving little for improvement.
- Teams building private spreadsheets in parallel because it is quicker, which recreates the conflicting-versions problem the central approach was meant to solve.
Often the root cause is design: every question has to pass through a few people because there is no other route to the data.
Who gets access, and at what level
One way to ease the queue is to separate the kinds of access people need. A simple model has tiers:
- Standard reports and dashboards for common questions, available to many people without raising a request.
- Self-service exploration of curated, well-described data sets, for users who can filter and group data themselves.
- Analyst support for new or complex questions, handled by the central team.
- Raw or sensitive data, restricted to those with a clear need and appropriate approval.
Moving routine questions down to the first two tiers frees the central team for the work that needs its skills. The trade-off is that self-service reporting carries its own risks, notably misreading data or producing figures that quietly differ from official ones, so it works best with clear descriptions, certified data sets and some training.
Access decisions should follow written policy and the least privilege principle, with a defined route for exceptions. If sensitive data is involved, such as personal information, the rules should be agreed with the relevant owners and with qualified privacy and legal advisers.
Speed and service expectations
It helps to treat internal data requests as a service with stated expectations. Without making up targets for any particular business, a team might publish:
- how requests are submitted and prioritised;
- a rough turnaround range for each type of request;
- which requests it will not handle and where to go instead;
- how urgent, time-critical requests are treated.
Tracking the actual time from request to answer, and the share of requests that are repeats, shows whether the bottleneck is real and where it sits. These can be simple counts and averages; they do not need a sophisticated system.
Trust in the numbers
Fast data that people doubt does not support decisions. Ways to build trust include:
- showing the source and the last refresh time on every report;
- publishing definitions so users can see how a figure is calculated;
- having a clear process for challenging a number and a named person to respond;
- being honest about uncertainty, such as incomplete data for the most recent period.
It is also worth remembering that data informs decisions without making them. Data is always incomplete, historical and shaped by what was measured. Judgment, context and knowledge of the situation still count, and an over-reliance on whatever is easiest to measure can skew choices. A central team can help by flagging limits and not only supplying figures.
Keeping decisions close to the people who make them
Where decision-making is spread across regions or business units, forcing every analytical question through the centre can slow reaction time. A hybrid arrangement is common: a central team provides platforms, governed core data and standards, while embedded analysts in business units answer local questions using that foundation. Such an arrangement keeps definitions consistent and puts analytical capacity near the decisions. It requires coordination so that embedded analysts do not drift into their own conflicting definitions.
Questions worth asking
- How long does it take for a typical manager to get an answer, and how long would be acceptable?
- Which requests recur often enough to become a standard report?
- Who can currently see what, and does that match what they need?
- Do people trust the central figures, and if not, why?
- Is the central team a help or a gate?
The aim is not to centralize for its own sake but to make good information easy to reach by the people deciding. If centralizing data slows them down, the design, not the principle, usually needs adjusting. This article is general information.