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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

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

Subject: RE: [ebxml-dev] Comprehensive generalization of CRM

Zack, thanks for your comments. Very interesting.  I totally agree
that sellers generally want to change their behaviors like chameleons,
in response to the behaviors or traits of prospects.   My own view is
the *automation* of replies to sales inquiries based on some rules,
would require that your robot receive inquiries in machine-understandable
format, and that it have sufficient knowledge about the requestor
to make smart decisions that increase sales.   Personally, I don't
think I'm interested in pursuing that.  That's too ambitious for me
to think about until there is a broader framework.

The first objective of any ebXML XRM workgroup (CRM, SRM, etc.) might
be to enumerate the 3 biggest issues from the customers' viewpoints,
and 3 biggest issues from sellers' viewpoints, that need to be improved
to allow them to use ebXML RR and BP in the discovery and negotiation
phase of the business process.

<boring but necessary stuff>
Supporting relationship management with software is an extremely
competitive business, insinuated throughout transaction creation and
historical transaction and contact history information.  xRM has become
one of the key differentiators between Enterprise software platforms.
There is less than zero chance of getting any particpation from those
ERP or platform vendors in ebXML.  Anything ebXML produces in XRM
will need to be mostly UML diagrams, vocabulary and coordinated
handwaving exercise.  It will have to capture those aspects of CRM
that are already accomplished fact in every ERP package.  Where the
profit of differentiation is nearly zero, and the profits from ebXML RR
or UDDI integration exceed the loss of market lock-in.

Finally, in response to Bob's point today this is not focused
exclusively on price and it would be the participants' decision
both on the buy and sell side, what areas of differentiation they
want to search and discover and encode into their Commitment.
The whole objective here is to provide Buyers and Sellers with
a facility to publish more granular information about themselves,
if and when they desire, and to get as much information as
the trading partner is willing to provide at the same time, especially
reputation history.

Nothing in my comments is particularly new except the suggestion
that the rights and obligations of participants in the registry need to
be pinned down with math (hierarchies information secured by
cryptography) instead of entrusting bare information to the
operator of the UDDI registry, or burdening the registry operator
to somehow secure or underwrite the accuracy of the information,
how it is used, etc.


At 05:26 PM 6/14/02, Zachary Alexander wrote:
>Todd and Rainer,
>I agree with both of you. Further, I would offer two suggestions for fixing
>the issues:
>1) Qualification Profile -- This profile would be used to store procedures
>for qualifying request for information from third party requestors.  One of
>the problems that I see is that the information stored in the registry could
>be used to adjust a business position (i.e., pricing, product mix, terms).
>You don't want to send this information out to requestors and/or competitors
>that aren't qualified buyers.
>2) Sales-differentiator Profile -- This profile would outline the companies
>and/or product lines sales differentiators.  My concern is that, currently,
>the only criteria for making purchasing decisions is price/cost.  This puts
>a lot of pressure on margins and doesn't speak to any of the other reasons
>why companies make buying decisions.  Big ticket items would benefit from
>this additional information.  This could also lead to automated preliminary
>RFP processing.
>-----Original Message-----
>From: Todd Boyle [mailto:tboyle@rosehill.net]
>Sent: Friday, June 14, 2002 5:07 PM
>Both ebXML and web services are weak at the thing businesses
>need most:  helping businesses find customers, evaluate what they are
>susceptible to buying, and closing sales.  Or helping businesses figure
>out what are all their possible products and services, they have an
>opportunity to buy or resell.  Or helping identify/qualify suppliers.

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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC