[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Comments on Vienna spec 0.56
Hi, David -- I have worked with Dimitri for some time, and used to do much of the supplier integration work at Commerce One. One business scenario is the "enterprise buyer". An enterprise buyer receives a catalog from a supplier and publishes it on an internal purchasing application. Sometimes the publishing is done automatically, but usually the buyer wants to verify that the items offered are "on contract" and that the prices match the contract price. Users within the enterprise can then place orders from the catalog. Pricing information would typically be uploaded regularly; the catalog changes more slowly than the pricing does. Managing available-to-promise at the buyer site is seldom done, though some suppliers offer ATP information interactively to buyers located at important customer sites. -----Original Message----- From: Welsh, David [mailto:David.Welsh@nordstrom.com] Sent: Friday, April 06, 2001 1:06 PM To: 'Sigmund Handelman'; Cherkassky, Dimitri Cc: 'ebxml-poc@lists.ebxml.org' Subject: RE: Comments on Vienna spec 0.56 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 > ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: ebxml-poc-request@lists.ebxml.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC