Hi Aaron
I don?t want to prolong this any more than necessary so I?ll try to keep it
brief, but two points stand out:
You are thinking about doing things the way they have always been done with
different technology. Why not allocate the order number when it gets loaded
from the local client into the ERP system ? Uniqueness problem solved. Why
*not* have the inventory file on the users PC ? You only need to communicate
changes when they go on line. Initializing the file is a one-off effort.
Once again, can you get my point - this is an example of what can be done if
you want to, not necessarily the answer to the questions you raise. I'm just
demonstrating that you can solve the problem if you want to.
As far as ROI goes, what appears to make the salespeople and others
productive is what determines ROI. Since it is in a spreadsheet anyone can
make it come out to any number that proves their case (cynicism intended). I
have never seen yet an IT department win an argument against a
logistics|sales|inventory|purchasing|marketing executive - pick your title.
Once these operational guys decide something adds value to the business or
offers a strategic advantage IT better deliver. IT's view of ROI will be
overlooked, so your ROI argument is meaningless.
As to your it's only for personal applications comments - were you around in
1985 to hear how many times the mainframe guys (and others) made the same
comments about minis and PC's ? What the users *want* will drive this change
regardless of what we think or indeed what is actually the right answer.
Regards
Evan Harris
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Aaron Bartell
Sent: Wednesday, 24 December 2008 12:42 p.m.
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] JavaFX viability was->Re: Pete's web5250
Here's what I see for problems with order entry being offline (see
below). Obviously I haven't done order entry they way you are thinking
about it, so maybe I have a completely different scenario.
1) One of the first steps would be to get a unique order number that
wont clash with the other 100 order takers. Sure I can delay the
creation of that until I am connected, but if I am on the phone with a
customer then they are going to want some sort of reference number
*before* we hang up. I have played the game of "you have this number
range that nobody else will pull from" but that is kludgy IMO.
2) Customer on phone wants to order a pink hat. If they don't have the
sku number I need to prompt. There's no way I am going to download the
entire ITEMPF table *and* associated tables to the users PC - that's a
lot of data. What about calculating the price for that item? What if the
business is more than pick'n'pack and there's configuration?
3) I need to check and see if the item is in stock which requires up to
the minute real-time data. I also need to commit my order so inventory
can be deducted *before* somebody else orders and all the sudden we have
orders but not enough product.
I could go on, but you get my idea. In your scenarios what data would
you actually be attempting to store locally?
Your thinking that the application has to be centrally controlled or
maintained, that it has to live where the database lives. It doesn?t have
to, but it can, or you can have both.
I think the programming effort to NOT have them (app and DB) live in a
connected state (doesn't have to be on the same server) would prove to
be lengthly to build to the point of not enough ROI.
I understand that's an issue, but people working in technology are
asked to solve problems, not dictate how things should be done because
of any particular technical view they might have about how things
"should be".
We are also asked to develop applications for the long term that scale
well, maintain well, debugged easily, etc. Users would love to be able
to work from home and do orders even when the construction crew down the
street cut through their DSL line, but in reality it is more of an
infrastructure issue where the problem could be solved just by rerouting
calls.
With the proliferation of wireless networks at most coffee shops (and
even McDonalds in MN) I just can't see why an offline ERP type app is a
necessary thing. Again, the offline approach is great for things that
have more to do with that personal user, but outside of that I think we
are just wasting time trying to find a problem for a "solution".
I am all for thinking out of the box, but I am just not following your
line of reasoning for apps like order entry.
Aaron Bartell
http://mowyourlawn.com
Evan Harris wrote:
Hi Aaron
Any application could potentially operate this way - for instance you
might
want to create orders (or any kind of transaction) off line and then
upload
them when you are connected again. You might want to get some base data
files and then do some reporting or presentation of data. With the amount
of
local storage available now you can have any number of local lookup tables
to support a disconnected app.
Your thinking that the application has to be centrally controlled or
maintained, that it has to live where the database lives. It doesn?t have
to, but it can, or you can have both.
I am guessing your next comment will be along the lines of database
synchronization and maintaining data integrity in the face of a
distributed
environment. I understand that's an issue, but people working in
technology
are asked to solve problems, not dictate how things should be done because
of any particular technical view they might have about how things "should
be".
If you can't see it, then cool. But consider this: way back in the day
people considered PC's a waste of time; moving the apps out this way seems
like a natural extension of this at one level, at another level it's déjà
vu.
FWIW I am not commenting on what is necessarily best or right, just what I
think I see starting to emerge.
Regards
Evan Harris
midrange.com
