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
J.
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.
