Please forgive my ignorance on this subject, but what specifically is wrong
with EDI?
I read many general complaints from some of the list members, never anything
specific.
People who are complainers, complain about everything and will never be
satisfied. And they too
are never specific about their complaints. Saying *EDI stinks* means
nothing except about the person who says it.
After 20 years in the computer consulting business, I've learned several
important truths.
One, automating any business process brings challenges (and thus rewards).
Two, no project is ever done; there are
betters ways to do anything and everything is always changing. Three, this
industry provides us all with an excellent
income and lifestyle (at least for me). And four, if it was easy, we
wouldn't be needed.
Be creative. Every EDI implementation should include some business process
reengineering. Without it, it's like automating
an old index card system by simply *painting* the card on the screen. If
there are no appreciable business benefits, don't automate it.
Look at the enterprise (whether it be a department, business function or
corporation). Show the clients (the people paying you if your a consultant
or
the users in your company) how to improve their lives and work efficiency.
After participating in several dozen large-scale, UNIX-based, EDI
implementations, I have yet to see a customer whose life got worse.
Anything worth doing is doing well. Use the tools you have (software and
brains) to find a solution.
With the available technology at reasonable costs, the *magic bullet* is you
and your creativity.
Lee LoFrisco
Sterling Commerce Service Partner Consultant
VoiceMail: 614.210.2706
Cell Phone: 410.963.6218
eFax: 810.277.5002
-----Original Message-----
From: Electronic Data Interchange Issues
[mailto:[EMAIL PROTECTED]]On Behalf Of Bill Chessman
Sent: Monday, October 16, 2000 2:48 PM
To: [EMAIL PROTECTED]
Subject: Re: Re-engineering can make smaller XML!
I think the idea that XML (or any other syntax) is going to be the "magic
bullet" for EDI is a real misconception. I also don't think Mr. Kammerer
was actually implying that XML, in and of itself, was such a thing.
What I've found in the past is that when new technology becomes prevalent,
it gives people an opportunity to open there minds, think things through
and approach problems (old and new) from a different perspective. Gosh if
stick to the old precepts and all we do is transliterate all of the
elements from X12 straight into XML, I guarantee we will have gained...
nothing. In fact, we would just make life worse since there would be all
those extra characters (somewhere between 0 and infintely more characters,
depending on who the authority is).
We're all in a hurry to adopt the latest and greatest so long as it doesn't
mess up what we're already doing. Send documents via XML instead of EDI?
Cool, right? Just think we'll be doing XML!!!
Sorry, I don't see the point if that's all there is. So why not rethink
some things? We keep seeing (and saying) that EDI doesn't work well
enough. Could it be that we need to come at the problem from a different
angle? Is it enough to worry about where is the data in the application
and what is the format of the data across the wire? That's the major focus
of EDI today. Who really cares about process...let's just get those
separators and codes in the right format.
I think it's interesting that ebXML is focusing on process and XML is just a
means (and not even the only one), rather than an end in itself. To me
that makes a lot more sense.
In summary, if the only reason to jump on the XML bandwagon is to do
exactly the same thing as EDI using XML, that's not good enough.
Best regards,
Bill Chessman, whose opinions may not exactly match those of his employers
Peregrine Systems - e-business connectivity group (formerly Harbinger)
On 16-Oct-2000 Paul Krikke wrote:
> William Kammerer wrote:
>
>> As far as XML's benefits go for B2B ecommerce: if permission to "play"
>> with XML is accompanied by a management dictate to improve the process
>> (regardless that the processes could have just as well been optimized
>> with X12 EDI), then all might turn out well in the end. As an example
>
> Doesn't this just mean that the real benefits of converting from X.12 to
> XML are gained from reengineering the process as opposed to anything that
> XML brings to the table?
>
> Perhaps I'm just cynical about "yet another magic bullet that solves all
> EDI problems", but I wince when I read all about XML's "magic ability" to
> make things faster/easier/cheaper. In my case, most of my EDI is
> customer-driven, and my customers come from such disparate market
> segments such as auto manufacturing, construction, and appliance
> manufacturing. Each customer's EDI implementation guideline differs from
> the next customers, often significantly. I don't see that being any
> different with XML (one cu
> stomer may use <CustomerName>Bzzt</CustomerName> while the next will use
> <ShipTo>Bzzt</ShipTo>, I'm sure). This doesn't seem a whole lot better
> than one customer saying "N1*ST*Bzzt" while the next says "N1*ZZ*Bzzt".
> I *still* need to tell my application that these examples all map to
> something like BLinfo.ShipTable.ShipName in my database tables.
>
> I've always seen the real work in any EDI project as being the
> application integration, and I don't that as being any easier with XML.
> As a matter of fact, I think that the ease of creating customer-specific
> "standards" (cough choke gasp) may well make the situation worse.
>
> Keep in mind that I'm talking about the situation where XML is used in
> place of X.12 for EDI. I *do* see some significant benefits in using XML
> to communicate between applications internally, but I'm still (very)
> jaded about XML for EDI. Is this way off-base? What am I missing? I
> really want to jump on the XML bandwagon!
>
> Paul Krikke
> Coordinator, Business Applications
> Taylor Steel Inc.
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
____________NetZero Free Internet Access and Email_________
Download Now http://www.netzero.net/download/index.html
Request a CDROM 1-800-333-3633
___________________________________________________________
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
