On Oct 22, 2007, at 5:41 PM, Kenny Fogarty wrote:
It’s the concept of "one strike, you're out!" that I find amazing.
What
constitutes a mistake serious enough to put someone's livelihood at
stake?
With that kind of pressure hanging over anyone, how can they be
expected to
learn, and grow and enhance the company they're working for?
Kevin:
How would you handle a person that scrutinizes blood for a living and
mistakes a diagnosis ?
In some case an operator is just as "guilty" as the blood analyzer.
If you say thats not the same, I would agree but not in all
circumstances. If an operator put in a wrong date at IPL and (because
of that) RACF refuses to come up and there is no backout or even
worse datasets gets scratched because of the operator error which
leads to a fine from say the SEC (or take you pick of agency). There
are degrees of error of course some are who cares to a possible
company going bankrupt there are in the last case MANY people being
out of work (possibly 1000's or more) would you not fire the person?
The gravity of the error is all important, of course.
I think we've all seen enough horror stories over the years, where a
command, or parameter has been entered in error, but from those horror
stories, procedures got tightened, people were educated, things got
better.
People learn from mistakes, and go on to pass on their findings to
their
colleagues, to their peers and people act on that, and learn and
improve.
If you hang a sword of Damocles like that over everyone within an
organisation, nothing would get done.
Within a programming environment, has anyone ever written a 100%
bug-free
piece of code, that has lasted for all eternity, never once needing
to be
optimized or re-compiled or re-linked? Are bugs that are exposed
over time
by new releases of the operating system, or various subsystems
classed as
being serious enough to have your job and reputation absolutely
caned? I
just think it’s a nonsense concept and a nonsense approach.
I think you are comparing apples and oranges. An operator can by
mistake put the company out of business, a programmer can cause loss
revenue and yes possibly a fine . BUT that should have been found in
QA before the program goes live. In other words their work is checked
by others. An operator does not have this luxury. Yes programmers can
make mistakes but (in most cases) its not a shut the front doors and
turn off the power whoever is the last one to leave. An operator can
do so with a small "oops". That is why an operator, IMO must go
through several years of training so they CAN'T make stupid mistakes.
Its possible that a programmer could write a program that
misdiagnoses a test (health) result and yes that could lead to the
persons death, but presumably there are other fingers in the stew to
catch the errors. In the case of an operator there is no way to catch
all errors that could cause a major issue. Catching a Vary is a small
part of any possible error. Catching a bad date at lets say early on
in the IPL process is impossible by any of the suggestions mentioned
as the exits (programs) are not available then.
I would suggest an incorrect VARY command might cause some amount of
grief but (probably) not enough get fired over. I know some places
have intercepts to catch an incorrect vary command. That is almost as
bad (IMO) as saying your fired as you don't trust your operators so I
am going to attempt to intercept commands and double check them.
There is no guarantee that the devices were not the right devices
even with an exit.
Being an operator is a lot like being an anethesiologist the skill to
know how much sleeping gas to administer so the patient does not
awake or die. The surgeon is one part (major) of the operation an
operator is a helper. That is what an operator is a helper.
Ed
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
