The technology is rarely the bottleneck

When a new internal system goes unused, the post-mortem usually blames the software. The interface was clumsy, the reports were slow, the integration was incomplete. Sometimes that is true. More often, the software did what it was asked to do, and the people it was built for had no reason to use it.

Every system that depends on human input runs on three things that are not technical: who benefits from the data being correct, who is accountable when it is not, and how easy it is to enter the data at the moment the work happens. Get those right and a modest tool will be used every day. Get them wrong and the best software available will be filled with blanks and guesses.

The person entering the data must get something back

Look at who types information into the system and who reads it. In many businesses they are different people. A sales representative logs calls so that a manager can see a pipeline. A supervisor records downtime so that a plant head can see a report. The person doing the work carries the cost, and someone else collects the value.

That arrangement is fragile. People will comply while they are watched and drift when they are not. The fix is to design the system so that the person entering the data gets something useful in return, immediately. A technician who logs a fault should see the history of that machine. A salesperson who records a meeting should get a prepared follow-up. If you cannot find a direct benefit for the person at the keyboard, expect the data to decay.

Ownership has to be real, not nominal

Most organisations can name a system owner. Fewer can name someone who actually loses something when the data is wrong. Real ownership means a role whose decisions depend on the system, who notices gaps, and who has the authority to change how people work. If the owner can only send reminder emails, the system has a sponsor, not an owner.

A useful test: if the system went offline for a week, who would notice first, and what would they be unable to do? If the honest answer is nobody, the system is not yet part of how the business runs, however well it was built.

If a system went offline for a week and nobody noticed, it was never part of the business.

Data entry habits beat data models

Teams often spend weeks designing fields, categories and validation rules, and very little time watching when and where the information is actually known. Data gets entered accurately when it is entered at the moment and place the work happens, by the person who did it, with as few steps as possible. Every extra minute between the event and the entry adds forgetting, rounding and invention.

This is why end-of-shift forms and end-of-week updates produce poor data. By then, people are reconstructing from memory. It is also why a form with twenty fields will have three filled in carefully and the rest filled in with whatever clears the validation. Before adding a field, ask who knows this value, when they know it, and whether it can be captured automatically instead.

Design the incentives before the software

In practice, this means doing some work before any code is written:

• Map every piece of data the system needs to the person who first knows it and the moment they know it.
• For each of those people, write down what they get back from entering it. If the answer is nothing, redesign until it is something.
• Name the owner, and confirm that their own decisions or targets depend on the system being correct.
• Remove any field that nobody will act on. Every field is a small tax on the person entering it.
• Prefer capturing data from the work itself (a scan, a sensor, a status change) over asking someone to report it afterwards.
• Retire the old path. If the spreadsheet still works, people will keep using it.

Watch for the quiet signs of rejection

People rarely refuse a new system openly. They route around it. Watch for records that are all entered at the end of the day in a single burst, default values that are never changed, free-text fields used to explain what the structured fields could not hold, and parallel spreadsheets that reappear in meetings. Each of these tells you where the design does not fit the work.

Treat these signals as design input rather than discipline problems. If supervisors are batch-entering at the end of the shift, the entry point is probably in the wrong place. If a free-text field is overflowing, the categories are probably wrong. Adjust the system, then look again.

Where technology does matter

None of this means technology is irrelevant. Speed matters: a screen that takes several seconds to load will be avoided on a busy floor. Reliability matters: one lost entry can undo months of trust. And the ability to change the system quickly matters most of all, because the first design of the incentives will be partly wrong. A system that is cheap to adjust lets you fix the human side as you learn it.

The order of work is what counts. Decide who benefits, who owns and how data is captured at the source. Then choose the technology that makes those decisions easy to live with. Done the other way round, you end up with a well-engineered system that describes a business that does not exist.