RE: Comments on Vienna spec 0.56

["Welsh, David" <David.Welsh@nordstrom.com>]

Dimitri,
Plse don't get me wrong, I do see hudge business opportunities when Product
Catalog's are sent/shared but especially integrated into the business
operating systems within company's properly. 
(There's nothing worse than trying to order a CD from a catalog to find out
the catalog is out of date OR someone got the UPC/EAN product id's wrong so
the customer (which is why we're all here) ends up with a CD Player ! -
Unless you wanted a CD player and only get charged the CD price !)

In the previous emails, I was really struggling with what the business
process around a catalog exchange could be. IE. I'm a business person and
what's the business problem I'm dealing with, not the technical service
solution. If you get my meaning.

Let's take a busines approach to this ..... Let me throw out something here
to see if maybe this works. Again if you can help me understand the catalog
exchange process business drivers a bit better then please jump in. 
How about as in the current drop ship model there is regular reporting of
available-to-promise inventory, there can also be a regular business
notification process in the same line which does a regular reporting of
latest product catalog information; so the drop ship 'vendor' role has to
deal with some typical product life cycle things; style/seasonal changes,
amended digital image (which is really something traditional EDI is weak
on), or even (!!) catalog sharing for those massive catalogs, ... 
Something like that ?

Dimitri, I do like Product Catalog's and I do deal with it every day in my
business but can you help me 'frame' a good business process angle you may
have had in mind. If the business angle above when added to the drop ship
scenario in Figure 2 makes sense then let's throw it into the mix. It's not
hard to add, and it actually complements the drop ship model quite nicely.

Does that make sense ?

Thanks
Dave



> -----Original Message-----
> From: Sigmund Handelman [mailto:swhandel@us.ibm.com]
> Sent: Friday, April 06, 2001 11:25 AM
> To: Cherkassky, Dimitri
> Cc: 'ebxml-poc@lists.ebxml.org'
> Subject: RE: Comments on Vienna spec 0.56
> 
> 
> 
> Hello,
> 
> I will work with Sid and Philippe to "improve" the scenario 
> so hopefully we
> should have this done by the middle of next week. We did have 
> "catalog" in
> the original work from Mark Hale and then the Business 
> Process Team said
> they would help us on the Drop Ship. That is why we have the mismatch.
> 
> We will work on this next week, and it will come out in 0.57 
> (with change
> bars).
> 
> Regards, Sig
> 
> 
>                                                               
>                                                              
>                     "Cherkassky, Dimitri"                     
>                                                              
>                     <dimitri.cherkassky@commer       To:     
> "'ebxml-poc@lists.ebxml.org'" <ebxml-poc@lists.ebxml.org>     
>                     ceone.com>                       cc:      
>                                                              
>                                                      Subject: 
>     RE: Comments on Vienna spec 0.56                         
>                     04/06/2001 01:51 PM                       
>                                                              
>                                                               
>                                                              
>                                                               
>                                                              
> 
> 
> 
> David,
> 
> David,
> 
> At the Vancouver F2F the POC group agreed to demonstrate 
> catalog exchange
> in
> the runtime portion of the Vienna demo.  (BTW, this is not 
> the only runtime
> demo we wilI present as you can tell from the spec; we will also show
> interaction with a payment authority and a financial 
> institution.)  I fully
> agree with you that we should include a meaningful demo of the ebXML
> business process capability in the Vienna demo.  We need input and
> cooperation from the BP group to make it happen.
> My comment,  however, had nothing to do with BP.  Unless I'm 
> misreading the
> 0.56 spec, figures 2 and 3 are showing the entire e-business scenario
> covered by the POC demo.  My comment is of an editorial 
> nature.  It is that
> the figures 2 and 3 do not reflect the catalog exchange 
> interaction that
> was
> agreed upon.  The figures should be synchronized with steps 1 
> - 3 on p.18.
> 
> 
> Dimitri Cherkassky
> 
> 
> 
>  -----Original Message-----
> From:           Welsh, David [mailto:David.Welsh@nordstrom.com]
> Sent:           Friday, April 06, 2001 9:57 AM
> To:        Cherkassky, Dimitri; 'ebxml-poc@lists.ebxml.org'
> Subject:        RE: Comments on Vienna spec 0.56
> 
> hmmm .. but figure 2 as it is represents a whole real 
> **business process**
> as it is, that's used in the Internet e-tail and the catalog 
> sales worlds,
> where both are called a 'direct to consumer' (or in slang 
> terms 'drop ship'
> or I've heard 'customer direct') supply chain model.
> 
> The **business process** has it's actors and roles and it's 
> collaborations
> and it's transactions and it's failure states and it's 
> success states, all
> of which are a must for the BP part of ebXML.
> If the POC is going to show "end-to-end" ebXML, which it must 
> as Vienna it
> the delivery date of all of ebXML, then it means all of the 
> ebXML project
> team's word deliverables get's roped into the POC and to meet 
> ebXML's basic
> purpose to exists we must start with a business process and end with a
> business process.
> 
> So to the business process model in question in figure 2, 
> it's not a sales
> order business process and I can't see any product catalog exchange
> business
> process going on :
> - unless you count the Internet dotcom's web site is actually 
> publishing a
> catalog thru the website and then the business process (ie. 
> buy/sell) is
> about product selection and shopping baskets.
> - unless you count on mass snail-mailings of product 
> catalogs, and I don't
> think that'd be a good idea to show in Vienna.
> 
> One of the complaints I heard in Tokyo about the execution of 
> the business
> process in the POC was the *business process* wasn't real 
> enough *for a
> business person*.
> 
> Nope, sorry Dimitri, I still don't see what the *business process* of
> catalog exchanges would be that would be supportive of the 
> differentiator
> aspects of ebXML over somthing like say EDI which the most 
> people in the
> world today know.
> Please explain.
> Thanks
> Dave
> 
> 
> > -----Original Message-----
> > From: Cherkassky, Dimitri 
> [mailto:dimitri.cherkassky@commerceone.com]
> > Sent: Thursday, April 05, 2001 6:23 PM
> > To: 'ebxml-poc@lists.ebxml.org'
> > Subject: RE: Comments on Vienna spec 0.56
> >
> >
> > I apologize that I was not more explicit in my comments. My
> > point is that we
> > are planning to use product catalog exchange in the demo (p.
> > 18, steps 1 -
> > 3), however this is not reflected in the Figures 2 and 3.
> > Instead, Figures
> > 2 and 3 show an order entry scenario.  My recommendation is 
> to updates
> > Figures 2 and 3 to reflect what will be actually presented 
> in Vienna.
> >
> > -----Original Message-----
> > From: Welsh, David [mailto:David.Welsh@nordstrom.com]
> > Sent: Thursday, April 05, 2001 6:14 PM
> > To: Cherkassky, Dimitri; 'ebxml-poc@lists.ebxml.org'
> > Subject: RE: Comments on Vienna spec 0.56
> >
> >
> > Hi Dimitri,
> > I still need to talk to Sig about filling in the BP details
> > but to your
> > comments :
> > > pp. 9, 10.  Figures 2, 3.
> > > The figures do not show Product Catalogue exchange.  The
> > > figures do show an
> > > order entry scenario that I thought we were not doing.
> > >
> > Trust me, in a real business world, figures 2 & 3 go way
> > beyond order entry.
> > The pictures are meant to graphically show to essential
> > business elements of
> > a real business where promising a customer, buying and
> > selling inventory
> > with customer and vendor payments included and direct to
> > customer product
> > delivery are all going on.
> >
> > Now product catalog exchanges itself is a very interesting subject
> > (especially for very large catalogs with 300,000 plus
> > products) where XML
> > technology, especially for digital content, has many
> > descriptive advantages
> > over traditional EDI business processes (but maybe isn't as
> > size efficient
> > as old EDI).
> > What I was wondering was if you could sketch out the business
> > process case
> > within which the activity of product catalog exchange might
> > be used, showing
> > esssentially why ebXML is better than say EDI ?
> >
> >
> > Thanks
> > Dave
> >
> >
> >
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-poc-request@lists.ebxml.org
> >
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-poc-request@lists.ebxml.org
> 
> 
> 
> 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-poc-request@lists.ebxml.org
>