RE: Interactive Response Time

Phil,

Ya.. Tom got it extremely right...  (Just saw Jim Franz' post.. same...!)

I was inspired, by these posts, to take a look at your company's website...
I assume you're from PHD, Inc. "Solutions for Industrial Automation"...
Didn't spend but a few minutes, but I gather you're worldwide.. very wide
range of products I don't understand.. in business for 40 years...  Appears
that you're not a distributor, but a design and manufacturing company.  No
way to guess sales, and didn't want to see if the family-founders have taken
the company public, or not.  I'd guess anywhere between $50M and $500M, but
websites can give an appearance of a larger company than what it actually
is.  Anyhoo...  If that's you, I'm surprised your President has time for
this issue...

...Well, he doesn't...

I imagine he was grabbed by the necktie, by an extremely irate user.
However, it is of no matter whether this is an extremely isolated case, or
worse yet, the tip of the iceberg.  The extent of the problem can be
tracked, a number of ways.  You can find out where the bulk of the problems
are coming from, fairly quickly, I'd think.  Long-running batch-like jobs,
record locks, JDE (could be causing both), other...


If your President is like some I've run across, he's got dozens and dozens
of issues like this to deal with, at all times.  (Not to mention the bigger
issues Presidents typically deal with.)  And he probably doesn't
particularly care to deal with the computer issues.

He may, or may not, take an interest in all the details that go into this
decision.  But if you get to take Tom's suggestion of a few demonstrations
of the problem(s) you can accomplish a lot.  I would add that you might want
to have your own ideas about how to fix the problem, but it would be a great
idea to ask your President how he'd want to deal with the situations.

Because whether or not he understands anything more about computers after
the demo, he would have an opportunity to see:

a) There are contrary objectives
b) Various ways of balancing these objectives
c) Several specific causes and solutions
d) The solutions all have costs, some more easily defined than others


BTW, Phil, do you report TO the President?  Or were you grabbed by the
necktie at random?...;D

jt


| -----Original Message-----
| [mailto:midrange-l-admin@midrange.com]On Behalf Of thomas@inorbit.com
| Sent: Thursday, December 13, 2001 10:23 PM
|
| >From seeing the other posts and your responses, I don't think
| you need much more advice. Your plan was a good one from the
| start. But I do have one suggestion on managing expectations.
|
| I suggest you create a couple situations guaranteed to show long
| response times and ask your president how they should be handled.
| For example, bring a record up for update in one session but
| don't press <Enter>, i.e., establish a lock. Then try to update
| the same record in another job. Tell the president "I need your
| ruling on some things. The user at the first session has just
| gone to lunch. The second session user cannot update that record
| until the first user comes back. How do you want me to implement
| the 30-second rule in this case?"
|
| I realize JDE might handle this specific situation through
| application code, but you can create the demos in other ways.
| Another possibility might involve waiting for a message to be
| replied to. There are numerous possibilities.
|
| The point would simply be to make sure it was understood that it
| might not physically be possible for you to implement the
| 30-second rule without causing side-effects worse than long
| response times or requiring major programming effort.
|