RE: Party XML Schema Defintions

[Bob Haugen <linkage@interaccess.com>]

Martin Bryan:
>If an SML already has a small application using Access why the hell
>should he be forced to create ebXML BP, BOV, FSV, CPP, TPa, UTCAA,....
>formal definitions of his processes.
[...]
>Most SMEs have very trivial BPs. Most of them do not even have formal
>procedures but work on an ad-hoc basis. My point is that if we want to
>attract more than a few percent of the larger SMEs we have to be able to
>work using extremely simple, probably manually controlled, procedures that
>do not need more than a few seconds to set up.

I wonder what situations you are thinking of here.  SME <-> SME?
SME <-> larger company?  SME <-> Web service?  Something else?
What kinds of documents and processes?

If SME <-> larger company, the larger company likely has formal
procedures that they want the SMEs to follow. The larger company
could package up the procedures and supporting software so that
the SME could either download it or use it online as a Web service.
In such cases, ebXML with packaged procedures may allow SMEs
to participate in larger supply chains more effectively, as opposed
to being the "weak links".

If SME <-> SME, if it is worth doing ebXML collaborations,
they may want at least request-response business transactions,
that is, a minimal BP which can be run manually but will
require some supporting software that will not be included
in their existing applications (until ebXML support gets
baked into e.g. QuickBooks).

If they can't do request-response transactions, the customer
will not know if their order was accepted unless they call 
each other on the phone or email. I suppose they could just 
email ebXML documents, if there was some payback for ebXML 
at all.

My general question here is:  what are the conditions that
will make it beneficial for SMEs to adopt ebXML?  And in
those conditions, what are the likely business process and
software requirements?

Regards,
Bob Haugen