[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-dev] RE: [EDI-L] Article on ebXML Core Components ...
On Tuesday 23 April 2002 05:17 am, you wrote: > Chris, > > Your comments are on the mark! I've personally been a bit dismayed over the > life history of the ebXML initiative that what once started out to have a > focus on "inclusion" of the SME and their needs has instead, at least in my > viewpoint, clearly moved over into the domain of the large enterprise and > what they need/want. > > What still amazes me is the assumption (apparently) on the part of the > large enterprise is that if they get their needs meet the small guys will > stand up, salute and march on. If the SME's needs are not truly addressed > here, as I said during one of my ebXML Marketing Work Group updates to the > ebXML plenary, my personal opinion is that the ebXML effort will have > failed. I have been lurking on this list for some time. My hope was that I was missing something, that if I just learned more about ebXML I would understand how ebXML will address some vital needs for small business. The above message, and others previously make me now believe this not to be the case. According to New Zealand Government Statistics about 95% of all businesses in NZ have computers. Of those businesses 95% have an Internet connection. And how many NZ businesses use the Internet for ecommerce? under 5%! A huge majority of businesses are still stuffing paper invoices into envelopes and spending 40 cents to physically deliver them - while at the same time using email to communicate with the very same entities they are invoicing. The same computers used for email are also used for accounting systems - all that is missing is a way for accounting systems to send the invoices in an email. My original (mis)understanding was that ebXML would provide a standard - a specification or XML schema for say - and invoice. We could then create a XML invoice and send it, and know that because its a standard that it would be supported at the other end if they have complying software. Lets avoid the issue of transport security right now - because thats trvial - I've already developed an open source implementation working based on PGP. My primary concern is that rather than specifying a simple standard like HTML or POP3 or SMTP which can be easily understood and easily implemented by software companies there is now a complex, hard to understand solution which doesn't really even provide any standard, and doesn't address the basic need to send a invoice in an email. I mean, if I were to ask you to send me a schema for an invoice so I can send to someone with ebXML I will find there isn't one - not a universal one - that I have to negociate with the receiver about their format. The fact is (at least in NZ) that an invoice will have the same information on it for 95% of the companies. There is no reason we cannot have a standard invoice schema for 95% of companies. Then to cater for the remaining companies - large corporates who have specific needs - we can allow inheritance, so that they can add stuff to the invoice schema - but not delete stuff. That way if a invoice is received from BigCorporate by SME the SME can still understand most of the body even though it contains additional elements. It seems to me that a huge amount of work is being done to please corporates who in the main have existing EDI systems anyway, while very little is being done to address the much simpler needs of the SME. All they need is a way to replace their paper transports with electronic transports. Turn paper to electrons. More than a year ago I started a open source project called "Internet Document Transfer". I have already implemented the transport system, which allows users to send files to each other encrypted with no messing about to understand public keys and suchlike (public key crypto is still used, but key handling is automatic). I have also developed a system of inheritable schema, although I might have duplicated the work of the W3C in some respects, and I have developed my own lightweight parser. Finally I have developed an actual application to send and receive invoices and orders as a proof of concept. What I am saying is not that everyone should start using my project - but that we could address the needs of SME's very quickly because in the main their existing system is simply paper. Trying to replace heavyweight EDI is much harder. On to addressing Christopher Harvy's post: > Very true but... I am increasingly of the opinion that unless we use the > power of the big guys down onto the SMEs, the latter will not bother to do > anything. Currently SME's have no compelling software. Literally. The accounting system companies I have talked to each have to maintain large numbers of file interfaces to deal with importing and exporting data from various other accounting systems. There is no simple solution to send an invoice like there is to send a simple text message. Generally there is no transport mechanism at all. > SMEs do not have much of a collective voice except the scream that will > come when they big guys hit them were it hurts. So, can we blame the big > guys for "taking charge"? What we don't seem to be addressing is that the needs of the corporates are very different to the simple needs of the SME's. All this stuff about forming relationships doesn't relate much to the transactions of an SME which are mostly adhoc - ie with people they will not have an ongoing relationship with. > As you may gather, my patience with (some... most) SMEs is wearing thin. > The average SME will ignore change until it is forced otherwise (at least > in this part of the world). We are slowly getting more and more of the big > corporations telling our SMEs: "Do it electronically, or lose the > business". Good, about bl**dy time. Most SME's I have delt with would just love an easy way to transmit invoices and orders. The problem is that there is no standard for the accounting companies to decide on. They don't want to pay for ongoing 'translation' services. Perhaps they are just as frustrated with you if what you are pushing on them isn't something that fits their business? > The SMEs have only themselves to blame. I am new to ebXML but my 0.02 cents > worth is to ask all involved to understand the needs of the SMEs but to use > the big guys to force change. The needs of corporates nd SME's are different. The corporates will push for complex expensive solutions that they will use to replace the complex EDI solutions they have now. SME's just want something to send and receive common business documents. Besides which, having a common standard will be good for everyone - even corporates. Sure they will have to inherit from the standard to build in the needed functionality, but at least they wouldn't need to worry about whether joe bob SME has a compliant system. Finally a comparision: Imagine a world in which email used an ebXML like system - a world where there was no SMTP, and every email software company used a different protocol. In order to make it all work large translation services would charge users to translate between all the different protocols. The protocols themselves would be very complex because they would need to cater for all the functionality required in corporates. Email software is very expensive because of the complexity of dealing with all the functionality. And only 5% of people on the Internet would be able to afford it - both in terms of software and transmission fees. This is what we are heading for if we drive the standartd according to corporate needs. However, if we address the needs of the SME - create simple standards like SMTP it will benefit both SME's and corporates. View my project at: http://www.devcentre.org/idtrans By the way, if you are interested in helping me with my open source implementation please let me know. I am not making any money on the project, so currently its part time. I need more developers to help move it forward. The current work is in Delphi and Java, although ports to C and other languages would be welcome. Regards, Peter Harrison Nothing But Net Limited http://www.nothingbutnet.co.nz
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC