MELLORCATalk to Mellorca
Patterns

Data, Reporting & Management Visibility

The Signs That Your Reporting Model Has Become a Bottleneck

A single report builder is efficient until the questions multiply. Here are the signs that the way reports are owned and changed has become the limit, and the structure that relieves it.

Mellorca Patterns2026-10-10

Observable condition

There is a list. It lives in an email folder, a shared spreadsheet or the head of the person who looks after reporting, and it is called something like "report requests". It contains a new column for the sales team, a change to the way stock is valued, a regional split for the Eastern Cape, and a request from the directors to show the same figures by customer segment. Some items are a month old. Every one of them is reasonable, and the person responsible is working hard, but the list grows faster than it shrinks.

Meanwhile the rest of the business has adapted. Managers who cannot wait build their own spreadsheets from exports. Department heads ask for "just a quick extract". The official reports continue to be produced on time, but they are no longer where decisions are made.

An illustrative example: a Bloemfontein agricultural-equipment dealer with five branches. All reporting passes through one finance analyst who maintains the master workbook. A request to add warranty claims to the branch view has been waiting since the previous quarter, and at least three branch managers now maintain their own versions of the same view.

Realisation

A reporting arrangement that served a business well at one stage can become the limiting factor at the next, without anything having gone wrong. When there were two managers and one branch, a single person building every report was efficient: nothing was duplicated and everything was consistent. As the number of questions grows, that same arrangement turns into a queue, and the queue sets the speed at which the whole business can learn about itself.

The costly part is that the bottleneck is almost invisible. The reports are delivered. The analyst is competent and busy. Requests are acknowledged. The loss is in the questions that are not asked, the decisions made without the data and the parallel reporting that grows around the official channel. None of these show up as a line in any budget.

Identification

This is a reporting-capacity constraint: the structure for producing and changing reports, including who builds them, who owns the data and how changes are made, has stopped matching the volume and variety of questions. It is different from waiting for an individual answer, which looks at the delay of one question, and from only one person knowing where the numbers come from, which focuses on key-person risk. This Pattern asks a wider question: has the whole model for creating and maintaining reports reached its limit?

The visible symptom is a backlog and a proliferation of unofficial reports. The common assumption is that the reporting person needs help or that the team needs a better tool. The structural cause is the operating model itself, in which every change has to pass through one narrow point.

Diagnosis

Look for the following signs. Having three or four of them is a strong indication.

  • A request backlog with no visible priority. Items remain open for weeks, and nobody can say which will be done next or why.
  • Shadow reports. Managers maintain private versions of figures that the official report is supposed to supply. Microsoft's adoption guidance draws a useful line here: governed business-led self-service, where a business unit has the authority and support to build its own content, is not the same as unsanctioned workarounds built to get around a team that cannot keep pace.
  • Every change needs the same person. Adding a field, a filter or a period requires reopening a file only one person understands.
  • The monthly cycle has crowded out everything else. The reporting person spends most of each month producing the standard pack and has little time left for improvements.
  • New questions arrive from new places. Marketing, operations, HR and branch managers now want figures, not just finance.
  • The same data is prepared repeatedly. Each new report starts again from raw exports, because the cleaned data is not saved in a form that others can reuse.
  • Nobody can say who owns what. When asked who is responsible for a given report or measure, the answers differ.

Microsoft describes three broad ways of owning and managing reporting content: business-led self-service, in which each business unit owns and manages everything; managed self-service, in which a central team owns the data while business users build their own reports on it; and enterprise, in which a central team owns everything. Each suits different conditions. The enterprise model suits sensitive or tightly regulated data and well-defined needs. It struggles when the volume and variety of requests grow beyond what the central team can handle. The guidance explicitly recommends considering a managed self-service approach where the central team has scheduling and priority challenges.

The guidance also stresses role clarity: who defines what the data means, who maintains it technically, and who makes decisions about its appropriate use. Where those roles are unnamed, requests default to whoever is nearest.

Commercial impact

The commercial value at stake is productivity, speed, scalability and cost.

Productivity is lost in two places: the reporting specialist is consumed by routine production, and managers spend their own time building workarounds. Speed is affected by the queue. Scalability is limited because each new branch, product line or manager adds to the demand without adding capacity. Cost appears as the opportunity cost of skilled people, and as the cost of the duplication that grows around the bottleneck. The labour of recurring report production is quantified further in rebuilding recurring reports by hand.

Common misidentification

The most common reaction is to add another analyst. This helps for a while, but if the model stays the same, the queue and the dependency return at a larger scale.

The second is to open everything up with no governance. Anyone can build anything, and within months the business has many models that disagree. Microsoft's guidance warns that a high ratio of models to reports signals poor reuse, and that discrepancies between reports cause distrust. Self-service without shared, reliable data simply moves the problem to a different place; see why teams spend more time preparing reports than using them.

A third is to expect the next system to solve it. A new tool changes how reports are built, not who owns them or how requests are prioritised.

Possibility

In a better arrangement, the core data is prepared once, by a small central function that is responsible for its quality and definitions. Business users build and adjust their own views on top of it, within clear guardrails. The central function concentrates on what only it can do: connecting sources, keeping the data reliable and maintaining the small set of reports that the whole business depends on. Content that has been checked is marked as such, in the way that Microsoft's endorsement feature distinguishes promoted content that someone finds useful from certified content that meets an organisation's quality standards.

For the equipment dealer, branch managers would add warranty claims to their own views from shared data, and the analyst would be freed to improve data quality and reconcile the branches rather than act as a switchboard.

Intervention

  1. Count the demand. List open requests, their age and who asked. Add the unofficial reports that exist because the official ones were too slow.
  2. Sort requests by type. Some are about data (a new source), some about definitions, and some about presentation. The last category rarely needs a specialist.
  3. Name the roles. Decide who owns the data, who defines the measures and who builds the standard reports.
  4. Prepare the shared data once. Clean and combine the main entities, such as customers, products, branches and dates, in one place that reports can reuse.
  5. Delegate the last mile. Allow trained managers to build their own views on the shared data, with a simple way to mark which reports have been checked.
  6. Prioritise what remains. Agree a visible order for central requests, based on the decisions they support.
  7. Review quarterly. Check whether the backlog is falling and shadow reports are being retired.

Diagnostic questions

  • How many reporting requests are open, and how old is the oldest?
  • How many unofficial versions of a management report exist in the business?
  • Could anyone besides the reporting owner make a simple change to a standard report?
  • Who decides which request is done first, and on what basis?
  • What proportion of your reporting person's month is routine production, and what is improvement?

Bottom line

A reporting model that once protected consistency can become the narrowest point in the business. Moving to shared, well-governed data with distributed building lets the number of questions grow without growing the queue.

Sources and further reading

Related Mellorca reading

Article summaryA single report builder is efficient until the questions multiply. Here are the signs that the way reports are owned and changed has become the limit, and the structure that relieves it.
Explore our solutionsStart a conversation