Mark,
You must be reading my mind ... very well written!
I hope you are not complaining though. After all,
it is because of the technology and miscommunication you write
about that pays my mortgage, car payment, private schools, vacations,
child support, etc.
Not only that, they also satisfy a need in me to help people.
Nothing like arriving at a location where people are frustrated
and understaffed, trying to make sense of it all, and you "help"
them pull it together.
When I go to bed at night in some far off hotel room, I dream
and sleep well.
Lee
>--- Original Message ---
>From: Mark Kusiak <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Date: 8/30/01 12:41:39 PM
>
The age old problem of communication between organizations, individuals
and
>entities will continue as long as there are humans around who
want to
>attempt to talk to and understand each other. It strikes me
as odd that
>anyone would think that a "man made" process would not suffer
from the same
>short comings as does man himself/herself.
>
>Considering that ERP systems were/are designed to satisfy mostly
internal
>issues and concerns, of which there are many, what makes any
person think
>that taking the act on the road is going to be any easier.
This will
>require folks to sit down around a table and negotiate or discuss
those
>differences and formulate solutions if possible. The problem
is that the
>negotiating process is not a level playing field. Each party
is a customer,
>the position of strength or a vendor, the position of weakness.
>
>If one can force their unsolvable problems off on the weaker,
then they will
>do it and call the savings generated by an improvement in efficiency.
The
>weakling looks at it and says, my costs for EDI are out of control.
One
>fact of life is that most of those involved in EDI are in a
position of
>weakness, thus the cries from the pit of despair for some thing
to come down
>from on high and ease the pain and suffering (sounds like XML
to me).
>
>In defense of XML, improvements in technology and communications
do lend
>themselves to passing information (a purely technical breakthrough)
in a
>manner that is simple and widely available. Does it solve the
problems
>associated with attempting to communicate and understand another
person,
>entity, or organization? Not on your life!!!!
>
>You will still have the ever continuing problem of how do I
get the
>information I received into the ERP and make it provide or produce
something
>that I can take and use with the tools that I have already built?
>
>One answer floated around is to make all the ERP's the same.
That will
>solve the problem. Well, we all know that this is a perfect
solution that
>will never occur. There are always going to be those home-grown
ERP's that
>will enter into the mix because the SME can't afford the off
the shelf same
>ERP that everyone else has. So I will not be holding my breath
waiting for
>this to happen either! Or the government will step in and call
it a
>Monopoly.
>
>I don't think that EDI, XML or any other standard up and coming
has an
>answer to all of the issues or problems associated with "automatic
>electronic communication". But they do provide tools that can
be utilized
>to solve the issues and build solutions to answering some of
those
>questions. The Pandora's box of electronic communication is
open and we in
>the business will never be able to fully stuff the resulting
plethora of
>issues and concerns back into it.
>
>Other issues:
>
>Freight terms and what they mean on a PO. FOB destination/origin,
who pays
>when? Must be agreed to between the parties. Which prospective
is used?
>
>Drop Shipment and how it works How do I handle something
in my
>ERP if I'm shipping to a customer's customer and I don't know
who they are
>and have no mechanism for gathering their information, qualifying
them and
>providing the internal checks and balances to process them without
having a
>human person to deal with and defeat the checks in place?
>
>Bottom Line:
>
>The change in meaning and communication between organizations
has kept me
>busy most of my professional life. I have a feeling that this
is not going
>to change with EDI, XML, XYZ or any other standard that comes
down the pipe.
>So get in, sit down, hold on tight, and enjoy the ride. One
thing is sure.
>It's going to be fun :-).
>
>
>Mark
>
>
>
>
>
>-----Original Message-----
>From: Matthew Montano [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, August 29, 2001 10:01 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Application-level trading partner integration
>
>You've touched on why EDI/B2B is not a simple IT exercise.
>
>> many ship-to addresses (up to 2500)...
>
>ERP software 'thinks' one way, EDI documents 'think' another,
and your
>trading partner will 'think' in another. Sound familiar?
>
>Most EDI implementations, at least the ones that I've come across,
aren't as
>simple as an ERP system coupled with a mapping tool and a message
transport
>tool. In your SDQ examples, solutions include 'double mapping/splitting',
>'user exits' in the ERP package, or pieces of "glue code."
>
>Most EDI job postings including UNIX shell scripting as a 'nice
to have' for
>a very good reason. ;-)
>
>> buyer sends data in an inappropriate document
>
>Isn't this the truth? Half of the problem is that it could be
easier to
>'cram' data into an inappropriate document and export the problem
to their
>trading partner. The other half of the problem is the reality
that every
>business does business differently, and it gets mapped into
EDI documents
>differently as well.
>
>Put all of these together and it becomes obvious why I've always
used a rule
>of thumb of a minimum of 4 man-weeks per transaction per application/trading
>party pair. Throwing XML formats, Internet based transports,
partner
>management tools doesn't decrease the 4 weeks. If anything they
make it
>worse.
>
>(Want some more? How about variations in the interpretation
of English? Does
>"Requested Delivery Date" mean the date to goods are supposed
to leave the
>warehouse, or arrive at the customer site? What does "price"
mean, before
>discount, after rebate or visa-versa, or neither.)
>
>Matthew
>
>
>
>
>-----Original Message-----
>From: Electronic Data Interchange Issues [mailto:[EMAIL PROTECTED]]On
>Behalf Of jwells123
>Sent: August 28, 2001 5:34 PM
>To: [EMAIL PROTECTED]
>Subject: Application-level trading partner integration
>I often read that one of the challenges of EDI is having to
make changes to
>your internal applications for each new trading partner integration.
As I
>don't work with EDI, I've been trying to dig up some examples
of this.
>
>1. Large buyers often send EDI POs with many ship-to addresses
(up to 2500).
>Their suppliers have to modify their applications to split these
POs into
>multiple orders.
>(General case: The sender crams extra information into one EDI
document to
>reduce information repetition as much as possible, until there
are
>effectively multiple documents crammed into one. The receiver
has to modify
>their application to split the document back apart in order
to process it
>properly. Presumably the VAN costs savings are greater than
the costs of
>modifying the application, or else this is just an example of
the larger
>trading partner dumping their costs on the smaller?)
>
>2. One trading partner wants to exchange information that currently
isn't
>handled by the other's application. For example, a buyer could
send
>information in the PO that the seller is required to repeat
in the advance
>ship notice (ASN), such as PO number, line numbers, dock door
number, etc,
>but the seller's application might not be equipped to handle
this
>information.
>
>3. A buyer sends forecast data to suppliers in lieu of purchase
orders, but
>the forecast data must be processed as a PO.
>(This one strikes me as odd...why not just send a PO?)
>
>Does anyone know of other cases?
>
>In my ongoing EDI vs. XML comparison, I notice that XML can't
really help
>with any of these...one more way to counter the misconception
that XML is
>going to solve the problem of application-level integration
with each
>trading partner.
>
>
>
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
