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: AW: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...


What I liked most at ebXML from the very beginning was the
"document-independency". Approaching a customer, offering a reliable,
low transmission cost, secure(d) standard which brings with it a huge
count of (not obligatory) opportunities (actually features) also
offering a migration path. (Answering the customers question "And I do
need to develop all my mappings from incoming to inhouse system and
inhouse to outgoing again?" with "No, sure you don't!" ("... but you
can, if you like to.")

Following this discussion I (again) get the impression that a huge count
of people is waiting for the 1001st definition of a invoice and the
5096th definition of a purchase order. 

Again (I expect) we will face the reality that even SME will require
branch specific information in their documents and will "interpret" this
or that so or different, will use price including tax and the addition
of tax and net price will not match the total price and so on. Will face
the issue that they could receive a very nice and well formed and well
filled ebXML PO but their ordering system (programmed by a student in
1991 who "forgot" to write a documentation as well) cannot handle XML
(even close) but another student developed a converter for the thee ANSI
message types they need to send and receive, which is working fine
(since 1992:-). 

Somehow I get the impression that we are assuming SME to have an
excellent and well designed IT (and message) infrastructure where ebXML
messages can be easily adapted into what no other message format of the
past was able to achieve. I - somehow - doubt that.

I really appreciate the dictionary definition, to define a strong
"CoreComponent library" where you can build messages from if you need.
But in my experience you don't need to for standard
EDI/B2B/default-Business messages. 
Small fish are doing business with bigger fish and the bigger the fish,
the more suitable for himself he defines his water (and the small fish
have to swim in there if they want to live no matter whether they like
to or not).

Best Regards,

-----Ursprüngliche Nachricht-----
Von: Christopher Harvey [mailto:ckharvey@zaratechnology.com.sg]
Gesendet: Dienstag, 23. April 2002 03:41
An: mike@rawlinsecconsulting.com
Cc: ebxml-dev@lists.ebxml.org
Betreff: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...

Mike, and others,

It's great to see such a likely discussion. It is only through
that we get understanding...

Don't get me wrong; my sentiment comes from years of working with SMEs
Asia - I cannot speak for other parts of the world - Here, there is a
definite *problem* with *them".

Our government is very hands-on (in the best kind of way). It makes it
clear and direct (at the highest levels): "Go regional, go global, or
The response is classic: "I have done business like this for 30 years
should I change, it will not affect me". (Many still apply this argument
even basic the use of technology!).

Now, in a small country, we cannot afford to let them die. So the
powers-that-be encourage a combination of sticks AND carrots. It is a
necessity; especially when one lives so close to China considering
everything she will achieve over the next 20 years.

Perhaps the best way to describe my sentiment is to say that I would
like to
use the big guys to "wake up" and get the attention of the SMEs to the
global economy, shrinking world, massive opportunities, power of the
Internet, etc... Perhaps small and developing countries have a different
perpective to the developed world.

My company has been working towards affordable fully-integrated SME
solutions along the e-commerce model for some time. I am very interested
anyone developing anything in this space. WIll check it out Peter.

Like others in this discussion, to me the most important component are
document layouts and basic protocols for the exchange of those
ebXML must succeed; a simple set of document formats that can be
to become a de facto standard must be the first step. People must get

Chris Harvey

----- Original Message -----
From: "Mike Rawlins" <mike@rawlinsecconsulting.com>
To: "Christopher Harvey" <ckharvey@zaratechnology.com.sg>
Cc: "'Todd Boyle'" <tboyle@rosehill.net>; <rachelf@ix.netcom.com>;
Sent: 23 April 2002 03:15
Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components

> Excuse me, but I can't help but violently disagree with most of this
> sentiment!  The main problem is not necessarily with the SME, but with
> the tools that are available to them.  Most would accommodate a big
> customer's request to do business electronically if it was cost
> effective for them to do so.  In the current way of doing things (and
> I'm afraid how ebXML may turn out the same way) it costs them more to
> business electronically than by other means.  And you blame *them* for
> that?  That's exactly how the big guys work.  If they can't show an
> on something, they won't do it.
> Your thinking reflects a big stick approach which I am increasingly
> seeing, with large buyers imposing financial penalties of all sorts
> their suppliers in force a shift of costs from the customer to the
> supplier.  Does this produce efficiencies?  In some cases yet, but as
> often as not it forces the supplier to raise their prices so that they
> can recover costs and still make a profit.  This is *not* a very good
> We need better solutions, not bigger sticks...

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>

[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