Re: Application-level trading partner integration

[Mark Kusiak]

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.