RE: Business Process Components - SMEs want a two way flow of dat a

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

David,

I'm sure you are aware that 'EDI" (X12, EDIFACT) supports the two-way flow
of data you describe in your Email.  As some others who listen in on this
list may not be aware, I first want to assure them this is so.

The real problem you observe is that EDI has not generally been integrated
into off-the-shelf business packages.  Instead, EDI has been an add-on that
requires additional outlay of capital and additional in-house or contracted
technical support.  Perhaps it would be helpful to examine the shortcomings
of EDI and of off-the-shelf business packages that contribute to this lack
of integration.  It would also be helpful to ponder whether XML/EDI
addresses any, most, or all of these shortcomings.

I can provide a start on the shortcomings, and perhaps others will enhance
the list.

	1) New Versions of EDI requires significant support effort
	
With early releases of a given Message/Transaction Set, significant changes
in content and structure may occur, and such changes are likely to require
significant support effort.  Unfortunately, I see XML/EDI taking a backward
step on document structure maturity.
With later releases EDI requires some support effort to upgrade to a new
version.  In most cases, the message content actually used by an SME would
not change, so the support effort would be fairly small.  In this case,
XML/EDI would likely further reduce upgrade support effort in cases where
the message content actually used by and SME did not change.

	2) Inport/export of data from off-the-shelf business packages has
typically been in a highly proprietary format

A number of off-the-shelf business packages have chosen to provide XML data
import/export.  While the actual XML constructs may remain proprietary to
each application, it should make it easier for application integrators to
map between applications and message protocols.  But since AIs map XML/EDI,
X12, and EDIFACT with equal effort, there is no inherent advantage to
XML/EDI over traditional EDI.  And this still requires support for a
middleware program between the applicaiton and the messaging service.

	3) There is a mismatch between the Business Models upon which
off-the-shelf business packages and upon which eBusiness messaging are
based.

This is perhaps the most serious problem in the way of meeting the SME needs
you express.  Essentially, it's solution requires the participation of
application vendors in the public messaging standards setting process, and
the acceptance of a common business model across competing applications.  I
view this as the biggest of all hurdles to jump.  Cooperation among 'trading
partners' is difficult.  Cooperation among direct competitors is extremely
difficult.  Competitors will not voluntarily cooperate.  Yes, there are
numerous public standards that represent the result of cooperation of
competitors.  From my experience these come about not because competitors
want to cooperate, but rather because the customers of the competitors
demand standardization.  

	4) Business models / business practices are complex.  

Advances in modelling tools, and increasing acceptance of modelling as a
means to improve business processes holds promise of reducing some of the
complexity, but more importantly, of allowing greater automation of the
details of that complexity.  In my opinion, this is the most promising of
the efforts toward expanding the usability of eBusiness standards.  


I look forward to continued improvement in eBusiness tools and subsequent
penetration into smaller businesses.  At the same time, I don't see any
magic potions in the kettle.  That is, I see eBusiness evolution, not
eBusiness revolution as the pace of change.

Cheers,
        Bob Miller

-----Original Message-----
From: David Lyon [mailto:djlyon@one.net.au]
Sent: Thursday, April 26, 2001 9:25 PM
To: ebxml-core@lists.ebxml.org
Subject: Business Process Components - SMEs want a two way flow of data


One of the biggest influences that has slowed down electronic commerce and
EDI over the years is the uni-directional data flow typically found in EDI
systems. That is, the expectation that Orders will flow in, and nothing much
will come back the other way.

Purchase Orders have been the main focus of the EDI endeavours, as EDI
itself was originally invented to solve a particular problem in the area.

However, for SMEs at the moment, need more. They want the flow of data to be
two ways.

They want to be able to receive Invoices/Delivery dockets and Statements
electronically and have them loaded automatically into their systems.

In most cases, they have to 'key' this information manually and it's a
hassle. Obviously with the prevalence of packaged accounting systems, there
is every likelyhood that 'monkeys' (programs to key Invoicees and Delivery
Dockets) will become more widespread.

Receipts/Invoices and Delivery dockets. They are the worst for small
business, and most big businesses are ambivilent about automating them, yet
they are so important.

Having said this, I acknowledge that there are some companies who offer
this, however, more work needs to be done to provide a 'two-way' flow of
data between organisations, now that the uni-directional flow has been in
operation between some organisations for over 15 years.

For success with ebXML for SMEs, a big push needs to be made on streamlining
the Invoice/Delivery Docket/Receipt flow in the same way that Purchase
Orders were the big push in EDI.

Take care

David Lyon








------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org