Counting the hours
that go into moving
data by hand.
Count every hour a week your team spends exporting, reconciling, retyping and rebuilding the same report, across the whole team rather than per person, then multiply by 48 working weeks. The result is an estimate rather than a measurement, and its value is not precision. It is that asking the same question again after a change gives you a number you can compare with this one.
What counts
The test is simple: if a person is the connector between two systems, that is manual data movement. It counts whether or not anyone calls it a task, and most of it is not on anybody's job description.
- Exporting from one system so it can be loaded into another.
- Reconciling two systems that disagree, and deciding which one is right.
- Retyping numbers a machine already produced.
- Rebuilding the same report every month, from the same sources, by hand.
- Chasing the person who holds the file, which is usually the largest hidden component and the one people forget to count.
What does not count: analysis, deciding what to do about a number, or writing the commentary around it. That work is the point of having the numbers. Moving the numbers is not.
Count across the team, not per person
The usual mistake is to answer for yourself. The figure that matters is the whole team's, because manual data movement is distributed by design: fifteen minutes here, an afternoon there, one person who has quietly become the integration layer between two systems that were never connected.
Asked per person the answer is always small enough to ignore. Asked across a team it is usually the largest recurring cost nobody has a line item for.
The arithmetic
| Answer band | Hours per week used | Hours a year |
|---|---|---|
| Under 5 | 3 | 144 |
| 5 to 15 | 10 | 480 |
| 15 to 40 | 27 | 1,296 |
| More than 40 | 50 | 2,400 |
Each band maps to a single figure near its lower half rather than its midpoint, which is deliberate: a band answered honestly tends to be answered optimistically, and a model that rounds upward would be arguing its own case.
Why 48 weeks and not 52
Shutdowns, maintenance windows and holidays. Using 52 inflates every figure by about eight per cent for no reason, and the first person to notice will be the one you most needed to convince.
Why an estimate is the right instrument here
Nobody has this number. It is not in a timesheet, because the work is spread across people who are doing something else, and instrumenting it properly would cost more than the answer is worth at this stage.
So the honest position is that this is what the person closest to it believes, recorded as such. Two things follow. It should be answered by somebody who works with the systems in question rather than by whoever opened the page, which is a distinction the diagnostic makes explicitly. And it should be written down before anything changes, because its whole value is comparative.
What to do with the number
Start with the report that gets rebuilt every month. It is usually the cheapest thing to remove and the easiest to prove, and it doubles as a map: a recurring manual report tells you exactly which systems people are already reconciling by hand, which is the same list as the connections worth building first.
What the recovered time is for is the part worth being careful about. The useful outcome is not a smaller team. It is that the same team absorbs more without the reporting load growing in proportion, and that people who know the process spend their time on it rather than on moving numbers between systems that should be talking to each other.
What this number is not good for
- It is not a benchmark. We publish no distribution to compare yours against, because we do not have one.
- It is not a business case on its own. Hours are not money until somebody who knows the loaded cost of those hours says so, and that is your arithmetic rather than ours.
- It is not evidence about your plant that we could have produced. Nobody outside your plant can tell you this figure. That is the whole reason it is asked rather than inferred.
The band-to-hours mapping and the 48 week convention are reasoned judgements. Neither is calibrated against observed data.
The diagnostic has been completed three times in total, and all three were our own runs while building and checking it. No outside respondent has completed it yet, so we hold no distribution, publish no benchmark, and make no claim about what a typical plant answers.
If your own count disagrees with the band you selected, trust your count. The bands exist to make the question answerable in a few seconds, not to overrule somebody who has actually added it up.
Put a number on it
Twelve questions about how your systems, machines and registers actually hold information. No signup. You get a fragmentation score, the annual hours estimate, and the three things worth fixing first.
Your answers and your score are recorded when the report renders on your screen, which happens before any email is asked for. The page says so before the first question.
Take the diagnostic