How to reduce data entry errors?

[Frank Whittemore]

I'm old enough to remember central keypunching and key verifying by a
second person.

I'm curious. What are you doing today to reduce data entry errors
where programmed reasonableness checks can not detect all the errors?
Are some of you still requiring a second person to key the data in and
verifying it against what the first person has keyed in?

I've been under the impression that data verification needs dropped
dramatically when end users started entering their own data rather
than sending it to be centrally keypunched. However, if the data is
critical enough are some of you still doing something to require that
the data be entered by a second person and then comparing it to what
the first person entered? Final question – what else are you doing
to reduce data entry errors?

[mike]

I remember those days too!

Real accuracy is labor intensive and can only be justified when errors can
be PROVEN to be much more costly. Users just do not believe how many errors
they make - usually > 5% or how expensive correction after the fact is for a
business.

Numeric data usually falls into two categories.

1) If you can control all the data values, e.g., customer numbers, serial
numbers, account numbers, product model numbers, ... ; you can embed a
modulus 10 or 11 check digit into the data and validate it on entry. This
will reduce the error rate by 90%.

2) If you do not control the data values, e.g., some other company's
product ID, dates, money, patient weight, ... ; use batch totals. This
is possible even when data is entered in real time as received. When a user
starts a session, create a unique batch ID. Enter a bunch of transactions
but keep a separate off line running total of the numeric field in question.
(If this is from paper transactions, have a separate user - or an outside
source such as a bank lockbox - generate this total to avoid duplicate
reading errors.) At the end of a reasonable number of transactions (25 to
100) enter and compare the count and total. If they differ the user must
scroll back to find and correct the discrepancy. If you can control the data
and accuracy is super critical options 1 & 2 can be combined.

For character data such as names and address, auto registration records,
product inventory data, ...; maintain an online reference database of all
possible / likely customers, members, patients, cars, ... and compare the
user input to potential matches. For most data, if a match is found the
user simply selects the item from the reference table and all related fields
are automatically filled in from previously entered reference info.

For character data requiring the highest possible level of accuracy and / or
if the reference table may also have errors, the user should not see the
possible matches until completing data entry for the transaction. The
system can then lookup possible matches. The user then selects the
reference entry, if any, and all differences with that data are highlighted
by the system. The user then corrects the new transaction and reference
data as needed.

In all cases try to minimize user data entry with barcodes, magnetic strip
readers, ... This is both more economical and usually much more accurate.
Where data entry is un-avoidable, and the input is paper forms, consider
optical character recognition combined with independent key entry. Again
all differences can be displayed, for user correction. This is not as
accurate as duplicate key entry but can improve on single key entry.

I am a retired CIO from the insurance industry. We implemented several
other, after the fact, batch edits to look for fraud, duplicate policies,
incorrectly spelled or abbreviated names and addresses etc. But a lot of
those edits would be specific to the data and industry.

Mike Sicilian

"Frank Whittemore" <fra...@adelphia.net> wrote in message
news:bcdcd347.04072...@posting.google.com...

> the first person entered? Final question - what else are you doing

[Drew Dekreon]

I'm always amazed when I go into a business and discover they're using
numeric identifiers without check digits for critical applications (loan
#s, account #s, invoice #s). It's trivial to implement and eliminates so
many costly errors.

[Frank Whittemore]

To Mike Sicilian -

Thanks for sharing your valuable insights with us!