re: ... SMEs want a two way flow of data

[James Bryce Clark <jbc@lawyer.com>]

I am re-posting the 27 April exchange between David Lyon and Bob Miller to
the BP list, because it is highly relevant to our BP work and assumptions.  

Your discussion of the probable evolutionary path for X12 users, and its
pitfalls, is extremely insightful and helpful.   That set of problems, and
upgrade path issues, was central to the development and refinement of the
BP spec schema.  

The best working non-vaporware solution I know to the 'two-way' problem
David describes is the logical request-response paradigm originally from
RosettaNet RNIF 1.0 and ported into the TMWG N90 UMM metamodel.  It
combines re-use of simple documents in actual commerce (such as X12 POs)
with simple signals that logically assemble the docs into transactions.
Much of the ebXML BPSS is an attempt to bring that same logical model into
a cross-platform standard.  Based on some preliminary work, I strongly
suspect that we will find it aligns very nicely with users' legal and
accounting requirements, and real world interfaces with EAI systems, as well.

Of course, we need the core components work to continue.  At the moment, we
have (for example) a BP layer capable of collaborations that re-use XPath
pointers to a data field in a payload document (like a PO or bill of
lading), but we don't have a standard format for the doc so we can always
find the right field.  

Personally I am confident that commerce will eventually force solutions to
that latter problem, as large volumes of commoditizable transactions pour
through the system.   Look what has happened to residential mortgages in
the last few years.  

Best regards    Jamie

James Bryce Clark
Spolin Silverman & Cohen LLP 
310 586 2404    jbc@lawyer.com   

At 08:59 AM 4/27/2001 , you 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
>