The year-two test
A system that works on day one and a system that holds up a year later are two different things. The difference is usually decided before anyone writes a line of code.
Most systems are judged on the wrong day. They get judged on the day they launch, when everyone who built them is still in the room, everyone who uses them has just been trained, and every field still means what it meant in the meeting where it was agreed.
The real test comes about a year later. Someone asks a question about something that happened eight months ago. The person who entered the record has moved on. The person asking was not there. And the only thing standing between a clear answer and an expensive guess is whatever the system happened to capture at the time.
The three questions
Before designing anything, there are three questions worth answering about the process as it exists today.
What does the record actually show? Not what people believe it shows. What a stranger reading it cold, with no context and no access to the people involved, would be able to establish.
What is missing from it? Usually the answer is time, sequence, and who decided. Processes tend to capture the outcome and lose the path. The outcome is rarely the part that gets questioned.
Would it survive being asked about? This is the one people skip, and it is the one that matters. A record that cannot be defended is not a record, it is a note.
Why paper and spreadsheets fail here
They do not fail because they are old. They fail because they have no memory of themselves.
A spreadsheet shows you the current state. It does not show you that a figure was changed on a Tuesday, by whom, or what it said before. A paper form captures a moment and then sits in a drawer with no relationship to the form filed the week before. Both work well right up until the moment someone needs to reconstruct what happened, which is precisely when you need them most.
This is not an argument that every organisation needs software. Plenty of processes are fine as they are. It is an argument that the decision should be made deliberately, based on whether the process will ever have to answer for itself.
What holds up
Systems that pass the year-two test tend to share a few unglamorous things.
- Every change is additive. Nothing is overwritten, it is superseded, and the previous version remains readable.
- Every entry carries who and when, captured automatically rather than typed.
- The fields are the same every time, so two records from different months can actually be compared.
- Someone unfamiliar with the process can read a record and understand what happened without asking anyone.
None of that is technically difficult. It is mostly a question of deciding, early and on purpose, that the record has a job to do beyond the day it was created.
The organisations that get this right are rarely the ones with the biggest budgets. They are the ones that asked the awkward question before they started building, rather than a year later when somebody finally asked it for them.