Building Your Own Reports Without Waiting for IT
The most expensive report in any Kenyan business is the one somebody assembles by hand every month because asking IT takes three weeks. What a report builder removes, and how to avoid the mess that follows when everyone can build one.
Somewhere in your organization a person spends the first two days of every month building a report in a spreadsheet. They export three things, paste them into a template, apply the formulas they have refined over two years, and produce a document everybody relies on. It works, it is accurate, and it exists entirely inside one person's knowledge of where the numbers come from.
That is the most expensive report in the business. Not because of the two days, though those are real — because of what happens when that person is on leave in a month that matters, or resigns, or makes an error nobody can find because the working is in a spreadsheet only they understand.
Why the hand-built report exists
It is never because the person enjoys it. It is because of a queue.
Requesting a report change from IT or a vendor means specifying it, waiting, receiving something slightly wrong, clarifying, and waiting again. Three weeks later there is a report that answers last month's question. Meanwhile the spreadsheet took an afternoon and answers exactly the question asked. Anyone rational chooses the spreadsheet, and then keeps choosing it forever.
Nobody builds a shadow spreadsheet because they prefer it. They build it because the official route takes three weeks and answers a question that has already moved on.
So the value of a report builder is not primarily that it saves the two days. It is that it removes the queue, and with it the reason the shadow report existed in the first place.
What you should be able to do without help
The self-service bar
- Choose the fields you want, not accept a fixed column set somebody decided in advance
- Filter to your own scope — your branch, your customers, your period, your category
- Group and total in a way that matches how you think about the business
- Save it, so tomorrow's version is a click rather than a rebuild
- Share it, so it belongs to the organization rather than to your login
- Schedule it, so the people who act on it receive it without asking
- Export it for the genuine cases where the data needs to go elsewhere
The save-and-share pair matters more than it looks. A report that exists only in one person's session is a spreadsheet with extra steps — the fragility has been moved, not removed. A saved, shared definition is the point at which the report becomes an asset of the business.
The mess to design against
Self-service reporting has a predictable failure of its own, and it arrives about four months in. Everybody builds their own version of the same report, each with slightly different filters, and now two managers arrive at a meeting with different sales figures for the same month. Both are correct. Neither can explain the difference quickly. Confidence in all reporting drops.
This is worth pre-empting, because it is much easier to prevent than to unwind.
-
Name the definitive few
A small set of saved, shared reports that are the official version of each key number. Anybody may build their own view, but disagreements are settled against these.
-
Put the filters in the report name
"Sales — Nairobi branch — excluding internal transfers" cannot be confused with something else. "Sales report v2" can and will be.
-
Give the definitive reports an owner
One person responsible for what the report means and whether its filters are still right. Not a committee.
-
Let personal reports stay personal
Somebody exploring a question does not need governance. The distinction is between exploring and reporting, and only the second needs to be shared and named.
-
Reconcile the two when they diverge
If a personal view disagrees with the definitive one, that is a useful signal — usually a filter assumption worth making explicit rather than an error.
Disagreement is often information
When two reports of the same thing differ, the instinct is to find the wrong one. Frequently neither is wrong — one includes internal transfers, or credit notes, or a branch, and the other does not. That difference is usually a definition the business never made explicit, and surfacing it is worth more than the report that started the argument.
What we do and do not do
What AWRA OpsHub does today
- A report builder — choose fields, filters and grouping without a developer.
- Saved report definitions and saved filters, reusable and stable.
- Sharing, so a report belongs to the business rather than to a session.
- Scheduling on top of a saved definition, to users, roles or external addresses.
- Dashboard pinning for the handful you watch continuously.
- Exports, and a record of what was delivered and when.
- Field-level settings, so what is available can be curated rather than overwhelming.
What it does not do
- No SQL access or query workbench. You compose reports through the builder, not by writing queries.
- No calculated fields of arbitrary complexity — if you need a bespoke derived metric, expect to raise it rather than build it.
- No joining to external data. Operational data only; nothing blended from other systems.
- No chart-design surface — this is tabular and summary reporting, not a visualisation studio.
- No version history on a report definition — an edit changes it for everyone it is shared with.
That last point is worth a habit: when materially changing a shared report, duplicate it and change the copy rather than editing in place, so anybody depending on the original keeps what they had.
Retire the spreadsheet deliberately
The migration that fails is the one where the new report is built and the spreadsheet quietly continues. Both exist, they disagree at the margins, and everybody keeps trusting the spreadsheet because it is the one they know.
Do it properly instead. Build the report, then run both for one period and reconcile them line by line — that reconciliation is where you discover the undocumented adjustments the spreadsheet has been making for two years, which is genuinely valuable knowledge that currently exists nowhere. Once they agree, retire the spreadsheet, tell everyone it is retired, and schedule the new report to the people who received the old one.
Skipping the reconciliation is how organizations end up with two sources of truth indefinitely. The wider picture on which reports are worth having at all is in reporting and BI in Kenya.
Our take
Give people the ability to build their own views — the shadow spreadsheet exists because of a queue, and removing the queue removes the spreadsheet. Then name a small set of definitive shared reports with the filters in their titles and an owner each, so self-service does not turn into two managers arriving at a meeting with different numbers for the same month.
See reports built without a queue
Choose your own fields, filters and grouping, save and share the definition, pin it or schedule it — without waiting on IT or a vendor.
Explore the report builderFrequently asked questions
Can non-technical staff really build their own reports?
Yes — you choose fields, apply filters, group and total, then save the result. There is no SQL and no query workbench, which is deliberate: the aim is removing the three-week queue that causes people to build shadow spreadsheets in the first place. What you cannot do is author arbitrarily complex derived metrics; for those, expect to raise a request rather than build it yourself.
Will self-service reporting create conflicting numbers?
It will if you do not pre-empt it, and this is the characteristic failure — two managers arriving at a meeting with different sales figures for the same month, both correct, differing on whether internal transfers or credit notes are included. Prevent it by naming a small set of definitive shared reports with their filters in the title and a named owner each. Personal exploratory views need no governance; the official version does.
What happens if someone edits a shared report?
It changes for everyone it is shared with, and there is no version history to roll back to. So adopt the habit of duplicating a shared report and editing the copy whenever the change is material, rather than editing in place. This is the one place where the flexibility of self-service can quietly break something somebody else depends on.
How do we replace an existing spreadsheet report?
Build the equivalent report, then run both for one period and reconcile them line by line before switching. That reconciliation is the valuable part — it surfaces the undocumented adjustments the spreadsheet has been making for years, knowledge that currently exists only in one person's head. Once they agree, retire the spreadsheet explicitly and schedule the new report to whoever received the old one. Letting both run is how you end up with two sources of truth permanently.
Can we combine data from other systems?
No — reporting covers your operational data in AWRA and does not join to external sources such as bank feeds, marketing platforms or a separate payroll system. If you need blended reporting across several systems, export from here into a dedicated BI tool and do the joining there. Treat this as excellent operational reporting rather than a data warehouse.
