That's a great story Virgil!
Mike
Virgil Bierschwale wrote:
I see it didn't come through
I studied the techniques taught by Juran and deming in the 80's
The thing I was referring too was a problem with molten lead
Out of x lead preparers all were failing
When the experts were bright in to study them they could find nothing
One morning one of the experts showed up several hrs before the shift started
The guy that always poured a perfect lead mold was cleaning the funnel with a
file
Fascinating stuff the Juran and deming and six sigma stuff
I miss it
Sent from my iPhone
On Oct 1, 2014, at 9:45 PM, Dan Covill <[email protected]> wrote:
I think Virgil's on to something here. If their 'macro' work flow is better
when they move the stuff around first, then do the computer work, find a way to
help with that scenario instead of forcing a different one.
Why not try automating the Notepad - let them scan (n) boxes into a list, then
in your app pick from the list. At least it won't be full of typo's.
Dan Covill
From: [email protected]
Subject: Re: square peg - square hole
Date: Wed, 1 Oct 2014 17:18:51 -0500
To: [email protected]
Juan had a case study about a similar problem in the 80's
Sounds to me like the solution is a portable scanner with a pick list program
Sent from my iPhone
On Oct 1, 2014, at 5:11 PM, Mike Copeland <[email protected]> wrote:
Yep, tried that first thing, along with frank discussions with the users asking "why?"
This has been a problem for years now, and the issue comes and goes as new employees cycle through.
Management even installed wireless rechargeable hand-held scanners on multiple workstations that
are located near the work/processing area...there's no reason anyone in management can come up
with. They even tried moving a VP of operations to the warehouse processing office for a couple of
months last summer to watch (from 8 to 5 at least) and see what was "really" happening.
The only thing that makes sense, in the end-user's defense, is that they prefer
to move boxes around for all their orders that need to be processed, then when
the boxes are stacked up they go and do all their computer work for all their
orders that need to be processed (instead of processing one order from pulling
boxes to paper work to completion of order.) But we're talking personal
preference here...the distance from the computer to the box staging area is
about 12 feet.
Thanks, Virgil.
Mike
Virgil Bierschwale wrote:
Must be a process flow problem if they're going to that much trouble
Grab you a chair and watch their frustration with the process for a week or
month until you understand why they are going to that much effort
Sent from my iPhone
On Oct 1, 2014, at 4:52 PM, Mike Copeland <[email protected]> wrote:
All,
I have a problem with end users hand-keying information that should be scanned
with a barcode scanner to improve accuracy.
Here's the gist of the issue...
Every piece of inventory has a barcode sticker on it representing a unique
serial #, always 8 characters long.
(My application offers a way to reprint the barcode label in case this label
gets torn, damaged.)
What I need to force, somehow, is that the # represented on the barcode label
MUST be scanned by a simple barcode scan gun connected to the computer.
As ya'll know, all the scanner does is convert the barcode data into standard
keyboard keystrokes and stuff the data into the keyboard buffer...really fast.
In other words, a very fast, very accurate typist. But most importantly, the
CORRECT # is input (so that the correct inventory item is recorded as
'processed.')
The problem is that the users hand-key the number at the prompt...and
frequently hand-key it wrong.
So, to try to stop the hand-keying I removed the human-readable text under the
barcode on the label. So now, you either scan it or you learn to read barcode
by eye. One would hope/think that this would have solved the problem...but no.
Now (by watching security video footage) we find that they are
1. opening Notepad
2. scanning the barcodes, which enters the barcode data in human readable form,
obviously
3. then hand keying the data into my application when they should use the
scanner.
And...errors are being made regularly. And, yes, training, threats, etc. have
been tried.
From the application's viewpoint, the only difference between a barcode
scanner providing input and a human typing on a keyboard is the speed with
which the data is input.
So, my last-ditch idea to force scanning and negate hand-keying is to, somehow,
use a timer on the input. Set the timer to a short time, like 1 second, which
is faster than 99% of humankind can type 8 characters. Start the timer on the
first keystroke and when the timer fires again if the length of the input is
less than 8, clear the input...because they're not scanning.
My question, is this nuts? Is there a better way? Am I barking at the moon?
Begging for problems? Any other Ideas?
Thanks for feedback.
Mike Copeland
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
