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

[Mike Rawlins <mike@rawlinsecconsulting.com>]

An excellent, concise analysis, Bob!

"Miller, Robert (GXS)" wrote:

> 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
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org

--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com