Data Validation

Published date01 April 1990
Date01 April 1990
DOIhttps://doi.org/10.1108/02635579010142122
Pages3-5
AuthorMark Fielden
Subject MatterEconomics,Information & knowledge management,Management science & operations
Data
Validation
Mark Fielden
DATA VALIDATION 3
D
espite the advances in computer tech-
nology, problems with data similar to
those of 20 years ago can still be
experienced.
A Short Story
Only an incredible 20 years ago all of our data were held
on 10" tape reels; there were no
disks.
Computers could
only do one thing at a time. They were used for the
productive work of running the business during the day,
with professional operators to look after them. At night,
programmers were allowed to use them for
testing.
They
had to do their
own
operating, feeding programs and test
data into the machine on punched cards and, if the test
was a long one, had to wait, and wait. On one occasion
whilst waiting for a test to run, a colleague commented
on two tapes, side-by-side in the rack:
Look, there are
two tapes here
that
ought to have
the same
data on them. How long would it take to write a program
to compare them?
One tape was a statement of the Spares Department's
requirements from Production for the next
18
months.
The
other
was
Production's "Customer tape", detailing what
it was going to deliver to Spares over the same period.
The program did not take
long
to write. There was a card
punch in the corner and by the time our long test was
over we had a program that would run through the two
tapes and compare the quantities on order, printing out
the differences if there were any.
At first we thought the program was wrong, as such a
lot of material appeared on the printer. It was not that
the quantities did not match, but hardly any of the part
numbers were the same.
There was nothing wrong with the program. On behalf
of customers, Spares were ordering part numbers that
were no longer made. Somebody in Production was
changing the orders to parts that were now current.
It is not difficult to imagine what would happen when the
newly-manufactured parts arrived at the Spares Stores.
After the confusion had died down, somebody would need
to telephone the customer. Another set of paperwork
would
have to
be prepared, another
price
agreed.
All would
incur costs.
Computers Cannot Validate
The answer to problems like this is Data Validation.
"Validate, v.t. make valid, ratify, confirm", says the
dictionary. Make sure that the data are correct when they
go
into the system.
An
error found at data entry time costs
a
lot
less
to
fix than
one
found when
the
components arrive
in stores.
. . .systems cannot "make
valid"
or "ratify" data
on their own
It
is
actually quite difficult to estimate the cost of this sort
of operation. There must
have
been
a whole
infrastructure
of people in the company to cope with the Spares and
Production part number problem, though we did not
realise the implications at the time.
Unfortunately, computer systems cannot "make valid"
or "ratify" data on their own. But they can "confirm"
decisions made by an operator. The operator is the key
to ensuring the data are correct, preferably backed up by
a database against which the input can be validated. The
operator should feel responsible for the quality of the data
s/he enters and should monitor that aspect of performance
as well as the more obvious ones.
The Problem is Still with Us
We have moved on a long way since the part number
problem was discovered. It still exists, however, though
in a different guise.
On the shopfloor
we
have small data collection terminals.
Data are fed into them using barcodes and a small
keyboard.
All
work is accompanied
by
a "follower", a set
of cards in a transparent plastic bag. Operators have a
plastic card with their own personal number on it. After

To continue reading

Request your trial

VLEX uses login cookies to provide you with a better browsing experience. If you click on 'Accept' or continue browsing this site we consider that you accept our cookie policy. ACCEPT