Mark:
Very well said.
Thank you.
Regards,
Bob Scheuermann
EDI Manager
The Mentholatum Co., Inc.
707 Sterling Drive
Orchard Park, NY 14127
716.677.2500 ext. 1519
716.674.3696 fax
-----Original Message-----
From: Mark Kusiak [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 30, 2001 12:42 PM
To: [EMAIL PROTECTED]
Subject: Re: Application-level trading partner integration
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/
