Programme Statistics, Analytics & Reporting · Technical White Paper
Programme Statistics, Analytics & Reporting
A reference information model for programme reporting — the person-versus-event distinction, the entities required to support it, and the quality controls that structure makes possible.
2 · The modelling decision that matters most
A person and a service event are not the same unit
One person may receive several different services, and one service category may be delivered repeatedly over time.
A system that stores only people served will understate service intensity. A system that stores only services delivered can overstate reach, by counting the same person several times. Neither error is visible in the resulting report, which is what makes it dangerous.
The model therefore requires both a unique-person dimension and a service-interaction fact layer. Everything else in the architecture follows from holding those two things separately.
3 · Reference architecture
Seven entities, and what each is for
Scroll table sideways →
| Entity | Purpose | Illustrative fields |
|---|---|---|
| Service recipient | Represents the person receiving support. | Unique internal identifier; demographic band; region or site; classification fields; consent and privacy controls. |
| Service interaction | Represents a discrete service event or support episode. | Recipient reference; service category; date; duration or quantity; programme; location; responsible user; outcome. |
| Programme / service family | Provides controlled categorisation of what the organisation delivers. | Programme code; service family; subcategory; active status; funding and reporting tag. |
| Region / site | Enables local capture and consolidated reporting. | Region; site; reporting hierarchy; responsible manager; active period. |
| User / role | Defines who may capture, approve, view or administer information. | User; role; region or site; access level; activation status; audit metadata. |
| Reporting period | Supports consistent periodic reporting. | Financial period; month, quarter, year; submission status; close status. |
| Reference taxonomy | Holds the controlled values used by capture forms. | Age band; service type; outcome type; referral type; status; programme classification. |
3.1 · What the structure makes possible
Distinct metrics from one governed dataset
- Unique people served, and total service events, as separate figures.
- Services per person — the intensity measure neither figure gives alone.
- Service mix by demographic group, and geographic distribution.
- Activity by programme, by reporting role, and period on period.
3.2 · And the checks it enables
Quality control that becomes possible once the model is right
- Duplicate people.
- Missing classifications.
- Service events without a valid programme.
- Inactive users entering records.
- Unusually high or low activity volumes.
5 · The reporting layer
Filterable by the dimensions management actually uses
Management reporting had to filter and aggregate by age group, demographic profile, geography, service type, duration and organisational level — because those are the cuts that funding relationships and operational decisions are built on.
The structure also had to be capable of later integration with adjacent enterprise systems, without making those integrations a prerequisite for the first usable reporting environment. That ordering is a commercial decision as much as a technical one: it delivers reporting before integration, instead of delaying both.
16 · Financial governance
The commercial result is procurement and design governance rather than a software discount. The cost envelope was challenged before commitment, the average implementation estimate reduced, and the scope decomposed so that later additions require separate authorisation.
Data cleaning, import and external integrations were explicitly fenced out of the initial contracted scope — the two line items most likely to expand without limit once delivery is underway.
Conclusion
Reporting as an output of daily work
The objective was not a better monthly reporting exercise. It was an architecture in which reporting falls out of controlled capture at source, rather than being reconstructed from spreadsheets after the fact.
That shift is what removes the dependency on individual staff knowledge, the duplicate capture, the reconciliation effort and the reporting delay — none of which was monetised in this engagement, and all of which is the reason the work was commissioned.