Full Version: data entry errors-people don't read from the screen what they en
UtterAccess Forums > Microsoft® Access > Access Forms
I have a question about quality control, but not know where to ask. I hope, actually, I always get help from here.
My data entry people told me they don't read or look at the interface when they enter data. They just read the hard copy, and strike the keys. But the problems are they always type wrong things or use wrong keys. They talk to each other while typing. You can see it easy to get mistakes without realization. For example, they should enter 2.03, but they just enter 203, not knowing that by just a glance. Sometimes they enter the year like 255, etc.
Odesign an interface to fix the problems by comparing what difference with twice entry. But still need to read or look at the screen. If they change something here, and still wrong, I can not detect that.
Do you know if this just a way for the data entry technicians working? Do you have any idea how to solve this problem. In my project, the data accuracy is very important.
Do you have any suggestions or good ideas to help improve the quality of entry?
Thanks a lot for your kind support!
Why not use data validation?
ach field in an Access table can be set up to validate the data entered.
Yes, I used data validation. But not all can be controled. For example, both ABC and BAC are allowed to enter, if they enter BAC which should be ABC, it will not triggar the validation.
This has always been a problem. For data entry to be as rapid as possible, the data entry personnel need to keep their hands on the keyboard. However, for data entry to be as accurate as possible, the data entry personnel can make really good use of combo boxes, date controls, etc., all the nifty GUI stuff that is available now.
It has always seemed to me that making the screen as much like the paper form as possible is the best way to do this. That way the user won't have to look at the screen, he just presses tab to move to the next control and keeps on typing.
There's only so much you can do along these lines anyway.
If that's the sort of error you will be trying to eliminate then I think you're out of luck.
How would you cater for the hundreds/thousands/millions of possible errors that could occur?
Thank you, guys!
Actually, I don't care so much how fast they will enter, we have enough people to finish the work. I am more concerned the accuracy.
So, in real world, I can not require them seeing the screen? And I also can not say anything about concentration. since this work is really boring, they need to talk?
Just like Frank said, they just press tab and continue.
Sometimes, it is so frustrated. Since they will enter the wrong line. All of them correct, but just in wrong place. Till we made analysis then the problems caught, but only for obvious ones. I just a kind of scared how much potential errors.
I'm gonna jump in here. This is not a database issue but a performance/productivity one. You can lead a horse to water but you can't make him drink. But if he won't drink you send him someplace else.
hese people are being paid to perform a task. You need to set some reasonable productivity standards (i.e. 10 records per hour at 90% accuracy). If they can't meet some reasonable standards then replace them. the excuse that the work is boring so they need to do something to occupy them is ridiculous.
Its definitely part of the job of the developer to make data entry as quick and easy as possible. But once that has been done, its up to the data entry person to accurately and quickly enter the data.
I've worked in this sort of environment many times.
The way this sort of thing was handled was through quality checking.
You would have some people inputting the data, then others checking it.
Each person would alternate between the 2 tasks at different times.
Any errors would be noted and then fixed.
Also you could do analysis to find out how many errors were made.
Thank you, Scott. Sometimes I just don't know how to handle it.
i, Norie,
I am curious how do you do with quality checking? Print out and compare with the hard copy or just compare what displayed on the screen with the hard copy?
Just compare the hard copy to what's been input.
em, maybe it is a way to train them to look at the screen.
once printed the table, and ask them to check with the hard copy. But they still failed to catch the errors. Even they did not find some records missing.
I think the best way is what you posted earlier. Enter each batch of data TWICE then compare them for differences. It might take longer, but GIGO.
This is a "lo-fi" version of UA. To view the full version with more information, formatting and images, please click here.