RE: bpPROC

["Sharma, Nita" <nsharma@Netfish.com>]

 Hi David,

thanks for your comments. 

>So my question is that if the focus of ebXML business process is framed
>largely at Purchase Orders, knowing that Small Enterprises hardly use of
>them and large Enterprises are already efficient in this area, what
>positive
>impact is ebXML anticipated to have.
>

This document, "Catalog of Common Business Processes" is not at all focused
on Purchase Orders. It has a catalog of over 300 business processes that can
be used across various industries. You are correct in one respect and that
is we should have defined all those processes instead of defining just a
handful, which happen to be purchase order related and in our examples as
well we have used purchase orders. We could have used any transactions..
payments..invoices..Financial settlements ..any thing. 

ebXML is not at all transaction specific. It lays out the infrastructure
framework for doing e-business using any transactions. It goes beyond
transactional processing into collaboration processing which is a
choreography of transactions exchanged between trading partners having
pre-established agreements. Via the various ebXML BP group deliverables we
are defining the methodology to define and model business processes or
re-use already defined business processes from ebXML or UDDI global
repositories, the specification schema for defining those business processes
in XML to be used for run time...etc. 

>In fact, I get the impression that they don't want large numbers of people
using ebXML.

If this statement is true, then ebXML will never succeed. I am not sure if
you are aiming this towards ebXML as a whole or not. Through out this
Catalog document we stress on reusability. This implies that one can define
business processes and store it in the Global Repository for any one else to
discover. The success of this vastly depends on the user community storing
and retrieving business processes in the repository. So the larger number of
users, the more successful ebXML will be

I hope I was able to express some essence of ebXML. Feel free to discuss
this further.

Cheers

- Nita

EDI Product Manager
Netfish/IONA
408-3509517


-----Original Message-----
From: David Lyon
To: ebxml-bp@lists.ebxml.org; ebxml-ccbp-analysis@lists.ebxml.org;
ebxml-core@lists.ebxml.org
Cc: Paul R. Levine
Sent: 4/29/01 6:14 PM
Subject: Re: bpPROC

Interesting reading. Everybody has done a very good job at ensuring that
this document comes together well. Good work. However the document only
addresses the wants of bigger organisations, and has the same push as
all of
the EDI systems that we have ever seen, and that is:- Purchase Orders.

Betty is able to truly capture what the response of SMEs will be.
Millions
of businesses are going to say the same thing about the description of
the
business process:

Betty:
> I have been in business 6 years and have created 1 PO and have
received 2
so a PO is not big on my list of wants.

That's the way it is.

With large organisations it not always dissimilar. One company that I've
done consulting for only receives about 20 POs for day (each usually for
over a million dollars worth of product).

These POs, both EDI and manual, must be received between 11:00am and
12:00am. A Longer window means unneccessary cost, and so they've been
able
to streamline the process into something that works quite well.

With the business process defined in this document, ebXML might shave
possibly ten minutes off a the process that is only taking a few hours
anyway. With each PO usually for over a million dollars worth of goods,
the
operator isn't placed in a high pressure job. He makes a big fuss over
how
much trouble he has to go to to download the EDI files from GEIS, but I
think he's just trying to play up the importantance of his job.

So my question is that if the focus of ebXML business process is framed
largely at Purchase Orders, knowing that Small Enterprises hardly use of
them and large Enterprises are already efficient in this area, what
positive
impact is ebXML anticipated to have.

The only benefit that I can see is for the business process modelling
consultants who are looking for increasingly smaller faults to correct,
without seeing any of the broader and more pressing applications of XML
technology.

I get the impression that ebXML is much like the current NASA space
station
situation. The ebXML designers are afraid to make design changes that
would
allow too many passengers to come on board. In fact, I get the
impression
that they don't want large numbers of people using ebXML.

To quote something I saw Buzz Aldren say on the news last night speaking
about the NASA administration, "They think that only superhumans should
be
able to do it [fly in space]".

For just $20M one can get into space now, and yet the price of ebXML
will be
for many companies more expensive.

I just can't see why ebXML has to be made more difficult than achieving
space travel.

Maybe we need Russians working on ebXML also.

Take care

David Lyon

----- Original Message -----
From: Paul R. Levine <plevine@telcordia.com>
To: <ebxml-stc@lists.ebxml.org>
Cc: ebXML-BP (E-mail) <ebxml-bp@lists.ebxml.org>; ebxml-ccbp-analysis
(E-mail) <ebxml-ccbp-analysis@lists.ebxml.org>
Sent: Monday, April 30, 2001 4:55 AM
Subject: bpPROC


> This is the official transmittal of the final draft of the ebXML
Catalog
of
> Common Business Processes [bpPROC] reference document from the
> Analysis/Methodology Group of the ebXML Business Process/Core
Components
> Joint Delivery Team (BP/CC JDT) for public review prior to the Vienna
> plenary meeting.
>
> Included in the zip file are a pdf file of bpPROC and an doc file of
the
> log of comments and resolutions.
>
> Klaus Naujok and Karl Best are hereby requested to post bpPROC and the
> disposition log for public viewing.
>
> Regards,
>
> Paul Levine
> (See attached file: bpPROC_v0.99.zip)
>


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org