OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: SMEs : was RE: Party XML Schema Defintions


I think that what you are saying makes a lot of sense.
The idea would be that via some discovery mechanism it will be simple to
jump on the ebXML bandwagon without buying special tools. The possibility to
discover the Business that "just waits for you" and to easily configure some
"available" software to properly engage would be very powerfull.

/stefano

> -----Original Message-----
> From: James Bryce Clark [mailto:jbc@lawyer.com]
> Sent: 06 February 2001 15:33
> To: linkage@interaccess.com; ebxml-core@lists.ebxml.org
> Cc: 'Martin Bryan'; Stefano POGLIANI
> Subject: SMEs : was RE: Party XML Schema Defintions
>
>
> <Martin>
> >> 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.  </Martin>
>
> <Bob>
> > 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. * * *
> > ebXML with packaged procedures may allow SMEs to
> > participate in larger supply chains more effectively, as
> > opposed to being the "weak links".  </Bob>
>
> This is a compelling case for me -- I know a few SMEs whose operations are
> savaged by  being repeatedly "rationalized" by dominant supply chain
> partners.   The SME's life would be much easier if the two or three
> 800-pound gorillas in its life were imposing transaction sets that shared
> modelling assumptions and function calls (to its ERP system, or
> QuickBooks,
> or whatever).
>
> <Bob>
> > 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 * * *
> > If they can't do request-response transactions, the customer
> > will not know if their order was accepted unless they call
> > each other * * * I suppose they could just email ebXML * * * </Bob>
>
> Can we rethink the SME-to-SME problem?   I think what you really
> have is an SME-to-cloud-of-undifferentiated-opportunity problem.
>
> There will always be commerce between people who just pick up the phone,
> where the bother of automation (ebXML or otherwise) isn't worth it.  I
> don't think we have to accommodate that case.
>
> However, transaction modularization (like ebXML) and open distributed
> resource discovery (along the lines of UDDI) is going to create market
> opportunities for SMEs.   Thanks to network effects, we will eventually
> have a bunch of disembodied deals strolling through the woods, calling out
> "Heidi!  Heidi!"   To find them, Heidi will need a subset of tools to
play,
> for the same reason you need a little French to get along in Provence.
> What subset?
>
> I'm not worried about Ma's Malt Shop using ebXML to sell gumballs
> retail to Junior and Spike.  But I am concerned that Ma can get a
> user-friendly front end that allows her to notice that the air force base
down the street is
> looking for a bulk purchase of gumballs, and reply.
>
> Jamie
>
> James Bryce Clark
> Spolin Silverman & Cohen LLP
> 310 586 2404    jbc@lawyer.com
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC