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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: RE: [ubl-dev] Re: [ebxml-dev] P2P for e-business - applications?


Stephen,

Well, ok, so collaboration's potentially interesting - still not
convinced that P2P or any other one specific underlying technology is
required to make that happen.

But there's a bigger problem - the scenario you describe contains two
things each of which is hard on its own, and extremely hard to the point
of implausibility when you put them together.

First, you describe the exchange of standardized messages to configure
the end-point systems for B2B. The big problem (especially with SMBs) is
that virtually none of the real business systems SMBs use have any
notion whatsoever of sending/accepting any such standardized messages to
configure an exchange. Even the more basic need of just getting a PO or
invoice document in or out is a challenge. And even where it's possible,
it's going to be in whatever legacy format they happen to support, not
any "preferred standard" document. So given this environment today, the
exchange of standardized B2B messages from peer-to-peer adds relatively
little value, to the extent it ignores the more important job of
actually integrating those messages with the existing systems.

Secondly, you talk about "clerks" customizing the setup of business
processes between the two businesses, with the notion that those
customizations will flow through and be understood and supported by the
business systems. This may not be far-fetched in the context of ebXML
CPAs, but it's fairly far-fetched given real-world SMBs, their systems,
and their people. In reality, what I see with our customers is each SMB
having its own internal process - and yes, wanting some degree of
customization to fit with that. But this is first about them, and second
about partners, who they ideally want to all look the same as far as
possible. In other words, it's more of a one-time setup as to what they
want and support. It's certainly not end-users negotiating case-by-case
with partners. The better analogy would be a merchant posting on their
storefront that they accept Visa, Mastercard and American Express.  A
shopper with Discover and Amex then decides which card to present, but
it's the same payment process for the merchant. That's more the
negotiation.  In our context, I expect mostly that this negotiation
would be automated based on the capabilities and preferences that each
party has expressed to set up the electronic relationship accordingly.
So here, even the experience of each party is some way from the
"collaborative" process you envisioned. (And even that more
collaborative process you describe fits P2P less well than you suppose,
given the first point about the constraints of dealing with the internal
business systems).

BTW not sure where your last comment came from. I'm not saying there's
not value here. There's huge value... in actually solving the problems
that SMB users care about, and applying appropriate technologies to do
so. As technologists, it's very easy for us to fall into "man with
hammer seeing all problems as nails" way of thinking... especially in a
group like this that's defined by technologies. The only value in P2P
(or standards, or any other technology) is enabling solution providers
to incrementally reduce costs.

As to expense... well yes, it does take effort to make this work, but
there are consulting business models, and mass market product models.
Despite our similarities, David and I have different business approaches
that affect what customers do and don't end up paying for.

Best regards,
Roger



-----Original Message-----
From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk] 
Sent: Tuesday, April 03, 2007 10:25 PM
To: ubl-dev@lists.oasis-open.org
Subject: RE: [ubl-dev] Re: [ebxml-dev] P2P for e-business -
applications?

Hi Guys

So it looks like it is still on the horizon, albeit
with some vendor reluctance, then.

I could imagine it being very useful for situations
where there is collaboration needed: you mention the
problem there is in parties agreeing business processes
and I'd add to it agreement of the constituent parts
of a document (customisation as UBL calls it). Maybe
products will one day use IM or the like to provide
collaboration; like chat but more structured and
controlled, point-to-point, clerk-to-clerk as it were.
This could result in configuration of both systems for
the subsequent B2B. It's not so far fetched when you
look at the negotiation of CPAs in ebXML.

So what's the point of point-to-point? :-) Not much
more than allowing collaboration in real time. In B2B
I'd regard that as imperative for trading agreements
but not necessarily for the business itself. But if
it is provided for agreement resolution then why not
allow it to be used subsequently for the business
itself.

But all this talk of expensive development just makes
me think there must be more value in doing it than you
guys say or you wouldn't be talking about it still :-)

All the best

Stephen Green



Quoting david.lyon@preisshare.net:

> Quoting Roger Bass <Roger@Traxian.com>:
>
>> Stephen, David et al,
>>
>> I'm jumping into this thread a little late...
>
> no - unfortunately it is still an ongoing thing...
>
>> This technology discussion all misses the point. From a pragmatic
SMB's
>> perspective, all they care about in this context is interconnecting
>> their business processes with one or more of their trading partners -
>> and having that be easy and inexpensive enough to be worthwhile, in
the
>> context of the overall business relationship. (The paper you link is
>> quite flawed in its most basic premises and approach, IMHO).
>
> Pretty much. I'd second that.
>
>> Don't get me wrong - I'd love to have a technology that could do at
>> least some connections P2P, and would do it for free.
>
> I think that there's a lot of talk and promises about this in the
> marketplace. But it usually comes down to it needing some (quite)
> expensive programming being done in an outsourced setting. It starts
> off with the promise of cheap... but ends up being more costly than
the
> clients could have ever imagined because you end up having to provide
> on the job training for the programmers even though you are being
> charged full market rates.
>
> It's interesting to pick up the pieces anyhow.
>
>> In fact, I expect we will end up doing P2P in future - but only
>> once we have a big enough group of SMBs connected to have a stable
set
>> of end-to-end process requirements. Then and only then will we (or
>> anyone else trying to do this) be able to deliver a P2P product that
>> actually works.
>>
>> There are no short cuts here.
>
> I think that's what a lot of us are trying to do. Sounds like a
> familiar soapbox anyway.
>
> Regards
>
> David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org



---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org



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