[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 ...
Onk! 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, Christopher -----Ursprüngliche Nachricht----- Von: Christopher Harvey [mailto:email@example.com] Gesendet: Dienstag, 23. April 2002 03:41 An: firstname.lastname@example.org Cc: email@example.com 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 discussion that we get understanding... Don't get me wrong; my sentiment comes from years of working with SMEs in 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 very clear and direct (at the highest levels): "Go regional, go global, or die". The response is classic: "I have done business like this for 30 years why should I change, it will not affect me". (Many still apply this argument to 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 in 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 documents. ebXML must succeed; a simple set of document formats that can be supported to become a de facto standard must be the first step. People must get hooked. Regards Chris Harvey ----- Original Message ----- From: "Mike Rawlins" <firstname.lastname@example.org> To: "Christopher Harvey" <email@example.com> Cc: "'Todd Boyle'" <firstname.lastname@example.org>; <email@example.com>; <firstname.lastname@example.org> 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 do > 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 ROI > 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 upon > 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 model. > > 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>
Powered by eList eXpress LLC