top of page

Data Entry Team not Users


Error between keyboard and screen

A big source of poor data quality is data entry. A stubborn issue that is hard to address. Why is that? While there are many mechanisms and types of errors I would argue that the main obstacle to solving all of them is a fundamental flaw in the way we approach the users of our systems.

Though it may not be their official role, from the perspective of data analytics and reporting we need to recognize that our business users are not so much users of the system as they are our data entry team. It may seem like an insignificant change, but that inclusive point of view can make a big difference.

First off, let me define "we". I am making the assumption that your organization has technical and analytics teams separate from your business users: the "we". I further assume that you have some relatively non-technical front line staff that use transactional systems of some kind to manually enter data.

The model I personally have in mind is one from my recent past: a k-12 public school district with school based staff (teachers, registrars, attendance counselors, etc) entering data about students into various student information systems.

Within IT there is unfortunately an all too common tendency to blame the users. "Error between keyboard and screen", "luser", etc. The condescension can be brutal or subtle, but the common attitude is that the system needs to be protected from the users.

This is a very human reaction: once we become experts in something we forget what it was like when we were not. Accordingly, the way to combat this needs to take into account the way humans behave as well.

We are all still cavemen

Think about it this way: humans are fundamentally social creatures. Our neolithic ancestors banded together to protect themselves from the environment but also from other humans. We naturally form teams aligned against the other.

By treating our system users as the other, we mentally close off from collaboration. But once we see them as our de facto "data entry team" they are brought into the fold. And the mentality goes from protecting our data system from them to working in tandem with them to ensure we get fewer data entry errors. Instead of the the dynamic being two opposing energies, we harness energies from both groups to work harmoniously towards data effectiveness.

The job of our business folks is not to use the system, the job of the system is to support our business folks so treating them as our data entry team doesn't mean taking an authoritarian "thou shalt" view. But rather realizing that the better they are able to do their data entry task, the more our team wins.

The key difference is that with the team mindset we more easily fall into compromise. We would not get far by just demanding our team-mates do things. We work with them, giving a little and taking a little so that the overall goal is achieved. We work with our team members, we work against our enemies.

Explain, don't dictate

What does this look like in practice? A good example is rather than mandating rules and directives from on high, walk your data entry team through specific examples of how data entry errors propagate through to end reports.

In my old position schools would often complain that the reports we gave them were "not correct". But that was almost always due to some quick and dirty workaround they did in the main student information system (eg changing the enrollment date of the previous year's admission record when a child enrolls for the new school year instead of entering in a new admission record).

When we walked them through the data pipeline showing how *that* specific data entry error resulted in *this* specific reporting inaccuracy, you could see the light go on. People are usually trying to do a good job and when they realized that what they thought was an innocuous workaround was really creating problems in reports, the frequency of that error went down.

No tool, no front-end validation or back end error checking is going to solve the problem more effectively than buy-in from your data-entry team. Build a culture of data quality. Engage minds and the rest will follow.


Featured Posts
Recent Posts
Archive
Search By Tags
No tags yet.
Follow Us
  • LinkedIn Social Icon
  • Twitter Basic Square
bottom of page