RE: [ebxml-dev] BPSS and WSCI

[Todd Boyle <tboyle@rosehill.net>]

At 02:04 PM 6/25/02, Michael C. Rawlins wrote:
>Jean-Jacques put this very nicely:
>
>At 04:07 AM 6/25/02 -0400, Jean-Jacques Dubray wrote:
>
>><JJ> The fundamental achievement of BPSS is the state synchronization
>>between two (business) parties, whether this is part of a "commitment"
>>or a more casual message interchange. In any B2B message exchange (even
>>between a travel agent and an airline) this is mandatory. Imagine the
>>cost of getting periodically out of synch with your business partners?

We have always been out of synch, have never been in synch, and yes it is 
costly.

>While I agree with these statements, I must also note that they also point 
>out one of the more formidable problems that application vendors will have 
>in supporting the BPSS.  Every application already has it's own state 
>machine.  These state machines are usually organized around the point of 
>view of internal business processes (for example, many systems won't let 
>you invoice without an order, or invoice without first indating that the 
>ordered goods have been shipped).   Implementing a BPSS will require one 
>to map the states of these existing machines onto those specified in the 
>BPSS.  So, added to the burden of mapping application data to UIDs (or EDI 
>data elements in our current world), vendors and/or end users have to map 
>application states to BPSS process states.  That's fine so long as the 
>BPSS states are uniform (like a defined dictionary of states), but if they 
>are different then life gets very complicated (much more so than just 
>supporting both X12 and EDIFACT invoices).  In addition, if the BPSS 
>specifies a state that can't be easily matched to an internal application 
>state, then either application modifications are required in order to 
>support the state or the user is forced to intervene and handle that state 
>"out-of-band" as a manual exception.

Using the network allows parties to notify trading partners of events, and 
reach some state alignment.  If over-engineered, yes, the cost of the 
software will swamp the economic benefits.

>And about getting "out of synch" with your business partners - I'm sure 
>that there are a few people who have this problem and for them I'm sure 
>that it is a big problem.  However, most application systems I've worked 
>with that support e-Business in any serious fashion are already configured 
>to avoid this type of thing.  I don't see it as a major concern for most users.

That may be true for say, the 5000 largest companies in the US.  However, 
the number of small businesses is 5000 squared. (25 million) and we haven't 
even talked about Individual consumers.

The economic choices of the largest companies to date has been to dictate 
their EDI requirements and force their supply chain into alignment.  At the 
edges of the EDI communities are hundreds of millions of bilateral 
connections left without integration.  The costs of these unintegrated 
business processes (like all other costs, in a free market) are included in 
the cost of stuff General Motors buys. Thus General Motors is exceedlingly 
stupid to dictate some interfaces to make perhaps 1000 bilateral 
connections efficient, but in the process causing itself to bear the costs 
of 1 million manual bookkeeping processes further up the supply chain. Far 
better if General Motors adopted Quickbooks QBXML (or more realistically 
something like UBL or OAG) as its Enterprise interface.

>This leads me to the conclusion that while the BPSS and the UMM upon which 
>it is based may be valuable tools for documenting and agreeing on business 
>processes (for those who find ROI in using them), I see little utility for 
>them in the near future for actually automating the execution of business 
>processes.

That is an interesting phrase, "automating the execution of business 
processes".  Nobody ever really delegates the control over enterprise 
resources to unrelated parties.  I realize, some large enterprises delegate 
some immediate controls but those are backed up by contract ensuring the 
delegatee pays, i.e. they are wrappered within a larger BP which the Owner 
controls.

I'm a one-man company.  I don't exactly want my software to implement BPSS 
literally, aligning my balances of AR/AP or cash with the counterparty, or 
align the status of who owns the inventory.   I just want my software to 
show me when my vision of things differs from the untrusted external 
parties, so that I can "click to accept" their view or "click to 
reject/challenge".

I just want the BPSS to reach a level of stability that a catalog of 
processes can begin to be fleshed out by the business community.  Without 
that, the whole thing is an academic exercise afaics.   I don't think the 
enterprise software vendors (usu. major OS vendors) are going to implement 
any of the three competing BP models.  I think they are just going to 
observe whatever behavior patterns develop, and whatever document content 
begins to develop as markets, and then adopt some of it, break other parts, 
and invent new strategies to escape from standardization.  The software 
industry is a living exercise in game theory and nothing else.   The design 
of BPSS should itself be a collossal game of absolutely capturing vendors 
and ensuring vendors cannot capture above-normal economic returns through 
any rent or portal schemes.  That's the only way SMEs are going to touch 
this stuff and if you don't win the hearts and minds of SMEs this is a 
*big* waste of time.

Todd


>Mike (OK - so I still see the glass half empty ;^) )
>
>
>>Michael C. Rawlins, Rawlins EC Consulting
>
>www.rawlinsecconsulting.com
>
>
>----------------------------------------------------------------
>The ebxml-dev list is sponsored by OASIS.
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.ebxml.org/ob/adm.pl>