Current State
This page describes how the work is done today. It is context, not the source of the design. The design comes from the law, from policy and from the nature of the work. What is here serves as a check on it. A large, expensive piece of software, laboured over by hundreds of capable and well-meaning people, can still fail the organizations it serves, and the reason usually lies in what it leaves out: what it ignores, and what it pushes outside itself. A replacement must not do the same.
What the SDPR procedures are
Every recurring task a caseworker does has a written procedure: what starts it, which screens to open, which form to send, what to type in which field. Together they run to 8.2 million characters. They describe the service as staff really deliver it.
Each one carries a header naming its purpose, the policy it carries out, the law behind it, and how the system classifies the work. That turns the whole set into a map of the services.
Work crosses system boundaries constantly
63% of documented procedures need two or more systems to finish one task.
| Systems | Procedures | Proportion |
|---|---|---|
| 0 | 39 | |
| 1 | 80 | |
| 2 | 114 | |
| 3 | 51 | |
| 4+ | 42 |
Highlighted rows are the 207 procedures that cross a system boundary. Four procedures require seven.
One journey, three systems, two re-keys
Recovering an overpayment is the clearest example. A worker who has decided someone was paid too much has to:
- Open a separate web application to calculate the amount. It does not connect to either system of record.
- Print the result, scan it, and attach it back to the case.
- Move the case file to their own office in the mainframe so they have permission to act on it.
- Type the amount into the mainframe by hand.
- Move the case file back to where it came from.
Clients whose earnings are annualised need one step more: a spreadsheet. The worker reads figures off one screen, types them into the sheet, and types the result back.
None of this is anyone's poor practice. The procedure says to do it this way, because with the systems that exist this is the right way.
Where the rules actually live
A modernisation has to know what it is replacing. The rules that decide entitlement sit in six separate places. Only one of them is a rules engine, and the one that carries authority, the policy manual, can only be read by a person.
| Where | What it holds |
|---|---|
| A rules engine | 29 separate rulebases covering eligibility, validation, debt and payment calculation |
| The mainframe | Benefit calculation, rate recalculation, time limits, sanction end dates |
| Formulas inside the case system | Retention periods, access levels, privacy calculations |
| A database table | The rates the public-facing eligibility estimator uses |
| Spreadsheets on SharePoint | Eighteen workbooks with no version control or audit trail. Five of them decide entitlement |
| The policy manual | The authoritative rules, dated in prose, with only a partial archive |
Routing runs on a spreadsheet
An Excel workbook decides which queue a request joins, how urgent it is, how long it has, and where a scanned document goes. Fifty-six procedures point at it. One of its sheets maps 445 form numbers to their handling. So the priorities and service-level targets for the whole service sit outside the platform, kept up by hand.
Accommodation and the signature problem
There is a path for applicants who need an interpreter, find reading difficult, or have little access to a computer. A worker reads the questions aloud and enters the answers for them.
That path skips portal registration, so the applicant never gets a personal identification number. The electronic signature depends on that number. So the people the accommodation exists for are the people who then cannot sign electronically.
How these figures were produced
The counts come from reading the Resource Finder and the other document stores in full, then pattern-matching and mapping the text. Named systems, capability areas and the policy behind each procedure come from the documents and the policy manual.
Nobody has measured the volumes yet. You can count caseload throughput, worker streams, transaction rates and queue depth directly. The figures here come from the technical design documents instead.
The rest of the site sets out the design. It is worked out from the law, policy and the nature of the work, and the conditions on this page check it rather than shape it. Start with evidence. The overpayment journey above is what happens when a record cannot say what the ministry knew, or when.